topic Re: access-list insert after error in NSO Developer Hub Discussions

access-list insert after error

Ben Kelly — Fri, 01 Mar 2019 12:00:44 GMT

I'm getting an error when I'm trying to add an access-list entry at a particular place (Cisco ASA). The error says that the ACL I'm trying to insert after doesn't exist, but the config of the service shows that it is.

As far as I can tell, this occurs when I create more than one entry in a single transaction. Once I've done that, the next time I try to configure the service, I get the error.

I'm using ASA NED v5.5.2

Error:

Error: Unknown error (66): allowed-dest-entry-after.xml:14 Insert 'after' at '/ncs:devices/device{svlngen4-fab6-dmzdc-02-fw1}/config/asa:access-list/access-list-id{nso-dmz-to-internal-02}/rule{"extended permit tcp object-group cloud-app-1 172.16.0.0 255.255.252.0 eq https"}' failed because 'extended permit udp object-group cloud-app-1 192.168.2.0 255.255.255.0 eq 8080' does not exist.

Service Config

admin@ncs# show running-config devices device svlngen4-fab6-dmzdc-02-fw1 config asa:access-list nso-dmz-to-internal-02

devices device svlngen4-fab6-dmzdc-02-fw1

config

asa:access-list nso-dmz-to-internal-02 "extended permit tcp object-group bk-app-1 10.0.0.0 255.0.0.0 eq https"

asa:access-list nso-dmz-to-internal-02 "remark nso_managed_start"

asa:access-list nso-dmz-to-internal-02 "extended permit tcp object-group cloud-app-1 172.16.0.0 255.255.252.0 eq https" log

asa:access-list nso-dmz-to-internal-02 "extended permit tcp object-group cloud-app-1 192.168.1.0 255.255.255.0 eq 243" log

asa:access-list nso-dmz-to-internal-02 "extended permit udp object-group cloud-app-1 192.168.2.0 255.255.255.0 eq 8080" log

asa:access-list nso-dmz-to-internal-02 "remark nso_managed_end"

asa:access-list nso-dmz-to-internal-02 "extended permit tcp object-group bk-app-1 192.168.1.0 255.255.255.0 eq ssh"

Re: access-list insert after error

gschudel — Tue, 03 Oct 2017 19:22:48 GMT

Hey Ben

So... i tried this again - from CLI... looked at the XML - and it seems to work - but considering that we need to understand how it's (internally) looking at this... Meaning - what you tried to do (i believe) is use the "after" option.... but keep in mind that once you add a new rule, the "after" position now changes... because any subsequent rule would technically be "after" the new one you just added...

It looks like you can show this, using NSO CLI...

in this example, i added FOUR new rules "before" (i.e. just above) some marked position - in this case (again) a "remark" -- but that doesnt' matter - what matters is i want all four new rules to be inserted just above a line...

again - note the the inserts are all "before" -- but the resulting XML is all "after" syntax...

admin@ncs% edit devices device asa0 config asa:access-list access-list-id Corona

[ok][2017-10-03 11:13:25]

[edit devices device asa0 config access-list access-list-id Corona]

admin@ncs% insert

Possible completions:

after before first last rule

admin@ncs% insert rule

Possible completions:

<WORD> - quoted rule beginning with: remark|standard|extended|webtype, followed by options (e.g. log|inactive).

For example: "extended permit tcp any any" log

remark - this is the inside out traffic -

extended permit ip host 10.1.1.10 any -

extended permit ip host 10.1.1.12 any -

extended permit ip host 10.1.1.14 any -

remark - this is the hr admin address -

extended permit ip host 10.1.1.40 any -

admin@ncs% insert rule "extended permit tcp port 80 host any" before "remark - this is the hr admin address"

[ok][2017-10-03 11:14:50]

[edit devices device asa0 config access-list access-list-id Corona]

admin@ncs% insert rule "extended permit tcp port 81 host any" before "remark - this is the hr admin address"

[ok][2017-10-03 11:14:50]

[edit devices device asa0 config access-list access-list-id Corona]

