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
- Invisible fences for VLANs - August 8, 2011
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.
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.”
@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 :).
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”
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.
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!
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?
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.
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 🙂
Hey Barry,
I’m glad this helped you out!
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.