[j-nsp] Duplicate IP addresses on interfaces

[Richard A Steenbergen]

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

[Jared Mauch]

Post by Richard A Steenbergen
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.

I can think of one reason this would be of value. In your example
(removed) both interfaces were enabled. IMHO, this should fail a
commit/commit-check. If one interface is down and the other is up,
this is an acceptable configuration on Cisco.

I do agree this appears to be a problem, if they implemented this as
an enhancement (ie: reason for the change) they should be able to
provide you the ER/Feature documentation, similar to the way cisco can
provide an EDCS document that references why the decision was made.
You can still disagree, but it doesn't quite appear to be as big of a
problem as you suggest.

- Jared

[Eric Van Tol]

Post by Tony Stout
-----Original Message-----
From: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-
bounces at puck.nether.net] On Behalf Of Jared Mauch
Sent: Tuesday, September 30, 2008 1:18 PM
To: Richard A Steenbergen
Cc: juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] Duplicate IP addresses on interfaces
...
If one interface is down and the other is up,
this is an acceptable configuration on Cisco.
...

I have seen where this is not the case. While it is an accepted configuration option, it can break routing and cause similar issues to what Richard is saying happens on Juniper. Sometimes it will forward packets and sometimes it will drop them. It probably depends on the platform and IOS, but I've seen this wacky behavior on 6509s, 3550s, ME3400s, and ME3750s.

I agree that it should not be allowed and should cause a commit failure. When we encounter this, often because a customer is moving offices or T1 LECs, we deactivate the 'family inet' portion of the config. Unfortunately, unless we do a 'commit check' prior to committing, we end up having to commit twice if the warning appears.

-evt

[Richard A Steenbergen]

Post by Jared Mauch
I can think of one reason this would be of value. In your example
(removed) both interfaces were enabled. IMHO, this should fail a
commit/commit-check. If one interface is down and the other is up,
this is an acceptable configuration on Cisco.

Right, you can configure whatever you want on Juniper as long as the
config is inactive. The problem is that it lets you configure the same
IP on two live interfaces, which invariably breaks one or both of them.

Post by Jared Mauch
I do agree this appears to be a problem, if they implemented this as
an enhancement (ie: reason for the change) they should be able to
provide you the ER/Feature documentation, similar to the way cisco can
provide an EDCS document that references why the decision was made.
You can still disagree, but it doesn't quite appear to be as big of a
problem as you suggest.

Wait until you bring down a production interface because you
accidentally configured the same IP twice and nothing prevented it, then
tell me it isn't a problem. There is no legitimate reason for this to be
allowed, and at some point they changed what was a correct and working
behavior into one with no safety net. I for one am tired of outages
caused by this issue, and being told that it isn't actually a problem.

[Jared Mauch]

Post by Richard A Steenbergen

Post by Jared Mauch
I do agree this appears to be a problem, if they implemented this as
an enhancement (ie: reason for the change) they should be able to
provide you the ER/Feature documentation, similar to the way cisco can
provide an EDCS document that references why the decision was made.
You can still disagree, but it doesn't quite appear to be as big of a
problem as you suggest.

Wait until you bring down a production interface because you
accidentally configured the same IP twice and nothing prevented it, then
tell me it isn't a problem. There is no legitimate reason for this to be
allowed, and at some point they changed what was a correct and working
behavior into one with no safety net. I for one am tired of outages
caused by this issue, and being told that it isn't actually a problem.

Our provisioning system prohibits this type of activity
therefore we're unlikely to have an outage as a result. Note I said
that having it and inactive/down should give a warning. I would generally
agree that having both "up" should be a fatal/blocking issue. Any
developer that convinces themselves otherwise has never experienced
the challenges we share in the "real" world.

- jared

[Harry Reynolds]

Perhaps I can clarify a bit.

One, its seems that we specifically do allow duplicate addresses on ptp,
and we claim to reject such configs on multi-access (ethernet). This was
needed specifically because some customers were intentionally using
duplicate IPs on atm interfaces, for whatever reason.

