Multicast in HSRP Environment

Unanswered Question
Jan 27th, 2009

Hi,

I'm currently studying multicast and I'm having a hard time thinking on how it would work on a HSRP environment.

Let's say for example I have 2 VLANs, VLANs 10 and 20. VLAN 10 uses 192.168.10.0/24 and VLAN 20 uses 192.168.20.0/24. The active HSRP MSFC always uses .2 and the standby uses .3. If for example the multicast source is in VLAN 10. Source in VLAN 10 will use a destination MAC that corresponds to the multicast IP it is using so both HSRP MSFCs (I'm assuming both) will receive the traffic. If for example there are no multicast clients in VLAN 20, the MSFC will know this thru IGMP right? If there are no clients that wants to join the group, the MSFC will not forward the traffic in VLAN 20. The IGMP querier will be the active MSFC since it is using a lower IP address which is 192.168.20.2. But for example, 1 host in VLAN 20 wants to join the group, it will send an IGMP membership report to 224.0.0.2 then MSFCs will start forwarding the multicast traffic, but this time, the standby MSFC will forward the traffic since it is the designated forwarder on the LAN because it has a higher IP address which is 192.168.20.3. I don't know if I got this correctly but please correct me if I'm wrong.

My another inquiry is, since the destination MAC address of the multicast source is a multicast MAC, both MSFCs will receive the traffic. Base from the previous scenario, the standby MSFC is the designated forwarder. Will the active router still process the received packets from the source? From what I'm thinking, it is still receiving the traffic in VLAN 10 but it doesn't forward the packets in VLAN 20 because of the Assert message processed in VLAN 20 and they both agree that standby MSFC will be the forwarder.

