10-03-2017 03:17 AM - edited 03-01-2019 04:00 AM
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"
10-03-2017 12:22 PM
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">
<device>
<name>asa0</name>
<config>
<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
10-03-2017 09:26 PM
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.
10-18-2017 12:56 AM
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
10-18-2017 01:51 AM
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
10-23-2017 09:26 PM
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
10
20
30
---
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
10-24-2017 01:39 AM
Thanks Lennart, that is awesome!
Great stuff and im excited for the NED update!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide