[c-nsp] IOS-XR accepted duplicate subnet configurations for interface

[Christoffer Hansen]

Dear c-nsp fellows,

I am not sure if any one of you would have an answer the the below
example...

I have recently run into a case with an ASR9k router running IOS-XR
v5.3.4. Were I by accident put an identical secondary subnet on a 2nd
interface located inside the same VRF as the first one. It is even a 2nd
sub-interface to another sub-interface on the same main interface.

Case-in-point: The router accepted the configuration commit without
complaints and of course traffic then stops flowing.

Normally I would not expect this to be possible to do. And would expect
the router to output a warning telling me I am trying to commit an IPv4
address|subnet already configured on another interface in the same VRF.


Q: Would you expect
(1) a warning in my scenario or
(2) the router just accepting the staged configuration change upon commit?


```iosxr
!!! 1st-subinterface
!
interface GigabitEthernet666/0/0/2.1478 !!nvSatellite interface
vrf ROUTING-INSTANCE-INTERNET
ipv4 mtu 1500
ipv4 address 198.51.100.1 255.255.255.252
ipv4 address 203.0.113.1 255.255.255.252 secondary
ipv4 verify unicast source reachable-via any allow-default
encapsulation dot1q 1478
!

!!! 2nd sub-interface
!
interface GigabitEthernet666/0/0/2.665 !!nvSatellite interface
vrf ROUTING-INSTANCE-INTERNET
ipv4 mtu 1500
ipv4 address 192.0.2.1 255.255.255.252
ipv4 address 203.0.113.1 255.255.255.252 secondary !!committed line
ipv4 verify unicast source reachable-via any allow-default
encapsulation dot1q 665
!
```

-Christoffer

[Randy via cisco-nsp]

From: Christoffer Hansen <***@nianet.dk>
To: "cisco-***@puck.nether.net" <cisco-***@puck.nether.net>
Sent: Wednesday, September 26, 2018 2:48 PM
Subject: [c-nsp] IOS-XR accepted duplicate subnet configurations for interface



Dear c-nsp fellows,

I am not sure if any one of you would have an answer the the below
example...

I have recently run into a case with an ASR9k router running IOS-XR
v5.3.4. Were I by accident put an identical secondary subnet on a 2nd
interface located inside the same VRF as the first one. It is even a 2nd
sub-interface to another sub-interface on the same main interface.

Case-in-point: The router accepted the configuration commit without
complaints and of course traffic then stops flowing.

Normally I would not expect this to be possible to do. And would expect
the router to output a warning telling me I am trying to commit an IPv4
address|subnet already configured on another interface in the same VRF.


Q: Would you expect
(1) a warning in my scenario or
(2) the router just accepting the staged configuration change upon commit?


```iosxr
!!! 1st-subinterface
!
interface GigabitEthernet666/0/0/2.1478 !!nvSatellite interface
vrf ROUTING-INSTANCE-INTERNET
ipv4 mtu 1500
ipv4 address 198.51.100.1 255.255.255.252
ipv4 address 203.0.113.1 255.255.255.252 secondary
ipv4 verify unicast source reachable-via any allow-default
encapsulation dot1q 1478
!

!!! 2nd sub-interface
!
interface GigabitEthernet666/0/0/2.665 !!nvSatellite interface
vrf ROUTING-INSTANCE-INTERNET
ipv4 mtu 1500
ipv4 address 192.0.2.1 255.255.255.252
ipv4 address 203.0.113.1 255.255.255.252 secondary !!committed line
ipv4 verify unicast source reachable-via any allow-default
encapsulation dot1q 665
!
```

-Christoffer

---------------------------------------------------------------------------------------------------------------------------------------------------------------------Hi,It is a case of "missing a few check&balances. Happens! I have seen worse!A call to the TAC will help by the way of a bug-report/fix../Randy

[Martin Mehaffy]

I'd expect the commit to fail in that scenario. I'd log a TAC case and see what Cisco says.


On 27/09/18, 10:15, "Randy" <***@yahoo.com> wrote:

From: Christoffer Hansen <***@nianet.dk>
To: "cisco-***@puck.nether.net" <cisco-***@puck.nether.net>
Sent: Wednesday, September 26, 2018 2:48 PM
Subject: [c-nsp] IOS-XR accepted duplicate subnet configurations for interface



Dear c-nsp fellows,

I am not sure if any one of you would have an answer the the below
example...

I have recently run into a case with an ASR9k router running IOS-XR
v5.3.4. Were I by accident put an identical secondary subnet on a 2nd
interface located inside the same VRF as the first one. It is even a 2nd
sub-interface to another sub-interface on the same main interface.

Case-in-point: The router accepted the configuration commit without
complaints and of course traffic then stops flowing.

Normally I would not expect this to be possible to do. And would expect
the router to output a warning telling me I am trying to commit an IPv4
address|subnet already configured on another interface in the same VRF.


Q: Would you expect
(1) a warning in my scenario or
(2) the router just accepting the staged configuration change upon commit?


```iosxr
!!! 1st-subinterface
!
interface GigabitEthernet666/0/0/2.1478 !!nvSatellite interface
vrf ROUTING-INSTANCE-INTERNET
ipv4 mtu 1500
ipv4 address 198.51.100.1 255.255.255.252
ipv4 address 203.0.113.1 255.255.255.252 secondary
ipv4 verify unicast source reachable-via any allow-default
encapsulation dot1q 1478
!

!!! 2nd sub-interface
!
interface GigabitEthernet666/0/0/2.665 !!nvSatellite interface
vrf ROUTING-INSTANCE-INTERNET
ipv4 mtu 1500
ipv4 address 192.0.2.1 255.255.255.252
ipv4 address 203.0.113.1 255.255.255.252 secondary !!committed line
ipv4 verify unicast source reachable-via any allow-default
encapsulation dot1q 665
!
```

-Christoffer

---------------------------------------------------------------------------------------------------------------------------------------------------------------------Hi,It is a case of "missing a few check&balances. Happens! I have seen worse!A call to the TAC will help by the way of a bug-report/fix../Randy







This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Contract and Commercial Law Act 2017.

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp

[Rimestad, Steinar]

Hi.

As long as the l2 encapsulation is different the syntax is allowed even without vrf and as primary addresses.

You get a warning in the syslog and one of the addresses with the duplicate config is forced down.

Sep 27 09:13:09.372 : ipv4_arm[292]: %IP-IP_ARM-3-CFLCT_FORCED_DOWN : The IPv4 address 10.11.12.1/31 on Bundle-Ether100.2177 conflicts with other IPv4 addresses and has been forced down

You can check for any conflicts using "show arm conflicts".

/Steinar


On 27/09/2018, 00:21, "cisco-nsp on behalf of Martin Mehaffy" <cisco-nsp-***@puck.nether.net on behalf of ***@sparkventures.co.nz> wrote:

I'd expect the commit to fail in that scenario. I'd log a TAC case and see what Cisco says.


On 27/09/18, 10:15, "Randy" <***@yahoo.com> wrote:

From: Christoffer Hansen <***@nianet.dk>
To: "cisco-***@puck.nether.net" <cisco-***@puck.nether.net>
Sent: Wednesday, September 26, 2018 2:48 PM
Subject: [c-nsp] IOS-XR accepted duplicate subnet configurations for interface



Dear c-nsp fellows,

I am not sure if any one of you would have an answer the the below
example...

I have recently run into a case with an ASR9k router running IOS-XR
v5.3.4. Were I by accident put an identical secondary subnet on a 2nd
interface located inside the same VRF as the first one. It is even a 2nd
sub-interface to another sub-interface on the same main interface.

Case-in-point: The router accepted the configuration commit without
complaints and of course traffic then stops flowing.

Normally I would not expect this to be possible to do. And would expect
the router to output a warning telling me I am trying to commit an IPv4
address|subnet already configured on another interface in the same VRF.


Q: Would you expect
(1) a warning in my scenario or
(2) the router just accepting the staged configuration change upon commit?


```iosxr
!!! 1st-subinterface
!
interface GigabitEthernet666/0/0/2.1478 !!nvSatellite interface
vrf ROUTING-INSTANCE-INTERNET
ipv4 mtu 1500
ipv4 address 198.51.100.1 255.255.255.252
ipv4 address 203.0.113.1 255.255.255.252 secondary
ipv4 verify unicast source reachable-via any allow-default
encapsulation dot1q 1478
!

!!! 2nd sub-interface
!
interface GigabitEthernet666/0/0/2.665 !!nvSatellite interface
vrf ROUTING-INSTANCE-INTERNET
ipv4 mtu 1500
ipv4 address 192.0.2.1 255.255.255.252
ipv4 address 203.0.113.1 255.255.255.252 secondary !!committed line
ipv4 verify unicast source reachable-via any allow-default
encapsulation dot1q 665
!
```