Please help me. Really having a hard time studying multicast. :-(

Thanks in advance.

John

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Thiago Cardoso Wed, 01/28/2009 - 06:39

Hi John,

I'm confused with so much information you have given.

"The active HSRP MSFC always uses .2 and the standby uses .3."

Well, What's the HSRP IP then? 1?

Let's say that 192.168.10.2 and 192.168.10.3 are the routers, you probably going to setup 192.168.10.1 as the HSRP, right?

"If for example the multicast source is in VLAN 10. Source in VLAN 10 will use a destination MAC that corresponds to the multicast IP it is using so both HSRP MSFCs (I'm assuming both) will receive the traffic"

So, you want to do some kind of Load Sharing? I think the concept of HSRP you got is wrong.

Here's an example of config:

interface Vlan20

description Main Data LAN

ip address 192.168.10.2 255.255.255.0

no ip redirects

standby 20 ip 192.168.10.1

standby 20 priority 130

interface Vlan20

description Main Data LAN

ip address 192.168.10.3 255.255.255.0

no ip redirects

standby 20 ip 192.168.10.1

standby 20 priority 120

The priority field is used to elect the active router and the standby router for the specific group.

So always the 192.168.10.1 will forward the traffic, not both routers.

"Base from the previous scenario, the standby MSFC is the designated forwarder."

The stand by is just standing by if the active drops.

I'm not sure If I understand your questions.

John Patrick Lopez Fri, 01/30/2009 - 23:47

Hi Sir,

I'm not trying to implement HSRP load-balancing here. I'm just trying to interpret what would happen if the source is in a VLAN with HSRP routers/MSFC as a gateway. Since the packet will be sent to multicast MAC, both of the active and standby routers will receive the packet.

My question was, if the designated forwader downstream is the standby MSFC, will the active MSFC still process the multicast packet?!


Thanks.

John

crow930us Wed, 01/28/2009 - 07:37

Multicast packets generated by HSRP are local scope only. The only issues between multicast and HSRP is when a physical address is used instead of a virtual IP address.

http://www.cisco.com/en/US/tech/tk828/technologies_tech_note09186a0080094aab.shtml

When messages are exchanged within HSRP they are sent to multicst IP address 224.0.0.2 port 1985 for everything. within each of those messages the packet identifies the HSRP group and priority. the only two devices sending packets within HSRP are the Active and standby devices. all other devices for the group are only listening for packets.

Only the Active HSRP device uses a virtual MAC address, the standby device uses it's own MAC address.

hth

mlund Fri, 01/30/2009 - 00:36

Hi John

"Source in VLAN 10 will use a destination MAC that corresponds to the multicast IP it is using so both HSRP MSFCs (I'm assuming both) will receive the traffic."

Yes

"If for example there are no multicast clients in VLAN 20, the MSFC will know this thru IGMP right?"

Yes

"If for example there are no multicast clients in VLAN 20, the MSFC will know this thru IGMP right? If there are no clients that wants to join the group, the MSFC will not forward the traffic in VLAN 20."

Yes

"The IGMP querier will be the active MSFC since it is using a lower IP address which is 192.168.20.2. "

Yes

"1 host in VLAN 20 wants to join the group, it will send an IGMP membership report to 224.0.0.2 then MSFCs will start forwarding the multicast traffic,"

No, igmp join is send to the multicastgroup you want to join ex. 239.1.2.3. Report is only send as an answer to a query.

"but this time, the standby MSFC will forward the traffic since it is the designated forwarder on the LAN because it has a higher IP address which is 192.168.20.3."

Yes

"My another inquiry is, since the destination MAC address of the multicast source is a multicast MAC, both MSFCs will receive the traffic."

Yes

"Will the active router still process the received packets from the source?"

Yes, but how they process may be differnet depending on the type of router. I think some routers will process the traffic in cpu, before dropping, others will use hardware to drop. If someone out there know, please jump in and correct/confirm.

"it is still receiving the traffic in VLAN 10 but it doesn't forward the packets in VLAN 20 because of the Assert message processed in VLAN 20 and they both agree that standby MSFC will be the forwarder."

Yes

/Mikael

John Patrick Lopez Fri, 01/30/2009 - 23:43

Hi Mikael,

Thank you very much for taking time answering my questions. For the 2nd to the last question you answered, Cisco TAC mentioned that if the TTL value of the packet is 1 then it will hit the CPU and will be processed in hardware if it's greater than 1.

I am asking this because we experienced very high CPU utilization because of Symantec Ghost client installed in workstations. Around 1500 sources are trying to send multicast traffic with TTL of 1 which hits the CPU. One of our server engineer asked if increasing the TTL value of the packet greater than 2 will resolve the issue. I just do not know what will be the effectd of this.

Thanks,

John

mlund Mon, 02/02/2009 - 00:35

Hi John

I'm glad my post was helpful.

I think it's worth trying to increase the ttl to avoid ttl 1 problem.

The effect of increasing ttl will be that the mcast traffic now can be forwarded to other vlans, if there are receivers that join the group.

If a packet arrives to the router with ttl=1 it will hit cpu. If it arrive with ttl=2 or greater, it will be decreased by one before forwarded, as for my understanding, this will be done in hardware, if the platform supports hardware switching.

Also if the packet has to be dropped because of an empty oil (= no listener in other vlans) it's done in hardware.

If it was me, had for sure tried with a ttl greater than 1, and then watch for the cpu.

/Mikael

John Patrick Lopez Mon, 04/20/2009 - 12:59

Hi Mikael,

It's me again. It's been a long time since I looked into this issue.

Just an update, we were able to reduce the CPU load of the switch down to 55% from a 80+% by disabling the Symantec Ghost application. However, there are still workstations trying to send multicast traffic and still hitting the CPU. I guess this is the UPnP Application which is multicast. It still gives the CPU several spikes a day and I want to eliminate this.

I analyzed the situation for a while and thought about our configuration which is sparse-dense-mode. Since the network is simple where we have plenty of SVIs where we enabled multicast but the metro-ethernet links (which is our WAN) doesn't have PIM config. So basically all multicast is being populated to SVIs.

I tried to think of it and noticed that we are not running auto-rp nor static RP. So basically all traffic is in dense-mode. I configured one 2600XM router to become an RP and advertise itself as mapping-agent and candidate-rp. It became an RP and all traffic switched to sparse-mode. However, this didn't help to reduce the CPU load.

I am thinking now if applying "ip multicast boundary" command can stop administrative multicast packets from hitting the CPU and reduce its process.

John

Actions

This Discussion