Trunked VLANs Dropping

mikeyggeary · ‎12-05-2011

Good Afternoon,

I was wondering if someone could point me in the right direction to fix this issue. Any help in the matter would be much appreciated. Please let me know if any other information is needed.

Here is what is happening:

Between every minute to 5 minutes, all VLANs except the native drop packets and stop responding for about 10-25 seconds. There are no Ethernet, STP, or CDP errors recorded.

Ethernet port configs:

c2950-1#sho run int fa0/14

Building configuration...

Current configuration : 175 bytes

!

interface FastEthernet0/14

switchport access vlan 112

switchport trunk native vlan 112

switchport mode trunk

-==-=-=-=-==-

c2940-2# sho run int fa0/1

Building configuration...

Current configuration : 141 bytes

!

interface FastEthernet0/1

switchport access vlan 112

switchport trunk native vlan 112

switchport mode trunk

Reza Sharifi · ‎12-05-2011

Hi,

Since your uplink is in trunk mode, you do not need "switchport access vlan 112" in your config.

access ports are ports connecting to your end devices.

HTH

mikeyggeary · ‎12-05-2011

Thank you for the idea. I disabled the switchport access vlan on the switches but alas the VLANs are still dropping.

Reza Sharifi · ‎12-05-2011

Do you have portfast configured an your access ports?

mikeyggeary · ‎12-05-2011

No, Sir. The only portfast ports we have are on a different network.

sleepyshark · ‎12-05-2011

I'm going to assume that you've verified physical connectivity to the port? (ie: is there ANY loss of sync during the outage?) (assuming cabling problem)
Have you tried another port on your switch? (assuming physical problem)
Have you swapped out your switch for another? (assuming backplane/iOS problem)

Sorry i'm being so basic, but even if a log/message isn't generated doesn't necessarily mean there isn't a problem.

Thanks,

Sean Brown (sean@sleepyshark.com)

voice: 212.760.1700 x7001

Wanna learn more about me? Check out my bio

Follow me on LinkedIn

mikeyggeary · ‎12-05-2011

Ethernet port connectivity and the port itself are good. I have not tried swapping the switch yet as it is about 5 hours away.

I would think that everything physical is functioning properly as the native VLAN stays active and pinging, just the non-native VLANs drop. But then again, I could be wrong.

sleepyshark · ‎12-05-2011

Can you post a "sh int" for both ports?

Thanks,

Sean Brown (sean@sleepyshark.com)

voice: 212.760.1700 x7001

Wanna learn more about me? Check out my bio

Follow me on LinkedIn

mikeyggeary · ‎12-05-2011

Master side:

FastEthernet0/14 is up, line protocol is up

Hardware is Fast Ethernet, address is 000c.859c.464e (bia 000c.859c.464e)

MTU 1500 bytes, BW 100000 Kbit, DLY 1000 usec,

reliability 255/255, txload 48/255, rxload 5/255

Encapsulation ARPA, loopback not set

Keepalive set (10 sec)

Full-duplex, 100Mb/s

input flow-control is off, output flow-control is off

ARP type: ARPA, ARP Timeout 04:00:00

Last input 00:00:02, output 00:00:00, output hang never

Last clearing of "show interface" counters 5d03h

Input queue: 1/75/0/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: fifo

Output queue :0/40 (size/max)

5 minute input rate 2130000 bits/sec, 1567 packets/sec

5 minute output rate 18861000 bits/sec, 2159 packets/sec

614033349 packets input, 2717617994 bytes, 0 no buffer

Received 636512 broadcasts, 0 runts, 0 giants, 0 throttles

2 input errors, 0 CRC, 2 frame, 0 overrun, 0 ignored

0 watchdog, 189806 multicast, 0 pause input

0 input packets with dribble condition detected

840717007 packets output, 223195368 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

Remote Side:

FastEthernet0/2 is up, line protocol is up (connected)

Hardware is Fast Ethernet, address is 001f.26b4.6002 (bia 001f.26b4.6002)

MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,

reliability 255/255, txload 47/255, rxload 5/255

Encapsulation ARPA, loopback not set

Keepalive set (10 sec)

Full-duplex, 100Mb/s, media type is 100BaseTX

input flow-control is unsupported output flow-control is unsupported

ARP type: ARPA, ARP Timeout 04:00:00

Last input 00:00:00, output 00:00:00, output hang never

Last clearing of "show interface" counters 00:42:58

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 2182000 bits/sec, 1598 packets/sec

5 minute output rate 18634000 bits/sec, 2179 packets/sec

4081572 packets input, 818480639 bytes, 0 no buffer

Received 2736 broadcasts (0 multicast)

0 runts, 0 giants, 0 throttles

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

0 watchdog, 1566 multicast, 0 pause input

0 input packets with dribble condition detected

5303954 packets output, 1006252315 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

sleepyshark · ‎12-05-2011

Nothing looks too bad in there, master side has some minor errors... Please post a "sh vtp c"

mikeyggeary · ‎12-05-2011

Master:

VTP statistics:

Summary advertisements received : 35488

Subset advertisements received : 1

Request advertisements received : 1

Summary advertisements transmitted : 170906

Subset advertisements transmitted : 3

Request advertisements transmitted : 0

Number of config revision errors : 0

Number of config digest errors : 0

Number of V1 summary errors : 1

VTP pruning statistics:

Trunk Join Transmitted Join Received Summary advts received from

non-pruning-capable device

---------------- ---------------- ---------------- ---------------------------

Fa0/14 544701 545068 0

Remote

VTP statistics:

Summary advertisements received : 45082

Subset advertisements received : 0

Request advertisements received : 0

Summary advertisements transmitted : 44338

Subset advertisements transmitted : 0

Request advertisements transmitted : 0

Number of config revision errors : 0

Number of config digest errors : 0

Number of V1 summary errors : 0

VTP pruning statistics:

Trunk Join Transmitted Join Received Summary advts received from

non-pruning-capable device

---------------- ---------------- ---------------- ---------------------------

Fa0/1 2171226 2170343 0

sleepyshark · ‎12-05-2011

Not a smoking gun, but it does appear there are some issues on the "master" switch - there are some interface errors on fa0/14, which are also coinciding with VTP errors.

I'd check cabling first, re-terminate the master switch fa0/14 connector - Trunking has to negotiate, native VLANs just pass traffic, if there's a problem on the transmit/receive pairs dropping packets, it would cause your trunk to drop, but may not necessarily show a [noticeable] loss of connectivity on the native VLAN.

If you have the ability to swap cables i'd do that first - that will tell you right away if it's a cable problem or switch problem (ie: if you swap cables and the problem continues = switch/port problem, if you swap cables and the problems subsides = cable problem, and you've fixed it).

Thanks,

Sean Brown (sean@sleepyshark.com)

voice: 212.760.1700 x7001

Wanna learn more about me? Check out my bio

Follow me on LinkedIn

mikeyggeary · ‎12-05-2011

Very interesting. I knew that trunking had to negotiate but I didn't know that if it failed, the native would still pass traffic. Do you know how often this negotiation takes place?

As for the cabling, I will definetly swap the patch cord out. I will post the results when it gets completed.

mikeyggeary · ‎12-05-2011

thank you very much for the help, too

sleepyshark · ‎12-06-2011

Any update?