Multicast, the strange, the backwards, the elusive. At least that’s what I used to think about it until I spent some time taking it out to dinner, listening to it, and developing a strong relationship with it. I have Peter Revill and his awesome four part series to thank for that (he’s a good wing man!).

In this post I’ll be following along Peter’s Multicast series. If you’re new to multicast, or just want a quick refresher, head on over to his blog and follow us on this journey.  As a bonus, I may throw in some basic NX-OS multicast at the bottom, as it pertains to OTV.

http://www.ccierants.com/2013/02/ccie-dc-multicast-part-1.html
http://www.ccierants.com/2013/02/ccie-dc-multicast-part-2.html
http://www.ccierants.com/2013/02/ccie-dc-multicast-part-3.html
http://www.ccierants.com/2013/02/ccie-dc-multicast-part-4.html

Follow him on twitter via @ccierants

First, a quick refresher on multicast and related terms. Feel free to revisit these as you follow the post.

Multicast

– Multicast is one-to-many, meaning one packet is copied to multiple receivers from a single source
– Multicast traffic is UDP, there is no such thing as return traffic.
– Unlike traditional routing where destination is most important, multicast routing places most importance on the source.

Addressing

224.0.0.0 – 239.255.255.255
– 224.0.1.39 and 224.0.1.40 are used for Cisco Auto-RP Discovery
– 232.0.0.0/8 – Reserved for Source-Specific Multicast (SSM)
– 239.0.0.0/8 – Reserved for private use within an organization (similar to RFC-1918 addresses)

PIM

– PIM – Protocol Independent Multicast
– Most common choice for multicast routing protocol
– PIM relies on the already existing unicast routing table to evaluate its reverse path forward (RPF) checks.
– Source of the multicast traffic is the root of the PIM multicast tree.
– With Sparse mode (the only mode supported on Nexus), multicast is not forwarded unless there are receivers listening.
– PIM Sparse mode uses a Rendezvous Point (RP), whereby all routers indicate there desire to join a particular multicast stream to the RP.
–      The source sends traffic to the RP and the RP forward the traffic.
–      This is known as a Shared Tree
– Remember, in Sparse mode, routers will not forward multicast traffic unless they know someone has asked to join it. The router connected to the source of the multicast traffic will encapsulate/tunnel the traffic to the RP.

IGMP

When a receiver wants to join a multicast group, the closest router to that receiver (also known as the last hop router) will send a message up the tree notifying the RP of the receiver; this is done via IGMP (Internet Group Management Protocol). An IGMP message notifies the router that the host wants to receive the multicast.

You can have a router join a multicast group with:

ip igmp join-group 239.1.1.1 (where 239.1.1.1 is the multicast group you want to join)

A source can start sending multicast traffic to 239.1.1.1 and the router will receive it.

Problems with IGMPv1 and IGMPv2

– Two sources could send to the same multicast address, resulting in receivers receiving two streams.
– A malicious user could send traffic to the multicast group
– RP reliability: We need to ensure that the RP discovers the devices needing to receive multicast traffic, while ensuring the RP receives the first frame from the source to the receiver in order to switch to the shortest path tree.
– Multicast on the Internet – Who runs the RP? How do you trust them? Without an RP, how do you learn about multicast sources and receivers?

IGMPv3

An IGMPv3 packet contains an additional “source” field, telling the router it wants to join the multicast stream, but only from a specific source.

Example:

Router(config-if)#ip igmp version 3
Router(config-if)#ip igmp join-group 232.1.1.1 source 1.1.1.1

– IGMPv3 is especially useful with SSM (Source specific multicast).
– With SSM and IGMPv3, you no longer need an RP. This is because we already know the source of the multicast stream because the receiver told us what it was (1.1.1.1 in the example above).
– SSM enables us to avoid multicast collisions since all entries are (S,G). There is always a specific source, so if someone else wanted to send multicast traffic to the same group, it wouldn’t matter because the receivers are only seeing the SSM (S,G) stream.
– Routers will absolutely not forward any multicast traffic for SSM groups unless they have specifically received a join with the source specified in the message (The exception to this rule is bi-directional PIM).

Auto RP

All PIM enabled routers automatically join the Cisco-RP-Discovery multicast group 224.0.1.40 in order to receive RP mapping information. RP mapping information is sent (sourced) to this group by routers configured as “mapping agents”. Multiple mapping agents are typically configured for redundancy purposes.

