Interprovider MPLS VPN - "drop -- rewrite null"

Hi,
i have an interprovider VPN where a remote route is received on ASBR and forwarded to my AS PE but traffic coing from my PE is dropped because label forwarding is not installed:
c2851-ASBR#sh ip bgp vpnv4 all la
Network Next Hop In label/Out label
Route Distinguisher: 3302:141141
10.0.0.0/24 172.26.107.94 20/100192
81.114.246.16/29 172.16.0.4 22/18
192.168.0.0 172.16.0.4 21/16
c2851-ASBR#sh mpls forwarding-table
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
16 Pop tag 172.16.0.4/32 0 Gi0/1 172.26.0.2
21 16 3302:141141:192.168.0.0/24 \
0 Gi0/1 172.26.0.2
22 18 3302:141141:81.114.246.16/29 \
0 Gi0/1 172.26.0.2
As you can see the label 100192 is not present in the mpls forwarding.
If i create the vrf on the ASBR everithing works correctly:
c2851-ASBR#sh mpls forwarding-table
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
16 Pop tag 172.16.0.4/32 0 Gi0/1 172.26.0.2
20 100192 10.0.0.0/24[V] 488 Gi0/0.124 172.26.107.94
21 16 192.168.0.0/24[V] 472 Gi0/1 172.26.0.2
22 18 81.114.246.16/29[V] \
0 Gi0/1 172.26.0.2
Thanks
S.

the lab setup is quite simple:
AS1 PE --ibgp-- AS1 ASBR (172.26.107.94) ----ebgp---- AS2 ASBR (172.26.107.93) --ibgp-- AS2 PE (lo0 172.16.0.4)
From the AS2 ASBR the next hop for the internal route is the lo0 of the AS2 PE and the next hop for the AS1 route is the ip address of the btb interface (the ebgp peer is built on the directed connected interface). So no problem on the ebgp next hop.
The label swap from 22 to 18 is unidirectional and is used for the traffic coming from AS1 PE directed to the AS2 PE for destination network annouced by AS2PE.
From the AS2PE point of view there is no problem on the traffic forwarding (label 20 is imposed to the packet and this is the right behaviour) but AS2ASBR doesn't swap it with label 100192 because it is not in the mpls forwarding table. so i think that the problem is not on the PE but in the behaviour of the ASBR.
s.

Similar Messages

MPLS VPN without Signalling Protocol in CORE

Hi,
I heard its possible to run L3 MPLS VPN between two sites across SP core without having any Signalling protocol (TDP/LDP)enabled on the core,the only constraint is running two TE tunnels between the two PE routers connected to CE. Is it possible. Can someone explain elaborately, pls?

Some more details regarding the behavior as to why LDP/TDP is not required in case of end-to-end TE tunnel between the PE's.
Using TE also the LSP is dynamically built untill and unless you are using explicitly defined TE tunnels.
Also do note that when you have TE tunnels end to end your egress PE receives the packet with the VPN label only and then takes the appropriate action as per the VPN forwarding table.
In case you dont have end to end TE tunnels you will have to enable LDP on the tunnels to carry the VPN labels untouched till the egress PE.( As in case if the tunnels are not end to end and are terminating on a P' which doesnt have any VPN information the packet would be dropped, so enabling LDP becomes a must.)
Here is a detailed document explaining the beahaviour in more detail and explains when LDP should be enabled or disabled with illustrations.
http://www.cisco.com/en/US/tech/tk436/tk428/technologies_tech_note09186a0080125b01.shtml
HTH-Cheers,
Swaroop

MPLS VPNs - Latency

Hello All,
I have a MPLS VPN setup for one of my sites. We have a 10M pipe (Ethernet handoff) from the MPLS SP, and it is divided into 3 VRFs.
6M - Corp traffic
2M - VRF1
2M - VRF2
The users are facing lot of slowness while trying to access application on VRF1. I can see the utilization on the VRF1 is almost 60% of it's total capacity (2M). Yesterday when trying to ping across to the VRF1 Peer in the MPLS cloud, I was getting a Max response time of 930ms.
xxxxx#sh int FastEthernet0/3/0.1221
FastEthernet0/3/0.1221 is up, line protocol is up
Hardware is FastEthernet, address is 503d.e531.f9ed (bia 503d.e531.f9ed)
Description: xxxxx
Internet address is x.x.x.x/30
MTU 1500 bytes, BW 2000 Kbit, DLY 1000 usec,
     reliability 255/255, txload 71/255, rxload 151/255
Encapsulation 802.1Q Virtual LAN, Vlan ID 1221.
ARP type: ARPA, ARP Timeout 04:00:00
Last clearing of "show interface" counters never
I also see a lot of Output drops on the physical interface Fa0/3/0. Before going to the service provider, can you please tell me if this can be an issue with the way QoS is configured on these VRFs?
xxxxxxx#sh int FastEthernet0/3/0 | inc drops
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 3665
Appreciate your help.
Thanks
Mikey

Hi Kishore,
Thanks for the clarification. Let me speak to the service provider and see if we can sort out the Output drops issue.
I had a few more queries.
1) Will output drops also contribute to the latency here?
2) The show int fa0/3/0.1221 output below only shows the load on the physical interface (fa0/3/0) and not of that particuar interface.Right?
xxxxxx#sh int fa0/3/0.1221 | inc load
     reliability 255/255, txload 49/255, rxload 94/255
