12-05-2011 09:39 AM - edited 03-07-2019 03:44 AM
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
12-05-2011 09:45 AM
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
12-05-2011 10:32 AM
Thank you for the idea. I disabled the switchport access vlan on the switches but alas the VLANs are still dropping.
12-05-2011 10:34 AM
Do you have portfast configured an your access ports?
12-05-2011 10:35 AM
No, Sir. The only portfast ports we have are on a different network.
12-05-2011 12:25 PM
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
12-05-2011 12:38 PM
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.
12-05-2011 12:42 PM
Can you post a "sh int" for both ports?
Thanks,
Sean Brown (sean@sleepyshark.com)
voice: 212.760.1700 x7001
12-05-2011 12:45 PM
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
12-05-2011 12:49 PM
Nothing looks too bad in there, master side has some minor errors... Please post a "sh vtp c"
12-05-2011 12:55 PM
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
12-05-2011 01:03 PM
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
12-05-2011 01:26 PM
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.
12-05-2011 01:26 PM
thank you very much for the help, too
12-06-2011 05:24 AM
Any update?
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide