On July 21st I’ll be teaching BGP Policy over at Safari Books Online. From the description:
This course begins by simplifying the entire BGP policy space into three basic kinds of policies that operators implement using BGP—selecting the outbound path, selecting the inbound path, and “do not transit.” A use case is given for each of these three kinds, or classes, of policies from the perspective of a transit provider, and another from the perspective of a nontransit operator connected to the edge of the ‘net. With this background in place, the course will then explore each of the many ways these classes of policy may be implemented using local preference, AS Path prepending, various communities, AS Path poisoning, and other techniques. Positive and negative aspects of each implementation path will be considered.
If you advertise routes through a provider to the global Internet, you might be wondering if you should go through the trouble of registering in the RPKI and advertising ROAs. What is the tradeoff for the work involved in what seems like a complex process? Cecelia Testart joins Jeremy White and Russ White to discuss recent work in measuring the value of the RPKI.
From the question pile: Route servers (as opposed to route reflectors) don’t change anything about a BGP route when re-advertising it to a peer, whether iBGP or eBGP. Why don’t route servers cause routing loops (or other problems) in a BGP network?
Route servers are often used by Internet Exchange Points (IXPs) to distribute routes between connected BGP speakers. BGP route servers
- Don’t change anything about a received BGP route when advertising the route to its peers (other BGP speakers)
- Don’t install routes received through BGP into the local routing table
Shouldn’t using route servers in a network—pontentially, at least—cause routing loops or other BGP routing issues?
I recorded the beginnings of a BGP training series over at Packet Pushers a short while back; they’ve released these onto youtube (so you can find the entire series there). I’m highlighting one of these every couple of weeks ’til I’ve gone through the entire set of recordings. In this recording, I’m talking through some more interesting aspects of BGP peering, including challenges with IPv6 link local nexthops, promiscuous peering, and capabilities.
Since BGP is designed to be an overlay protocol, it doesn’t really have good mechanisms for carrying routes within an autonomous system. In this video, I’m discussing some of the techniques developed to carry routes within an AS, including route reflectors.
My video on BGP convergence elicited a lot of . . . feedback, mainly concerning the difference between convergence in a data center fabric and convergence in the DFZ. Let’s begin here—BGP hunt and the impact of the MRAI are very real in the DFZ. Withdrawing a route can take several minutes.
What about the much more controlled environment of a data center fabric?
Several folks pointed out that the MRAI is often set to 0 in DC fabrics (and many implementations by default). Further, almost all implementations will use an MRAI of 0 for the first received update, holding the second and subsequent advertisements by the MRAI. Several folks also pointed out that all the paths through a DC fabric are the same length, so the second part of the equation is also very small.
These are good points—how do they impact BGP convergence? Let’s use the network below, a small slice of a five-stage butterfly fabric, to think it through. Assume every router is in a different AS, so all the peering sessions are eBGP.
This lesson in Russ White’s BGP course gets into withdrawing a route, MRAI time, implicit withdraws, BGP Hunt, graceful restart, and other topics.
At the most basic level, there are only three BGP policies: pushing traffic through a specific exit point; pulling traffic through a specific entry point; preventing a remote AS (more than one AS hop away) from transiting your AS to reach a specific destination. In this series I’m going to discuss different reasons for these kinds of policies, and different ways to implement them in interdomain BGP.
There are cases where an operator does not traffic to be forwarded to them through some specific AS, whether directly connected or multiple hops away. For instance, AS65001 and AS65005 might be operated by companies in politically unfriendly nations. In this case, AS65001 may be legally required to reject traffic that has passed through the nation in which AS65005 is located. There are at least three mechanisms in BGP that are used, in different situations, to enforce this kind of policy.
At the most basic level, there are only three BGP policies: pushing traffic through a specific exit point; pulling traffic through a specific entry point; preventing a remote AS (more than one AS hop away) from transiting your AS to reach a specific destination. In this series I’m going to discuss different reasons for these kinds of policies, and different ways to implement them in interdomain BGP.
In this post I’m going to cover local preference via communities, longer prefix match, and conditional advertisement from the perspective of AS65001 in the following network—