I've seen some funky things like this before, ie: with cable modems that
are supposed to be L1 only transparent but monkey up the stack.
If he hardcoded the mac's the adj should never change for CEF.
Verify it with 'sh adj detail' and sh ip arp.
Rodney
Jeff Fitzwater wrote:
IF you hardcoded the ARP in both routers, then they should never
change. So what exactly breaks? Can you ping the other router? What
is the other routers ARP entry and visa versa? They better be the ones
you put in.
Jeff
On Aug 13, 2009, at 4:53 PM, Graham Wooden wrote:
I say 30 minutes ... But I just had it occur on less than 5 minutes from
having the far end router and radio rebooted. And apparently my
attempt to
hardcode the MAC addresses on both ends didn't fix it. I am going to
start
blaming the radios I think ...
On 8/13/09 2:55 PM, "Jeff Fitzwater" <[email protected]> wrote:
It's interesting to note that this occurs at about the default ARP
timeout of 1800 seconds (Is that what the router is configured
for?). That implies that when the arp times out and the router arps
for the other end, it get an ARP REPLY from the wireless device. Is
that what you are saying? This would seem to say that the wireless
device may have some local proxy arp enabled so it responds to arp
requests on the local net.
Jeff Fitzwater
OIT Network Systems
Princeton University
On Aug 13, 2009, at 3:08 PM, Rodney Dunn wrote:
I can't follow the problem.
The router should try to defend the mac address it owns but if
another device simply takes over for it the only way to resolve that
is fix that device.
How exactly is it taking over?
What is the topo (ascii diagram would work).
Rodney
Graham Wooden wrote:
Hi there,
I have a customer hanging off of my edge router (6509/
Sup32/12.2.33SXI), doing a Point-to-Point wireless shot from the DC
to another site.
On myside, it's a L3 VLAN doing a /30 to a smaller Cisco router on
the other end. I am then statically routing some additional subnets
to the far end router.
After about 30 minutes of the link being powered up, the MAC
address of local Radio appears to take over the /30, and hence all
routing breaks. To fix this, seems to that if I hardcode the MAC
that belongs to the Cisco router on the far, all seems good and
traffic keeps on trucking. The other fix that was being done until
the hardcode went into affect, was power cycling the local radio.
My question is this: While the hardcoding seems to be the trick to
solve this, is there another command, maybe on the interface to
achieve this fix too?
I have yet to find out from the customer if there are any MAC/ARP
settings in his radios and that could be doing take over on purpose.
I am hoping that I can curb this type of behaviour without getting
him involved.
Thoughts to this? Thanks,
-graham
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
