BGP Policy Config with IOS and IOS-XR
In vanilla IOS, when modifying the BGP policies applied to a peering, it is required to manually clear the BGP process to allow any policy changes that affects the sending or receiving of routing updates to be applied immediately to the neighborship. This is because the policies are processed against the BGP table upon establishment of the neighborship and advertisement of NLRI.
This is opposite of how an IGP processes policies. When modifying policies applied to an IGP instance, the changes are propagated immediately as the filtering is done as the prefixes are installed into the routing table, not whether or not the prefixes are advertised. In the case of OSPF, prefix filtering doesn’t get applied to the LSA propagation, but instead to the installment of the prefix into the routing table.
There are three ways in which the policy changes can be propagated to a BGP neighbor :
Hard reset – This is performed when issuing the clear ip bgp command. This will completely tear down and re-establish the BGP connection between two neighbors.
Soft Reset – This option references a BGP table that is stored in memory to reconfigure and activate the BGP routing table without having to tear down the session.
Dynamic inbound soft reset – Also known as the REFRESH capability, allows for the reset of the local inbound routing table by providing route refresh requests to supporting peers. If both peers support route refresh, but it has not been defined upon the initial peering – the session will have to be torn down after modifying the configuration to support route refresh, as the capability is exchanged during the initial peering negotiation.
Within IOS-XR when editing an already existing RPL that’s been defined within the router, and committing the change, it will automatically issue a BGP REFRESH as long as the neighbor supports the capability. It is also a full table refresh as the changes you’ve made within the RPL may require prefixes to be imported, that weren’t previously flagged for import on the last table refresh. There is no need to issue a soft reset as with IOS. The RPL process will handle this after the committing of the change.
If the neighbor does not support the REFRESH capability, or it hasn’t been configured for the peering, a standard clear bgp will have to be used, restarting the BGP session which will provide a new table version for the policy to be applied against.
If you don’t want the automatic refresh capability when modifying an RPL within IOS-XR, you can disable the ability by issuing the bgp auto-policy-soft-reset disable command in either router or VRF configuration.