brownfield reconciliation - access list for line vty

[erdemk]

Dear community members,

Following is a requirement out of a PoC for an SP customer. Any help or guidance is appreciated.

Requirement is , while onboarding or adding new entry to access-list attached to line vty  , existing entries wouldn't be deleted at all times, re-ordering also wouldn't take place as it also deletes and re-defines the entries. Also compliance report wouldn't show any difference if all entries are there but in different order. ( this is cisco ios example, existing access-list is extended access-list, all rules are permit rules, let's call this vty_acl. This is a device management project, meaning changes will be applied to 1000s of devices via templates, no daily change operations)

Idea is , although we have tested and seen that existing session is not effected if the ip address from which we are accessing device is deleted from vty_acl, different vendors and different OSs could be behaving in different ways.

I have tried following methods without success :

1/ un-ordered access-list (method-3 as explained in cisco-ios-ned README file ) : i couldn't manage to use this in brownfield use-case. When i place un-ordered access-list in template, i could not deploy it, NSO says same access-list name already exists.

2/  template based service : i have placed the output of "show full-config" of the template with merge/replace/create tags. Merge was the closest one for the purpose, but doesn't re-order the entries while commit, but re-orders while re-deploy.

3/ access-list service like in example of "https://github.com/NSO-developer/nso-firewall-services" : i did try some options with guard in place, i added "deny any any" in the end in order to utilize guard. i couldn't manage to comply with the requirement. 

You may see some options that i tried for 2/ and 3/ above as attached.

A couple of CCIEs that i talked to said they are first deleting vty_acl from line vty, and adding again after making the desired changes to vty_acl. May be , this could be one solution which we can step by step implement using templates..

Or may be we would test different models to see if existing session is not effected from deleting the entry allowing us to connect to device,  and use simple template based approach.

Any guidance on how to implement this requirement is appreciated.

Thanks and regards.

[erdemk]

Hello again,

We ended up doing following.. I am sharing this, may be it is useful for someone :

1/ for cisco-ios devices, "un-ordered access-list" does exactly what the requirement wants, except that un-ordered access-list which has same name with an existing access-list cannot be created. Hence, once we follow the manual approach to on-board the device to NSO, requirement is fully satisfied. This can be used for both extended and standard access-lists.

( manual approach as explained above : A couple of CCIEs that i talked to said they are first deleting vty_acl from line vty, and adding again after making the desired changes to vty_acl. May be , this could be one solution which we can step by step implement using templates..)

2/ For huawei devices, un-ordered access-list is not supported. On the other hand, acl(s) are numbered.. By using manual approach to onboard devices onto NSO, numbered acl(s) are considered to be safe to satisfy the requirements. We could use numbered extended access-lists ( METHOD 2 ) for cisco-ios devices also, but some of the devices do not support persistent mode which is necessary to switch to numbered access-list, hence we will use un-ordered access-lists for them.

Regards.