BGP Route Withdrawal & Updates (IV)

Now that we know how to advertise prefixes, let's look at what happens when a route is removed or when something about a route changes. BGP manages both of these situations through UPDATE messages. When a prefix is no longer reachable, the router sends an UPDATE with the prefix listed in the Withdrawn Routes field. When a route's attributes change, the router sends a new UPDATE with the updated information, and the receiving peer replaces the old entry with the new one.

Withdrawing Prefixes

Let's start with how BGP manages route withdrawals. We have three routers in a chain, r1 in AS 64512, r2 in AS 64513, and r3 in AS 64514. Each router forms an eBGP session with its directly connected neighbor over the 172.16.1.0/30 and 172.16.1.4/30 links.

Our focus is on the 100.100.100.0/24 that r1 advertises into BGP. At this point, r3 has the prefix in its BGP table.

r3#show ip bgp
BGP table version is 22, local router ID is 10.0.0.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
              t secondary path, L long-lived-stale,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>   100.100.100.0/24 172.16.1.5                             0 64513 64512 i

Now, if we shut down the interface on r1 that connects to the 100.100.100.0/24 network, the prefix is no longer valid in r1's routing table. So, r1 removes the prefix from its BGP table and sends a BGP UPDATE message to r2 with 100.100.100.0/24 listed in the Withdrawn Routes field. When r2 receives this withdrawal, it removes the prefix from its own BGP table and sends another withdrawal to r3. I then waited a while, and then brought it back up. On r3, the debug output shows exactly what happens.

r3#terminal monitor
r3#debug ip bgp updates

BGP(0): 172.16.1.5 rcv UPDATE about 100.100.100.0/24 -- withdrawn
BGP(0): no valid path for 100.100.100.0/24
BGP: topo global:IPv4 Unicast:base Remove_fwdroute for 100.100.100.0/24
BGP(0): 172.16.1.5 rcvd UPDATE w/ attr: nexthop 172.16.1.5, origin i,
merged path 64513 64512, AS_PATH 
BGP(0): 172.16.1.5 rcvd 100.100.100.0/24
BGP(0): Revise route installing 1 of 1 routes for
100.100.100.0/24 -> 172.16.1.5(global) to main IP table

First, r3 receives an UPDATE from r2 with 100.100.100.0/24 listed as withdrawn. It removes the route. About sometime, r3 receives another UPDATE (after I un-shut the interface), this time advertising 100.100.100.0/24 again and the route is installed back into the routing table.

We can also see the message on the packet capture. The withdrawal UPDATE at frame 6 lists 100.100.100.0/24 under Withdrawn Routes.

Then at frame 21, the re-advertisement comes through with the prefix back in the NLRI field along with its path attributes, confirming the route has been restored.

BGP Advertisement Interval

Something worth mentioning here is the BGP advertisement interval, which manages how quickly a router sends UPDATE messages to its peers. By default, iBGP peers send updates immediately with an interval of 0 seconds. For eBGP peers, the default interval is 30 seconds.

This does not mean BGP sends periodic updates of all its routes every 30 seconds. BGP is not like an IGP in that regard. Updates are only triggered when something changes, such as a new prefix being learned, a route being withdrawn, or an attribute being modified. The advertisement interval managing the spacing between those triggered updates.

In my testing, with the default 30-second interval for eBGP, when I shut the interface, the withdrawal goes out right away. If I then bring the interface back up immediately, the re-advertisement does not go out straight away. It waits until 30 seconds have passed since the last update was sent. So if the withdrawal went out at second 0, the re-advertisement goes out at around second 30. If I then wait 10 seconds and shut the interface again, the next withdrawal still waits until 30 seconds from the previous update before it is sent.

If you want updates to be sent immediately without any delay, you can configure neighbor x.x.x.x advertisement-interval 0 on the eBGP peer. With this in place, the updates go out as soon as the change happens. To see this more clearly, I set the advertisement interval to 60 seconds and repeated the test.

BGP(0): 172.16.1.5 rcv UPDATE about 100.100.100.0/24 -- withdrawn
BGP(0): no valid path for 100.100.100.0/24
BGP: topo global:IPv4 Unicast:base Remove_fwdroute for 100.100.100.0/24
BGP(0): 172.16.1.5 rcvd UPDATE w/ attr: nexthop 172.16.1.5, origin i,
merged path 64513 64512, AS_PATH 
BGP(0): 172.16.1.5 rcvd 100.100.100.0/24
BGP(0): Revise route installing 1 of 1 routes for
100.100.100.0/24 -> 172.16.1.5(global) to main IP table
BGP(0): 172.16.1.5 rcv UPDATE about 100.100.100.0/24 -- withdrawn
BGP(0): no valid path for 100.100.100.0/24
BGP: topo global:IPv4 Unicast:base Remove_fwdroute for 100.100.100.0/24

Looking at the debug output on r3, the withdrawal comes in at 16:00:40 when I shut the interface on r1. I then brought the interface back up right away, but the re-advertisement does not arrive until 16:01:41, almost exactly 60 seconds later. I then shut the interface again shortly after, but the next withdrawal does not reach r3 until 16:02:41, again 60 seconds from the previous update. You can see the pattern here. Regardless of when the actual change happens on r1, the updates are spaced exactly 60 seconds apart because of the advertisement interval.