[c-nsp] ARP strangeness
Keegan Holley
keegan.holley at sungard.com
Wed Jan 12 10:40:43 EST 2011
On Wed, Jan 12, 2011 at 9:57 AM, Rodney Dunn <rodunn at cisco.com> wrote:
> I thought it was stated it only blocked them from the headend out towards
> the CPE. As long as you had them originated from the CPE (which in a home
> environment makes some sense as it's usually traffic originated from the CPE
> not servers hosted there..typically that is) one wouldn't need broadcast
> from the headend router if the refresh was unicast.
>
It's probably safe to allow all broadcast from the head end if possible
since it's owned by the service provider. That would certainly fix things.
Either way vendors never find out about this sort of stuff unless customers
submit feature requests.
>
> I'm not advocating for that as the optimal solution by any means. ;)
>
> Agreed...
> Rodney
>
>
>
> On 1/11/11 3:06 PM, Keegan Holley wrote:
>
>>
>>
>>
>> On Tue, Jan 11, 2011 at 2:50 PM, Rodney Dunn <rodunn at cisco.com
>> <mailto:rodunn at cisco.com>> wrote:
>>
>>
>>
>> On 1/11/11 11:49 AM, Keegan Holley wrote:
>>
>> Possibly a stupid question, but I thought ARP had to be broadcast
>> because the mac address of the destination was unknown.
>>
>>
>> That is true for the first request. For subsequent arp refreshes the
>> most efficient way is to unicast it.
>>
>>
>> That's what I said. However, having an ethernet that doesn't support
>> broadcast would make that first entry impossible. The problem would
>> repeat after reboots or power outages.
>>
>>
>>
>>
>> If the CPE has
>>
>> the correct mac address to unicast an ARP request, why would it
>> need to
>> arp in the first place?
>>
>>
>> To make sure the CPE is still alive and responding.
>>
>>
>> RIght but it can only do that if it has already successfully arp'd so I
>> think we are saying the same thing.
>>
>>
>>
>>
>> I suppose I can understand renewing the entry
>>
>> via unicast, but there will always be a need for broadcast ARP.
>> It just
>> seems strange to implement an ethernet based device and block all
>> broadcast traffic. Am I missing something?
>>
>>
>> I didn't go back and read the entire thread to remember what was
>> blocking the broadcast and understand the thought logic of whey they
>> do it. It may would be, and possibly has some logic to it, that in a
>> CPE environment you always rely on traffic originated at the CPE to
>> trigger the arp so you block broadcast out to the CPE not coming
>> from the CPE.
>>
>>
>> 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.
>>
>>
>>
>>
>>
>> On Mon, Jan 10, 2011 at 5:27 PM, Frank Bulk <frnkblk at iname.com
>> <mailto:frnkblk at iname.com>
>> <mailto:frnkblk at iname.com <mailto:frnkblk at iname.com>>> wrote:
>>
>> Thanks for explaining.
>>
>> Since the Linksys BEFRS41 does not ARP regularly, even after
>> a DHCP
>> RENEW
>> and DHCP DISCOVER, and because the access gear blocks all
>> broadcast
>> traffic,
>> the 7609-S will never (re-)populate its ARP entry.
>>
>> I'm going to see if the Linksys BEFRS41 has a configurable ARP
>> expiration
>> timer. If so, dropping it to 10 minutes would cause it to
>> unicast
>> ARP for
>> the default gateway, which would resolve the issue.
>>
>> Another possible option, I guess, is to extend the 7609-S ARP
>> expiration to
>> a longer time interval, but if the BEFRS41 is silent for
>> even a second
>> longer than the ARP timer, then I'm still stuck.
>>
>> I should really look at the behavior of other CPE to see how
>> often they
>> unicast ARP.
>>
>> Frank
>>
>> -----Original Message-----
>> From: Rodney Dunn [mailto:rodunn at cisco.com
>> <mailto:rodunn at cisco.com> <mailto:rodunn at cisco.com
>> <mailto:rodunn at cisco.com>>]
>> Sent: Monday, January 10, 2011 1:30 PM
>> To: frnkblk at iname.com <mailto:frnkblk at iname.com>
>> <mailto:frnkblk at iname.com <mailto:frnkblk at iname.com>>
>> Cc: cisco-nsp at puck.nether.net
>> <mailto:cisco-nsp at puck.nether.net>
>> <mailto:cisco-nsp at puck.nether.net
>> <mailto:cisco-nsp at puck.nether.net>>
>> Subject: Re: [c-nsp] ARP strangeness
>>
>> It only gets updated on getting and ARP packet from the host.
>>
>> It is not updated based on L3 data level traffic flowing
>> to/from the
>> host.
>>
>> Rodney
>>
>>
>>
>> On 1/10/11 11:43 AM, Frank Bulk wrote:
>> > Does the ARP cache get populated, or updated, if the traffic
>> comes into an
>> > L3 interface, or is it only populated upon a successful ARP
>> response?
>> >
>> > Frank
>> >
>> > -----Original Message-----
>> > From: cisco-nsp-bounces at puck.nether.net
>> <mailto:cisco-nsp-bounces at puck.nether.net>
>> <mailto:cisco-nsp-bounces at puck.nether.net
>> <mailto:cisco-nsp-bounces at puck.nether.net>>
>> > [mailto:cisco-nsp-bounces at puck.nether.net
>> <mailto:cisco-nsp-bounces at puck.nether.net>
>> <mailto:cisco-nsp-bounces at puck.nether.net
>> <mailto:cisco-nsp-bounces at puck.nether.net>>] On Behalf Of Rodney
>> Dunn
>> > Sent: Wednesday, January 05, 2011 7:38 AM
>> > To: Jeff Kell
>> > Cc: cisco-nsp at puck.nether.net
>> <mailto:cisco-nsp at puck.nether.net>
>> <mailto:cisco-nsp at puck.nether.net
>> <mailto:cisco-nsp at puck.nether.net>>
>> > Subject: Re: [c-nsp] ARP strangeness
>> >
>> > On 1/4/11 11:43 PM, Jeff Kell wrote:
>> >> On 1/4/2011 9:01 PM, Rodney Dunn wrote:
>> >>> There were some changes to ARP at one point to provide some
>> more
>> >>> triggered capability. I don't recall exactly what that was
>> but the
>> >>> default behavior for many years was that we send a unicast arp
>> to the
>> >>> destination 60 seconds prior to the arp timer set to
>> expire. If we
>> >>> don't get a response we send it again when the timer pops
>> and if no
>> >>> response we invalidate the ARP entry.
>> >>
>> >> Umm, that sort of rocks my boat with regard to network
>> monitoring
>> >> assumptions...
>> >>
>> >> We have one of those NMS systems that periodically "reads L2
>> devices for
>> >> mac-address/port mapping" and "reads L3 devices ARP for
>> mac-to-IP
>> >> mapping". Ideally, there should be no missing links (if the
>> MAC is
>> >> found, hopefully the ARP/IP is found, and vice-versa).
>> >>
>> >
>> > That still holds true as long as a timer (sam cam ager)
>> didn't pop
>> > sooner than your arp refresh timer.
>> >
>> >> For the default mac-address aging time of 300 seconds, I had
>> this notion
>> >> that setting the ARP timeouts to 270 seconds would
>> necessitate the
>> >> router ARPing the device (assuming active traffic) prior to the
>> >> mac-address aging out, keeping the mac-address table populated.
>> >
>> > Keep the other timers 60+ seconds out to be safe.
>> >
>> >>
>> >> But if the Cisco L3 behavior is to gratuitously do this for me
>> before
>> >> the ARP timeout... that changes things a bit.
>> >>
>> >> Is this default behavior across all the Cats, or just the
>> 6500/7600? Is
>> >> it supervisor-specific?
>> >>
>> >
>> > Traditionally generic to all of IOS. There may have been some
>> platform
>> > specific thing that changed here that I have missed in the last
>> couple
>> > of years though.
>> >
>> > Rodney
>> >
>> >> Jeff
>> > _______________________________________________
>> > cisco-nsp mailing list cisco-nsp at puck.nether.net
>> <mailto:cisco-nsp at puck.nether.net>
>> <mailto:cisco-nsp at puck.nether.net
>> <mailto:cisco-nsp at puck.nether.net>>
>>
>> > https://puck.nether.net/mailman/listinfo/cisco-nsp
>> > archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
>> _______________________________________________
>> cisco-nsp mailing list cisco-nsp at puck.nether.net
>> <mailto:cisco-nsp at puck.nether.net>
>> <mailto:cisco-nsp at puck.nether.net
>> <mailto:cisco-nsp at puck.nether.net>>
>>
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
>>
>>
>>
>>
>
More information about the cisco-nsp
mailing list