[c-nsp] ARP table corrupted?

[Arturo Servin]

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