xxxxx#sh int fa0/3/0 | inc load
     reliability 255/255, txload 49/255, rxload 94/255
I can try and enable IP accounting on that sub-interface (VRF) and see the load. Thoughts?
3) As you said, if the 2M gets maxed out I would see latency as the shaper is getting fully utilized. But I don't see that on the interface load as mentioned above? I have pasted the ping response during the time load output was taken. I can;t read much into the policy map output, but does it talk anything about 2M being fully utilized and hence packets getting dropped.
xxxxxxx#ping vrf ABC x.x.x.x re 1000
Type escape sequence to abort.
Sending 1000, 100-byte ICMP Echos to x.x.x.x, timeout is 2 seconds:
Success rate is 99 percent (997/1000), round-trip min/avg/max = 12/216/1972 ms
xxxx#sh policy-map interface fa0/3/0.1221
FastEthernet0/3/0.1221
Service-policy output: ABC
    Class-map: class-default (match-any)
      114998 packets, 36909265 bytes
      5 minute offered rate 11000 bps, drop rate 0 bps
      Match: any
      Traffic Shaping
           Target/Average   Byte   Sustain   Excess    Interval Increment
             Rate           Limit bits/int bits/int (ms)      (bytes)
          2000000/2000000   12500 50000     50000     25        6250
        Adapt Queue     Packets   Bytes     Packets   Bytes     Shaping
        Active Depth                         Delayed   Delayed   Active
        -      0         114998    36909265 1667      2329112   no
Thanks
Mikey

MPLS Tags not appearing on one side of new MPLS VPN

