It’s been a while since we talked about filtering BGP updates. BGP routers need to be configured with the right filters so packets don’t flow in directions they’re not supposed to flow.
However, applying a filter to a BGP session that’s already established isn’t very effective; it’s a bit like closing the barn door after the animals have already left the barn. Resetting/clearing your BGP sessions is like herding all the animals back inside and then see which ones are allowed out by the filter and which ones aren’t.
The most straightforward way to reset a BGP session is with the clear ip bgp command. clear ip bgp is the original version of the command. There’s also clear bgp ipv6 unicast for IPv6 BGP sessions and the corresponding clear bgp ipv4 unicast for IPv4 BGP sessions. Similarly, show ip bgp is the old version, show bgp ipv6 unicast and show bgp ipv4 unicast are the new versions of the same command for IPv6 and IPv4, respectively.
Note that according to the Cisco documentation, you should be able to use the clear ip bgp command with an IPv6 address as well as an IPv4 address, and using clear bgp ipv4 unicast <address> will apply to BGP sessions activated for the IPv4 unicast address family even if <address> is an IPv6 address. (And vice versa with the ipv6 unicast keywords and the IPv6 unicast address family.) However, depending on the exact platform and software version you’re using, applying these commands for IPv4 prefixes over IPv6 BGP sessions or IPv6 prefixes over IPv4 BGP sessions may or may not give you the desired results.
All the clear commands take an IP address, an AS number or an asterisk as their first argument. Unsurprisingly, clear bgp ipv4 unicast 192.0.2.2 clears (resets) the BGP session towards neighbor 192.0.2.2. clear bgp ipv6 unicast 65001 clears all (IPv6) BGP sessions from this router towards routers in AS 65001. And clear ip bgp * clears all BGP sessions.
When used without using additional arguments, the clear command tears down the indicated BGP session or sessions and then removes all prefixes learned from the neighbor(s) in question from the BGP table and the routing table. The router then initiates a new BGP session. When that session is established, all prefixes are transferred and the new filter is applied.
A side effect of clearing BGP sessions in this manner is that connectivity to and from the neighboring network is lost for some time; typically between 10 and 30 seconds, but longer is also possible. Remote networks now have to reroute packets for your network over another path—assuming one is available.
Clearing BGP sessions in this manner is not recommended: your network may become unreachable for a few seconds and perhaps longer if an upstream network uses flap damping. Flap damping is a mechanism developed in the late 1990s to isolate routers from “flapping”: instability in BGP caused by prefixes appearing and disappearing at relatively short intervals. Each flap incurs a penalty, and after accruing a certain penalty level, prefixes are ignored for a period between about 30 and 60 minutes. Usually, flap damping doesn’t kick in until you’ve flapped four times, but it’s possible for one flap to be multiplied along the way as updates propagate. Flap damping is currently not very widely used, but it’s still best to avoid too many BGP resets and especially the “hard” resets described above.
Fortunately, there’s a better way. When you’ve changed an outgoing filter or route map, you can use the clear ip bgp … out command. This doesn’t tear down the BGP session. Instead, this version of the clear command tells the router to push all the prefixes in the BGP table out to the neighbor or neighbors, applying the currently configured filters in the process. So prefixes that were previously filtered but are now allowed are propagated to the neighbor, and prefixes that were allowed before but are filtered now are withdrawn.
The result is exactly the same as with a “hard” reset of the BGP session, but without any disruption. The neighbor simply sees a sequence of updates. The clear … out command doesn’t require any cooperation from the BGP neighbor, so it always works, regardless of the capabilities of the neighbor.
It’s also possible to push prefixes through the incoming filters and route maps using the clear ip bgp … in command. The effect is the same as with the clear … out command, except in the other direction, of course. However, the implementation is different: in order for the router to apply its current inbound filters and route maps, it has to receive new copies of all the neighbor’s prefixes. It does this by asking the neighbor to send over its prefixes. This “route refresh” capability (RFC 2918) is an extension to the BGP protocol. Modern routers support route refresh, but you may encounter an old or exotic router that doesn’t. You can determine this with the show ip bgp neighbors <address> command. The output may include the following:
Route refresh: advertised and received(old & new)
In this case, the local router advertises the route refresh capability and it also received an advertisement of the route refresh capability from the neighbor. “Old” refers to the old pre-RFC 2918 Cisco implementation of route refresh. “New” means the RFC 2918 compliant implementation of the capability.
Should your neighbor not support route refresh, all is not lost. You can achieve much the same result by configuring soft-reconfiguration inbound:
router bgp 65000
neighbor 192.0.2.2 remote-as 65001
neighbor 192.0.2.2 soft-reconfiguration inbound
With this setting in place, the router will store a copy of all prefixes received from neighbor 192.0.2.2—including the ones that are filtered out. You can now use the clear ip bgp … in or clear ip bgp … soft in command to apply updated filters and route maps without a hard reset. Be warned that Cisco notes that “this method is memory-intensive and not recommended unless absolutely necessary.”
Inspecting the BGP table
However, soft-reconfiguration inbound does have an added benefit: you can inspect the full set of prefixes advertised by a neighbor, including the prefixes that aren’t added to the regular BGP table because they’re blocked by a filter or route map. This is done with the show ip bgp neighbors … received-routes command. This lists all the prefixes learned from the neighbor in question in the same format as the show ip bgp output. This includes prefixes that are filtered out which aren’t added to the BGP table. The show ip bgp … routes command, on the other hand, only shows the prefixes learned from the neighbor that are actually added to the BGP table. Another difference is that show … received-routes shows the prefixes with their original attribute values, while show … routes shows them after a route map may have altered certain attributes. For instance, let’s apply this route map to the session, which changes most of the attributes attached to a BGP prefix:
route-map makechanges permit 10
set as-path prepend 4200000000
set metric 12345
set local-preference 10000
set ip next-hop 192.0.2.222
set weight 999
This makes the prefix show up as follows in the BGP table:
*> 188.8.131.52 192.0.2.222 12345 10000 999 4200000000 2 i
The show … received-routes command, on the other hand, shows the prefix in its original form:
Router# show ip bgp neighbors 192.0.2.2 received-routes
Network Next Hop Metric LocPrf Weight Path
*> 184.108.40.206 192.0.2.2 0 1000 0 2 i
More detailed information on prefixes that pass the filters and are added to the BGP table is shown using the show ip bgp <prefix> command:
BGP routing table entry for 220.127.116.11/8
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Not advertised to any peer
192.0.2.222 from 192.0.2.2 (18.104.22.168)
Origin IGP, metric 12345, localpref 10000, weight 999, valid, external
203.0.113.5 from 203.0.113.5 (22.214.171.124)
Origin IGP, localpref 10000, valid, external, best
Community: 65000:2 65000:3
There are two paths/routes available towards 126.96.36.199/8. The first route is the one mangled by the route map above, as we can see from the presence of AS 4,200,000,000 in the AS path. On the next line, the first address is the next hop address. This is usually the same as the second address, which is the neighbor address. However, in this case the route map changed the next hop address, but the neighbor address isn’t affected. The third address is the router ID of the neighbor, which we can use to determine whether two BGP sessions connect to the same neighboring router or to different routers.
The second path towards 188.8.131.52/8 is considered best by BGP; it also has the very high local preference value of 10,000, but the AS path is only one hop rather than two. This path also has two community values attached.
The router indicates that the prefix is not announced to peers (neighbors). If it is, you’ll usually see their IP addresses here. So the show ip bgp <prefix> command is useful to see whether a specific prefix is announced to neighbors. Alternatively, you can use the show ip bgp neighbors … advertised-routes command to list all the prefixes announced to a specific neighbor.
As the saying goes, “speak softly, but carry a big stick”. The big stick in this scenario is a prefix filter that only allows the right prefixes in or out, but we clear the BGP sessions softly.
Boost BGP Preformance
Automate BGP Routing optimization with Noction IRP