I would expect to have some kind of encapsulation on the interface.
eg; set encapsulation flexible-ethernet-services
-Original Message-
From: jayshankar nair [mailto:n_jayshan...@yahoo.com]
Sent: Thursday, April 08, 2021 5:46 AM
To: juniper-nsp@puck.nether.net
Subject: vlan-tagging on osp
Good morning folks,
Am wondering if anyone has recently gone through licensing process for an SRX
with the NCP remote-access license (Eg; SRX-RA1-10 [1])
What I can garner from Juniper documentation, suggests license is included. But
there's no documented process (I, or that my Juniper reps can
What was the reported reboot reason?
You will find that in 'show chassis routing-engine'
-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of
Mohammad Khalil
Sent: Thursday, October 22, 2020 3:13 PM
To: Juniper List
Subject: [j-nsp] SRX300 Sudden
Nothing looks out of sorts.
For the sake of testing, if you give the input direction a different policer,
does it show any hits on 'show policer' output?
Eg;
set firewall family inet filter customer-ZZZ-out term default then policer
policer-20m-TEST
set firewall policer policer-20m-TEST if-excee
Though not had any experience with MX's, we were never successful in getting
DAC's to work with our EX's.
Had to go for optics.
We learned to just not bother with DAC's in future due to off-list anecdotes of
such behavior - not just with Juniper (HPE, Cisco...)
-Original Message-
From: j
We've not had any issues (so far) with either 15.1X53-D51, or 18.2R2.6.
Only using them for L2 distribution or QinQ, though. So your mileage may vary.
-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of
Philippe Girard
Sent: Monday, December 09,
Based on what you described, it sounds like you already got your MPLS/LDP
running in a packet-mode routing-instance, as otherwise MPLS is dropped on an
SRX in flow mode.
No obvious ideas with the output provided otherwise.
Do the flows in your IPSEC instance get created?
-Original Message--
Page 6 of the SRX300 series datasheet states in the fineprint;
16* "Throughput numbers based on UDP packets and RFC2544 test methodology."
That said, I don't see RFC2544 generation and reflection explicitly stated
anywhere, nor do I see the config syntax supported up to 15.1X49-D160.2
Juniper KB
> I would avoid changing "messages" since JTAC usually relies on the standard
> stuff being there (and often increasing the logging to daemon any; kernel
> any;)
Despite our messages configuration, I second this sentiment. You're better to
play it safe unless you have reason to otherwise.
We r
Our 'messages' content is pretty minimal. We try to keep as little data in one
lump on the device(s) to make auditing easier.
If we need to login to the device to check something, we want to find an answer
quick. If we have time or it's looking like a far more complex problem, then we
can scrape
I expect you don't like the idea of syslog for the same reason as SNMP traps...
So perhaps you could craft something using SLAX? I would be a little surprised
if someone hasn't already done this somewhere:
https://www.juniper.net/documentation/en_US/junos/topics/example/junos-script-automation-s
Our experiences with DAC's have been atrocious to date - Genuine Cisco, Genuine
HPE, compatible or generic from FS.com...
In the end, we chose Optics (after some off-list recommendations via this
list), and all our problems with devices not linking were resolved.
-Original Message-
From:
Juniper has always been accommodating in my occasional request to provide
disambiguation to KB's or PR's, whenever I use the feedback widget.
Let them know your thoughts.
-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of
Sebastian Wiesinger
Se
+1 for PHPIPAM.
It's code is clean and super-easy to modify if needed, and it has GUI built-ins
to add custom fields.
-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of
Roger Wiklund
Sent: Thursday, December 13, 2018 7:09 AM
To: adamv0...@netco
I can't offer any working samples or clue-bats, but I too am interested in this.
I've not been successful in getting this working since I last ran 12.3X48-D35.
-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of
Mohamed Faye
Sent: Thursday, Octob
> If it is on a Web page you can simply use the star rating and leave feedback
> with a comment.
> My response rate from the documentation team is still 100%.
+1
-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of
Karsten Thomann via juniper
You might want to check the MTU of the path, or ensure that pmtu is enabled.
It looks like you're using a redundant ethernet interface (reth). If you're
using a non-standard MTU, make sure it is set correctly for its member
interface(s).
From: juniper-nsp
We've got a half dozen EX2300 and EX2300-C's in production, and no issues for
us with those so far.
EX2200's have been fine for us less a pair of 2200-C's that managed to go out
the door with 15.x JunOS. But as someone stated in this thread earlier, there
are known issues attempting this on the
lf Of
Chuck Anderson
Sent: November-21-17 7:10 AM
To: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] EX3400 or EX4600, and HPE FlexFabric-20/40, QSFP+ DAC's
On Tue, Nov 21, 2017 at 06:28:07AM -0800, Emille Blanc wrote:
> Hello folks,
>
> Trudging through the woes that are cross-v
Hello folks,
Trudging through the woes that are cross-vendor compatibility issues, and
failing completely at getting a link between an EX3400 or EX4600, and an HPE
FlexFabric-20/40 F8 card in our c7000 enclosure using an HPE branded QSFP+ 3mtr
DAC. That is to say, Juniper on one side, HPE on t
20 matches
Mail list logo
