Configuration note IP multicast only across GRE tunnels with static routing only Last updated: 14/09/03 ------------------------------------------------------------------------------ ContentIndex: 1. Overview 2. Nonredundant configuration Example 1: Nonredundant topology Example 1: Nonredundant configuration Rules of thumb 3. Redundant configuration Example 2: Redundant topology Configuration mistakes to avoid Example 2: Redundant configuration Limitations: GRE Keepalives required No multipath load splitting supported 1. Overview This configuration note considers configuration to pass IP multicast traffic across GRE tunnels with either a non-redundant configuration (one tunnel) or redundancy (two tunnels). The configuration note only considers the case where only IP multicast, but not IP unicast is to be passed across the GRE tunnel(s) (incongruent routing). The configuration note only considers configurations not involving dynamic routing protocols - but just static routing - for traffic across the tunnel(s) This configuration note shows reference topologies and configurations. It describes how to arrive at a working configuration, which approaches will not work, and which limitations exist. 2. Nonredundant configuration GRE tunnels are often used to pass IP multicast traffic across parts of a topology that do not support IP multicast. A typical case of this are third party (non Cisco-IOS) firewalls. In general, only IP multicast, but not IP unicast traffic is then to be passed across these GRE tunnel(s). This is one case of what is being called "incongruent" routing, - eg: routing that uses different paths for IP unicast than for IP multicast. Incongruent routing in Cisco IOS IPv4 is supported via MBGP, static mroutes and DVMRP unicast routes. As of this writing, there is no support for incongruent routing via multi-topology IGP routing protocols like multi topology support in IS-IS. Static mroutes are best used in tactical environments in which the total number of routers that need to be configured is limited to a few routers, because it requires accurate and consistent manual configuration of static routes to work correctly. Configuring tunnel redundancy together with static mroutes can be tricky in Cisco IOS IPv4 multicast. This configuration note will describe what pitfalls need to be considered. Example 1: Nonredundant topology Tunnel only for multicast /----------------------------------------\ | | tun0| Physical connectivity | tun0 StubArea -- RtrA ---- across other routers ---- RtrB --- Internet eth1 eth0 not enabled for multicast eth0 eth1 or Intranet Example 1 shows the typical example of a stub area connected via a router to the Internet (or Intranet). The stub area reaches up to RtrA and is fully multicast enabled (beside RtrA it may have 0 or more other routers below RtrA enabled for IP multicast). Upstream of RtrA one or more routers are not IP multicast enabled, and so IP multicast must be tunneled towards some router that again has IP multicast connectivity towards the Internet or Intranet. In example 1, this is RtrB. The ip multicast configuration for this situation is quite simple and one option on how to configure this is roughly as follows - only the relevant pieces of the configuration are shown: Example 1: Nonredundant configuration ! RtrA ip multicast routing interface ethernet 0 ip address 192.168.100.1 255.255.255.0 ip pim sparse-mode interface ethernet 1 interface tunnel 0 ip unnumbered ethernet 0 ! tunnel interface address ip pim sparse-mode tunnel source ethernet 0 ! tunnel source address tunnel destination 192.168.300.1 ! tunnel destination address ip route 0.0.0.0 0.0.0.0 200 ! default unicast route to [1] ! some router on eth0 ip mroute 0.0.0.0 0.0.0.0 tunnel 0 ! default multicast route to [2] ! RtrB via the GRE tunnel ! RtrB ip multicast routing interface ethernet 0 ip address 192.168.300.1 255.255.255.0 interface ethernet 1 ... interface tunnel 0 ip unnumbered ethernet 0 ! tunnel interface address ip pim sparse-mode tunnel source ethernet 0 ! tunnel source address tunnel destination 192.168.100.1 ! tunnel destination address tunnel mode gre ip ip mroute tunnel 0 ! multicast route to [3] ! stub area Example 1 configuration shows a couple of standard design decisions. The stub area router RtrA only has static unicast routing, for example some form of a static default route (maybe multiple routes) [1]. It definitely needs a default static multicast route [2] to point towards the tunnel. It is important to understand that IPv4 multicast routing in Cisco IOS does by default select the route via what is called "distance-based-first". So it is important to ensure that the administrative distance any unicast route is higher than the static multicast default route - in the example, the distance for the unicast default route is set to 100, the multicast default route to 1 (implicit default). Likewise, on the RtrB, the not-shown dynamic unicast routing protocols or any other static unicast routes are best to have a higher distance than 1, which is the implicit distance of the static mroute [3]. To avoid having to allocate more ip adresses for RtrA/RtrB in support of the GRE tunnel, the tunnel interface address and tunnel source address are configured to re-use an already allocated address. In this example it is the address of eth0 on either router. This configuration works as well with loopback addresses, as long as their addresses are appropriately routed so that RtrA/RtrB can reach them respectively, and in more complex situations one may actually want to prefer using a loopback address for either the tunnel interface address and/or the tunnel source address: When a tunnel interface or source address is configured to be unnumbered, having it refer to another interfaces ip address (henceforth called the master interface), then the tunnel will become inoperable when the master interfaces goes down. A loopback interface can only go down when it is administratively configured to do so. Physical interfaces on the other hand can go down due to external natural causes (failure in the network). In example 1 it is fine to use the ip address of ethernet 0, because if ethernet 0 goes down physically, then the tunnel would not work anyhow, because the tunnel packets would have no other way to go. In example 1, it would also be fine to use the physical interface address of eth1 on either end, because on both RtrA and RtrB, there is only one physical interface across which the actual IP multicast traffic would flow natively, and if that one interface is physically down, then there is no need to have the tunnel working either. Rules of thumb: R1) If there is exactly one physical interface across which a router can reach the remote tunnel destination address, then you can use this physical interfaces IPv4 address as the tunnel source address, otherwise you should use the IP address of a loopback interface as the tunnel source address. R2) If there is exactly one physical interface across which the router provides native IP multicast routing, then you can use this physical interfaces IPv4 address as the tunnel interface address, otherwise you should use the IP address of a loopback interface as the tunnel interface address. 3. Redundant configuration Example 2 topoplogy: Redundant configuration Tunnel only for multicast tun0/----------------------------------------\ tun0 | eth0| eth1 eth1| Physical connectivity --- RtrB --- .. StubArea -- RtrA ---- across other routers .. Internet eth1| eth0 not enabled for multicast --- RtrC --- .. | eth0| eth1 tun1\----------------------------------------/ tun0 Tunnel only for multicast Consider now the case where IP multicast service to the stub area border router RtrA is to be provided in a redundant fashion via RtrB and RtrC. For example imagine that RtrB and RtrC provide GRE IP multicast tunnels to many RtrA type routers, eg: if they act as distribution layer routers: There may be no redundancy for RtrA, because if it fails, IP multicast (and IP unicast) service is only interrupted for one stub area, but there may need to be redundancy for RtrB, because if it fails, then a hundred or more stub areas may loose multicast connectivity. Note: It should be easy to deduce from example 2 other redundancy configurations, for example cases where there is also a redundant router for RtrA. As is explained in the following configuration note: ftp://ftpeng.cisco.com/ipmulticast/config-notes/static-mroutes.txt [A] Cisco IOS IPv4 multicast does not support to configure more than one static mroute towards any given prefix. A workaround is thus required which works by using just one static mroute which is using an address as it's next-hop which is appropriately routed so that it will use either available paths - in the case of RtrA both tunnel 0 and tunnel 1. Applying the method explained in above configuration note to tunnels does introduce a set of further issues though, which will be explained here: Configuration mistakes to avoid: Consider that both tunnel 0 and tunnel 1 on RtrA are configured similarily to example 1 and then the method for static routing from [A] is being applied: interface tunnel 0 ! tunnel towards RtrB ip unnumbered ethernet 0 ip pim sparse-mode keepalive 2 3 tunnel source ethernet 0 tunnel destination 192.168.300.1 interface tunnel 1 ! tunnel towards RtrC ip unnumbered ethernet 0 ip pim sparse-mode keepalive 2 3 tunnel source ethernet 0 tunnel destination 192.168.400.1 ip route 1.1.1.1 255.255.255.255 tunnel 0 200 ! tunnel0 towards RtrB [10] ip route 1.1.1.1 255.255.255.255 tunnel 1 210 ! tunnel0 towards RtrC [11] ip mroute 0.0.0.0 0.0.0.0 1.1.1.1 This is a non-working example of how one might want to apply [A] to two tunnels instead of two directly connected neighboring routers. As shown, the tunnel to RtrB would be preferred (distance 200 in the static route vs. 210 for tunnel 1). In addition, tunnel keepalive is used so that RtrA will know when tunnel 0 goes down. What is not working in this example is the actual IP multicast operations because the indirection via two tunnel interfaces does not work as would for example indirection would work to two directly connected neighboring routers. With the shown configuration, IP multicast RPF lookup for any source/RP reachable via the two tunnels will result in the correct tunnel interface, but the RPF neighbor of 1.1.1.1 instead of the actual RPF neighbor. The correct RPF neighbor address would of course be the IP interface address of RtrB or RtrC on their appropriate tunnel, eg: 192.168.300.1 / 192.168.400.1. Because it is 1.1.1.1, RtrA will want to send PIM join messages towards 1.1.1.1 on the tunnel interface, and this will fail: By default, Cisco IOS will not send PIM join messages to any RPF neighbor from whom it is not receiving PIM Hello messages. As 1.1.1.1 does not exist, RtrA will never send PIM join messages and thus never receive IP Multicast traffic (in PIM-SM/SSM/Bidir, the consequences for other modes of PIM are not considered here). Even if RtrA would send PIM join messages, the remote RtrB or RtrC would not react to them because they are still addressed to 1.1.1.1 instead of the correct address. If one does not use interface names but instead directly connected IP addresses as next hops to the two "ip route" commands, this problem does not exist, because in this case, the RPF lookup will not return the intermediate address 1.1.1.1 but instead the final next-hop address, indicating of course an existing PIM neighbor. Unfortunately, with the above shown tunnel configuration this can not be used because the next-hop addresses are not known to be directly connected! The configuration would be: ip route 1.1.1.1 255.255.255.255 192.168.300.1 200 ! RtrB ip route 1.1.1.1 255.255.255.255 192.168.400.1 210 ! RtrC ip mroute 0.0.0.0 0.0.0.0 1.1.1.1 What happens now is that RPF lookup will correctly recurse into 192.168.300.1 and 192.168.400.1, but because neither address is known to be directly connected, the RPF lookup will recurse further and find the (not shown) IP unicast default route "ip route 0.0.0.0 0.0.0.0 eth0". In result, the tunnels will not be used to join to IP multicast traffic but natively across ethernet 0. Adding static routes towards the remote tunnel interface addresses as shown in the following does also not work: ip route 192.168.300.1 255.255.255.255 tunnel 0 ! RtrB ip route 192.168.400.1 255.255.255.255 tunnel 1 ! RtrC ip route 1.1.1.1 255.255.255.255 192.168.300.1 200 ! RtrB ip route 1.1.1.1 255.255.255.255 192.168.400.1 210 ! RtrC ip mroute 0.0.0.0 0.0.0.0 1.1.1.1 With this configuration, IP multicast RPF lookup will work correctly, and PIM joins will also work correctly... unfortunately, both tunnels will not work anymore but be shut down automatically because we are now unicast routing the tunnel source addresses 192.168.300.1/192.168.400.1 across the tunnels, resulting in recursive packet forwarding. Logically the problem is this: The example is using the same ip address for the tunnel interface addresses and the tunnel source/destination addresses. The tunnel interface address is only of relevance to IP multicast, and the tunnel source/destination address only to IP unicast (GRE packet routing), but as soon as we use recursive route lookup, Cisco IOS can only use static routes (not static mroutes), and in effect configuring the correct multicast routing creates simultaneously non-working IP unicast routing for the tunnel source/destination addresses. The only solution to this problem is thus NOT to use the same tunnel source and tunnel interface address, so that it is possible to keep multicast and unicast routing appropriately separate. This will be shown in the example below. Note: The above text said that using a next-hop interface name, as shown in [10], [11] does not work. Why then does it work in the non-redundant case in [2] ? The reason is simple: [2] is a static mroute, not a static route, and for static mroutes, Cisco IOS does detect the situation that it needs to figure out the correct next-hop neighbor address. For tunnel interface or other point-to-point interfaces (eg: serial interfaces), Cisco IOS can support this by simply using the address of the only PIM neighbor as learned via PIM hello messages across the tunnel or serial interface. For non-point-to-point interfaces this will not work. Example 2: Redundant configuration ! RtrA ip multicast routing interface ethernet 0 ip address 192.168.100.1 255.255.255.0 ip pim sparse-mode interface ethernet 1 interface tunnel 0 ! tunnel towards RtrB ip address 10.0.1.1 255.255.255.0 ! [24] ip pim sparse-mode keepalive 2 3 tunnel source ethernet 0 tunnel destination 192.168.300.1 interface tunnel 1 ! tunnel towards RtrC ip address 10.0.2.1 255.255.255.0 ! [23] ip pim sparse-mode keepalive 2 3 tunnel source ethernet 0 tunnel destination 192.168.400.1 ip route 0.0.0.0 0.0.0.0 200 ! unicast default route ip route 1.1.1.1 255.255.255.255 10.0.1.2 200 ! multicast default [21] ip route 1.1.1.1 255.255.255.255 10.0.2.2 210 ! routing [22] ip mroute 0.0.0.0 0.0.0.0 1.1.1.1 ! [20] ! RtrB ip multicast routing interface ethernet 0 ip address 192.168.300.1 255.255.255.0 interface ethernet 1 ... interface tunnel 0 ip address 10.0.1.2 255.255.255.0 ip pim sparse-mode keepalive 2 3 tunnel source ethernet 0 tunnel destination 192.168.100.1 ! tunnel destination address ip mroute tunnel 0 ! RtrC ip multicast routing interface ethernet 0 ip address 192.168.300.1 255.255.255.0 interface ethernet 1 ... interface tunnel 0 ip address 10.0.2.2 255.255.255.0 ip pim sparse-mode keepalive 2 3 tunnel source ethernet 0 tunnel destination 192.168.100.1 ! tunnel destination address ip mroute tunnel 0 As this example shows, the configuration is not more complex in principle than the example 1 configuration, only that it does require to allocate IP addresses for the tunnel interface addresses. The IP multicast RPF operations on RtrA is now working: It will first use [20], then recurse into [21] or [22] (if tunnel 0 is not up and running), and then into the interface route installed automatically by IOS via the "ip address" configurations [23] or [24]. This results in the correct RPF neighbor addresses 10.0.1.2 or 10.0.1.2 to be used which are also seen by RtrB via PIM Hello messages across the tunnels. The two subnets 10.0.1.0/24 and 10.0.2.0/24 shown in the example have no significance outside of these three routers. They should not be included in any dyanmica unicast routing protocol used (unless problems described below have to be solved - maybe !). As can also be seen, there is no need to otherwise change the configuration on RtrB or RtrC - because they do not try to have redundancy across tunnels, they can also keep the simple one line "ip mroute" route configuration for IP multicast. There are two key limitations to the configuration: o GRE Keepalives required You must have Cisco IOS versions supporting keepalives across the tunnel interfaces. If you do not enable keepalive, the GRE interface (for example tunnel 0 on RtrA) will always indicate for the tunnel to be up and running, and RtrA will try to receive IP multicast traffic across this tunnel, even though RtrB may not be alive and running. This is not a generic limitation but specific to the combination of incongruent routing and the requirement not to use dynamic routing across the tunnels: If you use a dynamic routing protocol across the tunnel interfaces, you can use the routing reachability learned by those protocols to dynamically fail over IP multicast routing. If you need incongruent IP unicast/multicast routing though, the only dyamic routing protocols that do NOT also influence IP unicast routing are DVMRP unicast routing and MBGP, both of which are not necessarily ideally suited for tactical situations as the one described here. Note: Cisco IOS IP multicast routing by default does take PIM Hello messages from neighbors into account: If two equal-cost RPF neighbors are learned from the RPF route lookup, but only one of them also sends PIM Hello messages, then Cisco IOS will use that one neighbor. This can be used in other network configuration to achieve redundancy failover without a dynamic routing protocol, purely relying on PIM Hello messages. Unfortunately, this can also not be used in this situation, because it is not supported together with recursive route resolution from a static mroute: For all the recursion steps taken after looking up an ip mroute, only the first available path is used - even if multiple equal cost paths are used! o No multipath load splitting supported You can not effectively use "ip multicast multipath" on RtrA with the shown configuration, eg: Cisco IOS can not load split traffic across tunnel 0 and tunnel 1, even if you were to configure the same distance on [21] and [22]. The reason is as explained in the last paragraph that Cisco IOS does not consider multiple paths after recursion in a static mroute lookup. In addition to these limitations, the configuration also only shows the requrired level of configuration necessary for redundant receipt of IP multicast traffic in the stub area behind RtrA. If redundancy for IP multicast sources within the stub area is required for receivers within the Internet/Intranet, then RtrB and RtrC need to also have appropriate configuration to conditionally inject the prefix(es) of the stub area into the Internet/Intranet. As we assume that IP unicast traffic for the stub area does NOT run across the tunnels, this does require use of a multicast-only dynamic routing protocol between RtrB/RtrC and the appropriate receiver routers within the Intranet/Internet. This is outside of the scope of this configuration note. .