Accepted Solutions
Hi Ambivert,
Please find below documents on configuring VACL:
http://www.ciscopress.com/articles/article.asp?p=29649&seqNum=4
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.
But what if we want to filter traffic that is flowing within 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:
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.
R1#telnet 10.10.10.2 Trying 10.10.10.2 ... Open User Access Verification Password: R2>quit [Connection to 10.10.10.2 closed by foreign host] R1#
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 permit Access Control List Entry (ACE) to specify the traffic, but I will end up denying it later on in the VACL structure.
SW2(config)#ip access-list extended ACL_TELNETR1_R2 SW2(config-ext-nacl)#permit tcp host 10.10.10.1 host 10.10.10.2 eq 23
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:
SW2(config-ext-nacl)#vlan access-map VACL_STOPTELNET SW2(config-access-map)#action drop SW2(config-access-map)#match ip address ACL_TELNETR1_R2 SW2(config-access-map)#vlan access-map VACL_STOPTELNET SW2(config-access-map)#action forward SW2(config-access-map)#exit
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 action forwardcommands, 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:
SW2(config)#vlan filter VACL_STOPTELNET vlan-list 10
Now it is time for verification. In our case it should be very simple to test. R1 should be able to ping R1, but Telnet should fail. First the ping:
R1#ping 10.10.10.2 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. And next the telnet should be failing.
R1#telnet 10.10.10.2 Trying 10.10.10.2 ... % Connection timed out; remote host not responding
HTH
REgards
Inayath
Hi Ambivert,
Please find below documents on configuring VACL:
http://www.ciscopress.com/articles/article.asp?p=29649&seqNum=4
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.
But what if we want to filter traffic that is flowing within 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:
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.
R1#telnet 10.10.10.2 Trying 10.10.10.2 ... Open User Access Verification Password: R2>quit [Connection to 10.10.10.2 closed by foreign host] R1#
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 permit Access Control List Entry (ACE) to specify the traffic, but I will end up denying it later on in the VACL structure.
SW2(config)#ip access-list extended ACL_TELNETR1_R2 SW2(config-ext-nacl)#permit tcp host 10.10.10.1 host 10.10.10.2 eq 23
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:
SW2(config-ext-nacl)#vlan access-map VACL_STOPTELNET SW2(config-access-map)#action drop SW2(config-access-map)#match ip address ACL_TELNETR1_R2 SW2(config-access-map)#vlan access-map VACL_STOPTELNET SW2(config-access-map)#action forward SW2(config-access-map)#exit
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 action forwardcommands, 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:
SW2(config)#vlan filter VACL_STOPTELNET vlan-list 10
Now it is time for verification. In our case it should be very simple to test. R1 should be able to ping R1, but Telnet should fail. First the ping:
R1#ping 10.10.10.2 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. And next the telnet should be failing.
R1#telnet 10.10.10.2 Trying 10.10.10.2 ... % Connection timed out; remote host not responding
HTH
REgards
Inayath
