Equipment Support > Hardware By Brand > Cisco > MPLS VPN

MPLS VPN

As to the first question, no, not with an L3 MPLS VPN. however if you setup EPLS (pseudowire crossconnects), VPLS (vfi crossconnects), you can deliver devices on the same subnet across an MPLS wan. However this requires real high end equipment (think 7600s or GSR12400s)

As to the second question, there are ALOT of ways to deliver internet service into an L3 MPLS VPN. I would go with one of the following:
1) per-vpn firewall contexts on a separate security device (asa/fwsm). this is how major providers would go about doing it.
2) per-vpn nat pool with internet in the global routing table, i can provide a config example if u want to go this direction.
Remember that both of these approaches need to be done on a PE router rather than a P router. (PE vs PCORE) as the p-cores have no knowledge of VPNs or customer routing/bridging other than the outer most labels (transport labels) in the stack.

Anyways, I build MPLS aware services relatively often so if you have any specific questions i can certainly help.
The easiest thing might be for you to zip up txt files of all your running configs and we can have a conversation with more specific configuration examples.

Good luck, have fun, mpls is wonderful stuff!

Im going to spend some time reading into your config more when i have time.
Below is a config example, but as i said before, its for a PE and there are MANY different ways to accomplish this kind of thing. It really depends on how many customers you have, and how complex their networks are, and if there is a good deal of address space overlap etc.

ip vrf cust1
 rd 1:1
 route-target export 1:1
 route-target import 1:1
 
ip vrf cust2
 rd 1:2
 route-target export 1:2
 route-target import 1:2
 
ip vrf cust3
 rd 1:3
 route-target export 1:3
 route-target import 1:3
 
ip vrf services
 rd 65000:1
 route-target export 65000:1
 route-target import 65000:1
 
interface FastEthernet0/0.3
 ip vrf forwarding services
 ip nat enable
 no ip route-cache
 
interface FastEthernet0/0.210
 encapsulation dot1Q 210
 ip vrf forwarding cust1
 ip address 10.3.210.1 255.255.255.0
 ip nat enable
 no ip route-cache
 
interface FastEthernet0/0.220
 encapsulation dot1Q 220
 ip vrf forwarding cust2
 ip address 10.3.220.1 255.255.255.0
 ip nat enable
 no ip route-cache
 
ip route vrf cust1 0.0.0.0 0.0.0.0 FastEthernet0/0.3 10.3.0.1
ip route vrf cust2 0.0.0.0 0.0.0.0 FastEthernet0/0.3 10.3.0.1
ip route vrf services 0.0.0.0 0.0.0.0 10.3.0.1
 
ip nat pool NAT 10.3.0.61 10.3.0.61 netmask 255.255.255.0
 
ip nat source list 1 pool NAT vrf cust1 overload
ip nat source list 1 pool NAT vrf cust2 overload
 
access-list 1 permit 10.3.210.0 0.0.0.255
access-list 1 permit 10.3.220.0 0.0.0.255
 

show mpls l2transport hw-capability interface $INTERFACE
 

Great! No rush... when ever you get the chance to look over the configs it would be greatly appreciated!

Thanks

I do have two real quick questions that arent so related to MPLS VPN so much as P/PE functionality.

Why do you have network 0.0.0.0 255.255.255.255 in the OSPF config? Usually I just throw "ip ospf 1 area 0" on loopbacks and transits. This is useful as point to point interfaces are frequently unnumbered (as to not waste transit /30s and keep track of them all)

The loopbacks in BGP
network 1.1.1.1 mask 255.255.255.255
network 1.1.1.2 mask 255.255.255.255
network 1.1.1.3 mask 255.255.255.255
network 1.1.1.4 mask 255.255.255.255
are also questionable. If they are in OSPF, you could accidentally cause a loop in the event of an equipment failure or outage. They shouldnt be in the BGP table, ospf will be responsible for the routing table to share TE information. BGP doesnt participate in TE.

Always double check that your neighbors send-community both. some say extended.

Also, quick reminder, the default route should only be installed in a VRFs routing table, not the global. Global should only contain transit/loopbacks of LSRs. Most IOS will not install a label for the default route by default so any packets without a specific prefix to another known LSR (if the IGP P/PE topology doesnt match on all the LSRs) you may get IP routing rather than label switching and blackholed traffic due to broken label switch path.

For every VRF you may want to assign two (or more) route-targets. This is done by most providers incase you ever need to build a hub/spoke topology for a VPN or extranet/leak selectively between VPNs.

