BGP dual ISP memory req

[arnis]

I have an Sup720, with 512meg RAM

I am wondering if that is enough memory to take full internet routing tables from two diffrent service providers, and also a iBGP session with another router that also has full routing tables.

as I understand that it would need memory for 3 full routing tables, is that the case ?

Cheers

Arni

[jackyoung]

According to my understanding. You will have only one BGP table and one routing table. The difference is some routes will be learned from ISP A and remaining from ISP B, i.e. ISP A as next-hop or ISP B as next-hop.

Therefore, I believe the 512MB is good enough to carry the full Internet routing table.

However, in this case, you have to own an BGP AS youeself to peer w/ ISP A & B.

Hope this helps.

[network.king]

Hi

I agree with Jack , also make sure you donot add this " soft-reconfiguration inbound " command in your bgp config , which would consume memory ( thrice ) for all your routes received from three peers.

Hope this helps

regards

vanesh k

[adrian.chadd]

There's seperate forwarding and routing tables, yes. You can learn the same routes from multiple entries which'll show up as multiple possibilities in the routing/BGP tables but only one will be selected for installation into the forwarding table.

As for internal representation, you might find that there's some overlap to conserve memory usage but BGP memory usage does scale upward as you add more full BGP feeds. The BGP table/routing tables do grow.

Yah, 512mb should be just enough but 1gb will definitely do it - and, as I mentioned in another post, the 6500's have platform limitations for forwarding.

[adrian.chadd]

Hi Arnis,

512meg RAM should be enough for three full views of ~200k routes each. Keep in mind that the 6500 platform uses hardware assistance for forwarding and thus you have to take into account platform limitations as well as RAM.

The Supervisor 720 comes in a number of flavours each with differing amounts of TCAM resources, divvied up differently. You'll want to make sure there's enough Unicast L3 route TCAM entries in the supervisor you're using.

Please take a look at the Sup720 datasheet:

http://www.cisco.com/en/US/products/hw/switches/ps708/products_data_sheet09186a0080159856.html

Highlights: straight Sup720 has 256k L3 IPv4 unicast routes which is just enough for now but may not be enough for your environment (since the number of forwarding table entries is going to include BGP-learnt routes -and- your IGP-learnt routes); Sup7203BXL may be a better fit moving forward.

[arnis]

Hi all

thank you for your responses

can you explain what are the pro?s and con?s of using

soft-reconfiguration inbound

as someone stated that it should not be used, as then the memory requierments would be to big.

[sourabhagarwal]

If all of the BGP routers in the connection do not support the route refresh capability, we can use the soft reset method that generates a new set of inbound routing table updates from information previously stored. To initiate storage of inbound routing table updates, you must first preconfigure the router using the neighbor soft-reconfiguration command. The clear ip bgp command initiates the soft reset, which generates a new set of inbound routing table updates using the stored information.

Once BGP session get reset, it initiates storage of inbound routing table updates from the specified neighbor or peer group. From that point forward, a copy of the BGP routing table for the specified neighbor or peer group is maintained on the router, due to which it consumes more memory.

Due to this, earlier post suggested not to add "soft-reconfiguration inbound" command in BGP config.

hope this answer your query .. rate if it does ...

[ruwhite · Accepted solution]

To provide more information on the first post to this part....

If you reconfigure your inbound filters for any reason, there's no way to know what you should now accept that you'd already thrown away under your old filters. In the "old days," we would reset the BGP session when you changed your route filters, so we could relearn everything, and apply the new filters properly.

BTW, this is the reason EIGRP resets its neighbors when you change the link metric, filters, or summaries, as well--though with newer code, we have a refresh capability, like BGP, so we don't reset the neighbors any longer for these things.

Anyway, before BGP had a route refresh capability, we implemented soft reconfiguration. This stores everything we've received from a peer, even if it would normally be filtered out by a local inbound filter. If you change the inbound filter, we just dump the marks off the routes that say whether they've passed inbound filtering or not, and rescan the table to figure out what we should and shouldn't work with, based on the new filters.

If you have no inbound filters, I don't think soft-reconfiguration makes any difference in memory used. But, OTOH, if you don't have any filters, and don't intend to change them, why would you configure it? :-)

At some point after soft reconfiguration was implemented, IDR decided to add the route refresh capability to BGP. This essentially allows one BGP speaker to resend it's entire table. Now, when you do a filter change, you just dump everything learned from a given peer, and do a route refresh. This saves you from holding all the routes your peer has sent, which saves a bit of memory--a lot if you have a lot of route filters.

Almost all BGP implementations support route refresh at this point, so soft reconfiguration has been much been discarded. We should actually think about taking it out of the code, at some point int he near future, but things generally take a long time to work out of the code--longer than they take to work into the code.

HTH.

:-)

Russ