The BGP Community attribute is a way of grouping a set of destinations so that a common policy can be applied to all. If a router receives this attribute and does not understand it, it will simply pass it on in its own update.
Routers participating in a community can be programmed to apply a routing policy to community routes. The Community attribute is not restricted to one network or a single AS.
There are three common/prefined communities that can be set in BGP updates:
This can be used where BGP can learn routes from an IBGP (BGP internal to the AS) peer and also an IGP (internal routing protocol - RIP, IGRP, OSPF etc.). If BGP is told to synchronise then:
This may be desirable when an AS is carrying transit information or not all of the routers in the AS are running IBGP. (It is possible for BGP (internal and external) to know about a route that hasn't fully propagated through the non BGP routers in the AS ie. for there to be a transient "black hole".
Part of this job has already been achieved when we started BGP. The statement:
network [IP address] mask [netmask]
Will cause the router to advertise to BGP any matching routes learned via an IGP.
In addition, the commands:
redistribute static redistribute connected
Could be used to advertise static routes and directly connected routes via BGP.
This is just the distribute-list idea from the Route Redistribution lecture. This uses one or more access-list statements to select or reject the routes to be advertised. For BGP the distribute-list is applied via the neighbor statement, rather than via a separate statement within the routing protocol configuration:
neighbor A.B.C.D remote-as 300 neighbor A.B.C.D distribute-list list_number in|out
This is done with the ip as-path access-list statement:
ip as-path access-list list_number permit|deny as_regular_expression
For example:
ip as-path access-list 5 permit _131_
This will match the AS number 131 appearing anywhere in the AS Path attribute. It is also possible to match an AS number at the beginning or end of the AS Path attribute (the syntax is like that of Unix regular expressions).
Route Maps allow the router to modify route attributes for those routes that match the "Route Map". It is common for AS Path filtering to be implemented in conjunction with Route Maps since this allows the filtering to be readily applied to multiple routes.
The syntax of these is:
route-map map-tag permit|deny sequence_number match statements set actions
The map-tag is the name of the route map; the permit or deny key-words specify whether to accept or reject the prefixes that match the match statements.
The map statements are applied in sequence number order. The match statements can check for AS path, BGP Community list, IP address etc. The set command can modify one of the attributes of the route.
Example 1:
route-map example1 permit 10 match ip address 1 set metric 200 ! route-map example1 permit 20 match ip address 2 set metric 150 ! access-list 1 permit 11.0.0.0 0.255.255.255 access-list 2 permit 0.0.0.0 255.255.255.255
This sets the MED to 200 for prefixes matching access list 1 and to 150 for all other IP addresses.
as-path Match BGP AS path list community Match BGP community list extcommunity Match BGP/VPN extended community list interface Match first hop interface of route ip IP specific information length Packet length metric Match metric of route route-type Match route-type of route tag Match tag of route
as-path Prepend string for a BGP AS-path attribute automatic-tag Automatically compute TAG value comm-list set BGP community list (for deletion) community BGP community attribute dampening Set BGP route flap dampening parameters default Set default information extcommunity BGP extended community attribute interface Output interface ip IP specific information level Where to import route local-preference BGP local preference path attribute metric Metric value for destination routing protocol metric-type Type of metric for destination routing protocol origin BGP origin code tag Tag value for destination routing protocol weight BGP weight for routing table
A link that is periodically advertised as WITHDRAWN then UPDATED is said to "flap".
The persistent propagation of messages can consume link bandwidth and increase router CPU usage as each router advises its neighbours.
Advertisements about flapping links can be suppressed by a feature known as Route Dampening. This involves detecting when a link is changing state too often and suppressing advertisements for a while.
Typically this is done by calculating a decaying average of the number of flaps in a given time. Each time the link flaps, it incurs a penalty. After some time has elapsed, the "average" is reduced by some percentage. This produces an exponentially decaying average.
If the average exceeds the suppress-limit it is no longer advertised. When the average falls below the re-use limit, the link will again be advertised.
Parameters such as half-life and the various limits are configurable. Typically, Route Dampening will suppress advertisements for around half an hour.
To reduce the size of routing tables by aggregating routes. Routers can be programmed to propagate summary routes only or summary plus more specific routes.
Interior BGP should be fully meshed, but in a large network, this results in a lot of peering sessions.
One solution to this problem is Confederations which allow for an AS to be broken into smaller areas, each area effectively being its own AS (using private AS numbers) which work together to form the larger AS.
This is a similar idea to domains/areas used within IGRP, EIGRP and OSPF. Each areas should be fully meshed internally (or use route reflectors, see next). The areas, though within the overall AS, peer using EBGP.
Rather than having a fully meshed IBGP network, each IBGP speaker can be configured to talk to a route reflector. A route reflector learns routes via BGP and reflects or advertises it back to each of the IBGP peers. Route reflectors are somewhat analogous of Designated Routers (DRs) within OSPF and result in a hub and spoke type topology, rather than a mesh network.
Used in IBGP networks with or without confederations.
This is a group of routers with the same update policy (same outbound route maps, distribute lists, filter lists, update source etc.). The grouping is for administrative convenience.
Members are generally within the one AS but also may be from outside the AS.
Members are grouped using the neighbor command.
See earlier slide - a set of routes that have a common routing policy applied.