MPLS or Multi-Protocol Label Switching is a mechanism of fast-forwarding a packet by attaching a special bit sequence to the packet called “the label“. It’s a bit complex to understand how MPLS works, but in summary it gives a router the ability to quickly forward packets without looking at the routing table. Therefore, MPLS is improving the network performance and often used to maintain scalability in ISP backbone environment. In this scenario, we are going to show how we Configure MPLS IP on Cisco IOS Router and use it to establish connectivity between two separated client’s network.
How to Configure MPLS IP on Cisco IOS Router
In this scenario, we are working for a fictional provider named “The MBG Network“. MBG has a client that requires connectivity between its two sites that located in different city. The whole network is built using Cisco IOS router with the topology as shown below:
There are three simple steps to configure MPLS IP on Cisco IOS router and make the client sites connected to each other.
1. Configure the provider backbone using iBGP
Before we configure iBGP, all the routers in provider backbone should be connected to each other through IGP. It can be OSPF, EIGRP, RIP, or anything as long as reachability between routers is guaranteed. As in this topology, all the routers in the provider backbone has been interconnected using OSPF. Therefore the next thing to do is configure the internal BGP relationship between PE routers.
The reason why we should use iBGP and not the other routing protocol will be explained later. For now, these are the iBGP configuration on PE1 and PE2:
PE1(config)#router bgp 65000 PE1(config-router)#neighbor 10.1.1.12 remote-as 65000 PE1(config-router)#neighbor 10.1.1.12 update-source loopback0 PE1(config-router)#neighbor 10.1.1.12 next-hop-self
PE2(config)#router bgp 65000 PE2(config-router)#neighbor 10.1.1.11 remote-as 65000 PE2(config-router)#neighbor 10.1.1.11 update-source loopback0 PE2(config-router)#neighbor 10.1.1.11 next-hop-self
And to verify BGP peering has been established, we should be able to see the neighbour address by issuing the show ip bgp summary command. The output for this example shown below:
PE1#sh ip bgp summ | b Neighbor Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 10.0.0.102 4 65000 19 20 2 0 0 00:15:57 0
PE2#sh ip bgp summ | b Neighbor Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 10.0.0.101 4 65000 20 19 2 0 0 00:15:09 0
Notice that BGP peering has been established but the current counter for received prefix is 0. Next, we will advertise the client prefix on BGP configuration on each PE.
2. Advertise the attached client prefix on each PE
The attached client prefix on PE1 is 22.214.171.124/24 and on PE2 is 126.96.36.199/24. With iBGP we can exchange this information between PE without having the intermediate routers (P1 and P2) to know this information, and this is the reason why iBGP is chosen for this the backbone connectivity.
The command to advertise the client prefix on each PE is shown below:
PE1(config)#router bgp 65000 PE1(config-router)#network 188.8.131.52 mask 255.255.255.0
PE2(config)#router bgp 65000 PE2(config-router)#network 184.108.40.206 mask 255.255.255.0
Wait for a while until routing information exchange is completed between PE. We know it when PE1 already obtained installed route to 220.127.116.11/24 in its routing table, and vice versa on PE2 for route to 18.104.22.168/24.
PE1#sh ip route bgp 22.214.171.124/24 is subnetted, 1 subnets B 126.96.36.199 [200/0] via 10.0.0.102, 00:23:34
PE2#sh ip route bgp 188.8.131.52/24 is subnetted, 1 subnets B 184.108.40.206 [200/2] via 10.0.0.101, 00:23:51
However, even if the route information exchange between PE has been successful, CE1 will still not be able to reach CE2 and vice versa.
CE1#ping 220.127.116.11 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 18.104.22.168, timeout is 2 seconds: ..... Success rate is 0 percent (0/5)
This is because the intermediate routers, or P1 and P2, doesn’t have any information about the client prefix so they don’t know where to forward the packet. Now to solve this, if we want to rely so much on routing, we can redistribute BGP into OSPF on both PE routers and let both P routers know the way to both client prefix. But this means we will still burden P routers with additional routing entries and from scalability perspective this is not a feasible solution.
The more client connected to MBG network means more burden on P routers as it needs learn every time a new prefix is established and this is not an ideal condition for a service provider. The better solution is to implement MPLS IP on the backbone network.
3. Enable MPLS IP on the provider backbone
As mentioned, the last step for this scenario is to implement MPLS IP on the ISP backbone. With MPLS, it’s as if we have a tunnel between PE routers so that packet can be forwarded between client prefix without informing the prefix information to the P routers. And this is the beauty of MPLS.
The command to configure MPLS IP on Cisco IOS router is as simple as typing “mpls ip“, but it needs to be applied on the global configuration and interface configuration of all routers that are going to participate in the MPLS network. In this case, they are P1, P2, PE1, and PE2.
P1(config)#mpls ip P1(config)#interface f0/0 <-- interface connected to PE1 P1(config-int)#mpls ip P1(config-int)#interface f0/1 <-- interface connected to PE2 P1(config-int)#mpls ip
P2(config)#mpls ip P2(config)#interface f0/0 <-- interface connected to PE1 P2(config-int)#mpls ip P2(config-int)#interface f0/1 <-- interface connected to PE2 P2(config-int)#mpls ip
PE1(config)#mpls ip PE1(config)#interface f0/0 <-- interface connected to P1 PE1(config-int)#mpls ip PE1(config-int)#interface f0/1 <-- interface connected to P2 PE1(config-int)#mpls ip
PE2(config)#mpls ip PE2(config)#interface f0/0 <-- interface connected to P1 PE2(config-int)#mpls ip PE2(config-int)#interface f0/1 <-- interface connected to P2 PE2(config-int)#mpls ip
Now after implementing the above command, all backbone routers will start exchanging label and after that ping between CE will works. See the output below:
CE1#ping 22.214.171.124 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 126.96.36.199, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 84/86/96 ms
Also, notice the second hop in the trace route below is utilizing MPLS to forward the packet.
CE1#trace 188.8.131.52 Type escape sequence to abort. Tracing the route to 184.108.40.206 1 220.127.116.11 8 msec 20 msec 24 msec 2 10.1.1.1 [MPLS: Label 16 Exp 0] 52 msec 60 msec 72 msec 3 10.1.1.6 64 msec 48 msec 68 msec 4 18.104.22.168 96 msec 72 msec 96 msec
With this we have successfully implementing MPLS to connect between client sites.
Working with MPLS IP on Cisco IOS Router
As mentioned in the beginning of this article, MPLS works by utilizing something called the label. This label is assigned to a prefix that the router knows in its routing table, and all labels are stored in the MPLS forwarding-table. The command to verify MPLS label forwarding-table on Cisco IOS router is show mpls forwarding-table. Below is the example output on PE2:
PE2#show mpls forwarding-table Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 16 Pop tag 10.0.0.1/32 0 Fa0/0 10.1.1.5 17 Pop tag 10.1.1.0/30 0 Fa0/0 10.1.1.5 18 17 10.0.0.101/32 0 Fa0/1 10.1.1.13 17 10.0.0.101/32 0 Fa0/0 10.1.1.5 19 Pop tag 10.0.0.2/32 0 Fa0/1 10.1.1.13 20 Pop tag 10.1.1.8/30 0 Fa0/1 10.1.1.13
On the table above we can see the local tag a.k.a the label, the outgoing interface and the related next-hop information for a prefix. Thankfully all of these information are automatically calculated when we configure MPLS IP on Cisco IOS router. However, it is still important to know how the MPLS router make forwarding decision based on these information by understanding how MPLS works in Cisco IOS router.