Description
This article describes the advantages of soft BGP reconfiguration and compares them with the advantages of a route refresh.
Scope
FortiGate.
Solution
One of the most powerful features of BGP is the power to manipulate prefixes with inbound and outbound policies.
By the original BGP specification, these policies are applied when receiving the prefixes from a peer, which means that the routing database might not show all the prefixes received by the BGP peer (because they have been filtered), or the attributes might have been manipulated. If the BGP policies need to be modified to allow more prefixes, change attributes, etc, the original data received by the peer is not available, as it has been filtered and manipulated locally already.
Previously, the only way to get all of the data from the peer again - so that it could be processed by the new BGP policies - was to perform a BGP hard reset, meaning totally tearing down the BGP peering between both peers. This is inconvenient as it disrupts traffic flow.
A commonly used approach to overcome this issue is to store an unmodified copy of all routes from the peer at all times, this is known as soft-reconfiguration. The drawback is the additional cost in processing power and memory to maintain this additional copy of all routes, per peer.
In September of 2000, RFC 2918 was proposed. This RFC introduced the Route Refresh Capability for BGP, allowing the BGP speaker to send a Route Refresh Message to the peer requesting the resend of all prefixes whenever an inbound policy is applied or modified. This completely removes the necessity of having to store a duplicate copy of the peer’s prefixes, saving CPU and memory resources.
Consider a practical example where FortiGate is peering with a BGP neighbor that is sending the full internet routing table.
Disclaimer:
This is a lab test and the BGP peer is sharing a static copy of the full internet routing table. BGP recalculations are not considered, and the appliance is also not processing any user traffic. Different results may be encountered in a production environment.
config router bgp
config neighbor
edit "192.168.5.105"
set remote-as 65001
set route-map-in "next-hop"
next
end
get router info bgp sum
VRF 0 BGP router identifier 10.0.0.2, local AS number 65002
BGP table version is 1
125138 BGP AS-PATH entries
150 BGP community entries
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
192.168.5.105 4 65001 144741 4 0 0 0 00:00:33 948711
FortiProxMox # diag sys top-mem
bgpd (165): 440786kB
nsm (160): 337089kB
node (173): 52960kB
ipshelper (218): 21883kB
cmdbsvr (148): 21078kB
Top-5 memory used: 873796kB
By default, Route Refresh is enabled, so the command is not seen in the configuration. Enable soft reconfiguration and compare the results:
config router bgp
set as 65002
set router-id 10.0.0.2
config neighbor
edit "192.168.5.105"
set soft-reconfiguration enable
set remote-as 65001
set route-map-in "next-hop"
next
end
end
get router info bgp sum
VRF 0 BGP router identifier 10.0.0.2, local AS number 65002
BGP table version is 1
125138 BGP AS-PATH entries
150 BGP community entries
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
192.168.5.105 4 65001 144741 4 0 0 0 00:00:30 948711
Total number of neighbors 1
FortiProxMox # diag sys top-mem
bgpd (165): 523759kB
nsm (160): 337092kB
node (173): 37361kB
ipshelper (221): 21959kB
cmdbsvr (148): 21125kB
Top-5 memory used: 941296kB
As can be observed, the memory usage is higher with soft reconfiguration enabled. This can have a great impact when peering with multiple BGP neighbors. Route refresh is the preferred method to use and has been an IETF standard since the year 2000.
If 'Route Refresh: advertised and received' shows under Neighbor capabilities, FortiGate and the remote bgp peer are both configured to support Route Refresh.
get router info bgp neighbors 192.168.5.105 | grep capabilities -A 1
Neighbor capabilities:
Route refresh: advertised and received (old and new)
