[j-nsp] Microsoft NLB cluster with EX-series

[Dale Shaw]

Hi all,

For the record, we ended up putting the server interfaces
participating in NLB in dedicated VLANs. We have 4 NLB clusters across
4 physical servers so we ended up with 4 new VLANs each with 2 member
switch ports.

This seems to be a fairly common workaround to limit the spread of
flooded traffic (which, of course, is expected with NLB).

There still seems to be a bad NLB/EX-series interaction which could be
caused by one of the many multicast bugs fixed in 10.0S10 but I
haven't yet had time to confirm. IGMP snooping shouldn't have to be
disabled to make this work.

Cheers,
Dale

On Mon, Nov 15, 2010 at 10:33 PM, Dale Shaw <dale.shaw at gmail.com> wrote:
> Hi all,
>
> Has anyone been given the torturous task of supporting Windows servers
> running NLB? (in multicast mode w/IGMP). Horrible things. Ptooey!
>
> It's wreaking havoc at L2, flooding traffic all over the VLAN because
> I haven't been able to make it work at all with IGMP snooping enabled.
> I'm doing my best to isolate the badness.
>
> I've got the static ARP entries in to support the *unicast* IP to
> multicast MAC mapping. I couldn't find a way to set a static
> ethernet-switching table entry using a multicast MAC.
>
> With IGMP snooping enabled, "show igmp-snooping member" creates the
> right entries but for the multicast group address reverse-derived from
> the multicast MAC.
>
> The problem seems to be forwarding L2 multicast traffic across a dot1q
> trunk. I've tried 'set protocols igmp-snooping vlan BLAH interface
> <trunk> multicast-router-interface' to no avail -- it helps with the
> IGMP snooping entries on the far side but traffic just doesn't seem to
> make it.
>
> EX4200 running 10.0R4 (same end result as with 10.0S1 but there are
> known problems with IGMP snooping fixed in 10.0R4 so I upgraded)
>
> I've got a case open with the JTAC but it's moving fairly slowly.
>
> cheers,
> Dale
>