[j-nsp] MS NLB multicast mode and EX 12.x new behaviour issues

[David Monosov]

Dear Tarko, j-nsp,

Strongly second this motion. The EX line has been a complete disaster for
deployments with multicast MS NLB.

Before 11.4, there was no way to get multicast MS NLB to work at all if you
needed it in combination with RVI (PR/434505), and some older software would not
correctly flood multicast MS NLB frames even without RVI and with igmp-snooping
disabled.

In 11.4, this got resolved. Next to that, however, EX also had no support for
the equivalent of Cisco's 'bpdufilter', and working around that with manual
ethernet-switching family filters in 11.4 has been a mixed experience.

With 12.1, an actual bpdufilter-alike knob was finally introduced - but now
multicast MS NLB is broken again...

Hoping to see this fixed soon in a meaningful way.

--
Respectfully yours,

David Monosov


On 04/01/2013 11:33 AM, Tarko Tikan wrote:
> hey,
> 
> I just want to let everyone know about the new behaviour for unknown multicast
> that was introduced in junos 12.1 for EX switches. I'm also looking for feedback
> from other EX users because we have been unable to convince juniper to rethink
> this for 4 months now.
> 
> In 12.1, EX will now copy all transit multicast packets matching destination mac
> 03:bf:* to control plane. This is normally used for MS NLB multicast mode and
> should be flooded. I would somewhat understand if they would do it in management
> vlan but this is done for all vlans, including ones that should be pure transit
> in L2 device.
> 
> The side effect of this is that multicast will totally congest some of your
> inband management queues leaving you without ssh and telnet.
> 
> You can verify this by running "show sh packet-descriptor dev 1 pcl-out" from
> SFID shell and looking whats in the packet queue. Cut-down example (original
> output has lot more fields):
> 
> CPU code           : 253
> Dest IP addr       : 192.168.17.95
> Dest MAC addr      : 03:bf:c0:a8:11:5f
> Ether type         : 0x800
> IP TTL             : 62
> Is routed          : 0
> MAC DA lookup rslt : 0
> MAC DA type        : Multicast
> Packet command     : Mirror to CPU
> Src IP addr        : 192.168.16.58
> Src MAC addr       : 44:d3:ca:ba:55:c1
> TCP/UDP dest port  : 3389
> TCP/UDP src port   : 47679
> Vlan ID            : 12
> 
> JTAC is now proposing using scripts and cronjobs to run some commands from pfe
> shell on every startup to ratelimit this multicast. Not only is this not
> deployable in large scale, but this is head-in-the-sand type of solution. They
> should really fix the root cause (by redesigning it) or revert the change. EX
> software quality has been going downhill for a while now and still keeps doing so.
>