[j-nsp] Duplicate IP addresses on interfaces
Harry Reynolds
harry at juniper.net
Tue Sep 30 16:40:06 EDT 2008
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
On Tue, Sep 30, 2008 at 01:18:25PM -0400, Jared Mauch wrote:
>
> 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.
> 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.
--
Richard A Steenbergen <ras at e-gerbil.net>
http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1
2CBC) _______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
More information about the juniper-nsp
mailing list