Your Service Provider Doesnt Do What You Want
Your Service Provider Doesn t Do What You Want
Problem
As an MPLS customer, you want to implement a feature like multicast or a particular PE-CE routing protocol that your service provider doesn't support.
Solution
Some service providers support only a limited range of MPLS features. The most common missing features are specific routing protocols for PE-CE routing and multicast support. This example will assume that you want to pass OSPF and multicast through an MPLS network that supports only BGP:
Router-CE-A1#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router-CE-A1(config)#ip multicast-routing Router-CE-A1(config)#interface FastEthernet0/0.1 Router-CE-A1(config-if)#encapsulation dot1Q 101 Router-CE-A1(config-if)#ip address 192.168.1.5 255.255.255.0 Router-CE-A1(config-if)#exit Router-CE-A1(config)#interface Loopback1 Router-CE-A1(config-if)#ip address 192.168.101.1 255.255.255.255 Router-CE-A1(config-if)#exit Router-CE-A1(config)#interface Tunnel1 Router-CE-A1(config-if)#ip address 192.168.152.1 255.255.255.252 Router-CE-A1(config-if)#tunnel source 192.168.101.1 Router-CE-A1(config-if)#tunnel destination 192.168.101.2 Router-CE-A1(config-if)#ip pim sparse-dense-mode Router-CE-A1(config-if)#exit Router-CE-A1(config)#router bgp 65535 Router-CE-A1(config-router)#neighbor 192.168.1.1 remote-as 100 Router-CE-A1(config-router)#network 192.168.1.0 Router-CE-A1(config-router)#network 192.168.101.1 mask 255.255.255.255 Router-CE-A1(config-router)#no synchronization Router-CE-A1(config-router)#no auto-summary Router-CE-A1(config-router)#exit Router-CE-A1(config)#router ospf 155 Router-CE-A1(config-router)#network 192.168.5.0 0.0.0.255 area 0 Router-CE-A1(config-router)#network 192.168.152.0 0.0.0.255 area 0 Router-CE-A1(config-router)#exit Router-CE-A1(config)#end Router-CE-A1#
At this site, we are using the same OSPF configuration as in Recipe 26.6 to facilitate routing within the site, but we want to separate the BGP and OSPF parts of the network. BGP will allow us to route between the CE routers and keep the tunnels working, while OSPF will run through the tunnels. So we don't redistribute between BGP and OSPF this time.
We configure the other CE router similarly:
Router-CE-A2#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router-CE-A2(config)#ip multicast-routing Router-CE-A2(config)#interface Ethernet0 Router-CE-A2(config-if)#ip address 192.168.3.8 255.255.255.0 Router-CE-A2(config-if)#exit Router-CE-A2(config)#interface Loopback1 Router-CE-A2(config-if)#ip address 192.168.101.2 255.255.255.255 Router-CE-A2(config-if)#exit Router-CE-A2(config)#interface Tunnel1 Router-CE-A2(config-if)#ip address 192.168.152.2 255.255.255.252 Router-CE-A2(config-if)#tunnel source 192.168.101.2 Router-CE-A2(config-if)#tunnel destination 192.168.101.1 Router-CE-A2(config-if)#ip pim sparse-dense-mode Router-CE-A2(config-if)#exit Router-CE-A2(config)#router bgp 65534 Router-CE-A2(config-router)#neighbor 192.168.3.1 remote-as 100 Router-CE-A2(config-router)#network 192.168.3.0 Router-CE-A2(config-router)#network 192.168.101.2 mask 255.255.255.0 Router-CE-A2(config-router)#no synchronization Router-CE-A2(config-router)#no auto-summary Router-CE-A2(config-router)#exit Router-CE-A2(config)#router ospf 155 Router-CE-A2(config-router)#network 10.8.8.0 0.0.0.255 area 0 Router-CE-A2(config-router)#network 192.168.152.0 0.0.0.255 area 0 Router-CE-A2(config-router)#exit Router-CE-A2(config)#end Router-CE-A2#
Then the PE configurations are identical to those shown in Recipe 26.8.
Discussion
In the discussion section to Recipe 26.5, we showed a simplified version of this recipe. In that case, we used GRE tunnels to carry RIP between CE routers. Here we use GRE tunnels to carry OSPF and multicast traffic. Also, in Recipe 26.5 we used static routes to define the routing for the loopback interfaces that hold the tunnel source and destination addresses. Here we assume that the MPLS carrier allows BGP and only BGP as a PE-CE routing protocol. So we take advantage of this BGP capability to bring up the tunnels, but we have been careful to keep all other internal customer routing out of the BGP routing tables.
This careful separation of internal and external routing tables serves two purposes. First, it ensures that there are no problems with recursive routing. This is a common problem when using tunnels with dynamic routing protocols. It happens when the routing protocol that goes through the tunnel is also carrying the information about the tunnel source and destination addresses. Here, the source and destination addresses are carried by BGP and the internal customer routing tables that traverse the tunnel are carried by OSPF. As long as we avoid redistribution between the two protocols, there are no issues.
The second advantage to doing it this way is that your tunnels will go down in the event of a problem in the MPLS cloud. If there is a failure in the cloud that isolates a site, the tunnel destination address for this site will drop out of the routing tables for all of your other CE routers. The tunnels will then drop, and you'll lose your OSPF neighbor relationships. This is a good thing because it means that you will be able to use standard rerouting mechanisms such as dial backup to recover your network connection.
However, if you allowed the tunnel destination addresses to lead into your OSPF routing tables, you could wind up with a situation in which the network is actually using a secondary path between sites and carrying the tunnel traffic down this alternate path. This is not only disoptimal in terms of routing, but also inherently unstable because OSPF doesn't have a way to discover the failure or subsequent recovery of the primary path.
So why use BGP at all in this case? Why not just use static routes to carry the information about the tunnel end points? The biggest reason is flexibility. If your MPLS service provider is willing to use BGP for carrying your tunnel source and destination addresses for you, then you are free to define as many tunnels as you like, and change them if necessary without notifying the carrier. If you were to use, for example, static routes, then the carrier would have to manually inject these addresses into their MP-BGP routing tables for your VRF. So using a routing protocol here is in everybody's best interests.
With the tunnels up, OSPF establishes neighbor relationships directly between the CE routers:
Router-CE-A1#show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 192.168.101.2 1 FULL/ - 00:00:36 192.168.152.2 Tunnel1 192.168.57.12 1 FULL/BDR 00:00:39 192.168.5.12 FastEthernet0/0.2 Router-CE-A1#
And multicast routing works normally through the tunnel, as if the two CE routers were directly connected to one another. To demonstrate this, we will put a static IGMP Join on the loopback interface of one of the routers:
Router-CE-A2#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router-CE-A2(config)#interface Loopback0 Router-CE-A2(config-if)#ip address 10.8.8.8 255.255.255.255 Router-CE-A2(config-if)#ip pim sparse-dense-mode Router-CE-A2(config-if)#ip igmp join-group 239.1.2.3 Router-CE-A2(config-if)#end Router-CE-A2#
We can then ping this multicast group to see that multicast routing works as expected through the tunnel:
Router-CE-A1#show ip pim neighbor PIM Neighbor Table Neighbor Interface Uptime/Expires Ver DR Address Prio/Mode 192.168.152.2 Tunnel1 00:24:49/00:01:26 v2 1 / S Router-CE-A1#ping 239.1.2.3 Type escape sequence to abort. Sending 1, 100-byte ICMP Echos to 239.1.2.3, timeout is 2 seconds: Reply to request 0 from 192.168.152.2, 12 ms Router-CE-A1#
For more information on multicast routing, as well as other multicast configuration options, please refer to Chapter 23.
So this solution does work. Protocols such as OSPF and multicast travel transparently through the MPLS cloud between the CE routers, and the customer's network behaves very much like a conventional WAN. But there are two potential issues with this solution that you should at least be aware of.
The first is that there is overhead to carrying traffic through a tunnel. If the maximum transmission unit (MTU) on the network is 1,500 bytes, you lose 24 bytes to the GRE tunnel packet header. So, between your CE routers, your effective MTU becomes 1,476 bytes. This could result in packet fragmentation and a small performance degradation.
The second potential problem is that this solution doesn't scale well to large numbers of CE routers, as we noted in Recipe 26.5. Since the MPLS network forms a mesh of all of the CE routers that belong to the same VRF, the number of tunnels required to duplicate this mesh for N CE routers is N(N 1)/2. For large networks, this quickly becomes unmanageable.
There is a standard solution to this link mesh scaling problem, though, which is simply to avoid a fully meshed network topology. In traditional WAN technologies such as X.25, ATM, and Frame Relay, it is common to deploy the network using a hub and spoke topology. This means that the routers at different sites don't all talk directly to one another. Instead, a small number (usually one or two) of routers become the central hub routers. The other spoke routers talk only to the hub routers. If two spoke routers need to communicate, their packets are relayed through one of the hub routers.
So, for the purposes of this recipe, we would define one or two of our CE routers as hub routers, and the other CE routers as spoke routers. This way, the spoke routers would have only as many tunnel interfaces as there are hub routers. The hub routers, on the other hand, would have tunnel connections to all of the other CE routers. Instead of scaling as N(N 1)/2, this now scales like N, which is much more manageable.
See Also
Chapter 12; Chapter 23; Recipe 26.5; Recipe 26.8