Multicast+Routing

There are six basic requirements for multicast routing: toc
 * 1) A designated range of IP addresses must be reserved for use in the multicast network and should only be used by multicast applications
 * 2) A multicast address may only be used as a destination address
 * 3) The multicast application must be installed on all receiving hosts and must use the same address specified on the server
 * 4) All devices in the LAN must use a standard method to calculate the layer 2 multicast addresses
 * 5) A host must be able to dynamically indicate that it needs to receive specific multicast traffic. This is usually done via IGMP snooping
 * 6) There must be a multicast protocol that allows routing of Multicast packets

When a host wants to subscribe to to a group, it indicates it with IGMP. The host then calculates the layer 2 address from the layer 3 address and begins listening for packets for those addresses.

=Multicast addressing=

Each multicast application is represented by an IP address. This is called a group address.

Addresses range from 224.0.0.0 - 239.255.255.255 (First four bits must be **1110**).

Layer 2 addresses are formed by using the OUI **01005E**, followed by a binary 0 and the last 23 bits of the multicast address.

Well known addresses
Permanent multicast groups: 224.0.0.0 - 224.0.1.255 Source-Specific multicast: 232.0.0.0–232.255.255.255 (SSM gives hosts the ability to select where the stream comes from) GLOP Addressing: 233.0.0.0–233.255.255.255 Private multicast addresses: 239.0.0.0–239.255.255.255

The permanent addresses are divided into two groups, with the first group having addresses which should not be forwarded by routers and the second group that should. Local only addresses are in the range 224.0.0.0 - 224.0.0.255

=IGMPv1=

IGMP v1 routers use the Host Membership query message to determine if it needs to forward any multicast traffic on a specific link. Packets use a TTL of 1 to prevent them from being routed. Hosts should respond with an IGMP report. Membership queries are sent every 60 seconds by default. Only one router should be sending queries per subnet/link.

IGMPv1 has no explicit leave mechanism. A router will wait up to 3 minutes (Group membership interval) for a host membership report, at which point it considers the device inactive for that group.

Host membership report
A host membership report sent in response to an IGMP Membership query is called a solicited report. One is sent for each group the host has joined. Also, when a host joins a new group it immediately sends a membership report (Unsolicited).

This can cause wasted bandwidth, since a router only needs to receive a membership report once for each application. To mitigate this, the Report suppression mechanism uses the Maximum response time. This is set at 10 second increments and cannot be configured, but you can use multiple MRT values. Once a query is received by a host, it has until the total MRT to respond. When a query is received, each host picks a random delay between 1 and 10 seconds before sending the report. If the host sees another report on the same link come in, it does not send.

=IGMPv2=

IGMPv2 introduces the following new features:


 * Leave group messages to inform routers that a host has left a multicast group
 * Group specific query messages to allowed a router to send a membership query for a specific group. When a device sends a leave message, the router will immediately send a group specific query message to see if any hosts are still interested in that group.
 * Maximum response time field. This allows the tuning of the MRT for the host membership report
 * Provides a method for selecting a primary multicast router on a subnet

IGMPv2 is backwards compatible with version 1.

Querier election
When an IGMPv2 router starts up, it sends a general query message. All routers on the link compare IP addresses and the lowest is elected as the querier. All other routers cease to send IGMP membership queries, but still monitor the send rate of the primary router. When the primary router stops sending queries for **2 consecutive query** intervals and **1 half query response interval**, a new querier is elected.

=Interoperability=

IGMPv2 Host and IGMPv1 Routers
IGMPv2 hosts send membership reports with type code 0x16, which does not exist in v1. As a result, v2 routers will consider this message invalid and ignore it. IGMPv2 hosts must therefore send only v1 reports when v1 routers are active. This is determined by the MRT field in an IGMP query packet. On version 1 packets, this field is 0. It is non-zero on version 2 packets. If a version 1 query is received, the host marks the interface as version 1 and sends only those packets. A version 1 present timer is also set at 400-seconds. When this timer expires the host resets the interface to v2. The timer is reset for each v1 query received.

