Solved: Re: Delete an ACL entry with ydk

thanhuwng · ‎06-22-2017

Hi all, does anyone have a working ydk python script to remove an ACL entry in an existing ACL on IOS-XR 6.1.3? I've tried using CRUD DELETE and ydk.types DELETE, both to no avail. I'm using Cisco-IOS-XR-ipv4-acl-cfg.yang model. Appreciate your help.

thanks

Hung

einarnn · ‎06-23-2017

Hung,

Try something like this:

the ace we want to delete

d_ace = Cisco_IOS_XR_ipv4_acl_cfg.Ipv4AclAndPrefixList.Accesses.Access.AccessListEntries.AccessListEntry()

d_ace.sequence_number = 10

the ACL we want to delete an entry from

d_acl = Cisco_IOS_XR_ipv4_acl_cfg.Ipv4AclAndPrefixList.Accesses.Access()

d_acl.access_list_name = 'FOO'

add the ace to the acl

d_acl.access_list_entries.access_list_entry.append(d_ace)

c.delete(session, d_ace)

Cheers,

Einar

View solution in original post

shgandhi · ‎06-22-2017

Hi Hung, you can use this sample app to delete ACL entries.

Thanks,

Shruti

thanhuwng · ‎06-22-2017

Thanks Shruti for quick reply, I can use that sample app to delete the whole ACL, but not just an ACL entry in an ACL. Have you got a sample app to delete an ACL entry without having to delete the whole ACL?

Thanks

Hung

einarnn · ‎06-23-2017

Hung,

Try something like this:

the ace we want to delete

d_ace = Cisco_IOS_XR_ipv4_acl_cfg.Ipv4AclAndPrefixList.Accesses.Access.AccessListEntries.AccessListEntry()

d_ace.sequence_number = 10

the ACL we want to delete an entry from

d_acl = Cisco_IOS_XR_ipv4_acl_cfg.Ipv4AclAndPrefixList.Accesses.Access()

d_acl.access_list_name = 'FOO'

add the ace to the acl

d_acl.access_list_entries.access_list_entry.append(d_ace)

c.delete(session, d_ace)

Cheers,

Einar

thanhuwng · ‎06-23-2017

Hi Einar, thanks. Below is the error message when I try your code

ydk.errors.YPYServiceProviderError: Server reported an error while committing change.

error-type: application

error-tag: operation-failed

error-severity: error

error-path: ns1:ipv4-acl-and-prefix-list/ns1:accesses/ns1:access[access-list-name = 'ACL1']/ns1:access-list-entries/ns1:access-list-entry[sequence-number = '20']

error-message: File exists: ACL is being used by the following clients,Detach the access list from all the clients and then remove ACL

error-type: application

error-tag: operation-failed

error-severity: error

error-path: ns1:ipv4-acl-and-prefix-list/ns1:accesses/ns1:access[access-list-name = 'ACL1']/ns1:access-list-entries/ns1:access-list-entry[sequence-number = '20']

error-message: process : pkg/bin/netio pid : 327775 node : node0_0_CPU0

The configuration on the IOS-XR device when the code is attempted is below

RP/0/0/CPU0:xrv1#sh run ipv4 access-list

Fri Jun 23 13:53:53.130 UTC

ipv4 access-list ACL1

10 remark x

20 permit tcp host 172.31.255.1 any match-any +ack +fin +psh +syn +urg

!

ipv4 access-list ACL2

10 remark acl2

!

RP/0/0/CPU0:xrv1#sh run int g0/0/0/0

Fri Jun 23 14:00:58.201 UTC

interface GigabitEthernet0/0/0/0

shutdown

ipv4 access-group ACL1 egress

!

RP/0/0/CPU0:xrv1#

I think the IOS-XR device tries to remove the ACL upon receiving the request ; if I remove the ACL from the interface, the request will delete the whole ACL. Could you help to try in your lab?

thanks

Hung

einarnn · ‎06-23-2017

Hung,

This is a semantic restriction in IOS-XR. The restriction is that you may not delete all ACEs from an ACL that is in-use. You will get exactly the same error if you tried the same operation via the CLI. I realize you have a remark in the ACL also, but remark entries do not count in this case. The error is actually coming form the underlying logic that deals with activating the ACL. When you try to bind an ACL with only a remark statement in it to an interface, we see this error:

RP/0/RP0/CPU0:r622prod(config-if)#show configuration failed

Fri Jun 23 13:30:17.034 UTC

!! SEMANTIC ERRORS: This configuration was rejected by

!! the system due to semantic errors. The individual

!! errors with each failed configuration command can be

!! found below.

interface GigabitEthernet0/0/0/0

ipv4 access-group FOO ingress

!!% 'pfilter-ma' detected the 'warning' condition 'The verification of the specified access list failed because either it's empty or it has remark ACEs only.'

!

end