I have an already existing 6509 that is going to provide the entire MPLS routing table via route reflector to a new 6509. Here are the relevant configs:
EXISTING 6509 (Router A)
interface Loopback0
ip address 10.255.2.2 255.255.255.255
end
router bgp 23532
no bgp default ipv4-unicast
bgp log-neighbor-changes
neighbor 10.255.2.3 remote-as 23532
neighbor 10.255.2.3 update-source Loopback0
address-family ipv4 mdt
neighbor 10.255.2.3 activate
neighbor 10.255.2.3 send-community extended
neighbor 10.255.2.3 route-reflector-client
neighbor 10.255.2.3 soft-reconfiguration inbound
exit-address-family
address-family vpnv4
neighbor 10.255.2.3 activate
neighbor 10.255.2.3 send-community extended
neighbor 10.255.2.3 route-reflector-client
neighbor 10.255.2.3 next-hop-self
bgp redistribute-internal
exit-address-family
address-family ipv4 vrf CustomerA
redistribute connected
redistribute static
no synchronization
bgp redistribute-internal
exit-address-family
DAL-COLO-6509-1#show mpls ldp neighbor 10.255.2.3
Peer LDP Ident: 10.255.2.3:0; Local LDP Ident 10.255.2.2:0
TCP connection: 10.255.2.3.16271 - 10.255.2.2.646
State: Oper; Msgs sent/rcvd: 647/646; Downstream
Up time: 06:07:30
LDP discovery sources:
Vlan65, Src IP addr: X.X.X.69
Addresses bound to peer LDP Ident:
10.255.2.3 X.X.X.69 X.X.X.254 10.10.1.31
DAL-COLO-6509-1#show mpls forwarding-table 10.255.2.3 detail
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
257 Pop Label 10.255.2.3/32 22272 Vl65 X.X.X.69
MAC/Encaps=14/14, MRU=1584, Label Stack{}
001CB14458000009B6A4B8008847
No output feature configured
DAL-COLO-6509-1#show mpls ldp bindings 10.255.2.3 32
lib entry: 10.255.2.3/32, rev 4933
local binding: label: 257
remote binding: lsr: 10.255.2.1:0, label: 131
remote binding: lsr: 10.255.2.3:0, label: imp-null
DAL-COLO-6509-1#traceroute 10.255.2.3
Type escape sequence to abort.
Tracing the route to 10.255.2.3
1 69-69.netblk-66-60-69.yada.net (X.X.X.69) 0 msec * 0 msec
DAL-COLO-6509-1#
New 6509 (Router B)
router bgp 23532
no bgp default ipv4-unicast
bgp log-neighbor-changes
neighbor 10.255.2.2 remote-as 23532
neighbor 10.255.2.2 update-source Loopback0
address-family ipv4 mdt
neighbor 10.255.2.2 activate
neighbor 10.255.2.2 send-community both
neighbor 10.255.2.2 soft-reconfiguration inbound
exit-address-family
address-family vpnv4
neighbor 10.255.2.2 activate
neighbor 10.255.2.2 send-community both
neighbor 10.255.2.2 next-hop-self
bgp redistribute-internal
exit-address-family
address-family ipv4 vrf CustomerA
redistribute connected
redistribute static
no synchronization
bgp redistribute-internal
exit-address-family
Br26-COLO-6509-1#show mpls ldp neighbor 10.255.2.2
Peer LDP Ident: 10.255.2.2:0; Local LDP Ident 10.255.2.3:0
TCP connection: 10.255.2.2.646 - 10.255.2.3.16271
State: Oper; Msgs sent/rcvd: 657/657; Downstream
Up time: 06:16:40
LDP discovery sources:
Vlan65, Src IP addr: X.X.X.70
Addresses bound to peer LDP Ident:
10.255.2.2 X.X.X.10 X.X.X.14 X.X.X.5
66.60.70.18 66.60.75.252 66.60.72.65 66.60.75.81
10.10.1.40 66.60.70.17 X.X.X.17 66.60.73.161
X.X.X.70
Br26-COLO-6509-1#show mpls forwarding-table 10.255.2.2 detail
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
40 Pop Label 10.255.2.2/32 0 Vl65 X.X.X.70
MAC/Encaps=14/14, MRU=1584, Label Stack{}
0009B6A4B800001CB14458008847
No output feature configured
Br26-COLO-6509-1#show mpls ldp bindings 10.255.2.2 32
lib entry: 10.255.2.2/32, rev 40
local binding: label: 40
remote binding: lsr: 10.10.1.30:0, label: 29
remote binding: lsr: 10.255.2.2:0, label: imp-null
Br26-COLO-6509-1#traceroute 10.255.2.2
Type escape sequence to abort.
Tracing the route to 10.255.2.2
1 70-69.netblk-66-60-69.yada.net (X.X.X.70) 0 msec * 0 msec
Br26-COLO-6509-1#
Im seeing label switching coming from the old switch (which has several MPLS VPN connections already). Im not seeing anything from the new switch. OSPF is the routing protocol between the interfaces, and shows to be working fine. LDP neighbor relationship seems to be good- just tagging isn’t occurring going back toward the old switch. Any suggestions?
Thanks
Greg

Yes- that is the problem we are trying to fix.
Br26-COLO-6509-1#sh ver
Cisco IOS Software, s72033_rp Software (s72033_rp-ADVENTERPRISEK9_WAN-M), Version 12.2(33)SXI13, RELEASE SOFTWARE (fc3)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2014 by Cisco Systems, Inc.
Compiled Tue 11-Mar-14 04:53 by prod_rel_team
ROM: System Bootstrap, Version 12.2(17r)SX5, RELEASE SOFTWARE (fc1)
Br26-COLO-6509-1 uptime is 1 day, 49 minutes
Uptime for this control processor is 1 day, 49 minutes
Time since Br26-COLO-6509-1 switched to active is 1 day, 48 minutes
System returned to ROM by reload at 09:20:45 CDT Wed May 7 2014 (SP by reload)
System restarted at 09:24:29 CDT Wed May 7 2014
System image file is "disk0:s72033-adventerprisek9_wan-mz.122-33.SXI13.bin"
Last reload reason: Reload Command
This product contains cryptographic features and is subject to United
States and local country laws governing import, export, transfer and
use. Delivery of Cisco cryptographic products does not imply
third-party authority to import, export, distribute or use encryption.
Importers, exporters, distributors and users are responsible for
compliance with U.S. and local country laws. By using this product you
agree to comply with applicable laws and regulations. If you are unable
to comply with U.S. and local laws, return this product immediately.
A summary of U.S. laws governing Cisco cryptographic products may be found at:
http://www.cisco.com/wwl/export/crypto/tool/stqrg.html
If you require further assistance please contact us by sending email to
[email protected].
cisco WS-C6509-E (R7000) processor (revision 1.3) with 458720K/65536K bytes of memory.
Processor board ID SMG1125N74N
SR71000 CPU at 600Mhz, Implementation 0x504, Rev 1.2, 512KB L2 Cache
Last reset from s/w reset
5 Virtual Ethernet interfaces
154 Gigabit Ethernet interfaces
1917K bytes of non-volatile configuration memory.
8192K bytes of packet buffer memory.
65536K bytes of Flash internal SIMM (Sector size 512K).
Configuration register is 0x2102
Yes- we do have a Sup7303B in this switch.

MPLS-VPN Label

In MPLS-VPN the forward of packets based on the LFIB tabel and the first label (NextHope)
label is advertised through the LDP and the second label (VPN label) is annouced via
MP-BGP, the problem is that when i check the FIB tabel of the customer VRF i can see both labels
but when i check the customer LFIB i did't see the second label=VPN!! so is that the VPN labels stors
only in the FIB and if right how is that while the forward always based on the LFIB
kindly advice
Router#show ip cef vrf cust det
10.10.44.0/30, version 1499, epoch 0, cached adjacency to Switch1.2
0 packets, 0 bytes
tag information set
local tag: VPN-route-head
fast tag rewrite with Sw1.2, point2point, tags imposed: {83 544}
via x.x.x.x, 0 dependencies, recursive
next hop x.x.x.x, Switch1.2 via x.x.x.x/32
Router#show tag for vrf cust
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
126 Untagged 10.10.52.8/29[V] 55708 Sw1.87 point2point
253 Untagged 10.10.52.4/30[V] 0 Sw1.87 point2point
263 Aggregate 10.10.52.0/30[V] 0
284 Untagged 10.230.52.0/22[V] 8616469838 Sw1.87 point2point

Hello,
the command "show mpls forwarding-table vrf cust" asks for a list of all locally assigned VPN labels! As the network 10.10.44.0/30 is learned via BGP, there is no locally assigned VPN label - hence it will not show up in the LFIB.
Another explanation would be: traffic towards 10.10.44.0/30 is received from the CE in the form of IP packets. So the PE has to perform an IP lookup and that means it is the FIB´s "business" to attach labels. LFIB has nothing to do with it. As you have seen the FIB however "knows" what to do, so everything is fine - cust is happy ;-)
Hope this helps! PLease rate all posts.
Regards, Martin

MPLS VPN / BGP Netflow Issue

