From: Marcus Lasarko (mlasarko@co.ba.md.us)
Date: Sat Dec 09 2006 - 05:12:12 ART
Agreed, I thought about aging... also considered authorized ARP (w/ DHCP - if it was one of those "app servers" ), "arp timeout 0", etc... but IIRC the default ARP timeout is like 4 hours on an IOS (12.3?) router. (Trying to keep this in the context of the lab blueprints and their respective hardware platforms, it's been a while since CSCdu81936)
Then I looked back into the context of ARP's being received from the router and not being clear on what exactly was happening, I asked myself - "What was the router ARP'ing for; Are we talking about a single entry? Is the switch CAM getting blasted?? Could we have a static route pointing to a broadcast (VLAN?) interface??? Assuming there is a switch between the router and the server hosting the app, it could actually be connected directly to the router, which would make the VACL <null>, or even thrown in an ISR w/ ESM for a twist. Lots of pieces, most missing at this point IMO.
I came to my conclusion, topology pending, that the question does not specify ARP's for anything in particular so while a single static entry may certainly be a potential solution to add to the list, the 4-hour timeout, if I am correct in assuming such, even if it aged-out rapidly, that in itself would be an indication of something else happening. Opening a different can of worms here!
Yum - worms - midnight snack time! (Ok, 03:11 hours EST -5, but who's counting)
~M
>>> Guy Sherr <gsherr@gmail.com> 12/09/06 2:09 AM >>>
The router might be aging the ARP cache too quickly. You (assuming you are
permitted) might want to just fix a static ARP entry in the router. Once it
is in the ARP cache this way, it cannot age off the list and the router will
stop asking for a resolution.
Marcus Lasarko wrote:
> Certainly,
>
> If the router was sending excessive ARP's there could be a flood, possibly an issue on a neighboring segment that is passing through the router, assuming the routers MAC, so it could look like the router was pounding on the server causing it to intermittently fail. There could be other chicanery <evil> taking place, but I think (hope?) you get my point :)
>
> Make sense?
> ~M
>
>>>> "Lab Rat #109385382" <techlist01@gmail.com> 12/09/06 12:47 AM >>>
> Can you elaborate on the proxy-arp solution? How does that apply?
>
>
> -----Original Message-----
> From: Marcus Lasarko [mailto:mlasarko@co.ba.md.us]
> Sent: Friday, December 08, 2006 9:46 PM
> To: techlist01@gmail.com
> Cc: ccielab@groupstudy.com; cisco@groupstudy.com; security@groupstudy.com
> Subject: Re: ARP Scenario Question
>
> Greetings Ed,
>
> Sounds like a local-segment thing, so I expect your solution to be
> appropriate. "Keeps failing" concerns me more if there are other factors,
> aging, proxy-ARP, and so on. I do not have my rack online, but the syntax
> looks good as well as the approach to the solution.
>
> Take care,
> ~M
>
>>>> "Lab Rat #109385382" <techlist01@gmail.com> 12/08/06 11:58 PM >>>
> If the question states that "a particular server application on VLAN 100
> keeps failing due to ARPs received from a router", what could the possible
> resolution be?
>
> I'm thinking a MAC access-list configured to block ARP from the router to
> the server? Such as the following:
>
>
> mac access-list extended ROUTER_ARP
> permit host 1234.1234.1234 host 4321.4321.4321 0x806 0x0
>
> vlan access-map V-FILT 10
> action drop
> match mac address ROUTER_ARP
>
> vlan access-map V-FILT 20
> action forward
>
> vlan filter V-FILT vlan-list 100
>
>
>
> So, if ARP filtered before reaching the server will allow the application to
> work, will the above do the trick?
>
> Thanks,
>
> Ed
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Tue Jan 02 2007 - 07:50:37 ART