3650 switch interfering with Microsoft multicast NLB

[Gareth Tomlinson]

We have a large (30+ hosts) VM environment, largely on 3560G and 3560X switches, all running without issues

We switched to Multicast NLB many years ago, and have never had issues with it. (all switches run layer 2 only, layer 3 device is elsewhere)

We have now deployed a 3650 switch, which initially stopped servers booting with the correct IP (IP device tracking is now disabled), and now we are finding issues with Multicast NLB; if one device in a cluster moves to the VM host on the 3650, it cannot converge.

IOS version on the switch is 03.03.03SE and license is Lanbase.

[Mark Malone]

Is the switch setup with the below if using IGMP multicast

have you tried a different IOS-XE version in case you hit a bug that's a very early release

The recommended version currently is 3.6.4 MD

Multicast Mode

Here are some notes about the use of NLB in Multicast mode:

• In Multicast mode, the system administrator clicks the Multicast button in the Microsoft NLB configuration GUI. This choice instructs the cluster members to respond to the ARPs for their virtual address with the use of a multicast MAC address, such as 0300.5e01.0101.
  
  
• The ARP process does not complete for multicast MAC addresses (this breaks RFC 1812). A static MAC address is required in order to reach the cluster outside of the local subnet.
  
  
• The virtual IP address is 10.100.1.99 and the multicast MAC address is 0300.5e01.0101. Enter this command in order to populate the ARP table statically:
  

  arp 10.100.1.99 0300.5e01.0101

• Since the inbound packets have a unicast destination IP address and a multicast destination MAC address, the Cisco device ignores this entry and the unicast floods each cluster-bound packet. In order to avoid this flooding, insert a static mac-address-table entry in order to switch the cluster-bound packets in the hardware:
  

  mac address-table static 0300.5e01.0101 vlan 200 interface TenGigabitEthernet1/4
   TenGigabitEthernet1/5

[Gareth Tomlinson]

Yes, that's all done; in fact, I posted a how to on this many years ago.

I'm conscious this is an early OS, but I'm reluctant to update a production switch unless a bug is identified.

I'm going to move the VM host onto a different (3560) switch, to see if the problem moves with the host or is switch related. I'll update this when I get the result

[Mark Malone]

Yes that's at least less impactful and should prove out the ios , the fact it was working then you moved to this ios-xe which some of these early  versions had some bad bugs in them I would think its the ios, I did check your release there couldn't see anything  noted as bug for NLB and just couple of multicast bugs but you may have hit something that was not triggered when it was out

http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3650/software/release/3se/release_notes/OL30563.html

[Gareth Tomlinson]

I'm sure it will surprise no-one to find that when the host is in a 3560 switch, everything works fine.

I'm going to raise a TAC case, but I suspect an IOS upgrade is inevitable.

I'll update this as and when I get an answer!

G

[Mark Malone]

Yes post what they say would be good at least to get a bug id out of them

[kahsieh]

Hi Gareth,

What's the answer you got ?