>
> # show
> term term1-match {
> from {
> destination-address {
> 131.0.245.143/32;
> }
> packet-length 32-63;
> protocol 6;
> source-port 443;
> tcp-flags "syn & ack & !fin & !rst & !psh";
> }
> then {
> co
I don't see this behavior in 20.X trains, so possibly something introduced
in 21.
That being said, I think that concerns about SSD's dying because of write
volume is pretty over dramatic. The volume of logs written for everything
else is certainly much higher than this.
Worth opening a case on fo
>
> If you have Cisco HTTS or Juniper ACP or the like, where you get named
> engineers, then you can develop a mutual trust and give those
> engineers access to your network.
>
To each their own, but I'm with Jared on this. No way would a vendor have
any direct access. The most permissive I'd acce
>
> I also find that BFD can cause more problems than it fixes if you go too
> aggressive with it !
>
Concur here. BFD has its uses in specific circumstances, but it's almost
always much better to rely on interface state change and hold-time up FOO.
On Sat, Apr 27, 2024 at 6:34 AM Sean Clarke vi
>
> but a BGP-LU solution exists even for this problem.
>
My first thought was also to use BGP-LU.
On Wed, Apr 3, 2024 at 2:58 AM Saku Ytti via juniper-nsp <
juniper-nsp@puck.nether.net> wrote:
> On Wed, 3 Apr 2024 at 09:45, Saku Ytti wrote:
>
> > Actually I think I'm confused. I think it will
I've read this a couple times. Also confused, but I think this is what you
are saying :
- You have a /19 aggregate that is announced via BGP to upstreams.
- You use an upstream RTBH service that will sink a particular destination
via a BGP announcement to a particular peer.
- When you add a /32 di
hough I haven't had reason or cycles to really ride it hard and see
where I can break it yet. :) )
On Fri, Feb 9, 2024 at 3:51 AM Saku Ytti wrote:
> On Thu, 8 Feb 2024 at 17:11, Tom Beecher via juniper-nsp
> wrote:
>
> > For any use cases that you want protocol interacti
will catch you on Juniper's metal ,
or your own metal for vMX, or cRPD ( assuming said bug is not hardware
dependent/related ).
On Thu, Feb 8, 2024 at 10:21 AM Mark Tinka wrote:
>
>
> On 2/8/24 17:10, Tom Beecher wrote:
>
> >
> > For any use cases that you want protocol
>
> I wouldn't consider cRPD for production. vRR (or vMX, if it's still a
> thing) seems to make more sense.
>
For any use cases that you want protocol interaction, but not substantive
traffic forwarding capabilities , cRPD is by far the better option.
It can handle around 1M total RIB/FIB using
>
> I am aware of a few major orders of the ACX7024 that Juniper are working
> on. Of course, none of it will become materially evidential until the
> end of 2024. That said, I think HP will give the box a chance, as there
> is a market for it. They might just put a time line on it.
>
I doubt this
>
> HPE will turn Juniper just like they turn 3com.
>
3Com's death started almost a decade before HP acquired them. They were
pretty much dead by the time that happened,
On Wed, Jan 10, 2024 at 2:38 PM Alexandre Figueira Guimaraes via
juniper-nsp wrote:
> HPE will turn Juniper just like they
>
> In our hubris to "decouple the control plane from the data plane (tm)",
> we, instead, decoupled the software/hardware integration from a single
> vendor.
>
I wouldn't necessarily agree that was the wrong *technical* decision.
Unfortunately, it was a perfect scenario to be exploited for the
MB
>
> Is there a difference between "MX204" and "MX204-HW-BASE"?
>
Strictly speaking they are just different SKUs, not different models.
MX204 : Chassis + Fan trays + PEMs
MX204-HW-BASE : Base MX204 chassis PLUS perpetual Junos software license
AFAIK , code that has enforcement is limited to speci
This is correct, they exist for the bypass LSPs.
I wouldn't characterize it as a dirty hack though. RFC4090 fast reroute
requires the backup pathways to be pre-computed for a sub-10ms switchover.
You put an export policy in place to make sure all labels (including
bypass) are in the FIB already. O
>
> Did I mention Arista is not spending valuable engineer time on all this
> license shit, but on actually making great products?
>
Oh they aren't?
https://www.arista.com/en/support/product-documentation/eos-feature-licensing
Arista will almost certainly move towards a licensing model similar t
MX304's.
>
> -Aaron
>
> On 10/24/2023 4:18 AM, Karl Gerhard via juniper-nsp wrote:
> > On 18/10/2023 18:55, Tom Beecher via juniper-nsp wrote:
> >> Juniper licensing is honor based. Won't impact functionality, will
> >> just grump at you on commits.
>
&g
Juniper licensing is honor based. Won't impact functionality, will
just grump at you on commits.
On Wed, Oct 18, 2023 at 10:32 AM Mark Tinka via juniper-nsp <
juniper-nsp@puck.nether.net> wrote:
>
>
> On 10/18/23 15:47, Aaron1 via juniper-nsp wrote:
>
> > Also, I get a license warning when commit
>
> Which in theory opens a new attack vector for the future.
>
What is the attack vector you foresee for a route sitting as hidden with
the potentially offending attributes stripped off?
On Thu, Aug 31, 2023 at 4:27 AM Tobias Heister via juniper-nsp <
juniper-nsp@puck.nether.net> wrote:
> Hi,
>
This PR may be worth asking about.
https://prsearch.juniper.net/problemreport/PR1693424
On Sat, Sep 2, 2023 at 7:08 PM Gonzalo Caceres via juniper-nsp <
juniper-nsp@puck.nether.net> wrote:
> Hi everyone,
>
> I have multicast traffic through a P2MP LSP and when this traffic goes
> through an EX
What this is saying:
If you have a GROUP level policy, and make any MODIFICATIONS to INDIVIDUAL
neighbor policies, that individual neighbor will reset.
This means adding OR removing the peer level policy will trigger the reset.
As I recall, it is because there is normally a single BGP Update IO
Start with the highest code version supported on the hardware that has all
the features you need.
Subtract 2 from the major revision number.
Pick a .3 version of that major revision.
Work towards current from there depending on test results, security needs,
etc.
On Wed, Aug 19, 2020 at 10:47 AM Co
This is the most recent Juniper document I had bookmarked for the QFX.
https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/protocols-edit-ddos-qfx-series.html
I agree with Saku that the ddos-policer is a good tool to use, but as he
said it requires turning f
Likely, but if you only need like 4 :)
On Wed, Mar 4, 2020 at 10:01 AM Mark Tinka wrote:
>
> On 4/Mar/20 16:53, Giuliano C. Medalha wrote:
>
> With the new MPC10 you can get 10 x 100G or 15 x 100G per slot in mx240 ,
> mx480 or mx960
>
> But you will need premium 3 chassis with scbe3 boards
You can still get 100G ports on the 960 chassis with MPC5E/6/7s , depending
on what kind of density you require.
On Wed, Mar 4, 2020 at 9:42 AM Mark Tinka wrote:
>
>
> On 4/Mar/20 16:36, Tom Beecher wrote:
> > It really depends on what you're going to be doing,but I still ha
It really depends on what you're going to be doing,but I still have quite a
few MX960s out there running pretty significant workloads without issues.
I would suspect you hit the limits of the MS-MPCs way before the limits of
the chassis.
On Wed, Mar 4, 2020 at 6:56 AM Ibariouen Khalid wrote:
>
This was, and still is, the most accurate answer in the thread. To expand
on it further
Cisco IOS images are standalone binary images. Each time the device is
powered on, it loads the image it is configured too, and executes it. The
entire operating system is encapsulated in this image file, a
n Thu Feb 28, 2019 at 03:19:36PM -0500, Tom Beecher wrote:
> >> These don't work on the 204?
> >>
> >> Red Alarm: jnxRedAlarmState 1.3.6.1.4.1.2636.3.4.2.3.1
> >> Yellow Alarm: jnxYellowAlarmState 1.3.6.1.4.1.2636.3.4.2.2.1
> >
> > They don'
These don't work on the 204?
Red Alarm: jnxRedAlarmState 1.3.6.1.4.1.2636.3.4.2.3.1
Yellow Alarm: jnxYellowAlarmState 1.3.6.1.4.1.2636.3.4.2.2.1
On Thu, Feb 28, 2019 at 2:51 PM Tarko Tikan wrote:
> hey,
>
> > i just found out that it seems not to be possible to poll Yellow/Red
> Alarm (Count or
So I missed your specific comment about being concerned about the bypass
LSPs.
I think (although I haven't tested this in forever) if you enable
no-node-protection under RSVP , that will prevent those interfaces from
being available for any node or link bypass LSP to use.
On Fri, Jan 25, 2019 at
Best option would be the coloring scheme along with explicit excludes in
the config for the LSPs you dont want to go through said device.
On Thu, Jan 24, 2019 at 3:25 PM Luis Balbinot wrote:
> That’s a good idea. I’m not 100% sure that this will prevent the creation
> of bypass LSPs but I’ll giv
I feel like I hit this once and had to use a rib-group.
But it would probably be helpful to see the relevant configs in full.
On Wed, Dec 19, 2018 at 10:52 PM Anderson, Charles R wrote:
> On Wed, Dec 19, 2018 at 03:41:40PM -0800, Chris Cappuccio wrote:
> > Nathan Ward [nw...@daork.net] wrote:
>
entation that $thing is dead.
>
> Surely I'm procrastinating with such pedantry here. =) :D
>
> -Original Message-----
> From: Chris Cappuccio [mailto:ch...@nmedia.net]
> Sent: 19 December 2018 22:18
> To: Tom Beecher
> Cc: Niall Donaghy ; Juniper List
> ; pasv...@
Lots of people (for better or for worse) may have hard linked / referenced
KB15585 in their documentation, so IMO it's a good idea to leave it up with
a bolded note of depreciation, which is what they did.
Expecting a bit of RTFM on the end user isn't that much, IMO.
On Wed, Dec 19, 2018 at 12:37
No problem!
@Niall : I can't remember if there was something under the hood that made
the discard *interface* more preferable than just a discard *route*. In our
implementation we have a qualified next-hop to send flagged traffic to a
local collector box first, and only discard if that's not reach
I’m pretty sure we drilled Juniper about the IPv6 discard interface thing a
few months ago and got a feature request in for that. One of our guys
wasted about 2 weeks on that.
On Fri, Oct 12, 2018 at 09:07 Niall Donaghy wrote:
> Hi Jason,
>
> Yes we (large ISP) tried using dsc interfaces (MX ser
Related, my company open sourced a tool we've been working on for network
telemetry at NANOG in Vancouver. I'm 95% sure that a JTI receiver is
functional on our internal builds, but they're still working on a few
things with streaming receivers generally, so it's not yet in the public
repo. May be
You have switches with completely different buffer depths than you used to.
You prob want to look into that.
On Tue, Oct 2, 2018 at 9:39 AM james list wrote:
> Dear experts
>
> I’ve a strange issue.
>
> Our customer replaced two L2/3 switches (C6500) where a pure L2 and L3
> (hsrp) environment w
There's no one magic knob that fixes CPU spikes in an MPLS environment.
They're all different. What I change to optimize mine might knock your
network over in 5 minutes. You need to determine what is triggering the
churn before you can reasonable optimize it. Take a look at logs and see
what is cau
In my view, the benefits of keeping them separate far outweigh the
additional effort of creating and managing the additional groups.
On Fri, Jun 29, 2018 at 11:01 AM, Rob Foehl wrote:
> Wondering aloud a bit... I've seen plenty of cases where wedging parallel
> v4/v6 sessions into the same BGP
Can confirm convergence time on the MX80 with even a single full table
session is extremely painful, and essentially not functional in a
production environment.
On Wed, Jun 27, 2018 at 7:10 AM, Dovid Bender wrote:
> Hi All,
>
> In my 9-5 I work for an ITSP where we have two MX5's with
> - iBGP
40 matches
Mail list logo
