[j-nsp] Microsoft NLB cluster with EX-series
dale.shaw+j-nsp at gmail.com
Wed Nov 17 05:16:04 EST 2010
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
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.
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.
More information about the juniper-nsp