There are two ways to do access-lists in EXOS.
1.) You can create a policy file using the Vi editor and apply it to a VLAN. The policy file uses bracketed syntax and can contain multiple rules which you give unique names to. The policy file is named with a .pol extension and is separate from the configuration file.
2.) You can create dynamic ACLs which are single match/action rules that you create and apply to an interface or VLAN. Multiple rules can be applied and the order is important. The rules are contained within the config file, so if you’re backing the switch config up it is easier because you don’t need to worry about the .pol files too.
I’m covering a simple example here of the first type – the policy file version.
Setup:
1 Summit X450a switch, configured with three VLANs:
– ICT – 192.168.0.1/24
– Public – 192.168.1.1/24
– Outside – 192.168.2.1/24
IP forwarding is enabled on all three VLANs, and a port has been added into each with a PC on the appropriate subnet connected for ping testing. Intially, all PCs can ping each other.
Objective:
What I want to achieve here is that the ICT and Public access VLANs cannot talk to each other, but they can talk to the Outside (i.e. Internet) VLAN. Replies from the Outside should come back into the VLAN that originated the request unhindered.
Configuration:
First, I need to create a policy file. For this, you need to be a bit familiar with the Vi text editor. There are plenty of resources around covering this, but I will try to give you enough here.
To create the new file, type “vi Public.pol”. This will give you a blank screen with the filename at the bottom. You are currently in a kind of ‘view’ mode and can’t make changes to the file’s contents.
To enter into ‘edit’ mode, press the Escape key once, then press i (for ‘insert’). You’ll notice the filename goes away. When you start typing, you’ll see that the bottom status line says the file has been modified – indicating that you need to save changes.
To come out of edit mode, just press escape again.
Now, to write the file type :wq The colon tells the editor that there’s a command coming, and the command is wq which means write the file and quit.
So all that said, here’s what we need in our policy file for the public VLAN:
entry Block-Local {
if match all{
source-address 192.168.1.0/24;
destination-address 192.168.0.0/24;
} then {
count pub-deny;
deny;
}
}
entry Permit-Other {
if match all{
source-address 192.168.1.0/24;
destination-address 0.0.0.0/0;
} then {
count pub-permit;
permit;
}
}
Each ‘entry’ is a rule. First we have a ‘if match all’ statement, followed by some parameters in brackets. Match all tells the switch that this is a packet filtering policy, rather than ‘Match any’ which would filter routing updates. In the Block-Local entry we are matching on the source address of the Public VLAN, and the destination address of the ICT VLAN.
What follows is a ‘then’ section, which denotes what action to perform on packets that match these conditions. I have a counter called ‘pub-deny’ which just clocks up the number of packets matching this condition. Finally, there’s a ‘deny’ statement, which does the job of chucking the packets away. I have a feeling if you had these two the other way around, packets woudl get chucked before they get a chance to be counted, but I’ve not tested this out yet.
After that, there’s another entry called Permit-Other which matches the source address of the Public VLAN, and 0.0.0.0/0, which equates to anything else. Once again, we count the packets (using a differently-named counter), and this time we permit.
Write the file and quit.
Check that you got all your brackets and semi-colons in the right places using “check policy Public”. This should come back with errors or the message ‘Policy file check successful’. (Note that you don’t include the .pol extension).
Now all that’s left to do is to apply the policy to the VLAN. You do this with the command:
configure access-list Public vlan Public ingress
And you’re done. Public client now can’t ping the ICT client and vice-versa, but both can ping the Outside client.
I guess technically you’d configure a similar ACL policy for the ICT VLAN to be thorough.
If you need to make changes to the .pol file, once you’re done editing it you need to do a ‘refresh policy Public’ to get the switch to read in your policy again and apply it to the hardware. If you don’t do that, your old policy will still be active despite the changes you made to the file.
You can verify that packets are hitting the ACL by looking at the stats on the counters that we configured. See below:
# show access-list counter
Policy Name Vlan Name Port Direction
Counter Name Packet Count
===================================================
Public Public * ingress
pub-deny 28
pub-permit 205
Hope that makes sense!
The Data Plumber 