IGMPv1 Host and IGMPv2 Routers
A version 2 router can detect the presence of version 1 hosts based on the membership report type field values, as they differ between versions. For this reason, version 2 membership reports do not trigger the report suppression mechanism for version 1 hosts. When a version 1 host is present on a LAN, version 2 routers will ignore leave messages and wont send group-specific query messages. When a version 1 report is received, routers will start a v1 host present timer which is equal to the group membership interval. Interoperability actions cease once this timer expires, and it is reset with each v1 report.

IGMPv1 and v2 Routers
When both router versions exist on a network, all version 2 routers should be manually updated to act as version 1 routers.

=Intervals=

=Multicast Listener Discovery=

The MLD protocol is derived from IGMPv2 and is designed for IPv6. The major differences are:


 * All devices use the link local address as a source for communication to other multicast devices. This prevents the communications from traveling beyond the local link.
 * MLD uses "Done" messages when a host wants to leave a group

=IGMP Snooping=

The following messages are observed by IGMP snooping:


 * IGMP General query message
 * OSPF messages
 * PIMv1 and HSRP hello messages
 * Pv2 hello messages
 * DVMRP messages

Each time a IGMP report is received, the switch adds that port to a list and beings to forward traffic to that port for the group requested. The reverse happens when a leave message is received.

=Dense Mode Multicast Routing=

Dense mode routing forwards multicast packets out all interfaces except the interface on which it was received. Dense mode assumes that all subnets want to receive multicast traffic. Subnets that do not want to receive the traffic can opt out if:


 * The router does not have any downstream routers that need to receive the traffic
 * No directly connected hosts have joined the multicast group

When a router meets these requirements, a "prune" message it sent to the upstream router to stop the forwarding of multicast packets.

=Sparse Mode Multicast Routing=

Sparse mode is the opposite of dense mode. It will only forward packets if the downstream router has specifically requested traffic for that group. This will occur for two reasons:


 * A downstream router has asked to receive packets
 * A directly connected host has sent an IGMP join message

In this operation, all traffic is sent to a Rendezvous point which will then forward traffic out interfaces based on which downstream devices sent a PIM JOIN.

=Multicast Scoping=

Multicast scoping is the practice of defining boundaries to determine how far traffic will travel in your network. Two versions exist


 * Administrative Scoping
 * TTL Scoping

TTL Scoping
TTL scoping involves configuring a new TTL limit (Per interface) for multicast packets, which will be discarded if the packet TTL is lower. This option is difficult to scale in large or variable device networks.

Administrative Scoping
Administratively scoped addresses are those in the range of 239.0.0.0 - 239.255.255.255. A router can be configured to deny entry of exit of packest matching multicast address in the administrative range. Manual configuration is required;

=PIM-DM=

PIM relies on the unicast routing table for RPF checks in both dense mode and sparse mode.

Source based distribution tree
A source based distribution tree is the path a multicast packet takes through the network. The path can vary based on source, source location and multicast group.

The following is a multicast routing entry

00:00:12: Route has been active for 12 seconds 00:02:48: Route will expire in this time Fa0/0 has been forwarding for 12 sec, and will note expire until a prune message is received.

Prune messages
A router can send a prune message to remove a forwarding interface from a specific SPT. The interface removed is that on which the prune message is received. When a prune message is sent, the multicast routing entry will resemble the following:



This shows that the interface was pruned 8 seconds ago, and since its dense mode, it will return to the forwarding state in 2:52. A prune can be sent when either of the following occur:


 * A packet is received on a non-rpf interface.
 * No downstream routers and no locally connected hosts need the multicast traffic

PIMv2 implements State refresh messages which is sent just before the prune timer expires. Prune messages can also be overridden. When a prune message is sent, all routers on the shared link receive it. The upstream router starts a 3 second timer before pruning, and any other router still wishing to receive the traffic (And heard the prune message) can send a join in response. This is called a prune override.

Graft messages can be sent to force a link out of the pruned state

