[j-nsp] auto-negotiation on 1000BASE-X ports
m4rtntns at gmail.com
Wed May 15 06:23:25 EDT 2013
I thought that "auto-negotiation remote-fault local-interface-online"
translates to "keep the local interface online despite the fact that
remote-fault detection, which is part of the autonegotiation, has
detected that link is unidirectional". If I connect both optical
cables, enable auto-negotiation and set the remote fault either
"Online" or "Offline", then both ports are still up:
Either it's not working or I am doing it wrong..
2013/5/14, Olivier Benghozi <olivier.benghozi at wifirst.fr>:
> Hi Martin,
>> by flow control you mean the 'regular' Ethernet flow control using the
>> PAUSE frame mechanism?
> Yes: the peers can negotiate its use, and in what direction.
> In that case, such explicit flow control replaces the old school "Back
> pressure" mechanism (a switch can send a fake ethernet collision signal if
> it wants to slow down what it receives).
>> I wasn't aware that remote fault detection is part of the
>> autonegotiation. Thanks! I tested this out with two directly connected
>> Juniper M series routers and it works exactly as you described.
>> However, as I understand, JUNOS allows to enable auto-negotiation
>> while at the same keep the local interface online despite the fact
>> that link is unidirectional. I mean the [ auto-negotiation
>> remote-fault local-interface-online ] and [ auto-negotiation
>> remote-fault local-interface-offline ] options. For some reason, this
>> did not work:
>> As you can see, both in case "Remote fault" "Online" or "Offline", the
>> local interfaces go down if link becomes unidirectional. Any comments
>> on this behavior?
> From what I understand from the very-poorly-written-by-alien-monkeys Juniper
> documentation (
> ), pages 330 & more...
> Well, I don't understand what they meant in this piece of crap, obviously
> not expected to be ever read. The most funny is when a little * points to
> just nothing, in their crappy doc.
> However in
> , I understand that this might be designed to locally simulate a
> remote-fault received from the other peer, which would be really useless. Or
> in fact, maybe to send a remote-fault signal to the other peer, which could
> be more useful. Or not.
> Is this consistent with your tests?
> Anyway, it doesn't look like it's expected to allow an unidir link with
> autoneg activated (which by nature needs both speakers to be able to
> communicate together, so it makes sense to me).
More information about the juniper-nsp