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

[Arie Vayner (avayner)]

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: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] 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)" <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
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/