[c-nsp] VRF and update-groups

[Bruce Pinsky]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michail Litvak wrote:
> I have cisco 6500 with sup720bxl3.
> 
> s72033_rp Software (s72033_rp-ADVIPSERVICESK9_WAN-M), Version
> 12.2(18)SXF4, RELEASE SOFTWARE (fc1)
> 
> I  have some vrf configured (not for mpls but for router virtualization
> ). In one vrf  I have an uplink session with full-view and about 20
> peers which receive full-view from us.  I case uplink interface
> flap/BGP session flap I see 100% CPU used  by BGP Router/Scaner
> process and some session  then goes down due "hold time expired".
>  This 20 peers united to few peer-groups. In order to investigate and
> improve CPU usage I try to view how effective update-groups and:
> 
> router# sh ip bgp vpn vrf world peer-group   | inc repl
>   Update messages formatted 0, replicated 0
>   Update messages formatted 0, replicated 0
>   Update messages formatted 0, replicated 0
>   Update messages formatted 0, replicated 0
>   Update messages formatted 0, replicated 0
>   Update messages formatted 0, replicated 0
>   Update messages formatted 0, replicated 0
>   Update messages formatted 0, replicated 0
>   Update messages formatted 0, replicated 0
>   Update messages formatted 0, replicated 0
>   Update messages formatted 0, replicated 0
> 
> I see that peer-groups have no effect to optimize route updates.
> Is this caused by errors in my configuration or in configuration with
> VRF this optimization don't work ?
> 
> P.S. Sorry my bad english.
> 

In the version you are running, peer-groups are only a configuration tool
and don't affect how updates are generated.  Instead, the router creates
update-groups dynamically based on the outbound policies applied to the
neighbors.  You should use "sh ip bgp vpn vrf world update-group" to see
how the neighbors are grouped for update purposes.

With 20+ peers with full views, I suspect that you are seeing symptoms of
1) input queue exhaustion of the downstreams resulting in high
retransmissions on your router; 2) input queue exhaustion on your router
due to high ack rate from number of updates being generated; and 3) MSS
that could be too small resulting in huge number of packets necessary to
transmit the updates.

You may also be suffering from buffer exhaustion and/or memory exhaustion
due to the number of packets being generated.

You should take a look at the following stats:

- - interface stats to look for input and output queue drops
- - IP traffic stats to see if you have a high number of retransmissions
- - buffers stats to see if you have buffer starvation
- - memory stats to see how much free memory you have and what the lowest
free memory was
- - SPD stats looking for flushes and drops
- - BGP neighbor info to determine the TCP MSS (max data segment size)

You will likely need to do some tuning based on what you find in the
output. Minimally, I suspect you will need to modify your input queue
lengths and possibly your output queues as well.  Without some more info,
it's difficult to make any further recommendations or to precisely identify
the exact cause of your situation.

- --
=========
bep

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFE0NjPE1XcgMgrtyYRAhbRAKD5ORFZ0vZKKHyDOlxrQTeTkpxAHQCfXNdF
yyos1boyuk1+taB16+EjBNA=
=zAw0
-----END PGP SIGNATURE-----