CONTENT TYPE
How BGP Really Converges
This lesson in Russ White’s BGP course gets into withdrawing a route, MRAI time, implicit withdraws, BGP Hunt, graceful restart, and other topics.
Hedge 131: Easier for the Computer or the Person?
One of the mainstays of scripting—and now network management—are increasingly focused on making things “easier” for the human operator. Does this focus on making things “easier” for the operator produce a better experience, though? Or does it create frustration as humans try to “outguess” the computer’s programming and process? Join Tom Ammon and Russ White as they discuss the problems with scripting, automation, and ease-of-use.
Hedge 130: The Importance of Network Inventories
Inventories are generally hard, and hence don’t tend to be where you’d like to spend your time. The importance of having a good inventory, however, can hardly be overstated. Malcom Booden joins Tom Ammon and Russ White to talk about the importance of inventories and inventory ideas.
OT’N: BGP Loop Free Paths
Hedge 129: Open Source Mentoring
Mentoring is a topic we return to time and again—because it’s one of the most important things we can talk about in terms of building your people skills, your knowledge, and your career. On this episode of the Hedge, Guedis Cardenas joins Tom Ammon and Russ White to talk about open source mentoring. We discuss how this is different than “regular” mentoring, and how it’s the same. Join us as we talk about one of the most important career and personal growth things you can do.
BGP Policy (Part 7)
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—the last post in this series—I’m going to cover do not transit options from the perspective of AS65001 in the following network—
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.
Do Not Advertise Communities (Provider Specific)
Many providers supply communities a customer can use to block the advertisement of their routes to a particular AS. For instance, if AS65002 were NTT, according to the NTT customer communities site, if AS65001 advertises 100::/64 with the community 65500:65005, NTT would advertise 100::/64 to all its other peers, but not to AS65005.
Note: NTT is not AS65002; this is only used as an illustration of using a community to block advertisement to a peer’s peer.
The operator at AS65001 might reasonably expect that blocking AS65002 from advertising 100::/64 to AS65005 will block all traffic traveling through AS65005—but the vagaries of the global Internet routing table may well cause traffic to be forwarded through AS65005 anyway in some instances.
If AS65006 has a default route pointing to AS65005, traffic destined to 100::/64 may still be forwarded to AS65005. If AS65005 happens to have a covering aggregate route, or learned of the route via AS65004, it might still carry traffic destined for 100::/64.
It is almost impossible to block all traffic to a given reachable destination from being forwarded through a given autonomous system.
AS Path Injection
An alternate, widely used mechanism is to intentionally inject an AS Path loop when advertising a route to prevent some AS from accepting the route. For instance, AS65001 might advertise 100::/64 with the AS Path [65005,65001] to AS65002. AS65005 would then reject this advertisement because the local AS is already in the AS Path.
While this might appear to “break the rules” of BGP, the reality is the AS Path was never really intended to be a “true record” of the path of an “update” (in fact, there is no such thing as an “update” that travels from one router to the next—the “update” is constructed at each hop based on local tables). This technique is problematic in providing “path security” in BGP, but it does not intrinsically break any BGP rules.
Note: For more information about this technique, refer to this episode of the Hedge.
Again, note it is almost impossible to block all traffic to a given reachable destination from being forwarded through a given autonomous system.
Do Not Advertise Communities (Well Known)
Three further well-known communities, although they are not widely used, are worth considering.
When a route is marked with NO-PEER, the AS should only advertise the route to its customers and never its peers. For instance, if AS65001 advertises 100::/64 to AS65003 with NO-PEER, AS65003 will advertise the destination to AS6507 and AS65008 (assuming these are customers), and not to AS65002 or AS65004 (because both of these autonomous systems transit traffic to and from AS65003).
When a route is marked with NO-EXPORT, the AS should not advertise the reachable destination to any other AS. For instance, if AS65001 advertises 100::/64 to AS65003 with NO-EXPORT, AS65003 will not advertise this reachable destination to any other AS, including AS65007, AS65008, AS65002, or AS65004.
When a route is marked with NO-ADVERTISE, the receiving BGP speaker should not advertise the route to any other BGP speaker, including internal and external connections.
Hedge 128: Network Engineering at College
Have you ever thought about getting a college degree in computer networking? What are the tradeoffs between this and getting a certification? What is the state of network engineering at colleges—what do current students in network engineering programs think about their programs, and what they wish was there that isn’t? Rick Graziani joins Tom Ammon and Russ White in a broad ranging discussion on network engineering and college. Rick teaches network engineering full time in the Valley.