WeOSStatic Multicast Routing
About
This document gives an overview of the concepts around IP multicast routing and how to set up and debug static multicast routes.
Introduction
Multicast is an efficient data distribution mechanism for purposes of reaching more than one receiver. IP multicast applications, such as a camera or sensor, can send one packet only to reach many receivers. Switches and routers in the network infrastructure duplicate the packet as it makes its way to each receiver.
A receiver of multicast is said to be a subscriber to a group, a group is an IP address. In IPv4 the entire 224.0.0.0/4 block is reserved for multicast, i.e., 224.0.0.0 – 239.255.255.255. However, not all address are available to the end-user.
In the reserved IPv4 multicast range, a small subnet, 224.0.0.0/24 or 224.0.0.*, is further reserved for control protocols, e.g., IGMP, RIPv2 and OSPF.
Like regular IP addresses, IP multicast groups must be translated to Ethernet (LAN) MAC addresses. However, the range of reserved MAC multicast addresses is too small. For example group 225.1.2.3 and 226.1.2.3 both map to 01:00:5e:01:02:03. See RFC 1112 for details. This limitation may be a problem in switched networks where the switch fabric only supports filtering on MAC level.
On a per LAN basis (layer-2) IP multicast is managed by IGMP (routers) and IGMP Snooping (switches). Managing multicast on this level is important due to its inherent broadcast nature. Knowledge of this can be very important when debugging multicast (re)distribution and routing.
Routing of IP multicast can be done either dynamically (e.g., DVMRP, PIM) or statically. WeOS currently only supports the latter.
Overview
Compared to unicast routing, multicast routing uses a separate routing table and is handled a little bit differently. To be able to route multicast you need the following:
- Enable IP forwarding
- Enable IP multicast forwarding
- A multicast route, (S,G) or (*,G)
- Multicast traffic, where packets have a TTL > 1
The two enable flags simply control routing and multicast routing, respectively. However, if IP forwarding is disabled toggling the multicast forwarding flag will have no effect.
A multicast route is made up of a group, an inbound interface, an optional source address and one or more outbound interfaces. There can be at most 128 multicast routes with at most 16 outbound interfaces per route.
The source, or sender address, is optional but the underlying Linux kernel still require a source address to be able to route the traffic. A dedicated multicast routing daemon manages this by adding rules to the kernel on-demand based on the source-less rules specified. For each new multicast stream, from a given group and inbound interface, the routing daemon checks to see if a matching mroute rule exists and then adds that source specific rule to the kernel. This may cause some initial delays in activation of such rules.
Notation:
- (S,G) - source-specific
- (*,G) - source-less
Configuration
To set up a source-specific route of group 225.1.2.3 from sender 192.168.2.42 from vlan1 to vlan2 and vlan3:
example:/#> configure ip example:/config/ip/#> forwarding example:/config/ip/#> multicast-forwarding example:/config/ip/#> mroute group 225.1.2.3 source 192.168.2.12 in vlan1 out vlan2 vlan3 example:/config/ip/#> leave
To set up a source-less route of another group:
example:/#> configure ip example:/config/ip/#> forwarding example:/config/ip/#> multicast-forwarding example:/config/ip/#> mroute group 225.3.2.1 in vlan1 out vlan2 vlan3 example:/config/ip/#> leave
Status
To verify that the route is correctly set:
example:/#> show ip mroute ROUTE (S,G) INBOUND PACKETS BYTES OUTBOUND (*, 225.3.2.1) vlan1 0 0 vlan2 vlan3 (192.168.2.42, 225.3.2.1) vlan1 226 7232 vlan2 vlan3 (192.168.2.12, 225.1.2.3) vlan1 0 0 vlan2 vlan3
Worth noting here is that the (*,G) route acts as a template. When the sender, here 192.168.2.42, is discovered a dedicated (S,G) rule is added automatically. The packet counters for (*,G) routes will therefore always be zero.