cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1094
Views
0
Helpful
12
Replies

4507 Vlan issue

brammathorn
Level 1
Level 1

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?

12 Replies 12

thisisshanky
Level 11
Level 11

Are the nics identical ? and are they 100 Mbps capable ?

Sankar Nair
UC Solutions Architect
Pacific Northwest | CDW
CCIE Collaboration #17135 Emeritus

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.

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

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?

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

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.

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

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

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

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.

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?

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

Review Cisco Networking for a $25 gift card