Re: OT: Strange ARP Behavior

I have updated my blog post with this information at
http://nadeemrafi.com/arp-arpa-and-snap-wow-110/

On Fri, Jun 24, 2011 at 9:58 AM, Nadeem Rafi <nrafia_at_gmail.com> wrote:

> Your are Correct! only way to really clear the ARP table, you have to shut
> down interface. Which seems quite non-realistic approach in production.
>
>
> On Fri, Jun 24, 2011 at 9:55 AM, John Neiberger <jneiberger_at_gmail.com>wrote:
>
>> That is exactly what happens. If you truly want to clear an ARP cache,
>> you have to shutdown the relevant interfaces before you clear the
>> cache, then bring the interfaces back up. What's funny is that I
>> remember the exact day I learned this very lesson while working on a
>> lab. I had that same, "WTF?" kind of moment while trying to figure out
>> what was going on.
>>
>> John
>>
>> On Fri, Jun 24, 2011 at 12:46 AM, Joe Astorino
>> <joeastorino1982_at_gmail.com> wrote:
>> > Thanks Nadeem. I tested this on an 1841 and a 2811 running different
>> IOS
>> > with the same results. Further research seems to indicate that whenever
>> you
>> > clear the ARP cache, the router will send a unicast ARP request to
>> > everything in the ARP table at that moment. New to me! Learn something
>> new
>> > every day!!!
>> >
>> > With 1 IP/MAC in my table not a big deal, but somewhat interesting to
>> think
>> > of that process happening on a router located on a segment where there
>> are
>> > many hosts. I wonder if it staggers those ARPs in that case.
>> >
>> >
>> >
>> > On Fri, Jun 24, 2011 at 1:13 AM, Nadeem Rafi <nrafia_at_gmail.com> wrote:
>> >
>> >> AFAIK, when you clear arp cache, it does not remove entries, it just
>> >> refresh entries, and for refreshing entries it will query about already
>> >> known entries via unicast.
>> >>
>> >> Please check this article, although specific scenario is not included,
>> but
>> >> it may help.
>> >> http://nadeemrafi.com/arp-arpa-and-snap-wow-110/
>> >>
>> >> HTH
>> >>
>> >>
>> >> On Fri, Jun 24, 2011 at 6:18 AM, Joe Astorino <
>> joeastorino1982_at_gmail.com>wrote:
>> >>
>> >>> "When I initially ping 10.10.10.1 from Cat1" -- Whoops. I mean when I
>> >>> initially ping 10.10.10.1 from R1. My bad.
>> >>>
>> >>> On Thu, Jun 23, 2011 at 11:10 PM, Joe Astorino <
>> joeastorino1982_at_gmail.com
>> >>> >wrote:
>> >>>
>> >>> > Has anybody else ever seen anything like this or know why this is
>> >>> > happening? I have R1 connected to Cat1, a L3 switch. R1 has an IP
>> >>> address
>> >>> > 10.10.10.4 and Cat1 VLAN1 has an IP address of 10.10.10.1.
>> >>> >
>> >>> > When I initially ping 10.10.10.1 from Cat1 of course the ARP process
>> >>> > happens and I end up with an ARP table entry on R1 for 10.10.10.1.
>> >>> However,
>> >>> > when I clear the arp cache via "clear arp" or "clear ip arp
>> 10.10.10.1",
>> >>> R1
>> >>> > IMMEDIATELY sends a gratuitous ARP for it's own IP address (which is
>> >>> normal
>> >>> > and fine) but then the puzzle....it sends a UNICAST ARP request for
>> >>> > 10.10.10.1 to the specific MAC address of Cat1 VLAN1 interface. How
>> R1
>> >>> > still knows this address is the mystery.
>> >>> >
>> >>> > Additional Information: R1 has no routes other than the directly
>> >>> connected
>> >>> > route. No default route, no static route, nothing. IP routing is
>> >>> enabled.
>> >>> > In my troubleshooting I disabled CEF and had the same issue. Debugs
>> >>> below
>> >>> >
>> >>> > R1(config-if)#do sh ip arp
>> >>> > Protocol Address Age (min) Hardware Addr Type
>> Interface
>> >>> > Internet 10.10.10.1 0 0018.1820.2740 ARPA
>> >>> > FastEthernet0/0 <--- Cat1 VLAN1
>> >>> > Internet 10.10.10.4 - 0019.e721.84da ARPA
>> >>> > FastEthernet0/0 <--- R1 Fa0/0
>> >>> >
>> >>> > R1(config-if)#do clear arp
>> >>> > R1(config-if)#
>> >>> >
>> >>> > /* GRATUITOUS ARP -- Normal */
>> >>> > *Jun 24 02:27:00.663: ARP: flushing ARP entries for all interfaces
>> >>> > *Jun 24 02:27:00.667: IP ARP: sent rep src 10.10.10.4
>> 0019.e721.84da,
>> >>> > dst 10.10.10.4 ffff.ffff.ffff FastEthernet0/0
>> >>> >
>> >>> >
>> >>> > /* WTF ? /*
>> >>> > *Jun 24 02:27:00.667: IP ARP: sent req src 10.10.10.4
>> 0019.e721.84da,
>> >>> > dst 10.10.10.1 0018.1820.2740 FastEthernet0/0
>> >>> > *Jun 24 02:27:00.667: IP ARP: rcvd rep src 10.10.10.1
>> 0018.1820.2740,
>> >>> dst
>> >>> > 10.10.10.4 FastEthernet0/0
>> >>> >
>> >>> > --
>> >>> > Regards,
>> >>> >
>> >>> > Joe Astorino
>> >>> > CCIE #24347
>> >>> > Blog: http://astorinonetworks.com
>> >>> >
>> >>> > "He not busy being born is busy dying" - Dylan
>> >>> >
>> >>> >
>> >>>
>> >>>
>> >>> --
>> >>> Regards,
>> >>>
>> >>> Joe Astorino
>> >>> CCIE #24347
>> >>> Blog: http://astorinonetworks.com
>> >>>
>> >>> "He not busy being born is busy dying" - Dylan
>> >>>
>> >>>
>> >>> Blogs and organic groups at http://www.ccie.net
>> >>>
>> >>>
>> _______________________________________________________________________
>> >>> Subscription information may be found at:
>> >>> http://www.groupstudy.com/list/CCIELab.html
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>
>> >
>> >
>> > --
>> > Regards,
>> >
>> > Joe Astorino
>> > CCIE #24347
>> > Blog: http://astorinonetworks.com
>> >
>> > "He not busy being born is busy dying" - Dylan
>> >
>> >
>> > Blogs and organic groups at http://www.ccie.net
>> >
>> > _______________________________________________________________________
>> > Subscription information may be found at:
>> > http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Fri Jun 24 2011 - 11:00:47 ART