Welcome to the Cisco Networking Professionals Ask the Expert conversation. This is an opportunity to discuss MPLS VPN Technology with Cisco expert Amrit Hanspal. Amrit is a Senior Product Manager. He works in the Internet Software Technologies which is responsible for the development of the IOS software. He specializes in MPLS and QoS. He specifically focuses on MPLS Traffic Engineering with respect to ISIS and OSPF based bandwidth optimization, Protection Services in Traffic Engineering like Fast ReRoute, and DiffServ aware Traffic Engineering. His area of responsibility also includes DiffServ over MPLS, Integrated Services and IntServ-DiffServ Integration. Remember to use the rating system to let Amrit know if you have received an adequate response.
Amrit might not be able to answer each question due to the volume expected during this event. Our moderators will post many of the unanswered questions in other discussion forums shortly after the event. This event lasts through January 16. Visit this forum often to view responses to your questions and the questions of other community members.
When enterprises migrate the existing ATM/FR to MPLS based IP VPN service provided by the Service provider, will network security, such as virus, DDos, be a bigger concern to enterprises?
MPLS Based IP VPNs have been certified to be as secure as ATM/FR by independent sources like Miercom. MPLS leverages a number of mechanisms within Cisco IOS to handle virus attacks and DDoS. For example, NBAR, a "deep packet" inspection technology within IOS, was used to detect Code Red Virus signatures. Configuring MPLS VPNs to limit number of routes learned can also effectively thwart DoS attacks.
In a nutshell, there are a number of features available within Cisco IOS to ensure a similar, if not better, degree of security with MPLS based IP VPNs.
My question is about mission critical applications.How do traffic requirements for mission critical applications like SAP differ from those of VoIP?
MPLS leverages IP QoS mechanisms to handle multiservice traffic. Service Providers have deployed as many as 5 traffic classes - Voice (VoIP), Video, Mission Critical, Interactive & Best Effort.
VoIP uses the "Voice" class and has very strict delay, packet loss and jitter requirements. It is also a traffic class that is very "well behaved" when compared to Video traffic. "Well behaved" implies that traffic within this class is not bursty in nature. The most common approach to service this class is to use the Priority Queue (i.e. LLQ) and use strict policing (since traffic is well behaved).
Mission Critical traffic needs low packet loss and is also delay sensitive (though not as much as VoIP or Video). This class generally requires CBWFQ, WRED and sometimes shaping. WRED thresholds for this class are less aggressive than those for lower traffic classes like Interactive & Best Effort.
We are in the retail industry and we have hundreds of stores, warehouses, dealer stores, office buildings and etc. We are trying to find a new solution to replace the old frame relay circuits between all these premises and the data center. ADSL technology could be the potential candidate. My question is:
1. Is there an ADSL/MPLS/VPN technology?
2. If there is, what is the difference between the frame mode/ATM mode MPLS and the ADSL mode MPLS?
Since MPLS VPN is Layer 3 based, it has the flexibility to be offered on a variety of Layer 2 technologies - and ADSL is definitely a candidate over which MPLS VPN services can be offered. There is no "ADSL mode MPLS" as such. MPLS can be used in either Frame Mode or Cell Mode. Frame mode would generally be used over ADSL technology.
For retail industry, MPLS VPN offers immense simplification at the headend site. For example, if your headend site had to connect to, say, 100 remote sites you would probably need to manage 100 FR VCs. With MPLS VPNs, your headend site has a single connection to the Service Provider backbone. Additionally, MPLS VPNs can leverage import/export of routes to simulate hub/spoke as well as mesh topologies. For example to create a hub/spoke topology, you would configure MPLS VPN "spoke sites" to import routes only from the "hub site". Consequently, "Spoke site 1" can reach "Spoke Site 2" only via the "Hub site".
Typical scenarios of MPLS VPNs have ADSL at the Access layer (PE-CE links) - so MPLS switching is not present over ADSL. However, scenarios wherein ADSL is used for PE-P links, MPLS Switching comes into play.
Cell mode MPLS is used only when Label controlled ATM switching is used. There are advanced deployment scenarios of MPLS VPNs that use Carrier Supporting Carrier which extend MPLS to the edge devices - those have typically used Frame Mode MPLS.
One common misconception is that that ATM encap implies cell mode MPLS. Consider the following topology:
Router A ===> ATM Switch 1 =====> ATM Switch 2 ===> Router B
If a PVC is defined from Router A to Router B, one can enable Frame mode MPLS over this switched WAN media. It is important to note that you can configure cell mode and frame mode on the same ATM physical interface. So you can have one sub-interface with cell mode, while another with frame mode
However, it is certainly conceivable to have cell-mode MPLS used over ADSL. Hope this helps.
Are we able to gain the same sort of latency as a standard frame relay connection?
Is Voice over these types of VPN's now a viable option in terms of quality?
And is the success of implementation mainly hanging on the service provider chosen?
Almost 98% of our Service Providers that have MPLS have enabled MPLS VPNs and QoS offering within them (deployed or planning in the near term) is closer to 75%. The success of the QoS offering is indicative that the latency achieved is closer, if not better, than Frame Relay connections. Actual numbers achieved vary from network to network - we have very often heard of sub 100ms latencies. Voice typically requires lesser than 150ms latency.
Like any service offering, the success of a VPN implementation is dependent upon the Service Provider chosen - whether it is MPLS VPNs or IPSec or a hybrid of these.
We are an ISP which is in a process to make its network MPLS enabled.I have few queires to you:
1)On an MPLS enabled interface if an IP access-list has been implemented.How the access-list behave when the access-list is inbound to the interface and how does it behave when it is outbound?
In Cisco IOS, every interface is inherrently designed to simultaneously forward IP as well as MPLS packets. IP access lists are applicable for IP Traffic or "unlabeled packets".
If you were to configure an ACL on an interface which has MPLS enabled, only IP packets will be affected. This is applicable for inbound and outbound. A point to note - for MPLS VPNs, the inbound interface (or CE facing) at the ingress PE receives IP packets, while the outbound interface at the egress PE (CE facing) pumps out IP packets. So an ACL configured at these points in your network will permit/deny IP packets.
We have enabled MPLS in following Physical Topology and facing problem related to Label assignement. Please help to resolve the same.
A-PE1--ESTEL-HSSI-----Satellite Link UK-A-P(it has separate Receive Interface & Separate TX Interface)---DS3---> B-P--FastEthernet-->B-PE2
a. Loopback of PE1, say Lo1: a.b.c.d
b. Loopback of PE2, say Lo2: p.q.r.s
c.. Now we have defined Static Route to reach Lo1 & Lo2 in the entire path between PE1 & PE2
d. PING was tested for Lo1 & Lo2 from PE2 & PE1 respectively.
e. Now we have enabled the MPLS/LDP("mpls ip") in entire path which connect PE1 & PE2 but after enabling MPLS/LDP, the PING for Loopbacks, between PE1 & PE2 stops/fails.
f. As such UK-A-P Router should have behaved as P Router but we observed a very odd behavior. We observed that PE1 was sending "NULL" Label for Lo1 to UK-P[with respect to UK, this is like remote label for Lo1], Normally UK-A-P should assign a valid Local Label for Lo1 & advertise to P-RTR-Fus but on the contrary, the UK-A-P was assigning "NULL" Label for Lo1 & advertising the same to B-P. Hence Return Traffic for Lo1 a.b.c.d, coming from B-PE2 via B-P, will get drooped at UK Router due to implicit Local "NULL" Label & therefore PING failed when "MPLS/LDP" was enabled on the given path.
I may be wrong in my interpretation of this Flow, would appreciate your help to correct my understanding & guide to resolve this issue.
It maybe difficult to do this via this forum. The only input that I can provide is that having separate interfaces for rx/tx can cause this problem.
Please send me an email with config/display files - firstname.lastname@example.org and I can help.
Thanks for your response.I have a few more queries.
1)In case of L2VPN even if the VC gets established the packets end to end do not flow?What could be the possible reasons?
2)Do we need to enable "mpls ip propagate-ttl" on all the routers on the LSP to find out breakage in the LSP?
It is possible that L2 VPN pseudo wires can get established, but packets do not flow. There can be a host of issues involved. I cannot give you a definite answer on this specific query - however, I would request you to send me an email with the following information:
1) Topology being tested
2) Config files/display outputs
Please contact me at email@example.com - I can help troubleshoot the issue you are facing offline.
1.What are the operational & reliability issues if the ATOM is setup across Inter-AS over GRE Tunnel?
2. We have following connectivity setup
CE1->802.1Q VLAN->PE1-AS1->P-AS1- Over-GRE-Tunnel----->P-cum-PE-AS2-->CE2
a. P cum PE-AS2, is the same Router.
b. GRE Tunnel is between P-AS1 & P-cum-PE-AS2 Router.
c. PE1-AS1, P-AS1 & P-cum-PE-AS2 are all 75xx chassis and all are running 12.0(25)S1
d. All these routers are running Distributed DCEF and also running flow switching on some interfaces.
As such VC comes but it require following steps to be executed on P-cum-PE2-AS2 to bring up the VC.
i. Disable DCEF on GRE Tunnel Interface.
ii. Enable the flow switching on GRE Tunnel Interface.
iii. Enable the DCEF on GRE Tunnel Interface.
We observe this is a odd behavior and infer that while MPLS packets start DCEF Switched but it require flow Switch Path on GRE Tunnel Interface to Tunnel [GRE encapsulation]the MPLS Packet.
Request for your input on this behavior & stability of such a L2 Service (ATOM based).
3. Please also updated on ATOM Bug "CSCec74884" like what it is expected Resoloution Time etc.
It would be better if you implement Inter-AS Layer 2 VPNs using Inter-AS with BGP label distribution. You will need to leak PE loopbacks to establish the VC.
I guess, you are referring MP-BGP based Label distribution which is normally used for L3 VPN. Kindly post me a link which define such a L2 VPN/ATOM case where MP-BGP based leaking can be used to distribute the Tunnel Lable[LSP between PEs].
You see, the issue, which I have lighted, is related to Switching of MPLS Packet over GRE Tunnel but not availability of Tunnel Lable, across Inter-AS. As such, we can not do away the GRE Tunnel between these two AS, so we are looking for stable & reliable solution which meet our L2VPN requirement.
Would appreciate your reply.
The BGP based label distribution for building Inter-AS L2 VPNs is a relatively new area. We have some internal documents - I am trying to determine whether we have an externally applicable document. I will work with you offline via email to address your specific queries.
I am assuming your query was motivated by my earlier comment of "leaking PE loopbacks".
If so, MPLS Layer 2 VPNs uses directed LDP sessions to establish pseudowires using Any Transport over MPLS (AToM). Directed LDP sessions generally use the loopbacks of the PE to establish sessions. If you need to establish a pseudowire across AS, you need a LDP to be established across this AS. To accomplish this you need to advertise or "leak" the IP addresses of the loopback interface of a PE router using BGP label distribution. That is what I meant by "leaking PE loopbacks"
If I misunderstood your question, please let me know. Will be happy to answer again.
I have a 2610 cisco Router. I want to choose an E1 chanalizer module for that but I don't know which one of the E1 chanalizer cisco modules is the right one how can I find it?
Thanks for your help
My primary focus is on MPLS as a software technology. Consequently, I am not the best person to answer a hardware specific query.
The best way to obtain an answer for your query would be to post your question to the Network Infrastructure Forum - specifically the WAN, Routing and Switching. You can access that section via this url - http://forums.cisco.com/eforum/servlet/NetProf?page=Network_Infrastructure_discussion
I will be more than happy to answer your MPLS specific queries.