Continuing on from the previous article, BGP Path Attributes, I’ll cover the remaining popular path attributes.
Multi Exit Discriminator
The MED is an optional non-transitive attribute, which is the metric of BGP. Though other protocols rely almost entirely on the metric to calculate routes, the BGP metric is only used when there are two exit points from one AS into another AS. In my example
there are no places where this occurs. If AS2 and AS3 were combined into AS2, then MED could be used to influence how to get into AS1.
r3#show ip bgp BGP table version is 5, local router ID is 10.3.3.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 10.1.1.0/24 192.168.3.2 0 0 2 i *> 10.2.2.0/24 192.168.3.6 0 0 3 i * 192.168.3.2 0 2 3 i *> 10.3.3.0/24 0.0.0.0 0 32768 i
Here, the MED (metric) is all zero. To set it on r3:
router bgp 1 network 10.3.3.0 mask 255.255.255.0 route-map set-metric route-map set-metric permit 10 set metric 42
Here, the network is advertised after being passed through a route map, which sets the metric to 42. Indeed, we can see after a clear ip bgp * soft that it is the case:
r3#show ip bgp neighbors 192.168.3.2 advertised-routes BGP table version is 6, local router ID is 10.3.3.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 10.2.2.0/24 192.168.3.6 0 0 3 i *> 10.3.3.0/24 0.0.0.0 42 32768 i
And on r1:
r1#show ip bgp BGP table version is 40, local router ID is 10.1.1.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 10.3.3.0/24 192.168.3.1 42 0 1 i ...
If R1 had multiple routes to 10.3.3.0/24 through its own AS, then MED might be used to choose the route. Lowest MED wins.
Cisco has more detail on MED: How BGP Routers Use the Multi-Exit Discriminator for Best Path Selection
Just as a final point on MED: By setting MED you are attempting to influence the decision of how your neighbouring AS sends traffic to you (assuming you have two entry points), but the final decision remains with them.
Local Preference
This is a well-known discretionary attribute that is only sent within an AS — never to peers. If routers within an AS have multiple destinations to a route, local preference can be used to break the tie. Since it’s a preference, a higher preference wins.
In the example, R2 has multiple ways to get to R3:
r2>show ip bgp 10.3.3.0
BGP routing table entry for 10.3.3.0/24, version 55
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
192.168.3.9
2 1
192.168.3.9 from 192.168.3.9 (10.1.1.1)
Origin IGP, localpref 100, valid, external
1
192.168.3.5 from 192.168.3.5 (10.3.3.1)
Origin IGP, metric 0, localpref 100, valid, external, best
Without getting into how BGP makes decisions, the AS-path of “1″ via R3 is better than going “2 1″ via R1. However, local preference trumps AS-path, so if I want to use R1’s path to AS1, I’ll need to have R2 set local preference to something higher than the default of 100 for R1’s routes. (note there are many ways to do it, per route, per neighbour, etc. Since I did the metric on a per route basis, I’ll do this one on a per neighbour)
router bgp 3 neighbor 192.168.3.9 remote-as 2 neighbor 192.168.3.9 route-map setlocalpref in ip as-path access-list 1 permit _2_ ip as-path access-list 2 permit .* ! route-map setlocalpref permit 10 match as-path 1 set local-preference 200 ! route-map setlocalpref permit 20 match as-path 2
This code applies a route map to routes coming in from r1. Anything passing through AS 2 (as-path acl 1) gets local pref set to 200 in clause 10. Any other routes (which there shouldn’t be, since this map is only applied to one peer) are matched (so they aren’t dropped), but no changes are made.
For more information on BGP regular expressions, see Using Regular Expressions in BGP
Now,
r2#show ip bgp 10.3.3.0
BGP routing table entry for 10.3.3.0/24, version 7
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
192.168.3.5
1
192.168.3.5 from 192.168.3.5 (10.3.3.1)
Origin IGP, metric 42, localpref 100, valid, external
2 1
192.168.3.9 from 192.168.3.9 (10.1.1.1)
Origin IGP, localpref 200, valid, external, best
So even though the AS-path is longer, the route via r1 was chosen because of a higher local preference. Had we done this on R3, R0 would also see the local preference, though it should only see one route since R3 will only pass along its best route.
Local pref and MED do much the same thing (LP on a more global scale since it works across different ingress ASes). Often providers will allow you to tag your routes with a particular community (see below) that causes them to set local preference. As such, you’ll rarely use MED with an ISP.
Weight
This one really isn’t an attribute per se, since it is Cisco proprietary and never sent outside the local router. Other than this, it is the same as local preference. Highest weight wins. Weight is checked before local preference, so this attribute lets you override local pref on a per router basis.
By default, routes learned from another router have a weight of 0, and a route originated locally has a weight of 32768.
Atomic Aggregate and Aggregator
I’m going to have to come back to this another time after talking about route aggregation. Like other protocols, BGP lets an administrator aggregate routes. However, depending on how routes are aggregated, both the aggregate and some specific routes can be sent out at the same time! These attributes add information about how the route was aggregated.
If you can’t wait, check out Understanding Route Aggregation in BGP.
Communities
Communities are an addition to the original BGPv4 that let an administrator tag routes with extra information that can be used downstream. RFC 1997 defines a community as:
A community is a group of destinations which share some common property.
For example, a provider might tag all its customer routes (ie direct peers) to let the other customers filter (ie to only accept customer routes)
Similarily, a customer may tag routes according to the provider’s policy to set local preference on a route, or to mark it as non exportable.
There are four predefined communities: NO_EXPORT, NO_ADVERTISE, and NO_EXPORT_SUBCONFED, and INTERNET. The first three tell the peer not to send a route outside the confederation, local router, and peer’s AS respectively. INTERNET routes are the default, meaning they can be exported anywhere.
A real world example of how communities are used can come from the Allstream RADB entry:
$ whois AS15290@whois.radb.net
...
remarks: ***********************************************************
CUSTOMER COMMUNITIES:
Allstream Corp customers may choose to affect our
local preference from their routers by setting their
routes with the following BGP communities:
Community Definition Description
--------- ---------- -----------
(default) Local preference = 100 customer
15290:100 Local preference = 100 customer primary
15290:90 Local preference = 90 customer back-up
15290:30 Local preference = 30 customer fall-back
If a multi-homed customer sets the community to
15290:30, Allstream Corp will prefer an announcement
from a peer over directly connected customer
---------
Customers may also choose to control their advertisements
by setting thier routes with following BGP communities:
15290:333 Don't send to Transit (default)
15290:333 15290:100 Don't send to Transit LP=100
15290:333 15290:90 Don't send to Transit LP=90
15290:444 Send only to BGP downstream (default)
15290:444 15290:100 Send only to BGP downstream LP=100
15290:444 15290:90 Send only to BGP downstream LP=90
-----------------------------------------------------------
PUBLIC/PRIVATE PEERS:
None (Default) Local pref=80
15290:80 Set local pref=80 on AS15290
15290:75 Set local pref=75 on AS15290
-----------------------------------------------------------
FILTERING POLICIES:
- We do NOT acknowledge MEDs from any:
- Public Peer
- Private Peer
- Downstream Customer
- Allstream Corp filters RFC1918 and other such
advertisements with prefixes longer than /24
- Peering requests/infos should be sent to:
peering@allstream.com
- Public Route-Server is:
route-server.east.allstream.com
Just as a quick example, R3 will tag its local route with NO_EXPORT, and we’ll see that R1 and R2 won’t learn about the route through the other peer.
Before:
r2#show ip bgp ... Network Next Hop Metric LocPrf Weight Path * 10.3.3.0/24 192.168.3.5 42 0 1 i *> 192.168.3.9 200 0 2 1 i
R3 config:
router bgp 1 no synchronization bgp log-neighbor-changes network 10.3.3.0 mask 255.255.255.0 neighbor 10.50.0.1 remote-as 1 neighbor 10.50.0.1 next-hop-self neighbor 192.168.3.2 remote-as 2 neighbor 192.168.3.2 send-community neighbor 192.168.3.2 route-map noexport out neighbor 192.168.3.6 remote-as 3 neighbor 192.168.3.6 send-community neighbor 192.168.3.6 route-map noexport out no auto-summary ! route-map noexport permit 10 set community no-export
Back on R2:
r2#show ip bgp 10.3.3.0
BGP routing table entry for 10.3.3.0/24, version 14
Paths: (1 available, best #1, table Default-IP-Routing-Table, not advertised to EBGP peer)
Flag: 0x208
Not advertised to any peer
1
192.168.3.5 from 192.168.3.5 (10.3.3.1)
Origin IGP, metric 0, localpref 100, valid, external, best
Community: no-export
(r1 has the same thing except the peer’s IP address is different).
So, we can see that r1 and r2 didn’t tell each other about the routes they know from AS1 because R3 tagged the routes with no-export.
No user commented in " BGP Path Attributes continued "
Follow-up comment rss or Leave a TrackbackLeave A Reply