multicast mac-address and NLB

[katerina.dardoufa]

Hello community,

I have the following question: my company has deployed two microsoft servers with NLB. In order for that to work we have configured a static arp entry on our 3LS for the multicast mac and the VIP according to the following url:

http://www.cisco.com/en/US/products/hw/switches/ps708/products_configuration_example09186a0080a07203.shtml

The servers are physically connected to the same access switch.

My questions are:

1. show mac-address table  on the 3LS (65xx) does not show an entry for the multicast mac. Should it?
2. do we need to configure a static mac-entry on the switch of the form:

    mac-address-table static 0300.5e11.1111 vlan 200 interface fa2/3 fa2/4
   We did that, and show mac-address table on the switch does show the entry as static. I thought that it would get propagated to the 3LS, but it doesn't.
      Is that normal?
   3. If the physical servers were on different switches how would the above command be configured and would there be a point to it?
   4. Since the multicast mac address does not show in the mac-address table on 3LS, whenever someone searches for this multicast will it be flooded throughout the domain?

The static arp on the 3LS seems sufficient for the NLB to work, but is there something else to it?

Thank you in advance,
Katerina
 

[andtoth]

Hi,

As mentioned in the documentation which you were referring to mentiones that the disable-snooping parameter is essential and applicable only for Cisco Catalyst 6000/6500 series switches. Without this statement, the behavior is not affected.

See the Multicast Mode section on the following link:

http://www.cisco.com/en/US/products/hw/switches/ps708/products_configuration_example09186a0080a07203.shtml#mm

I hope this helps you solving the issue.

Best regards,

Andras

[katerina.dardoufa]

Hi Andras,

as I understand from the document, "disable-snooping" should be configured on 65xx, if the servers are physically connected to the 65xx.

That is not our case, since the 65xx are at the core layer, and our servers connect to an access switch.

What I don't understand is how the below command influences anything, when it's configured on a an access switch, as opposed to the 65xx.

mac-address-table static 0300.5e11.1111 vlan 200 interface fa2/3 fa2/4

The only thing that changes is the mac-address table on the switch were this is configured. 
The 65xx still has no idea how to reach this mac-address, since it doesn't show in its mac address table.
Is there something I am missing? Something else that needs to be configured for the mac to show in 65xx or is this how it's supposed to be?
And if nothing is missing, then doesn't NLB, configured this way, end up flooding the domain, everytime someone tries to reach the VIP?

Thanks in advance,

Katerina

[andtoth]

Please see the following post for more information which will cover your questions as well:

https://supportforums.cisco.com/message/3202182#3202182

Andras

[katerina.dardoufa]

Andras and Giuseppe,

thanks for the useful link and your answers

I submit the part which is of interest:

• Static ARP bindings must be applied on any devices  which route traffic from a different subnet into the subnet with NLB  servers. This is because Cisco devices will not honour an ARP reply  associating a unicast IP with a multicast Ethernet MAC address.
• Static CAM entries are recommended (but not mandatory) on all switches in the subnet(s) containing NLB  servers to avoid flooding traffic destined for the cluster on  unnecessary ports. This is because by default NLB servers do not  generate IGMP reports which are the primary mechanism switches use to  constrain multicast traffic. Newer Windows versions can be enabled for  IGMP, but this may not work for all switches as some models (notably  Catalyst 3750 and similar) forward multicast at L2 based on destination  IP (which we can't determine from the NLB IGMP reports) rather than MAC.  For a network with a small number of routers touching the NLB subnet I  recommend staticly configured entries.

Static ARPs should be applied on the 65xx which performs intervaln routing. Understandable and mandatory!

Static CAM. In our environment VTP pruning is not enabled (yet!!!), so flooding will affect all switches in the domain. In order to avoid this, static CAM entries should be added on the access switch - pointing to the physical servers - but also on all other switches - pointing out their uplinks - aswell as on the 65xx (core switch) pointing towards the access switch and on the EtherChannel ports (connecting are two 65xx)? If vtp pruning were enabled, then these static CAM should be configured on all switches with ports on the same vlan as the NLB. Correct?

Last question: in order to disable snooping on the 65xx, shouldn't it be enabled in the first place, or is it a default behaviour? I though that igmp snooping was possible, if you already had multicast routing enabled.

Since the static CAM is recommended but not mandatory, it seems only  wise to go with the simplest solution. But I still want to understand  how this works!!!!

Sorry for all these questions, but mulicast always makes my head hurt

Thanks in advance,

Katerina

[katerina.dardoufa]

To answer my own question, it seems that igmp snooping is enaled globally by default per vlan!

[andtoth]

If VTP pruning is enabled, that's per-vlan and it will prune inactive vlans, so that does not change behavior in this case too much because if you need the multicast traffic somewhere, that vlan will be active anyway and if static entries are not configured, traffic will be flooded in that vlan on that switch.

You're right, IGMP snooping is enabled by default in all vlans on almost all Catalyst switches.

Please don't forget to rate the posts and mark the thread as answered if you're satisfied with the replies.

Andras

[katerina.dardoufa]

The reason I mention VTP pruning is that we already have flooding, each time there is a broadcast, so I believe that flooding when multicasting won't change anything that much!

I still don't fully get the static CAM entries and where they should be placed. Attached you will find a topology diagram, and that might somehow clear up things for me...

Thanks once again,

Katerina

[andtoth · Accepted solution]

VTP pruning will only limit the scope of flooding, so for example if the vlan where multicast traffic is going is not active on switch 4, switch 4 will tell the upstream switches that he does not need that vlan, so when traffic is flooded (due to broadcast or unknown unicast or unknown multicast), switch 4 will not receive that flooded traffic at all. VTP pruning will not tell devices where the traffic should be sent, they just automatically remove (prune) unnecessary vlans from trunks.

Should static CAM entries be placed pointing to etherchannel and links towords switch1 on both 65xx?

Yes. If it's an etherchannel towards switch 1, only need to point to the port-channel interface.

static CAM on Switch 1 pointing to the connection with srv1 and srv2

Correct

static CAM on swithces 2,3,4 pointing to their uplinks?

Yes, if they need to reach the NLB servers.

Andras

[Giuseppe Larosa]

Hello Katerina,

>> The 65xx still has no idea how to reach this mac-address

you probably need to configure the static entry also on the C6500 pointing to the link(s) to the access layer switch as noted you may need to disable IGMP snooping on the C6500

Actually this  configuration is a trick and you need to disable IGMP snooping, because otherwise the association of an unicast IP address with a multicast MAC address will be considered an error by IGMP snooping code

lower end switches are less smart

Hope to help

Giuseppe