Note that if the ACL wasn't attached to any target this wouldn't be an issue.

Unfortunately, this kind of restriction can be hard to express in YANG constraints, and so currently we have nothing in the model to describe this.

As a workaround, and depending on what your overall ACL policy is, I can suggest having ether a trailing "deny ip any any" or a trailing "permit ip any any" that is left in place always to allow you to manipulate all other ACEs.

Cheers,

Einar

thanhuwng · ‎06-23-2017

Thank you Einar, I can replicate in my lab everything you said. Thanks for your help.

regards

Hung

thanhuwng · ‎06-23-2017

Hi Einar, on a side note, is there a way to use ydk to ask for all targets that an ACL is applied on? Instead of modifying a living ACL, I can detach the ACL from all targets, remove the ACL, re-create the ACL with new content and apply the new ACL on all targets therefore it'd be useful to retrieve existing targets of an ACL from the device.

thanks

Hung

einarnn · ‎06-23-2017

Hung,

I don't know if the YDK can support a query that tells you this. It might, but I'm not aware (today) of how to formulate such a query. What you need to use as a query if you're doing netconf directly, is a subtree filter like this:

<interface-configurations xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-ifmgr-cfg">

<interface-configuration>

<ipv4-packet-filter xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-ip-pfilter-cfg">

<acl-name-array>FOO</acl-name-array>

</inbound>

</ipv4-packet-filter>

</interface-configuration>

</interface-configurations>

When my configuration looks like:

interface GigabitEthernet0/0/0/0

ipv4 address 10.1.2.1 255.255.255.0

ipv4 access-group FOO ingress

!

interface GigabitEthernet0/0/0/1

shutdown

!

interface GigabitEthernet0/0/0/2

shutdown

ipv4 access-group FOO ingress

!

...this subtree filter will return something like:

(v) ✔ /opt/git-repos/ncc-devnet master ↓·1

16:13 $ python ncc.py --host=127.0.0.1 --port=8300 -g --named-filter ingress-acl-interfaces

<interface-configurations xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-ifmgr-cfg">

<interface-configuration>

<interface-name>GigabitEthernet0/0/0/0</interface-name>

<ipv4-packet-filter xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-ip-pfilter-cfg">

<acl-name-array>FOO</acl-name-array>

<is-common-array>false</is-common-array>

</inbound>

</ipv4-packet-filter>

</interface-configuration>

<interface-configuration>

<interface-name>GigabitEthernet0/0/0/2</interface-name>

<ipv4-packet-filter xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-ip-pfilter-cfg">

<acl-name-array>FOO</acl-name-array>

<is-common-array>false</is-common-array>

</inbound>

</ipv4-packet-filter>

</interface-configuration>

</interface-configurations>

</data>

Maybe someone else in the forum can outline how to perform a similar query with the YDK instead?

Cheers,

Einar

PS ncc.py is a Python script you can find at https://github.com/CiscoDevNet/ncc

abhirame · ‎06-23-2017

Hi Einar,

Is the subtree filter missing from your reply? It could be useful to look at it when writing the YDK CRUD read request.

einarnn · ‎06-23-2017

Abhi,

Seems embedded XML doesn't get inserted too well!! I've edited my reply to include the subtree filter and result.

Cheers,

Einar

thanhuwng · ‎06-23-2017

Thanks Einar and abhirame. I can't run ncc.py to retrieve running-config. It throws the error below. I've always had this issue with ncclient to retrieve full running-config, while retrieving a filtered running-config or retrieving capabilities is ok. Did you come across this before?

lxml.etree.XMLSyntaxError: Input is not proper UTF-8, indicate encoding !

thanks

Hung

einarnn · ‎06-23-2017

Never seen an error like that, sorry!

thanhuwng · ‎06-23-2017

I've attached a verbose output of the ncc.py get-running issue. As it's a slight digress from the main topic, I can put this to a separate topic if need be, let me know.

regards

Hung

einarnn · ‎06-29-2017

I thought I'd replied to this earlier, my apologies!

Looking at the debug logs, we can see that the secret leaf is probably the culprit:

<secret>«ÍC!</secret>

</username>

</usernames>

</aaa>

<usergroup-under-usernames>

<usergroup-under-username>

<name>root-system</name>

</usergroup-under-username>

</usergroup-under-usernames>

<secret>«ÍC!</secret>

</username>

</usernames>

</aaa>

The problem is how the secret is encoded. It is being embedded using characters that are not legal for the XML character set. I would agree that this is an XR issue. I'll forward on to the AAA team.

This issue can be worked around somewhat by dealing with the returned payload directly and potentially using a different XML parser from what is used by ncclient, or possibly by using the same parser with a different configuration. I looked around a bit, and found some articles talking about similar issues, like:

python - How to make xml parser ignore invalid characters? - Stack Overflow

However, we need to fix XR to return data with a valid encoding.

Cheers,

Einar