EXOS – ACL’s

29th December 2015 by Martin Flammia

Filed under Extreme Networks EXOS

Last modified 7th April 2016

ACL’s can be created in two ways. The first is to create a policy (static ACL) with “if”, “then” statements the other is to use the ‘Dynamic’ ACL format. The former you are able to create a list of ACL’s and apply them as a whole to a selection of ports, the later ‘dynamic’ you create singular rules and apply each to a port.

I typically configure policy based ACL’s, the main reason for this is that it is far easier to make amendments after, like enabling logging, then using dynamic ACL’s.

The dynamic example given below shows how to create an access-list that blocks pings.

The following example shows how to do it using a policy:

The edit command will take you into a ‘vi’ editor, where you can add the actual rule:

Common Vi commands:

  • [i]—Inserts text ahead of the initial cursor position.
  • [a]—Appends text after the initial cursor position.
  • To escape the input mode and return to the command mode, press the [Esc] key.
  • [dd]—Deletes the current line.
  • [yy]—Copies the current line.
  • [p]—Pastes the line copied.
  • [:w]—Writes (saves) the file.
  • [:q]—Quits the file if no changes were made.
  • [:q!]—Forcefully quits the file

ACL Policy Rules:

  • A rule entry name, unique within the same ACL policy file or among Dynamic ACLs.
  • Zero or more match conditions.
  • Zero or one action (permit or deny). If no action is specified, the packet is permitted by default.
  • Zero or more action modifiers.

Each rule entry uses the following syntax:

An ACL rule is evaluated as follows:

  • If the packet matches all the match conditions, the action and any action modifiers in the then
    statement are taken.
  • For ingress ACLs, if a rule entry does not contain any match condition, the packet is considered to
    match and the action and any action modifiers in the rule entry’s “then” statement are taken. For
    egress ACLs, if a rule entry does not contain any match condition, no packets will match.
  • If the packet matches all the match conditions, and if there is no action specified in the then
    statement, the action permit is taken by default.
  • If the packet does not match all the match conditions, the action in the then statement is ignored.
  • If no match has occurred after evaluating all entries, the default action is permit.

Unlike ingress ACLs, for egress ACLs you must specify either a source or destination address, instead of writing a rule with no match conditions.

For example, an ingress ACL deny all rule could be:

The previous rule would not work as an egress ACL.

The following is an example of an egress ACL deny all rule:

You can check a policy for errors with the following command, but if there is a problem with your policies syntax when you apply it to the port it will also do a check then:

If you make a change to a policy and wish to refresh it, you can use the following command:

The following is an example dynamic explicit deny all:

Sometimes when creating ACL’s its useful to log permit or denies in order to check it’s doing what you want it to do.

The action in an ACL can be log, but logging needs to be handled by the CPU so you will also need to enable this too. The following is an dynamic ACL example:

The following is a static, policy based ACL:

For adding the logging to the CPU you need to enable an entry in the log filter as this is excluded by default (assuming the use of the ‘defaultfilter’ filter):

or

Had a situation when creating an ACL it would not function as expected, but the log on the ACL was not showing any detail, so the way I got around this was to create a capture for the permit all at the end on my ACL and log the hits, I could then see what was falling through the net. In my particular case the ACL was being applied in the wrong direction.

Warning: Use this with caution, as you could overwhelm the switch. You can simply tailor your permit all too suit.

3 Comments

  1. Kygo

    Thanks for a nice blog!

    So if i have multiple ip’s added to my switch, but i only want to allow management/snmp/ssh on that specific ip, can that be done?

    Or do the ACL need to limit that i allow which souce ips that can connect to the switch on any of the ipadresses.

    Or can ssh/snmp be disabled for specific vlans?

    22nd April 2016 - 10:58 am – Reply

    • Hi Kygo, thanks for your comments.

      Believe you can do something like the following:

      create access-list MgmtAccess " source-address 192.168.100.1/32; " "permit"
      create access-list MgmtDeny " source-address 0.0.0.0/0; " "deny"

      configure ssh2 access-profile add MgmtAccess first
      configure ssh2 access-profile add MgmtDeny after MgmtAccess
      configure snmp access-profile add MgmtAccess first
      configure snmp access-profile add MgmtDeny after MgmtAccess
      configure web http access-profile add MgmtAccess first
      configure web http access-profile add MgmtDeny after MgmtAccess

      You can’t use a policy file for http or https, but you can for the other protocols. Standardised the config with a dynamic ACL for simplicity.

      22nd April 2016 - 11:28 pm – Reply

      • Kygo

        Thanks!

        25th April 2016 - 9:32 am – Reply

Leave a Comment