On Sep 30, 2008, at 12:57 PM, Richard A Steenbergen wrote:
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
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
