VLAN Management Domains explained at Layer 2 and 3 (from end of previous post), TSHOOT / Real world on the job troubleshooting of VLAN issues!

To demonstrate allowing and disallowing the VLANs across a Trunk I am re-configuring the above Topology, but I wanted to touch quickly on the management domain output from my previous tired ramblings.

The management domain VLANs have to do with VTP (next topic to cover), and in the case I was looking at, it was as I had suspected a VTP Management domain.

However I came across some interesting output when configuring the above Topology:

SW1(config)#vlan 300

SW1(config)#do sh vlan brief

VLAN Name Status Ports
—- ——————————– ——— ——————————-
1 default active Fa1/0/2, Fa1/0/4, Fa1/0/5
Fa1/0/6, Fa1/0/7, Fa1/0/8
Fa1/0/9, Fa1/0/11, Fa1/0/12
Fa1/0/13, Fa1/0/14, Fa1/0/15
Fa1/0/16, Fa1/0/17, Fa1/0/18
Fa1/0/19, Fa1/0/21, Fa1/0/22
Fa1/0/23, Fa1/0/24, Gi1/0/1
Gi1/0/2
12 VLAN0012 active Fa1/0/1
34 VLAN0034 active Fa1/0/3
300 VLAN0300 active
1002 fddi-default act/unsup
1003 token-ring-default act/unsup
1004 fddinet-default act/unsup
1005 trnet-default act/unsup

SW1(config)#do sh int trunk

Port Mode Encapsulation Status Native vlan
Fa1/0/10 on 802.1q trunking 1
Fa1/0/20 on 802.1q trunking 1

Port Vlans allowed on trunk
Fa1/0/10 1-99,101-4094
Fa1/0/20 1-99,101-299,301-399,401-4094

Port Vlans allowed and active in management domain
Fa1/0/10 1,12,34,300

Fa1/0/20 1,12,34

Port Vlans in spanning tree forwarding state and not pruned
Fa1/0/10 1,12,34,300

Fa1/0/20 1,12,34
SW1(config)#

As you can see I haven’t gotten around to “switchport trunk allowed vlan all” yet before I found, that first any VLAN created on the switch seems to be put in the management domain / VLAN Database / vlan.dat file in flash, and that it is only being allowed over certain redundant trunks because STP (Spanning Tree Protocol) put them into a non-forwarding state (get to that probably after VTP).

However, the VLANs only remain in the Management Domain if their “interface” is not shutdown, pay attention to the portions highlighted in red after a VLAN is shutdown:

SW1(config)#vlan 300
SW1(config-vlan)#shut
SW1(config-vlan)#do sh vlan brief

VLAN Name Status Ports
—- ——————————– ——— ——————————-
1 default active Fa1/0/2, Fa1/0/4, Fa1/0/5
Fa1/0/6, Fa1/0/7, Fa1/0/8
Fa1/0/9, Fa1/0/11, Fa1/0/12
Fa1/0/13, Fa1/0/14, Fa1/0/15
Fa1/0/16, Fa1/0/17, Fa1/0/18
Fa1/0/19, Fa1/0/21, Fa1/0/22
Fa1/0/23, Fa1/0/24, Gi1/0/1
Gi1/0/2
12 VLAN0012 active Fa1/0/1
34 VLAN0034 active Fa1/0/3
300 VLAN0300 act/lshut
1002 fddi-default act/unsup
1003 token-ring-default act/unsup
1004 fddinet-default act/unsup
1005 trnet-default act/unsup
SW1(config-vlan)#do sh int trunk

Port Mode Encapsulation Status Native vlan
Fa1/0/10 on 802.1q trunking 1
Fa1/0/20 on 802.1q trunking 1

Port Vlans allowed on trunk
Fa1/0/10 1-99,101-4094
Fa1/0/20 1-99,101-299,301-399,401-4094

Port Vlans allowed and active in management domain
Fa1/0/10 1,12,34

Fa1/0/20 1,12,34

Port Vlans in spanning tree forwarding state and not pruned
Fa1/0/10 1,12,34

Fa1/0/20 1,12,34
SW1(config-vlan)#

First note shutting the VLAN removed it from mgmt domain and STP configs for the Trunk!

So there is some output to be aware of, and also be aware of what I did was at a Layer 2, VTP / STP level. What I am used to as VLANs in a management domain are for actual administrators, and you actually assign your own VLAN and the switch an access IP as such:

Layer 2

SW1(config)#vlan 300
SW1(config-vlan)#ip add ?
% Unrecognized command

Layer 3

SW1(config-vlan)#exit
SW1(config)#interface vlan 300
SW1(config-if)#ip add ?
*Mar 1 01:36:00.104: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan300, changed state to down
A.B.C.D IP address
dhcp IP Address negotiated via DHCP
pool IP Address autoconfigured from a local DHCP pool

So just an important distinction and something to get familiar with, the different functionality in the layer 2 configuration (where you might add a name, or shut down the VLAN), however when you put “int …” it treats it as a virtual Layer 3 interface that can be assigned an IP address.

So enough of that for now, we will beat that horse to death later, now I want to demonstrate removing and allowing a VLAN from the Trunk (I am just going to remove the cable from Fa1/0/20 for this).

Ok, quick connectivity test among our two VLANs:

R1#ping 10.0.0.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/4 ms
R1#
ASR#5
[Resuming connection 5 to r3 … ]

R3#ping 10.0.0.4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.4, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/2/4 ms
R3#ping 10.0.0.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)
R3#

As the routers haven’t communicated in a bit they needed that first dot to think about it, but they are able to ping within their VLAN, and tested R3 is not able to ping R2 outside of its VLAN.

I said in the last post but it bares repeating, if you are going to dis-allow a VLAN, it should be on the switch that the VLAN resides in, so you are not wasting local and remote resources for unnecessary traffic.

That being said, lets do exactly that:

SW1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
SW1(config)#int fa1/0/10
SW1(config-if)#switchport trunk allow vlan remove 12
SW1(config-if)#
ASR#3
[Resuming connection 3 to r1 … ]

R1#ping 10.0.0.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)
R1#

Now you may look at those dots and say “That was just pinging a moment ago, that is a layer 3 issue!”

Always start at Layer 1, and work your way up, with a bad cable no data is going anywhere. So one approach to troubleshoot this, as this is something you may see on TSHOOT or in real life in a production environment, is to use “debug ip packet” to see what is going on:

R1#ping 10.0.0.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:

*Aug 29 08:03:50.511: IP: s=10.0.0.1 (local), d=10.0.0.2 (FastEthernet0/1), len 100, sending
*Aug 29 08:03:50.511: IP: s=10.0.0.1 (local), d=10.0.0.2 (FastEthernet0/1), len 100, sending full packet.
*Aug 29 08:03:52.511: IP: s=10.0.0.1 (local), d=10.0.0.2 (FastEthernet0/1), len 100, sending
*Aug 29 08:03:52.511: IP: s=10.0.0.1 (local), d=10.0.0.2 (FastEthernet0/1), len 100, sending full packet.
*Aug 29 08:03:54.511: IP: s=10.0.0.1 (local), d=10.0.0.2 (FastEthernet0/1), len 100, sending
*Aug 29 08:03:54.511: IP: s=10.0.0.1 (local), d=10.0.0.2 (FastEthernet0/1), len 100, sending full packet.
*Aug 29 08:03:56.511: IP: s=10.0.0.1 (local), d=10.0.0.2 (FastEthernet0/1), len 100, sending
*Aug 29 08:03:56.511: IP: s=10.0.0.1 (local), d=10.0.0.2 (FastEthernet0/1), len 100, sending full packet.
*Aug 29 08:03:58.511: IP: s=10.0.0.1 (local), d=10.0.0.2 (FastEthernet0/1), len 100, sending
*Aug 29 08:03:58.511: IP: s=10.0.0.1 (local), d=10.0.0.2 (FastEthernet0/1), len 100, sending full packet.
Success rate is 0 percent (0/5)
R1#

For production networks in the real world, you’d of course use an ACL at the end of your debug command specifying the output, but in terms of TSHOOT, you want to verify that the pings are even leaving the local router / switch in the exam room – So you want to verify in every way / shape / form that this device is doing what it needs to.

Now this is a very interesting behavior every CCNP should know about:

SW1#debug ip packet
IP packet debugging is on
SW1#
ASR#3
[Resuming connection 3 to r1 … ]

R1#ping 10.0.0.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:

ASR#1
[Resuming connection 1 to sw1 … ]

SW1#sh debug
Generic IP:
IP packet debugging is on

Even with “ip routing” configured at a global level, this switch’s debug is not showing any packet information in its debug output of “debug ip packet”, so this is where our Ninja skills in verifying Trunks comes in:

SW1#sh vlan

VLAN Name Status Ports
—- ——————————– ——— ——————————-
1 default active Fa1/0/2, Fa1/0/4, Fa1/0/5
Fa1/0/6, Fa1/0/7, Fa1/0/8
Fa1/0/9, Fa1/0/11, Fa1/0/12
Fa1/0/13, Fa1/0/14, Fa1/0/15
Fa1/0/16, Fa1/0/17, Fa1/0/18
Fa1/0/19, Fa1/0/20, Fa1/0/21
Fa1/0/22, Fa1/0/23, Fa1/0/24
Gi1/0/1, Gi1/0/2
12 VLAN0012 active Fa1/0/1

The port R1 is connected to is in VLAN 12 – So lets make sure that VLAN is allowed to talk to the remote switch:

SW1#sh int trunk

Port Mode Encapsulation Status Native vlan
Fa1/0/10 on 802.1q trunking 1

Port Vlans allowed on trunk
Fa1/0/10 1-11,13-4094

Port Vlans allowed and active in management domain
Fa1/0/10 1,34

Port Vlans in spanning tree forwarding state and not pruned
Fa1/0/10 1,34
SW1#

Ah ha! Dag nab we are good.

Now there are two valid ways come exam day to add the VLAN back in, and that is either “switchport trunk allowed vlan 12″ or switchport trunk allowed vlan all”, I’ll just add 12 back in there but technically both answers are right if the question arises:

SW1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
SW1(config)#int fa1/0/10
SW1(config-if)#switchport trunk allowed vlan 12
SW1(config-if)#
ASR#3
[Resuming connection 3 to r1 … ]

R1#u all
All possible debugging has been turned off
R1#ping 10.0.0.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
R1#

It’s late so I’ll end it here, one more VLAN post regarding Voice VLANs which are a very important topic, so until next time!