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.s...@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 > _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp