Re: [j-nsp] ifstrace log filling up with debug output

[Timur Maryin via juniper-nsp]

Hi Joerg,

On 23-Mar-24 15:24, Joerg Staedele via juniper-nsp wrote:

Hi,

No traceoptions ... and meanwhile i've tested even with no configuration and 
after a zeroize it also does the same. I guess it’s a bug. I will try another 
version (maybe some 19.x)



And I believe it will be the same because ifstraced  daemon is enabled 
by default on SMP systems (for a while already)



How much data do you get in your logs?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] GRE tunnels on a QFX10002-60C

[Timur Maryin via juniper-nsp]

On 24-Jun-22 9:28, Saku Ytti via juniper-nsp wrote:

Tunnel interfaces are not supported on PE/Paradise, I don't think this
changed in BT/Triton either.

>
> However you can decapsulate/encapsulate on ingress firewall filter, e.g.:



On the other hand, there is fti (flexible tunnel interface) concept 
which is the recommended (as far as i'm aware) way for BT platforms.

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

Re: [j-nsp] Database size on JunOS

[Timur Maryin via juniper-nsp]

--- Begin Message ---

It does exist:


> show version | match model:
Model: qfx10002-72q

> show system configuration database usage
Maximum size of the database: 406.99 MB
Current database size on disk: 10.50 MB
Actual database usage: 10.48 MB
Available database space: 396.52 MB


> request system configuration database resize
Configuration database resized




On 02/11/2020 09:21, Vincent Bernat wrote:
Thanks for the hint. Unfortunately, the partition is too small on the 
QFX and I suppose that's why the command does not exist on this serie.


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

Re: [j-nsp] Database size on JunOS

[Timur Maryin via juniper-nsp]

--- Begin Message ---

Hi there,


Have a look

https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/request-system-configuration-database-resize.html



On 29/10/2020 17:05, Vincent Bernat wrote:

Hey!

With a configuration file around 5 MB, we get a pretty big configuration
database:

% gunzip -c /config/juniper.conf.gz | wc
   122092  331622 4452705
router> show system configuration database usage
Maximum size of the database: 409.99 MB
Current database size on disk: 145.00 MB
Actual database usage: 69.82 MB
Available database space: 340.17 MB

How 5MB of text could translate to 145/69 MB in binary format?

The configuration file is "big" because we have some IRR-generated
policies.

Moreover, on a QFX10k, the partition for /var/rundb is quite small
(1GB). Is there a way to bump that, dynamically or through a reinstall?

Thanks.

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

Re: [j-nsp] Netflow config for MX204

[Timur Maryin via juniper-nsp]

--- Begin Message ---

Perhaps you just needed to add (to your original config)

routing-instance vrf-name
under forwarding-options sampling family inet output flow-server x.x.x..x


and not to overdo everything under vrf



On 09-Apr-20 10:03, Liam Farr wrote:

Seems I cant just drop the forwarding options into the vrf verbatim;

# show | compare
[edit]
-  forwarding-options {
-      sampling {
-          sample-once;
-          instance {
--- End Message ---
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Netflow config for MX204

[Timur Maryin via juniper-nsp]

--- Begin Message ---



On 09-Apr-20 08:20, Liam Farr wrote:

Hi,

changed to a loopback address on one of the VRF's,


...


Not sure specifically what I am doing wrong here, it seems to be collecting
the flows ok, but exporting is the issue?

I'd appreciate any advice or pointers thanks :)



maybe this?

https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/routing-instance-edit-forwarding-options-sampling.html

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

Re: [j-nsp] Slow RE path 20 x faster then PFE path

[Timur Maryin via juniper-nsp]

--- Begin Message ---



On 23-Mar-20 14:03, Robert Raszuk wrote:

Hi,

Would anyone have any idea why IP packets with options are forwarded via
MX104 20x faster then regular IP packets ?

"fast" PFE path - 24-35 ms
"slow" RE path - 1-4 ms



24 ms is ages in terms of PFE.
I hardly can imaginethat is possible.


Is it possible that .209 answers faster to packets with options?
--- End Message ---
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] QFX10K port shaping

[Timur Maryin via juniper-nsp]

--- Begin Message ---

I found this:
QFX1 Series switches do not support the shaping-rate statement. 
However, you can configure the transmit-rate exact option to prevent a 
queue from consuming more bandwidth than you want the queue to consume.



here:
https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/shaping-rate-edit-class-of-service.html



On 21-Feb-20 10:59, Chen Jiang wrote:

Hi!

QFX10008 w/ JUNOS 15.1X53 and 18.4R2.3

Thanks!

On Fri, Feb 21, 2020 at 4:53 PM Timur Maryin > wrote:


What is exact model you have?
And junos version?


On 20-Feb-20 13:43, Chen Jiang wrote:
 > Hi! Experts
 >
 > Sorry for disturbing, we found the "set class-of-service
interfaces xxx
 > shaping-rate" is missing in QFX platform, is there any other
method could
 > do port shaping ?
 >
 > Thanks for your help.
--- End Message ---
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] QFX10K port shaping

[Timur Maryin via juniper-nsp]

--- Begin Message ---

What is exact model you have?
And junos version?


On 20-Feb-20 13:43, Chen Jiang wrote:

Hi! Experts

Sorry for disturbing, we found the "set class-of-service interfaces xxx
shaping-rate" is missing in QFX platform, is there any other method could
do port shaping ?

Thanks for your help.

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

Re: [j-nsp] MX204 vs. MX240??

[Timur Maryin via juniper-nsp]

--- Begin Message ---

On 14-Nov-19 14:19, adamv0...@netconsultings.com wrote:


There are several places where you can run your keepalieve

a) RPD
b) RE PPMd
c) LC CPU PPMd
d) NPU (dispatch block in the LU/XL)

