On Mon, Jan 19, 2009 at 05:24:19PM +0100, Benny Amorsen wrote: > Ross Vandegrift <[email protected]> writes: > > I disagree. It doesn't make any sense to accept a multicast address > > for a unicast neighbor resolution protocol - especially since I > > could use that as a denial-of-service vector by maliciously > > answering ARP queries and forcing others to multicast. > > Not much of a denial-of-service, is it?
Well, not in this case. But in the general case, if anyone accepted multicast MACs for ARP entries, it'd be easy to start causing your switches to flood more frames than they are switching. Imagine a datacenter full of boxes willing to multicast their traffic instead of unicast it without knowing about it. I'm just defending the spirit of the requirement. > How does it help to generate a virtual MAC? The packets will only get > delivered to one device. The whole point of using a multicast MAC is > that all traffic gets delivered to all active devices; enabling > active-active setups. VRRP, HSRP, NSRP all do active/backup. Maybe there's a use-case I'm not aware of, but when would you want all of your active devices to receive all traffic? I'd want each active device to receive 1/n of the packets, and so would use something like equal-cost routes. But maybe you have some active-active setup in mind that doesn't split the traffic? -- Ross Vandegrift [email protected] "If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher." --Woody Guthrie _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
