Just a small tip when activating IPv6 in BGP - use the "global" bgp command "no bgp default ipv4-unicast". This would stop the default creation of bgp peers under the ipv4 unicast address family, avoiding the below situation.
Arie -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Jeremy Reid Sent: Monday, September 13, 2010 17:08 To: Oliver Boehmer (oboehmer) Cc: cisco-nsp Subject: Re: [c-nsp] C65K: Any significant correlation between import filter route-map complexity and BGP Router process utilization? Oli/All, Thanks for the clarification about no hardware assist whatsoever being involved in route-map processing -- makes sense: I just wasn't thinking clearly. ;) That said, just for posterity, we did notice about a 2% total drop in RP CPU by simply removing the match statement from the final 'catch-all' clause in the route-map. As Oli pointed out, that statement was completely unnecessary. Separate from the original question asked: We did find the true culprit for what was significantly elevating our RP CPU (BGP process) loads: An IPv6 peer that was activated under *both* the ipv6 AND ipv4 address-families... Once the errant ipv4 neighbor activate statement was removed, the session reset and we shed about 20% overall CPU for BGP router. Word to the wise, outside of us previously failing to notice the V6 session output in a (v4) 'show ip bgp summary', there were no log messages, etc. indicative of the mis-built peer session, and the peer was up and working correctly within the V6 context. Operationally, All we saw was high CPU for BGP router that could not otherwise be explained until the V4 peer session was found pointing to the V6 peer's address. Anyway, our stupidity -- just something everyone else may want to be aware of as a possibility should you ever be troubleshooting otherwise unexplainable high CPU conditions with BGP Router. -Jeremy ----- Original Message ----- From: "Oliver Boehmer (oboehmer)" <[email protected]> To: "Jeremy Reid" <[email protected]>, "cisco-nsp" <[email protected]> Sent: Friday, September 3, 2010 2:33:30 AM Subject: RE: [c-nsp] C65K: Any significant correlation between import filter route-map complexity and BGP Router process utilization? > Hi list, > > I was wondering if anyone here has been able to establish any real-world > correlation between the relative complexity of a BGP import filter (a route- > map with various match clauses which reference various other prefix/AS-path > lists to set metric/preference attributes on incoming prefixes) and any > related impact to RP CPU? (specifically, the BGP Router process) > > We make fairly extensive use of import route-map logic for outbound traffic- > engineering purposes between our various transit providers, and I'm trying > to determine if this practice is responsible for driving up RP CPU > utilization significantly higher than would otherwise be the case. I believe > that route-maps are (largely?) processed in hardware on the 65K platform > (S720-3BXL), but nevertheless, logically, it seems to me that since each > received prefix must pass through the route-map logic until it reaches a > match clause that matches and then sets the associated attributes, I can't > help but think the impact on CPU can't plausibly be 'zero'. You are talking about BGP routing policy statements, which are implemented on the CPU, not in hardware (this is control plane, not fwd plane). So there is a direct correlation between RP CPU load and routing policy complexity. I can't tell if your policy can be optimized, but you are already matching on prefix list (which is generally causing less CPU cycles for lookup). Not sure if "match as-path 41" is needed in the last statement (seq 20, which looks like a catch-all), if you do want to drop some as-paths there, you could consider moving the drop logic to the top, and don't use any "match" in the last clause. Not sure if this changes the cpu load noticeable.. [...] > Any thoughts on if this seems excessive, or if you think this should or > should not significantly contribute to overly 'elevated' CPU consumption by > the BGP router process? I don't think your policy is excessive. oli -- Jeremy Reid Network Engineer, MojoHost Toll Free: (888) 345-MOJO, ext: 808 International: +1-248-233-2045, ext: 808 _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
