Options
VACLs / VLAN Access Maps
Again, this is another teach-myself-by-teaching-others moment.
So long story short, regular access lists are used to create IP ranges using IP and wildcard masks. ACLs can be a single line, or can be multiple lines. "permit" is used, though the term itself is merely a holdover, it has nothing to actually do with the rules other than telling the access-map what it is permitted to match against.
Access maps are created with sequence numbers, similar to ACLs. They are processed top-down. Sequence 5 is processed before sequence 6. The match command within a sequence number tells the map what to match against, in this example addresses from an IP access list, list number 110 and 120. At the end of the access-map is an implicit-drop, so if we want to forward everything not explicitly matched against we have to include an explicit forward, without requiring an ACL.
Finally, we use vlan filter to apply the access-map to VLANs.
Comments
-
Options
TWX
Member Posts: 275 ■■■□□□□□□□
Step by step, with a PC on 172.16.0.5 to demonstrate the effects:Initial state of the client:
Create access-lists and access-maps:
At this point nothing has been applied to the VLAN itself, the PC can still ping:
apply the access-map with vlan filter to the VLAN:
Now no pings are successful:
At this point, the VACL is working. -
OptionsTWX
Member Posts: 275 ■■■□□□□□□□
Some experimentation on amending the VACL:Remove access-map sequence 6, the explicit-deny ICMP echo to host 172.16.0.10 in the same VLAN:
Ping to 172.16.0.10 is now successful:
So we have established that one can edit the access-map while the filter is applied to a VLAN with apparently the effects that we wish to have.Now this is where it got interesting. I attempted to remove one entry from access-list 110:
What I didn't account for was that everything after "110" is apparently superfluous. My client PC stopped working. I'd used remote desktop to manage the client PC, and had to log in locally, got limited or no connectivity:
When I checked, sure enough, I no longer had an access-list 110 of any kind:
This apparently broke the access-map. I am used to interfaces and VTY lines that refer to access-lists functioning when the access-list itself doesn't exist, a dangerous situation since creating an access-list with that name/number would result in it being immediately applied. In the case of vlan access-maps though, it appears to break the vlan access-map if it refers to an access-list that doesn't exist.I created a new access-list 110:
And my client PC was able to get an address via DHCP and ping to the two IP ranges that are now allowed worked fine:
So in short, you can delete the access-map sequence numbers while a filter is applied and it'll behave properly, but you cannot delete ACLs while access-maps refer to them while the filter is applied and still have it function. -
OptionsTWX
Member Posts: 275 ■■■□□□□□□□
something that I should add, I was labbing this on a 2960S. I tried on 15.0 and 15.2, and neither IOS release appeared to have the command "show vlan access-map".I have confirmed that on a 3750ME the command is present though, even back in IOS 12.2. I have to suspect that despite features like private VLANs, ISPs are probably better off with VLAN filtering via VLAN access maps, since they could define the access-map on every switch possessing that VLAN and IP range. If an ISP had range 198.51.100.0/24 on VLAN 100, they could define an access-list like the following:access-list 101 permit ip 198.51.100.0 0.0.0.255 host 198.51.100.0access-list 101 permit ip 198.51.100.0 0.0.0.255 host 198.51.100.1access-list 101 permit ip 198.51.100.0 0.0.0.255 host 198.51.100.255access-list 102 permit ip 198.51.100.0 0.0.0.255 198.51.100.0 0.0.0.255apply that to a single sequence number in a vlan access-map:vlan access-map net198-51-100-0 5match ip address 101action forwardvlan access-map net198-51-100-0 10match ip address 102action dropvlan access-map net198-51-100-0 99action forwardvlan filter net198-51-100-0 vlan-list 100and theoretically this would let the clients talk to the network address, the broadcast address, and the router on 198.51.100.1, but not to each other. No private-vlans required. While VACLs are locally-significant like how private VLANs are locally-significant and do not themselves affect traffic as it's received on adjacent switches, since they're not configured per-interface, it is not necessary to edit down to the users per-interface, and the same actual configuration can be applied on all relevant switches without having to edit ports on all switches.And as always, comments, corrections, clarifications are welcome.