cam aging tima and other problems in VLAN 1

[binaryflow]

the cam aging time for vlan 1 keeps getting reset to 15

I have enabled portfast on all host ports across my enviroment. I still have many hosts in VLAN 1. I have

some servers in VLAN 900. These servers become unaccessible to some of the clients in vlan 1 until they run tracert on a per client basis. after the tracert they are ok for the rest of the day. In the morning they have to run tracert again. If I move them

from vlan 1 to any other vlan they no longer exhibit the problem. I have several hundred users to migrate still out of Vlan 1, so if any body has any ideas, i would appreciate it.

[milan.kulik]

Hi,

ad "cam aging time for vlan 1 keeps getting reset to 15":

Don't you see many STP TCNs (Topology Change Notifications) in your network?

See http://www.cisco.com/warp/public/473/17.pdf

If yes, there is probably some flapping line connecting two switches or some loop in your network. Portfast on host ports should prevent TCN storm in other cases.

So find the source of TCNs and you'll fix the problem probably.

ad "after the tracert they are ok":

Do I understand correctly that you have to issue tracert command for each clinet on the server?

Or for each server on the client?

Does Ping have the same effect?

If yes, it's probably something regarding the ARP tables...

Are the default gateways configured correctly on the clients and servers? Or is some proxy ARP involved?

ad "I have several hundred users...VLAN1":

There are some maximum numbers of workstations recommended in a broadcst domain (i.e. VLAN), if I remember correctly it's 200 for NetBios (or mixed protocols) users, 300 for IPX users, 500 for pure IP users. So you should decrease the number of users. But it probably is not the key problem, there must be something wrong causing the cam aging resetting.

Good luck,

Milan

[binaryflow]

i have turned proxy arp off on VLAN one and it seems many of the problems hae gone away.

[binaryflow]

after turning off Proxy arp, for whatever reason the cam aging time seems to be holding now.

we have to run tracert for each client to the server. we do not have to run anything from the server,

Sometimes a ping will work, sometimes not. tracert works everytime.

there gateway is configured to the ip address of Vlan 1

[milan.kulik]

Are the servers and users connected to the same device? If not, whech devices are involved?

Is the default gateway configured correctly on the servers?

Who is providing routing?

Are there any ALCs or firewalls involved?

Do you see STP TCNs in VLAN1?

What is the total number of VLANs in your L2 network?

Are there any low-end (2900, e.g) switches involved?

Regards,

Milan

[binaryflow]

The servers are in VLAN 900 10.230.0.0 /16

gateway 10.230.0.1 is the IP address on VLAN 900 on MSFC2 on 6500.

The clients having trouble are in VLAN 1 10.200.0.0 /16 gateway for all VLAN 1 clients is 10.200.0.1 which is the ip address of VLAN 1 on the MCSFC2 on another 6500.

The two 6500's are connected via fiber over 1/1.

The VLAN 1 interface of the 6500 with VLAN 900 is 10.200.0.5 /16

fisrt tracert from clients that have the problem

10.200.0.1

10.200.0.5

timeout

tracert from clients that don't have the problem

10.200.0.1

10.200.0.5

10.230.200.70

I do not see any TCNs in VLAN 1

I have probably 75 VLANs in my L2 network.

All the switches involved are 4006s w/sup2s and 6500s with SUP2/MSFC2s.

[milan.kulik]

Hi,

it seems there is something wrong with ICMP redirect in your network.

What hapens when your PC wants to send an IP packet to 10.230.200.70?

It has 10.200.0.1 configured as the default gateway. So it is sending the packet to this next-hop. But the MSFC2 on the default gateway has an entry in it's routing table saying that 10.230.0.0 /16 should be routed through 10.200.0.5 (another router in the same segment - VLAN).

So the MSFC2 sends ICMP redirect back to the PC saying "send all packets with target 10.230.200.70 through 10.200.0.5 !". The PC should accept this redirect and you should be able to see the route via "route print" command issued in Windows command line.

I've got a feeling this scenario doesn't work in your network for some reason. (ICMP redirect not allowed on MSFC2, personal firewall denying ICMP redirects running on PCs, ...?).

I don't understand why tracert fixes the problem but I'd check routing table on the PC before and after the tracert and I bet there will be the difference described above.

My question about the number of VLANs in your network came from following idea:

Some low-end switches support only low number (64 typically) STP instances . If you configure more VLANs, some (random) VLANs don't run STP and it could bring loops to your topology.

Regards,

Milan

[binaryflow]

i have no ip redirects on the vlan 1 interfaces.

would that do it?

[milan.kulik]

Yes,

your router (MSFC2) doesn't send ICMP redirects then, see http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fipr_c/ipcprt1/1cfip.htm#1026257

You should decide what's better for you, I think you've got four options:

a) enable ICMP redirect

b) create int VLAN900 on both MSFCs (but you could get into asymetric routing troubles while having one MSFC configured as default gateway in VLAN1 and the other MSFC as default gateway in VLAN900)

c) configure HSRP in VLAN1 (and VLAN900 optionally)

d) configure a route to VLAN900 on each PC manually

Regards,

Milan