Hi, Collin:

The link you gave me covers an enhancement to the soft reconfiguration featre - its called Soft Reset. By reading it, one can probably deducehow the older feature worked, but I want secific information regarding the older technique.

Thanks

Victor

Victor

Have a read of this excerpt from Routing TCP/IP (Jeff Doyle) -

http://books.google.co.uk/books?id=GdWAapirZ9gC&pg=PA210&lpg=PA210&dq=bgp+soft-reconfiguration+inbound&source=bl&ots=66NZiTsG29&sig=YsMG91fNgWN1dT3-V5XgJANu6to&hl=en&ei=H_-CSpnXMdW2jAe2-diACg&sa=X&oi=book_result&ct=result&resnum=9#v=onepage&q=bgp%20s...

Basically what you say is correct. Prior to the dynamic reset you had to explicitly configure soft reset inbound and this meant the router then had to start storing routing updates without modification.

As for memory used. I'm assuming that it is the same amount of memory used to store the current BGP routing table or at least to store the current BGP routes received from a specific peer(s).

Jon

Jon:

Thanks, boss.

Check it out, though...I havent been able to get anything detailed about this particular point:

With the peer cleared to implement a new policy, and soft reconfig enabled, will the peer resend its BGP table again anyway??? I always thought that it did not and that that was the whole purpose of configuring it in the first place; to prevent the peer from having to resend BGP info and prolonging reconvergence.

However, what a Cisco engineer is telling me is that soft reconfig is also a sort of poor man's BGP NSF/Graceful Restart -- so the peer WILL INDEED resed its entire BGP table; however, the forwarding plane will be preserved while the static BGP table is having the new policy applied to it. So, the policies will be applied to the stored/local BGP table, AND a new table will also be sent by the peer.

I dont know if thats right...that sounds fishy.

Edison, got a take on this?

Hello Victor,

This is my understanding of the Soft Reconfiguration:

The BGP protocol is event-driven, i.e. it sends updates only if a change in the BGP database occurs. This poses a problem if you installed a new inbound policy for a particular neighbor - filtering out some networks, applying various attributes and so on. In order for this policy to become effective, you need to ask the neighbor to resend its BGP database to you so that the new inbound policy can be successfully applied to all networks from scratch.

Originally, there were only four types of BGP messages: Open, Update, Keepalive and Notification. There was no specific message to ask your neighbor to resend its BGP database to you. Applying a new inbound policy under this circumstance would require dropping the BGP connection completely and having it reestablished anew. This is clearly an unpleasant thing to do. Therefore, a different approach was chosen: your router maintained a separate unfiltered and unmodified copy of the entire BGP database that your neighbor sent to you. Whenever you needed to reapply an inbound policy, your router took that unfiltered database and "distilled" it through the new inbound policy into its main BGP database. This functionality was called the Soft Reconfiguration (or Soft Reset). Basically, it is a workaround about an ancient insufficiency of the BGP protocol. The drawbacks are clear here: as your BGP process has to maintain a separate unfiltered table for each Soft Reconfiguration-enabled neighbor, the memory requirements increase dramatically. It might be perceived as an advantage that the Soft Reconfiguration does not necessitate any changes to the BGP protocol and that it may reduce the amount of information sent between two BGP peers but these facts might not justify the hugely increased memory footprint.

Fortunately, this defficiency was corrected in RFC 2918 where a fifth BGP message was defined - the so-called Route Refresh. This message can be used to ask your neighbor to resend all its routes of a particular address family to you. Sometimes, this functionality is called the Dynamic Inbound Soft Reset but personally I prefer calling it simply Route Refresh because it is more clear. The Route Refresh capability does not require you to store any separate BGP database for your neighbor. After you change your inbound policy for a neighbor, you can use the Route Refresh message to ask the neighbor to resend its BGP database back to you so you can apply the new inbound policy. The only disadvantage of this approach might be that the amount of BGP traffic to resend the entire BGP database of your peer back to you might be quite large. This can be further rectified by using so-called Outbound Route Filtering but let's not confuse things here too much.

I don't know if this answers your questions but please ask further.

Best regards,

Peter

Peter, that was freaking AWESOME, dude!

NICE!

I have been scouring Cisco's website for some comprehensive information on this to no avail. C'mon Cisco! Get those docs out of the Engineering archives and share the wealth! :-)

Peter, one last question....actually, I spelled out the question in my post to Jon. Its the one about the peer resending its entire BGP table even wth soft reconfig configured. Scroll up, if you will.

Thanks again!

Victor

Victor,

You are heartily welcome.

About that question of yours: I strongly doubt that a router resends its entire BGP database even with Soft Reconfiguration. I have just tested it on a small two-router network. If the Soft Reconfiguration was activated for a neighbor then the command clear ip bgp * in obviously used only the local unfiltered database. No BGP messages were sent between the routers as a result of that command.

I think that it is logical. If I have a Soft Reconfiguration for a particular neighbor, why would I ask it to resend its BGP database to me if I so or so have an unmodified copy of it? And moreover, the Soft Reconfig is by its very definition a workaround about a missing Route Refresh capability. It is therefore completely independent from the Route Refresh. But if the neighbor does not support the Route Refresh then there is absolutely no way to ask him to actually resend his BGP table to us so I do not see a way how a pure Soft Reconfiguration could actually ask a neighbor to resend its BGP table.

Best regards,

Peter

Peter:

I agree. It seemed "fishy" that the BGP table would be resent by the peer even if soft recon was enabled. If the peer were to resend its BGP table while the local router appies the new policies to the static table in memory - and meanwhile the forwarding plane is preserved --, why then would we need BGP NSF/NSR, Graceful Restart (GR) etc?

So, I have a client who is wondering whether they should configure soft recon on their Internet-facing routers.

They have one eBGP peer with an ISP, they accept the full routing table, and they have NO inbound or outbound policies.

Moreover, they have Graceful Restart configured and the ISP does recognize it so it is active.

Does it make sense to have soft recon configured in this case?

post removed

Was going to ask a question related to this, but Ill just start a new thread.

Hi, Peter...it all makes sense..

Thank you so much for all your help....

Victor