admin@ncs% insert rule "extended permit tcp port 82 host any" before "remark - this is the hr admin address"

[ok][2017-10-03 11:14:50]

[edit devices device asa0 config access-list access-list-id Corona]

admin@ncs% insert rule "extended permit tcp port 83 host any" before "remark - this is the hr admin address"

[ok][2017-10-03 11:14:50]

[edit devices device asa0 config access-list access-list-id Corona]

admin@ncs% commit dry-run

cli {

local-node {

data devices {

device asa0 {

config {

asa:access-list {

access-list-id Corona {

+ # after rule "extended permit ip host 10.1.1.14 any"

+ rule "extended permit tcp port 80 host any";

+ rule "extended permit tcp port 81 host any";

+ rule "extended permit tcp port 82 host any";

+ rule "extended permit tcp port 83 host any";

}

[ok][2017-10-03 11:14:53]

[edit devices device asa0 config access-list access-list-id Corona]

admin@ncs% commit dry-run | di

% Invalid input detected at '^' marker.

admin@ncs% commit dry-run outformat xml

result-xml {

local-node {

data <devices xmlns="http://tail-f.com/ns/ncs">

<access-list xmlns="http://cisco.com/ned/asa">

<access-list-id>

<id>Corona</id>

<rule xmlns:yang="urn:ietf:params:xml:ns:yang:1"

xmlns:ncs="http://tail-f.com/ns/ncs"

yang:insert="after"

yang:key="[ncs:id='extended permit ip host 10.1.1.14 any']">

<id>extended permit tcp port 80 host any</id>

</rule>

<rule xmlns:yang="urn:ietf:params:xml:ns:yang:1"

xmlns:ncs="http://tail-f.com/ns/ncs"

yang:insert="after"

yang:key="[ncs:id='extended permit tcp port 80 host any']">

<id>extended permit tcp port 81 host any</id>

</rule>

<rule xmlns:yang="urn:ietf:params:xml:ns:yang:1"

xmlns:ncs="http://tail-f.com/ns/ncs"

yang:insert="after"

yang:key="[ncs:id='extended permit tcp port 81 host any']">

<id>extended permit tcp port 82 host any</id>

</rule>

<rule xmlns:yang="urn:ietf:params:xml:ns:yang:1"

xmlns:ncs="http://tail-f.com/ns/ncs"

yang:insert="after"

yang:key="[ncs:id='extended permit tcp port 82 host any']">

<id>extended permit tcp port 83 host any</id>

</rule>

</access-list-id>

</access-list>

</config>

</device>

</devices>

}

[ok][2017-10-03 11:15:05]

[edit devices device asa0 config access-list access-list-id Corona]

admin@ncs%

so... what we see is NSO converted this "before" request into a series of "after" requests - where each was applied just after the new rule that was just added...

hth

cheers

gregg

Re: access-list insert after error

Ben Kelly — Wed, 04 Oct 2017 04:26:13 GMT

Thanks for the guidance Gregg. It's a big help

I think the problem is that I was inserting the new rule after a rule that is part of the service instantiation. I changed the logic around so that it inserts the rule before another entry NOT part of this service instantiation and it appears to be working.

Re: access-list insert after error

branblac@cisco.com — Wed, 18 Oct 2017 07:56:09 GMT

Hey NSO team,

Is there a way to implement this capability with the IOS NED? as the IOS sequence numbers function in the same form?

Currently for the IOS NED to do surgical placement in a ACL the NED issues no commands up the list, inserts the new rule, then adds the commands back.

Since the logic for using sequence numbers is implemented for ASA, is it possible to port that capability into the IOS NED?

This would a fantastic improvement and make NSO usable for IOS ACL Management

Re: access-list insert after error

branblac@cisco.com — Wed, 18 Oct 2017 08:51:43 GMT

NSO CLI output example of how this feature works on IOS:

branblac@ncs% insert ext-access-list-rule "remark test" first

[ok][2017-10-18 18:51:58]

[edit devices device device-name config ip access-list extended ext-named-acl qos-signalling]

branblac@ncs% commit dry-run

cli {

local-node {

data devices {

devicedevice-name {

config {

ios:ip {

access-list {

extended {

ext-named-acl qos-signalling {

+ # first

+ ext-access-list-rule "remark test";

}

[ok][2017-10-18 18:52:04]

[edit devices device device-name config ip access-list extended ext-named-acl qos-signalling]

branblac@ncs% commit dry-run outformat native

native {

device {

name device-name

data ip access-list extended qos-signalling

no remark Traffic to be classify into signalling

no remark Skinny

no permit tcp any any range 2000 2001

no remark Gatekeeper RAS, Q.931 and H.

no permit tcp any any eq 1720 5061

no remark RADIUS for EAP

no permit udp any range 2326 2485 any dscp 35

no permit udp any range 46000 49000 any dscp 37

no remark Tandberg endpoints

no remark Traffic to be classified as AF41

no permit udp any range 46000 49000 any dscp 35

remark test

remark Traffic to be classify into signalling

remark Skinny

permit tcp any any range 2000 2001

remark Gatekeeper RAS, Q.931 and H.

permit tcp any any eq 1720 5061

remark RADIUS for EAP

permit udp any range 2326 2485 any dscp 35

permit udp any range 46000 49000 any dscp 37

remark Tandberg endpoints

remark Traffic to be classified as AF41

permit udp any range 46000 49000 any dscp 35

exit

}

[ok][2017-10-18 18:52:16]

As you can imagine, if one is trying to add a line to an ACL that is allowing the NSO to communicate to the device, then NSO removes the permit line for its self, it would effectively remove NSO (and others..) ability to access it.

Having the ability to enter ACE entries via the sequence number for ordering IOS ACL like the ASA NED is doing would amazing.

Here is an example from a trace to an ASA where we used the 'first' ordering keyword for inserting to an ACL like explained above. As expected, it leveraged the sequence number of 1 for inserting first rather than negates and re-entering of config:

asa-device(config)#

*** output 18-Oct-2017::01:46:09.409 ***

access-list jw_apt line 1 remark test

Re: access-list insert after error

Lennart Bång — Tue, 24 Oct 2017 04:26:59 GMT

Answering here as well for the benefit of all.

You can actually insert access-list entries with the cisco-ios NED today. Just do:
1) set "ip access-list persistent" on device, it instructs IOS to show sequence numbers in the access-lists in show run

2) switch YANG model to use the sequence number as the key instead of the rule by setting a ned-setting:
admin@ncs(config)# devices device <devname> ned-settings cisco-ios-api new-ip-access-list true

admin@ncs(config)# commit

admin@ncs(config)# devices device <devname> disconnect (to force a reload of ned-settings)

3) Configure ip access-lists on the device in order to help see how it looks in NSO
4) devices device <devname> sync-from

5) admin@ncs(config)# do show run devices device <devname> config ios:ip access-list -- to show you access-lists

6) admin@ncs(config)# do show run devices device <devname> config ios:ip access-list | display xml - to show the model

Then if you want to insert just use a sequence number before/after the relative entry.

admin@ncs(config-config)# ip access-list extended MYACL

admin@ncs(config-nacl)# ?

Possible completions:

<1-2147483647> Sequence Number

---

admin@ncs(config-nacl)# 40 ?

Possible completions:

<WORD> deny | permit | remark | dynamic | evaluate ACL entry

Hence, the key is now the sequence number, allowing insertions etc.

+++

Also, worth mentioning is that we are soon releasing a third method (in cisco-ios v5.5) which will allow you to work in NSO without sequence numbers, and let the NED handle them for you. This method will issue "ip access-list resequence" in order to allocate room for inserting/moving entries. This method may be desirable if you do not want to handle the sequence ordering yourself, and you wont risk running out of space between two entries, forcing a resequence and re-sync from the device.

Regards,

Lennart

Re: access-list insert after error

branblac@cisco.com — Tue, 24 Oct 2017 08:39:54 GMT

Thanks Lennart, that is awesome!

Great stuff and im excited for the NED update!