Handling of L2 broadcast, L3 unicast frames

Saku Ytti saku at ytti.fi
Mon Apr 2 08:44:45 UTC 2012


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




More information about the NANOG mailing list