Multicast mega notes - CCIE Written

With under a week to go until my CCIE written test it’s time to go over my notes and get some of them written up to get them fresh in my mind. Todays notes of choice are my multicast notes.

The notes may be a little sparse in places so if you can add anything or spot any mistakes please let me know.

Multicast notes #

Common Multicast addresses #

Multicast address types and ranges #

• Local network – Addresses in the 224.0.0.0 – 224.0.0.255 are assigned by IANA and are designated for applications that are to be used in the local network only and are to not be routed on the internet.
• Internetwork control block – Addresses in the range 224.0.1.0 – 224.0.1.255 are assigned by IANA and are designated for the use of applications that should be routed over the internet (such as NTP, 224.0.1.1).
• SSM address block – Addresses in the range 232.0.0.0/8 are reserved for the use by source-specific multicast applications.
• GLOP addresses – Addresses in the range 233.0.0.0/8 are reserved for use by organizations who have been allocated an AS number, the second and third octets of the address are made from the 16-bits of the AS number.
• Admin scoped addresses – The 239.0.0.0/8 range is considered private (much like the RFC1918 unicast address ranges) and therefore should NOT be see routing on the internet.

PIM (Protocol Independent Multicast) #

• Protocol independent means that it doesn’t matter which type of unicast routing protocol you use underneath.
• There are other multicast routing protocols that do rely on particular routing protocols like M-OSPF (multicast OSPF).
• There are 3 different types of PIM that are used, these are: Sparse mode, dense mode and sparse-dense mode.
• Sparse mode supports two types of trees, the (*,G) tree and the (S,G) tree. The latter is more efficient as the traffic travels along the shortest path (also known as the SPT) whereas the shared tree can travel along a less than ideal route to the destination.
• Dense mode as default runs in a (S,G) mode as it floods all traffic throughout the domain however this is less than ideal as it means that traffic can be flooded to places that do not need it. Dense mode does allow for traffic to be pruned however this is only a temporary action and therefore needs to be constantly refreshed.
• On a shared LAN segment if there a multiple PIM routers then only one of them will forward the join/prune messages towards the RP, this role is called the ‘Designated Router’ and is elected by virtue of whoever has the highest IP is the DR.

BiDir-PIM (Bi-directional PIM) #

This is a slight alteration on the usual sparse mode of PIM. Bidir-PIM disables the use of (S,G) trees and forces the use of (*,G) trees throughout the domain.

Doing this means that all traffic always has to go through the RP and therefore the placement of this is important in this mode.

