Tag Archives: SWITCH

Private Vlans – Control Plane/Data Plane

Private vlans are actually very easy to configure. But what’s actually happening at the data plane level? Knowing this helps when we need to span our pvlans through switches that do not support private vlans.

 

Let’s use the following topology for these tests. The routers are just acting as hosts. I also have a laptop connected to port fa0/48 on SW3 to capture some frames. All routers are in the 10.0.0.x/24 range.

data pvlan 1 Private Vlans   Control Plane/Data Plane

 

SW1 is a 3750 and SW2 is a 3560. Both support pvlans. SW3 is a 3550 which has no concept of private vlans.

The first thing I’m going to do is create the primary private vlan with an id of 50. I’ll then create a secondary community vlan with a vlaue of 24.  I’ll then put R2′s and R4′s port into the pvlan.

R1:

vlan 24
  private-vlan community
!
vlan 50
  private-vlan primary
  private-vlan association 24
!
interface FastEthernet1/0/4
 switchport private-vlan host-association 50 24
 switchport mode private-vlan host

At this point if I ping R4 from R2 the ping fails:

R2#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 0 percent (0/5)

If two community ports are trying to speak to each other, SW1 and SW2 will use the community vlan value id for traffic in both ways. The community vlan is 24, so let’s try creating a regular vlan 24 on SW3:

SW3(config)#vlan 24
SW3(config-vlan)#end

Can we ping now?

R2#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 100 percent (5/5), round-trip min/avg/max = 1/6/20 ms

It doesn’t matter that SW3 doesn’t support pvlans at this point. SW1 and SW2 simply use a generic vlan tag of 24. This can be shown in the wireshark capture for both the ping request and response:
pvlan 1 Private Vlans   Control Plane/Data Plane

pvlan 2 Private Vlans   Control Plane/Data Plane
SW3 doesn’t know this is a private-vlan. It simply sees traffic for vlan 24 passing through it’s trunk ports. Does this mean that we can put R3′s port into vlan 24 and it’ll be able to ping both R2 and R4? Well it should, but let’s find out.
SW3:

interface FastEthernet0/1
 switchport access vlan 24
 switchport mode access

R2:

R2#ping 10.0.0.3

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

No problems there. Wireshark shows the same regular vlan 24 being used between the switches.

Now let’s add a promiscuous port. I’ll make port fa1/0/1 on SW1 a promiscuous port which will represent the gateway on this subnet.
SW1:

interface FastEthernet1/0/1
 switchport private-vlan mapping 50 24
 switchport mode private-vlan promiscuous

Can R4 and R2 ping R1?

R4#ping 10.0.0.1

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

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

R4 can ping, R2 can’t. Why it can’t will become clear very shortly. Let’s add vlan 50 on SW3 and try again on R2.

SW3#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
SW3(config)#vlan 50
SW3(config-vlan)#end
R2#ping 10.0.0.1

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

Now R2 can ping. To figure out why, let’s have a look at what wireshark is telling us.
pvlan 3 Private Vlans   Control Plane/Data Plane

pvlan 4 Private Vlans   Control Plane/Data Plane
It’s quite clear from the captures above. When traffic needs to get from a community port to an promiscuous port, SW1 and SW2 will use vlan 24 unidirectionally to get to the promiscuous port. Traffic going from the promiscuous port back to the community ports will use the primary vlan, which is id 50. (Isolated ports are the same in this regard)
As soon as vlan 50 is allowed through SW3, R2 can speak to the segment gateway. Once again SW3 has no idea that vlan 50 is any sort of private vlan.

However, this does cause a problem if R3 tries to get to the default gateway. R3 belongs to vlan 24 only, and so will never receive any reply from R1:

R3#ping 10.0.0.1

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

R3 is sending out an ARP request which R1 does  receive. This can be proved with a debug arp on R1:

R1#debug arp
ARP packet debugging is on
R1#
*Dec  9 13:04:55.339: IP ARP: rcvd req src 10.0.0.3 ca02.0b28.0008, dst 10.0.0.1 FastEthernet0/0
*Dec  9 13:04:55.339: IP ARP: sent rep src 10.0.0.1 ca00.0b28.0008,
                 dst 10.0.0.3 ca02.0b28.0008 FastEthernet0/0

The problem is that the reply is getting sent over vlan 50, of which R3 is not a part of. What happens if we make R3 part of vlan 50 on SW3?

SW3(config)#int fa0/1
SW3(config-if)#swit acc vlan 50
SW3(config-if)#end
R3#ping 10.0.0.1

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

That worked. Surely SW1 would assume that incoming traffic on vlan 50 can’t be correct as traffic from the associated ports should come in on the secondary vlan? Well there is a reason this works which I’ll cover in a bit. Wireshark proves that both the request and replys were send using vlan 50. Of course R3 no longer has access to R2 or R4:

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#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 0 percent (0/5)

What if we wanted to create an SVI on all 3 of our switches so that each had a layer3 interface in the vlan? Let’s try to create int vlan 24 on SW1:

SW1(config)#int vlan 24
SW1(config-if)#
*Mar  1 02:16:48.839: %PV-6-PV_SVI_DOWN: Vlan 24's interface remains down because this vlan is a secondary vlan.
*Mar  1 02:16:48.848: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan24, changed state to down

This doesn’t work. SVI’s will only work when you use the primary vlan id:

interface Vlan50
 ip address 10.0.0.11 255.255.255.0

This SVI is not part of the community though. This means it should be able to ping R1, R3, but not R2 or R4:

SW1#ping 10.0.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/208/1015 ms
SW1#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)
SW1#ping 10.0.0.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/206/1007 ms
SW1#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 0 percent (0/5)

Which is what we see. In fact if I ping from SW2 to R1, the vlans in both directions should be vlan 50. Are they?
pvlan 5 Private Vlans   Control Plane/Data Planepvlan 6 Private Vlans   Control Plane/Data Plane
Yes they are. This is why the ping from R3 worked earlier. When the frame entered SW1′s trunk interface encapsulated with vlan 50, it has no idea this isn’t coming from a pvlan switch. It simply sees a source of vlan 50, which is valid. Yes community and isolated ports will be coming inbound with their respective secondary vlans, but a frame coming in tagged with the primary vlan is still a valid frame.

What happens if I don’t want to use R1 as the gateway. Rather I would like to use SW2′s SVI interface. At the moment none of the community ports can actually ping the SVIs as they are not promiscuous. We can’t specifically make them promiscuous, but we can map vlans to an SVI interface:
SW2:

interface Vlan50
 ip address 10.0.0.12 255.255.255.0
 private-vlan mapping 24
R2#ping 10.0.0.12

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

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

For now, this means that SW3′s SVI should be able to ping SW1, SW2, R1, but neither R2 nor R4:

SW3#ping 10.0.0.11

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

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

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/202/1000 ms
SW3#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)
SW3#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 0 percent (0/5)

There are a couple of interesting things to note. If I remove the associations in my vlan config, then any interface using pvlans associated with the wrongly configured pvlan will go down:

SW1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
SW1(config)#vlan 50
SW1(config-vlan)#no private-vlan association 24
SW1(config-vlan)#end
SW1#
*Mar  1 03:07:08.604: %PV-6-PV_MSG: Purged a private vlan mapping, Primary 50, Secondary 24
*Mar  1 03:07:08.621: %SYS-5-CONFIG_I: Configured from console by console
*Mar  1 03:07:09.619: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/1, changed state to down
*Mar  1 03:07:09.619: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/4, changed state to down

This can be a bit tricky to troubleshoot, as there is no reason given for the port being down:

SW1#sh int fa1/0/1
FastEthernet1/0/1 is up, line protocol is down (notconnect)

The only way to figure that out (at least I can find) is to have a look at the vlans configured, or check the switchport command:

SW1#sh int fa1/0/1 switchport | include Administrative|Operational
Administrative Mode: private-vlan promiscuous
Operational Mode: down
Administrative Trunking Encapsulation: negotiate
Administrative Native VLAN tagging: enabled
Administrative private-vlan host-association: none
Administrative private-vlan mapping: 50 (VLAN0050) 24 (VLAN0024)
Administrative private-vlan trunk native VLAN: none
Administrative private-vlan trunk Native VLAN tagging: enabled
Administrative private-vlan trunk encapsulation: dot1q
Administrative private-vlan trunk normal VLANs: none
Administrative private-vlan trunk associations: none
Administrative private-vlan trunk mappings: none
Operational private-vlan: none

The administrative mode shows private-vlan, but the operational mode shows none. Not that easy to find.

Conclusions

  • It’s not essential to have a switch that suports pvlan as a transport switch between 2 pvlan switches
  • While you could add a host to the transport switch, it’s either going to be able to speak to the hosts, or the gateway. Not both at the same time
  • Just keep hosts or the routing SVI off the transport switch. Keep these limited to the pvlan switches
  • In the data-plane, the only distinguishing feature of the packet is the dot1q header. This is why you can use non pvlan switches in the middle. Your transport switches are simply forwarding based on the MAC address in the vlans configured over the trunk links
  • SVIs can only be created in the primary vlan id. A Secondary SVI id will not come up
  • SVIs are not promiscuous by default. You need to map secondary vlans to an SVI port
  • If you need to monitor pvlan traffic on a non-pvlan switch, you’ll need to monitor both the primary and secondary vlan id.

802.1s – Multiple Spanning Tree – Regions

I’m not going into the basics of 802.1s as there is plenty of documentation showing that. The main point of this blog is to see how the actual regions work.

For this blog I’ll be using the following topology:
MST regions 2 802.1s   Multiple Spanning Tree   Regions

I’ve created vlan 10, 20, 30, 40, 50, 60, 70, 80, 90, and 100 on all devices. VTP is OFF. I have created int vlan 10 and int vlan 30 on each switch, with addressing like so: 10.10.10.x and 30.30.30.x (x being the switch number) This will allow us to test connectivity.

I’ve got the following config on all these switches:

spanning-tree mode mst
!
spanning-tree mst configuration
 name mellowd
 revision 1
 instance 1 vlan 10, 30, 70
 instance 2 vlan 20, 40, 50

Any vlan not associated with an instance is automatically associated with instance 0. We can check this:

SW1#show span mst con
Name      [mellowd]
Revision  1     Instances configured 3

Instance  Vlans mapped
--------  ---------------------------------------------------------------------
0         1-9,11-19,21-29,31-39,41-49,51-69,71-4094
1         10,30,70
2         20,40,50
-------------------------------------------------------------------------------

MST considers switches to be in the same region, as long as their vlan to instance mapping, name, and revision match. If any one of these are different, they are in different regions. As they all currently match, let’s have a look at the spanning tree:

SW2#sh span mst 0

##### MST0    vlans mapped:   1-9,11-19,21-29,31-39,41-49,51-69,71-4094
Bridge        address 001c.f903.d580  priority      32768 (32768 sysid 0)
Root          address 0012.daf2.c300  priority      32768 (32768 sysid 0)
              port    Fa0/23          path cost     0
Regional Root address 0012.daf2.c300  priority      32768 (32768 sysid 0)
                                      internal cost 200000    rem hops 19
Operational   hello time 2 , forward delay 15, max age 20, txholdcount 6
Configured    hello time 2 , forward delay 15, max age 20, max hops    20

Interface        Role Sts Cost      Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa0/20           Altn BLK 200000    128.22   P2p
Fa0/23           Root FWD 200000    128.25   P2p

SW2 is showing SW1 as the root of MST 0. It also shows up as the regional root. I’ll expand on that a bit more later. The ports are both point-to-point. We can expand on the actual spanning-tree interface to see that:

SW2#sh span mst interface  fa0/23

FastEthernet0/23 of MST0 is root forwarding
Edge port: no             (default)        port guard : none        (default)
Link type: point-to-point (auto)           bpdu filter: disable     (default)
Boundary : internal                        bpdu guard : disable     (default)
Bpdus sent 9, received 399

Instance Role Sts Cost      Prio.Nbr Vlans mapped
-------- ---- --- --------- -------- -------------------------------
0        Root FWD 200000    128.25   1-9,11-19,21-29,31-39,41-49,51-69
                                     71-4094
1        Root FWD 200000    128.25   10,30,70
2        Root FWD 200000    128.25   20,40,50

You’ll notice the Boundry shows as internal.

Let’s take a look at the tree from SW4′s perspective for vlan 10:

SW4#sh span vlan 10

MST1
  Spanning tree enabled protocol mstp
  Root ID    Priority    32769
             Address     0012.daf2.c300
             Cost        200000
             Port        21 (FastEthernet0/21)
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    32769  (priority 32768 sys-id-ext 1)
             Address     0017.0e23.d380
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Fa0/20              Desg FWD 200000    128.20   P2p
Fa0/21              Root FWD 200000    128.21   P2p
Fa0/22              Altn BLK 200000    128.22   P2p
Fa0/24              Desg FWD 200000    128.24   P2p

Vlan 10 and vlan 30 are part of the same MST instance. They share the same tree. If you manually prune certain vlans off certain links, this can spell disaster in an MST set up. Let’s check if SW4 has connectivity to SW1′s vlan 10 and vlan 30 interfaces:

SW4#ping 10.10.10.1

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

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

fa0/21 is currently the root port. If I prune vlan 30 off that link, it will NOT use the alternative port. In PVST+ it will, since the spanning-tree for vlan 30 will recalculate

interface FastEthernet0/21
 switchport trunk allowed vlan 1-29,31-4094

SW4#ping 30.30.30.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 30.30.30.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
SW4#ping 10.10.10.1

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

vlan 30 traffic is now getting black-holed, while vlan 10 still works. I’ll remove the prune to move onto the next.

Now let’s say we add another vlan mapping to SW2. We create vlan 110 and map it to instance 2. What happens?

SW2#sh span mst configuration
Name      [mellowd]
Revision  1     Instances configured 3

Instance  Vlans mapped
--------  ---------------------------------------------------------------------
0         1-9,11-19,21-29,31-39,41-49,51-69,71-109,111-4094
1         10,30,70
2         20,40,50,110
-------------------------------------------------------------------------------

If I now check the MST0:

SW2#sh span mst 0

##### MST0    vlans mapped:   1-9,11-19,21-29,31-39,41-49,51-69,71-109
                               111-4094
Bridge        address 001c.f903.d580  priority      32768 (32768 sysid 0)
Root          address 0012.daf2.c300  priority      32768 (32768 sysid 0)
              port    Fa0/23          path cost     200000
Regional Root this switch
Operational   hello time 2 , forward delay 15, max age 20, txholdcount 6
Configured    hello time 2 , forward delay 15, max age 20, max hops    20

Interface        Role Sts Cost      Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa0/20           Altn BLK 200000    128.22   P2p Bound(RSTP)
Fa0/23           Root FWD 200000    128.25   P2p Bound(RSTP)

The ports have changed from P2p to PtP Bound(RSTP). Let’s take a look at the actual root port again:

SW2#sh span mst interface  fa0/23

FastEthernet0/23 of MST0 is root forwarding
Edge port: no             (default)        port guard : none        (default)
Link type: point-to-point (auto)           bpdu filter: disable     (default)
Boundary : boundary       (RSTP)           bpdu guard : disable     (default)
Bpdus sent 5, received 61

Instance Role Sts Cost      Prio.Nbr Vlans mapped
-------- ---- --- --------- -------- -------------------------------
0        Root FWD 200000    128.25   1-9,11-19,21-29,31-39,41-49,51-69
                                     71-109,111-4094
1        Mstr FWD 200000    128.25   10,30,70
2        Mstr FWD 200000    128.25   20,40,50,110

The boundry now shows up as boundry. These switches now consider themselves to be in different regions. All that has changed is we have added another vlan to instance 2. The name and revision is still the same, but remember all 3 have to match. As this is a boundry, they actually run rapid spanning tree between them.

A single region will present itself as a single bridge with multiple links to another switch. This means you could have 100 switches in an MST region connected with multiple links to a single 802.1d-2004 switch. That 802.1d-2004 will assume that all these links go to a single bridge.

If you connect multiple MST regions together, each region will have their own regional root, but they will see the best regional root as the actual root. You can check this on SW2:

SW2#sh span mst 0 detail

##### MST0    vlans mapped:   1-9,11-19,21-29,31-39,41-49,51-69,71-109
                               111-4094
Bridge        address 001c.f903.d580  priority      32768 (32768 sysid 0)
Root          address 0012.daf2.c300  priority      32768 (32768 sysid 0)
              port    Fa0/23          path cost     200000
Regional Root this switch

SW2 sees SW1 as the root bridge, but sees itself as the root of it’s own region. In order for multiple-region MST to work, the overall root bridge has to be in an MST region. If we make SW3 a non-MST bridge, and lower it’s priority to 0, it won’t work:

Sw3
spanning-tree mode rapid-pvst
!
spanning-tree vlan 1-4094 priority 0

I immediately get this error on SW4:

%SPANTREE-2-PVSTSIM_FAIL: Blocking root port Fa0/24: Inconsitent inferior PVST BPDU received on VLAN 10, claiming root 10:0017.0e23.a800

If you check the spanning-tree now:

SW4#sh span mst 0 | include Fa0/24
              port    Fa0/24          path cost     200000
Fa0/24           Root BKN*200000    128.24   P2p Bound(PVST) *PVST_Inc

SW4 has blocked this port. This means no traffic can get to SW3:

SW4#ping 10.10.10.3

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

If I remove the priority on SW3, all goes back to normal:

%SPANTREE-2-PVSTSIM_OK: PVST Simulation inconsistency cleared on port FastEthernet0/24.

SW4#sh span mst 0 | include Fa0/24
Fa0/24           Desg FWD 200000    128.24   P2p Bound(PVST) *PVST_Inc
SW4#ping 10.10.10.3

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

Conclusions:

  • Vlan to instance mappings, revision, and instance name need to match in order for switches to be in the same region
  • Vlans do not actually need to be created, or even allowed over trunks in order to be mapped to an instance. The essential part of the vlan id to instance mapping
  • If any one of the above doesn’t match, switches are in different regions and will run RSTP between them
  • Manually pruning vlans can lead to black-holing of traffic
  • If running multiple regions with legacy switches, always ensure one of the MST switches is actually the root (just use priority 0)

Protocol fundamentals – dot1q

I’ve noticed that a lot of people seem to get confused with what exactly dot1q is doing most of the time. It’s actually incredibly simply.

Tagging traffic, or Trunking in Cisco-talk, is a very straightforward process. I will not be discussing ISL here as not only do I not use it, but Cisco is phasing it out on their stuff anyway.

The dot1q tag is simply inserted into the layer2 header when a packet leaves a switchport over a trunk. If a frame leaves a switchport that is not a trunk, there is no dot1a tag inserted into it, regardless of what vlan the frame came from or is going to. This means that the following is a perfectly valid topology:
dot1qex1 Protocol fundamentals   dot1q
Let’s configure the above quickly.

3560TOP#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
3560TOP(config)#int range fa0/1, fa0/8
3560TOP(config-if-range)#switchport mode access
3560TOP(config-if-range)#switchport access vlan 10
% Access VLAN does not exist. Creating vlan 10
C3550#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
C3550(config)#int range fa0/1, fa0/8
C3550(config-if-range)#switchport mode access
C3550(config-if-range)#switchport access vlan 20
% Access VLAN does not exist. Creating vlan 20

Can the PC’s ping each other?

PC2#ping 10.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/10/28 ms
PC1#ping 10.1.1.2

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

They both can ping each other. But aren’t the devices in different vlans? They sure are, yet they can still communicate. Why is this?

The issue is that the switch interlink are both access ports. An access port will not send or accept tagged traffic. Hence when SW1 sends PC1′s traffic over the link, the tag is removed. When that packet comes into SW2′s fa0/8 interface, that interface is part of vlan 20. SW2 will allow that frame to flow to PC2. The same happens vice-versa.

Let’s change the topology so that there is a trunk instead between the 2 switches. I also want to force the use of dot1q.

C3550#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
C3550(config)#default interface fa0/8
Interface FastEthernet0/8 set to default configuration
3560TOP#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
3560TOP(config)#default interface fa0/8
Interface FastEthernet0/8 set to default configuration
3560TOP(config-if)#switchport trunk encapsulation dot1q

Now can the PC’s ping each other?

PC2#ping 10.1.1.1

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

They cannot. It now works as expected SW1 now sends PC1′s frame over the link with a dot1q tag. In that tag is the vlan id of 10. When it gets to SW2, it’ll look at that tag and ensure the frame is not sent out any access port that is not in vlan 10.

Another important part of dot1q is the notion of a native vlan. The native vlan does not get tagged over a trunk unless you configure otherwise. Vlan1 is the default native vlan.

So let’s try something here. Let’s configure SW1 to think that vlan 10 is the native vlan, while on SW2 let’s change it to vlan20. Will my PC’s be able to ping each other?

3560TOP(config)#int fa0/8
3560TOP(config-if)#switchport trunk native vlan 10
*Mar  1 00:13:42.385: %SPANTREE-2-RECV_PVID_ERR: Received BPDU with inconsistent peer vlan id 1 on FastEthernet0/8 VLAN10.
*Mar  1 00:13:42.385: %SPANTREE-2-BLOCK_PVID_PEER: Blocking FastEthernet0/8 on VLAN0001. Inconsistent peer vlan.
*Mar  1 00:13:42.385: %SPANTREE-2-BLOCK_PVID_LOCAL: Blocking FastEthernet0/8 on VLAN0010. Inconsistent local vlan.
*Mar  1 00:14:13.389: %SPANTREE-2-UNBLOCK_CONSIST_PORT: Unblocking FastEthernet0/8 on VLAN0001. Port consistency restored.
*Mar  1 00:14:19.270: %CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on FastEthernet0/8 (10), with C3550 FastEthernet0/8 (20).

I’ve done the same on SW2, but for vlan 20. You can see that the switch is giving me all kinds of error messages.

However I cannot ping between my PCs:

PC2#ping 10.1.1.1

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

I tried disabling CDP, hard coding the trunk between the 2 switches and also disabling negotiation between the 2 links but no communication at all. Even though it should work theoretically, the switches just do not like the native vlan not matching on either side of the link

I was not happy with the outcome above, so I dug a little deeper. It seems STP is blocking communication. The BPDU’s still carry vlan information with them. What I’ve done on both switches is disable STP on vlans 10 and 20 on both switches:

3560TOP(config)#no spanning-tree vlan 10,20

Can I now ping?

PC2#ping 10.1.1.1

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

Indeed I can. So even though there is a trunk between the 2 switches and both devices are in separate vlans, they can still communicate as SW1 and SW2 both think that the native vlan matches on each side. They have no idea that PC1 is in vlan 10 and PC2 is in vlan 20.

I don’t much like leaving the native vlan untagged. Thankfully we have an option to tag all frames:

3560TOP(config)#vlan dot1q tag native
C3550(config)#vlan dot1q tag native

What this does is essentially ignore the native vlan setting. All traffic, regardless of vlan, will be tagged over the link. This is proven by the fact I can now no longer ping again:

PC2#ping 10.1.1.1

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

It’s important to note that an untagged frame is identical to a frame that goes in and out of an access port. There is no difference. To prove this I’m going to put both PC1 and PC2 into vlan 10, and them create a trunk link to PC1. PC1 does not understand trunk links and will continue to send regular traffic. I’ll configure SW1 to untag the native vlan again and make vlan 10 the native vlan. Will this work?

3560TOP(config)#int fa0/8
3560TOP(config-if)#no switchport trunk native vlan 10
3560TOP(config-if)#exit
3560TOP(config)#no vlan dot1q tag native
3560TOP(config)#int fa0/1
3560TOP(config-if)#switchport trunk encap dot
3560TOP(config-if)#switch mode trunk
3560TOP(config-if)#switchport trunk native vlan 10

Can PC1 ping PC2?

PC1#ping 10.1.1.2

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

