Slow Ping response when directly connected to Core/Server-Switch

matthiaseberle · ‎01-03-2005

We have a small site with a Cisco 4506 as a Layer 3 Core Switch (Supervisor Engine II Plus, IOS 12.2).

We use a 24 port 1000Base-T module (WS-X4424-GB-RJ45) for connecting some servers (Subnet 1).

We use two 48 port 100Base-T modules (WS-X4148-RJ) for connecting the PCs in the same building/floor (Subnet 2).

We use a 18 port GBIC (1GBit/s) module (WS-X4418-GB) for connecting some access switches (Cisco 2950) with trunk links (Subnet 1 + 2 + 3 allowed on trunks).

When pinging a server from a PC (Subnet 2) which is connected to an access switch the response time is about 1 ms (PC --> Access Switch --> Trunk to Core-Switch --> Server).

When pinging a server from a PC (Subnet 2) which is directly connected to the Core Switch the response time is about 10 ms (PC --> Core-Switch --> Server).

It seems to me that the physical interfaces (configuration) of the Core-Switch are the problem.

Any ideas, why the ping-response is faster when connecting via an additional access switch via a trunk?

I tried different PCs with different NICs. I tried fixed speed and duplex configuration. Portfast is enabled. CEF is enabled.

m.sir · ‎01-03-2005

It could be speed or duplex problem. Try to set port speed 100 and dupex full

Kevin Dorrell · ‎01-03-2005

This does look like a duplex mismatch issue. You say you have tried fixing the speed and duplex, but did you do this on both the switchport and on the PC NIC? You should never have auto on one side of the link, and forced full-duplex on the other; that would be sure to give you problems. auto-auto works OK, as does full-full or half-half.

Do the switchports on the WS-X4148-RJ show any error counts?

Is it just the first ping that is delayed, or is it subsequent pings as well? Is the 10 msec consistent or variable?

On the WS-X4148-RJ, is there any heavy traffic going on through ports that are adjacent to the one you are testing? When I say "adjacent" in this context, I mean in the same group of ports, counting 8 ports at at a time. Each 8 ports shares a 1 Gbit backplane connection up to the supervisor.

OTOH, for information, are your subnets all on the same VLAN (as secondary subnets), or is each one on a different VLAN (as is more normal)? Are the VLANs of the access ports set up any differently on the core switch than on the access switches?

Kevin Dorrell

Luxembourg

matthiaseberle · ‎01-03-2005

@Kevin.Dorrell

Actually I tried to fix 100/full only on the switch side. I will try again tomorrow, fixing it on both sides.

BTW: Is there any difference between a connection that has successfully autonegotiated to 100/full and a connection with 100/full fixed?

I will check the error counts tomorrow.

All Pings are delayed. They are quite constant at 10ms (about 1 of 30 might be 9 or 11).

BTW: What does it mean, if only the first ping is delayed? I saw this often in other situations.

No, there is no heavy traffic on adjacent ports.

Each subnet has a different VLAN (as normal;-).

On the CoreSwitch the interfaces look like:

...

interface FastEthernet4/23

description Floor 3

switchport access vlan 11

switchport mode access

spanning-tree portfast

...

interface Vlan11

ip address 10.11.0.1 255.255.0.0

ip access-group 101 in

ip helper-address 10.10.1.1

and on the access Switches (Cisco 2950) it looks like:

...

interface FastEthernet0/5

switchport access vlan 11

switchport mode access

spanning-tree portfast

...

interface Vlan11

ip address 10.11.0.17 255.255.0.0

no ip route-cache

...

Matthias Eberle

Germany

Kevin Dorrell · ‎01-03-2005

Matthias,

Yes, there is a difference between a negotiated 100/full and a fixed 100/full. When you fix full-duplex, you effectively turn off negotiation on that side of the link. The other side does not see any negotiation, so it falls back to the default, which is half-duplex. Therefore you get a duplex mismatch. Interestingly, the speed is correct even if negotiation is turned off on one side only, because each side can deduce that from the clock from the partner. But not the duplex.

If the first ping is delayed, but not subsequent pings, that usually points to the delay in ARP and/or frame flooding and/or setting up route cache. The first frame needs to ARP first, perhaps get routed, and perhaps get flooded to all ports. From the second frame onwards, the ARP entries are known, the egress port is known, and the router fast-cache (maybe) is set up.

Your configs look OK. I guess you set the default gateway on the PC to 10.11.0.1, and you do not change it when you move the PC onto the core switch. That is all OK.

Let us know how you get on with auto-auto.

Kevin Dorrell

Luxembourg

glen.grant · ‎01-03-2005

The best way to look for errors on these switches is to use the "show interface counters errors " , this will give you a nice readout like the old catos switches which is a lot easier to read than trying to go thru a show interface for all ports .