North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: "Cisco MPLS-based VPNs" & BGP Stability
Hello Franklin, I promised to Danny to stay silent but since there are a few things I must clarify in your mail I will break my promise with just one small calrification: > 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. Yes you are right. That is why all knobs we have are address family specific. You can adjust timers for Internet routes in a different way then for VPN one without impacting one with the other on the same router. R. > Franklin Lian wrote: > > 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 > Internet? > > 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. > > Franklin > > 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: [email protected] 13775 McLearen Road > Tel: (703)375-7893 Oak Hill, VA 20171 > Fax: (703)471-3380 U.S.A. > ---------------------------------------------------------------
|