And it depends on config where you run it. 



... and on hardware and on defaults of the Junos version you run.



Then PPMD can run on RE obviously or can be distributed onto LC -now this is
where my confusion comes in.

That's because I was under the impression that it's the LC CPU hosting the
PPMD in distributed mode,



packet generation by lookup chip used be referred as 'inline'
by LC CPU - distributed.
check first reply here:
https://forums.juniper.net/t5/Junos/Inline-BFD-vs-distributed-BFD/td-p/463242



Also is there a cmd I can use to switch between LC CPU and LU?



I recall there is a hidden knob (mentioned in MX series book):

https://books.google.nl/books?id=SVvnDAAAQBAJ=PA12=PA12=junos+inline+bfd=bl=Dt7vVwAShk=ACfU3U0FWXmAHyJA7urRdPO5w5kJZFdwjw=en=X=2ahUKEwj38tz5rfblAhVRoZ4KHbCjDqEQ6AEwDXoECAkQAQ

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

Re: [j-nsp] prsearch missing in inaction

[Timur Maryin via juniper-nsp]

https://kb.juniper.net/KB33515

If i recall correctly what i heard about it.

There is some third party(or smth) search engine which is(was) used and 
it had issues. And there is no way to upgrade/fix that engine as it out 
of support/development.

So i has to be replaced or re-written from scratch.




On 09-May-19 02:37, Nathan Ward wrote:


Can you shed any light on what on earth is going on, and why? It seems crazy 
that a company would disable this sort of thing intentionally for such a long 
time and with such poor comms and timing info. “Technical issue” sounds like an 
accident - but surely a restore from backup would work, right?
I cannot think of a scenario here which looks anywhere remotely positive for 
Juniper - every scenario I can consider has a root cause of “complete and utter 
incompetence” somewhere along the chain.
I really like Juniper, so I’ve searched, but, this is a hard one, help me out 
here..


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

Re: [j-nsp] Old JunOS upgrade path

[Timur Maryin via juniper-nsp]

This is not applicable to MX80 (as platform was mentioned by topic starter).


On 12-Mar-19 15:38, adamv0...@netconsultings.com wrote:


Upgrading from 12.3 to 15.1 upgrades the FreeBSD version from 6.1 to
10.0.
Upgrading from 12.3xxx to 15.1xxx reformats the file system. Only specific
files and directories are preserved.


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

Re: [j-nsp] Junos Arp Expiration Timer Behavior & Active Flows

[Timur Maryin via juniper-nsp]

On 11-Jan-19 17:50, Clarke Morledge wrote:

A couple of questions:

(a) Is this default behavior across all Junos platforms, including MX, 
SRX, and EX?



I would expect so.

What is also possible in this case is to configure huge arp timeout:

set system arp interfaces xe-1/1/0 aging-timer ?
Possible completions:
  Change the ARP aging time value (1..60 minutes)


that's 400+ days.

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

Re: [j-nsp] MX204 Tunnel Services

[Timur Maryin via juniper-nsp]

Perhaps encapsulation vlan instead may help.


On 27-Dec-18 23:40, Fraser McGlinn wrote:

Further to this, and to clarify I do already have tunnel-services enabled and 
after configuring I get output packets on each unit, but no input packets. It 
seems like the PFE is just eating the packets.




fraser@> show configuration | display set | match lt-0/0/0
set interfaces lt-0/0/0 unit 100 encapsulation ethernet
set interfaces lt-0/0/0 unit 100 peer-unit 101
set interfaces lt-0/0/0 unit 100 family inet address 100.64.0.1/30
set interfaces lt-0/0/0 unit 101 encapsulation ethernet
set interfaces lt-0/0/0 unit 101 peer-unit 100
set interfaces lt-0/0/0 unit 101 family inet address 100.64.0.2/30
set routing-instances TEST interface lt-0/0/0.101

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

Re: [j-nsp] interface-range inheritance change in 14.1X53 and 15.1

[Timur Maryin via juniper-nsp]

My bet is that is an example of poorly written external description.
Besides "Resolved-In" has only one version.


On 21-Dec-18 00:22, Anderson, Charles R wrote:

Can anyone shed some light on WHY this change was made?  I much prefer the old 
behavior.


From PR1281947:


"The behavior of the "interface-range" configuration statement changed in 14.1X53 and 15.1. 
Prior to 14.1X53 and 15.1, more specific configuration on the interface would supersede what was configured 
in the interface-range. In 14.1X53 or 15.1, if there was specific interface configuration, the configuration 
in "interface-range" will append to it. For example, if there is a mismatch of VLAN assignment 
between the interface-range and the direct interface configuration, it will append the configured VLAN and 
cause an invalid configuration in 14.1X53 or 15.1."

https://prsearch.juniper.net/InfoCenter/index?page=prcontent=PR1281947

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

Re: [j-nsp] MX204-IR RIB->FIB sync?

[Timur Maryin via juniper-nsp]

Hi Jason,


The loss upon restoration could easily be due to microloop. Which is 
caused by different convergence speed of neighboring.


When you leave only one type of routers they converge at the same speed 
so no microloops.






On 13-Dec-18 02:47, Jason Lixfeld wrote:

Hi all,

I’ve been playing around with rLFA in a small lab using a pair each of 
MX204-IR, ASR920, ME3600s in a ring:

MX1-et0/0-MX2-xe0/1-ASR2-ge-ME2-ge-ME1-ge-ASR1-te-MX1

They're all running BFD (150ms x 3), LDP, ISIS, LDP-IGP sync (infinite 
holddown), LDP session protection and LDP GR (not that GR really applies here, 
but…)

MX1, MX2, ASR1 and ASR2 have a single armed host hanging off each of them.  The 
test consists of H-ASR1 pings to H-MX2, and H-ASR2 pings to H-MX1.  In both 
cases, it’s sudo ping -fi 0.001 ${host}

ASR1 has rLFA for H-MX2 subnet, ASR2 has rLFA for H-MX1 subnet, MX1 has rLFA 
for H-ASR2 subnet, and MX2 has rLFA for H-ASR1 subnet.

With this topology, when I pull the plug between MX1 and MX2, I lose a ping or 
two, but when I connect MX1 and MX2 again, there’s about 500ms of loss on all 
tests.
If I re-jig the topology and move the MX1-MX2 link from et0/0 to also be 
xe-0/1, the failover and tailback both lose about 500ms worth of traffic.
If I re-jig the topology and remove the MX1-MX2 links entirely and instead 
create a link between ASR1 and ASR2 to close the ring, there’s zero loss on the 
failover of that ASR1-ASR2 link, and only about 10ms loss on the fail back.

This is all really surprising to me.  Surprising that when the MX1-MX2 link is 
on et0/0 it behaves one way, and another way when the MX1-MX2 link is on xe0/1 
(PIC0 vs PIC1).  Also, surprising that it didn’t seem to perform as well as 
when the ASRs were closing the ring instead of the MXs.

I really thought this testing would be much more uneventful than it has been.  
If I think through this as rationally as I understand it, the only thing that 
seems to make sense is that on the MX, the FIB is a bit out of sync with the 
RIB, worse based on the PIC.

I’m pretty new to JunOS and Juniper HW architecture in general, so there’s no 
doubt much that I don’t know.

Thoughts?

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

Re: [j-nsp] command authorization and tacacs

[Timur Maryin via juniper-nsp]

Hi Pierfrancesco,



 Timur> 2. commit script which checks presence of certain parts of config.

I'll need to refresh myself on this and see if I can use this
technique.



There is an example on github which can be used as starting point:

https://github.com/Juniper/junoscriptorium/blob/master/library/juniper/commit/system/protect-config/protect-config.slax


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

Re: [j-nsp] command authorization and tacacs

[Timur Maryin via juniper-nsp]

Hello!


On 11-Dec-18 15:33, Pierfrancesco Caci wrote:


I have not found a way to prevent a user from accidentally delete entire
bgp config, but still allowing him to operate on single neighbors. Or
other similar situation involving top level configuration vs details
inside each block.



There are several ways to achieve that, for example:

1. protect  (kb.juniper.net/KB25493)
2. commit script which checks presence of certain parts of config.


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

Re: [j-nsp] negation operator in SLAX

[Timur Maryin via juniper-nsp]

Hi Phil,


On 18-Jun-18 20:40, Phil Shafer wrote:


"!" and "not" are identical.  The "!" is just syntactic sugar that
turns "! x " into "not(x)", as you can see in the code:



Was it always like this?

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

Re: [j-nsp] negation operator in SLAX

[Timur Maryin via juniper-nsp]

Hi Martin,


There is not() :


https://www.juniper.net/documentation/en_US/junos/topics/reference/scripting/junos-script-automation-function-xslt-not.html



On 14-Jun-18 23:39, Martin T wrote:

Hi!

I have quite often used "!" negation operator familiar from other
languages. For example:

/* If string does not match the pattern, then terminate the script. */
if ( ! jcs:regex( $pattern, $string ) )  {
 terminate 'Invalid input string!';
}

However, I have not found this method in the official SLAX
documentation or SLAX operators list. Based on my example above, the
suggested solution seems to be to check if jcs:regex returned an empty
node-set or not using jcs:empty:

if ( jcs:empty( jcs:regex( $pattern, $string ) ) ) {
 terminate 'Invalid input string!';
}

Just out of curiosity, is there a difference between those two methods?





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

Re: [j-nsp] Strange Behavior after ISSU from 13.3R8 to 17.4R1.16

[Timur Maryin via juniper-nsp]

Hi Jeffrey,

I'm under impression that

(quote from 
https://www.juniper.net/documentation/en_US/junos/topics/topic-map/junos-kernel-freebsd-upgraded.html 
)


"ISSU is not supported from an older version of FreeBSD to an upgraded 
FreeBSD"




On 28-May-18 04:01, Jeffrey Nikoletich wrote:

Hello all,



So I have been scratching my head at a weird issue I am seeing on only 1 of
our devices after a ISSU rollout to 17.4. It seems that all peering session

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

Re: [j-nsp] Syslog getting spammed by DDOS_PROTOCOL_VIOLATION_SET

[Timur Maryin via juniper-nsp]

Hi Karl,

DDOS subsystem applies only to the traffic destined to the host (router 
itself) and not transit traffic.


When you announce that /18 have you got all destinations of that /18 
reachable by the router? Have you got default route ?



The graceful way to handle those messages is to figure out what causing 
them i presume.


I'd start figuring out what's going on from answering above questions 
and looking at below outputs:


 show ddos-protection protocols resolve statistics brief
 show ddos-protection protocols violations


I'm sure if you google this topic you may find a lot of information as well



On 21-Nov-17 12:01, Karl Gerhard wrote:

Hello

our syslog is getting spammed with the following messages:
jddosd[12168]: %DAEMON-4-DDOS_PROTOCOL_VIOLATION_SET: Protocol resolve:ucast-v4 
is violated at fpc 11 for 1389 times
jddosd[12168]: %DAEMON-4-DDOS_PROTOCOL_VIOLATION_CLEAR: Protocol 
resolve:ucast-v4 has returned to normal. Violated at fpc 11 for 1389 times

What is puzzling is that there is barely any traffic going through that machine 
(like 5 MBit/s). It seems like those messages are being triggered by random 
noise from the internet just by announcing a single /18.

Is that normal? Is there a way to gracefully handle those messages (i.e. save 
them into another file) without losing important information?

Regards
Karl

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

Re: [j-nsp] Junos 15.1 and DPC

[Timur Maryin via juniper-nsp]

Hi Johan,


Yes, it works fine.


On 10-Aug-17 09:59, john doe wrote:

Hi

Will 15.1 work well on MX boxes with old DPC cards? Anyone running 15.1 on
MX with DPC?

Johan

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

Re: [j-nsp] flowspec in logical-systems

[Timur Maryin via juniper-nsp]

Hi Michael,


I believe it's not supported.



On 22-Mar-17 20:07, Michail Litvak wrote:

Hi all,

Did anybody tried to use flowspec in the logical-system ?


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

Re: [j-nsp] juniper router reccomendations

[Timur Maryin via juniper-nsp]

Hi Adam,

On 01-Aug-16 10:02, Adam Vitkovsky wrote:


Now I have realized that there might be a problem which BGP PIC can't really 
solve.
And that's when the primary edge link/PE comes back online advertises it's 
prefixes to the rest of the AS and ingress PEs will actually install and start 
using these, sending traffic to egress PE sooner than it can actually forward 
it cause it's FIB is still being updated.
And for this specific case what you describe would be needed.



I presume this is addressed via
https://prsearch.juniper.net/PR1130154

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