NLB Multicast Mode Switch Config

[murphyw]

Hi everyone,

I have been asking several people this but no-one seems to want to get back to me :( Anyhow, hopeing someone here can help. I would like to configure our Cisco 3750G switch (with IP image) to allow for Multicase Mode NLB. I have found the following details but not sure what i need to do to configure this ?

"Another potential solution to the "switch flooding" problem is use of multicast mode, as long as your networking gear supports multicasting. In this case, you can either create mapping between the cluster multicast MAC address and switch ports connected to cluster adapters through static entries in the Content Addressable Memory on the switch, or you can enable the Internet Group Multicasting Protocol feature, which advertises the multicast MAC address assigned to cluster adapters to the switch. This way, the switch can forward client traffic to the relevant ports only, avoiding polluting ports used by non-clustered systems."

Any help would be appreciated

Regards

[beth-martin]

Switch flooding is limited when using unicast mode by creating VLANs in the switch and putting the NLB cluster on its own VLAN.

[michael_davis]

I'm not specifically knowlegeable with NLB switch flooding vs multicasting modes. But I can tell you that IGMP (Internet Group Multicasting Protocol) is enabled by default on Catalyst 3750 switches. No special configuration necessary unless you've manually disabled it.

Since IGMP is a local/Layer 2 protocol, if the servers are on the same VLAN, then there should be no issue from the Cisco standpoint. If the multicasting is not constrained to a single vlan, then your routers will need to be enabled to route multicasting using PIM, MOSPF, DVMRP, etc. That's an entirely different discussion.

Let me know if this helps by rating the post.

Michael

[skristiansen]

I'm having the same issues, I was able to add static mac-address entries for the virtual ip of the cluster to the switch and this solves the problem. Sort of an administrative nightmare, and really doesn't answer the multicast issues. But it works.

I now have 2 member servers on different switches and this doesn't work. I'm hoping someone might know why that might be. I tried adding the mac address staticly to the trunk ports but the switch doesn't seem to take it.

Thanks,

[michael_davis]

Can you provide a link that points to a description and/or installation guidelines for the NLB solution you are working with?

I might have a better idea of how to work this on the network side if I understand the application.

Michael

[michael_davis]

I found the quote from the first posting - seems y'all are referring to Win2k3 NLB.

I was doing some looking at:

http://technet2.microsoft.com/WindowsServer/en/Library/c7da3162-2055-438d-87c1-c1086c694c9f1033.mspx?mfr=true

"Cisco's interpretation of the RFCs is that Multicast is for IP Multicast" is amusing. Makes it sound like Cisco is just narrow minded. Lol.

It is correct that Cisco follows RFC 1112. Sec 6.4 says:

"An IP host group address is mapped to an Ethernet multicast address

by placing the low-order 23-bits of the IP address into the low-order

23 bits of the Ethernet multicast address 01-00-5E-00-00-00 (hex)."

Clearly Microsoft is breaking the RFC to implement this solution. They want you to map a multicast mac to a unicast IP. Hence the ARP hack. Unfortunately, since this is a hack, you are forced to limit your NLB cluster to a single vlan. The reason is, you cannot multicast route a unicast IP address. To do so would break lots o' things in IP.

Anyway, all that said, I'd use the equivelent of the multicast private address 239.2.2.2 which equals 01:00:fe:02:02:02 for the mac in your arp entry.

Syntax on the router/L3 switch is

arp A.B.C.D H.H.H arpa

where A.B.C.D is your virtual IP address, H.H.H is the multicast mac address, in this case 0100.fe02.0202.

With this mapping, you should be able to traverse trunk interfaces, from switch to switch, as long as you remain on the same vlan in the same VTP domain. Once a layer 3 device such as a router or L3 switch hop gets in the middle of things, the multicast option will break.

Michael

Let me know if this helps by rating the post.

[skristiansen]

I don't understand how you come up with the correct multicast mac address. How can you generate a multicast mac with a unicast ip address? The router in my case is actually a pix (I know that might throw a wench into things), but it already has an arp entry for the virtual ip, and it matches what the server says it's virtual ip and mac should be.

It seemed to me, the server never addressed it's ethernet frames with the virtual mac address, thus the switch never added the virtual mac address to it's cam table. Since there is no cam entry all ports on that vlan are flooded. When both hosts were on the same switch, no problem mac-address-table static xxx.xxx.xxx vlan x interface GigabitEthernet1/0/1 For the virtual mac and all is well. For some reason when adding the mac to a switch downstream the mac entry won't go on the trunk and thus traffic only goes to the local port and the downstream member server doesn't see any traffic.

If the multicast mac/arp entry will work, I'm all for it, could you just say a little more about how to calculate it?

Thanks

Stein

[michael_davis]

Hello Stein,

It was not the "correct" mac address. You cannot automatically generate multicast mac with a unicast ip. That was my point with regard to Microsoft's interpretation of the RFC.

What I did was convert a private multicast IP - 239.2.2.2 to its multicast mac equivelent. (first 23 low order bits of 239.002.002.002 are mapped to the first 23 low order bits of mac 01-00-fe-00-00-00.) Then I suggested that you could then manually bind your unicast Virtual IP address to the multicast mac address. This "tricks" the router to sending the frame to the multicast mac rather than arping for a unicast mac.

You could use the same mapping approach for your VIP IP address. But I don't know the particular IPs in the poster's network, and I wanted to pick a mac that I could reasonably guess was not in use by another multicast application in their network. Remember routing protocols, hsrp, vrrp, glbp, etc all use multicast in one form or another.

I'm not a big fan of this "broken multicast" approach. Nor am I a fan of MS's NLB. I do not recommend either of them. Despite what Microsoft says, NLB is not inherently scalable nor a highly available approach by itself. Maybe if you used IP Anycast in conjuction or something...

And multicast-to-unicast arp mapping is not my idea. This is Microsoft's implementation guideline for leveraging IGMP for NLB. I found it at:

http://technet2.microsoft.com/WindowsServer/en/Library/597848c1-3ab4-4ade-80f2-b54bb33be5c11033.mspx?mfr=true

Why would someone consider doing the multicast approach? You would consider it to avoid flooding NLB destined frame with its unknown dmac to every port and trunk on the vlan for every frame.

Now, to your specific issue.

From the switch that is connected to the PIX - can you see the broken server's real mac address in the switch's cam appearing to come from the trunk port?

The approach you are taking is another Microsoft supported approach - one that leverages normal switch behavior rather than breaking RFCs. You are still constrained to a particular vlan,

I'm not following your topology. If the next-hop/default-gateway is the pix, then where are where are you adding the arp entry downstream? I'm presuming an SVI (interface Vlan X) but am wondering why that switch would ever arp for your server?

On its face, I think you have two vlans with the same name, separated by a router. Please elaborate.

Some other things I imagine that could break the flooding mechanism.

Vlan ID/Tag mismatches.

Spanning tree blocked ports.

Server assigned to wrong vlan.

NLB mis-configuration - virtual mac, virtual ip, mismatches, etc.

NLB not communicating with peers.

HTH clarify,

Michael