Information About IP Multicast over UDL
Unicast and multicast routing protocols assume that links in a network are bidirectional, and forward data on interfaces from which they have received the routing control information. However, some network links are unidirectional, and usually, in a unidirectional network, the physical send-only interface is on the upstream router (for example, a satellite). The physical receive-only interface is on the downstream router (for example, a ship). In this case, a method of communication that allows the routing protocol to operate in a unidirectional environment is necessary.
Configuring Multicast over UDL helps you achieve control information in a unidirectional environment. You must configure a Unidirectional Link Routing (UDLR) tunnel as a unidirectional generic routing encapsulation (GRE) tunnel and map this tunnel to a one-way satellite link. By doing so, the UDLR tunnel mechanism enables the associated unicast and multicast routing protocols to treat the UDL as a bidirectional link. Before getting into the configuration, you must understand what is UDLR.
What is UDLR?
In unicast routing, when a router receives an update message on an interface for a prefix, it forwards the data to the destinations that match that prefix. Similarly, in multicast routing, when a router receives a join message for a multicast group on an interface, it forwards copies of the data that is destined for that group out from that same interface. Based on these principles, unicast and multicast routing protocols are not supported over UDLs without the use of UDLR. UDLR enables the operation of routing protocols over UDLs without changing the routing protocols themselves. UDLR also enables a router to emulate the behaviour of a bidirectional link for IP operations over the UDLs through a tunnel.
UDLR Tunnel
The UDLR tunnel is the back channel of a unidirectional high-capacity link which transparently emulates a single, bidirectional link for unicast and multicast traffic. A UDLR tunnel enables IP and its associated unicast and multicast routing protocols to treat the UDL as being logically bidirectional. A packet that is destined on a receive-only interface is picked up by the UDLR tunnel mechanism and sent to an upstream router using a generic routing encapsulation (GRE) tunnel. The control traffic thus flows in the opposite direction of the user data flow. When the upstream router receives this packet, the UDLR tunnel makes it appear that the packet was received on a send-only interface on the UDL.
The purpose of the GRE tunnel is to move control packets from a downstream node to an upstream node. This one-way tunnel is mapped to a one-way interface that goes in the opposite direction. The mapping is performed at the link layer so that the one-way interface appears bidirectional. When the upstream node receives packets over the tunnel, it causes the upper-layer protocols to act as if the packets were received on the send-capable UDL.
A UDLR tunnel supports the following functionalities:
-
Address Resolution Protocol (ARP) and Next Hop Resolution Protocol (NHRP) over a UDL
-
Emulation of bidirectional links for all the IP traffic
-
Support for IP GRE multipoint at a receive-only tunnel
 Note |
A UDL router can have many routing peers (for example, routers interconnected via a broadcast satellite link). As with bidirectional links, ensure that the number of peer routers is relatively small, to limit the volume of routing updates that are processed. |
Multicast Over UDL For Cisco IOS XE
The Multicast over UDL functionality is supported for PIM starting from the IOS XE Amsterdam 17.3.1 release. See the following sample topology that specifies the events that happen sequentially:
-
The PIM router receives a PIM join from the downstream PIM neighbor.
-
The PIM router connects to the FHR router through the UDLR tunnel.
-
The PIM router forwards the PIM join towards the FHR router through the physical interface.
-
After the PIM join is received, the FHR router forwards the corresponding multicast traffic to the PIM router through the UDLR tunnel interface. The traffic is encapsulated so that the traffic is not blocked.
In an encap-helper (encapsulated) tunnel on a physical interface, all the (*/S, G) MROUTE entries having the physical interface as the outgoing interface (OIF), use the tunnel interface as the OIF. All the multicast traffic destined to the physical interface flows through the configured tunnel with the encapsulation.
A new flag is propagated and is first introduced to MROUTE. This flag is set against an entry, provided the entry has at least one physical interface as the OIF on which the encap-helper is configured. Consequently, a new flag is introduced to MRIB, which is set against the entry that corresponds to the MROUTE entry. Similarly, a new flag is introduced to MFIB that corresponds to the MRIB entry. The flag is then visible to the platform which punts the multicast traffic only for those (*/S, G) entries based on the status of the flag. The IOS process then switches the packets and sends out these GRE-encapsulated packets.
Note |
When you remove or disable the encap-helper tunnel configuration on a physical interface, all the (*/S, G) MROUTE entries having the tunnel interface as the OIF use the physical interface as the OIF. The encap-helper feature is removed on the interface and the default behavior is enabled. |
Feedback