Interface speed, bandwidth

[Shawnw4401]

I am not sure if I am understanding the whole 'speed' concept right. Going from the modem to the PC directly, I am getting approximately 71Mb/s. When I add the switch in between these two devices, I am staying at a constant 7.1Mb/s. Here's the following output on the switch:

interface FastEthernet1/0/19
switchport access vlan 192
switchport mode access
speed 100
duplex full
spanning-tree portfast
spanning-tree bpduguard enable
end

Switch1#sh int f1/0/19
FastEthernet1/0/19 is up, line protocol is up (connected)
Hardware is Fast Ethernet, address is 001a.2f87.b615 (bia 001a.2f87.b615)
Description: ## Users_LAN ##
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, media type is 10/100BaseTX
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:10:01, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 14000 bits/sec, 3 packets/sec
5 minute output rate 124000 bits/sec, 7 packets/sec
22781235 packets input, 2840105450 bytes, 0 no buffer
Received 358255 broadcasts (301987 multicasts)
0 runts, 0 giants, 0 throttles
90073 input errors, 90072 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 301987 multicast, 0 pause input
0 input packets with dribble condition detected
38367454 packets output, 48250785424 bytes, 0 underruns
0 output errors, 0 collisions, 1 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 PAUSE output
0 output buffer failures, 0 output buffers swapped out

Is there something I am missing?

[Philip D'Ath · Accepted solution]

You are getting lots of interface errors.

90073 input errors, 90072 CRC, 0 frame, 0 overrun, 0 ignored

Most likely you have a speed and/or duplex error.  Remove those hard coded values:

interface FastEthernet1/0/19
  speed auto
  duplex auto

[Shawnw4401]

Philip,

I am unsure if those CRCs was from this issue. I didn't happen to even notice those until you mention it. I did set the speed/duplex to auto. Nothing changed in the interface though. It's still Full-duplex and 100Mb/s. I did clear the errors to see if they are still coming in. Here's the result:

Switch1#show int f1/0/19
FastEthernet1/0/19 is up, line protocol is up (connected)
Hardware is Fast Ethernet, address is 001a.2f87.b615 (bia 001a.2f87.b615)
Description: ## Users_LAN ##
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, media type is 10/100BaseTX
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:04:46, output 00:00:00, output hang never
Last clearing of "show interface" counters 01:06:56
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 18000 bits/sec, 14 packets/sec
5 minute output rate 707000 bits/sec, 57 packets/sec
17701 packets input, 3203826 bytes, 0 no buffer
Received 1472 broadcasts (1318 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 1318 multicast, 0 pause input
0 input packets with dribble condition detected
40869 packets output, 47527594 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 PAUSE output
0 output buffer failures, 0 output buffers swapped out

Speed test is still showing roughly 7-8Mb/s.

[Philip D'Ath]

It is is still showing 100/full then it was definitely an error to hard code them to 100/full.

So there are two ports involved.  One to the PC and one to the "modem".  Can you show both ports please.

[Shawnw4401]

Here are the configuration for both ports.

interface FastEthernet1/0/2
switchport access vlan 192
switchport mode access
spanning-tree portfast

interface FastEthernet1/0/19
switchport access vlan 192
switchport mode access
spanning-tree portfast
spanning-tree bpduguard enable

[Shawnw4401]

I think I had found the error in both. My connection to the modem as also having a lot of CRC errors, as shown:

FastEthernet1/0/2 is up, line protocol is up (connected)
Hardware is Fast Ethernet, address is 001a.2f87.b604 (bia 001a.2f87.b604)
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, media type is 10/100BaseTX
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 6000 bits/sec, 1 packets/sec
5 minute output rate 3000 bits/sec, 1 packets/sec
92413689 packets input, 118612265337 bytes, 0 no buffer
Received 353778 broadcasts (322262 multicasts)
2 runts, 0 giants, 0 throttles
32317 input errors, 32315 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 322262 multicast, 0 pause input
0 input packets with dribble condition detected
73532581 packets output, 9797750323 bytes, 0 underruns
0 output errors, 0 collisions, 1 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 PAUSE output
0 output buffer failures, 0 output buffers swapped out

Once I fixed the connection, the speed seemed to resumed back to normal. Now, why was hard coding them to be full/100Mb/s a bad idea? The reason why I did it to begin with was because they didn't want to sync up at first. I was getting half/full.

[Philip D'Ath · Accepted solution]

The rule for a port is if you can't auto-negotiate then you must use half duplex.

When you lock a port at a particular speed you disable auto-negotiation.  So when you locked your end at 100/full the other end could not auto-negotiate, and had to default to half duplex, creating an instant error.

It would be great if you could rate and mark helpful posts.

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages wha2tsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

The rule for a port is if you can't auto-negotiate then you must use half duplex.

Just to expand a bit on this . . .

Both device ports either need to auto-negotiate duplex or they should be hard coded with a compatible duplex (ideally speed too).

When one device is set to full duplex and the other is set to auto-negotiate, the latter being unable to determine the duplex mode will use half duplex.  (NB: generally, auto-negotiate can determine what speed the other side is using.)

Interconnected ports, one running at half duplex and one running at full duplex, will pass traffic, but with many errors and very, very slowly.

(NB: ports running at different speeds won't interoperate.)

[Shawnw4401]

Thanks, I appreciate the help on everything and the useful tip. I didn't know that it worked that way.