Re: [j-nsp] How to shut down laser on any optics
On MPC7 can you please try test cmic fpc shell command? On Wed, Jun 24, 2020 at 12:37 PM Pierre Emeriaud wrote: > Le mer. 24 juin 2020 à 21:29, Olivier Benghozi > a écrit : > > > > This being said, we didn't experience this neither with Skylane nor > Cubeoptics transceivers (currently on MPC7-MRATE / 18.4R[2-3]-[S*]). It > «just works» as we expect (laser is switched off when the channel is > disabled in the config). I would only expect to see another behaviour from > some buggy/cheap/crappy network gears, whatever how lite the official > specifications are, and therefore see this issue as a bug in a Juniper case. > > I'll open a case on this then, as this works for most of you, and > given the price of a current Juniper qsfp pluggable, one could expect > that it has all fancy optional features :) > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] How to shut down laser on any optics
Le mer. 24 juin 2020 à 21:29, Olivier Benghozi a écrit : > > This being said, we didn't experience this neither with Skylane nor > Cubeoptics transceivers (currently on MPC7-MRATE / 18.4R[2-3]-[S*]). It «just > works» as we expect (laser is switched off when the channel is disabled in > the config). I would only expect to see another behaviour from some > buggy/cheap/crappy network gears, whatever how lite the official > specifications are, and therefore see this issue as a bug in a Juniper case. I'll open a case on this then, as this works for most of you, and given the price of a current Juniper qsfp pluggable, one could expect that it has all fancy optional features :) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] How to shut down laser on any optics
Le mer. 24 juin 2020 à 18:59, Jared Mauch a écrit : > > > > Many of the optics don’t have a way to disable the laser except via custom > > commands over the i2c. Last I read the SFF MSA there wasn’t a good way to > > do this, and it wasn’t required. > > Correction (somewhat) > > It’s not required for the hardware to implement this. There is a pin as well > as bit you can set via i2c to (maybe) disable things: > > - relevant part of MSA - > 8.10 > > Enhanced Options [Address A0h, Byte 93] > > The Enhanced Options are a one byte field with 8 single bit indicators which > describe the optional digital diagnostic features implemented in the > transceiver. Since transceivers will not necessarily implement all optional > features described in this document, this field allows the host system to > determine which functions are available over the two-wire serial bus. A '1' > indicates that the particular function is implemented in the transceiver. > Bits 3 and 6 of byte 110 (see Table 9-11) allow the user to control the > Rate_Select and TX_Disable functions. If these functions are not implemented, > the bits remain readable and writable, but the transceiver ignores them. > - snip - > > They would either need to have the GPIO wired for this pin on the PCBs and/or > implement disable sets this bit AND the optic would need to honor it. Thanks Jared. So even with Juniper branded optics, same P/N, I guess not all optics come from the same OEM, hence the "disable" stanza working, or not. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] How to shut down laser on any optics
This would prove once again that vendor_endorsed_and_overcharged optics are just a useless scam. This being said, we didn't experience this neither with Skylane nor Cubeoptics transceivers (currently on MPC7-MRATE / 18.4R[2-3]-[S*]). It «just works» as we expect (laser is switched off when the channel is disabled in the config). I would only expect to see another behaviour from some buggy/cheap/crappy network gears, whatever how lite the official specifications are, and therefore see this issue as a bug in a Juniper case. Example of 2 different channels of a QSFP+ PLR4 (MTP): Physical interface: xe-3/1/1:0 (disabled) Lane 0 Laser bias current: 0.000 mA Laser output power: 0.000 mW / -40.04 dBm Tx laser disabled alarm : On Physical interface: xe-3/1/1:1 (in use) Lane 1 Laser bias current: 32.453 mA Laser output power: 0.501 mW / -3.00 dBm Tx laser disabled alarm : Off [...] > Le 24 juin 2020 à 18:59, Jared Mauch a écrit : > > They would either need to have the GPIO wired for this pin on the PCBs and/or > implement disable sets this bit AND the optic would need to honor it. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] How to shut down laser on any optics
> On Jun 24, 2020, at 12:51 PM, Jared Mauch wrote: > > > >> On Jun 24, 2020, at 10:50 AM, Pierre Emeriaud wrote: >> >> Howdy >> >> I'm trying to shut down the laser from my optics from the junos cli in >> order to ease troubleshooting. On MXes 240/480/960, mostly 17.4R2. >> >> 'set interface ge- disable' works *sometimes* on mpc2e with an >> sfp, or on mpc2 with xfp, but fails (laser still emits) on some other >> mpc2 with xfp too, and didn't find it working on mpc2e and mpc7e with >> xfp and qsfp optics. >> >> I know I can use 'test xfp laser off' from fpc shell, but >> not only this doesn't seem to work on anything besides xfp, it also >> requires shell access which I can't provide to everyone needing >> port-level privileges. >> >> All juniper genuine optics, with the same P/N between working and >> non-working ones. >> >> - would you consider the 'disable' not working as (I) expected a bug? >> - is there some other magic cli command that would achieve what i'm after? > > > Many of the optics don’t have a way to disable the laser except via custom > commands over the i2c. Last I read the SFF MSA there wasn’t a good way to do > this, and it wasn’t required. Correction (somewhat) It’s not required for the hardware to implement this. There is a pin as well as bit you can set via i2c to (maybe) disable things: - relevant part of MSA - 8.10 Enhanced Options [Address A0h, Byte 93] The Enhanced Options are a one byte field with 8 single bit indicators which describe the optional digital diagnostic features implemented in the transceiver. Since transceivers will not necessarily implement all optional features described in this document, this field allows the host system to determine which functions are available over the two-wire serial bus. A '1' indicates that the particular function is implemented in the transceiver. Bits 3 and 6 of byte 110 (see Table 9-11) allow the user to control the Rate_Select and TX_Disable functions. If these functions are not implemented, the bits remain readable and writable, but the transceiver ignores them. - snip - They would either need to have the GPIO wired for this pin on the PCBs and/or implement disable sets this bit AND the optic would need to honor it. - Jared ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] How to shut down laser on any optics
> On Jun 24, 2020, at 10:50 AM, Pierre Emeriaud wrote: > > Howdy > > I'm trying to shut down the laser from my optics from the junos cli in > order to ease troubleshooting. On MXes 240/480/960, mostly 17.4R2. > > 'set interface ge- disable' works *sometimes* on mpc2e with an > sfp, or on mpc2 with xfp, but fails (laser still emits) on some other > mpc2 with xfp too, and didn't find it working on mpc2e and mpc7e with > xfp and qsfp optics. > > I know I can use 'test xfp laser off' from fpc shell, but > not only this doesn't seem to work on anything besides xfp, it also > requires shell access which I can't provide to everyone needing > port-level privileges. > > All juniper genuine optics, with the same P/N between working and > non-working ones. > > - would you consider the 'disable' not working as (I) expected a bug? > - is there some other magic cli command that would achieve what i'm after? Many of the optics don’t have a way to disable the laser except via custom commands over the i2c. Last I read the SFF MSA there wasn’t a good way to do this, and it wasn’t required. - Jared ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] How to shut down laser on any optics
Howdy I'm trying to shut down the laser from my optics from the junos cli in order to ease troubleshooting. On MXes 240/480/960, mostly 17.4R2. 'set interface ge- disable' works *sometimes* on mpc2e with an sfp, or on mpc2 with xfp, but fails (laser still emits) on some other mpc2 with xfp too, and didn't find it working on mpc2e and mpc7e with xfp and qsfp optics. I know I can use 'test xfp laser off' from fpc shell, but not only this doesn't seem to work on anything besides xfp, it also requires shell access which I can't provide to everyone needing port-level privileges. All juniper genuine optics, with the same P/N between working and non-working ones. - would you consider the 'disable' not working as (I) expected a bug? - is there some other magic cli command that would achieve what i'm after? thanks in advance pierre ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ipfix is not accounting next-ip firewall actions properly
Hi, On 24.06.2020 12:28, Marcel Bößendörfer wrote: *Issue: *However, IPFIX is not considering the next-ip, instead it's acting like the next-ip would not exist at all. That means, traffic from 192.168.0.2 is reported to be egressing multiple interfaces like the router would handle it without the next-ip rule. So it seems that the sampling is taking place before the firewall rule is applied. This is a very unexpected behaviour. In reality traffic from that source IP is only egressing the interface that's related to 192.168.1.1. I have seen things like this with Flow Export on MX before. In my case it was filter based forwarding towards a different RI with different interfaces for TE purposes. In that case the flow export would match the "Original" destination before the FBF took place which lead to wrong flow statistics on $collector. This was years ago and i never checked back on that, seems like the behavior is still there. I kind of remember it happening for flow-spec drop/rate-loimit routes/filters as well. So Flow would still report the traffic ingressing the interfaces while the filters were already blocking them. Which in the Case of flow-Spec was a good thing, because you could keep the announcement active as long as the attack lasted. -- Kind Regards Tobias Heister ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] ipfix is not accounting next-ip firewall actions properly
Hi,
Following simple scenario:
The firewall rule is on *input* of the interface where the traffic from the
source address is coming from:
term force-next-hop {
from {
source-address {
192.168.0.2/32;
}
}
then {
next-ip 192.168.1.1/32;
}
}
term accept {
then accept;
}
The router is multi homed to various ISPs via eBGP full table.
The firewall filter is working very well. All of the traffic from
192.168.0.2 is "nexted" to 192.168.1.1.
*Issue: *However, IPFIX is not considering the next-ip, instead it's acting
like the next-ip would not exist at all. That means, traffic from
192.168.0.2 is reported to be egressing multiple interfaces like the router
would handle it without the next-ip rule. So it seems that the sampling is
taking place before the firewall rule is applied. This is a very unexpected
behaviour. In reality traffic from that source IP is only egressing the
interface that's related to 192.168.1.1.
Currently, sampling is enabled on each interface (*family inet/inet6
sampling input+output*). We've already tried to sample via the firewall
action *sample* instead of the sampling statement *after* the next-ip term.
This did not change anything.
We assume this is a JunOS bug, but maybe we're doing something wrong here
(I cannot imagine but you never know).
HW/SW: MX204 / JunOS 18.3R2-S3.1
Also confirmed with MX480 / 17.3R3-S7.2 / MPC 3D 16x 10GE
More configuration details:
set chassis fpc 0 sampling-instance SAMPLER1
set chassis fpc 0 inline-services flow-table-size ipv4-flow-table-size 10
set chassis fpc 0 inline-services flow-table-size ipv6-flow-table-size 5
set forwarding-options sampling instance SAMPLER1 input rate 1024
set forwarding-options sampling instance SAMPLER1 family inet output
flow-server x.x.x.x port 2055
set forwarding-options sampling instance SAMPLER1 family inet output
flow-server x.x.x.x autonomous-system-type origin
set forwarding-options sampling instance SAMPLER1 family inet output
flow-server x.x.x.x version-ipfix template TEMPLATEv4
set forwarding-options sampling instance SAMPLER1 family inet output
inline-jflow source-address x.x.x.x
set forwarding-options sampling instance SAMPLER1 family inet output
inline-jflow flow-export-rate 400
set forwarding-options sampling instance SAMPLER1 family inet6 output
flow-server x.x.x.x port 2055
set forwarding-options sampling instance SAMPLER1 family inet6 output
flow-server x.x.x.x version-ipfix template TEMPLATEv6
set forwarding-options sampling instance SAMPLER1 family inet6 output
inline-jflow source-address x.x.x.x
set forwarding-options sampling instance SAMPLER1 family inet6 output
inline-jflow flow-export-rate 100
set interfaces ae0 unit 82 family inet sampling input
set interfaces ae0 unit 82 family inet sampling output
set interfaces ae0 unit 82 family inet6 sampling input
set interfaces ae0 unit 82 family inet6 sampling output
[...for every interface...]
Any help is highly appreciated.
Thanks,
Marcel
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] vrf auto-export rib-group
> Mihai > Sent: Tuesday, June 23, 2020 12:39 PM > > Hi, > > Is the rib-group configured under VRF auto-export supposed to be a 'per- > table' (instead of per-protocol) rib-group which can also export routes from > VRFs to non-VRF instances, default included? > The example on the link below shows the export to another table within the > same instance: > > https://www.juniper.net/documentation/en_US/junos/topics/example/poli > cy-duplicating-routes.html > > I already tested and confirmed that routes from VRFs can be leaked to > inet.0 by just using the rib-group under auto-export but I am not sure > whether this is officially supported. > Maybe Jeff could chime in and shed some light on the peculiar differences of using rib-groups under auto-export versus the below which I'm sure is supported: And how this all changes if the feature to have BGP not restart itself/to always use l3vpn table for import export (can't recall name just now) is enabled. Could really use a "How BGP Works in Junos - Day One Book" set routing-options rib-groups V4_INTERNET_TO_INET0 import-rib INTERNET.inet.0 set routing-options rib-groups V4_INTERNET_TO_INET0 import-rib inet.0 set routing-options rib-groups V4_INTERNET_TO_INET0 import-policy DEFAULT_ROUTE_V4 set routing-options rib-groups V6_INTERNET_TO_INET0 import-rib INTERNET.inet.0 set routing-options rib-groups V6_INTERNET_TO_INET0 import-rib inet.0 set routing-options rib-groups V6_INTERNET_TO_INET0 import-policy DEFAULT_ROUTE_V6 set routing-options rib-groups V4_PUBLIC_TO_INTERNET import-rib inet.0 set routing-options rib-groups V4_PUBLIC_TO_INTERNET import-rib INTERNET.inet.0 set routing-options rib-groups V4_PUBLIC_TO_INTERNET import-policy AGGREGATES_V4 set routing-options rib-groups V6_PUBLIC_TO_INTERNET import-rib inet6.0 set routing-options rib-groups V6_PUBLIC_TO_INTERNET import-rib INTERNET.inet6.0 set routing-options rib-groups V6_PUBLIC_TO_INTERNET import-policy AGGREGATES_V6 adam ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] vrf auto-export rib-group
Hi, - On 23 Jun, 2020, at 14:57, Saku Ytti s...@ytti.fi wrote: > Hey Mihai, > > >> Is the rib-group configured under VRF auto-export supposed to be a >> 'per-table' (instead of per-protocol) rib-group which can also export >> routes from VRFs to non-VRF instances, default included? >> The example on the link below shows the export to another table within >> the same instance: >> >> https://www.juniper.net/documentation/en_US/junos/topics/example/policy-duplicating-routes.html >> >> I already tested and confirmed that routes from VRFs can be leaked to >> inet.0 by just using the rib-group under auto-export but I am not sure >> whether this is officially supported. > > I'm not sure if auto-export and rib-groups are directly related. The > common reason why you need auto-export in Junos (but not in other NOS) > is that if you import RT, and that RT in another local VRF, you don't > import it. As import only works on verbatim l3vpn rib. Auto-export > allows you to RT import routes from other local VRFs. > > rib-group is a set of ribs,which you can attach to multiple places and > it has different semantics on where you set it. But once a route hitsa > rib-group, instead of it being installed to one specific RIB, it is > installed to all of the RIBs in that rib-group. > > There are some significant behavioural differences on route which > arrived 'natively' to RIB and route which arrived via rib-group, > namely you might not be able to reflect one in BGP while you are able > to reflect another. And sadly it's a feature, not a bug. In addition to the significant behavioural difference between copying routes with rib-groups vs. leaking by RTs that Saku referred above, there are some interesting behaviour when using rib-groups. For example, when a rib-group is attached to a BGP peering, the BGP import policy is effectively applied twice - first when the route is accepted into the "native" table and a second time when the route is copied e.g. to inet.0 or some other table. Antti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
