[c-nsp] ARP table corrupted?
Ruben Montes
Ruben.Montes at eu.didata.com
Thu Sep 1 02:21:40 EDT 2005
Yes, the arp table is the same
-----Mensaje original-----
De: Arturo Servin [mailto:aservin at remoteconfig.net]
Enviado el: miércoles, 31 de agosto de 2005 23:27
Para: Ruben Montes
CC: cisco-nsp at puck.nether.net
Asunto: Re: [c-nsp] ARP table corrupted?
Ruben Montes wrote:
>Hello,
>
>I'm suffering a weird problem.
>
>I'm trying to ping the ip address of two switches (c2950-12.1(22)EA1) that are conected in the same vlan that I am in and I get no response until I do a clear arp in the switches. Then I can ping them again, but if I wait some minutes I get the same problem and I have to clear the arp table. They are in the same vlan, so no L3 issues involved.
>The diagram:
>
>core1 -----switch1-----switch2
> |
>core2--------
>
>Due to the nature of the connections, I think is a problem between the core and the switches. I have these outputs in switch1:
>
>switch1#sh int trunk
>Port Mode Encapsulation Status Native vlan
>Fa0/1 on 802.1q trunking 1
>Fa0/2 on 802.1q trunking 1
>
>Port Vlans allowed on trunk
>Fa0/1 1,45,55,73,254,1002-1005
>Fa0/2 1,45,55,73,254,1002-1005
>
>Port Vlans allowed and active in management domain
>Fa0/1 1,45,55,73,254
>Fa0/2 1,45,55,73,254
>
>Port Vlans in spanning tree forwarding state and not pruned
>Fa0/1 1,45,254
>Fa0/2 55,73
>
>Fa0/1 connects with core1 and fa0/2 with core2. Vlan with problems is 254. This side is normal (spanning-tree is forwarding vlan 254 in Fa0/1, Fa0/2 is blocking) but in core1 side I have:
>
>core1#sh int fa1/3 trunk
>Port Mode Encapsulation Status Native vlan
>Fa1/3 on 802.1q trunking 1
>
>Port Vlans allowed on trunk
>Fa1/3 1,45,55,73,254
>
>Port Vlans allowed and active in management domain
>Fa1/3 1,45,55,73,254
>
>Port Vlans in spanning tree forwarding state and not pruned
>Fa1/3 1
>
>The strange thing here is last line: it seems to be pruning vlan 254 for that connection!!! Switch1 and 2 are vtp transparent but obviously have vlan254 configured and core1 shouldn't prune vlan 254 in this connection. I think this is the problem. It is not a configuration issue; I had a problem similar in the past that was solved doing a shut/no shut of the interface. Anyway, as you can see, vlan 45 is also being prunned and there are clients there: I cannot explain why they're not affected...!
>
>What do you think?
>
>Regards,
>
>Ruben
>_______________________________________________
>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/
>
>
>
>
The arp table after and before the sucessful ping are the same for
that IPs?
-as
--
Remote Config, The Remote Configuration Company
http://www.remoteconfig.net
Global Service Offices
contact at remoteconfig.net
More information about the cisco-nsp
mailing list