You will want to change "mpls ldp router-id Loopback0" to "mpls ldp router-id Loopback0 force". Sometimes IOS is just flakey about that ID and its not easy to clear the LDP process.

Again, to run the nat virtual interface (NVI) "ip nat enable" stuff above, you will need to create per VRF address-families on the 3725 and turn it into a full PE even if there are no actual interfaces in a VRF. You will just be redistributing static and adding default routes for those VPNs. Remember that on lower end platforms performing vrf-aware nat may cause soft-switching of packets so I wouldnt count on great performance. I would really suggest installing a pair of ASA 5520's or better in multicontext mode, using a fast ethernet or gigabit ethernet interface and tagging subinterfaces in different VPNs forced through different contexts to reach the internet.

Ill provide more config when i get a chance at work today.

reply to Need BB

reply to nosx

I havent seen a same-broadcast-domain connection across an mpls cloud outside of L2 VPN's. Can you give an example?

He did post the configs: Project_configs.zip 4,675 bytes
Router Configs

OSPF is the gold standard for MPLS deployments worldwide. I have yet to see a live deployment using IS-IS, and when you talk about operational support, OSPF knowledge is much more prevalent.
Dont use statics because OSPF carries metrics that are copied into BGP MED as well as adding the possibility of future TE and easy network expansion.

This is how I have seen network-facing interfaces configured:

interface Loopback0
 ip address X.X.X.6 255.255.255.255
 ip ospf 1 area 0
!
interface POS0/0/1
 ip unnumbered Loopback0
 ip ospf 1 area 0
 mpls ip
!
router ospf 1
 log-adjacency-changes
!
mpls ldp router-id Loopback0 force
!
router bgp 123
 bgp always-compare-med
 no bgp default ipv4-unicast
 bgp log-neighbor-changes
 bgp deterministic-med
 bgp dynamic-med-interval 60
 timers bgp 7 21
 neighbor PEER_RR peer-group
 neighbor PEER_RR remote-as 123
 neighbor PEER_RR update-source Loopback0
 neighbor Y.Y.Y.4 peer-group PEER_RR
 !
 address-family vpnv4
  neighbor PEER_RR send-community both
  neighbor Y.Y.Y.4 activate
  bgp scan-time 15
 exit-address-family
 !
 

This info is great. I will give it a try and see what I come up with!

Thanks

Can you send me the config for the internet gateway 3725?

and actually, if you have a terminal server in your lab or some other way for me to telnet or ssh into the equipment id love to take a look at it a little deeper.

That is the issue I don't have any configs for the 3725. I have a single DHCP IP to the Inerent from outside the lab and want to redistribute this into the lab network.

The 3725 config is the same as before except I changed some of the stuff that was suggested. Here is the current config:

version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Router3725.1
!
boot-start-marker
boot-end-marker
!
no aaa new-model
memory-size iomem 5
ip cef
!
mpls label protocol ldp
multilink bundle-name authenticated
!
!
archive
log config
hidekeys
!
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
ip ospf 1 area 0
!
interface FastEthernet0/0
ip address 10.1.1.1 255.255.0.0
ip ospf 1 area 0
speed 100
full-duplex
mpls ip
!
interface Serial0/0
ip address 10.2.1.1 255.255.0.0
ip ospf 1 area 0
mpls ip
clock rate 2000000
!
interface FastEthernet0/1
ip address 10.100.1.1 255.255.0.0
ip ospf 1 area 0
speed 100
full-duplex
mpls ip
!
interface Serial0/1
ip address 10.101.1.1 255.255.0.0
ip ospf 1 area 0
mpls ip
clock rate 2000000
!
interface FastEthernet1/0
ip address dhcp
speed 100
full-duplex
!
router ospf 1
log-adjacency-changes
!
router bgp 100
no synchronization
bgp cluster-id 1
bgp log-neighbor-changes
neighbor PE peer-group
neighbor PE remote-as 100
neighbor PE update-source Loopback0
neighbor PE route-reflector-client
neighbor PE send-community both
neighbor PE send-label
neighbor 1.1.1.2 remote-as 100
neighbor 1.1.1.2 update-source Loopback0
neighbor 1.1.1.2 send-community both
neighbor 1.1.1.2 send-label
neighbor 1.1.1.3 peer-group PE
neighbor 1.1.1.4 peer-group PE
no auto-summary
!
address-family vpnv4
neighbor PE send-community both
neighbor PE route-reflector-client
neighbor 1.1.1.2 activate
neighbor 1.1.1.2 send-community both
neighbor 1.1.1.3 activate
neighbor 1.1.1.4 activate
exit-address-family
!
ip forward-protocol nd
!
ip http server
no ip http secure-server
!
!
mpls ldp router-id Loopback0 force
!
!
control-plane
!
!
line con 0
exec-timeout 0 0
line aux 0
line vty 0 4
login
!
!
end
--
AWD Turbo Power

