[c-nsp] Bridge devices - ARP takeover
Graham Wooden
graham at g-rock.net
Thu Aug 13 19:08:36 EDT 2009
I know - the whole thing is bizarre. I was able to get access to that
remote C2621, and noticed that ip proxy-arp was disabled. I enabled to to
match my interface on the 6500. It's been up for close to an hour now with
no issues (hopefully I just didn't jinx myself).
I removed the hardcoded MACs as that didn't seem to help. And no, I can't
see the otherside at all when the issue arises.
Here is the "show adj detail" from the VLAN (6500 side). The
172.20.255.248/28 is the secondary address subnet on the VLAN to manage the
radios. Poorman's OOB. Radios are .250 and .251.
IP Vlan201 12.nn.nn.246(11)
291469 packets, 216514528 bytes
epoch 0
sourced in sev-epoch 2
Encap length 14
000628A343000004DEFF70000800
ARP
IP Vlan201 172.20.255.250(7)
376 packets, 46187 bytes
epoch 0
sourced in sev-epoch 2
Encap length 14
000B6B2E5A2C0004DEFF70000800
ARP
IP Vlan201 172.20.255.251(7)
370 packets, 43771 bytes
epoch 0
sourced in sev-epoch 2
Encap length 14
000B6B2E59FB0004DEFF70000800
ARP
And then from the 2621 side ...
IP FastEthernet0/0 172.20.255.251(5)
1983 packets, 266146 bytes
000B6B2E59FB000628A343000800
ARP 03:58:41
Epoch: 0
IP FastEthernet0/0 172.20.255.249(5)
7 packets, 686 bytes
0004DEFF7000000628A343000800
ARP 03:26:18
Epoch: 0
IP FastEthernet0/0 xxxxxx(7) (12.nn.nn.245)
232362 packets, 51704892 bytes
0004DEFF7000000628A343000800
ARP 02:42:29
Epoch: 0
On 8/13/09 4:58 PM, "Rodney Dunn" <rodunn at cisco.com> wrote:
> 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" <jfitz at Princeton.EDU> 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 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
>>>>> 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