It sure can. PC1 is simply sending untagged traffic off to SW1. SW1 assumes that untagged traffic is part of vlan10 and forwards those frames throughout vlan 10. This goes over the trunk to SW2, and sends those frames over the vlan10 access ports where it gets to PC2.

Of course routers and some servers can also send tagged traffic. Let’s change PC1 so that it sends out tagged traffic. Let’s change SW1 back to the regular native vlan on port fa0/1

3560TOP(config)#int fa0/1
3560TOP(config-if)#no switchport trunk native vlan 10
PC1(config)#int fa0/0
PC1(config-if)#no ip address
PC1(config-if)#int fa0/0.1
PC1(config-subif)#encapsulation dot1Q 10
PC1(config-subif)#ip address 10.1.1.1 255.255.255.0

Can I ping?

PC1#ping 10.1.1.2

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

As expected I sure can.

Just like the switches, I can also make any single vlan I choose to be the native vlan. This frame will simply be sent untagged. Let’s change SW1′s fa0/1 interface to an access port again, and change PC1 to continue to use dot1q, but ensure that vlan 10 traffic is untagged:

3560TOP(config)#default interface fa0/1
Interface FastEthernet0/1 set to default configuration
3560TOP(config)#int fa0/1
3560TOP(config-if)#switch mode access
3560TOP(config-if)#switch access vlan 10
PC1(config)#int fa0/0.1
PC1(config-subif)#encapsulation dot1Q 10 native

Ping should still work, does it?

PC1#ping 10.1.1.2

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

As you can see, it’s pretty simple stuff at the end of the day.

Checking optical interface type

Sometimes you log onto a switch remotely and need to know what kind of optical interface the switches actually have plugged in. It’s pretty simple:

Switch#show interface gi1/0/25 capabilities
GigabitEthernet1/0/25
Model:                 WS-C3750G-24TS
Type:                  1000BaseLX SFP
Speed:                 1000
Duplex:                full
Trunk encap. type:     802.1Q,ISL
Trunk mode:            on,off,desirable,nonegotiate
Channel:               yes
Broadcast suppression: percentage(0-100)
Flowcontrol:           rx-(off,on,desired),tx-(none)
Fast Start:            yes
QoS scheduling:        rx-(not configurable on per port basis),
tx-(4q3t) (3t: Two configurable values and one fixed.)
CoS rewrite:           yes
ToS rewrite:           yes
UDLD:                  yes
Inline power:          no
SPAN:                  source/destination
PortSecure:            yes
Dot1x:                 yes

The most important things here is that you can see I have a 1000BaseLX SFP installed.

CiscoPress CCNP Cert Kit Giveaway

Steve over at networking-forum.com is giving away 4 new CCNP Training kits. These are the kits for the new CCNP track.

CCNP Cert Kits
CCNP ROUTE 642-902 Cert Kit: Video, Flash Card, and Quick Reference Preparation Package
CCNP SWITCH 642-813 Cert Kit: Video, Flash Card, and Quick Reference Preparation Package
CCNP TSHOOT 642-832 Cert Kit: Video, Flash Card, and Quick Reference Preparation Package *

* – Available in Spring of 2010

The old exams, BSCI (Building Scalable Cisco Internetworks), BCMSN (Building Cisco Multilayer Switched Networks), ISCW (Implementing Secure Converged WANs), and ONT (Optimizing Converged Cisco Networks), will be available through July 31, 2010. The new exams, ROUTE (Implementing Cisco IP Routing), SWITCH (Implementing Cisco Switched Networks), and TSHOOT (Troubleshooting and Maintaining Cisco IP Networks) will be available in March and April of 2010.

Cisco Press, the official publisher of Cisco, has announced their new portfolio of exam preparation materials which includes a new type of product for them called Cert Kits. The kits are considered quick reference material to be used in conjunction with the official books to prepare for the exams. Included in each kit is video, online flash cards for your mobile device or desktop, and a quick reference guide for last minute studying.

For a chance to win this prize, have a look here: http://www.networking-forum.com/viewtopic.php?f=29&t=15461&start=0