INE Workbook Vol 1 MPLS

Finally on to MPLS, which is the last section of Volume 1. I skipped Bridging/switching so I will need to return to that before moving on to full labs. Hopefully I can tackle both MPLS and bridging/switching this week.

The route distinguisher (RD) is a special 64-bit prefix prepended to every route in the respective VRF routing table. This avoid collisions if two VRFs contain the same prefixes. It is possible to use static routes for 'inter-VRF' communications. If you are using a static route with the interface specification, the interface could belong to any VRF. With multi-access interfaces, you will also need to specify the next-hop associated with the interface. Cisco IOS will install a CEF entry in the 'source' VRF using the information provided and will not attempt to resolve the next-hop recursively. This only works with non-recursive static routes that use directly connected interfaces.


ip vrf VPN_A
 rd 100:1
ip vrf VPN_B
 rd 100:2
interface FastEthernet0/0.67
 encapsulation dot1Q 67
 ip vrf forwarding VPN_A
 ip address 155.1.67.6 255.255.255.0
interface FastEthernet0/0.76
 encapsulation dot1Q 76
 ip vrf forwarding VPN_B
 ip address 155.1.76.6 255.255.255.0
ip route vrf VPN_A 192.168.7.0 255.255.255.0 FastEthernet0/0.76 155.1.76.7
ip route vrf VPN_B 172.16.7.0 255.255.255.0 FastEthernet0/0.67 155.1.67.7

'mpls ldp autoconfig' will activate LDP/MPLS switching on all interfaces running OSPF. You can set the LDP router-id using the command 'mpls ldp router-id force'. If you want LDP to establish a TCP connection using the physical interface IP address, use the interface command 'mpls ldp discovery transport-address interface) command. LDP neighbor sessions can be authenticated using the 'mpls ldp neighbor password command. The IP address here is the LDP router-id. To make passwords mandatory, issue 'mpls ldp password required'. 

Sham links must NOT be advertised by BGP and should instead be advertised by MP-BGP. When using OSPF as the PE-CE routing protocol, area 0 is not needed because OSPF VRF routing information is passed in MP-BGP updates. The MP-BGP cloud is a special 'super backbone'.

On to EIGRP SOO...in short, this prevents MP-BGP routes from re-entering BGP when mutual redistribution between EIGRP/MP-BGP is present with backup links. If an incoming or outgoing update has the SoO value matching the locally configured one, the updated is dropped. Here are the PE configs.

R5

interface FastEthernet0/0
 ip vrf forwarding VPN_A
 ip vrf sitemap EIGRP_SOO
 ip address 155.1.58.5 255.255.255.0
route-map EIGRP_SOO permit 10
 set extcommunity soo 100:15


R6

interface FastEthernet0/0.67
 encapsulation dot1Q 67
 ip vrf forwarding VPN_A
 ip vrf sitemap EIGRP_SOO
 ip address 155.1.67.6 255.255.255.0
route-map EIGRP_SOO permit 10
 set extcommunity soo 100:16


We create the simple route-map and attach it to the CE facing interfaces. Now on the CE side, we attach the same to the backup-link configuration. SW1 is attached to R6 and SW2 is attached to R5.

SW1

interface FastEthernet1/7
 no switchport
 ip vrf sitemap EIGRP_SOO
 ip address 155.1.78.7 255.255.255.0
 delay 1000
route-map EIGRP_SOO permit 10
 set extcommunity soo 100:16

SW2

interface FastEthernet1/7
 no switchport
 ip vrf sitemap EIGRP_SOO
 ip address 155.1.78.8 255.255.255.0
 delay 1000
route-map EIGRP_SOO permit 10
 set extcommunity soo 100:15


When using BGP as your PE-CE routing protocol, you may be required to use as-override if both CE routers are using the same AS. When the PE router gets the routes from the CE router, they won't get installed in the other CE router because it will see it's own AS in the path across a e-BGP neighbor relationship. With AS-override, the CE AS will be replaced with the MPLS 'core' AS and thus installed in the BGP/RIB. 


