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
[email protected]
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 |
| [EMAIL PROTECTED] Internet Backbone & Colocation http://he.net |
+---------------------------------------------------------------------+
_______________________________________________
foundry-nsp mailing list
[email protected]
http://puck.nether.net/mailman/listinfo/foundry-nsp
