TE and Multicast

Multicast packets are not sent over TE tunnels, but over the underlying physical infrastructure. This can cause problems with multicast's Reverse-Path Forwarding (RPF) lookup when autoroute is enabled.

Multicast does its forwarding by doing an RPF lookup on the source address of every multicast packet. It forwards that packet only if it came in on the interface that the routing table says is the shortest path to the source.

The problem with this and TE, though, is that if you enable autoroute, your routing table points to a bunch of routes out a TE tunnel, but packets never come in on TE tunnels! Multicast breaks! Bad!

With autoroute disabled, things look like Example 10-14.

Example 10-14 Routing and RPF Information with No MPLS TE


gsr3#show ip route 192.168.1.7

Routing entry for 192.168.1.7/32

  Known via "isis", distance 115, metric 45, type level-2

  Redistributing via isis

  Last update from 192.168.11.6 on POS2/1, 00:00:26 ago

  Routing Descriptor Blocks:

  * 192.168.11.6, from 192.168.1.7, via POS2/1

      Route metric is 45, traffic share count is 1



gsr3#show ip rpf 192.168.1.7

RPF information for ? (192.168.1.7)

  RPF interface: POS2/1

  RPF neighbor: ? (0.0.0.0)

  RPF route/mask: 192.168.1.7/32

  RPF type: unicast (isis lab)

  RPF recursion count: 0

  Doing distance-preferred lookups across tables

In the preceding output, you can see that both the unicast IP route and the RPF entry for 192.168.1.7 are out POS2/1. This is good.

With autoroute enabled on Tunnel1, RPF breaks, as Example 10-15 confirms.

Example 10-15 Routing and RPF Information with MPLS TE Enabled and Without mpls traffic-eng multicast-intact Configured


gsr3#show ip route 192.168.1.7

Routing entry for 192.168.1.7/32

  Known via "isis", distance 115, metric 45, type level-2

  Redistributing via isis

  Last update from 192.168.1.7 on Tunnel1, 00:00:11 ago

  Routing Descriptor Blocks:

  * 192.168.1.7, from 192.168.1.7, via Tunnel1

      Route metric is 45, traffic share count is 1



gsr3#show ip rpf 192.168.1.7

RPF information for ? (192.168.1.7) failed, no route exists

Luckily, there's an easy solution to this problem. Under your IGP configuration (both OSPF and IS-IS support this), configure mpls traffic-eng multicast-intact. This builds the RPF table using the routing table that would be used if you didn't have TE tunnels. Problem solved.

The configuration is simple, as Example 10-16 shows.

Example 10-16 Configuring mpls traffic-eng multicast-intact


router ospf 1

 log-adjacency-changes

 passive-interface Ethernet0

 network 0.0.0.0 255.255.255.255 area 0

 mpls traffic-eng router-id Loopback0

 mpls traffic-eng area 0

 mpls traffic-eng multicast-intact

The result of configuring mpls traffic-eng multicast-intact is that both the unicast routing table and the RPF table are correct, as shown in Example 10-17.

Example 10-17 Routing and RPF Information with MPLS TE Enabled and mpls traffic-eng multicast-intact Configured


gsr3#show ip route 192.168.1.7

Routing entry for 192.168.1.7/32

  Known via "isis", distance 115, metric 45, type level-2

  Redistributing via isis

  Last update from 192.168.1.7 on Tunnel1, 00:00:14 ago

  Routing Descriptor Blocks:

  * 192.168.1.7, from 192.168.1.7, via Tunnel1

      Route metric is 45, traffic share count is 1



gsr3#show ip rpf 192.168.1.7

RPF information for ? (192.168.1.7)

  RPF interface: POS2/1

  RPF neighbor: ? (0.0.0.0)

  RPF route/mask: 192.168.1.7/32

  RPF type: unicast (isis lab)

  RPF recursion count: 0

  Doing distance-preferred lookups across tables

As you can see, the unicast route for 192.168.1.7 now points down Tunnel1, but the RPF information for that same prefix points down the physical interface, POS2/1. This is as it should be. Multicast traffic now flows properly on your network.

< Free Open Study >