We can also use SoO with BGP peering. Simply attach the SoO attribute to the neighbor statements on each PE. 


Internet Access with MPLS is interesting. The VPN clients will need a default route. In this case (with the global routing table), we need to create a special static pointing the default route to the global routing table. If Internet access is in a different VRF, classic route export/import could be used. 


ip route vrf VPN_A 0.0.0.0 0.0.0.0 54.1.1.254 global

Then we need to originate the default route to our VPN clients - in this case via BGP.

router bgp 456

address-family ipv4 vrf VPN_A
  redistribute connected
  redistribute static
  neighbor 155.1.67.7 remote-as 78
  neighbor 155.1.67.7 activate
  neighbor 155.1.67.7 as-override
  neighbor 155.1.67.7 soo 100:1
  default-information originate
  no synchronization

Now since we are doing private addressing, we need to do NAT.


interface FastEthernet0/0.67
 ip vrf forwarding VPN_A
 ip address 155.1.67.6 255.255.255.0
 ip nat inside
 ip virtual-reassembly
interface FastEthernet0/0.146
 ip address 155.1.146.6 255.255.255.0
 ip nat inside
 ip virtual-reassembly
interface Serial0/0
 ip address 54.1.1.6 255.255.255.0
 ip nat outside
 ip virtual-reassembly
ip nat inside source list VPN_PREFIXES interface Serial0/0 vrf VPN_A overload
ip access-list standard VPN_PREFIXES
 permit 150.1.0.0 0.0.255.255


Notice the vrf keyword in the NAT statement. This ties the NAT statement to the sources addresses in that particular VRF (as there could be several VRF's with overlapping address space).

AToM is a pretty simple concept. It takes the L2 frames and encapsulates them over MPLS. The VCs must match, and you may need to provide LDP neighbor password parameters.


R5(config)#do sh run int fa0/1
interface FastEthernet0/1
 no ip address
 duplex auto
 speed auto
 xconnect 150.1.6.6 100 encapsulation mpls



R6(config)#do sh run int fa0/1
interface FastEthernet0/1
 no ip address
 duplex auto
 speed auto
 xconnect 150.1.5.5 100 encapsulation mpls


Verify with 'show mpls l2transport vc detail'



R6(config)#do sh mpls l2tra vc det
Local interface: Fa0/1 up, line protocol up, Ethernet up
  Destination address: 150.1.5.5, VC ID: 100, VC status: up
    Next hop: 155.1.146.4
    Output interface: Fa0/0.146, imposed label stack {16 21}
  Create time: 00:01:10, last status change time: 00:00:57
  Signaling protocol: LDP, peer 150.1.5.5:0 up
    MPLS VC labels: local 29, remote 21
    Group ID: local 0, remote 0
    MTU: local 1500, remote 1500
    Remote interface description:
  Sequencing: receive disabled, send disabled
  VC statistics:
    packet totals: receive 4, send 40
    byte totals:   receive 595, send 3145
    packet drops:  receive 0, seq error 0, send 0

Now you can configure CE devices attached to the xconnect ports and assign IP addresses. L2TPv3 is similiar to AToM except it requires more options and you must specify a pseudowire class. You must also set the local interface. Enable path-mtu-discovery with 'ip pmtu'. 'ip dfbit set' avoids in-core framentation and performation degredation. 'ip tos reflect' copies the TOS bit.


pseudowire-class L2TPV3
 encapsulation l2tpv3
 ip local interface Loopback0
 ip pmtu
 ip dfbit set
 ip tos reflect
interface FastEthernet0/1
 no ip address
 duplex auto
 speed auto
 xconnect 150.1.6.6 100 encapsulation l2tpv3 pw-class L2TPV3


Verify with 'show l2tp session all'.

Well, that is all for the MPLS section. Pretty brief but there was a lot of material to cover. Hoping to cover Bridging and Switching tomorrow - or perhaps I'll fire up Narbik's MPLS lab for a different perspective. I'll see how I feel tomorrow.