A mapping agent also joins the group 224.0.1.39 in order to learn which routers in a network are potentially RPs. Candidate RP’s source their candidacy as an RP to this multicast group by sending an RP_Announce message to this Cisco-RP-Announce group. If multiple RP’s announce their candidacy, highest IP address wins.

The mapping agent then distributes this information to the 224.0.1.40 group as an RP_Discovery message.

The problem with Auto-RP is that the RP information itself is distributed via multicast. PIM sparse mode will not forward multicast since we do not have an RP, we must use PIM dense mode on these groups to propagate across the network. You can verify this by the “D” flag in the mroute table:

(*, 224.0.1.40), 00:26:20/00:02:36, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet1/0, Forward/Sparse, 00:22:19/00:02:32

Following Peter’s “ccierants” Multicast labs:

Quick note before starting, I had to modify the initial configs:
– no shut the interfaces
– “ip pim sparse-mode” on the interfaces (PIM1,PIM2,RP)
– no ip domain lookup

All routers are OSPF adjacent. PIM1, PIM2 and RP are PIM neighbors.

Observing Multicast Shared Trees and Shortest Path Trees

Let’s jump right in an join the multicast group 239.1.1.1.

On Source2Receiver1:

int g1/0
 ip igmp join-group 239.1.1.1

Debug output on PIM2, showing that it received the IGMP join:

*Jul  5 22:25:39.299: PIM(0): Building Triggered (*,G) Join / (S,G,RP-bit) Prune message for 239.1.1.1

Mroute on PIM2:

PIM2#sh ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.1.1.1), 00:08:56/00:02:22, RP 0.0.0.0, flags: SJC
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    GigabitEthernet2/0, Forward/Sparse, 00:08:56/00:02:22

(*, 224.0.1.40), 00:11:16/00:02:23, RP 0.0.0.0, flags: DCL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    GigabitEthernet2/0, Forward/Sparse, 00:11:16/00:02:23 

The (*,224.0.1.40) entry is for Auto-RP Discovery listening group, which we’re now worried about right now.

PIM2 will forward all traffic for group 239.1.1.1 to the outgoing interface Gi2/0, but since there is no incoming traffic for this group the incoming interface is NULL.

The flags SJC:

S = Sparse
C = Connected (meaning there is a receiver connected to one of the local interfaces)
J = Join

The J flag says that, as soon as this router see’s traffic come in from a source for this particular group, it will immediately switch to a SPT (Shortest Path Tree) by sending a join message up the PIM domain to that particular source.

Configure a Rendezvous Point (RP) in order to forward traffic in the PIM domain. First remove the igmp join, and clear the mroute table on PIM2.

Source2Receiver1(config)#int gi1/0
Source2Receiver1(config-if)#no ip igmp join-group 239.1.1.1

PIM2#clear ip mroute *

Specify a loopback on the RP Router to act as our RP:

RP(config-if)#int lo1
RP(config-if)#ip add 3.3.3.3

Specify this as our RP on our PIM2 Router:

PIM2(config)#ip pim rp-address 3.3.3.3
PIM2(config)#
*Jul  7 15:40:57.421: PIM(0): Check RP 3.3.3.3 into the (*, 224.0.1.40) entry
*Jul  7 15:40:57.421: PIM(0): Building Triggered (*,G) Join / (S,G,RP-bit) Prune message for 224.0.1.40
*Jul  7 15:40:57.425: PIM(0): Insert (*,224.0.1.40) join in nbr 10.2.0.2's queue
*Jul  7 15:40:57.429: PIM(0): Building Join/Prune packet for nbr 10.2.0.2
*Jul  7 15:40:57.429: PIM(0): Adding v2 (3.3.3.3/32, 224.0.1.40), WC-bit, RPT-bit, S-bit Join
*Jul  7 15:40:57.429: PIM(0): Send v2 join/prune to 10.2.0.2 (GigabitEthernet1/0)

Let’s see what happens when we tell the receiver to join the group again:

Source2Receiver1(config)#int gi1/0
Source2Receiver1(config-if)#ip igmp join-group 239.1.1.1

Pim2:

