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

[Tarko Tikan]

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.

-- 
tarko