WeOS
5.29.0

# Static 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 supports both PIM and static multicast routing.

## 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 optional prefix length of the group, an inbound interface, an optional source address and one or more outbound interfaces. There can be at most 256 multicast routes with at most 32 outbound interfaces per route.

Multicast groups may not overlap for the same source interface or a mix of any and a specific source interface. The only exception is a source specific /32 and a sourceless /32 route for legacy purposes.

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

    example:/#> configure ip
    example:/config/ip/#> forwarding
    example:/config/ip/#> multicast-forwarding
    example:/config/ip/#> mroute group 225.3.5.0/24 in vlan1 out vlan2 vlan3
    example:/config/ip/#> leave

To setup up a multicast route that tracks a VRRP instance(only forwards packets if the vrrp instance is in Master state):

    example:/#> configure
    example:/config/#> router
    example:/config/router/#> vrrp vrrp1
    example:/config/router/vrrp-vrrp1/#> iface vlan1
    ...
    example:/config/router/vrrp-vrrp1/#> end
    example:/config/router/#> end
    example:/config/#> ip
    example:/config/ip/#> forwarding
    example:/config/ip/#> multicast-forwarding
    example:/config/ip/#> mroute group 225.3.2.2 track vrrp1 in vlan1 out vlan2 vlan3
    example:/config/ip/#> leave

Such a multicast route may not overlap without another multicast route. This means that they can not have same group and the same input interface as another multicast route.

## Status

To verify that the route is correctly set:

    example:/#> show ip mroute

    (*,G) Template Rules
    ROUTE (S,G)                        IIF                 PACKETS      BYTES  OIFS
    (*, 225.3.2.1)                     vlan1                     0          0  vlan2 vlan3
    (*, 225.3.5.0/24)                  vlan1                     0          0  vlan3 vlan2
    (*, 225.3.2.2)                     vlan1                     0          0  vlan3 vlan2

    (S,G) Rules
    ROUTE (S,G)                        IIF                 PACKETS      BYTES  OIFS
    (192.168.2.12, 225.1.2.3)          vlan1                     0          0  vlan3 vlan2

    Kernel MFC Table
    ROUTE (S,G)                        IIF                 PACKETS      BYTES  OIFS
    (192.168.2.12, 225.1.2.3)          vlan1                     0          0  vlan3 vlan2

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.

« Previous Next »