*Jul  7 15:42:41.841: PIM(0): Check RP 3.3.3.3 into the (*, 239.1.1.1) entry
*Jul  7 15:42:41.845: PIM(0): Building Triggered (*,G) Join / (S,G,RP-bit) Prune message for 239.1.1.1
*Jul  7 15:42:41.845: PIM(0): Insert (*,239.1.1.1) join in nbr 10.2.0.2's queue
*Jul  7 15:42:41.849: PIM(0): Building Join/Prune packet for nbr 10.2.0.2
*Jul  7 15:42:41.849: PIM(0): Adding v2 (3.3.3.3/32, 239.1.1.1), WC-bit, RPT-bit, S-bit Join
*Jul  7 15:42:41.853: PIM(0): Send v2 join/prune to 10.2.0.2 (GigabitEthernet1/0)

A join message has been successfully sent to the RP from PIM2. We now know where the shared tree is, so we have now sent a message towards the RP saying we have a receiver for group 239.1.1.1, so as soon as you get traffic for it, send it to me.

Let’s Examine the Entry:

Pim 2 (show ip mroute):

(*, 239.1.1.1), 00:01:14/00:02:26, RP 3.3.3.3, flags: SJC
  Incoming interface: GigabitEthernet1/0, RPF nbr 10.2.0.2
  Outgoing interface list:
    GigabitEthernet2/0, Forward/Sparse, 00:01:14/00:02:26  

Break this down:

(*,239.1.1.1)

Shared trees have the notation (*,G), indicating that the source “*” could be anything going to the group “G”.
Shortest Path Trees have the notation (S,G), indicating that the source “S” is the IP address of the actual source of the multicast traffic, going to the group “G”.

RP 3.3.3.3

Indicates the RP’s address, considered to be the root of the tree.

RPF nbr 10.2.0.2

Indicates the reverse path forward neighbor PIM has determined via the unicast table as the next hop to the RP. This is the RP’s interface address.

GigabitEthernet2/0

Shows which interface multicast traffic will be forwarded to (facing the RP).

Now, lets look at the mroute table on the RP:

(*, 224.0.1.40), 00:05:39/00:02:39, RP 0.0.0.0, flags: DCL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    GigabitEthernet1/0, Forward/Sparse, 00:05:39/00:02:39

It’s missing the route for group 239.1.1.1. Looking at the logs, you’ll see this:

*Jul  7 15:40:57.497: %PIM-6-INVALID_RP_JOIN: Received (*, 224.0.1.40) Join from 10.2.0.1 for invalid RP 3.3.3.3

You must tell the RP itself that it is the RP

RP(config)#ip pim rp-address 3.3.3.3

We have PIM traffic, and an updated mroute table:

*Jul  7 15:50:34.645: PIM(0): Received v2 Join/Prune on GigabitEthernet2/0 from 10.2.0.1, to us
*Jul  7 15:50:34.645: PIM(0): Join-list: (*, 239.1.1.1), RPT-bit set, WC-bit set, S-bit set
*Jul  7 15:50:34.649: PIM(0): Check RP 3.3.3.3 into the (*, 239.1.1.1) entry
*Jul  7 15:50:34.649: PIM(0): Add GigabitEthernet2/0/10.2.0.1 to (*, 239.1.1.1), Forward state, by PIM *G Join
*Jul  7 15:50:44.953: PIM(0): Received v2 Join/Prune on GigabitEthernet2/0 from 10.2.0.1, to us
*Jul  7 15:50:44.953: PIM(0): Join-list: (*, 224.0.1.40), RPT-bit set, WC-bit set, S-bit set
*Jul  7 15:50:44.957: PIM(0): Add GigabitEthernet2/0/10.2.0.1 to (*, 224.0.1.40), Forward state, by PIM *G Join

(*, 239.1.1.1), 00:00:38/00:02:51, RP 3.3.3.3, flags: S
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    GigabitEthernet2/0, Forward/Sparse, 00:00:38/00:02:51

Go ahead and configure the RP address on PIM1. Now initiate a ping from Source1 to the Multicast address 239.1.1.1

Source1Receiver2#ping 239.1.1.1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:

Reply to request 0 from 2.2.2.1, 68 ms 

PIM2(config)#do sh ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.1.1.1), 00:10:49/stopped, RP 3.3.3.3, flags: SJC
  Incoming interface: GigabitEthernet1/0, RPF nbr 10.2.0.2
  Outgoing interface list:
    GigabitEthernet2/0, Forward/Sparse, 00:10:49/00:02:29

