08-20-2024 06:36 AM
Hi All,
I am trying to use common openconfig interface to configure both IOS XE and IOS XR. I created a template and used Nornir_scrapli to push the config. The IOS XE was successful after deploying the config but XR 6.3.1, although it configured the IP but it configures only the first interface normally, any other interface was configured with secondary appended to it as if it is secondary IP. I attempted same config on IOS-XRv 9000 and it also configured the first normally but the subsequent Gig interfaces came back as preconfigured. I don't know if I am doing anything wrong here. Can Anyone figure out what is going on here please and help.
Below are the result of what was configured on this XR 6.3.1
interface Loopback0
ipv4 address 10.255.255.22 255.255.255.255 secondary
!
interface GigabitEthernet0/0/0/0
ipv4 address 10.22.23.22 255.255.255.0
!
interface GigabitEthernet0/0/0/1
ipv4 address 10.21.22.22 255.255.255.0 secondary
!
interface GigabitEthernet0/0/0/2
ipv4 address 10.1.22.22 255.255.255.0 secondary
!
See below for what was configured on the IOS-XRv9k.
interface Loopback0
ipv4 address 10.255.255.22 255.255.255.255
!
interface GigabitEthernet0/0/0/0
ipv4 address 10.22.23.22 255.255.255.0
!
interface preconfigure GigabitEthernet0/0/0/1
ipv4 address 10.21.22.22 255.255.255.0
!
interface preconfigure GigabitEthernet0/0/0/2
ipv4 address 10.1.22.22 255.255.255.0
Below are the openconfig template used for this deployment.
<config>
<interfaces xmlns="http://openconfig.net/yang/interfaces">
{% for iface in host.facts.interfaces %}
<interface>
<name>{{ iface.name }}</name>
<config>
<name>{{ iface.name }}</name>
<type xmlns:idx="urn:ietf:params:xml:ns:yang:iana-if-type">{{ iface.Type }}</type>
<enabled>{% if iface.enabled %}true{% else %}false{% endif %}</enabled>
</config>
{% if iface.ipv4 is defined %}
<subinterfaces>
<subinterface>
<index>0</index>
<ipv4 xmlns="http://openconfig.net/yang/interfaces/ip">
<addresses>
<address>
<ip>{{ iface.ipv4.address }}</ip>
<config>
<ip>{{ iface.ipv4.address }}</ip>
<prefix-length>{{ iface.ipv4.prefix }}</prefix-length>
</config>
</address>
</addresses>
</ipv4>
</subinterface>
</subinterfaces>
{% endif %}
</interface>
{% endfor %}
</interfaces>
</config>
Below are my variable host yaml file
interfaces:
- name: GigabitEthernet0/0/0/0
enabled: true
Type: "idx:ethernetCsmacd"
description: A1-XR22-A1-XE23
ipv4:
address: 10.22.23.22
prefix: 24
- name: GigabitEthernet0/0/0/1
enabled: true
Type: "idx:ethernetCsmacd"
description: A1-XR22-A1-XR21
ipv4:
address: 10.21.22.22
prefix: 24
- name: GigabitEthernet0/0/0/2
enabled: true
Type: "idx:ethernetCsmacd"
description: A1-XR22-C-XR1
ipv4:
address: 10.1.22.22
prefix: 24
- name: Loopback0
description: System_ID
enabled: true
Type: "idx:softwareLoopback"
ipv4:
address: 10.255.255.22
prefix: 32
08-20-2024 08:08 AM
I just did a get using the openconfig-interfaces module - the only difference I see is an additional config-element in the subinterface. I don't think this is necessary, however I suggest trying to add this element in your payload. It's worth a try.
Template with additional config element:
<config>
<interfaces xmlns="http://openconfig.net/yang/interfaces">
{% for iface in host.facts.interfaces %}
<interface>
<name>{{ iface.name }}</name>
<config>
<name>{{ iface.name }}</name>
<type xmlns:idx="urn:ietf:params:xml:ns:yang:iana-if-type">{{ iface.Type }}</type>
<enabled>{% if iface.enabled %}true{% else %}false{% endif %}</enabled>
</config>
{% if iface.ipv4 is defined %}
<subinterfaces>
<subinterface>
<index>0</index>
<!-- try to add the following config element -->
<config>
<index>0</index>
<enabled>true</enabled>
</config>
<!-- end of addition -->
<ipv4 xmlns="http://openconfig.net/yang/interfaces/ip">
<addresses>
<address>
<ip>{{ iface.ipv4.address }}</ip>
<config>
<ip>{{ iface.ipv4.address }}</ip>
<prefix-length>{{ iface.ipv4.prefix }}</prefix-length>
</config>
</address>
</addresses>
</ipv4>
</subinterface>
</subinterfaces>
{% endif %}
</interface>
{% endfor %}
</interfaces>
</config>
08-20-2024 01:22 PM
Thanks @Marcel Zehnder . I have tried it but it's still the same result.
Result from IOS-XR 6.31:
interface Loopback0
ipv4 address 10.255.255.22 255.255.255.255 secondary
!
interface GigabitEthernet0/0/0/0
ipv4 address 10.22.23.22 255.255.255.0
!
interface GigabitEthernet0/0/0/1
ipv4 address 10.21.22.22 255.255.255.0 secondary
!
interface GigabitEthernet0/0/0/2
ipv4 address 10.1.22.22 255.255.255.0 secondary
Result from XR9k:
interface Loopback0
ipv4 address 10.255.255.22 255.255.255.255
!
interface GigabitEthernet0/0/0/0
ipv4 address 10.22.23.22 255.255.255.0
!
interface preconfigure GigabitEthernet0/0/0/1
ipv4 address 10.21.22.22 255.255.255.0
!
interface preconfigure GigabitEthernet0/0/0/2
ipv4 address 10.1.22.22 255.255.255.0
!
08-20-2024 01:30 PM
Try and modify your OpenConfig template to remove the subinterfaces
container and place the ipv4
container directly under the interface
container.
if memory serves me, on XR platforms, the preconfigure
keyword is used to configure interfaces that are not yet present in the running configuration. If the interface is already present, the preconfigure
keyword is not necessary. You can try removing the preconfigure
keyword from your template to see if it makes a difference.
08-20-2024 03:05 PM
Thanks @bigevilbeard . I have tried it. The execution of the code on XR devices on the returned rpc reply as if it was successful but it was never executed on the device. Also, the IOS-XE failed.
---- Committing Changes into the C-XR1 Running Configuration ** changed : True - INFO
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="102">
<ok/>
</rpc-reply>
^^^^ END INTERFACE_ROUTER_MPLS_CONFIGURATION ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Final Result Summary:
+----------+------------------------------------------------------------+
| Device | Status |
+==========+============================================================+
| C-XR1 | Deployed Successfully |
+----------+------------------------------------------------------------+
| C-XE1 | Subtask: Config_to_iosxe_Device_Deployed_to_C-XE1 (failed) |
+----------+------------------------------------------------------------+
Below is the adjusted template which I used :
<config>
<interfaces xmlns="http://openconfig.net/yang/interfaces">
{% for iface in host.facts.interfaces %}
<interface>
<name>{{ iface.name }}</name>
<config>
<name>{{ iface.name }}</name>
<type xmlns:idx="urn:ietf:params:xml:ns:yang:iana-if-type">{{ iface.Type }}</type>
<enabled>{% if iface.enabled %}true{% else %}false{% endif %}</enabled>
</config>
{% if iface.ipv4 is defined %}
<!-- end of addition -->
<ipv4 xmlns="http://openconfig.net/yang/interfaces/ip">
<addresses>
<address>
<ip>{{ iface.ipv4.address }}</ip>
<config>
<ip>{{ iface.ipv4.address }}</ip>
<prefix-length>{{ iface.ipv4.prefix }}</prefix-length>
</config>
</address>
</addresses>
</ipv4>
{% endif %}
</interface>
{% endfor %}
</interfaces>
</config>
08-20-2024 09:43 PM
Okay, one more try, what about explicit set the ipv4 type to PRIMARY (which should be the default):
<config>
<interfaces xmlns="http://openconfig.net/yang/interfaces">
{% for iface in host.facts.interfaces %}
<interface>
<name>{{ iface.name }}</name>
<config>
<name>{{ iface.name }}</name>
<type xmlns:idx="urn:ietf:params:xml:ns:yang:iana-if-type">{{ iface.Type }}</type>
<enabled>{% if iface.enabled %}true{% else %}false{% endif %}</enabled>
</config>
{% if iface.ipv4 is defined %}
<subinterfaces>
<subinterface>
<index>0</index>
<config>
<index>0</index>
<enabled>true</enabled>
</config>
<ipv4 xmlns="http://openconfig.net/yang/interfaces/ip">
<addresses>
<address>
<ip>{{ iface.ipv4.address }}</ip>
<config>
<ip>{{ iface.ipv4.address }}</ip>
<prefix-length>{{ iface.ipv4.prefix }}</prefix-length>
<type>PRIMARY</type>
</config>
</address>
</addresses>
</ipv4>
</subinterface>
</subinterfaces>
{% endif %}
</interface>
{% endfor %}
</interfaces>
</config>
If this does not work, you probaly need to switch to the platform specific models - I know its annoying as you also need platform specific templates.
08-21-2024 12:24 AM
Thanks @Marcel Zehnder for supporting. It did not work. Both devices returned errors.
---- Config_to_iosxe_Device_Deployed_to_C-XE1 ** changed : True ---------------- ERROR
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
<rpc-error>
<error-type>application</error-type>
<error-tag>unknown-element</error-tag>
<error-severity>error</error-severity>
<error-path xmlns:oc-ip="http://openconfig.net/yang/interfaces/ip" xmlns:oc-if="http://openconfig.net/yang/interfaces" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
/nc:rpc/nc:edit-config/nc:config/oc-if:interfaces/oc-if:interface[oc-if:name='GigabitEthernet1']/oc-if:subinterfaces/oc-if:subinterface[oc-if:index='0']/oc-ip:ipv4/oc-ip:addresses/oc-ip:address[oc-ip:ip='10.22.23.22']/oc-ip:config/oc-ip:type
</error-path>
<error-info>
<bad-element>type</bad-element>
</error-info>
</rpc-error>
</rpc-reply>
---- Config_to_iosxr_Device_Deployed_to_C-XR1 ** changed : True ---------------- ERROR
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
<rpc-error>
<error-type>protocol</error-type>
<error-tag>unknown-element</error-tag>
<error-severity>error</error-severity>
<error-message>Unknown element is specified.</error-message>
<error-info>
<bad-element>type</bad-element>
</error-info>
</rpc-error>
</rpc-reply>
^^^^ END INTERFACE_ROUTER_MPLS_CONFIGURATION ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Final Result Summary:
+----------+------------------------------------------------------------+
| Device | Status |
+==========+============================================================+
| C-XR1 | Subtask: Config_to_iosxr_Device_Deployed_to_C-XR1 (failed) |
+----------+------------------------------------------------------------+
| C-XE1 | Subtask: Config_to_iosxe_Device_Deployed_to_C-XE1 (failed) |
+----------+------------------------------------------------------------+
08-21-2024 03:00 PM
@bigevilbeardNow I understand what you meant by being present. So the reason for the preconfigure on the XR9k is because the interface I was testing is not connected to any other device. So, it appears those interfaces are not present and does not even display with show ip interface brief. I connected those interfaces on XR9k and all interfaces works fine.
Many thanks to all for all your support so far.
However, XR 6.3.1 is still not working fine.
interface Loopback0
description System_ID
ipv4 address 10.255.255.22 255.255.255.255 secondary
!
interface GigabitEthernet0/0/0/0
description A1-XR22-A1-XE23
ipv4 address 10.22.23.22 255.255.255.0
!
interface GigabitEthernet0/0/0/1
description A1-XR22-A1-XR21
ipv4 address 10.21.22.22 255.255.255.0 secondary
!
interface GigabitEthernet0/0/0/2
description A1-XR22-C-XR1
ipv4 address 10.1.22.22 255.255.255.0 secondary
08-22-2024 03:13 AM - edited 08-22-2024 03:15 AM
@henry-ezeilo awesome, sorry if i was not clear there with my wording. Where are you stuck now? IMO i have found open-config somewhat of challenge on Cisco and other funky threads in the past, and when i/others switched to Cisco Yang models most of the issues vanished...
08-22-2024 03:43 AM
Thanks @bigevilbeard . I have been able to configure both IOS-XE(CSR1k) and IOS-XRv9k with same template. The pending issue is with that of IOS-XR 6.3.1 which implements the first interface in the loop normally and subsequent interfaces as secondary ip address. The learning point for me in this is that I can actually use same openconfig template to configure both IOS-XE(CSR1k) and IOS-XRv9k.
08-22-2024 04:45 AM
@henry-ezeilo yes this the case i have found in the past with open-config. Which makes me wonder if this is likely due to a platform-specific behavior or limitation in that particular version, you have running, it might be some versions of XR might have different interpretations or support levels for sub-interfaces or secondary IP addresses? (Thats a little guess btw)
Only thing i am thinking now is try to modify your template to explicitly set the primary flag for each interface IP address it might help XR understand that each IP should be the primary address for its respective interface or if that doesn't work, you could try sending separate configuration blocks for each interface, rather than configuring all interfaces in a single operation, again it might help XR treat each interface configuration independently.
Hope this helps.
08-24-2024 06:26 AM
@Marcel Zehnder has already suggested that I should explicitly set the PRIMARY flag but it returns "an unknown element is specified" error.
<ipv4 xmlns="http://openconfig.net/yang/interfaces/ip">
<addresses>
<address>
<ip>{{ iface.ipv4.address }}</ip>
<config>
<ip>{{ iface.ipv4.address }}</ip>
<prefix-length>{{ iface.ipv4.prefix }}</prefix-length>
<type>PRIMARY</type>
</config>
</address>
</addresses>
</ipv4>
08-24-2024 08:04 PM
To me it looks like IOS-XR has implemented a very old revision of the openconfig-interfaces module - if I get it right it's using openconfig-if-ip.yang@2016-05-26 (which contains the data types for openconfig-interfaces). However, the PRIMARY/SECONDARY ip type was introtuced in revision 2023-04-12 (source: https://github.com/openconfig/public/blob/master/release/models/interfaces/openconfig-if-ip.yang
revision "2023-04-12" {
description
"Add ipv4 address type configuration.";
reference "3.3.0";
}
I would recommend to use the native XR models from Cisco in order to configure IOS-XR via NETCONF.
08-27-2024 05:01 AM
@henry-ezeilo its a wild guess, try the primary
attribute instead of the type
element, and set it to True
to indicate that it's the primary address? Its a guess at this stage (thats my coding style!)
<ipv4 xmlns="http://openconfig.net/yang/interfaces/ip">
<addresses>
<address>
<ip>{{ iface.ipv4.address }}</ip>
<config>
<ip>{{ iface.ipv4.address }}</ip>
<prefix-length>{{ iface.ipv4.prefix }}</prefix-length>
<primary>true</primary>
</config>
</address>
</addresses>
</ipv4>
08-27-2024 07:55 AM
Thanks @bigevilbeard , I tried it and it returned below error.
---- Config_to_iosxr_Device_Deployed_to_C-XR1 ** changed : True ---------------- ERROR
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
<rpc-error>
<error-type>protocol</error-type>
<error-tag>unknown-element</error-tag>
<error-severity>error</error-severity>
<error-message>Unknown element is specified.</error-message>
<error-info>
<bad-element>primary</bad-element>
</error-info>
</rpc-error>
</rpc-reply>
^^^^ END INTERFACE_ROUTER_MPLS_CONFIGURATION ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Final Result Summary:
+----------+------------------------------------------------------------+
| Device | Status |
+==========+============================================================+
| C-XR1 | Subtask: Config_to_iosxr_Device_Deployed_to_C-XR1 (failed) |
+----------+------------------------------------------------------------+
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