[c-nsp] ARP strangeness

[Frank Bulk - iName.com]

No, the FTTH doesn't allow broadcasts, at all. =(

Right now the ARP timeout is 480 seconds, CAM is 540 seconds, and the FTTH's
FDB is 900 seconds.

If the CPE had a reasonable ARP timeout, it would refresh the ARP entry for
it's default gateway (7609) upon the first CPE-initiated packet after a
period of deafness, but it doesn't.

Frank

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Phil Mayers
Sent: Wednesday, January 12, 2011 4:09 AM
To: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] ARP strangeness

On 01/11/2011 08:06 PM, Keegan Holley wrote:
>
> That doesn't make sense though.  The cpe will need to broadcast for the
> initial request and after reboots regardless of what the provider router
> does.  The device that was blocking broadcast was a third party FTTH
device.
>   I get the feeling I'm missing something here though.  Maybe it only
allows
> broadcast for a specific interval after it detects a link down/link up.

As I understood it, the FTTH device permits broadcasts but they're only
flooded on ports with FDB entries (!). So, once the FDB entry expires
(as a result of a "quiet" CPE) it's impossible to refresh the ARP (and
FDB) entry from the outside - only the CPE could do it, and it isn't
doing it.

Therefore there is a need to tune ARP timers well below FDB timers on
the FTTH device, to ensure that even for "quiet" hosts, ARP refresh
traffic from the 7600 keeps the state.

This does seem like a broken "smart" layer2 to me, but I'm sure someone
thought it was a good idea ;o)

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/