MPLS VPN L3 BGP to Customer CPE

Hello,
I am learning how to setup MPLS VPN L3. I am running OSPF in the MPLS Core and have configured MP-BGP between PE. I am running BGP between the PE and CPE in my lab, and I can see redistributed routes from the CPE in the vrf routing table for that customer on the PE router. My question is how to reditribute the vrf routes into my MPLS core to transmit the traffic to the customer other site on the same vpn. Below is what my config looks like.
PE
ip vrf customerA
rd 100:101
route-target export both 100:1000
int fa0/0
ip vrf forwarding customerA
ip address x.x.x.x x.x.x.x
router ospf 1
loopback in area0
networks in area0
router bgp 65000
neighbor to other PE routers in AS 65000 (MPLS Network)
address family vpn4
neighbor other PE routers activate
neighbor other PE routers send community
ip address ipv4 vrf customerA
neighbor to customerA in AS 55000
CPE
router ospf 1
loopback in area 0
networks in area 0
router bgp 55000
neighbor to PE router in AS 65000
redistribute ospf 1

Hi
You dont have to redistribute your routes into mpls core. The vpnv4 bgp session that you have has already sent your ce routes to the remote pe router, provided you have the vrf configured on the other end.
For more detaiked explanation please check a presentation available in the current running Ask The Expert event in the support community.

Similar Messages

RIP Between CPE & PE in a MPLS VPN

When RIP is used as the dynamic routing protocol between dual homed CPE and PE in a MPLS VPN scenario with a backdoor link, there are chances of loops occurring and traffic transiting low bandwidth links. What precautions or actions can be taken to prevent these behaviors with RIP?
               CPE
                  |
CPE-------PE---P
    |                      |
CPE-------PE---P
                 |
              CPE

Hi,
When you redistribute the MP-BGP routes into RIP on PE, you have an option of specifying the metric with which RIP redistributes the routes. You can make use of this feature, set the RIP metric accordingly while you redistribute the RIP of remote CE location into local CE location. Also make the metric over the backdoor link less or more preferrable (whichever way you opt for) with offset list on that specific interface. By this way local CE receives updates with two different metric (one over MPLS provider and other over backdoor link) and the one with least metric is preferred.
Also you have to stop advertising the LAN prefixes of remote CE router to unwanted interfaces by using distribute list command. This can be done on the interface of CE connecting to PE routers where distribute list contains LAN of remote CE locations. Though split horizon stops advertising I am bit skeptical about the prefixes with different metrics works with split horizon.
If the backdoor is TDM or the ethernet link where physical layer is going down on Layer 1 issues, then better option is to have static routing with higher/lower AD than RIP over backdoor link. There is no chance of looping in this case and you have better control.
HTH
Arun

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

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

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

L3-MPLS VPN Convergence

Perhaps someone on this group can identify the missing timers/processing-delays in end-to-end client route convergence
Scenarios:
a) BGP New route Advertised by Cleint(CPE1)
b) BGP Route withdrawn by Client(CPE1)
PE-to-RR i-M-BGP (Logical)
========= ----RR------ ======
" | | "
CPE1---->PE1------->P1-------->P2---->PE2----->CPE2
| |
--------->P3-------->P4-------
Routing:
- eBGP btw CPE and PE (any routing prot within Cust site),
- OSPF, LDP in Core,
Timers/Steps I'm aware of:
- Advertisement of routes from CE to PE and placement into VRF
- Propagation of routes across the MPLS VPN backbone
- Import process of these routes into relevant VRFs
- Advertisement of VRF routes to attached VPN sites
- BGP advertisement-interval: Default = 5 seconds for iBGP, 30 for eBGP
- BGP Import Process: Default = 15 seconds
- BGP Scanner Process Default = 60 seconds
Would appreciate if you someone can identify any missing process-delay, timers? specially w.r.t RR.
Thanks
SH

Check the LDP/TDP timers in the core. Remember if a link fails in the core, reroute occurs, LDP/TDP binding needs to be renewed. tags are binded on those routes being in the routing table (IGP). So, there is a delay possible from a core prespective:
mpls ldp holdtime
mpls ldp discovery hello [holdtime | interval]
In case you are using TE check these:
mpls traffic-eng topology holddown
mpls traffic-eng signalling forwarding sync
mpls traffic-eng fast-reroute timers promotion
I believe the latter one onyl applies to SDH. In which you use segment loss feature.
Regards,
Frank

Implemting a Sprint MPLS/VPN

Hello
I'm implmenting a Sprint MPLS/VPN network. This is a point to point between two of my locations. The connection is handed of to me as a serial connection and I will be connecting to cisco 2800 on bothe ends. Does anyone have what a sample config might look like for my Cisco rotuer?
Thanks in advance

HI, [Pls Rate if HELPS]
In addition to JOE POST,
You need to configure as normal CE Router. You can handover your Network Traffic either via some DYNAMIC Routing Protocols (BGP, EIGRP, OSPF, RIP) or Static Routing at LAST MILE towards your Service Provider.
At the Service Provider Side, the Connected Interface with your CE will be added with "ip vrf forwarding " command. Where seperate Routing instance will be maintained on top of Global Routing Table. The MPLS Labels are swapped over their Backbone / partner - NNI to carry your traffic over a Label Switched Path.
For an MPLS to work, the IP-CEF will be enabled. This kind of MPLS Technology, will enable fast processing of Packets and Traffic over the Large Scale Network.
Similarly the RT & RD Values are used to distinguish the Customer Prefixes. The RT export and Import will be done at end - to - end at Service Provider Side Routers to make the HO & BO to communicate.
The CE Router will not involve any MPLS / VRF Configuration Technology.
Hope I am Informative.
Pls Rate if HELPS
Best Regards,
Guru Prasad R