Bidir-PIM is useful when you have a lot of multicast sources/listeners as it lessens the strain on the RP (it doesn’t have to build an (S,G) tree for each source.

In Bidir-PIM there is a Designated Forwarder (DF), this role is determined by whichever advertises the lower cost route to reach the RP, this ensures a loop free topology.

RPF (Reverse Path Forwarding) #

The RPF check is the primary loop prevention mechanism in multicast.

Because multicast packets could arrive at a router from multiple directions it needs to decide which path to listen to and which to ignore.

To do this it looks at the Unicast IP that sourced the packet and looks this IP up in the Unicast routing table to see which interface it would usually use to forward traffic to that destination.

Once it has checked this in the routing table it then only accepts multicast packets from that interface.

One way to get around RPF issues would be to ensure that all interfaces on both devices are in the multicast domain however this may not be allowed.

Another way would be to use a static multicast route:

ip mroute [ip address of source] [mask] [incoming interface]

PIM Sparse Mode (PIM-SM) #

Messages process #

Sources #

• Don’t need to run IGMP/PIM, they just need to blindly start to send traffic to the destination group address.
• The first hop router (DR) will see this traffic and then send a PIM register message toward the RP.
• The RP acknowledges this with a ‘register stop’ message.
• The RP then has a (S,G) entry in its mrouting table.

Receivers #

• Hosts send an IGMP Join message on their local LAN.
• The PIM DR (last hop router) turns this into a PIM Join message and sends it off toward the RP.
• Every router along the way adds the relevant interface (back toward the receiver) to its OIL (outgoing interface list) for this particular (*,G) entry.

Converging / Merging the two trees #

• Once the RP knows about both the sender and the receiver the RP sends a PIM Join message towards the source.
• All routers in the reverse path tree from the RP to the source install a (*,G) with the OIL including the interface back towards the RP.
• Once the (S,G) data starts to flow, the tree is built end-to-end through the RP.

Joining the SPT #

• The path that the data takes from the sender to the receiver may be less than ideal, for example it may take 10-hops to go through the RP whereas there is a more direct route that would only take 3-hops.
• This means that the shared tree is actually made of two different trees: Receiver -> RP, RP -> Sender
• To fix this, the last-hop router can join the source tree directly. It joins the (S,G) by sending a PIM Join toward the source. It also leaves the RPT by sending a (*,G) prune toward the RP.
• This behaviour of joining the source tree can be modified by doing: ``` ip pim spt-threshold {kbps | infinity} [group-list access-list]

AutoRP #

This is used so that you do not have to manually set the RP in a sparse-mode multicast network.

There are two different types of AutoRP:

• AutoRP (Cisco proprietary)
• BSR (Bootstrap Router, introduced in PIMv2; not covered in the written exam)

There are two separate parts that make up AutoRP, the mapping agent and the candidate RP’s.

The candidate RP’s communicate with the mapping agent on address 224.0.1.39 and then the mapping agent communicates these mappings out to the rest of the network on 224.0.1.40.

The issue with sparse mode and using AutoRP is that you need multicast to setup multicast, so you end up with a chicken and the egg scenario.

In order to get around this Cisco made two solutions, the first is PIM Sparse-dense mode which allows the interface to run in sparse mode for some groups and dense mode for others.
Any group that has an RP assigned to it will act in sparse-mode and any groups that do not have an RP mapped to them will act in dense mode.

The second solution was a command that Cisco created called:

ip pim auto rp listener

This command allows all groups to run in sparse mode apart from those needed for AutoRP negotiation.

Anycast RP #

This technology is another alternative to setting up the RP’s for sparse mode.

In order for the feature to work it relies on you having multiple RP’s in the network all configured with the same IP address.

Once you have the addresses configured and distributed into the unicast routing table it will mean that a particular source or listener will always connect to the RP closest to it (according to unicast metric).

One issue that can arise is that a source could register to one RP and a listener to another, for that reason a protocol called MSDP (multicast source discovery protocol) is used to allow the RP’s to communicate with one another.

To use Anycast RP you just do the following:

ip msdp peer [peer ip] connect-source [interface]
ip msdp originator-id [interface]

IGMP (Internet Group Management Protocol) #

This protocol is used to allow for end hosts to communicate with the router to inform it that it wants to ‘subscribe’ to a multicast group.

There are several versions of IGMP, these are:

• Version 1 – This was the first version and is quite inefficient in its operation.
  One of these inefficiencies is that there is no way for a host to leave a group and therefore it could take up to 3 minutes after the client has stopped listening before the traffic flow will stop.
• Version 2 – This version added feats such as the leave group message which allowed for hosts to communicate to the router that they no longer wished to receive that group traffic.
• Version 3 – This version added support for SSM (source specific multicast) which allows for the client to not only specify the group they want to subscribe to but also the source of that traffic (useful if there are many sources in the same group).

Version 1 & 2 of IGMP are somewhat compatible with one another.

IGMPv2 #

IGMPv2 uses a number of different types of messages, for both hosts and routers:

Hosts #

• Membership report – Used when a host wants to join a group or as a response to a membership query. The destination address of the message is the IP address of the group.
• Version 1 membership report – Used to support backwards compatibility with IGMPv1.
• Leave group – Used to signal that the host wants to stop receiving traffic for that group.

Routers #

• General query – Query to all multicast receivers on a link.
• Group-specific query – Query to a specific group on a link.

IGMPv3 #

IGMPv3 added a couple of new message types and also modified some of those found in IGMPv2, for this reason the two are not backwards compatible.

• Group & Source-specific query – Used so that a router can query which hosts want to receive traffic from a specific source inside a group.
• Filter support – Allows hosts to explicitly filter out traffic from specific sources in a group.
• One-to-many – Allows hosts to create a one-to-one relationship between the source and themselves.