cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1535
Views
0
Helpful
7
Replies

Multicast SM dosn't work with virtual Gateways

rolf.fischer_2
Level 1
Level 1

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

1 Accepted Solution

Accepted Solutions

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

View solution in original post

7 Replies 7

Giuseppe Larosa
Hall of Fame
Hall of Fame

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

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.

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

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.

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.

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

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

Getting Started

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:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco