Invisible fences for VLANs

This week we have a guest post from CJ Infantino. He is currently writes on convergingontheedge.com. You can find him hanging out on Google Plus as CJ Infantino or follow him @cjinfantino on twitter.

————————————-

The other day I was adding VLANs to the the allowed list on the core routers at work. It was then a question came to mind, “Does the VLAN allowed list filter ingress or egress traffic?”.

Now, because all good engineers would configure the allowed list on both ends – as Aaron would say – in the grand scheme of things this really doesn’t matter, but being the inquisitive guy that I am, I wanted to know.

So I searched, and searched and google’d and could not find the answer. At that point there was only one thing left to do – lab it up!

The Setup:

 

|PC1| —— [SW1] — trunk — [SW2] —— |PC2|

 

The Test:

 

We will setup a trunk between SW1 and SW2. PC1 and PC2 will connect to SW1 and SW2 respectively. Each PC will connect into an access port configured for VLAN 10.

 

Output for SW1:

 

SW1#show run int f0/3

interface FastEthernet0/3
switchport access vlan 10
switchport mode access


Output for SW2:

 

S2#sho run int f0/7

interface FastEthernet0/7

switchport access vlan 10

switchport mode access

 

Next, we configure SW1’s trunk port with VLAN10 in the allowed list, and SW2’s trunk for ONLY VLAN20. So VLAN10 will not be allowed on the trunk.

 

Output for SW1:

 

SW1#sho run

interface FastEthernet0/1

switchport trunk encapsulation dot1q

switchport trunk allowed vlan 10

switchport mode trunk

 

Output for SW2:

 

SW2: sho run

interface FastEthernet0/1

switchport trunk encapsulation dot1q

switchport trunk allowed vlan 20

switchport mode trunk

end

 

And to verify the trunks are setup properly:

 

SW1#sho int f0/1 trunk

 

Port Mode Encapsulation Status Native vlan

Fa0/1 on 802.1q trunking 1

 

Port Vlans allowed on trunk

Fa0/1 10

 

Port Vlans allowed and active in management domain

Fa0/1 10

 

Port Vlans in spanning tree forwarding state and not pruned

Fa0/1 10

 

—-

 

SW2#sho int f0/1 trunk

 

Port Mode Encapsulation Status Native vlan

Fa0/1 on 802.1q trunking 1

 

Port Vlans allowed on trunk

Fa0/1 20

 

Port Vlans allowed and active in management domain

Fa0/1 20

 

Port Vlans in spanning tree forwarding state and not pruned

Fa0/1 20

 

Now, if we ping from PC1 to PC2, it will pass over the trunk port and if we see the icmp echo hit PC2’s interface we can safely say it only filters on egress. We know too, that the ping will ultimately fail even if SW2 allows the packet on ingress, it has to then filter on egress so the reply would never reach PC1.

 

Lets run a ping and test it out.

 

PC1% ping 192.168.1.2

PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data.

From 192.168.1.1 icmp_seq=22 Destination Host Unreachable

 

It failed and we also never saw the packet hit the interface on PC2. So this tells us that the command filters both ingress and egress frames. Just to verify we will add VLAN10 to the allowed list on SW2 and see if the ping goes through.

 

SW2#sho run

interface FastEthernet0/1

switchport trunk encapsulation dot1q

switchport trunk allowed vlan 10,20

switchport mode trunk

 

—-

 

SW2#sho int f0/1 trunk

 

Port Mode Encapsulation Status Native vlan

Fa0/1 on 802.1q trunking 1

 

Port Vlans allowed on trunk

Fa0/1 10, 20

 

Port Vlans allowed and active in management domain

Fa0/1 10, 20

 

Port Vlans in spanning tree forwarding state and not pruned

Fa0/1 10, 20

 

Next we will ping from PC1 to PC2, let’s take a look.

 

PC1% ping 192.168.1.2

PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data.

64 bytes from 192.168.1.2: icmp_req=1 ttl=64 time=9.66 ms