(1.1.1.1, 239.1.1.1), 00:00:07/00:02:52, flags: J
  Incoming interface: GigabitEthernet3/0, RPF nbr 10.0.0.1
  Outgoing interface list:
    GigabitEthernet2/0, Forward/Sparse, 00:00:07/00:02:52

(*, 224.0.1.40), 00:12:55/00:02:31, RP 3.3.3.3, flags: SJCL
  Incoming interface: GigabitEthernet1/0, RPF nbr 10.2.0.2
  Outgoing interface list:
    GigabitEthernet2/0, Forward/Sparse, 00:12:55/00:02:31 

We now have a (S,G) (shortest path tree) for (1.1.1.1,239.1.1.1). The incoming interface is Gi3/0, which faces towards the PIM1 Router, completely bypassing the RP!

The green arrows show our efficient multicast delivery, we only use the shared tree to learn the source of the multicast, once we know the source we create an SPT Tree back to it. This is known as the SPT-Switchover. So now our multicast traffic is NOT being sourced from the RP but rather we received a single frame from the RP, realised what the source is and built a more effective tree.

This can be confirmed on router PIM1 as well:

PIM1(config)#do sh ip mroute
..

(*, 239.1.1.1), 00:00:04/stopped, RP 3.3.3.3, flags: SPF
  Incoming interface: GigabitEthernet2/0, RPF nbr 10.1.0.2
  Outgoing interface list: Null

(1.1.1.1, 239.1.1.1), 00:00:04/00:02:55, flags: FT
  Incoming interface: GigabitEthernet1/0, RPF nbr 0.0.0.0, Registering
  Outgoing interface list:
    GigabitEthernet3/0, Forward/Sparse, 00:00:04/00:03:25
    GigabitEthernet2/0, Forward/Sparse, 00:00:04/00:03:25

We now have a SPT for the (S,G) 1.1.1.1, 239.1.1.1. it’s incoming interface is as we expect, and the outgoing interface is now Gi3/0. Awesome.

Configure IGMPv3

Currently, we’ve been accomplishing this via IGMPv2. We can actually avoid the RP altogether when running IGMPv3 and SSM. In this case, there will be no need for SPT-Switchover, as we will not be initiating the conversation via shared tree. Let’s test this out. First, remove the RP address from all routers.

no ip pim rp-address 3.3.3.3

Configure SSM range on PIM1, PIM2 and RP:

ip pim ssm default

This tells PIM to use the range 232.0.0.0/8 as the SSM range.

Additionally, you’ll need to enable IGMPv3 on the interfaces receiving IGMPv3 packets. Without this enabled, PIM will not know what to do with the message and ignore it.

Receiver1:

interface GigabitEthernet1/0
 ip address 2.2.2.1 255.255.255.0
 ip pim sparse-mode
 ip igmp join-group 232.1.1.1 source 1.1.1.1
 ip igmp version 3

PIM2 before enabling igmp version 3:

*Jul  7 16:16:15.045: IGMP(0): Send v2 general Query on GigabitEthernet1/0
*Jul  7 16:16:15.069: IGMP(0): Received v2 Report on GigabitEthernet2/0 from 2.2.2.1 for 232.1.1.1
*Jul  7 16:16:15.069: IGMP(0): Received Group record for group 232.1.1.1, mode 2 from 2.2.2.1 for 0 sources
*Jul  7 16:16:15.069: IGMP(0): WAVL Insert group: 232.1.1.1 interface: GigabitEthernet2/0Successful
*Jul  7 16:16:15.073: IGMP(0): Group Record mode 2 for SSM group 232.1.1.1 from 2.2.2.1 on GigabitEthernet2/0, ignored

PIM2, enabling igmp version 3:

PIM2(config)#int gi2/0
PIM2(config-if)#ip igmp version 3 

