The Multicast Problem

Certain types of Internet interactions, such as conferencing and video broadcasts, require a single client or host to send the same packet to multiple receivers. This could be achieved through the sender duplicating the packet with different receiving IP addresses or by a broadcast of the packet across the Internet. These solutions waste large amounts of sender resources or network bandwidth and are therefore not satisfactory. An appropriate solution should also be able to scale to large numbers of receivers.

The Multicast Routing Solution

Multicast Routing solves the problem by the network routers themselves, replicating and forwarding packets via the optimum route to all members of a group.

The IETF standards that allow multicast routing are the following:

Underlying Principles

Multicast routing functions on the principle that an interested receiver joins a group for a multicast by using the IGMP protocol. PIM routers can then duplicate and forward packets to all members of such a multicast group, thus creating a distribution tree for packet flow. Rather than acquiring new network information, PIM uses the routing information from existing protocols, such as OSPF, to decide the optimal path.

Reverse Path Forwarding

A key mechanism in the multicast routing process is Reverse Path Forwarding. For unicast traffic, a router is concerned only with a packet's destination. With multicast, the router is also concerned with a packets source since it forwards the packet on paths which are known to be downstream, away from the packet's source. This approach is adopted to avoid loops in the distribution tree.

Routing to the Correct Interface

By default, multicast packets are routed by cOS Core to the core interface (in other words, to cOS Core itself). Multicast Policy objects are created in the IP rule set in order to perform forwarding to the correct interfaces. This is demonstrated in the Example 4.16, “Multicast Forwarding With No Address Translation”.

Promiscuous Mode

If an IP rule set entry exists which applies to a multicast packet's destination IP address, then that Ethernet interface automatically gets its receive mode set to promiscuous in order to receive multicast packets. Promiscuous mode means that traffic with a destination MAC address that does not match the Ethernet interface's MAC address will be sent to cOS Core and not discarded by the interface. Promiscuous mode is enabled automatically by cOS Core and the administrator does not need to worry about doing this.

With multicast only, the usage of promiscuous mode can be explicitly controlled using the Ethernet object property Receive Multicast Traffic which has a default value of Auto. If this property is set to Off, the multicast forwarding feature cannot function.

If the administrator enters a CLI ifstat <ifname> command, the Receive Mode status line will show the value Promiscuous next to it instead of Normal to indicate the mode has changed. This is discussed further in Section 3.4.2, Ethernet Interfaces.

The Multicast Policy is used to achieve duplication and forwarding of packets through more than one interface. This feature implements multicast forwarding in cOS Core, where a multicast packet is sent through several interfaces.

Note that since this rule overrides the normal routing tables, packets that should be duplicated by the Multicast Policy need to be routed to the core interface.

By default, the multicast IP range 224.0.0.0/4 is always routed to core and does not have to be manually added to the routing tables. Each specified output interface can individually be configured with static address translation of the destination address. The Interface field in the Interface/Net Tuple dialog may be left empty if the IPAddress field is set. In this case, the output interface will be determined by a route lookup on the specified IP address.

The Multicast Policy can operate in one of two modes:

Creating a Multicast Policy with the CLI

Creating multicast policies through the CLI requires some additional explanation.

The CLI command to create a Multicast Policy is the following:

Device:/> add MulticastPolicy Name=mc_policy1
	SourceNetwork=<srcnet>
	SourceInterface=<srcif>
	DestinationInterface=<srcif>
	DestinationNetwork=<destnet>
	Service=<service>
	MultiplexArgument={outif1;ip1},{outif2;ip2},{outif3;ip3}...

The two values {outif;ip} represent a combination of output interface and, if address translation of a group is needed, an IP address.

If, for example, multiplexing of the multicast group 239.192.100.50 is required to the output interfaces if2 and if3, then the command to create the rule would be:

Device:/> add MulticastPolicy Name=mc_policy2
	SourceNetwork=<srcnet>
	SourceInterface=<if1>
	DestinationInterface=core
	DestinationNetwork=239.192.100.50
	Service=<service>
	MultiplexArgument={if2;},{if3;}

The destination interface is core since 239.192.100.50 is a multicast group. No address translation of 239.192.100.50 was added but if it is required for, say, if2 then the final argument would be:

	MultiplexArgument={if2;<new_ip_address>},{if3;}

IGMP signaling between hosts and routers can be divided into two categories:

Normally, both types of rule have to be specified for IGMP to function but there are two exceptions:

cOS Core supports two IGMP modes of operation:

