Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member


Iam in progress of designing the MPLS VPN network , The ? is (1)What type of routing protocols can I implement between "P" router or edges , Iam using IGX 8420 with URM Modules.(2) What routing protocols between "PEs" (3) What routing protocols in "CE".

My current sceneria explains: "CE" ->OSPF , PE-PE ->BGP Comm. , P-P -> IS-IS , Need suggestions , Do I complicating the Network , IS it advisable

  • Other Network Infrastructure Subjects
Cisco Employee


between PE-P and P-P you can use what ever routing protocol you want.

However, OSPF and ISIS offer the most advantages due to their Link state type (especially for MPLS/TE).

Between PE routers you need BGP to carry VPN information.

To go to the CE, you can also use different protocols like OSPF,BGP,RIP, ....

But you can also use static routes depending on what you want to do.

You also have to chose a label/tag distribution protocols.

You can either chose TDP or LDP.

TDP is the cisco version and LDP is the standard which is also supported by Cisco devices.

New Member


Thanks Indeed!!! For your valuable points , but still I have few more to be answered.

1. If I use CE's (VPN) OSPF as routing protocol , then what routing protocol been advisable to use between PE - P and P-P. For. ex.: If I use OSPF then what will be the complication's will occur or If I use IS-IS what will be the complications and Which one will drive me in a correct sceneriao.

2. I have 16 major sites and Iam planning to run each sites as a separate VPN's , Is it advisable to run like this or all sites as one VPN.

3. Which will suite me ? either L3 MPLS VPN or L2 MPLS VPN and in what type of sceneriao will able me to choose L3 or L2 MPLS VPN


Since you asked about whether you are complicating the network and whether your suggestions are advisable, I would go further and say that the whole L3 MPLS VPN concept is probably not advisable, at least not right now. Let's face it. Customers aren't exactly champing at the bit for L3 MPLS VPN services, and whatever VPN's they do want can usually be provided more simply, more reliably, and cheaper using existing FR/ATM services, or if you really really want to use MPLS, then L2MPLS VPN's such as offered by Cisco's AToM technologies, or technology offered by a, shall we say, unnamed vendor (hint, starts with a 'J'). L3 VPN's suffer from problems of BGP route-table scalability and the fact that you're now accepting responsibility for the routing of your customers. So in most cases, I would say that it's simply too much complexity for not enough benefit. The only clear benefit L3 MPLS VPN's offer over L2 MPLS VPN's are in any-to-any customer connections, but honestly, right now and for the foreseeable future,how many customers really need any-to-any connectivity?

