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

[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" <randy_94108 at yahoo.com> wrote:

     From: Christoffer Hansen <cdh at nianet.dk>
     To: "cisco-nsp at puck.nether.net" <cisco-nsp at 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.