"Cisco MPLS-based VPNs" & BGP Stability

Christian Kuhtz ck at arch.bellsouth.net
Wed Apr 18 00:33:29 UTC 2001


> I'm referring more to the PE impact, or any other router that
> participates in unicast IPv4 peering.  There's still a single
> BGP process, a finite amount of memory and CPU resources, etc..,
> and impacting any of these can adversely effect IPv4 route
> stability.  Or does the separation you refer to suggest that
> we have no worries with BGP and route table growth, churn
> frequency, et al., and that it should be left to the academics?

I don't believe anyone's suggesting that.

Full Internet routing tables, unicast IPv4 BGP peering over RFC2547(bis)
networks should be done between peers directly, and not with the PE (there's
really no reason for the PE to participate in this, all the PE needs is a path
to get to the CE and the other PE, and vice versa).

So, you do peer with (or import static from) each CE attached to a PE.  Per
VPN, how many summarized routes are you going to get? a dozen?  two dozen per
VPN tops?  With the average being much less, right?  So, a couple of thousand
VPNs add a couple of thousand or so more routes in the BGP (counting
everything as VPNv4 addresses) don't add all that much grief, or do they? Now,
keep in mind that again, all the PE-CE peering needs to pass is enough routes
for the CE-PE-PE-CE communications (and the various iterations with n peers)
to occur.  If CE's peer with BGP, they would exchange routes directly with the
other CE in the VPN via eBGP multihop.  Otherwise, it's whatever the IGP
summarizes and passes to the PE.

Maybe I'm missing something here, but that's how I see the world, and I'm not
sure this is such a big deal.  The work we've done in this area in the past
confirms that.

It's a tool.  And if you decide to blow one or both of your feet away, it's
your choice.  But there's nothing that says that's the only way to use the
tool, or the only reasonable or least ops pain to use the tool.

Cheers,
Chris

--
Christian Kuhtz <ck at arch.bellsouth.net> -wk, <ck at gnu.org> -hm
BellSouth Internet Services, Atlanta, GA, U.S.
Sr. Architect, Engineering & Architecture  "I speak for myself only"






More information about the NANOG mailing list