[j-nsp] EX4500 SFP+ laser lit when interface is admin down and vice versa

[Jed Laundry]

Hi Tore,

I haven't seen this particular issue, and I'm not sure about the EX4500,
but on a EX4550 you can:

> start shell user root

% lcdd 0 chassism

chassism<0>#xcvr enable ge-0/0/30
devNum:0, portNum:49

HERE BE DRAGONS: any errors/warnings in chassism (i.e., finger fudges) will
cause the device to kernel panic and reboot... Been there, done that...

Thanks,
Jed.



On 6 March 2015 at 23:13, Tore Anderson <tore at fud.no> wrote:

> Hi,
>
> I've got an EX4500 running 12.3R8.7 that has a port that's misbehaving
> in a rather odd way: If I disable the interface in the config and
> commit, the laser is turned on (normal Tx levels in show interfaces
> diagnostics optics). If I re-enable the interface and commit, the laser
> is switched off (Tx level of -Inf dBm). So it's doing precisely the
> opposite of what I'd expect it to.
>
> When I commit the configuration that enables the interface, the
> following message is logged:
>
> chassism[1405]: Tx Disable called for port: 0, enable: 0
>
> I've tried multiple SFP+ modules and they all behave the same. Also
> I've tried re-seating the SFP+ with as many different combinations of
> the interface being disabled/enabled when I remove/insert the module as
> I could think of, no luck. Finally it's only impacting port 0, e.g.,
> port 4 works as expected (i.e., Tx off when interface is disabled and
> on when enabled) - even with the very same module that don't work right
> when inserted in port 0.
>
> Anyone seen anything like that? I'm hoping to find a way fix it without
> needing a maintenance window to reboot it.
>
> Tore
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>