I have never attempted NVI config on a non-edge router without an interface that was a member of a customer VRF. Also I have never done interface nat with NVIs (only POOL) for outbound internet connections. This config is a best guess thats untested and might require tweeking and troubleshooting:

 
conf t
 
ip vrf VRF_SERVICES
  rd 1.1.1.1:999
  route-target export 100:999
  route-target import 100:999
 exit
ip vrf Business1
  rd 1.1.1.1:1
  route-target export 100:1
  route-target import 100:1
 exit
 
int fa1/0
  ip vrf forwarding VRF_SERVICES
  no ip dhcp client request dns-nameserver
  no ip dhcp client request static-route
  ip address dhcp
  ip nat enable   
  no ip route-cache
 exit
 
int loop101
 !This is a failsafe loop int for testing to turn
 !this router into a PE with Customer facing interfaces.
  ip vrf forwarding Business1
  ip address 192.168.255.1 255.255.255.255
  ip nat enable
  no shut
 exit
 
ip route vrf Business1 0.0.0.0 0.0.0.0 FastEthernet1/0 DHCP
ip route vrf VRF_SERVICES 0.0.0.0 0.0.0.0 FastEthernet1/0 DHCP
 
ip nat source list 1 interface FastEthernet1/0 vrf Business1 overload
 
access-list 1 permit 192.168.100.0 0.0.0.255   
access-list 1 permit 192.168.200.0 0.0.0.255  
access-list 1 permit 192.168.255.0 0.0.0.255  
 
router bgp 100
  address-family ipv4 vrf Business1
    redistribute static
    redistribute connected
    no auto-summary
    no synchronization
   exit-address-family
 exit
end
 

reply to Need BB

Its one of the valid ways to provide internet service to your VPN customers. When you do so, it basically turns whatever router INTO a PE because you have to run mp-bgp and define VRFs and routing for your customers VPNs.
Like we discussed above, a better solution is to hairpin through a multicontext firewall (much more common setup) but the nat virtual interface (NVI) stuff is still prevalent to be on the CCIE service provider lab so its out there too.

How involved you are in your customers routing depends greatly on what kind of business you are in. Verizon or ATT woudnt do this kind of trickery, but a small managed services centric service provider with only a couple POPs might do this for some customers. Its a cheap (as in no capital expense) way to charge your customers for more service.

I am understanding the MPLS architecture much better now. So it would be best to have the Internet connected to the 2650XM PE router. The issue is that the 2650XM only have one WAN port which will connect to the core 3725 routers. The 2650XM also has the 16ESW switching module but I don't think this card is routable. I did read that you can route using VLAN trunking, but this wouldn't allow an external connection to the Internet. It seems that the existing hardware is limiting how I setup and configure the devices.
--
AWD Turbo Power

I would home the internet connection into an existing PE router.

I would also make sure that any route reflectors are NOT in the traffic path from one PE to another.

Segmenting the role of PCORE, PE, and RR are important.
The PCORE routers should not participate in BGP at all, they have no need to. Their primary responsability is to forward MPLS frames by outer-most transit label. The intelligence should reside on the PE for BGP and customer routing, as well as LSP construction and selection.
The route-reflectors might hang off a PCORE but shouldnt participate in MPLS, and when their links are configured steps should be taken (very high interface IGP/OSPF costs) to make sure that they dont become transit paths for traffic transversing the cloud.

Making sure that you have a solid architectural foundation ensures that when your network grows (and all do eventually) that it doesnt become unmanagable or difficult to support and maintain.

Also, a good practice for numbering things like RD's is to use the devices loopback : unique number per PE.
This makes troubleshooting routing across the cloud simpler (you can instantly tell which PE the originating VRF is on) as well as ensure that RDs remain unique across the cloud.

Make sure that you dont accidentally install a default route in the global routing table. MPLS likes explicit paths to a PE. If there is an IGP screwup, and you lose a path to a PE loopback, you dont want to blackhole the traffic out a default ipv4 route in the global table. Make sure any default routes are in VRF routing instances only.