Forwarding over Trunk Question

typesh

Hey,

I needed a little clarification on forwarding frames over trunks.

I am running a lab with (2) 2950s connected over 1 trunk link. VTP is in place and both switches have a PC in VLAN 100. I did a continuous Ping from PC1 to PC2 (which are both in VLAN 100) and everything worked as expected. I went to SW2 and shut down VLAN100, and as expected, the Ping does not work.

My question is... Since VLAN100 is shutdown on SW2, does SW1 still send the Ping over the trunk, or does it somehow know that VLAN100 is shutdown on SW2? I am thinking that SW2 still gets the Ping, but does not forward it because VLAN100 is shutdown. VTP Pruning is not enabled.

Here's what it looks like:

PC1(VLAN100)---SW1---Trunk---SW2---PC2(VLAN100)


Thank you.

ColbyG

Run a sniffer and see what happens.

typesh

ColbyG wrote: »

Run a sniffer and see what happens.

Would the correct place to put the sniffer be on the trunk?

thenjduke

You can put it on the trunk line.

notgoing2fail

Wow, what an interesting question....

Please let us know what you discover....

typesh

Okay...this is really cool...

So I did a continuous Ping from PC1 in VLAN100 connected to SW1.

I let the Ping work for a few seconds (through the trunk to SW2 and then hitting PC2)... then I disconnected the Trunk cable and ran the sniffer on the Trunk Port of SW1.

I found this in the output between the Internet Protocol Info and the Ethernet II info:

802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 100

From what I gather, this is the 802.1Q header with the VLAN ID of 100?

ColbyG

Do a SPAN session on one of the switches (trunk port as the source), then stick the sniffer at the destination port of the session. Then start the capture and shut the SVI down like you were saying.

typesh

ColbyG wrote: »

Do a SPAN session on one of the switches (trunk port as the source), then stick the sniffer at the destination port of the session. Then start the capture and shut the SVI down like you were saying.

Sounds good.

First I gotta figure out how to configure it.
Using this link: Catalyst 2940 Switch Software Configuration Guide, 12.1(19)EA1 - Configuring SPAN [Cisco Catalyst 2940 Series Switches] - Cisco Systems

Thanks for the suggestion! For a while I was wishing I had a hub to stick on the trunk line.

Will post my results soon!

ColbyG

should be:

monitor session 1 source interface [trunk port]
monitor session 1 destination interface [sniffer port]

typesh

Okay, so I have run the lab with the SPAN Session in place.
By the way, Span Session is really cool...

PC1 has an IP Address of 192.168.100.1 and is connected to SW1 in VLAN100.
PC2 has an IP Address of 192.168.100.2 and is connected to SW2 in VLAN100.

Network topology:

PC1(VLAN100 & IP 192.168.100.1)---SW1---Trunk---SW2---PC2(VLAN100 & IP 192.168.100.2)

VTP is in place and VLAN database is synchronized on both switches.

Two things I have noted:

(1) For some reason the packets no longer have the 802.1q header which I noticed in my earlier post. I am not really sure why this is since the Pings are coming through on VLAN100.

(2) After I shutdown VLAN100 on SW2 (using "shutdown vlan 100") I was still able to see the ICMP Requests going over the trunk. This appears to mean that SW1 had no idea that SW2 had its VLAN100 shutdown, and SW1 still sent ICMP Echo Requests over the Trunk to SW2. Once I shut down VLAN100 on SW2, the port light went Orange. Also, after a few seconds, I noticed that the host connected to SW1 in VLAN100 started sending out ARP Requests for 192.168.1.1 MAC Address (it's default gateway). This ARP Request did not occur prior to me shutting down the VLAN.

So it appears to me that SW1 did not realize that SW2 had VLAN100 shutdown since the Pings kept going over the Trunk...

johnwest43

I believe that the 802.1q header is stripped of the frame as it leaves the access port toward the end device. The end device is oblivious to what vlan it belongs to.

typesh

johnwest43 wrote: »

I believe that the 802.1q header is stripped of the frame as it leaves the access port toward the end device. The end device is oblivious to what vlan it belongs to.

True... but I put the sniffer on the interface that was mirroring the trunk. So I expected to see the 802.1q header since the data coming in on the sniffer was data prior to entering SW2.

johnwest43

hmmmmm.........

could you show me a topo real quick, i cant wrap my head around it.

ZZOmega

How many VLANs exist on the switches, and is the trunk link operating in full-duplex? Operating the ports on half-duplex and initiating a constant data stream should eliminate any part of this process that VTP is messing with. Also, does VTP send a new revision when VLANs are simply shutdown, or just created/deleted? I would assume that shutting a VLAN down triggers an update, although I'm not sure what it would contain since VTP pruning is disabled.


Come to think of it, I'm not even sure if enabling VTP pruning would handle the situation differently. Shutting a VLAN interface down doesn't change the amount of ports assigned to it. VTP Pruning was designed to maximize the bandwidth of trunk links, and it would make more sense that enabling it makes use of information the switch already has, rather than starting to build a table from the first moment it's turned on. If this wasn't the case, then wouldn't VTP Transparent Mode switches throw the network for a loop? (pun not intended)


So the way it's working in my head is you've got two VLANs, 1(native) and 100 on both switches, which are both in VTP Server mode. They each have only one configured 802.1Q trunking port, which would make the trunking line not unlike a default route. As soon as VLAN 100 is shut down, the switches synchronize and decide to stop tagging traffic, since VLAN 1 is native and only VLAN with operational switchports. Actually nevermind, that sounds like an outcome VTP Pruning would have a part in. Unless, the shutdown of VLAN 100 converged, and VLAN 1 became the only active VLAN... Wait. That doesn't make sense since you were sniffing SW2's trunk port, and were still receiving traffic originating from PC 1. I know why PC1 would be sending ARP requests to its default gateway, but I'm stumped as to why the dot1q header stopped appearing.


Now I'm just speculating and throwing ideas around aloud because I don't really have a wide knowledge-base on these topics. CCNA curriculum doesn't really dive too deep into 802.1Q, VTP, or VLANs for that matter, which is probably why this is so interesting to me.

EDIT: I just read what I typed. Let me know if it makes no sense, because it's making no sense to me, and I wrote it. Then again, I've been up for too long. 8am and no sleep