If you try % sudo ip route add 194.100.7.227/32 dev eth0 % sudo arp -i eth0 -s 194.100.7.227 ff:ff:ff:ff:ff:ff % ping 194.100.7.227 Chances are that you get ping replies (Cisco VXR, Cisco ISR, Juniper SRX, Juniper M10i, Juniper M7i, Linksys e4200) But you also might not be getting replies (Catalyst 7600, 3560, EX4200) RFC[0] says in rather unambiguous way, that this should not be working. I don't think catalyst/EX guys were lot smarter and honoured the RFC. Rather I think it's hardware limitation they work like this. At least 7600 (as per ELAM capture) acts like switch and tries to normally broadcast the frame in the VLAN, but as it is L3 interface, there is only one port in the VLAN, so net effect is, frame is dropped. Now I'm facing loop, which is caused by ill-configured network, by any networker definition of ill-configured. However, if our router would behave like RFC says, then the ill-configured network would not cause loops. This puts me in bit of a pickle, I can't call cisco and juniper and tell them to fix all their routers and give me fixed release tomorrow, since this behaviour seems very standard/de-facto behaviour. Customer refuses to do any of the fixes in the ill-configured network, as problem only started after swapping catalyst to ISR, so customer understandably does not grasp the fault is not in our end (it's not, fault is caused by mismatching L2/L3 topologies with directed-broadcast in customer router) Anyone else ever had problems due to router vendors not implementing rfc1812 5.3.4? [0] http://tools.ietf.org/html/rfc1812#section-5.3.4 -- ++ytti