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