Crafting endless AS-PATHS in BGP

In this post, I’ll look at how combining BGP confederations and AS override can potentially create a BGP routing loop, resulting in an indefinitely expanding AS-PATH.

BGP confederation is a technique used to reduce the number of internal BGP (iBGP) sessions and improve scalability in large Autonomous Systems (ASes). It divides an AS into sub-ASes. Most external (eBGP) rules apply between sub-ASes, except that next-hop, Multi-Exit Discriminator (MED), and local preferences remain unchanged. The AS-PATH length ignores contributions from confederation sub-ASes. BGP confederation is rarely used and BGP route reflection is typically preferred for scaling.

AS override is a feature that allows a router to replace the Autonomous System Number (ASN) of a neighbor in the AS-PATH of outgoing BGP routes with its own. It’s useful when two distinct ASes share the same ASN. However, it interferes with BGP’s loop prevention mechanism and should be used cautiously. A safer alternative is the allowas-in directive (when using BGP confederations with Cisco IOS XR, use allowconfedas-in instead. It’s been available since IOS XR 7.11).

In the Figure 1 example, we have four routers in a single confederation, each in its own sub-AS. R0 originates the 2001:db8::1/128 prefix. R1, R2, and R3 forward this prefix to the next router in the loop.

Figure 1 — BGP routing loop using a confederation.

The router configurations are available in this Git repository. They are running Cisco IOS XR. R2 uses the following configuration for BGP:

router bgp 64502
 bgp confederation peers
  64500
  64501
  64503
 !
 bgp confederation identifier 64496
 bgp router-id 1.0.0.2
 address-family ipv6 unicast
 !
 neighbor 2001:db8::2:0
  remote-as 64501
  description R1
  address-family ipv6 unicast
  !
 !
 neighbor 2001:db8::3:1
  remote-as 64503
  advertisement-interval 0
  description R3
  address-family ipv6 unicast
   next-hop-self
   as-override
  !
 !
!

The session with R3 uses both as-override and next-hop-self directives. The latter is only necessary to make the announced prefix valid, as there is no IGP in this example. Using BGP confederations is already inadvisable. If you don’t use the same IGP for all sub-ASes, you’re inviting trouble! However, the scenario described here is also possible with an IGP.

Here’s the sequence of events leading to an infinite AS-PATH. When an AS-PATH segment comprises ASNs from a confederation, it is displayed between parentheses.

R0 sends the prefix to R1 with AS-PATH (64500).
R1 selects it as the best path, forwarding it to R2 with AS-PATH (64501 64500).
R2 selects it as the best path, forwarding it to R3 with AS-PATH (64500 64501 64502).
R3 selects it as the best path. It would forward it to R1 with AS-PATH (64503 64502 64501 64500), but due to AS override, it substitutes R1’s ASN with its own, forwarding it with the AS-PATH (64503 64502 64503 64500).
R1 accepts the prefix, as its own ASN is not in the AS-PATH. It compares this new prefix with the one from R0. Both (64500) and (64503 64502 64503 64500) have the same length because confederation sub-ASes don’t contribute to AS-PATH length. The first tie-breaker is the router ID. R0’s router ID (1.0.0.4) is higher than R3’s (1.0.0.3). The new prefix becomes the best path and is forwarded to R2 with AS-PATH (64501 64503 64501 64503 64500).
R2 receives the new prefix, replacing the old one. It selects it as the best path and forwards it to R3 with AS-PATH (64502 64501 64502 64501 64502 64500).
R3 receives the new prefix, replacing the old one. It selects it as the best path and forwards it to R0 with AS-PATH (64503 64502 64503 64502 64503 64502 64500).
R1 receives the new prefix, replacing the old one. Again, it competes with the prefix from R0, and again the new prefix wins due to the lower router ID. The prefix is forwarded to R2 with AS-PATH (64501 64503 64501 64503 64501 64503 64501 64500).

A few iterations later, R1 views the looping prefix as follows. By default, IOS XR paces eBGP updates. This is controlled by the advertisement-interval directive. Its default value is 30 seconds for eBGP peers (even in the same confederation). R1 and R2 set this value to 0, while R3 sets it to two seconds. This gives some time to watch the AS-PATH grow.

RP/0/RP0/CPU0:R1#show bgp ipv6 u 2001:db8::1/128 bestpath-compare
BGP routing table entry for 2001:db8::1/128
Last Modified: Jul 28 10:23:05.560 for 00:00:00
Paths: (2 available, best #2)
  Path #1: Received by speaker 0
  Not advertised to any peer
  (64500)
    2001:db8::1:0 from 2001:db8::1:0 (1.0.0.4), if-handle 0x00000000
      Origin IGP, metric 0, localpref 100, valid, confed-external
      Received Path ID 0, Local Path ID 0, version 0
      Higher router ID than best path (path #2)
  Path #2: Received by speaker 0
  Advertised IPv6 Unicast paths to peers (in unique update groups):
    2001:db8::2:1
  (64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64500)
    2001:db8::4:0 from 2001:db8::4:0 (1.0.0.3), if-handle 0x00000000
      Origin IGP, metric 0, localpref 100, valid, confed-external, best, group-best
      Received Path ID 0, Local Path ID 1, version 37
      best of AS 64503, Overall best

There’s no upper bound for an AS-PATH, but BGP messages have size limits (4,096 bytes per RFC  42 71 or 65,535 bytes per RFC  8654). At some point, BGP updates can’t be generated. On Cisco IOS XR, the BGP process crashes well before reaching this limit (this is CSCwk15887. It only happens when using as-override on an AS-PATH with a too-long AS_CONFED_SEQUENCE. This should be fixed around 24.3.1.)

The main lessons from this tale are:

Never use BGP confederations under any circumstances.
Be cautious of features that weaken BGP routing loop detection.

Vincent Bernat is a Network Engineer at AS12322 and a Debian and free software developer.

This post is adapted from the original at Vincent’s blog.

Rate this article

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.

Leave a Reply Cancel reply