At the stage of source registration and switchover PIM, the router can understand that the traffic is duplicated precisely by the source-IP + dest-group combination (one combination but different methods) and router send regiter stop. In situations 3-4, the story is about the same… But will the router prune the flow - unclear.
This is all in general, it refers to the issue of reserving the source, that is… The idea is this: There is 2 mcast src with the same IP and groups. In normal mode, a stream is sent from source 1, and if it fails (the stream from it breaks), traffic from the second source starts to be sent (without restarting vlc and changing the group address. Can this be done?
When R1’s suppression timer is almost expired, it will send a PIM register null packet to check if the RP is still not interested as per below packet capture:
Yes, this is also an encapsulated packet. You can see this from the wireshark capture you posted. Notice that encapsulated within the PIM layer shown above is another IP packet indicated as “Internet Protocol Version 4” with a source and destination IP address of 192.168.1.1 and 239.1.1.1 respectively. That is encapsulated within the PIM message.
Hello Rene/Laz
I have found the below multicast configuration in one of our Nexus 9K switches and I need to convert these configurations for a IOS-XE L3 switch. Would you please explain the below bolded commands to me and if possible, please provide me the IOS equivalent commands for them?
vrf context PROD-VRF
ip pim bsr bsr-candidate loopback0 priority 200
ip pim rp-address 10.1.1.3 group-list 224.0.0.0/4
ip pim bsr rp-candidate loopback1 group-list 224.0.0.0/4 priority 200
ip pim ssm range 232.0.0.0/8
ip pim bsr forward listen
ip pim bfd
ip msdp originator-id loopback0
ip msdp peer 10.1.1.2 connect-source loopback0 remote-as 1
ip msdp password 10.1.1.2 3 gfdsafs546jopjo646d4gfdsgds6546fdg
address-family ipv4 unicast
interface Ethernet1/1
vrf member PROD-VRF
ip address 10.10.10.1/30
ip pim sparse-mode
ip pim hello-authentication ah-md5 3 sg46DSAF46446gefsdf56464sdfdf46
no shutdown
The configuration syntax for multicast for NX-OS and IOS devices is indeed somewhat different. Take a look at this NetworkLessons note on an NX-OS and IOS config comparison that may help you out. I also suggest you do a search online for something like “Cisco NX-OS/IOS Multicast Comparison” and you should find some additional resources that will help you out…
Go over those and if you have any more specific questions, feel free to let us know!
Why is the first entry there? The other outputs make sense to me in terms of (S,G) and incoming/outgoing interfaces, but this one has me confused because I can’t see why it would exist in the first place. The second entry I understand.
Remember in section 1.5 PIM Register Rene issued a ping to 239.1.1.1? That initial ping, which failed, created that first entry for the (*,239.3.3.3) route. R1 received that, encapsulated it and forwards it with a PIM register message to the RP. Of course the RP sends a stop message since there are no multicast hosts receiving it, but the entry has been installed.
Later, H3 will join the group which will eventually create the second entry. Does that make sense?
It still didn’t make sense, so I created a lab to match the one in the course.
After reaching section 1.5 PIM Register and starting a ping, I checked the mroute tables on both R1 and R2. R2’s output made sense. But again, R1 had an entry that I didn’t understand (for the same reason as when 239.3.3.3 was pinged):
The second entry is expected as R1 has a source IP, destination multicast IP, and an incoming interface, but no outgoing interface because the RP doesn’t have any subscribers and hasn’t built a tree to the source yet.
But I don’t understand the first entry (in bold). Why is the incoming interface towards the RP instead of the source?
The only thing I can think is that it is some kind of split-horizon type rule that prunes multicast traffic so it doesn’t get sent back down the path it came from.
Take a look at this debug output that occurs on R1 when the ping is sent to 239.1.1.1 from S1:
R1#
PIM(0): Check RP 2.2.2.2 into the (*, 239.1.1.1) entry
PIM(0): Building Triggered (*,G) Join / (S,G,RP-bit) Prune message for 239.1.1.1
PIM(0): Adding register encap tunnel (Tunnel0) as forwarding interface of (192.168.1.1, 239.1.1.1).
PIM(0): Received v2 Register-Stop on GigabitEthernet0/1 from 2.2.2.2
PIM(0): for source 192.168.1.1, group 239.1.1.1
PIM(0): Removing register encap tunnel (Tunnel0) as forwarding interface of (192.168.1.1, 239.1.1.1).
PIM(0): Clear Registering flag to 2.2.2.2 for (192.168.1.1/32, 239.1.1.1)
First of all keep in mind that R2 is the RP and that is reached via Gi0/1. Also note that when the ping is sent, a register stop is received on Gi0/1 from 2.2.2.2 for the source 192.168.1.1 and for group 239.1.1.1. That is where this particular entry for that particular interface in the mrouting table comes from. Does that make sense?
Just to be sure, I went into the lab and checked this out. I performed pings to multiple multicast addresses, and every time, the group that I pinged was added to the mroute table of R1 with an outgoing interface of Gi0/1. I also did a packet capture and found that the only PIM packets to be exchanged between R1 and R2 were indeed a PIM Register message from R1 to R2, and a Register-stop message from R2 to R1.
So it can be concluded that the information found within either the PIM register message, or the PIM register stop message populated the mroute table.
Strictly speaking, to create a multicast distribution tree and to add routes to the multicast routing table, routers need to exchange PIM messages and participate in the construction of the tree based on the source and group information contained in the messages. PIM join messages are used to build the tree from the receivers towards the source, while PIM register messages are used to build the tree from the source towards the RP or the receivers.
So from this description of how PIM works, there is no reason for these entries to be added to R1.
Now, digging a little deeper we discover that Cisco has not adhered strictly to this way of operation. It seems that Cisco has chosen to use a type of snooping of PIM messages where these exchanges are inspected and any multicast address seen within them is added to the mroute table. In other words, seeing a multicast address within such a message may be interpreted as an indication that this address is present somewhere on the network, so it doesn’t hurt to add it into my mroute table.
It’s worth noting that this behavior is not part of the standard PIM protocol and may vary from device to device and platform to platform. Just to be clear, all of this is based on conjecture and on some non-Cisco documentation that seems to confirm this. I have been unable to find Cisco documentation explicitly supporting what I am proposing, but if anyone does, please share it here.
Can this command ip pim spt-threshold infinity
be put in any router in that RP domain for it to take effect on all routers or do I have to do it manually for each router in the domain?
This command will instruct the local router to always use the RPT, so the command only affects the way that the local router routes multicast traffic. It does not affect other routers in the topology. So this command should be manually applied to all routers where you want this multicast routing behavior to take place. You don’t actually have to do it to all routers, just the ones that won’t benefit from switching over. For example, R3 in the lab would not benefit from switching over to the SPT because it is the same as the RPT, so it would use more memory and resources to achieve the same thing.
More information about the benefits of preventing or delaying the use of the shortest path tree can be found in this Cisco documentation:
If we don’t apply the ip pim spt-threshold infinity command, then R3 will use the SPT. However, the RPT for R3 is the same. So if we leave the default, R3 will have to use more resources to achieve the same thing.
So we apply this command to R3 simply because the RPT for this particular router on this specific topology is exactly the same as the SPT. So it is preferable to use the RPT, which uses fewer resources, and we get the same result. Does that make sense?
I have to troubleshoot Multicast Spare mode Packet loss. this is Voice Multicast. I do not know what it mean.
what command should I use to find where packet loss occur? they told me packet loss happen after 11 sec or minutes. They also capture Wireshark, but this is Mulicast ( I do not see Wireshark yet) , no sequense number, so maybe Wireshark is not helpfull, maybe I look at timestamp to see the gap. Please correct me if I am wrong. PLEASE help.
Can you give us some more information about your particular scenario? So you have a multicast source used for voice applications, and after 11 seconds (or minutes??), you start seeing packet loss on a multicast sparse mode topology, correct? Can you give us some more information about this application and how you are determining that there is packet loss? ΅How do you know you have packet loss? What behavior are you observing? You have to first confirm that this is indeed the problem.
If you have determined that packet loss is indeed the problem, and that the packet loss is taking place in the multicast topology and infrastructure, then you can use some of the following commands to help troubleshoot:
show ip mroute: This command will show you the multicast routing table. You can use it to verify if the multicast traffic is being routed correctly.
show ip pim interface: This command will give you a summary of all the interfaces running PIM. You can use it to verify if PIM is running on the correct interfaces.
show ip igmp groups: This command will show you all the IGMP groups. You can use it to verify if the receivers are joining the correct multicast groups.
show ip pim rp mapping: This command will show you the RP (Rendezvous Point) mapping. You can use it to verify if the multicast group is using the correct RP.
show ip pim neighbor: This command will show you all the PIM neighbors. You can use it to verify if the routers are forming PIM neighbor relationships correctly.
ping multicast group address: This command will help you to verify if the multicast group is reachable.
Keep in mind that multicast typically uses UDP as the upper-layer protocol. TCP is a connection-oriented protocol, meaning it sets up a dedicated connection between two endpoints. Given the nature of TCP, it doesn’t lend itself naturally to multicast’s one-to-many or many-to-many model. Therefore, standard TCP is not used for multicast. Therefore, you won’t see any sequence numbers, or any sessions that you can follow, even if you do use Wireshark to capture packets.
You can also observe packet loss when looking at specific interfaces of network devices. There you can see the counters of problems that may arise so you can identify packet loss (whether it’s multicast or not). But you will have to zero in on the particular part of the network where you see the problem.
I hope this has given you some more information that you can use to further your troubleshooting process. Let us know more information so that we can help you further.
It turns out there is the problem on radio network, not the multicast problem.
But in general, I try to find the way to tell out confidently whether or not Multicast packet loss.
That what I think I should use:
Mstat . This command shows the multicast path in ASCII graphic format. It traces the path between any two points in the network, shows drops and duplicates, TTLs, and delays at each node in the network. It is very useful when you need to locate congestion points in the network or focus on a router with high drop/duplicate counts. Duplicates are indicated in the output as “negative” drops. This will help us to know exact path of packet.
Mtrace . This command shows the multicast path from the source to the receiver, and it traces the path between points in the networks, which shows TTL thresholds and delay at each node. When troubleshoot, use the mtrace command to find where multicast traffic flow stops, to verify the path of multicast traffic, and to identify sub-optimal paths.
Show ip mroute; look at <S,G> group for any NULL interface.
Show ip mroute count; to see any packet drop.
For me, Wireshark will not help us much in this case. Why? b/c it is UDP packet, no sequence number, so loss it is hard to detect, we can use timestamp between each packet to find the loss.
Please tell me what do you think.
So you have a multicast source used for voice applications,
When they talk about voice, I expect protocol like SIP, H.225, RTP, RTCP…, but they told me wireshark only show MULticast. That is confused to me? They figured out the problem before I have a chance to look at.
