[c-nsp] ARP on ASR9k 4.3.2

[Florian Lohoff]

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                                                 f at zz.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: Digital signature
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20140116/49a1357c/attachment.sig>