07-14-2005 03:41 PM - edited 03-02-2019 11:23 PM
Kind of a strange problem. I have 2 vlans on my 4507. One VLAN is for the 192.168.1.0 subnet and the other is for the 192.168.15.0. Some of my servers have dual NICs and connect to both VLANS. On the NIC that interacts with the 1.0 subnet, there is no packet loss but the NIC that is on the 15.0 subnet, I needed to configure the NIC for 10Mbps and either Full or Half duplex. Am I missing something here?
07-14-2005 03:59 PM
Are the nics identical ? and are they 100 Mbps capable ?
07-15-2005 04:28 AM
Yes, Identical NICs. I upgraded the drivers for the NICs but there was no difference in the performance. One server has Broadcom nics and the other server has Compaq nics. Also, I have a PIX connected to this VLAN and am experiencing connection problems with it. I've checked the physical port connections and the patch cables.
07-15-2005 06:09 AM
This isn't just a routing issue is it? What does the routing table look like on the Server? i.e. it has 2 NIC's so it will either have 2 default-gateways (one of which will be preferred so traffic destined outside of either local subnet will use this) or you have static routes configured on the host (or a routing protocol running on it).
Why don't you swap the Ethernet cables around on the Server and swap the Access VLANs on the switchports to see if the problem follows the VLAN or or the switchport?
Andy
07-15-2005 06:37 AM
I wouldn't think that it would be a routing issue since the PIX's ip is: 192.168.15.10 and the 4507 vlan int ip is: 192.168.15.4 and sometimes they can talk and other times they can. I'll move the PIX config to a different port to see if the problem goes away. Would you like for me to post the config of the affected ports?
07-15-2005 07:37 AM
What are the source IP addresses of clients? Is any traffic arriving on one interface but the return packets are going out of the other due to them being off-net? Hence my comment about routing.
Is this the outside or inside interface of the PIX?
Errors on the ports are only likely if you have a mis-match of speed/duplex or if there is an excessively high amount of broadcast or flooding traffic.
Andy
07-15-2005 09:24 AM
Good point on the routing issue. Below is what I have for my routing table:
S 192.168.12.0/24 [1/0] via 192.168.1.238
S 192.168.13.0/24 [1/0] via 192.168.1.238
S 192.168.14.0/24 [1/0] via 192.168.1.238
C 192.168.15.0/24 is directly connected, Vlan2
S 192.168.8.0/24 [1/0] via 192.168.1.238
S 192.168.10.0/24 [1/0] via 192.168.1.238
S 192.168.4.0/24 [1/0] via 192.168.1.238
S 192.168.20.0/24 [1/0] via 192.168.1.250
S 192.168.5.0/24 [1/0] via 192.168.1.18
S 192.168.6.0/24 [1/0] via 192.168.1.238
208.44.35.0/29 is subnetted, 1 subnets
S 208.44.35.248 [1/0] via 192.168.15.10
C 192.168.1.0/24 is directly connected, Vlan1
S 192.168.2.0/24 [1/0] via 192.168.1.238
192.168.3.0/24 is variably subnetted, 2 subnets, 2 masks
S 192.168.3.11/32 [1/0] via 192.168.1.251
S 192.168.3.0/24 [1/0] via 192.168.1.238
S* 0.0.0.0/0 [1/0] via 192.168.15.11
The int that I'm trying to ping on the PIX is the internal. I agree with miss-match of port speeds and duplex but I've set both the device port and switch port the same and I still get errors but only when I set the port to 10mbs/half.
07-15-2005 09:36 AM
What sort of loading is on the Network, in particular Broadcast & Flooding traffic? You say you only see errors when you set the port to 10/half - its possible that the network loading is quite high and you are receiving a lot of traffic on the interface where you see most errors. With that running at half-duplex you may be seeing a lot of collisions?
Andy
07-15-2005 11:25 AM
The cpu load on the switch is at 14%. Below is a show int of that particular port:
GigabitEthernet4/11 is up, line protocol is up (connected)
Hardware is Gigabit Ethernet Port, address is 0013.1a6b.6c6a (bia 0013.1a6b.6c
6a)
Description: PIX
MTU 1500 bytes, BW 100000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, link type is auto, media type is 10/100/1000-TX
input flow-control is on, output flow-control is on
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output never, output hang never
Last clearing of "show interface" counters 7w4d
Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
15606 packets input, 1682091 bytes, 0 no buffer
Received 9 broadcasts (0 multicast)
33 runts, 0 giants, 0 throttles
3006 input errors, 2973 CRC, 0 frame, 0 overrun, 0 ignored
0 input packets with dribble condition detected
2137130 packets output, 199670477 bytes, 0 underruns
3491 output errors, 1685 collisions, 0 interface resets
0 babbles, 446 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
07-16-2005 04:20 AM
It looks like a physical problem - the interface is 100/Full (set to auto so has negotiated this), but you are seeing collisions - in theory you can't get collisions on a full-duplex link so I would check out cabling and the PIX interface:
33 runts, 0 giants, 0 throttles
3006 input errors, 2973 CRC, 0 frame, 0 overrun, 0 ignored
0 input packets with dribble condition detected
2137130 packets output, 199670477 bytes, 0 underruns
3491 output errors, 1685 collisions, 0 interface resets
0 babbles, 446 late collision, 0 deferred
Andy
07-16-2005 04:28 AM
I swapped out cables last night on the port and noticed that the CRC errors dropped. Thanks for your help. I will keep you posted on what has been found.
07-16-2005 07:05 AM
Update: I recently swapped out cables and port configurations. The problem went from the NIC on VLAN 2 to the one on VLAN 1. Thinking that it could be a cable problem, I then swapped out cables but the problem stayed so I then moved the cable to a different port on a different card and the problem went away. I did the same procedure to the two other devices with the same problem and the problem went away as well. The card that is suspect now is a ws-x4548-gb-rj45v. Since this a POE card, I thought that maybe there is a problem with inline power even though inline is detected as auto but I set inline power to "never" and the problem persisted. This card was installed prior to power up and I can see it when I run "show mod". I was going to wipe the config of those ports but I was wondering if anyone has seen this type of problem?
07-16-2005 08:16 AM
I suggest you open a TAC case and get Cisco to investigate this further. It may just be a faulty module or maybe a batch?
Andy
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