-Christoffer

---------------------------------------------------------------------------------------------------------------------------------------------------------------------Hi,It is a case of "missing a few check&balances. Happens! I have seen worse!A call to the TAC will help by the way of a bug-report/fix../Randy







This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Contract and Commercial Law Act 2017.

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-nsp&amp;data=02%7C01%7Csteinar.rimestad%40altibox.no%7C81eb556bf547402e57cc08d623fe7412%7C22ca942f06c24f3894070e447dedbb67%7C0%7C0%7C636735973128509957&amp;sdata=R1INWmXt0SGsaIykG8Tb3PottJ329Zw3T0gORnaVos0%3D&amp;reserved=0
archive at https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpuck.nether.net%2Fpipermail%2Fcisco-nsp%2F&amp;data=02%7C01%7Csteinar.rimestad%40altibox.no%7C81eb556bf547402e57cc08d623fe7412%7C22ca942f06c24f3894070e447dedbb67%7C0%7C0%7C636735973128509957&amp;sdata=ORUEUdozlZtt5JlO28ezi1P1LioQDP71DZytu0lMQaQ%3D&amp;reserved=0


_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net

[Saku Ytti]

On Thu, 27 Sep 2018 at 10:24, Rimestad, Steinar

Post by Rimestad, Steinar
As long as the l2 encapsulation is different the syntax is allowed even without vrf and as primary addresses.
You get a warning in the syslog and one of the addresses with the duplicate config is forced down.
Sep 27 09:13:09.372 : ipv4_arm[292]: %IP-IP_ARM-3-CFLCT_FORCED_DOWN : The IPv4 address 10.11.12.1/31 on Bundle-Ether100.2177 conflicts with other IPv4 addresses and has been forced down
You can check for any conflicts using "show arm conflicts".

Just as side note there is DDTS where if you have say loop0 multiple
times, and you delete some of those, the loop0 may disappear from ARM
database entirely. Luckily impact isn't catastrophic, mostly just SNMP
issues and can be recovered runtime without inteerruption by
restarting ARM database.

But perhaps better not to have same IP multiple times, there be
dragons in corner cases.

[Nikolai Nespor]

Christoffer Hansen <***@nianet.dk> writes:

Hi,

Post by Christoffer Hansen
I have recently run into a case with an ASR9k router running IOS-XR
v5.3.4. Were I by accident put an identical secondary subnet on a 2nd
interface located inside the same VRF as the first one. It is even a 2nd
sub-interface to another sub-interface on the same main interface.
Case-in-point: The router accepted the configuration commit without
complaints and of course traffic then stops flowing.

AFAIK, this is the standard behavior for IOS-XR.

Post by Christoffer Hansen
Normally I would not expect this to be possible to do. And would expect
the router to output a warning telling me I am trying to commit an IPv4
address|subnet already configured on another interface in the same VRF.

A warning should have been logged by the router. Please check the logs
for an entry containing:

%IP-IP_ARM-3-CFLCT_FORCED_DOWN

Regards,

Nikolai

[a***@netconsultings.com]

Post by Randy via cisco-nsp
Christoffer Hansen
Sent: Wednesday, September 26, 2018 10:47 PM
Dear c-nsp fellows,
I am not sure if any one of you would have an answer the the below
example...
I have recently run into a case with an ASR9k router running IOS-XR v5.3.4.
Were I by accident put an identical secondary subnet on a 2nd interface
located inside the same VRF as the first one. It is even a 2nd sub-interface to
another sub-interface on the same main interface.
Case-in-point: The router accepted the configuration commit without
complaints and of course traffic then stops flowing.
Normally I would not expect this to be possible to do. And would expect the
router to output a warning telling me I am trying to commit an IPv4
address|subnet already configured on another interface in the same VRF.

Hi,

Yes this is an unfortunate default in XR,
Hence you might want to configure the correct behaviour using:
ipv4 conflict-policy static
ipv6 conflict-policy static

adam

netconsultings.com
::carrier-class solutions for the telecommunications industry::


_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/