I have followed all of the configuration steps given for egress accounting with netflow on a MPLS VPN link. However, it is only showing flows coming into the router. I need to be able to account both ways- any recommendations? Config below:
interface Multilink12
mtu 1580
ip address XX.XX.XX.XX 255.255.255.252
no ip redirects
no ip unreachables
ip pim sparse-mode
ip route-cache flow
mpls netflow egress
mpls label protocol ldp
mpls ip
ppp multilink
ppp multilink group 12
ip flow-export source FastEthernet0/0/0.10
ip flow-export version 5
ip flow-export destination XX.XX.XX.XX 9996
IP packet size distribution (10730093 total packets):
1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480
.000 .098 .645 .011 .016 .012 .009 .010 .000 .001 .000 .001 .000 .000 .000
512 544 576 1024 1536 2048 2560 3072 3584 4096 4608
.000 .000 .000 .002 .185 .000 .000 .000 .000 .000 .000
IP Flow Switching Cache, 4456704 bytes
4 active, 65532 inactive, 464700 added
6109192 ager polls, 0 flow alloc failures
Active flows timeout in 1 minutes
Inactive flows timeout in 15 seconds
IP Sub Flow Cache, 336520 bytes
0 active, 16384 inactive, 20706 added, 20706 added to flow
0 alloc failures, 0 force free
1 chunk, 1 chunk added
last clearing of statistics never
Protocol Total Flows Packets Bytes Packets Active(Sec) Idle(Sec)
-------- Flows /Sec /Flow /Pkt /Sec /Flow /Flow
TCP-Telnet 7 0.0 20 233 0.0 7.0 11.3
TCP-FTP 3 0.0 1 40 0.0 0.4 1.6
TCP-WWW 5757 0.0 6 389 0.0 1.1 3.0
TCP-SMTP 7 0.0 1 40 0.0 0.7 1.6
TCP-X 244 0.0 1 54 0.0 0.0 1.5
TCP-other 304762 0.2 7 346 1.6 2.2 4.8
UDP-DNS 346 0.0 1 127 0.0 0.0 15.4
UDP-NTP 3323 0.0 1 80 0.0 0.0 15.4
UDP-other 131041 0.0 62 341 5.4 17.6 13.2
ICMP 64291 0.0 1 79 0.0 0.0 15.4
Total: 509781 0.3 21 341 7.1 5.9 8.3
SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP DstP Pkts
Mu12 10.50.66.218 Null 10.105.0.1 11 0675 00A1 84
Mu12 10.50.66.218 Null 10.105.19.10 11 0675 00A1 2
Mu12 10.50.66.218 Null 10.105.19.3 11 0675 00A1 4
Mu12 10.50.66.42 Null 10.105.19.10 06 0B3C 01BD 12

Update on this- Im now receiving all traffic incoming into the interface, but am tracking only about 10% of the outgoing traffic- revised config below:
ip flow-cache timeout active 1
ip flow-cache mpls label-positions 1 2 3
ipv6 flow-cache mpls label-positions 1 2 3
interface Multilink12
mtu 1580
ip address XX.XX.XX.XX 255.255.255.252
no ip redirects
no ip unreachables
ip flow ingress
ip flow egress
ip pim sparse-mode
ip route-cache flow
mpls netflow egress
mpls label protocol ldp
mpls ip
ppp multilink
ppp multilink group 12
service-policy output cbwfq-voice20per
ip flow-export source FastEthernet0/0/0.10
ip flow-export version 9 origin-as
ip flow-export destination XX.XX.XX.XX 9996

Performance end to end testing and comparison between MPLS VPN and VPLS VPN

Hi,
I am student of MSc Network Security and as for my project which is " Comparison between MPLS L3 VPN and VPLS VPN, performance monitoring by end to end testing " I have heard a lot of buzz about VPLS as becoming NGN, I wanted to exppore that and produce a comparison report of which technology is better. To accomplish this I am using GNS3, with respect to the MPLS L3 VPN lab setup that is not a problem but I am stuck at the VPLS part how to setup that ? I have searched but unable to find any cost effective mean, even it is not possible in the university lab as we dont have 7600 series
I would appreciate any support, guidence, advice.
Thanks
Shahbaz

