[f-nsp] XMR BGP performance?

[Mike Leber]

In the past with versions prior to 3.6 yes.  Now, with versions 3.6 and 
later things are much much better.

If you are using an image prior to 3.6 upgrade to 3.6 or greater asap 
after testing.

3.7, 3.8, 3.9 are released, 4.0 is beta (BTW, 4.0 has 32 bit ASNs for 
those of you for which that is a drop dead requirement (it is for us) 
(ARIN, RIPE, APNIC, etc start issuing 32 bit ASNs by default January 1st 
2009, are you ready?))).

(warning curmudgeonly advice ahead) you can save CPU with the following:

* Don't use huge route-maps (<= 5 stanzas happy CPU, >= 40 stanzas sad CPU).

* Do use peer groups (in theory these save CPU by requiring most 
calculations once for the peer group, I say theory because sometimes 
vendors don't optimize for peer groups).

* Don't configure every peer with huge amounts of custom config (for an 
example of badness: every peer totally custom, with gigantic route-maps, 
and not a peer group in sight).

* (gasp) Use soft reconfig sparingly.

One other thing to do is to see if there is anything else that is using 
up the CPU (that is if you are already running a 3.6 or later image, 
otherwise you learned what you problem is in the first line of this email).

BTW, not your exact problem, for entertainment here is an XMR in 
Amsterdam with a decent amount of BGP sessions (before 3.6 used to act 
just like your problem, 3.6 and greater life is good):

core1.ams1.he.net>sh ip bgp sum
   BGP4 Summary
   Router ID: 216.218.252.173   Local AS Number: 6939
   Confederation Identifier: not configured
   Confederation Peers:
   Maximum Number of IP ECMP Paths Supported for Load Sharing: 1
   Number of Neighbors Configured: 342, UP: 323
   Number of Routes Installed: 1208271, Uses 103911306 bytes
   Number of Routes Advertising to All Neighbors: 5431183, Uses 
238972052 bytes
   Number of Attribute Entries Installed: 760991, Uses 70011172 bytes

core1.ams1.he.net>sh ipv6 bgp sum
   BGP4 Summary
   Router ID: 216.218.252.173   Local AS Number: 6939
   Confederation Identifier: not configured
   Confederation Peers:
   Maximum Number of IP ECMP Paths Supported for Load Sharing: 1
   Number of Neighbors Configured: 141, UP: 137
   Number of Routes Installed: 6519, Uses 560634 bytes
   Number of Routes Advertising to All Neighbors: 110382, Uses 4856808 bytes
   Number of Attribute Entries Installed: 39148, Uses 3601616 bytes

Mike.

Alex Rubenstein wrote:
> We're having a minor issue, and we are working with Foundry with this
> issue. However, I would like to take a quick survey and see if anyone
> else is running into similar problems.
> 
> We have several XMR's in our network. Their life is destined to be
> connected to other XMR's in our network, to transit providers, to peers,
> and then aggregation routers uplink to them.
> 
> We have had an issue where, when an XMR is rebooted, BGP takes an
> extraordinarily long time to converge. The slowness seems centered
> around the pushing of routes out to iBGP peers; we've seen instances
> where this might take hours. Even a lowly M5-333/768 or Sup2/MSFC2 can
> do this in 1 minute or less.
> 
> Has anyone else seen this sort of behavior?
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp at puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp

-- 
+---------------- H U R R I C A N E - E L E C T R I C ----------------+
| Mike Leber        Wholesale IPv4 and IPv6 Transit      510 580 4100 |
| Hurricane Electric                                           AS6939 |
| mleber at he.net     Internet Backbone & Colocation      http://he.net |
+---------------------------------------------------------------------+