Assert messages are used to prevent duplication of multicast packets by routers on the same shared link. The routers can sense a multicast packet they forwarded, thats not on their RPF interface. This cases the routers to forward an Assert message. The routers then compare thier administrative distances and metrics, and a winner is picked based on the following:


 * 1) Router with the lowest AD
 * 2) Router with the lowest advertised routing protocol metric
 * 3) Router with the highest IP address on the LAN

Forming Adjacencies
Hello messages are sent every 30 seconds to a reserved multicast address of 224.0.0.13. The packets contain a holdtime value which is usually 3 times the hello value of the sender.

Designated router
PIM hello messages are used to elect a DR. The router with the highest IP address becomes the DR. This is often used in conjunction with IGMPv1, as there is no method to elect a querier in that version. The DR takes on the responsibility of sending the IGMP query messages.

Multicast Open Shortest Path First

 * Uses type 6 LSA
 * SPT is calculated on demand when the first packet arrives
 * RPF check is not required

=PIM-SM=


 * Neighbor discovery done through hello messages
 * RPF is recalculated when the unicast table changes
 * DR election occurs
 * Prune override is used
 * Assert messages used

Rendezvous Point

 * 1) Sources send packest to the RP
 * 2) The RP sends packest to all devices that have requested the traffic

When a device is connected on the same LAN as a source and receives a multicast packet, it tries to register with the RP. When the RP gets the PIM register and no host want the packet, it sends a register stop message. The original router then starts a register suppression timer and resends the register at the end as long as it still is receiving packets from the source. The PIM register message contains an encapsulated multicast packet which the RP will forward if a host decides it does want traffic for the group.

Root Path Tree
The root path tree is similar to the SPT. The RP is the root, and different trees exist for each multicast group. This tree is created by the PIM join messages that are sent to the RP. A join message is sent under two conditions


 * A PIM join message is received on an interface other than the one used to route towards the RP
 * When an IGMP membership report is received from a host on a directly connected subnet




 * The (*,G) entry was created 8 seconds ago, and will expire in 2:58. Each forwarded packet renews this timer to 3 min.
 * RP is 10.1.10.3, S means sparse mode, C means directly connected neighbor
 * The RPF neighbor is 10.1.6.5, this is chosen based on the path to the RP, not the source
 * The outgoing interface, eth0, has been forwarding for 8 seconds and will be removed as an outgoing interface is no PIM join is received in 2:52

Routers can also perform a switchover to the SPT tree if a more efficient path exists. This is done only after a significant number of packets have been received in a certain time interval. Once the switchover is complete, a prune message is sent to the RP for that specific multicast group and source.

Dynamically locating RPs and Using redundant RPs
AutoRP can be used, but its Cisco only. Anycast RP with Multicast Source Discovery Protocol can be used for redundancy.

Bootstrap router protocol can be used for all vendors. This can also be used for redundant RPs

Bootstrap Router Protocol
One router acts as the BSR, which receives mapping information from the other RPs. The BSR does not pick the best RP, but sends all mapping information to other PIM routers to let them decide. The mappings are sent to the all PIM routers multicast address. PIM-SM routers forward the mappings out all non RPF interfaces. Candidate RPs send their information to the BSR. Multiple BSRs can be configured, and an election will occur.

Bidirectional PIM can be used to increase efficiently of larger networks.

=Command Reference=



=MBGP=

MBGP adds the ability for BGP to carry multicast routes into AS'. These routes are then used by PIM for both routing and RPF checks. To configure MBGP, you must enable BGP as normal and then declare the neighbor as a MBGP neighbor with the command:

//**#neighbor {ip-address | peer-group-name} remote-as number nlri multicast**//  You can declare MBGP peer groups with: //**#neighbor peer-group-name peer-group nlri multicast **// Multicast networks to be locally injected are declared with: //**#network [mask ] nlri multicast**//

Mostly, all commands are the same except you add nlri multicast to the end. This includes the aggregate address command. You can use route maps to match multicast routes with the #match nlri multicast option.