I have suffered the pain of trying to troubleshoot Multicast issues over the past few years (mainly across MPLS), however initially I struggled to find way of generating my own traffic independent of any application that was experiencing issues. Most of the time being the network guy I would not have access to run the application (sender) at one site and the client (receiver) at another site. I also would not be in the position to install my own sender + receiver devices on the network, so I was stuck with the tools available to me on the Cisco routers/switches at each end of the network.
Looking at the http://www.cisco.com/en/US/tech/tk828/technologies_tech_note09186a0080093f21.shtml they assume that you are able to control the sender and receiver; they have not mention two of the most valuable tools in my opinion to begin troubleshooting multicast.
It does mention "show ip mroute count" and "show ip mroute" which are indeed valuable.
Maybe it is my mindset, but I like to see packets move around the network to help me isolate potential issues, therefore in may cases I need to be able to generate packets and see these packets crossing interfaces on the network.
So how do we generate a multicast packet? Easy just use ping. The special thing about a multicast packet is simply its destination address, therefore we can just ping a multicast address and we have a multicast packet. But if you look at the output from ping you never get a response, but thats not the point, ping is simply used to generate traffic not to diagnose that it is crossing the network.
The client application sends igmp join messages out on the network to request that the network send traffic for that specific group onto that network, then the receiving station can listen for the destination address and pickup the multicast traffic. The join message is propagated up/down(I can never remember the direction) the tree based on PIM neighbor relationships and creates a path from the source to the destination
Now you have the sender and receiver (well sort of) the receiver cannot really see much, but using show ip mroute count we can see packet that have traversed a network interface.
I have setup a very basic lab using
[caption id="attachment_251" align="aligncenter" width="300" caption="Multicast1"]
[/caption]
On R4 I have
interface Loopback0
ip address 192.168.1.4 255.255.255.255
ip igmp join-group 239.5.5.5
On R1 I have
R1#ping ip 239.5.5.5 source loop 0 repeat 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 239.5.5.5, timeout is 2 seconds:
Packet sent with a source address of 192.168.1.1
..........
R1#
On R4 I have
R4#show ip mroute count
IP Multicast Statistics
3 routes using 1300 bytes of memory
2 groups, 0.50 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)
Group: 239.5.5.5, Source count: 1, Packets forwarded: 0, Packets received: 10
Source: 192.168.1.1/32, Forwarding: 0/0/0/0, Other: 10/0/10
Group: 224.0.1.40, Source count: 0, Packets forwarded: 0, Packets received: 0
R4#
on R2 I can see the traffic being forward to R4 and not R3
R2#show ip mroute count
IP Multicast Statistics
3 routes using 2296 bytes of memory
2 groups, 0.50 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)
Group: 239.5.5.5, Source count: 1, Packets forwarded: 10, Packets received: 10
Source: 192.168.1.1/32, Forwarding: 10/0/100/0, Other: 10/0/0
Group: 224.0.1.40, Source count: 0, Packets forwarded: 0, Packets received: 0
R2#show ip mroute 239.5.5.5
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, E - Extranet,
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,
V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.5.5.5), 00:00:24/stopped, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/2, Forward/Sparse-Dense, 00:00:24/00:00:00
Ethernet0/1, Forward/Sparse-Dense, 00:00:24/00:00:00
Ethernet0/0, Forward/Sparse-Dense, 00:00:24/00:00:00
(192.168.1.1, 239.5.5.5), 00:00:24/00:02:35, flags: T
Incoming interface: Ethernet0/0, RPF nbr 10.254.254.1
Outgoing interface list:
Ethernet0/1, Prune/Sparse-Dense, 00:00:24/00:02:35 -<<<< Not being sent to R3
Ethernet0/2, Forward/Sparse-Dense, 00:00:24/00:00:00-<<<< Being sent to R4
The purpose of this post is to highlight two important commands that Cisco seem to overlook when it come to multicast troubleshooting. I hope these help you.
Looking at the http://www.cisco.com/en/US/tech/tk828/technologies_tech_note09186a0080093f21.shtml they assume that you are able to control the sender and receiver; they have not mention two of the most valuable tools in my opinion to begin troubleshooting multicast.
- ping
- ip igmp join-group
It does mention "show ip mroute count" and "show ip mroute" which are indeed valuable.
Maybe it is my mindset, but I like to see packets move around the network to help me isolate potential issues, therefore in may cases I need to be able to generate packets and see these packets crossing interfaces on the network.
Ping=Sender
So how do we generate a multicast packet? Easy just use ping. The special thing about a multicast packet is simply its destination address, therefore we can just ping a multicast address and we have a multicast packet. But if you look at the output from ping you never get a response, but thats not the point, ping is simply used to generate traffic not to diagnose that it is crossing the network.
IP igmp join-group = Receiver
The client application sends igmp join messages out on the network to request that the network send traffic for that specific group onto that network, then the receiving station can listen for the destination address and pickup the multicast traffic. The join message is propagated up/down(I can never remember the direction) the tree based on PIM neighbor relationships and creates a path from the source to the destination
show ip mroute count = traffic viewer
Now you have the sender and receiver (well sort of) the receiver cannot really see much, but using show ip mroute count we can see packet that have traversed a network interface.
I have setup a very basic lab using
- ip multicast-routing
- ip pim sparse-dense-mode on each ethernet interface
- eigrp to put everything into routing
[caption id="attachment_251" align="aligncenter" width="300" caption="Multicast1"]
[/caption]On R4 I have
interface Loopback0
ip address 192.168.1.4 255.255.255.255
ip igmp join-group 239.5.5.5
On R1 I have
R1#ping ip 239.5.5.5 source loop 0 repeat 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 239.5.5.5, timeout is 2 seconds:
Packet sent with a source address of 192.168.1.1
..........
R1#
On R4 I have
R4#show ip mroute count
IP Multicast Statistics
3 routes using 1300 bytes of memory
2 groups, 0.50 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)
Group: 239.5.5.5, Source count: 1, Packets forwarded: 0, Packets received: 10
Source: 192.168.1.1/32, Forwarding: 0/0/0/0, Other: 10/0/10
Group: 224.0.1.40, Source count: 0, Packets forwarded: 0, Packets received: 0
R4#
on R2 I can see the traffic being forward to R4 and not R3
R2#show ip mroute count
IP Multicast Statistics
3 routes using 2296 bytes of memory
2 groups, 0.50 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)
Group: 239.5.5.5, Source count: 1, Packets forwarded: 10, Packets received: 10
Source: 192.168.1.1/32, Forwarding: 10/0/100/0, Other: 10/0/0
Group: 224.0.1.40, Source count: 0, Packets forwarded: 0, Packets received: 0
R2#show ip mroute 239.5.5.5
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, E - Extranet,
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,
V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.5.5.5), 00:00:24/stopped, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/2, Forward/Sparse-Dense, 00:00:24/00:00:00
Ethernet0/1, Forward/Sparse-Dense, 00:00:24/00:00:00
Ethernet0/0, Forward/Sparse-Dense, 00:00:24/00:00:00
(192.168.1.1, 239.5.5.5), 00:00:24/00:02:35, flags: T
Incoming interface: Ethernet0/0, RPF nbr 10.254.254.1
Outgoing interface list:
Ethernet0/1, Prune/Sparse-Dense, 00:00:24/00:02:35 -<<<< Not being sent to R3
Ethernet0/2, Forward/Sparse-Dense, 00:00:24/00:00:00-<<<< Being sent to R4
Here is a quick video clip
Summary
The purpose of this post is to highlight two important commands that Cisco seem to overlook when it come to multicast troubleshooting. I hope these help you.
Comments
Post a Comment