As usual, the same guidelines apply:
- You need at least one permit since there is always an implicit deny.
- The order matters.
- The global lists are first created then need to be assigned to a purpose.
- They will either recognize traffic and let it serve the purpose or prevent it from serving its purpose.
- One ACL will be used per protocol, per direction.
To configure ACLs the command will look like:
ip access-list NAME1
permit tcp 172.16.0.0/16 any eq 80
permit tcp 172.16.0.0/16 any eq 25
Now we can assign our ACL to a interface:
int e2/1
ip address 10.10.10.100/24
no shut
ip access-group TEST in
Which would apply the ACL to the inbound ACL on interface e2/1.
show access-list
Will display your ACLs with line numbers which can be used to manipulate the list further. To see the access-list assignment without viewing the ACL you can use (new to NX-OS):
show access-list summary
To edit a line or insert a line you can use:
ip access-list NAME1
line-number permit udp any any
Inserting a no before any line will let you remove a line so you can add one over it. Also, with NX-OS you can now verify ACLs before applying them using:
configure session ACLTEST
ip access-list name2
permit icmp any any
interface 2/2
ip access-group name2 in
Now you can run:
verify
To ensure the ACL will run as expected. You can then commit it by simply running:
commit
You can create object groups using object group commands to simplify hosts/ports into groups to make your ACLs more simple:
object-group ip address GROUP1
192.168.1.0/24
192.168.2.0/24
192.168.3.0/24
exit
show object-group GROUP1
ip access-list NAME3
permit ip addrgroup GROUP1 any
Now if you run a show access-list with expanded you can see the object groups expanded:
show access-list NAME3 expanded
WHEN YOU CREATE ACLs AND PUT DENY’S FIRST BE SURE TO PUT YOUR PERMITS AFTERWARDS OTHERWISE YOU WILL DENY EVERYTHING!