VLAN Access Control Lists (VACLs)
[LEFT]In this blog post, we will obtain some good solid Tier 1 level knowledge regarding VLAN Access Control Lists or VACLs. These are often also referred to as VLAN Access Maps or just VLAN Maps; thanks to the syntax that is used in their creation.
When you want to filter traffic that is moving from one VLAN to another, things are real CCNA-like and friendly [IMG]http://blog.ine.com/wp-includes/images/smilies/icon_smile.gif[/IMG] We use an Access Control List. In fact, we should elaborate on that term a bit now in light of this discussion. We actually use a Router-based Access Control List or RACL.
But what if we want to filter traffic that is flowing [I]within[/I] a VLAN? On no, a Router-based Access Control List cannot help us! This is when we turn to the VLAN Access Control List. To help us understand this feature, let us create a topology and a sample scenario. Here is the simple topology:
[/LEFT]
[CENTER][URL="http://blog.ine.com/wp-content/uploads/2009/08/VACLs.png"][IMG]http://blog.ine.com/wp-content/uploads/2009/08/VACLs.png[/IMG][/URL][/CENTER]
[LEFT]
Notice the Fast Ethernet interfaces of R1 and R2 are within the same VLAN (VLAN 10). So, based on the theory we have discussed, we will need a VACL if we want to filter the ability of R1 to communicate with R2. For this experiment, let us use Telnet. Before we begin, let me try Telnetting from R1 to R2. We want to ensure that works before we try and prevent that capability with a VACL.
[B]R1#[B]telnet 10.10.10.2[/B]
Trying 10.10.10.2 ... Open
User Access Verification
Password:
[/B]
[B][B]R2>quit[/B][/B]
[Connection to 10.10.10.2 closed by foreign host]
[B]R1#[/B]
Excellent, there is everything we need in place to test a VACL now. Let us be very specific and create a VACL that denies the ability of R1 to Telnet to R2. Notice, we want to be very specific. Can R1 ping R2 when we are done? Sure! That is, if we configure all of this correctly.
I begin the scenario configuration with an Access Control List that will define the exact traffic we are interested in preventing. Notice I am using a [I]permit[/I] Access Control List Entry (ACE) to specify the traffic, but I will end up denying it later on in the VACL structure.
[B]SW2(config)#[B]ip access-list extended ACL_TELNETR1_R2[/B]
SW2(config-ext-nacl)#[B]permit tcp host 10.10.10.1 host 10.10.10.2 eq 23[/B][/B]
Now that we have configured the identifying access list, it is time to configure the VACL. The first step is to create the VLAN Access Map, and then the second step is to apply it to the appropriate VLAN(s). Notice how these structures are eerily similar to Route Maps. Here is step one:
[B]SW2(config-ext-nacl)#[B]vlan access-map VACL_STOPTELNET[/B]
SW2(config-access-map)#[B]action drop[/B]
SW2(config-access-map)#[B]match ip address ACL_TELNETR1_R2[/B]
SW2(config-access-map)#[B]vlan access-map VACL_STOPTELNET[/B]
SW2(config-access-map)#[B]action forward
[/B]SW2(config-access-map)#[B]exit[/B][/B]
Notice that the ACL that matches on the Telnet has an action of DROP, then we match on all other traffic (implicitly), and we forward all of that. Forward is the default action, so I actually did not need the [B]action forward [/B]commands, but I added them above to make it more clear for us to learn.
Now for the really easy part of this configuration. In step two, all I need to do is apply this “map” to the appropriate VLAN. That is our VLAN 10:
[B]SW2(config)#[B]vlan filter VACL_STOPTELNET vlan-list 10[/B][/B]
Now it is time for verification. In our case itshould be very simple to test. R1 should be able to ping R1, but Telnet should fail. First the ping:
[B]R1#[B]ping 10.10.10.2[/B]
[/B]
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.2, timeout is 2 seconds:
!!!!!
That worked as expected. Now, drumroll please, it is time for the Telnet attempt. This is a time in the lab exam where you really hope for a failure:
[B]R1#[B]telnet 10.10.10.2[/B]
Trying 10.10.10.2 ...
[/B][B][B]% Connection timed out; remote host not responding[/B]
[/B]
[/LEFT]