Central Site Internet Connectivity for MPLS VPN User

What are the solutions of Central site Internet connectivity for a MPLS VPN user, and what is the best practice?

Hello,
Since you mentioned that Internet Access should be through a central site, it is clear that all customer sites (except the central) will somehow have a default (static/dynamic) to reach the central site via the normal VPN path for unknown destinations. Any firewall that might be needed, would be placed at the central site (at least). So, the issue is how the central site accesses the Internet.
Various methods exist to provide Internet Access to an MPLS VPN. I am not sure if any one of them is considered the best. Each method has its pros and cons, and since you have to balance various factors, those factors might conflict at some point. It is hard to get simplicity, optimal routing, maximum degree of security (no matter how you define "security"), reduced memory demands and cover any other special requirements (such as possibility for overlapping between customer addresses) from a single solution. Probably the most secure VPN is the one which is not open to the Internet. If you open it to the Internet, some holes also open inevitably.
One method is to create a separate Internet_Access VPN and have other VPNs create an extranet with that Internet_Access VPN. This method is said to be very secure (at least in terms of backbone exposure). However, if full routing is a requirement, the increased memory demands of this solution might lead you to prefer to keep the internet routing table in the Global Routing Table (GRT). You might have full routing in the GRT of PEs and Ps or in PEs only (second is probably better).
Some names for solutions that exist are: static default routing, dynamic default routing, separate BGP session between PE and CE (via separate interface, subinterface or tunnel), extranet with internet VRF (mentioned earlier), extranet with internet VRF + VRF-aware NAT.
The choice will depend on the requirements of your environment. I cannot possibly describe all methods here and I do not know of a public document that does. If you need an analysis of MPLS VPN security, you may want to take a look at Michael Behringer's great book with M.Morrow "MPLS VPN Security". Another book that describes solutions is "MPLS and VPN Architectures" by Ivan Pepelnjak. There is a Networkers session on MPLS VPNs that lists solutions. There is also a relevant document in CCO:
http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a00801445fb.shtml (covering static default routing option).
Kind Regards,
M.

Injecting Global default Routes into a MPLS VPN

Hi,
I have a PE router running MPBGP which receives two default routes to the internet through an IPV4 BGP session. I need to import these routes in to a VRF and export them to different customer VRFs so that these VRFs are able to access Internet.
I have used the feature called "BGP Support for IP Prefix Import from Global Table into a VRF Table" (URL:http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_feature_guide09186a00803b8db9.html#wp1063870)
and imported these routes into a VRF.
The issue is these routes are not propagated to any of the other PE routers which has customer VRFs configured.
Has anybody tried this or a similar method to inject a dynamic default route into a MPLS VPN.
Any suggestions would be highly appreciated.
Thanks
Subhash

Hi Subhash,
is there anything preventing you from terminating your internet BGP sessions in a VRF? Then everything should go smoothly, i.e. standard VRF import/export.
So possibility A) create a VRF Internet, move bgp neighbor commands there and use filters preventing anything but the default route, then use route targets to distribute the default route into other VRFs.
Possibility B) use static routing with packet leaking. Could look like this:
ip route vrf Internet 0.0.0.0 0.0.0.0 global
ip route vrf Internet 0.0.0.0 0.0.0.0 global 250
ip route Serial0/0 !assuming this is where the customer router connects.
Note: the BGP peer IP does not have to be directly connected! There has to be a LDP label for it though. so include your BGP peers network into your IGP and the backup will work, when you loose the link to the peer.
Hope this helps! Please rate all posts.
Regards, Martin

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

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

How can I find the all path available for a MPLS VPN in SP network

How can I find the all path available for a MPLS VPN in SP network between PE to PE and CE to CE?

Hi There
If we need to find all the available paths for a remote CE from a local PE it will depend upon whether its a RR or non-RR design. If the MP-iBGP deisgn is non-RR the below vrf specific command
sh ip bgp vpnv4 vrf "vrf_name" will show us the MP-iBGP RT for that particular VPN. It will show us the next hop. Checking the route for same in the Global RT will show us the path(s) available for same ( load-balancing considered) .Then we can do a trace using the Local PE MP-iBGP loopback as source to remote PE's MP-iBGP loopback to get the physical Hops involved.
However if the design is RR-based there might be complications involved when the RR is in the forwarding path ie we have NHS being set to RR-MP-iBGP loopback and the trace using the Local PE MP-iBGP loopback as source to remote PE's MP-iBGP loopback will get us the physical Hops involved.
If we have redundant RRs being used with NHS being set then the output of sh ip bgp vpnv4 vrf "vrf_name" will show us two different available paths for the remote CE destination but just one being used.
RR-based design with no NHS being used will always to cater to single path for the remote CE detsination.
So in any case the actual path used for the remote CE connectivity would be a single unless we are using load-balancing.
Hope this helps you a bit on your requirement
Thanks & Regards
Vaibhava Varma

MPLS VPN L3 BGP to Customer CPE

Similar Messages

Maybe you are looking for