Hi, On Thu, Jan 16, 2014 at 10:48:11AM -0600, Andrew Koch wrote: > We ran into similar trouble when swapping out our router for an ASR9k > running 4.2.3. Cisco scrambled a SMU for that release (sorta). From their > information it is not entirely arbitrary. Any IP that is routed down that > link can have an ARP stored. > > Our trouble became a bit worse when we removed the route and the ARP was > still present; the router was then black-holing traffic by trying to send > it via the stale ARP.
It blackholed for us immediatly. We had a route and a correct ARP
for the next hop so there was no reason that it shoudlnt work.
An out-of-ip-subnet-range arp entry broke forwarding - WTF!?!?!?
> We thought so to. We opened a case - Cisco DDTS CSCty06696 was the
> result. Cisco did not agree that this was faulty behavior: they insisted
> that it was correct. The DDTS and SMU are for an option to disable the
> ability to learn out of subnet ARPs. Under the interface you can configure
> "arp learning local" to block out-of-subnet ARPs.
It is completely broken by design - a blind person at the age of 85
would see this.
> > PS: I made some sysctl tweaks on the linux machine to behave a little
> > more nice but still i see a bug here.
>
> We did the same while waiting for the SMU. The SMU should not be needed
> for 4.3.2 - the "arp learning local" interface command should be built-in,
> so hopefully you are good to go.
RP/0/RSP0/CPU0:cr2(config-subif)#arp learning ?
disable Disable dynamic learning of ARP entries
RP/0/RSP0/CPU0:cr2(config-subif)#arp learning local
^
% Invalid input detected at '^' marker.
Not in 4.3.2
> Our biggest concern over this incident was receiving malicious ARPs on
> transit and peering links that have routes to large swaths of the network.
> If the route goes away, the ARP will be retained for long periods and the
> router will black-hole traffic until that clears. Cisco PSIRT evaluated
> the concern but evaluated it as a fairly concern.
*ROFL* - Sending out gratious arp on a peering exchange lan can
blackhole traffic for others - IMHO thats an easy DoS vector - how could
that be "fairly"?
Flo
--
Florian Lohoff [email protected]
signature.asc
Description: Digital signature
_______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