The operation of these two modes are shown in the following illustrations:

In Snoop Mode, the Clavister firewall will act transparently between the hosts and another IGMP router. It will not send any IGMP Queries. It will only forward queries and reports between the other router and the hosts.

In Proxy Mode, the firewall will act as an IGMP router towards the clients and actively send queries. Towards the upstream router, the firewall will be acting as a normal host, subscribing to multicast groups on behalf of its clients.

The following advanced settings for IGMP can be found in the Web Interface by going to:
Network > Routing > Advanced Multicast Settings

Auto Add Multicast Core Route

This setting will automatically add core routes in all routing tables for the multicast IP address range 224.0.0.0/4. If the setting is disabled, multicast packets might be forwarded according to the default route.

Default: Enabled

IGMP Before Rules

For IGMP traffic, by-pass the normal IP rule set and consult the IGMP rule set.

Default: Enabled

IGMP React To Own Queries

The firewall should always respond with IGMP Membership Reports, even to queries originating from itself. Global setting on interfaces without an overriding IGMP Setting.

Default: Disabled

IGMP Lowest Compatible Version

IGMP messages with a version lower than this will be logged and ignored. Global setting on interfaces without an overriding IGMP Setting.

Default: IGMPv1

IGMP Router Version

The IGMP protocol version that will be globally used on interfaces without a configured IGMP Setting. Multiple querying IGMP routers on the same network must use the same IGMP version. Global setting on interfaces without an overriding IGMP Setting.

Default: IGMPv3

IGMP Last Member Query Interval

The maximum time in milliseconds until a host has to send an answer to a group or group-and-source specific query. Global setting on interfaces without an overriding IGMP Setting.

Default: 5,000

IGMP Max Total Requests

The maximum global number of IGMP messages to process each second.

Default: 1000

IGMP Max Interface Requests

The maximum number of requests per interface and second. Global setting on interfaces without an overriding IGMP Setting.

Default: 100

IGMP Query Interval

The interval in milliseconds between General Queries sent by the device to refresh its IGMP state. Global setting on interfaces without an overriding IGMP Setting.

Default: 125,000

IGMP Query Response Interval

The maximum time in milliseconds until a host has to send a reply to a query. Global setting on interfaces without an overriding IGMP Setting.

Default: 10,000

IGMP Robustness Variable

IGMP is robust to (IGMP Robustness Variable - 1) packet losses. Global setting on interfaces without an overriding IGMP Setting.

Default: 2

IGMP Startup Query Count

The firewall will send IGMP Startup Query Count general queries with an interval of IGMPStartupQueryInterval at startup. Global setting on interfaces without an overriding IGMP Setting.

Default: 2

IGMP Startup Query Interval

The interval of General Queries in milliseconds used during the startup phase. Global setting on interfaces without an overriding IGMP Setting.

Default: 30,000

IGMP Unsolicited Report Interval

The time in milliseconds between repetitions of an initial membership report. Global setting on interfaces without an overriding IGMP Setting.

Default: 1,000

It is possible to tunnel cOS Core multicast between two Clavister firewalls through a GRE tunnel. The multicast server will be behind one firewall and the clients behind the other with a GRE tunnel linking the two firewalls.

Setup Issues

There are certain issues that must be noted with tunneling multicast:

Tunneling Setup Summary

The following components are needed on both the client and server side:

An Example Configuration

An example multicast tunneling scenario is illustrated below.

The IPv4 address book object called mc_group on both sides of the tunnel is the same multicast IPv4 range. In this example, 239.100.100.0/24.

A. Server Side Configuration Setup

For the server side configuration, assume the client network is the IPv4 address book object client_net, the local internal tunnel endpoint is If2_ip (the server is on the If2 interface). A GRE tunnel called gre_to_clients is configured and the remote network is the address book object called client_net.

GRE Tunnel

Routes

Provided that the above GRE object has the option to automatically add routes enabled, the following route will be added by cOS Core to the main routing table.

Services

IP Rule Set Entries

IGMP Rules

B. Client Side Configuration Setup

For the client side configuration, assume the server network is the IPv4 address book object server_net, the local internal tunnel endpoint is If3_ip (the clients are on the If3 interface). A GRE tunnel called gre_to_server is configured and the remote network is the address book object called server_net.

GRE Tunnel

Routes

Provided that the above GRE object has the option to automatically add routes enabled, the following route will be added by cOS Core to the main routing table.

Services

IP Rule Set Entries

IGMP Rules