*Jul  7 16:18:00.045: IGMP(0): Send v3 general Query on GigabitEthernet2/0
*Jul  7 16:18:00.045: IGMP(0): Set report delay to 4.7 seconds to respond to General Query on GigabitEthernet2/0
*Jul  7 16:18:01.109: IGMP(0): Received v3 Report for 1 group on GigabitEthernet2/0 from 2.2.2.1
*Jul  7 16:18:01.109: IGMP(0): Received Group record for group 232.1.1.1, mode 1 from 2.2.2.1 for 1 sources
*Jul  7 16:18:01.109: IGMP(0): WAVL Insert group: 232.1.1.1 interface: GigabitEthernet2/0Successful
*Jul  7 16:18:01.109: IGMP(0): Create source 1.1.1.1
*Jul  7 16:18:01.109: IGMP(0): Updating expiration time on (1.1.1.1,232.1.1.1) to 180 secs
*Jul  7 16:18:01.109: IGMP(0): Setting source flags 4 on (1.1.1.1,232.1.1.1)
*Jul  7 16:18:01.109: IGMP(0): MRT Add/Update GigabitEthernet2/0 for (1.1.1.1,232.1.1.1) by 0
*Jul  7 16:18:01.109: PIM(0): Insert (1.1.1.1,232.1.1.1) join in nbr 10.0.0.1's queue
*Jul  7 16:18:01.113: PIM(0): Building Join/Prune packet for nbr 10.0.0.1
*Jul  7 16:18:01.113: PIM(0): Adding v2 (1.1.1.1/32, 232.1.1.1), S-bit Join
*Jul  7 16:18:01.113: PIM(0): Send v2 join/prune to 10.0.0.1 (GigabitEthernet3/0) 

We have received a group request for 232.1.1.1 specifying 1 source – 1.1.1.1. Once the source is known, the router checks to see how it would route to reach 1.1.1.1 (next hop reachability):

PIM2#show ip route 1.1.1.1
Routing entry for 1.1.1.0/24
  Known via "ospf 1", distance 110, metric 2, type intra area
  Last update from 10.0.0.1 on GigabitEthernet3/0, 1d16h ago
  Routing Descriptor Blocks:
  * 10.0.0.1, from 1.1.1.2, 1d16h ago, via GigabitEthernet3/0
      Route metric is 2, traffic share count is 1

It determines the route to 1.1.1.1 is via Gi3/0. A PIM join message is sent up that interface towards the neighbor.

Check out the routing table of the appropriate routers:

PIM2#show ip mroute
..

(1.1.1.1, 232.1.1.1), 00:03:05/00:01:57, flags: sTI
  Incoming interface: GigabitEthernet3/0, RPF nbr 10.0.0.1
  Outgoing interface list:
    GigabitEthernet2/0, Forward/Sparse, 00:03:05/00:01:57

We can see from the above output we now have an entry for the (S,G) 1.1.1.1, 232.1.1.1. Notice the flags sTI:

s = SSM group,
T = SPT-Bit Set (shortest path tree)
I = Receiver asked for a particular source

let’s look at PIM1’s routing table:

PIM1(config)#do sh ip mroute
..

(1.1.1.1, 232.1.1.1), 00:13:42/00:02:38, flags: sT
  Incoming interface: GigabitEthernet1/0, RPF nbr 0.0.0.0
  Outgoing interface list:
    GigabitEthernet3/0, Forward/Sparse, 00:10:41/00:02:38

The tree has been built and we haven’t involved an RP at any point in time!

Let’s try a ping:

Source1Receiver2#ping 232.1.1.1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 232.1.1.1, timeout is 2 seconds:

Reply to request 0 from 2.2.2.1, 80 ms

Success! We have a multicast tree from our source to our receiver.

To prove the concept of SSM, on Source1 create a loopback interface and see if it can reach the receiver…

Source1Receiver2(config)#int lo1
Source1Receiver2(config-if)#ip add 50.50.50.50 255.255.255.255

Source1Receiver2#ping 2.2.2.1 source lo1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.1, timeout is 2 seconds:
Packet sent with a source address of 50.50.50.50
!!!!!

Source1Receiver2#ping 232.1.1.1 source lo1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 232.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 50.50.50.50

Failed. The source has reachability to 2.2.2.1 via 50.50.50.50, but because no multicast groups are setup for this (no receiver asked to join from this source 50.50.50.50), the ping doesn’t work as no multicast tree has been built on PIM1.

PIM1#show ip mroute
..

(1.1.1.1, 232.1.1.1), 00:11:14/00:03:02, flags: sT
  Incoming interface: GigabitEthernet1/0, RPF nbr 1.1.1.1
  Outgoing interface list:
    GigabitEthernet3/0, Forward/Sparse, 00:11:14/00:03:02

Let’s try a few more expirements.

Configure the RP address on RP, PIM1 and PIM2. Use the same 3.3.3.3 loopback address on RP.

ip pim rp-address 3.3.3.3

Now that’s done, lets see what happens when we try and source traffic from 50.50.50.50 again

Source1Receiver2#ping 232.1.1.1 source lo1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 232.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 50.50.50.50

