Following on my posts on Interdomain BGP policies looking at where traffic should enter and exit a network, in this post — the last post in this series — I’m going to cover the do not transit options from the perspective of AS65001 in the following network:
There are cases where an operator does not want 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 Autonomous System (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 travelling 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 AS.
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.
For more information about this technique, refer to this episode of the Hedge.
Note that it is almost impossible to block all traffic to a given reachable destination from being forwarded through a given AS.
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 ASes 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.
I hope this series has been informative and helpful. Please let me know if you have any questions or comments.
Russ White is a Network Architect at LinkedIn.
This post is adapted from a series at Rule 11.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.