64 bytes from 192.168.1.2: icmp_req=2 ttl=64 time=0.414 ms

 

So, there you have it. PC1 can now ping PC2.

 

So next time you’re configuring your VLAN allowed list remember, it filters in both directions! And most importantly, I will sleep better now that that mystery has been solved.

 

Did you know this already? No? Am I the only one who was wondering this?

 

CJ

11 comments for “Invisible fences for VLANs

  1. Jc
    August 9, 2011 at 3:27 am

    I already had this issue during my internship at Cisco Bruxelles.
    They given me a switch which was connected to the backbone and I normally have have access to 3 vlans. I’ve configured my vlan allowed list and there was no traffic. I’ve contacted the guy who was responsable the 6K BB switch because he forgot to allows thoses vlans on the other end.

  2. August 9, 2011 at 6:34 am

    In the command references of the DocCD (very valuable) it is stated that it filters the traffic sent and received :

    “allowed vlan vlan-list

    Set the list of allowed VLANs that can receive and send traffic on this interface in tagged format when in trunking mode. See the following vlan-list format. The none keyword is not valid. The default is all.”

  3. August 9, 2011 at 9:03 am

    @youssef – that is awesome! I will check out the DocCD, thanks for the tip. I typically just do a search query on Google specifying Cisco.com and most of the time I get to the DocCD, but it didn’t hit.

    Next time I will go digging for it :).

  4. August 9, 2011 at 4:38 pm

    While I agree that pruning VLANs from a trunk filters traffic in both directions, I’m not sure that this test proved it 🙂

    Unless the arp cache on the PCs was pre-populated, it’s likely that PC1 never even sent an ICMP echo request in the first place.

    In fact, I think the ‘destination host unreachable’ from PC1 is analogous to ‘encapsulation failed’ on our beloved Cisco boxes, indicating that ARP cache population is what actually failed here. That task requires *bidirectional* traffic flow.

    Had the ARP cache been populated, I think we’d have seen something along the lines of “no reply from host”

  5. Matt
    August 30, 2011 at 2:55 pm

    Interesting point by chrismarget but I imagine that the trace on PC2 was not filtered just for ICMP. Can this be confirmed?

    Good article – I like a good breakdown of things that we take for granted.

  6. August 30, 2011 at 3:04 pm

    On PC2, I was watching the traffic with wireshark. Nothing ever touched the box until the VLAN was allowed on the trunk. There was no ARP request, no broadcast traffic, nothing!

  7. chandra
    September 21, 2011 at 1:26 pm

    Good one.. I came across it when i needed it. At work one of my Controller is connected to trunk port(fa0/5) of the switch.
    #switch port mode trunk
    natie vlan 66
    Allowed vlan 113-115,56,xx.

    This switch and controller were on 1st floor and i was in ground floor, with my PC on 56 subnet.when i pinged controller (which got an dhcp ip x.x.66.16 , it failed/was not able to ssh to it.But when i add vlan 66 to allowed list it worked like a charm.

    i understand, switch was not allowing any packet to go out to vlan 66. correct?

  8. September 21, 2011 at 1:55 pm

    If the you are saying the controller was in VLAN66 coming off the switch, then yes, before you added VLAN66 to the trunk link, no traffic was able to pass on VLAN66.

  9. Barry Wells
    September 6, 2012 at 6:58 am

    Many Thanks for the Article saved me an hours lab work 🙂 I too use the same approach as the Author with a well shaped Google query 🙂

  10. September 24, 2012 at 9:05 pm

    Hey Barry,

    I’m glad this helped you out!

  11. Glen McLaughlin
    December 21, 2012 at 3:55 pm

    All of this is good information. I just have one thing to point out. What happens if you are not a good engineer. Yes, the traffic would be dropped. However, think about where it is being dropped and what resources you are using. If you only configure it on one side then the side not configured would still send the traffic across the trunk and the other switch would have to use resources to drop the traffic. Nevermind the extra bandwidth you are wasting on the link between the switches.

Leave a Reply

Your email address will not be published. Required fields are marked *