[j-nsp] Duplicate IP addresses on interfaces

[Sven Juergensen (KielNET)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On that occassion, I ran into something curious myself.
Yesterday I was migrating some portions of the internal
infrastructure, which involved an EX3200-24T and a L3
interface used for routing. So far nothing special, but
after commiting the config on ge-0/0/20, I couldn't for
the heck of it make it forward any traffic, react to
pings or see any arp entries for that interface. Config
snippet as follows:

ge-0/0/20 {
    unit 0 {
        family inet {
            address 10.26.11.49/28;
        }
    }
}

This is from JUNOS 9.1R1.8

The interface was up/up, all physical parameters seemed
in order, but this very interface refused to budge. So
I went ahead, deleted the config and applied it to
ge-0/0/19... As ridiculous as it sounds, there it
worked without any problem. So, well, wtf is going on?

Perhaps only odd interface numbers can have an ip address
assigned to them? ;)

Did any of you encounter something similar? I'm about to
open a Juniper case with this, but I'm sort of reluctant
w/o having much else than my word for this. And yes, it
is reproduceable. No, there isn't any uplink module used
either ;)

Cheers,

sven03


Richard A Steenbergen wrote:
> Once upon a time, Juniper did a sensible thing and didn't let you 
> configure the same IP address on two different interfaces on the same 
> router. Then at some point in the past (the earliest I've noticed it was 
> 8.2, but it could have been earlier), somehow the error check for this 
> condition got changed from a hard error (which prevented the config from 
> committing) to a warning (which still allows the commit to continue).
> 
> I can't find a single legitimate reason for this behavior to exist. It
> doesn't let you use both interfaces simultaniously, it doesn't let you
> pre-stage a circuit move so you can move the link from one port to
> another, and as best as I can tell it either breaks routing on both
> interfaces or at best arbitrarily allows one interface to work while
> breaking all the rest. This is very clearly a problem, which allows a
> simple typo to break routing for an existing interfaces, and yet in the
> past year+ that I've been complaining about this Juniper has claimed
> that it is functioning as designed and that it can't be PR'd.
> 
> At this point, I'm calling bullshit. Unless someone can come up with a 
> legitimate reason for this behavior to exist, which seems highly 
> unlikely, I'm pretty damn sure that this is a bug which needs fixing 
> and I'd like the other users of this list to tell Juniper as much.
> 
> [edit interfaces]
> ras at lab-mx480# show 
> xe-0/1/0 {
>     unit 0 {
>         family inet {
>             address 10.70.70.1/30;
>         }
>     }
> }
> xe-0/3/0 {
>     unit 0 {
>         family inet {
>             address 10.70.70.1/30;
>         }
>     }
> }
> 
> root at lab-mx480# commit check 
> [edit interfaces xe-0/3/0 unit 0 family inet]
>   'address 10.70.70.1/30'
>     warning: identical local address is found on different interfaces
> configuration check succeeds
> 


Mit freundlichen Gruessen

i. A. Sven Juergensen

- --
Fachbereich Netze/Projekte

KielNET GmbH
Gesellschaft fuer Kommunikation
Preusserstr. 1-9, 24105 Kiel

Telefon : 0431 / 2219-053
Telefax : 0431 / 2219-005
E-Mail  : s.juergensen at kielnet.de
Internet: http://www.kielnet.de

Geschaeftsfuehrer Eberhard Schmidt
HRB 4499 (Amtsgericht Kiel)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkjjFIAACgkQnEU7erAt4TIZEQCg1F5qlOfrZ4kS88DYfivTfB0k
6bYAniS/kNccD96UcaJ9voJo4dMIzaVP
=mCki
-----END PGP SIGNATURE-----