Still failed. The reason is we have set aside this group as an SSM Group, the routers will absolutely not forward any multicast traffic for these groups unless they have specifically received a join with the source specified in the message. Very cool.

If you try to join a group in the SSM range without specifying the source, PIM will ignore the message:

*Jul  7 16:147:01.223: IGMP(0): Group Record mode 4 for SSM group 232.1.1.2 from 2.2.2.1 on GigabitEthernet2/0, ignored

The receiver is asking to join group (*,232.1.1.2), the range 232.0.0.0/8 is a SSM group, so the (*,G), or Any Source Multicast (ASM) IGMP Join request is completely ignored.

Configuring Auto-RP

For more detail on this, please see Peter Revill’s blog post (http://www.ccierants.com/2013/02/ccie-dc-multicast-part-4.html).

Auto-RP is a Cisco-proprietary method for automatically assigning an RP in an network, and relying on mapping agents to relay the information. This is not typically used in production environments. To get this to function, we will remove all rp-address configuration from the devices, clear the mroute table and start from scratch.

Configure the RP router to announce itself as an RP candidate:

RP(config)#interface loop 1
RP(config-if)#ip pim sparse-mode
RP(config-if)#exit  
RP(config)#ip pim send-rp-announce loop1 scope 4

Configure PIM2 as the mapping agent:

PIM2(config)#ip pim send-rp-discovery scope 4

Verify on PIM1 and PIM2 that they have received the RP information:

PIM1#sh ip pim rp mapping
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
  RP 3.3.3.3 (?), v2v1
    Info source: 10.0.0.2 (?), elected via Auto-RP
         Uptime: 00:00:19, expires: 00:02:39
 
PIM2#sh ip pim rp mappi
PIM Group-to-RP Mappings
This system is an RP-mapping agent

Group(s) 224.0.0.0/4
  RP 3.3.3.3 (?), v2v1
    Info source: 3.3.3.3 (?), elected via Auto-RP
         Uptime: 00:00:40, expires: 00:02:16  

Anycast RP / MSDP

Anycast RP uses the unicast routing table to provide RP redundancy. With Anycast RP, multiple routers in the multicast networks share the same loopback address used as the RP. PIM devices will route multicast traffic to the closest RP, and if one fails, dynamic routing will direct traffic to the next closest RP.

New topology, notice the 2 RPs and a single source connected to both.

On RP1 and RP2 define a loopback address:

interface Loop1
 ip address 4.4.4.4 255.255.255.255

Next, we go to our source and check it’s route to 4.4.4.4:

source#show ip route 4.4.4.4
Routing entry for 4.4.4.4/32
  Known via "ospf 1", distance 110, metric 2, type intra area
  Last update from 10.1.0.1 on GigabitEthernet1/0, 00:00:12 ago
  Routing Descriptor Blocks:
  * 10.2.0.1, from 10.2.0.1, 00:00:59 ago, via GigabitEthernet2/0
      Route metric is 2, traffic share count is 1
    10.1.0.1, from 10.1.0.1, 00:00:12 ago, via GigabitEthernet1/0
      Route metric is 2, traffic share count is 1

We have equal cost paths to 4.4.4.4. This is fine, bur for sake of understanding AnyCast RP failure scenarios, let’s prefer the path to RP2:

interface GigabitEthernet1/0
 ip ospf cost 20000
end

source#show ip route 4.4.4.4
Routing entry for 4.4.4.4/32
  Known via "ospf 1", distance 110, metric 2, type intra area
  Last update from 10.2.0.1 on GigabitEthernet2/0, 00:01:10 ago
  Routing Descriptor Blocks:
  * 10.2.0.1, from 10.2.0.1, 00:01:57 ago, via GigabitEthernet2/0
      Route metric is 2, traffic share count is 1

Perfect. Now, on each RP router, configure 4.4.4.4 as the rp-address. Good thing to note is Anycast can work with Auto-RP or BSR, the only different is the same RP IP address exists on multiple RPs.

RP1(config)#ip pim rp-address 4.4.4.4
RP2(config)#ip pim rp-address 4.4.4.4 

On receiver1 and receiver2 let’s join the multicast group 239.1.1.1:

Receiver1(config-if)#ip igmp join-group 239.1.1.1 
Receiver2(config-if)#ip igmp join-group 239.1.1.1

Done, let’s now look at the routing tables of RP1 and RP2:

RP1#show ip mroute
IP Multicast Routing Table

(*, 239.1.1.1), 00:00:44/00:02:15, RP 4.4.4.4, flags: SJC
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    GigabitEthernet1/0, Forward/Sparse, 00:00:44/00:02:15

RP2#show ip mroute
(*, 239.1.1.1), 04:34:41/00:02:11, RP 4.4.4.4, flags: SJC
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    GigabitEthernet2/0, Forward/Sparse, 04:34:41/00:02:11

Both RP1 and RP2 are showing an outgoing interface for the traffic for 239.1.1.1, Great! Let’s try a ping from the source now.

source#ping 239.1.1.1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:

Reply to request 0 from 2.2.2.1, 52 ms

Only 1 response is received. There are 2 receivers, so we should have seen 2 responses. Since the RP’s are not aware of each other’s sources, Receiver1 connected to RP1 did not receive the traffic since RP1 does not know about the source.

Multicast Source Discovery Protocol (MSDP) is used to resolve this problem. MSDP discovers sources, and shares the information with other RPs. Establish an MSDP relationship between the RPs:

RP1(config)#ip msdp peer 2.2.2.2 connect-source gi3/0
RP1(config)#ip msdp originator-id gi3/0
 
RP2(config)#ip msdp peer 1.1.1.2 connect-source gi3/0
RP2(config)#ip msdp originator-id gi3/0

Verify the peer relationship between the two over MSDP:

RP1#show ip msdp sum
MSDP Peer Status Summary
Peer Address     AS    State    Uptime/  Reset SA    Peer Name
                                Downtime Count Count
2.2.2.2          ?     Up       00:00:25 0     0     ?

Now ping 239.1.1.1 from the source:

source#ping 239.1.1.1 source gi1/0
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 10.1.0.2

Reply to request 0 from 1.1.1.1, 52 ms
Reply to request 0 from 2.2.2.1, 92 ms

Success!

Here are few show commands (output straight from Peter’s blog):

RP2#show ip msdp peer
MSDP Peer 1.1.1.2 (?), AS ?  Connection status:
    State: Up, Resets: 0, Connection source: GigabitEthernet2/0 (2.2.2.2)
    Uptime(Downtime): 00:00:17, Messages sent/received: 1/2
    Output messages discarded: 0
    Connection and counters cleared 00:01:17 ago
  SA Filtering:
    Input (S,G) filter: none, route-map: none
    Input RP filter: none, route-map: none
    Output (S,G) filter: none, route-map: none
    Output RP filter: none, route-map: none
  SA-Requests:
    Input filter: none
  Peer ttl threshold: 0
  SAs learned from this peer: 1  Number of connection transitions to Established state: 1
    Input queue size: 0, Output queue size: 0
  MD5 signature protection on MSDP TCP connection: not enabled
  Message counters:
    RPF Failure count: 0
    SA Messages in/out: 1/0
    SA Requests in: 0
    SA Responses out: 0
    Data Packets in/out: 0/0

We can see from the above that we have peer’d with the other RP and that there is an active source address that we are caching

RP2#show ip msdp sa-cache
MSDP Source-Active Cache - 1 entries
(10.1.0.2, 239.1.1.1), RP 1.1.1.2, AS ?,00:01:18/00:05:40, Peer 1.1.1.2

Now if we check the show ip mroute for that entry

(10.1.0.2, 239.1.1.1), 00:01:34/00:01:25, flags: M
  Incoming interface: GigabitEthernet3/0, RPF nbr 10.0.0.1
  Outgoing interface list:
    GigabitEthernet2/0, Forward/Sparse, 00:01:34/00:02:36

There is an entry for this source with the “M” flag set.

M = MSDP created entry

You can take this one step further by requiring authentication prior to MSDP communications. Set a password on the MSDP peer:

RP1(config)#ip msdp password 2.2.2.2 PASSWORD
RP2(config)#ip msdp password 1.1.1.2 PASSWORD

NX-OS – AnyCast

In the NX-OS world, we actually have an Anycast protocol, and no longer need MSDP.  You simply configure the AnyCast RP address and the member addresses.

Nexus-1:
ip pim anycast-rp 4.4.4.4 1.1.1.2
ip pim anycast-rp 4.4.4.4 2.2.2.2


Nexus-2:
ip pim anycast-rp 4.4.4.4 1.1.1.2
ip pim anycast-rp 4.4.4.4 2.2.2.2

4.4.4.4 is your actual RP address, and 1.1.1.2 is an IP address of the nexus itself (you must specify yourself as being an RP Candidate) and 2.2.2.2 is the other RP Candidate.

NX-OS – Multicast as it pertains to OTV (Bonus section)

Although Unicast is fully supported (Adjacency server mode), Multicast is the recommended transport for OTV.  With the information learned above, we will build a multicast-enabled transport for OTV based upon Cisco requirements and recommendations.

When configuring OTV, you have two separate multicast groups to worry about – control and data.

Control

• This Any Source Multicast (ASM) group advertises MAC address reachability information to remote OTV Edge devices.
• Used to establish an adjacency with other OTV Edge Devices.
• For the ASM control group, use a group in the private range 239.0.0.0/8

Data

• This Source Specific Multicast (SSM) group encapsulates underlying multicast traffic that needs to traverse the OTV overlay.  If you have multicast sources in one Data Center and receivers in another Data Centers – this is how you extend this communication encapsulated over the IP network.
• For example, used when you have a multicast source activated in Data Center 1 that starts streaming traffic to multicast group (G) located in Data Center 2 over OTV.

Note: Normal unicast forwarding works by checking the CAM table, which has been populated via the multicast control-plane.  The multicast data group is only used for multicast traffic, not unicast.

• OTV edge devices act as multicast sources and receivers simultaneously.
• Do not enable PIM on the join interface, it is not required.
• PIM sparse-mode needs to be enabled on the upstream router interface, and along the network path between OTV Edge Devices
• Configure the SSM group range to be used for multicast encapsulation.
• This should be in the 232.0.0.0/8 range.  This is the configured range by default in NXOS, but always verify in case someone modified it.
• IGMPv3 will need to be enabled on the join interface and upstream router interface in order for the OTV Edge Device to behave as a multicast SSM host.
• An RP must be defined.  Recommended to deploy at least two RPs for redundancy
• Best practice to use AnyCast RP
• With NXOS, we can configure anycast-rp without the need for MSDP protocol or MSDP cache.  This will result in native PIM between the RPs with the (S,G)’s added straight to the PIM/MRIB tables.
• Can be configured statically, or distributed dynamically via Auto-RP or BSR.  Auto-RP and BSR and disabled by default in NXOS.
• OTV Edge Devices send an IGMP report to join the specific ASM group used to carry the control protocol exchanges.

Sample OTV configuration as it pertains to multicast:

OTV-1

interface overlay1
 otv control-group 239.1.1.1
 otv data-group 232.1.1.0/24

interface eth3/1
 description OTV Join Interface
 ip igmp version 3

OTV-2

interface overlay1
 otv control-group 239.1.1.1
 otv data-group 232.1.1.0/24

interface eth3/1
 description OTV Join Interface
 ip igmp version 3 

Upstream-Router_OTV-1

feature pim

interface eth3/10
 description To OTV Join Interface
 ip pim sparse-mode
 ip igmp version 3 

ip pim rp-address 4.4.4.4 group-list 224.0.0.0/4
ip pim ssm range 232.0.0.0/8 

Upstream-Router_OTV-2

feature pim

interface eth3/10
 description To OTV Join Interface
 ip pim sparse-mode
 ip igmp version 3  

ip pim rp-address 4.4.4.4 group-list 224.0.0.0/4
ip pim ssm range 232.0.0.0/8 
 
NXOS-RP1:

feature pim

interface loop0
 ip address 1.1.1.1 255.255.255.255
 ip pim sparse-mode

interface loop1
 ip address 4.4.4.4 255.255.255.255
 ip pim sparse-mode

ip pim rp-address 4.4.4.4 group-list 224.0.0.0/4
ip pim ssm range 232.0.0.0/8

ip pim anycast-rp 4.4.4.4 1.1.1.1
ip pim anycast-rp 4.4.4.4 2.2.2.2


NXOS-RP2:

feature pim

interface loop0
 ip address 2.2.2.2 255.255.255.255
 ip pim sparse-mode

interface loop1
 ip address 4.4.4.4 255.255.255.255
 ip pim sparse-mode

ip pim rp-address 4.4.4.4 group-list 224.0.0.0/4
ip pim ssm range 232.0.0.0/8

ip pim anycast-rp 4.4.4.4 1.1.1.1
ip pim anycast-rp 4.4.4.4 2.2.2.2