Clear ip bgp x.x.x.x soft in VS clear ip bgp x.x.x.x in

[Jonn cos]

Hi all experts.

Can someone help me understand the difference in these two commands ?

clear ip bgp x.x.x.x soft in

and

clear ip bgp x.x.x.x in

Are both these commands same or have some difference between them. I am using 12.4 IOS.

Thanks in advance

[Jon Marshall · Accepted solution]

Jonn.cos88 wrote:
Hi all experts.
Can someone help me understand the difference in these two commands ?
clear ip bgp x.x.x.x soft in 
and
clear ip bgp x.x.x.x in
Are both these commands same or have some difference between them. I am using 12.4 IOS.
Thanks in advance

Jon

It depends -

Without route refresh Capability

==========================

"clear ip bgp x.x.x.x in"  will actually tear the BGP session down which is obviously disruptive to traffic, and then rebuild the EBGP connection to the remote peer

"clear ip bgp x.x.x.x in soft" will not tear the connection down. Rather it instructs the router to use the stored update information in memory to make the updates. The drawback is that router has to keep a separate umodified copy of the updates in memory which with a lot of routes can be very heavy on the router memory.

RFC 2918 introduced something called the route refresh capability which allowed an EBGP router to dynamically send route refresh requests to it's peers to update it's local database. Note this meant the router did not have to store a separate copy in memory as it did with the "soft" option.

So if route refresh is supported there is no real use for the "soft" keyword as it is now redundant. The effect of "clear ip bgp x.x.x.x in" and "clear ip bgp x.x.x.x in soft" are the same therefore but they are achieved very differently.

Jon

[Peter Paluch]

Jon,

Can I discuss some of these things with you please? You obviously have more experience here than I have.

I agree about your description if the RFC 2918 Route Refresh is supported - there is no difference between the in and the soft in variants. I also made an experiment with a neighbor explicitly configured for the soft reconfiguration - there is again no difference in the behavior of these two commands. In any of these cases, no hard reset of the BGP peering will take place.

What I did not know is that if the neighbor does not support the RFC 2918 Route Refresh and at the same it is not configured for soft reconfiguration, the in form would reset the BGP adjacency (what would do the soft in form in such case?) I cannot test this because it seems that I cannot deactivate the RFC 2918 capability in the IOS and so I don't have such an old BGP implementation at hand to test this issue. Do you have any personal experiences with this?

One small nitpicking: the inbound update, be it via soft reconfig or via route refresh per RFC 2918 applies to all BGP neighbors, not just to EBGP.

Best regards,

Peter

[Jon Marshall]

paluchpeter wrote:
Jon,
Can I discuss some of these things with you please? You obviously have more experience here than I have.
I agree about your description if the RFC 2918 Route Refresh is supported - there is no difference between the in and the soft in variants. I also made an experiment with a neighbor explicitly configured for the soft reconfiguration - there is again no difference in the behavior of these two commands. In any of these cases, no hard reset of the BGP peering will take place.
What I did not know is that if the neighbor does not support the RFC 2918 Route Refresh and at the same it is not configured for soft reconfiguration, the in form would reset the BGP adjacency (what would do the soft in form in such case?) I cannot test this because it seems that I cannot deactivate the RFC 2918 capability in the IOS and so I don't have such an old BGP implementation at hand to test this issue. Do you have any personal experiences with this?
One small nitpicking: the inbound update, be it via soft reconfig or via route refresh per RFC 2918 applies to all BGP neighbors, not just to EBGP.
Best regards,
Peter

Peter

From memory, as it has been a while since i used an IOS not supporting route refresh. So assuming an IOS not supporting route refresh capability

for "clear ip bgp soft in" it depends -

to be able to use "soft in" the router needs an unmodfied copy of the updates in memory. You instruct the router to keep this copy by configuring -

"neighbor soft-reconfiguration inbound"

so if you have done that then "clear ip bgp x.x.x.x soft in" will do as you would expect it to ie. apply the changes without tearing down the session. But if you haven't configured "soft-reconfiguration inbound" then the router returns an error message telling you it is not configured and therefore cannot apply a "soft in". It does not automatically apply a "clear ip bgp x.x.x.x", rather it leaves it up to you to decide what to do.

Note that "clear ip bgp x.x.x.x soft out" will still work as expected ie. you don't need to configure anything else for this to work.

And  thanks for pointing out it applies to all BGP neigbors not just EBGP.

Jon

[Jon Marshall]

Peter

You obviously have more experience here than I have.

Hmmm, i think not actually

What I did not know is that if the neighbor does not support the RFC 2918 Route Refresh and at the same it is not configured for soft reconfiguration, the in form would reset the BGP adjacency

It doesn't, i was talking rubbish which i seem to making a habit of recently ! As i'm sure you know the way to reset a BGP session is "clear ip bgp x.x.x.x".

Only when you asked me about specific behaviour did my memory kick in properly. So thanks for clearing that up and Jon i apologise for confusing the issue. Peter's answer is the more accurate.

The response to your post about "soft in" prior to Route Refresh" is still correct as far as i can remember although i think we have established, my memory is not what it used to be

Jon