So the first scaling technique we're going to look at is route refresh. In the early days of BGP, in the early 90s, a BGP peer reset was required after every policy change. If you remember BGP only sends incremental updates. If something changes, it sends the change. If the change has already gone you can't really go and pull it back. If the change has arrived and you rejected it, well you can't really un-reject it. So we needed a mechanism whereby if policy would change, whether it was incoming or outgoing policy, you could actually refresh the BGP feed coming in to or going out from your router, and this is the route refresh. A hard BGP reset would of course tear down the BGP peering, would consume CPU on the local router, but worse it would severely disrupt connectivity for all networks. Tearing down the BGP session stops your prefixes from being announced to the world, and basically disconnects you from the whole internet, until the BGP session is reestablished potentially many minutes later. And that would cause significant connectivity disruption both for the end users of the local network, as well for the users of the wider internet accessing the local network. So soft BGP reset was introduced. It started off initially with Cisco during a soft-reconfiguration concept and we'll look at that a little bit later. But the standard version is known as route refresh, where the BGP peering remains active and it only impacts those prefixes which have been affected by the policy change. The "route refresh capability" as it's called, allows us to do a non-disruptive policy change. And what's even better no configuration is needed, the routers will negotiate it when they bring up the BGP session with their peer. It doesn't require any extra memory or any other extra facility on the router itself. RFC2918 documents how the route refresh capability is implemented. And the commands to implement it our very very simple. On Cisco IOS, as you can see in the slide, it's a simple "clear ip bgp <neighbour address> and "in" to refresh the inbound announcement, in other words tell the peer to send a full BGP update again. Or "clear ip bgp <neighbor> out" to resend the full BGP announcement out to the peer. These two commands allow the network operators either refresh the inbound policy, in the first case, or refresh the outbound policy in the second case. Today route refresh is supported on virtually every single BGP implementation out there. And it's considered good for the Internet. In fact doing a hard reset of BGP is considered an absolute last resort with many operators considering it to the equivalent of a router reboot. And router reboots are really only done during maintenance periods and even then are considered only when it's absolutely necessary. Now just before route refresh was introduced as a standard, Cisco produced a small feature called soft-reconfiguration. It's really not used anymore, but what it does was actually store all the prefixes that were received from the neighbor. Normally the router would just keep the prefixes after the policy was applied. Cisco's soft-reconfiguration would keep all the prefixes received, even those that were thrown away by the policy. The side effect is that it uses extra memory to keep the prefixes whose attributes have been changed or the prefixes which have not been accepted. And today the soft-reconfiguration feature is considered only useful when the operator needs to know which prefixes have been received by the local router before the application of any inbound policy. The configuration is quite simple, in Cisco IOS it's just applied on a per neighbor basis with the "soft-reconfiguration" keyword. The commands to implement it are exactly the same as those for the route refresh. Simply by doing "clear ip bgp <neighbor> in or out". "clear ip bgp <neighbor> in" will do the soft-reconfiguration in. "clear ip bgp <neighbor> out" will do the soft reconfiguration outbound. So soft-reconfiguration today is very much considered only useful, and only should be used, when two network operators are trying to troubleshoot a BGP session between their respective networks. It saves arguments about, "you sent these" or "you didn't send these" or "I sent this" and "you didn't get that". It helps with those discussions and will let the two operators effectively troubleshoot problems with prefixes being received and/or sent in a BGP session. Otherwise, if soft-reconfiguration is not required, then it should not be applied to the configuration so that operators have access to the route refresh capability which is part of the BGP specification.

© Produced by Philip Smith and the Network Startup Resource Center, through the University of Oregon.

Attribution-NonCommercial 4.0 International (CC BY-NC 4.0)
This is a human-readable summary of (and not a substitute for) the license. Disclaimer. You are free to: Share — copy and redistribute the material in any medium or format Adapt — remix, transform, and build upon the material The licensor cannot revoke these freedoms as long as you follow the license terms. Under the following terms: Attribution — You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use. NonCommercial — You may not use the material for commercial purposes. No additional restrictions — You may not apply legal terms or technological measures that legally restrict others from doing anything the license permits.