My testing with recent code indicates that in the ethernet case, we are
doing a partial commit, were we ignore the higher numbered ifd with the
duplicate IP, and this is not clear. There is a pr filed for this
(236094) against 8.5. The pr asked for clarity in the commit warn. I
have updated the above pr with these findings, and indicated that:

1. We should not log any warning in cli for ptp (we now are)
2. That warning for multipoint should be clear that a partial commit
fail did occur.

HTHs



<<< This is what we should do:


Per RLI 1203, Duplicate address is checked at 2 levels:

0. duplicate address is checked per ifd first:
. if ifd is p2p , warning message is syslog'ed.
. if ifd is multi-point, commit fail error is generated.

1. duplicate address detection then to be done for all interfaces:
. warning message will be displayed at cli and syslog.
. for multi-point interface, only the first IFA is installed, the
rest
of the duplicate addresses will be ignored.
. for p2p interface, all IFAs will be installed.

<<< My test shows that with ether, we log a warning and only honor the
lowest numbered IFD's ip:

[edit interfaces]
regress at vpn04# run show version
Hostname: vpn04
Model: m40
JUNOS Base OS boot [9.3B3.1]


[edit interfaces]
regress at vpn04# show
fe-5/2/0 {
fastether-options {
loopback;
}
unit 0 {
family inet {
address 200.0.0.1/24;
}
}
}
fe-5/2/1 {
fastether-options {
loopback;
}
unit 0 {
family inet {
address 200.0.0.1/24;
}
}
}

[edit interfaces]
regress at vpn04# commit
[edit interfaces fe-5/2/1 unit 0 family inet]
'address 200.0.0.1/24'
warning: identical local address is found on different interfaces
commit complete

[edit interfaces]
regress at vpn04# run show interfaces terse fe-5/2/1
Interface Admin Link Proto Local Remote
fe-5/2/1 up up
fe-5/2/1.0 up up inet

[edit interfaces]
regress at vpn04# run show interfaces terse fe-5/2/0
Interface Admin Link Proto Local Remote
fe-5/2/0 up up
fe-5/2/0.0 up up inet 200.0.0.1/24

[edit interfaces]
regress at vpn04# deactivate fe-5/2/0

[edit interfaces]
regress at vpn04# commit
commit complete

[edit interfaces]
regress at vpn04# run show interfaces terse fe-5/2/1
Interface Admin Link Proto Local Remote
fe-5/2/1 up up
fe-5/2/1.0 up up inet 200.0.0.1/24



<< I ran same test on sonet. While I still see the commit error, both
ifds are programed with the same IP:

es-5/3/0 up up
ge-6/0/0 up up
so-6/1/0 up up
so-6/1/0.0 up up inet 200.0.0.1/24
so-6/1/1 up up
so-6/1/1.0 up up inet 200.0.0.1/24
so-6/1/2 up up



-----Original Message-----
From: juniper-nsp-bounces at puck.nether.net
[mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Richard A
Steenbergen
Sent: Tuesday, September 30, 2008 10:39 AM
To: Jared Mauch
Cc: juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] Duplicate IP addresses on interfaces

Post by Jared Mauch
I can think of one reason this would be of value. In your

example

Post by Jared Mauch
(removed) both interfaces were enabled. IMHO, this should fail a
commit/commit-check. If one interface is down and the other is up,
this is an acceptable configuration on Cisco.

Right, you can configure whatever you want on Juniper as long as the
config is inactive. The problem is that it lets you configure the same
IP on two live interfaces, which invariably breaks one or both of them.

Post by Jared Mauch
I do agree this appears to be a problem, if they implemented

this as

Post by Jared Mauch
an enhancement (ie: reason for the change) they should be able to
provide you the ER/Feature documentation, similar to the way cisco can
provide an EDCS document that references why the decision was made.
You can still disagree, but it doesn't quite appear to be as big of a
problem as you suggest.

Wait until you bring down a production interface because you
accidentally configured the same IP twice and nothing prevented it, then
tell me it isn't a problem. There is no legitimate reason for this to be
allowed, and at some point they changed what was a correct and working
behavior into one with no safety net. I for one am tired of outages
caused by this issue, and being told that it isn't actually a problem.

