Re: [j-nsp] RPD coring today?

[Pierre Emeriaud via juniper-nsp]

Le dim. 18 sept. 2022 à 07:08, Chuck Anderson via juniper-nsp
 a écrit :
>
> On Sat, Sep 17, 2022 at 06:21:51PM -0400, Jared Mauch via juniper-nsp wrote:
> > Anyone else see their RPD start to core today?  Seeing something weird, 
> > unclear if it’s local to my network or otherwise but two devices at the 
> > same time seem to be having trouble, so puzzling.
> >
> > Running 20.4R3.8
>
> What does this show:
>
> show system core-dump core-file-info /path/to/corefile

gdb was removed from junos somewhere around 16. This unfortunately
doesn't work anymore. It was quite handy.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Tacacs command authorization not working as intended

[Pierre Emeriaud via juniper-nsp]

Le lun. 4 juil. 2022 à 16:43, Saku Ytti  a écrit :
>
> I don't believe what you're doing is tacacs command authorization, that is 
> junos is not asking the tacacs server if or not it can execute the command, 
> something IOS and SROS can do, but which makes things like loading config 
> very brutal (except SROS has way to skip authorization for config loads).
>
> You are shipping config to the router for its allow-commands/deny-commands. 
> And I further believe behaviour you see is because there is distinction 
> between key and values, and you cannot include values in it. Similar problem 
> with 'apply-groups', because the parser doesn't know about values and you're 
> just telling what exists in the parser tree and what does not.

You're absolutely right. This is imho an acceptable tradeoff if
everything works.

Le lun. 4 juil. 2022 à 17:03, Saku Ytti  a écrit :
>
> I believe this is best you can do:
>
> y...@a03.labxtx03.us.bb-re0# show|display set |match deny
> set system login class tacacs-user deny-commands "clear pppoe
> sessions($| no-confirm$)"
>
> y...@a03.labxtx03.us.bb-re0> clear pppoe sessions ?
> Possible completions:
> Name of PPPoE logical interface
> y...@a03.labxtx03.us.bb-re0> clear pppoe sessions
>
> You can't clear all, but you can clear any.

Thanks Saku, much appreciated. this works well, although I still have
to allow 'clear' permission and refuse all other commands.

deny-commands = "clear [a-o].*|clear [q-z].*|clear p[^p].*|clear pppoe
sessions($| no-confirm$)"
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Tacacs command authorization not working as intended

[Pierre Emeriaud via juniper-nsp]

Le lun. 4 juil. 2022 à 16:18, Saku Ytti  a écrit :
>
> I don't believe Junos has tacacs command authorization.

it has. This sorta works, I've been able to allow some commands like
'clear network-access aaa subscriber username.*' and 'monitor
traffic'. The issue I have is with 'clear pppoe sessions pp0'.

When providing 'clear' to the user I can make it work, but I also have
to forbid all other clear commands I don't want.

foo@bar> show cli authorization
Current user: 'GEN-USR-N' login: 'foo' class 'GEN-PROF-N'
Permissions:
clear   -- Can clear learned network info
(...)
Individual command authorization:
Allow regular expression: (clear pppoe sessions pp0.*|clear
network-access aaa subscriber username.*|monitor traffic.*)
Deny regular expression: (request .*|file .*|save .*|clear
[a-o].*|clear [q-z].*|clear p[^p].*)


foo@bar> clear ?
Possible completions:
  network-access   Clear network-access related information
  ppp  Clear PPP information
  pppoeClear PPP over Ethernet information

And one can reset all pppoe sessions while I only allowed 'pppoe
session pp0.*' :
foo@bar> clear pppoe sessions ?
Possible completions:
  <[Enter]>Execute this command
Name of PPPoE logical interface

login configuration for your information:
foo@bar> show configuration system login
class GEN-PROF-N {
idle-timeout 15;
}
user GEN-USR-N {
full-name "TACACS centralized command authorization";
uid 2006;
class GEN-PROF-N;
}
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Tacacs command authorization not working as intended

[Pierre Emeriaud via juniper-nsp]

Hi

i've been trying to authorize 'clear pppoe session pp0.*' for some of
our users. They already have some allowed commands such as 'monitor
traffic' and 'clear network-access aaa subscriber username' that
works, but 'clear pppoe' is refused.

foo@bar> clear ppp?
No valid completions

foo@bar> clear pppoe
   ^
syntax error, expecting .


Here are their rights on the box. They don't have 'clear' permissions
as I'd rather allow one command than refuse all the others.

foo@bar> show cli authorization
Current user: 'GEN-USR-N' login: 'foo' class 'GEN-PROF-N'
Permissions:
configure   -- Can enter configuration mode
interface   -- Can view interface configuration
network -- Can access the network
routing -- Can view routing configuration
trace   -- Can view trace file settings
trace-control-- Can modify trace file settings
view-- Can view current values and statistics
view-configuration-- Can view all configuration (not including secrets)
Individual command authorization:
Allow regular expression: (clear pppoe sessions pp0.*|clear
network-access aaa subscriber username.*|monitor traffic.*)
Deny regular expression: (request .*|file .*|save .*|clear log .*)
Allow configuration regular expression: (protocols pppoe
traceoptions|system processes smg-service traceoptions|system
processes general-authentication-service traceoptions|protocols
ppp-service traceoptions|services l2tp traceoptions)
Deny configuration regular expression: none

And the tacacs configuration:

  match = @RouterBNG {
# ReadOnlyDebug
service = junos-exec {
local-user-name = GEN-USR-N
user-permissions = "configure interface network routing trace
trace-control view view-configuration"
deny-commands = "request .*|file .*|save .*|clear log .*"
allow-commands = "clear pppoe sessions pp0.*|clear network-access
aaa subscriber username.*|monitor traffic.*"
allow-configuration = "(protocols pppoe traceoptions|system
processes smg-service traceoptions|system processes
general-authentication-service traceoptions|protocols ppp-service
traceoptions|services l2tp traceoptions)"
}
  }

options I've tried:
allow-commands = "(monitor traffic.*)|(clear pppoe sessions
pp0\..*)|(clear network-access aaa subscriber username.*)"
allow-commands = "monitor traffic.*|clear pppoe sessions pp0.*|clear
network-access aaa subscriber username.*"
allow-commands = "monitor traffic|clear pppoe sessions pp0\..*|clear
network-access aaa subscriber username"
allow-commands = "clear pppoe sessions pp0.*|clear network-access aaa
subscriber username.*|monitor traffic.*"


Is there a way without providing 'clear' permission? 'clear
network-access' works even without it...

thanks,
pierre
___
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

[Pierre Emeriaud]

Le mer. 24 juin 2020 à 16:50, Pierre Emeriaud  a écrit :
>
> 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.

> - would you consider the 'disable' not working as (I) expected a bug?

FYI, this is PR1376574, "Interface optic output power is not zero when
the port has been disabled.".
___
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

[Pierre Emeriaud]

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

[Pierre Emeriaud]

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

[j-nsp] How to shut down laser on any optics

[Pierre Emeriaud]

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] Old JunOS upgrade path

[Pierre Emeriaud]

Le ven. 8 mars 2019 à 10:26, Robert Hass  a écrit :
>
> Hi
> Can I do direct upgrade of JunOS 13.2S to 17.4S ?
> Platform is MX80
> Or should I go step by step: i.e:
> 13.2 -> 14.1
> 14.1 -> 15.1
> 15.1 -> 16.1
> 16.1 -> 17.1
> 17.1 -> 17.4

As others said, direct upgrade is somewhat unsupported and quite bold.

We're currently upgrading mx480s from 13.3R5 to 17.2R2 with an
intermediate step on 15.1F5. As those are LNSes we have to activate
tomcat (`services subscriber-management`) while in 15.1, then continue
the upgrade.

For downgrades besides deleting the subscriber-management
configuration we disable GRES and commit sync, and it goes smoothly.

HTH,
pierre
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] IS-IS POI

[Pierre Emeriaud]

Le ven. 28 sept. 2018 à 12:49, Saku Ytti  a écrit :
>
> Hey James,
>
> > Have anyone used this feature, did it actually help you pin-point the
> > source of an IGP issue?
>
> I doubt many people have ever encountered the problem.
>
> The problem is rogue or misconfigured ISIS speaker with duplicate
> address. This ISIS speaker can re-advertise every LSP with superior
> SEQ or even MAX_SEQ.

a subsidiary of $work had an issue with rogue purges. But it wasn't a
rogue equipment. It was just failing in the (very) wrong way. Their
network went down for several relly looong hours.

> Outcome of rogue ISIS speaker advertising MAX_SEQ is that you need to
> first remove the rogue speaker and then reload whole network
> simultaneously or renumber every ISIS speaker. If you reload all
> network except one, whole network will relearn the bad information
> from the remaining speaker once it comes up.
>
> In this failure mode this feature would help to find the rogue ISIS
> speaker, so looks sensible feature to me, even when very partial
> support it will limit limit the domain where the suspect exists. I've
> personally not used it, and very much hope I'll never have need for
> it.

Yes. I really want to never need such a feature, but as this scenario
is what our ops nightmares are fueled with, I asked for some more
monitoring of purge messages, so as updates per seconds and some other
metrics.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] deleting ntp server from config, perhaps a bug?

[Pierre Emeriaud]

Le jeu. 27 sept. 2018 à 19:23, Netravnen  a écrit :
>
> On Thu, 27 Sep 2018 at 13:43, Drew Weaver  wrote:
> > I added 0.pool.ntp.org, 1.pool.ntp.org, 2.pool.ntp.org, 3.pool.ntp.org to 
> > system ntp on an MX80 running JunOS 15.
>
> Maybe look into a way to dynamically update the ntp servers list?
> (using automation?)

ntpd from ntp.org has some additional logic to handle the pool.
Instead of configuring 'server 0.pool.ntp.org', use 'pool
0.pool.ntp.org':

ntpq> peers
 remote   refid  st t when poll reach   delay   offset  jitter
==
 0.debian.pool.n .POOL.  16 p-   6400.0000.000   0.000
 1.debian.pool.n .POOL.  16 p-   6400.0000.000   0.000
*ntp1.rrze.uni-e .DCFp.   1 u  428 1024  377   12.567   -0.544   0.285
+srcf-ntp.stanfo .GPSs.   1 u  876 1024  377  138.149   -0.128   0.397
-ntp-1.arkena.ne 145.238.203.14   2 u  764 1024  317   15.210   -7.569   0.990
+regar42.fr  62.210.244.146   4 u  375 1024  3775.038   -1.523   0.310

Only 0.debian.pool.ntp.org and 1.debian.pool.ntp.org are defined in
ntp.conf. (this is not mentioned in the manpage - yay).

Is Junos using ntpd from ntp.org or openntpd?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Taking down VPLS unit with OAM CFM

[Pierre Emeriaud]

> is it possible to mark a VPLS site interface unit as down when OAM CFM
> signals a fault over that unit?

It's possible. Try something like this:

> root@lab-mx80-2# show protocols oam ethernet connectivity-fault-management 
> action-profile vlan-down
event {
adjacency-loss;
}
> action {
> interface-down;
> }


> root@lab-mx80-2# show protocols oam ethernet connectivity-fault-management 
> maintenance-domain SATTest
> level 7;
> maintenance-association SAT {
> continuity-check {
> interval 1s;
> }
mep 2 {
interface ae1.2000;
direction down;
remote-mep 1 {
  action-profile vlan-down;
}
> }

This is what we're using, it works for us(tm).
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] maximum-prefixes not enforced on option B gateways

[Pierre Emeriaud]

2018-03-29 10:20 GMT+02:00 Pierre Emeriaud <petrus...@gmail.com>:
> 2018-03-28 17:02 GMT+02:00 James Bensley <jwbens...@gmail.com>:
>>
>> Do you have any other Junos versions that exhibit the same behavior?
>> Specifically do you see this on any newer Junos versions you maybe
>> running?
>
> I do have other option B gateways on MX with more recent releases,
> however none of the routing-instances configured on those reached the
> max prefix.

Ok, so I found three MXes, all running 14.1X50-D90.7, each one with a
l3vpn max prefix hit. And the max prefixes were honored. I guess the
issue was corrected somewhere between 12.3 and 14.1.

Thanks everyone.

--pierre
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] maximum-prefixes not enforced on option B gateways

[Pierre Emeriaud]

2018-03-28 17:02 GMT+02:00 James Bensley :
>
> Do you have any other Junos versions that exhibit the same behavior?
> Specifically do you see this on any newer Junos versions you maybe
> running?

I do have other option B gateways on MX with more recent releases,
however none of the routing-instances configured on those reached the
max prefix.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] maximum-prefixes not enforced on option B gateways

[Pierre Emeriaud]

>> Could you try 'maximum-paths' instead? Just as additional datapoint.

Unfortunately, after enabling the maximum-paths 2000 and disabling /
re-enabling the RI, it made no difference:

Mar 28 15:34:38  router rpd[1598]: RPD_RT_PATH_LIMIT_REACHED: Number
of paths (3580) in table CUST-VRF-FOO.inet.0 still exceeds or equals
configured maximum (2000)

still a weird issue, but no customer impact, so I don't really mind
about it. I was just curious.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] maximum-prefixes not enforced on option B gateways

[Pierre Emeriaud]

2018-03-28 13:47 GMT+02:00 Saku Ytti :
> Hey,
>
>> This is on M120 running 12.3R6-S3 (yes I know, ancient. No, can't upgrade).
>
> Then I recommend 'set system no-bugs'.

Error. Command not found. Please insert coin to conti^wupgrade.
:)

>> Anyone aware of a PR on this? Is this a known limitation?
>
> There are some PRs related to ways routes appear on RIB and that not
> all of these ways honour maximum-prefixes. One I found is PR1157842,
> but it's not really exact match to yours, provided your config is
> realistic and not cherry-picked example of what you believe is
> relevant to the problem.

Indeed, not exactly my issue, but that proves that max-prefix is not
always enforced.

> Could you try 'maximum-paths' instead? Just as additional datapoint.

Thanks, I'll try and report back.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] maximum-prefixes not enforced on option B gateways

[Pierre Emeriaud]

Gents,

I just noticed an issue on a couple of option B gateways in our
network. The max-prefix within routing-instances is not enforced. It's
although taken into account.

This is on M120 running 12.3R6-S3 (yes I know, ancient. No, can't upgrade).

me@router> show configuration routing-instances CUST-VRF-FOO
instance-type vrf;
interface sp-2/2/0.1451;
route-distinguisher 64544:123456;
vrf-import [ CUST-POL-IN-FOO GEN-POL-BOTH-REJECT ];
vrf-export [ CUST-POL-OUT-FOO GEN-POL-BOTH-ACCEPT ];
vrf-table-label;
routing-options {
maximum-prefixes 2000 threshold 80;
auto-export;
}

me@router> show route summary table CUST-VRF-FOO
Autonomous system number: 64544

CUST-VRF-FOO.inet.0: 2594 destinations, 3572 routes (2594 active, 0
holddown, 0 hidden)
Limit/Threshold: 2000/1600 destinations
 BGP:   3572 routes,   2594 active


Mar 28 09:03:45  router rpd[1598]: RPD_RT_PREFIX_LIMIT_REACHED: Number
of prefixes (2593) in table CUST-VRF-FOO.inet.0 still exceeds or
equals configured maximum (2000)

CUST-VRF-FOO is not the only routing-instance affected, I have plenty
of them. I don't even have 1 holddown route on theses boxen.

Anyone aware of a PR on this? Is this a known limitation?

thanks
---
pierre
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Juniper UDP Amplification Attack - UDP port 111 ?

[Pierre Emeriaud]

2018-03-16 3:06 GMT+01:00 Roland Dobbins :
>
> On 16 Mar 2018, at 8:59, Chris Kawchuk wrote:
>
>> Just a heads up; I'm probably not the first person to see this--
>
>
> This is rpcbind/portmapper, FYI, which is often abused for
> reflection/amplification attacks.
>
> I'm assuming vMX is a virtual MX - if so, are you sure the issue isn't on
> the hypervisor host?
>
> If not, definitely seems like a bug which should be reported to JSIRT.

this is definitely not on the host:

user@mx960> show system connections inet | match .111
tcp4   0  0  *.111 *.*
  LISTEN
udp4   0  0  *.111 *.*

Chris, besides filters, using un-announced prefixes for your backbone
would prevent this kind of issues (and some others).
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] DDoS to core interface - mitigation

[Pierre Emeriaud]

2018-03-09 15:48 GMT+01:00  :
>
> But I was actually referring to the very appealing idea you proposed in b) to 
> not to even advertise the range -so the DDoS traffic would not even end up at 
> your doorstep as simply the Internet would not have route for any of your p2p 
> links.

this is really nice and a must-have, but has the side effect (bonus or
not, up to you) to make your network 'invisible' to others if they
have urpf enabled towards you.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Experience with Junos 15.1 on MX960?

[Pierre Emeriaud]

> we've had very bad experience with Junos 15.1 on our switches (EX4550, 
> EX4300, EX4200).
> Now we're getting new MX960s with 2xRE-S-X6-64G and unfortunately the minimum 
> required Junos version for this RE is 15.1. Can anyone share their experience 
> with Junos 15.1 on MX960? Is it as bad as it is on the switches? Would it be 
> wiser to jump directly to 16.1/16.2/17.1/17.2/17.3?
>
> We're especially interested in bugs/problems related to MC-LAG.

We've been hit with several bugs on 15.1F5, from S4.6 to S7. S8 seems
to work fine for our usecase, and sleep is finally possible.

But so far, no issues with MC-LAG, with either two 15.1 boxen or a mix
of 14.1 and 15.1.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp