Samples of BGP Information
- This is a preview of the essay.
To view the full text you must login!
This same system can also be used for prefixes outside of or "behind" AS 2
For example, it could be used to tell AS 1 to use Link A when sending traffic to prefixes in AS 3, because the outbound path from AS 2 to AS 3 is closer to Link A than Link B
A subtle problem with the MULTI-EXIT-DISCRIMINITOR attribute is that one AS sets the value, while another AS reacts to it
For this reason, it is typically used only in a trusted provider-to-subscriber relationship, not between two competing ISPs
Here's why:
If you had two high-level ISPs with two interconnecting links in New York and San Francisco, the MULTI-EXIT-DISCRIMINATOR could be used by one to force more of their shared traffic onto the other
And since ISPs are in the business of buying and reselling bandwidth, that practice might be considered unfair
For example, the ISP BlackHat.com could be configured to ignore MULTI-EXIT-DISCRIMINATORs received from its competitor WhiteHat.com, while still sending its own discriminators to WhiteHat
15-9A Dirty Tricks With MULTI-EXIT-DISCRIMINATORs
[Note that both ISPs are sending valid MEDs]
In this example, WhiteHat is sending MEDs to BlackHat that say to use Link A for traffic bound for New York (10 < 50)
But if a customer of BlackHat in San Francisco wanted to communicate with a customer of WhiteHat in New York, BlackHat could ignore WhiteHat's discriminator (which says to favor Link A), and instead force that traffic directly onto WhiteHat over Link B in San Francisco
(This would be done using BlackHat's LOCAL-PREF attribute, which we'll cover in a moment)
So mostly WhiteHat resources are used, rather than BlackHat's
But on the return path from New York, WhiteHat would innocently read BlackHat's discriminators and send the return traffic over its own network until it reached Link B in San Francisco
For this reason, ISPs often ignore MULTI-EXIT-DISCRIMINATORs from other ISPs that aren't their own customers
This scenario points out one fundamental difference between interior and exterior routing protocols
Interior routers trust each other exterior routers don't
More to the point, the decision about which routes to accept form a neighbor, and the preference with which those routes should be treated, is a local decision [Stewart p. 65]
The LOCAL-PREF Attribute
Besides the fairness problem with the MULTI-EXIT-DISCRIMINATOR, they are only useful in choosing between multiple paths between the same two autonomous systems
And it is quite possible for an AS to have multiple paths to a prefix, such that the next hop can be one of several other AS's.
15-10 Example Topology With Multiple Paths [Stewart]
In this example, AS 1 injects the prefix 138.39.0.0/16 into BGP by advertising it to both AS 2 and AS 3
AS 2 and AS 3 could then pass that prefix on to AS 4, giving AS 4 two different paths to that prefix
The MULTI-EXIT-DISCRIMINATOR can't be used here, because there is only one connection between each pair of autonomous systems and because AS 4 may want to keep control over which path it selects
For example, AS 3 may provide more reliable or lower cost service than AS 2 so AS 4 wouldn't want to choose AS 2 just because it advertised an otherwise more attractive path
This is an example of a situation where policy routing comes into play
The way that AS 4 maintains control over this is by configuring the LOCAL-PREF attribute (Type Code 5) assigned to prefixes heard from AS 3 to be higher than those heard from AS 2
(The reason that this sounds confusing is that a higher numbered LOCAL-PREF is considered to be more desirable, while a lower numbered MULTI-EXIT-DISCRIMINATOR is better)
So AS 4 is establishing a policy that says, "I don't care whether AS 2 claims to have a better path to 138.39 if I have a choice, I want to use AS 3 as my next hop"
So, in practice, it's the LOCAL-PREF attribute that is most often used to express preference for one set of paths over another, rather than the MULTI-EXIT-DISCRIMINATOR
This is because with LOCAL-PREF, you get to specify the preferred path with MED, another AS makes the decision for you
LOCAL-PREF is well-known discretionary, meaning that it may or may not be sent in a particular UPDATE message (but all routers must understand it)
There is a difference in the way that LOCAL-PREF is used, compared to the other attributes that we've discussed
The destination for a BGP Update with a LOCAL-PREF attribute is a BGP peer within the same autonomous system
Up until now, we've been assuming that BGP sessions were only established between two different ASs
Later on, we'll discuss the use of BGP within an AS
The ATOMIC-AGGREGATE and AGGREGATOR Attributes
The purpose of the ATOMIC-AGGREGATE attribute (Type Code 6) is to allow a BGP speaker to inform its peers about how to handle potentially overlapping prefixes
This attribute is well-known discretionary too, and its just a simple boolean flag
Let's use the prefixes 138.39...