[Richard A Steenbergen]

Post by Harry Reynolds
My testing with recent code indicates that in the ethernet case, we are
doing a partial commit, were we ignore the higher numbered ifd with the
duplicate IP, and this is not clear. There is a pr filed for this
(236094) against 8.5. The pr asked for clarity in the commit warn. I

Ok I'll admit I haven't fully tested the failure mode for configuring
duplicate IPs in recent code (last time I tried this was 8.2), but I
swear that at the time it was a higher ifd that got added which broke
the lower ifd. Actually I think it also generated a big pile of pfe
errors too, but that could have been something entirely unrelated. It's
been too long and I don't remember for sure, so I'll take your word for
it.

At any rate, my argument is specifically against the case where only one
ip/interface can function at a time. What people do with their atm
configurations isn't my business, as long as it works for them, but
clearly in the case where it isn't possible to use the IP in two places
simultaniously it shouldn't be configurable (no matter how deterministic
the failure is :P).

By the point you've warned the user that only a partial commit occured
and that one of their configured interfaces won't be working it is
already too late, since they could just as easily have unknowingly
configured the duplicate IP on a lower ifd. The user shouldn't have to
know that only the lowest numbered ifd will function, that kind of
madness belongs in Foundry release notes not JUNOS. To allow a partial
commit where what is configured doesn't reflect reality goes against the
fundamentals of the Juniper commit process. Plus, since this still
doesn't allow the one possible use case on Ethernet (preconfiguring an
interface so someone can move and cable and have it work in the new
location), there isn't even any value in allowing such a bad thing to
occur.

[Harry Reynolds]

Well, I cannot comment farther on the merits. Proves you cannot please
all, all the time. I know folks get really mad when we break a
previously working config, which is why we (had) to allow on a ptp.

That said, I could not find any clear documentation as to how we handle
this, and was a bit surprised by the partial commit business. So, I have
raised doc-cmd/390788 to at least get the behavior documented.

Thanks

[Tony Stout]

Could this be useful in a situation where you have two links connected to
the same downstream device with Spanning Tree running to handle link failure
(active/passive). That way, if the primary link fails, the standby link
will be configured with the same address once it becomes the active link?

-----Original Message-----
From: juniper-nsp-bounces at puck.nether.net
[mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Richard A
Steenbergen
Sent: Tuesday, September 30, 2008 12:58 PM
To: juniper-nsp at puck.nether.net
Subject: [j-nsp] Duplicate IP addresses on interfaces

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.

[Jared Mauch]

Post by Tony Stout
Could this be useful in a situation where you have two links connected to
the same downstream device with Spanning Tree running to handle link failure
(active/passive). That way, if the primary link fails, the standby link
will be configured with the same address once it becomes the active link?

No.

You want HSRP/VRRP for those situations.

The challenges of who responds to an ARP request and these
other layer-2 activities makes this not an ideal avenue.

[Chris Adams]

Post by Richard A Steenbergen
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

It does for circuits that have valid link-state (i.e. not ethernet).
For example, we've had a T1 customer move to a new location, which
requires ordering a new local loop. We copy the provisioning from the
old loop to the new loop, and when the customer moves, they unplug their
CPE from the old loop, drive to the new location, and plug into the new
loop, and it just works.

[Daniel Roesen]

Post by Chris Adams
It does for circuits that have valid link-state (i.e. not ethernet).
For example, we've had a T1 customer move to a new location, which
requires ordering a new local loop. We copy the provisioning from the
old loop to the new loop, and when the customer moves, they unplug their
CPE from the old loop, drive to the new location, and plug into the new
loop, and it just works.

This works fine as long as the "local" route generated for the interface
IP address doesn't pose a problem for you.

I wonder why Juniper still generates this route even when an interface
(unit) is logically down... the ingenuity of that escapes me... anyone
could clue me in?

Best regards,
Daniel

[Sven Juergensen (KielNET)]

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

Post by Richard A Steenbergen
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)