[c-nsp] C65K: Any significant correlation between import filter route-map complexity and BGP Router process utilization?

[Jeremy Reid]

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)" <oboehmer at cisco.com>
To: "Jeremy Reid" <jeremy at mojohost.com>, "cisco-nsp" <cisco-nsp at puck.nether.net>
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