Hi Shahbaz,
I am not completely sure I understand your request.
MPLS VPN and VPLS are 2 technologies meant to address to different needs, L3 VPN as opposed as L2 VPN. Not completely sure how you would compare them in terms of performance. Would you compare the performance of a F1 racing car with a Rally racing car?
From the ISP point of view there is little difference (if we don't want to consider the specific inherent peculiarities of each technology) , as in the very basic scenarios we can boil down to the following basic operations for both:
Ingress PE impose 2 labels (at least)
Core Ps swap top most MPLS label
Egress PE removes last label exposing underlying packet or frame.
So whether the LSRs deal with underlying L2 frames or L3 IP packets there is no real difference in terms of performance (actually the P routers don't even notice any difference).
About simulators, I am not aware of anyone able to simulate a L2 VPN (AtoM or VPLS).
Riccardo

Centralize internet access in MPLS VPN

Can i implement Centralize internet access (the Hub CE Router to performs NAT) in cisco MPLS VPN solution?
If so, is there any example about that? i can't find it at CCO~
Thanks a lot~

If you run dynamic routing protocol in PE-CE,like rip2,ospf,bgp,do the following task.
1:set a default route in HUB CE;and generate the default route under its dynamic protocol.
2:in other CEs, make sure they can learn this route.
If you run static route and vrf static route between CE and PE,do the following task.
1.set default route in HUB CE, and set default route in other CEs.
2.In all PEs,redistribute the connected and static rotues to address-family ipv4 of customer vrf.
3.set the customer vrf default route in all PE which connected your all CEs.
Note: make sure all PEs can reach the GW address of vrf deafult route. GW IP address is the interface of which HUB CE towards PE.
command: "ip route vrf 0.0.0.0 0.0.0.0 global.
TRY

Selective Route Import/Export in MPLS VPN

Champs
I have multiple brach locations and 3 DC locations.DC locations host my internal applications , DC's also have central Internet breakout for the region. My requirement is to have full mesh MPLS-VPN but at same time brach location Internet access should be from nearest IDC in the region if nearest IDC is not availalbe it should go to second nearest DC for internet.I have decided which are primary and seconday DC for Internet breakout. How can this be achieved in MPLS-VPN scenario.Logically i feel , i have to announce specific LAN subnet and default route(with different BGP attribute like AS Path) from all 3 DCs. Spokes in the specific region should be able to import default route from primary DC and secondary DCs only using some route filter?
Regards
V

Hello Aaron,
the route example works for all routers except the one, where the VRF vpn2 is configured. What you can do for management purposes is either to connect through a neighbor router using packet leaking or configure another Loopback into VRF vpn2.
The last option (and my recommendation) is to establish another separate IP connection from your NMS to the MPLS core. Once VRFs are failing (for whatever reason, f.e. erroneously deleted) you might just not get connectivity to your backbone anymore to repair what went wrong.
So I would create an "interconnection router" with an interface in the VRF vpn2 and one interface in global IP routing table. This way you will still be able to access PEs, even if VRFs or MBGP is gone.
Hope this helps! Please rate all posts.
Regards, Martin

Ask the Expert:Concepts, Configuration and Troubleshooting Layer 2 MPLS VPN – Any Transport over MPLS (AToM)

With Vignesh R. P.
Welcome to the Cisco Support Community Ask the Expert conversation.This is an opportunity to learn and ask questions about concept, configuration and troubleshooting Layer 2 MPLS VPN - Any Transport over MPLS (AToM) with Vignesh R. P.
Cisco Any Transport over MPLS (AToM) is a solution for transporting Layer 2 packets over an MPLS backbone. It enables Service Providers to supply connectivity between customer sites with existing data link layer (Layer 2) networks via a single, integrated, packet-based network infrastructure: a Cisco MPLS network. Instead of using separate networks with network management environments, service providers can deliver Layer 2 connections over an MPLS backbone. AToM provides a common framework to encapsulate and transport supported Layer 2 traffic types over an MPLS network core.
Vignesh R. P. is a customer support engineer in the Cisco High Touch Technical Support center in Bangalore, India, supporting Cisco's major service provider customers in routing and MPLS technologies. His areas of expertise include routing, switching, and MPLS. Previously at Cisco he worked as a network consulting engineer for enterprise customers. He has been in the networking industry for 8 years and holds CCIE certification in the Routing & Switching and Service Provider tracks.
Remember to use the rating system to let Vignesh know if you have received an adequate response.
Vignesh might not be able to answer each question due to the volume expected during this event. Remember that you can continue the conversation on the Service Provider sub-community discussion forum shortly after the event. This event lasts through through September 21, 2012. Visit this forum often to view responses to your questions and the questions of other community members.

Hi Tenaro,
AToM stands for Any Transport over MPLS and it is Cisco's terminology used for Layer 2 MPLS VPN or Virtual Private Wire Service. It is basically a Layer 2 Point-to-Point Service. AToM basically supports various Layer 2 protocols like Ethernet, HDLC, PPP, ATM and Frame Relay.
The customer routers interconnect with the service provider routers at Layer 2. AToM eliminates the need for the legacy network from the service provider carrying these kinds of traffic and integrates this service into the MPLS network that already transports the MPLS VPN traffic.
AToM is an open standards-based architecture that uses the label switching architecture of MPLS and can be integrated into any network that is running MPLS. The advantage to the customer is that they do not need to change anything. Their routers that are connecting to the service provider routers can still use the same Layer 2 encapsulation type as before and do not need to run an IP routing protocol to the provider edge routers as in the MPLS VPN solution.
The service provider does not need to change anything on the provider (P) routers in the core of the MPLS network. The intelligence to support AToM sits entirely on the PE routers. The core label switching routers (LSRs) only switch labeled packets, whereas the edge LSRs impose and dispose of labels on the Layer 2 frames.
Whereas pseudowire is a connection between the PE routers and emulates a wire that is carrying Layer 2 frames. Pseudowires use tunneling. The Layer 2 frames are encapsulated into a labeled (MPLS) packet. The result is that the specific Layer 2 service—its operation and characteristics—is emulated across a Packet Switched Network.
Another technology that more or less achieves the result of AToM is L2TPV3. In the case of L2TPV3 Layer 2 frames are encapsulated into an IP packet instead of a labelled MPLS packet.
Hope the above explanation helps you. Kindly revert incase of further clarification required.
Thanks & Regards,
Vignesh R P

GRE with VRF on MPLS/VPN

Hi.
Backbone network is running MPLS/VPN.
I have one VRF (VRF-A) for client VPN network.
One requirement is to configure another VRF (VRF-B) for this client for a separate public VRF connection.
Sub-interfacing not allowed on CE-to-PE due to access provider limitation.
So GRE is our option.
CE config:
Note: CE is running on global. VRF-A is configured at PE.
But will add VRF-B here for the requirement.
interface Tunnel0
ip vrf forwarding VRF-B
ip address 10.12.25.22 255.255.255.252
tunnel source GigabitEthernet0/1
tunnel destination 10.12.0.133
PE1 config:
interface Tunnel0
ip vrf forwarding VRF-B
ip address 10.12.25.21 255.255.255.252
tunnel source Loopback133
tunnel destination 10.12.26.54
tunnel vrf VRF-A
Tunnel works and can ping point-to-point IP address.
CE LAN IP for VRF-B is configured as static route at PE1
PE1:
ip route vrf VRF-B 192.168.96.0 255.255.255.0 Tunnel0 10.12.25.22
But from PE2 which is directly connected to PE1 (MPLS/LDP running), connectivity doesnt works.
From PE2:
- I can ping tunnel0 interface of PE1
- I cant ping tunnel0 interface of CE
Routing is all good and present in the routing table.
From CE:
- I can ping any VRF-B loopback interface of PE1
- But not VRF-B loopback interfaces PE2 (even if routing is all good)
PE1/PE2 are 7600 SRC3/SRD6.
Any problem with 7600 on this?
Need comments/suggestions.

Hi Allan,
what is running between PE1 and PE2 ( what I mean is any routing protocol).
If No, then PE2 has no ways of knowing GRE tunnel IP prefixes and hence I suppose those will not be in its CEF table...
If Yes, then check are those Prefixes available in LDP table...
Regards,
Smitesh

Redundant access from MPLS VPN to global routing table

Several our customers have MPLS VPNs deployed over our infrastructure. Part of them requires access to Internet (global routing table in our case).
As I'm not aware of any methods how to dynamicaly import/export routes between VRF/Global routing tables, at the moment there are static routes configured - one inside VRF pointing to global next hop, another one in global routing table, pointing to interface inside VRF.
Task is to configure redundant access to Internet. By redundancy I mean using several exit points (primary and backup), what physically represents separate boxes.
Here comes tricky part - both global static routes (on both boxes, meaning) are valid and reachable in all cases - no matter if specific prefix is reachable in VRF or not. What I'd like to achieve is that specific static route becomes valid only if specific prefix is reachable inside VRF. Yea, sounds like dynamic routing :), I know
OK, hope U got the idea. Any solutions/recommendations ? Running all Internet routing inside VRF isn't an option, at least for now :(

Hi Andris,
I did not mean to have a VRF on the CE. The CE would have both PVCs in the global routing table - his ONLY routing table in fact. One PVC would be used to announce routes into the customer specific VPN (VRF configured on the PE). The other PVC would allow for internet access through the PE (global IP routing table on the PE).
dot1q will be ok as well.
This way the CE can be a normal BGP peer to the PE, i.e. there is no MPLS VPN involved here. This allows all options of customer-ISP connectivity.
Example:
PE config:
interface Serial0/0
encapsulation frame-relay
interface Serial0/0.1 point-to-point
description customer VPN access
ip vrf customer
ip address 10.1.1.1 255.255.255.252
interface Serial0/0.2 point-to-point
description customer Internet access
ip address 192.168.1.1 255.255.255.252
router rip
address-family ipv4 vrf customer
version 2
network 10.0.0.0
no auto-summary
redistribute bgp 65000 metric 5
router bgp 65000
neighbor 192.168.1.2 remote-as 65001
address-family ipv4 vrf customer
redistribute rip
CE config:
interface Serial0/0
encapsulation frame-relay
interface Serial0.1 point-to-point
description VPN access
ip address 10.1.1.2 255.255.255.252
interface Serial0.2 point-to-point
description Internet access
ip address 192.168.1.2 255.255.255.252
router bgp 65001
neighbor 192.168.1.1 remote-as 65000
router rip
version 2
network 10.0.0.0
no auto-summary
Of course you can replace RIP with whatever is suitable for you. And don´t sue me when you do not apply required BGP filters for internet access... ;-)
The other option ("mini internet") would be feasible as well. Just make sure your BGP filters are NEVER messed up and additionally apply a limit on the numbers of prefixes in your VRF mini-internet.
Regards
Martin

Managing Route-Map based MPLS VPN

1) How to derive the VPN information of the MPLS VPN configured using route-maps? As I understand, stitching route-maps information to derive VPN is complex as it is difficult to derive & correlate the filters tied to each of the route-maps that are tied to a VRF :(
2) Is there any MIB to get from the MIB
a) Route-maps tied to each VRF
b) What is the filter associated with each route-map?
c) Definition of each of the above filter
It would have been nice if the route-maps' name had global-significance within AS, so that we could have treated route-maps, pretty much like the route-tragets. Alas, I doubt it is :(
It should be noted here that if the MPLS VPN is configured using route targets, the VPN information derivation is fairly straight forward throught MplsVpn MIB.
So, the question is what is the simplest way to derive the MPLS VPN info given that they are configured using route-maps in BGP for labelled-route-distribution & for the pkt association with the VRFs.
Thanks,
Suresh R

