05-07-2009 04:52 AM - edited 03-06-2019 05:35 AM
Hi everybody,
I have a problem with multicast-routing:
We have 2 Core-Switches running sparse-dense-mode and auto-rp. The streaming device has its own VLAN and is directly connected. Client-PCs in other directly connected VLANs can receive the stream.
We also have a L3-distribution-switch and clients connected to its VLANs can't receive the stream.
There is a (*,G)-entry but no (S,G).
I've been troubleshooting for a while and found out that the problem's related to HSRP configured on the Core-Switches. When I remove the HSRP-configuration (or configure VRRP with the same virtual and physical IP-Address), it works perfectly.
Running pure Dense-Mode is another workaround - it even works with HSRP.
The output of "show ip mroute ... count" ist interesting.
1. Without HSRP:
core_1#show ip mroute 225.225.225.1 count
IP Multicast Statistics
6 routes using 4042 bytes of memory
4 groups, 0.50 average sources per group
Forwarding Counts: Pkt Count/Pkts(neg(-) = Drops) per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)
Group: 225.225.225.1, Source count: 1, Packets forwarded: 534933, Packets received: 537349
RP-tree: Forwarding: 0/0/0/0, Other: 0/0/0
Source: 189.193.189.4/32, Forwarding: 534933/585/1355/6346, Other: 537349/0/2416
2. With HSRP:
core_1#show ip mroute 225.225.225.1 count
IP Multicast Statistics
6 routes using 3678 bytes of memory
4 groups, 0.50 average sources per group
Forwarding Counts: Pkt Count/Pkts(neg(-) = Drops) per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)
Group: 225.225.225.1, Source count: 1, Packets forwarded: 0, Packets received: 9687
RP-tree: Forwarding: 0/0/0/0, Other: 0/0/0
Source: 189.193.189.4/32, Forwarding: 0/-501/0/0, Other: 9687/0/9687
I do not understand why there are drops when using HSRP. From my point of view it doesn't seem to be a RPF-Problem.
Any suggestions?
Thanks,
Rolf
Solved! Go to Solution.
05-08-2009 08:13 AM
Hello Rolf,
yes the ip mroute is for the source of the multicast group sorry I didn't write it!
I think the problem is related to RPF check even if it not showed:
For PIM SM one of its upstream neighbors has to be also the RPF neighbor (the one that provides the best unicast route for the route) and when using HSRP no pim neighbors uses the HSRP VIP address.
in other words as you have seen the downstream device would like to send a PIM join to RPF neighbor but
RPF neighbor = HSRP addres <> PIM neighbor addresses
Useful documents for multicast troubleshoting
http://www.cisco.com/en/US/tech/tk828/technologies_tech_note09186a0080094b55.shtml
I've found the document that explains the problem with HSRP
http://www.cisco.com/en/US/tech/tk828/technologies_tech_note09186a0080094aab.shtml
As I've guessed above the problem is:
The reason the HSRP standby address is not listed as a PIM neighbor is because the two routers running HSRP (Routers 2 and 3) will not source the PIM neighbor messages from the HSRP standby address.
The suggestion is to use a dynamic unicast routing protocol
Hope to help
Giuseppe
05-07-2009 04:59 AM
Hello Rolf,
see the following
http://www.cisco.com/en/US/tech/tk648/tk362/technologies_tech_note09186a0080094afd.shtml#t6
you may need to be sure that PIM DR and HSRP active are the same device
Hope to help
Giuseppe
05-07-2009 06:11 AM
Giuseppe,
thanks for your response.
I changed the IP-Addresses so that the Core-Switch is now DR and HSRP active.
Unfortunately streaming still doesn't work, mpackets are still dropped.
05-07-2009 11:18 AM
Hello Rolf,
I've read your initial post again.
You say that:
with VRRP that uses the same ip address of the interface you don't see any problem.
or
by using ip pim dense mode.
the difference between VRRP and HSRP is that.
With VRRP you have an ip next-hop (the VRRP address) that matches the source address of pim messages heard on the lan segment.
With HSRP you have an ip next-hop for which no pim messages are heard.
This could cause some problems in some checks that should be related to RPF.
but no rpf errors are reported.
What if you add an ip mroute for the Group source pointing to the HSRP VIP or to the interface address (just to see if something changes).
and
sh ip mroute group shows an empty olist ?
Hope to help
Giuseppe
05-08-2009 12:34 AM
I tried a lot of configuring static mroutes without seeing any success, but I'm not sure if I was really doing the right things...
But: I added a static Default-(Unicast)-Route pointing to the physical IP-Address (no the HSRP-Address) and doing so it works!
Of course this is not a workable solution for my problem but at least it's interesting.
I also traced PIM-Traffic with Wireshark. Result: When I run HSRP, I don't see any PIM Joins for the MC-stream (-> 224.0.0.13) leaving the outgoing interface of the Distribution-Switch.
05-08-2009 05:42 AM
Little step forward now:
I wanted to know what network/ip-address exactly needs a unicast-route pointing to the physical neighbor-address (instead of the HSRP-Address) to make it work. It's the IP-Address of the streaming device itself! So I removed the new default-route and added instead a hostroute for the streaming-device and now the clients connected to the distribution-switch receive the stream! This is still not really a workable solution for larger LANs but I think I'm very close on the cause now.
05-08-2009 08:13 AM
Hello Rolf,
yes the ip mroute is for the source of the multicast group sorry I didn't write it!
I think the problem is related to RPF check even if it not showed:
For PIM SM one of its upstream neighbors has to be also the RPF neighbor (the one that provides the best unicast route for the route) and when using HSRP no pim neighbors uses the HSRP VIP address.
in other words as you have seen the downstream device would like to send a PIM join to RPF neighbor but
RPF neighbor = HSRP addres <> PIM neighbor addresses
Useful documents for multicast troubleshoting
http://www.cisco.com/en/US/tech/tk828/technologies_tech_note09186a0080094b55.shtml
I've found the document that explains the problem with HSRP
http://www.cisco.com/en/US/tech/tk828/technologies_tech_note09186a0080094aab.shtml
As I've guessed above the problem is:
The reason the HSRP standby address is not listed as a PIM neighbor is because the two routers running HSRP (Routers 2 and 3) will not source the PIM neighbor messages from the HSRP standby address.
The suggestion is to use a dynamic unicast routing protocol
Hope to help
Giuseppe
05-08-2009 08:55 AM
Giuseppe,
thank you very much for the second link - it explains the issue very understandable!
Seems like I didn't use the right keywords searching on cisco.com :-)
Mille Grazie!
Rolf
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: