"Cisco MPLS-based VPNs" & BGP Stability

Franklin Lian Franklin.Lian at globalone.net
Wed Apr 18 20:18:41 UTC 2001

Hi, Robert

After dealing with MPLS-VPN for about two years I have something to
say about whether we should put IPv4 and VPNv4 on the same box.  Well
I will be more focus on the enterprise side instead of Internet side.

The characteristics of VPN are quite different from the Internet
customers, and I don't believe it is a good idea to use the same
hardware/software to address the requirements from two total 
different worlds.

Here are some differences:

Requirements		Internet		Enterprise
Access Speed		High (DS3 and above)	Low (64K~DS3)
Routing table		Huge (100K and above)	Small (up to 10K)
Serurity		Some			Critical
Convergence time	in term of min		in term of sec

Regarding routing process, I have less concern on the impact that
VPNv4 routes bring to IPv4, however, I have some concerns on the 
impact that the 100k IPv4 routes bring to the VPN world.

Cisco IOS gives me two BGP timers for tuning the convergence time of
BGP.  BGP has been proven to be scalable but not as fast as IGP such
as OSPF that is widely deployed in enterprise network.  With pure VPN
I can try to reduce the BGP timer for speeding the convergence up,
however, with full Internet routing table I would not do that.

I will say the scalability and fast speed convergence is a pair of
contradictions here.  Internet requires scalability much more, and
enterprise network requires faster convergence time on the hand.  So
I will not say it makes a lot of sense to bind them together.

Another issue is about maintenance and supporting.  Due to different
access speed requirements, and technologies used for the services,
the best IOS code for Internet service is not the code for the VPN
service.  At least YET.  I understand theoretically the code can be
converged into one, but I am talking about practical implementation.
>From this perspective, does it make more sense to split the functions
(IPv4 and VPNv4) into two sets of edge boxes considering the risks
of hardware/software failure?

The last point I would like to talk about security issue. Whenever 
an enterpirse customer put a RFP, security is always one of
the most critical issue there.  When I answer my customer about the
security I always say my MPLS VPN solution is as secure as FR/ATM 
solution because MPLS VPN technology can safely separate VPNs by 
deploying the address family and my service network is a private
network that is not aware of the Internet at all.  However, I don't
think I can guarantee the security level the same as FR/ATM if I
combine the Internet and Intranet together on the same network.
How can I prove that MPLS VPN solution is secured, or at least be
competitive to FR/ATM VPN and IPSec VPN in term of security, when 
the underlay network infrastruction is directly exposed to the 

IMHO, technically I don't think it is a good idea to have one box
supporting both Internet and MPLS VPN.  However, I do comprise to
the idea for the cost reason.


Robert Raszuk wrote:
> Hi Danny,
> > 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.
> But that was my point if you have a few vpnvs hang on any given PE with
> a few thousand of routes I don't think even ipv4 peering PE will fell
> any impact. On the other hand when your number of vpnv4 routes grow on
> PE it is clear that with current hardware limitations (mostly memory, a
> bit of CPU) operator will need to decomposition ipv4 nodes from vpn PEs
> hence the PEs will have 0 impact to the ipv4 BGP stability.
> > I fully agree that if dedicated infrastructure is employed for
> > this purpose then there will clearly be less impact.  However,
> > the whole pitch is that existing network elements can be used
> > to offer the service, the same network elements that provide
> > "Internet" connectivity today -- and lots of folks have drank
> > the kool-aide -- all in hopes of generating more revenue from
> > their existing IP infrastructure, not new dedicated or overlay
> > ones.
> As I said above you don't until you need to dedicate boxes for
> mpls-vpns. When you have so many customers that don't simply fit into PE
> (already loaded with 90K of ipv4 routes) you have two choices:
> A) Buy a more powerfull box,
> B) Decomposition Internet and VPN
> > Then every time someone brings up a scalability or convergence
> > or security issue with BGP/MPLS VPNs a slew of Cisco folks tell
> > them it's targeted at private networks and different
> > infrastructures (hence the requirement for BGP, MPLS, etc..,
> > I guess).
> >
> > Rob, I know how you & your cohorts feel, I was looking for operator
> > feedback.
> No it is not that I am feeling one way or the other. Getting feedback is
> extremely usefull - but all I care about it to get feedback regarding
> true issues not those which are practically not the problem.
> > -danny (who strives to only listen to the rest of this thread)
> I will do the same letting other's comment.
> R.

Franklin Lian (Lian, Zidan)          Global One
Principal Engineer                   Mailstop: VAOAKM0201
Email: Franklin.Lian at Globalone.net   13775 McLearen Road
Tel: (703)375-7893                   Oak Hill, VA 20171
Fax: (703)471-3380                   U.S.A.

More information about the NANOG mailing list