Multicast Lab Nexus: PIM Sparse

This lab is an extension of the IOS Multicast lab in some ways. This lab will explore the Nexus config and commands. The IOS lab explains the PIM modes and shows how PIM and IGMP work with packet captures.
The lab was created quickly using the base config template creator from my Scrapli and Flask project.

The lab is quite basic with four Nexus 9k switches running version 9.3 and two Windows 10 PCs. mcast_server will be the multicast server and mcast_client the client. The lab will allow me to see the multicast working using the Nexus commands.
All of my switchports are in routed mode to keep things as close to the IOS lab as possible.
The last test does cover VLANs for the two Windows PCs and the added link between mcast_nexus1 and 4.

Switch Configuration

The configuratiuon is quite basic and very similar for each switch. As Nexus switches only support PIM Sparse Mode switch mcast_nexus2 will be the rendezvous point.
You can find all the switch configs below

mcast_nexus1

mcast_nexus2

mcast_nexus3

mcast_nexus4

Testing

This testing will follow five stages. Each stage will have the output commands relevant to see what is happening on the relevant switches. Switch mcast_nexus3 will not be used a great deal until the end of this lab where it will become the RP backup, and then primary when mcast_nexus2 is turned off to simulate a failure.
Commands that will be used are below…

No Multicast Traffic

The Windows PCs create a multicast group for the IP 239.255.255.250/32. This is Simple Service Discovery Protocol (SSDP). Ignore this group.

PIM Neighbours

Multicast Routing Table – mroute

Server transmitting Only

This example has the mcast_server only transmitting. The mroute tables will change for only mcast_nexus1 and 2 switches. The only switches won’t have any changes.

mcast_nexus1

This switch now has the new group 239.0.0.1 for the server multicast traffic.

mcast_nexus2

This switch now has the new group 239.0.0.1 for the server multicast traffic. The group shows it can see traffic incoming, from mcast_nexus1 interface. But nothing out going. This is expected

Client Requesting Only

This next test will show what happens when the client is requesting multicast traffic, but the server is not sending. Before this test was started the multicast routing tables were cleared. So they are back to their original state of no multicast traffic being sent/received.

mcast_nexus2

This switch being the RP will be the one to receive any multicast group requests from other switches. Here we see the switch has the (*,G) as there is no source IP sending the multicast traffic for this group.
The outgoing interface (where the traffic is being requested from) is from Eth1/2 which makes this mcast_nexus4 switch.

mcast_nexus2

This switch is the one receiving the IGMP join request from the client. It will then send it on to the RP in the hope that the RP knows and is able to begin forwarding the multicast traffic. In this case, the source is not transmitting and so we will always see the (*,G).

Send/Receive Traffic

This will show the multicast routing table in its full operational state. For both mcast_nexus2 and 4 we will see the (*,G) along with the (S,G) as both switches will know the source IP of 172.16.2.200/32 for the multicast traffic.

mcast_nexus1

mcast_nexus2

mcast_nexus4

For this test I will add in a link between mcast_nexus1 and 4. This will cause the multicast traffic to be directed over this link once mcast_nexus4 learns of the source IP of the server as it is the shortest path. I have details this in another lab for IOS, this is moving from the Shared Tree to the Source Tree.

I have added a new interface to the mcast_nexus1 and 4. The network is 10.1.6.0/24, they are PIM neighbours. Below is the output from mcast_nexus1 only.

The switch from the Shared Tree to the Source Tree using the new 1-.1.6.0/24 interface was almost immediate after traffic started being received by mcast_client.
I captured the traffic on the 10.1.6.0/24 link to show the PIM join messages between mcast_nexus4 and mcast_nexus1.

VLANs! Not Routed Ports

This last test is to see the VLAN configuration. I have created VLANs for the two Windows PCs and the link between mcast_nexus1 and 4 only. The rest of the configuration is as was on routed ports.

Reconfiguration

I reconfigured the ports to be using VLANs with the configs below.

mcast_nexus1

mcast_nexus4

After the reconfiguration, the only major difference was that I needed IGMP snooping enabling on the VLANs for the Windows PCs and then that in the multicast routing table there were VLANs and no interfaces.

mcast_nexus1

mcast_nexus4

VLANs – Switch Running Configuration

mcast_nexus1

mcast_nexus2

mcast_nexus3

mcast_nexus4

Leave a Comment

Your email address will not be published. Required fields are marked *