HARD RESET : It will tear down TCP session as well as BGP session.Establishing new BGP session, will send Route refresh request to neighbor and learn all prefix again also network interuption will occured.
Soft Reconfiguration : Need More Memory due to store RAW Prefix in seperate table. No network interuption and will not send any Route refresh request.
Route Refresh : This is the most suitable method.No network interuption , no extra memory needed.Just send a Route refresh request.
Please correct me if I am wrong with my understanding .Thx
If using the route refresh option inbound, I assume any filters we have Inbound will be processed before routes are installed in the actual routing table? Is there any reason one would use soft reconfiguration over route refresh apart from it either being supported / not supported on the platform?
Lastly, for route refresh to work do we need the peer router to be able to support this or only our own local router?
That’s right. When you receive a refreshed route, filters are applied and then it gets installed in the BGP table, and in the routing table.
Today, there is no reason to use soft reconfiguration instead of route refresh. Soft reconfiguration was a bit of a workaround so you didn’t have to do a hard reset. Nowadays, all routers support route refresh so there’s no reason not to use it. Both peers need to support this.
Do we have a way of checking if the remote peer supports route refresh by any commands? Or would it be a case of having to ask the Provider of the peer link if their device supports route refresh?
There is a quick way to see the capabilities when you have established a neighbor adjacency:
R1#show ip bgp neighbors | begin capa
1 active, is not multisession capable (disabled)
Route refresh: advertised and received(new)
Four-octets ASN Capability: advertised and received
Address family IPv4 Unicast: advertised and received
Enhanced Refresh Capability: advertised and received
Stateful switchover support enabled: NO for session 1
Do we need to always clear ip bgp <> in if we make a change to the inbound policy? I do not see the change takes effect unless I perform that. My routers are having route-refresh capability enabled
If you make changes to the inbound or outbound policy, you will still require the clear ip bgp command. However, notice that by adding the keyword in, the reset is not a hard reset, but it is a soft reconfiguration that is implemented, as the options for the command indicate. So this is indeed a command that uses the route refresh capability.
So yes, you do need the clear ip bgp command but in order to verify that this command gives you the route refresh capability, you need to use the in, out or soft keywords.
Only the clear ip bgp soft command will initiate a BGP reset without tearing down the session. If you use clear ip bgp in or clear ip bgp out, it will still be a hard reset. If you use clear ip bgp it will do a hard reset on both inbound ant outbound sessions.
I understand that I can change the attributes of the prefixes that I receive by doing a soft reset (clear ip bgp * soft / clear ip bgp * in), which requires the Route Refresh Capability, or configuring soft reconfiguration (neighbor 188.8.131.52 soft-reconfiguration inbound).
If I do not make a soft clear and I do not configure soft reconfiguration, my inbound routes will never be updated with the new attributes?
Does BGP send an update message if there are no changes like a new network command?
If you make a change to a routing policy (policy attributes or filters) then in order to make those policies take effect you must apply one of the three solutions stated in the lesson. If you do not, these policies will never be applied.
However, for attribute changes, that is, changes to the way that the router will interpret and handle BGP information received, these won’t take effect unless one of the three methods in the lesson are employed.
It’s my understanding that if a BGP peer supports the route refresh capability, the peer re-advertises the prefixes to the requesting router allowing for the inbound policy to process using the new policy changes.
We have two methods of clearing the BGP session, the hard reset which is disruptive and the soft reset which request a full advertisement from its BGP peer without tearing down the TCP session.
My questions are:
How do we perform/issue a route refresh? via the soft reset method?
Route refresh is a dynamic method, requires no configuration, right?
If route refresh is not supported, which method will the router use?
When troubleshooting, sometimes it’s very helpful to see all the inbound routes, will this require to configure the soft-reconfig inbound command?
The route refresh capability and the soft reconfiguration feature are two different operations and are configured differently. Soft reset, or soft reconfiguration, stores all the information received from BGP neighbours in a separate table before the reset occurs. It works well, but it requires more memory, since an entire table is maintained for each BGP neighbour. More about this can be found at the BGP Soft Reconfiguration Lesson. To perform a route refresh, simply use the clear ip bgp command as you normally would.
Route refresh is enabled by default on all Cisco BGP routers, so it doesn’t need to actually be enabled or configured. More about how it works can be found in the BGP Route Refresh Capability lesson.
As mentioned before, route refresh is enabled by default. If you disable it, then when you apply the clear ip bgp command, a hard reset will take place.
Note here that the soft-reconfig inbound command is not involved in the route refresh feature of BGP, but in the soft reconfiguration feature. This command actually enables the soft reconfiguration feature, essentially telling the router to save the routing information from that particular neighbour in a new table called the adj-RIB-in table so that when a BGP session is cleared, that information will remain. Note that the information in this table is unmodified, meaning that it does not include any changes that may have been made by route maps that may be configured. In other words, this table shows the information as it appears in the neighbour’s BGP table.
Now you can use the show ip bgp neighbors<ip address of neighbor>received-routes command to see that table, but you can also get that information without the received-routes keyword. In such a case, any modifications made would not be shown. This is shown in much more detail in the BGP Soft Reconfiguration lesson.
If route refresh is support and enabled on both router. when we made change on policy inbound but we didn’t manually request route by clear ip bgp in command. Will router auto send route request from neighbor ? and if it will auto send route request how long will it send after we modify the policy ?
Soft-reconfiguration and route refresh are two different things.
Soft-reconfiguration stores an unmodified copy of all received routes from a neighbor in a separate table in memory and just reuse it whenever the inbound policy changes. This is configured on per neighbor basis using the command neighbor x.x.x.x soft-reconfiguration inbound.
A router using route refresh don’t need to store a separate unmodified copy of all routes from a BGP peer, the BGP peer will simply resend all routes of a particular address family.
The route refresh requires no configuration and will be used automatically.
In order to perform a route refresh we simply issue the clear ip bgp x.x.x.x soft in, the hard reset is not recommended because it’s disruptive.
Yes, it seems that you’ve got it! Just one clarification.
It’s not that it shouldn’t be used, but simply it is not the best choice. For small to medium sized networks, it should be fine, but for very large networks, it uses way too many resources on devices, so the better choice would be route refresh.
BGP does not utilize periodic updates, and thus route invalidation is not based on expiring any sort of soft state information (e.g prefix-related timers like in RIP). Instead, BGP uses explicit withdrawal section in the triggered UPDATE message to signal neighbors of the loss of the particular path. In addition to the explicit withdrawals, BGP also support implicit signaling, where newer information for the same prefix from the same peer replaces the previously learned information.
So to answer your question directly, if you modify an inbound policy, it is unknown when the prefixes will be sent again so that the new policy can take effect on the incoming BGP updates. This is the reason why it is advisable to always perform a reset on the BGP peering whenever such changes are made. And this in turn, makes features such as route refresh and soft reconfiguration necessary.
In a scenario without soft-reconfig inbound, the command show ip bgp neighbors x.x.x.x received-routes will always show a prefix’s attributes as changed by the BGP inbound policy, right? So, its output would be similar to show ip bgp?
There is no way to see the prefixes as they were sent by the neighbor.
If you issue the show ip bgp neighbors command using the received-routes keyword and you don’t have soft-reconfig configured, then you will get the following result (I just tested it out…):
R1#show ip bgp neighbors 192.168.12.2 received-routes
% Inbound soft reconfiguration not enabled on 192.168.12.2
So the command can only be used if soft reconfig is configured. However, you can use the following command:
R1#show ip bgp neighbors 192.168.12.2 routes
This command will show you the routes received and accepted from that particular neighbour, and includes any alterations that have been made using inbound policies. When soft reconfig is not configured, there is no way to see the raw BGP information that has been sent from the neighbor since that info is not stored anywhere.