But in direct answer to your question, your proposed routing is fine. Just make sure that the PE to PE connection is MBGP, not regular BGP (you would need regular BGP if also you want to do regular Internet routing on your PE's in addition to VPN routing).

New Member


Thanks Indeed for your open comments !!! Once again Thanks for you. But still I have few queries..

1. The sceneriao where Iam going to implement is Iam having almost 16 major sites in which all equipped with STM-1(155 mbps) P-P

2. Thanks for your advise for choosing MBGP between PE-PE

3.Iam already in selection of any-to-any connectivity , but now iam afraid from your comments , could you please explain what sort of compliocations will raise if I use L3mpls vpn - any-to-any and If I want to use L2 mpls vpn then in what type of setup you want to go further.


When I refer to problem as it relates to 'any-to-any', I am talking about the N-squared scalability problem of full-mesh peering of multiple customer routers over a traditional FR or ATM backbone. Any new site that a customer will want to add to such a backbone will require that the customer order many more virtual-circuits and then create a whole slew of new peering sessions. Clearly you can understand why this is a problem. L3 MPLS VPN's eliminate this N-squared scaling problem because customer routers no longer have to peer with other customers routers, they peer with a VRF on a provider router. This is the only clear advantage that L3 MPLS VPN's hold over other solutions.

But the real question is how many customers really have any-to-any peering? I'm not talking about peering within the provider, I'm talking about customer peering. For example, how many customers really have lots of branch offices that actually communicate with each other a lot, enough to justify any-to-any peering? At this time, almost none. Most customer networks are set up such that most of the WAN traffic consists of traffic from a branch office to a main "headquarters" office, and branch office to branch office traffic is low. Therefore, most customers really only need a hub-and-spoke model of peering.

So my point is, the advantage of L3 MPLS VPN's consists of eliminating the problems of customer any-to-any peering. But right now, how many customers really have this problem? Very few. So if you provide this service, how many customers will really want to order it? I regret to say that the answer will probably be very few. Your company will certainly find it difficult to earn high profits from such a service, because the fact is, the service doesn't really provide anything that most customers can't get already get by ordering a different service.

And the problems of L3 MPLS VPN's are well documented. Basically, you are taking partial responsibility for customer routing, which is a very dangerous thing. For example, what if one of your customers accidentally imports the entire BGP table and then propogates it to one of your PE's? Almost certainly, your router will crash, which takes down every customer attached to that PE. Or what if a customer's network is unstable? This will mean that the PE's VRF route table will be unstable which is very stressful for that PE. Things like that. So basically you end up with all these problems with linking your routers with a customer's routers, so any problems that a customer is having will become your problem also.

Which is why I'm much more enthusiastic about the L2 MPLS VPN's, which is simply providing L2 services like FR, but using IP and MPLS in the core of the provider. For example, Cisco's martini-draft implementations in its AToM technology. Or Juniper's kompella or martini-draft implementations. Either way, you are no longer linking the provider's network to the customer's network. If a customer's routing is having problems, it doesn't affect the provider's network. As long as you are properly providing L2 connectivity, your job is done. If the customer's routing is broken, it is not your problem because you are not responsible for providing routing services.

New Member


Thanks once again for your patience !!! of giving me the right indications.

Now !!

1. Basically Iam having an ATM Backbone and Iam in the phase of moving to MPLS VPN Architecture , and the current requirement Iam not going to be an ISP now but in future yes!!, The design which iam doing right now is as though like a corporate network .

2. I had major 16 sites to corporate with MPLS VPN , Still to decide L2/L3 Mpls vpn.

3. If and all I want to go L2 Mpls VPN , Is this will work for any-to-any comm.

4. Access will be HQ -to- Major sites - to - branches -to-HQ


Again, I have to ask, why MPLS VPN's?

If you want to merge your ATM and your IP routers together into a unified network, then implementing MPLS is good enough. You don't need to implement VPN's right now. Why not wait until MPLS VPN technology is more proven? The technology has only been out for a short while, so there are bound to be bugs.

L2 MPLS VPN's work for any-to-any just like traditional ATM. The customers have to worry about how they want to connect and if they decide they want any-to-any, then they will have to request multiple virtual circuits, just like ATM. And like I said before, the major advantage here is that you're not linking your routers with the customer's networks, so if they are having routing problems in their network, it doesn't affect you. As long as the virtual-circuits you are providing are functioning, your job is done, you don't need to worry about if the customer can route or not.

I should have added that L3 VPN's do have one other advantage over L2 VPNs, in that L3 VPNs are more standardized. They have actually attained RFC status, whereas L2 VPN's are still drafts. So I guess you could say that L3 VPN's are probably more stable and have better inter-vendor operability. But in any case, either one is still very new. There are bound to be problems with either technology. So why implement VPN's if you don't have to? You can just stick to normal MPLS (which is also fairly new, but does have a clear benefit in unifying your IP routers with your ATM switches).

New Member


MPLS-VPN will isolate my central region (SEC-CRB) from the core of the network, and the routes used in the ATM WAN will not be visible to the SEC-CRN network, but this will not be done until after head office migration.


Well in that case, either kind of VPN will do you just fine. Which one you choose will have to be determined by the specifics of your network. It's a design choice. I still think L2 is probably better, but since I don't the details of your network, I can't say for sure.

What I can tell you is this. If you insist on running L3, make absolutely sure that no CE accidentally introduces the whole BGP routing table into a VRF. That would blow up your network in a Sunday minute.

This widget could not be displayed.