[c-nsp] ARP strangeness

[Frank Bulk - iName.com]

There's no way for a smart L2 could compensate for the broadcast issue.
With a broadcast ARP the MAC address is not known, unlike a unicast ARP
where it is.  So the only way for that broadcast ARP to make it to the CPE,
which is unknown, is to blast it out to all the FTTH ports.

The FTTH vendor is going to support MACFF
(http://en.wikipedia.org/wiki/MAC-Forced_Forwarding), but that doesn't
really address the issue I've been having.

Frank

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

On Wed, Jan 12, 2011 at 5:08 AM, Phil Mayers <p.mayers at imperial.ac.uk>wrote:

> 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)
>
>
>
Thanks, I knew I had missed a detail somewhere.  It may be a longer route
but I'd also send a feature request to the FTTH vendor.  Opening up all
broadcast has potential security implications.  However, making the smart
layer-2 a little smarter and may be in order.  They could change the device
so that it could recognize when the CPE was trying to wake up.  They could
also implement some sort of directed broadcast where arp and other protocols
sent as broadcasts are only replicated to a single device.  Implementing
something similar to cisco private vlans would also work here.
_______________________________________________
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/