[j-nsp] Duplicate IP addresses on interfaces

Richard A Steenbergen ras at e-gerbil.net
Tue Sep 30 17:54:48 EDT 2008


On Tue, Sep 30, 2008 at 01:40:06PM -0700, Harry Reynolds wrote:
> 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:

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.

-- 
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)


More information about the juniper-nsp mailing list