why doesn't this vlan work?

[linnea.wren]

Hey...

Today I created 2 vlans. One works, the other doesn't. I'm defining "works" as a workstation on a port in the vlan, with an IP address in the correct subnet, can ping the interface address for that vlan.

Here's what I did:

.interface Vlan240

..description IP_Telephony_A

..ip address 10.10.240.3 255.255.255.0

..no ip redirects

..no ip proxy-arp

..standby 240 ip 10.10.240.1

..standby 240 priority 50

..standby 240 preempt

then:

.conf t

..vlan 240

for the other vlan:

.interface Vlan203

..description Johnson_Control

..ip address 10.10.203.3 255.255.255.0

..no ip redirects

..no ip proxy-arp

..standby 203 ip 10.10.203.1

..standby 203 priority 50

..standby 203 preempt

then:

.conf t

..vlan 203

Vlan 240 works. Vlan 203 doesn't.

sh run out put for the interfaces looks just like the commands above.

sh vlan output looks identical for each vlan.

Both vlans are up/up. Both are active.

sh int vlan output for vlan 203 follows. Notice how a lot of packets were recorded output in the 3rd line from the bottom. It seems likely that's a clue, but I'm not experienced enough to know where to look next.

.Vlan203 is up, line protocol is up

. Hardware is EtherSVI, address is 000c.cf6e.0900 (bia 000c.cf6e.0900)

. Description: Johnson_Control

. Internet address is 10.10.203.3/24

. MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,

.. reliability 255/255, txload 1/255, rxload 1/255

. Encapsulation ARPA, loopback not set

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

. Last input 02:15:01, output 00:00:01, 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 0 bits/sec, 0 packets/sec

. 5 minute output rate 0 bits/sec, 0 packets/sec

. L2 Switched: ucast: 0 pkt, 0 bytes - mcast: 0 pkt, 0 bytes

. L3 in Switched: ucast: 0 pkt, 0 bytes - mcast: 0 pkt, 0 bytes mcast

. L3 out Switched: ucast: 0 pkt, 0 bytes mcast: 0 pkt, 0 bytes

.. 2 packets input, 188 bytes, 0 no buffer

.. Received 2 broadcasts (0 IP multicast)

.. 0 runts, 0 giants, 0 throttles

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

.. 4956 packets output, 358624 bytes, 0 underruns

.. 0 output errors, 0 interface resets

.. 0 output buffer failures, 0 output buffers swapped out

This is on a 6509, IOS v12.2, in vtp server mode.

I was just thinking maybe I should delete the offending vlan - just start over.

Anyone have a thought on this situation?

Any help is much appreciated...

[lgijssel · Accepted solution]

Both config look pretty similar. Are you sure that the port where you tested was in the correct vlan and had the correct ip adress?

I noticed that you are using standby group numbers. This is not required though. You will only need this when you have multiple HSRP pairs running on the same vlan.

Perhaps you made a mistake with the numbers with dual HSRP-active nodes as a result? You can use the command: sh stand to verify the HSRP status. If one is active and the other standby and both sides confirm this you can be certain that there is data traversing the vlan. If this is not the case, you should verify and eventually reconfigure the vlan.

Regards,

Leo

[linnea.wren]

Hi Leo,

Thanks very much. Based on the sh standby output, I poked around in a different direction, and got things fixed.

What it was:

Our core is 3 6509s. 1 was vtp server, the other 2 were clients, up till about 2 months ago, when a contractor upgraded from SupIIs to Sup720s.

They put the 2 client 6509s in Transparent mode, which is standard procedure at their company (transparent mode until the network is fully configured and proven stable, then switch to client).

My test workstation was connected to a 4006 that is a vtp client, so that switch had the vlan. But, there is a transparent mode 6509 in between the 4006 and the 6509 where I created the vlan.

This is the first time I've created a Vlan from scratch (this system was built by contractors - I'm learning as I go), so inexperience, combined with these 2 switches in transparent mode was more than I could handle on my own.

Thanks Again!

[rdanevich]

Excellent find and kudos to you tracking down the problem!!! This is what makes "experience"!