Each CE in a customer VPN is also added to the management VPN by selecting the Join the management VPN option in the service request user interface.
The function of the management route map is to allow only the routes to the specific CE into the management VPN. The Cisco IOS supports only one export route map and one import route map per VRF.
http://www.cisco.com/en/US/products/sw/netmgtsw/ps4748/products_user_guide_chapter09186a0080353ac3.html

Overlapping addresses in MPLS VPN

I know that you can have overlapping addresses in a MPLS VPN and that route distiguisher is used for distiguishing them, by converting IPv4 to VPNv4.
My question is that if an IP range of a Branch A overlapps with IP range of branch B of the same VPN, How could a host in Branch A ping any host in Branch B, if they are in a same subnet? I mean, how could the router (CE) know to forward it to PE ? if the range is directly connected (to CE).
I will apreciate any help

Within a VPN the normal IP routing rules apply, eg. if you have 2 networks that overlap within a VPN you need to use NAT in one of the CE routers.
Hth,
Niels

Mapping Model in MPLS VPNs

Hi:
Based on paper titled "L3 MPLS VPN Enterprise Consumer Guide" page 52, figure 44. (http://www.cisco.com/en/US/partner/netsol/ns465/networking_solutions_white_papers_list.html).
1) The figure discards the "streaming video" and "bulk data" traffics within the mapping process. Why? What happens with these traffics? Both traffics are discarded or simply they need to be mapped to "Best Effort"? Please explain.
2)In the same figure, "Interactive Video" is mapped to "Realtime" SP class with "Voice" traffic. Is this "Interactive Video" traffic always no TCP-based? If the opposite is true, why is it mixing TCP & UDP over the same "Realtime" class?

Hi,
That articles mentions that these protocols tend to use transport-layer protocols such as UDP and RTSP. That is true but there are a lot of different streaming protocols around and some of them do use TCP. In fact, even RTSP supports the use of TCP. And you can also stream via HTTP (Windows Media supports this, for example).
So you see, there can be a mix of TCP and UDP traffic here.
The other, more critical, reason for not mixing interactive-traffic with streaming (one-way) traffic is the drastically different jitter/latency requirements for the two. Streaming traffic will easily sustain latency in the order of seconds and jitter is not even a problem. Whereas interactive traffic will not. That is why you should not mix the two.
Hope that helps - pls rate the post if it does.
Paresh

Interprovider MPLS VPN - "drop -- rewrite null"

Similar Messages

Maybe you are looking for