[c-nsp] BGP convergence in VRF vs. global routing table on 7600router

Oliver Boehmer (oboehmer) oboehmer at cisco.com
Fri Oct 19 07:59:51 EDT 2007

Christian Bering <> wrote on Friday, October 19, 2007 1:36 PM:

> Hi all,
> Putting a full Internet routing table inside a VRF instead of in the
> global routing table, we see BGP convergence times about a factor 10
> higher.

Can you pls describe which "convergence" you are referring? Time it
takes after bringing up the session until every other PE has the routes?
Or the table version on the CE and the receiving PE is the same?

> As far as we can tell, it's mostly the BGP process eating CPU time, so
> it doesn't seem to be a matter of label allocation or FIB/TCAM
> programming.
> What makes the BGP process behave differently in a VRF than it does in
> global routing table?

Well, if you are talking about the PE which has the eBGP session to your
upstream ISP, we need to allocate a label, go through the export policy
and create vpnv4 paths, so quite a bit of processing overhead. Not sure
about the platform, but I would also expect a bit more overhead
programming the hardware.

If you talk about a distant PE receiving the full table from the RR via
iBGP, the overhead will likely depend on the RD setup. I assume you use
a common RD for the "internet" VRF on all your PEs, right? Otherwise the
receiving PE would need to make a copy of each vpnv4 path while
importing the routes, effectively doubling the memory consumption :-|

> Is it because the code hasn't been optimised for this? Or a hardware
> issue?

This could be one reason. CEs advertising > 200k prefixes are not widely
seen in 2547bis environments :-)

> Any knobs to adjust?

next to PMTUD, none I could think of without knowing more details.
> Any improvements to this behaviour in SRB2 over SXE, SXF or SRA?

need to know more details..


More information about the cisco-nsp mailing list