While on the subject of old habits, I had to mention this one. I remember back when studying for CCNA and maybe even CCNP that it was always recommended to configure soft-reconfiguration in order to propagate route policy updates/changes without hard resetting the bgp neighbor. This is one of those things that sometimes just becomes routine, a habit, something that is just pasted into new configs and forgotten about. Well it might be time to shake this one off as well.
In brief terms the soft-reconfiguration command will allow a ’soft’ reset. The tcp session between the two bgp peers will not be reset but new policy changes will take effect. E.g, a new route-map filter is applied. Therefore a way to cause minimal damage to overall stability of the network.
A decade or so ago RFC 2918 Route Refresh for BGP-4 September 2000 was published which made the soft-reconfiguration redundant. Two bgp peers that support the route refresh capability can implement a soft reset without any preconfiguration. In order to determine whether a peer support this capability:
show ip bgp nei 11.11.7.11
BGP neighbor is 11.11.7.11, remote AS 11, external link
BGP version 4, remote router ID 150.140.130.120
BGP state = Established, up for 00:03:27
Last read 00:00:27, hold time is 180, keepalive interval is 60 seconds
Neighbor capabilities:
Route refresh: advertised and received(new)
Extract from: http://www.cisco.com/en/US/docs/ios/12_2/ip/configuration/guide/1cfbgp.html#wp1001128
To use soft reset without preconfiguration, both BGP peers must support the soft route refresh capability, which is advertised in the OPEN message sent when the peers establish a TCP session. Routers running Cisco IOS software releases prior to Release 12.1 do not support the route refresh capability and must clear the BGP session using the neighbor soft-reconfiguration router configuration command. Clearing the BGP session in this way will have a negative impact upon network operations and should only be used as a last resort.
| Type of Reset | Advantages | Disadvantages |
|---|---|---|
| Hard reset | No memory overhead. | The prefixes in the BGP, IP, and Forwarding Information Base (FIB) tables provided by the neighbor are lost. Not recommended. |
| Outbound soft reset | No configuration, no storing of routing table updates. | Does not reset inbound routing table updates. |
| Dynamic inbound soft reset | Does not clear the BGP session and cache.
Does not require storing of routing table updates, and has no memory overhead. |
Both BGP routers must support the route refresh capability (in Cisco IOS Release 12.1 and later releases). |
| Configured inbound soft reset (uses theneighbor soft-reconfiguration router configuration command) | Can be used when both BGP routers do not support the automatic route refresh capability. | Requires preconfiguration.
Stores all received (inbound) routing policy updates without modification; is memory-intensive. Recommended only when absolutely necessary, such as when both BGP routers do not support the automatic route refresh capability. |
Now what does this really mean to you and me? The memory consumption used by soft-reconfiguration since all routes from a neighbor with soft-reconfig configured will be stored in memory. For example a peer might send a full table but the router is filtering all neighbor AS and neighbor client AS’s. Although only a few thousand routes might be inserted into the bgp table from this neighbor, the router still has to keep the remaining 200k+ routes in memory. If the router has a couple on these peers, it will probably not scale well. By relying only on the route refresh feature, the router will be able to scale to far more peers.
In an enterprise environment with less routes, an old 3600 might still be active in the BGP routing domain and become unstable due to running out of memory. Removing the legacy “soft-reconfiguration” configuration might be the healing touch it needs.
Note that this is also used to show the routes received from a peer before any policy is applied. Very useful for troubleshooting.
Comment by Paul — January 30, 2010 @ 2:37 pm
That is true, I left that part out because in a production environment the value in this troubleshooting feature does not justify the cost.
If it is not filtered and not in the table then it is not advertised.
In a lab, where it is a race against the clock and stability is not remotely important, it’s different ball game.
Comment by 21500 — January 30, 2010 @ 4:06 pm