During my research of the ACL module of OnePK I found some interesting behaviors. I think this feature isn’t fully cooked as it has some definite room for improvement. The ACL module (found in onep.policy) doesn’t have a way to interact with existing ACLs and ACEs on an IOS device. The ACLs seem to be intended for on-the-fly ACL configuration but with a couple caveats:

  • Applying an ACL to an interface overwrites the existing ACL for that direction. Interfaces must play by the rule: ‘One ACL per direction’.
  • Make sure to use OnepLifetime.ONEP_PERSISTENT to keep ACLs applied after the OneP session is disconnected.

First I’ll cover ACL management with OneP, and then I’ll use the onep.vty module to show how to workaround some of the shortcomings.

Creating and Applying an ACL On-the-Fly

A use case that fits in well with OnePK ACL management is creating dynamic ACLs based on input from a separate application such as a IDS/IPS system. Let’s use this scenario for the first example: Our OnePK app received an alert (possibly a syslog or SNMP trap) that a device on the network is receiving an attack using a SSH exploit and we need to stop the bogus traffic.  We know that SSH uses TCP port 22 and also that the end host receiving the attack has an IP address of  Here’s one way we can create an ACL to block that traffic:

There isn’t a lot of logging provided on the IOS device to tell us that the ACL was applied, but we can run a show ip interface gi2 command at the enable prompt to see the following confirmation:

Boom, there’s our dynamic ACL on the inbound direction of the ‘gi2’ interface. We could apply this interface in both directions if we used Acl.Direction.ONEP_DIRECTION_BOTH in the .apply_to_interface() method. Also, you guessed it, we can use Acl.Direction.ONEP_DIRECTION_OUT for traffic leaving that interface also.  This ACL could also be applied to multiple interfaces (more than one Internet facing interface?) like this:

Depending on our expectations for the life of the ACL, we can have it automatically removed at the end of the onep session by specifying  L3Acl.OnepLifetime.ONEP_TRANSIENT during the creation of the L3Acl Object.

To see a more in-depth example that includes syslog parsing and a bi-directional ACE, check it out on the GitHub repo here.

Viewing and Modifying Existing ACLs

Support for interacting with existing ACLs isn’t directly built-in to OnePK, but we can use the onep.vty module to achieve some pretty close capabilities. Here’s a simple way to view existing ACLs:

Which gives the output:

Very cool, there’s our dynamically created ACL from the previous example along with an existing ACL on the router. This is returned to us as a string but some fancy parsing could be done in order to confirm compliance to policies. Using that same VtyHelper object, we can also modify the DEMO ACL by adding an ACE using the .config() method:

And we can see our added sequence #15 ACE and removed #20 sequence ACE in the DEMO ACL:

With both of these ACL creation technique, don’t forget to save the config on the device with the VtyHelper .commit() method.

As you can see, dynamic ACL creation is very powerful especially since you can manipulate existing ACLs with the VtyHelper object. I think this is a good supplement in places where the onep SDK doesn’t have full feature coverage. It certainly does open the door to any configuration that can be done via CLI.

Series Navigation<< OnePK – Interacting with Interfaces

This post was originally published on

This article has 2 comments

    1. Mat

      Hi Stefano, I appreciate your kind comment!  Unfortunately, adding routes does not see to be a native feature of the OnePK SDK at this time. It can still be done with the OnePL VTY Service Set which is similar to a SSH client that will send a command to a connected NetworkElement. Check out Cisco’s tutorial on using the VTY Service Set and just use your “ip route” type command as the string in TEST_CMD1.

Leave a Reply

Your email address will not be published. Required fields are marked *