On 5/3/24 19:54, Lee Starnes wrote:
Hello Mark,
Thanks for asking. This is eBGP and the issue is that there have been
failures whereby the link does not fail, and thus can't track that
routes should be removed. BGP session has stayed up in some cases as
well, yet no traffic.
Yeah, if
On 4/29/24 17:42, Lee Starnes via juniper-nsp wrote:
As for BFD and stability with aggressive settings, we don't run too
aggressive on this, but certainly do require it because the physical links
have not gone down in our cases when we have had issues, causing a larger
delay in killing the
On 4/29/24 09:13, Saku Ytti wrote:
100%, what Mark implied was not what I was trying to communicate.
Sure, go ahead and damp flapping interfaces, but to penalise on first
down event, when most of them are just that, one event, to me, is just
bad policy made by people who don't feel the cost.
On 4/29/24 09:15, Saku Ytti wrote:
You are making this unnecessarily complicated.
You could simply configure that first down event doesn't add enough
points to damp, 2nd does. And you are wildly better off.
Perfect is the enemy of done and kills all movement towards better.
Fair enough.
On 4/29/24 09:06, Gert Doering wrote:
Yes, but that's a slightly different tangent. If the underlay is unstable,
I think we're all in agremeent that higher layers should not send packets
there.
It comes down to how you classify stable (well-behaved) vs. unstable
(misbehaving) interfaces.
On 4/29/24 08:31, Saku Ytti via juniper-nsp wrote:
But why is this desirable? Why do I want to prioritise stability
always, instead of prioritising convergence on well-behaved interfaces
and stability on poorly behaved interfaces?
If I can pick just one, I'll prioritise convergence every
On 4/3/24 18:06, Tom Beecher wrote:
My first thought was also to use BGP-LU.
Would a virtual router with an lt- interface connecting the VRF to the
global table be too expensive?
Mark.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
On 4/3/24 08:45, Saku Ytti wrote:
Actually I think I'm confused. I think it will just work. Because even
as the EgressPE does IP lookup due to table-label, the IP lookup still
points to egressMAC, instead looping back, because it's doing it in
the CleanVRF.
So I think it just works.
So OP
On 4/3/24 08:07, Saku Ytti via juniper-nsp wrote:
If I understand you correctly, the problem is not that you can't copy
direct into CleanVRF, the problem is that ScrubberPE that does clean
lookup in in CleanVRF, has label stack of [EgressPE TableLabel],
instead of [EgressPE EgressCE], this
On 2/17/24 17:12, Vincent Bernat via juniper-nsp wrote:
Hey!
I am a bit lost on how the MX10008 power supplies work. My main
question is how much power will be drawn if a power feed is lost?
If we take the JNP10K-PWR-AC2 dual feed with high power (30-A)
setting, configured for dual
On 2/11/24 12:10, james list via juniper-nsp wrote:
Dear experts
we have a couple of BGP peers over a 100 Gbs interconnection between
Juniper (MX10003) and Cisco (Nexus N9K-C9364C) in two different datacenters
like this:
DC1
MX1 -- bgp -- NEXUS1
MX2 -- bgp -- NEXUS2
DC2
MX3 -- bgp --
On 2/8/24 17:10, Tom Beecher wrote:
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 around 2G RAM, right in
Docker or k8. The last version of vMX I
On 2/8/24 16:29, Saku Ytti wrote:
In absence of more specifics, junos by default doesn't discard but
reject.
Right, which I wanted to clarify if it does the same thing with this
specific feature, or if it does "discard"
Mark.
___
juniper-nsp
On 2/8/24 15:48, Jeff Haas wrote:
It’s rib-only. If you wanted the usual other properties, you’d use
the usual other features.
So internally, if it attracts any traffic for non-specific destinations,
does Junos send it /dev/null in hardware? I'd guess so...
Mark.
On 2/8/24 09:56, Saku Ytti via juniper-nsp wrote:
Same concerns, I would just push it back and be a late adopter. Rock
existing vRR while supported, not pre-empt into cRPD because vendor
says that's the future. Let someone else work with the vendor to
ensure feature parity and indeed perhaps
On 2/8/24 09:56, Saku Ytti via juniper-nsp wrote:
Same concerns, I would just push it back and be a late adopter. Rock
existing vRR while supported, not pre-empt into cRPD because vendor
says that's the future. Let someone else work with the vendor to
ensure feature parity and indeed perhaps
On 2/8/24 09:50, Roger Wiklund via juniper-nsp wrote:
Hi
I'm curious, when moving from vRR to cRPD, how do you plan to manage/setup
the infrastructure that cRPD runs on?
I run cRPD on my laptop for nothing really useful apart from testing
configuration commands, e.t.c.
I wouldn't
On 2/6/24 19:42, Jeff Haas wrote:
And for situations where you need it nailed up:
https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/bgp-static-edit-routing-options.html
Interesting, never knew about this BGP-specific feature.
What does the
On 2/6/24 18:53, Saku Ytti wrote:
Not just opinion, fact. If you see everything, ORR does nothing but adds cost.
You only need AddPath and ORR, when everything is too expensive, but
you still need good choices.
But even if you have resources to see all, you may not actually want
to have a
On 2/6/24 18:48, Lee Starnes via juniper-nsp wrote:
Hello everyone,
I was having difficulty in getting an announcement of a IPv6 /32 block
using prefix-lists rather than redistribution of the IP addresses in from
other protocols. We only have a couple /64 blocks in use at the moment but
On 12/8/23 19:36, Jared Mauch via juniper-nsp wrote:
I’ll also comment that many software suites don’t scale to 10’s or 100’s of
million of paths
Keep in mind paths != routes and many folks don’t always catch the difference
between them. If you have a global network like 2914 (for
On 12/8/23 19:16, Saku Ytti via juniper-nsp wrote:
I tried to advocate for both, sorry if I was unclear.
ORR for good options, add-path for redundancy and/or ECMPability.
IME, when we got all available paths, ORR was irrelevant.
But yes, at the cost of some control plane resources.
On 12/8/23 18:57, Saku Ytti via juniper-nsp wrote:
Given a sufficient count of path options, they're not really
alternatives, but you need both. Like you can't do add-path , as
the clients won't scale. And you probably don't want only ORR, because
of the convergence cost of clients not
On 12/7/23 17:05, Saku Ytti via juniper-nsp wrote:
If you have a
low amount of duplicate RIB entries it might not be very useful, as
final collation of unique entries will be more or less single threaded
anyhow. But I believe anyone having a truly large RIB, like 20M, will
have massive
On 1/11/24 02:56, Chris Kawchuk via juniper-nsp wrote:
Shall we start taking bets on what stays, and what goes?
I'm glad that Rami gets to stay as CEO for the networking side of
things. Good lad, that...
Again, ACX was never a competitor to the ASR920 which I know Mr Tinka was very fond
On 1/10/24 21:30, Aaron Gould via juniper-nsp wrote:
https://newsroom.juniper.net/news/news-details/2024/HPE-to-Acquire-Juniper-Networks-to-Accelerate-AI-Driven-Innovation/
Glad to see Rami will be staying on.
Considering Juniper's current market cap of US$9.5 billion, that US$14
billion
On 1/10/24 19:50, Richard McGovern via juniper-nsp wrote:
The “difference” is that either SKU above does not contain a [Flex] Feature
License. Some Feature License, Adv or Prem, at some term (years or perpetual)
must now be included if you want any MX to do any L3 or above features. So
On 1/10/24 18:22, Tom Beecher wrote:
I wouldn't necessarily agree that was the wrong *technical* decision.
Unfortunately, it was a perfect scenario to be exploited for the
MBA-ification of everything that has greatly expanded in the past decade.
I agree.
Kind of like "not making a
On 1/10/24 09:04, Forrest Christian (List Account) wrote:
I find it frustrating that things one would expect to be included in
any layer 3 switch has become additional revenue opportunities.
"The switch hardware is $x. Oh you want the software too? Oh,
that's an additional cost. L3
On 1/9/24 11:47, Roger Wiklund wrote:
Yeah the ISP business is no fun, I feel like everyone secretly wishes
they can start buying Huawei again, It seems it's all about the
lowest price per 100G/400G port.
There is no shortage of cheap ports. The issue is how useful those ports
are
On 1/9/24 10:55, Saku Ytti via juniper-nsp wrote:
What do we think of HPE acquiring JNPR?
I guess it was given that something's gotta give, JNPR has lost to
dollar as an investment for more than 2 decades, which is not
sustainable in the way we model our economy.
Out of all possible
On 10/26/23 16:10, Aaron Gould wrote:
After tshooting with JTAC yesterday, they've determined the built-in
FPC to be a problem. They are doing RMA.
Strange that when the 60-day trail license expired, I decided to
reboot to see what would happen. I rebooted "request system reboot
On 10/26/23 15:47, Saku Ytti wrote:
I urge everyone to give them the same message as I've given.
Any type of license, even timed license, after it expires will not
cause an outage. And enforcement would be 'call home' via 'http(s)'
proxy, which reports the license-use data to Juniper sales,
So my SE came back to me a short while ago to say that at present,
routing protocols will not be disabled if an MX304 (or some future
box/code designed for the same authorization framework) does not have
the appropriate license installed.
He did add, however, that Juniper are considering
On 10/26/23 08:02, Saku Ytti wrote:
Even if you believe/think this, it is not in your best interest to
communicate anything like this, there is nothing you can win, and
significant downside potential.
As you can probably tell, I am not terribly politically correct :-). The
coddle culture
On 10/25/23 21:02, Richard McGovern via juniper-nsp wrote:
I tried to get my daughter (now Sr at Uni) to look at this field. Her response
was, “I don’t want to do anything like what you do”
At the risk of derailing this thread, one item that is generally
programmed into an agenda of
On 10/25/23 16:00, Gert Doering wrote:
What is "high-touch edge" for you?
Most things we could come up with do work, with the notable exception
of MAC accounting (or inclusion of MAC addresses in sflow/ipfix) - but
here the ASR9000 is one of the few platforms on the market that can
actually
On 10/25/23 15:36, Gert Doering via juniper-nsp wrote:
There goes another vendor...
Now, if the base price would have been *lowered* by the amount the
L3 features of a *MX router* cost extra now, this might have been an
option... but for my understanding, the base MX304 is already insanely
On 10/25/23 14:42, Saku Ytti via juniper-nsp wrote:
But we can reject licenses that expire in operation and cause an
outage. That I think is a very reasonable ask. I know that IOS XE for
example will do this, you run out of license and your box breaks. I
swapped out from CRS1k to ASR1k
On 10/25/23 10:57, Sebastian Wiesinger via juniper-nsp wrote:
Yeah it depends. Our MX204 also needed licenses for subscriber
managment. Some options would produce a license warning and some other
stuff just failed silently which was worse. Also noone at Juniper
seemed to know WHICH licenses
On 10/25/23 08:01, Saku Ytti via juniper-nsp wrote:
Juniper had assured me multiple times that they strategically have
decided to NEVER do this. That it's an actual decision they've
considered at the highest level, that they will not downgrade devices
in operation. I guess 'reboot' is not
On 10/19/23 06:48, Chris Kawchuk wrote:
Indeed. Apologies to all --- I too got an update from JNPR on the "show route" vs
"show routing" CLI conflict a few weeks ago in early September -- but forgot to share it
here.
CASE;
2023-0719-733950
Synopsis:
"show route" and "show routing"
On 10/18/23 19:05, Chris Wopat via juniper-nsp wrote:
Only complaint is Junos related, with auto tab complete problems as
extensively discussed in a different thread.
I have an update on that...
Our request was granted, and Juniper are initially targeting to fix this
in Junos 24.1.
On 10/18/23 18:55, Tom Beecher wrote:
Juniper licensing is honor based. Won't impact functionality, will
just grump at you on commits.
Okay, so usual licensing enforcement.
Just curious why warnings about OSPF and LDP... this is what a router is
exactly for.
Mark.
On 10/18/23 15:47, Aaron1 via juniper-nsp wrote:
Also, I get a license warning when committing OSPF and LDP. We got a license
from our account team and now we don’t see that message anymore
Any details on what this license does, and if there is any operational
risk if you don't apply it?
On 9/10/23 20:50, Mohammad Khalil via juniper-nsp wrote:
Greetings
Hope all is well.
I need to check if Juniper's BGP extended community settings are compatible
with Cisco's BGP extended community settings.
Is it possible to intercommunicate Juniper's BGP extended community with
Cisco BGP
On 9/5/23 17:05, Gonzalo Caceres via juniper-nsp wrote:
Hi Mark, thanks for the quick reply!
It is a problem that we have been having for some time, and we have not
received concrete answers from our SE. That's why I checked here, as I
haven't seen colleagues expressing this flaw in other
On 9/3/23 01:07, Gonzalo Caceres via juniper-nsp wrote:
Hi everyone,
I have multicast traffic through a P2MP LSP and when this traffic goes
through an EX or QFX series switch (spot EX4600 and QFX5110/5120) it is
lost. We use these switches as multilayer, they have MPLS suite protocols
(ISIS,
On 7/19/23 06:22, Mark Tinka wrote:
I'm trying with my SE too. Let's stay in touch.
Got a ticket opened with JTAC which my SE upstreamed, and it has been
linked to an internal PR that was raised on the back of Chris' ticket.
So all we can do now is wait.
Thanks, all.
Mark.
On 7/19/23 02:37, Chris Kawchuk wrote:
Hi Jeff
I'll open it with my SE here in Australia (Mark Barrett). Will advise once
complete.
I'm trying with my SE too. Let's stay in touch.
Mark.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
On 7/15/23 20:54, Crist Clark wrote:
I find it kind of telling that customers are just getting around to
complaining about it two years after it was released. Not at all
surprising, but illustrates how slow network operators update cycles
can be compared to the pace of development.
To
On 7/12/23 15:45, Jeff Haas wrote:
You don't need to tell my fingers that. __
With the infrastructure as it is, the only "solution" is we stop adding things.
Good luck with that.
The general here is the explosion of keywords. I have about 15 features
sitting in my backlog that are
On 7/12/23 15:38, Chris Wopat wrote:
Another offender in 21. `protocols bgp` doesn't autocomplete as it did
since `bgpmcast` was added.
me@r-mx304-lab-re1# set protocols bgp?
Possible completions:
> bgp BGP options
> bgpmcast BGP multicast options
Yes, that
On 7/12/23 15:08, Vladimir Blazhkun wrote:
You can probably deny that command using the login class ACL.
As I'd mentioned to someone else already, not looking to create custom
hacks that would not survive staff movement.
While it is an option, it would be one of extreme last resort.
On 7/12/23 11:12, Chris Kawchuk wrote:
+1 Mark!
For transparency, it was Chris who gave me the nudge, so thanks for
that, mate :-).
As any good problem begs for a solution, my suggestions to JNPR are as follows,
as alternative places for this command:
"show route transport-class
So, this is going to be a very priviledged post, and I have been
spending the last several months mulling over even complaining about it
either on here, or with my SE.
But a community friend sent me the exact same annoyance he is having
with Junos 21 or later, which has given me a final
On 7/4/23 09:11, Saku Ytti wrote:
You must have misunderstood. When they fully scale the current design,
the design offers 100T capacity, but they've bought 400T of ports. 3/4
ports are overhead to build the design, to connect the pizzaboxes
together. All ports are used, but only 1/4 are
On 7/2/23 18:04, Saku Ytti wrote:
Not disagreeing here, but how do we define oversubscribed here? Are
all boxes oversubscribed which can't do a) 100% at max size packet and
b) 100% at min size packet and c) 100% of packets to delay buffer, I
think this would be quite reasonable definition,
On 7/2/23 15:19, Saku Ytti wrote:
Right as is MX304.
I don't think this is 'my definition', everything was centralised
originally, until Cisco7500 came out, which then had distributed
forwarding capabilities.
Now does centralisation truly mean BOM benefit to vendors? Probably
not, but it
On 6/28/23 09:29, Saku Ytti via juniper-nsp wrote:
This of course makes it more redundant than distributed box, because
distributed boxes don't have NPU redundancy.
Well, by your definition, the ASR9903, for example, is a distributed
platform, which has a fabric ASIC via the RP, with 4x
On 7/2/23 11:18, Saku Ytti wrote:
In this context, these are all distributed platforms, they have
multiple NPUs and fabric. Centralised has a single forwarding chip,
and significantly more ports than bandwidth.
So to clarify your definition of "centralized", even if there is no
On 7/2/23 10:42, Saku Ytti wrote:
Yes. Satellite is basically VLAN aggregation, but a little bit less
broken. Both are much inferior to MPLS.
I agree that using vendor satellites solves this problem. The issue,
IIRC, is was what happens when you need to have the satellites in rings?
On 6/28/23 08:44, Saku Ytti wrote:
Apart from obvious stuff like QoS getting difficult, not full feature
parity with VLAN and main interface, or counters becoming less useful
as many are port level so identifying true source port may not be
easy. There are things that you'll just discover
On 6/27/23 19:44, Gert Doering wrote:
The issues we see / have with "satellites that are not real satellites"
are
- l2 link down -> l3 not going down
- (H-)QoS on the L3 device to avoid sending 10/100G worth of traffic
down to a 100M customer port, saturating the "vlan on trunk"
On 6/27/23 18:45, Tarko Tikan via juniper-nsp wrote:
Previously mentioned centralized boxes are actually becoming more and
more common now (in addition to non-redundant pizzabox formfactor that
has been available for ages) that single NPU can do 2+ Tbps. For BCM
J2 see ACX7509, Nokia
On 6/27/23 17:07, Saku Ytti wrote:
Yes.
How?
Like cat6500/7600 linecards without DFC, so SP gear with centralised
logic, and dumb 'low performance' linecards. Given low performance
these days is multi Tbps chips.
While I'm not sure operators want that, they will take a look if the
On 6/27/23 09:02, Saku Ytti wrote:
Juniper messaging seems to be geo-specific, in EU their sales seems to
sell them more willingly than in US. My understanding is that
basically fusion is dead, but they don't actually have solution for
access/SP market front-plate, so some sales channels are
On 6/26/23 20:56, Jackson, William via juniper-nsp wrote:
Similar use case here but we use a QFX as a fusion satellite if port expansion
is required.
Works well as an small site start up option.
Are vendors still pushing their satellite switches :-)?
That technology looked dodgy to me
Junos 22.4R2 that fixes this issue has been released...
Mark.
On 6/10/23 13:55, Mark Tinka wrote:
On 6/10/23 13:50, Jason Lixfeld wrote:
Do either of you two have PRs for your respective issues? If you could share,
I, for one anyway, would be grateful :)
For the PTX1000 issue:
On 6/10/23 13:50, Jason Lixfeld wrote:
Do either of you two have PRs for your respective issues? If you could share,
I, for one anyway, would be grateful :)
For the PTX1000 issue:
https://supportportal.juniper.net/s/article/PTX1000-resources-exhaustion-causing-host-loopback-wedge
On 6/9/23 17:46, Andrey Kostin via juniper-nsp wrote:
We have two MX204s running in pair with 2x100G taken for links
between them and remaining BW is 6x100G for actual forwarding in/out.
In this case it's kind of at the same level for price/100G value.
Yeah, using the MX204 like this
On 6/9/23 16:35, Saku Ytti wrote:
I'm not convinced at all that leaba is being sold. I think it's sold
conditionally when customers would otherwise be lost.
Probably - it's a "grain of salt" situation when you hear the news.
I don't think Meta and Microsoft have not bought zero of the
On 6/9/23 16:12, Saku Ytti wrote:
I expect many people in this list have no need for more performance
than single Trio YT in any pop at all, yet they need ports. And they
are not adequately addressed by vendors. But they do need the deep
features of NPU.
This.
There is sufficient
On 6/9/23 15:57, Andrey Kostin wrote:
Hi Mark,
Not sure why it's eye-watering. The price of fully populated MX304 is
basically the same as it's predecessor MX10003 but it provides 3.2T BW
capacity vs 2.4T.
That's true, but the premium being paid for 400Gbps capability that some
houses
On 6/9/23 00:03, Litterick, Jeff (BIT) via juniper-nsp wrote:
The big issue we ran into is if you have redundant REs then there is a super
bad bug that after 6 hours (1 of our 3 would lock up after reboot quickly and
the other 2 would take a very long time) to 8 days will lock the entire
On 6/8/23 18:39, Giuliano C. Medalha wrote:
but you have the flex model. With license for capacity and features.
Advanced and Premium.
Which isn't a new thing with vendors. The prices are just terrible, even
with discounts.
fib is better now - 12M
sampling rate for ipfix is better
On 6/8/23 17:35, Giuliano C. Medalha wrote:
Hello good afternoon.
Please have a look at the following documentation:
https://community.juniper.net/blogs/reema-ray/2023/03/28/mx304-deepdive
Thanks, this is most useful!
It will have everything you need to do with it, including the
On 6/8/23 17:18, Kevin Shymkiw wrote:
Along with this - I would suggest looking at Port Checker (
https://apps.juniper.net/home/port-checker/index.html ) to make sure
your port combinations are valid.
We've had ample experience with Juniper's MPC7E, MX204, PTX1000 and
PTX10001 to know how
So, we decided to give the MX304 another sniff, and needed to find out
why Juniper charge a license for 16x 100Gbps ports per line card, and
yet the data sheet suggests the box can handle 48x 100Gbps ports
chassis-wide.
Well, turns out that if you deploy it with redundant RE's, you get 32x
On 6/6/23 09:27, Saku Ytti wrote:
I am not implying it is pragmatic or possible, just correct from a
design point of view.
Commercial software deals with competing requirements, and these
requirements are not constructive towards producing maintainable clean
code. Over time commercial
On 6/5/23 23:26, Jeff Haas via juniper-nsp wrote:
[Note that I've already inquired internally about the original problem. I
don't recall the answer from top of head and don't have time for code
spelunking...]
As to the point below, we get to these headaches one commit at a time. Junos
On 6/5/23 09:46, Saku Ytti via juniper-nsp wrote:
It is safer to put the service (internet) in VRF, and leave the main
table for signalling and NMS, if you want to create this distinction.
It will also make it a lot more convenient to leak between instances
and create subInternets, like
On 3/23/23 14:15, Tom Storey via juniper-nsp wrote:
We have A+B power delivered 3 phase to the racks, broken out on PDUs, but I
think I must have been thinking about another platform in regards to not
splitting PSUs across phases.
Right, data centre providers will deliver power to your
On 3/23/23 10:29, Gert Doering wrote:
"typical" data centres over here have 2 primary feeds, either one
with UPS and one with generator, or both with (different) UPSes - but
depending on the load drawn by a rack, might be presented as multiple
circuits with 16A each, and individual circuit
On 3/22/23 17:27, Tom Storey via juniper-nsp wrote:
Hi all.
I had this idea in my head that MX960 power supplies should not be split
across phases, but I cant find anything in any documentation that says that.
Can anyone comment on whether multiple phases per PEM are supported, or
whether
On 12/31/22 14:04, Giuliano C. Medalha via juniper-nsp wrote:
Good Morning
Think it is 10M RIB and 1.5M FIB ( need to check )
CPU is x86 running with 32GB of RAM.
FIB is 1 - 2 million entries.
Mark.
___
juniper-nsp mailing list
On 7/2/22 20:00, Randy Bush via juniper-nsp wrote:
- old m7i with RE-B-1800X1-4G-S
- currently running 14.2R7.5
- hard disk dying
- have nice new 1tb sata ssd for it
- juniper support download is pushing 15.1R7.9 at me
- should i worry about increased memory use or license changes in 15?
- if
On 6/27/22 21:22, Mark Tinka wrote:
I'm having a meeting with them about all this on Thursday. If anything
is exciting, and I can share, I will.
As promised, below is what has developed:
As it pertains to the both the MX204 and MX10003, Juniper have made the
following amendments:
On 6/27/22 18:22, Olivier Benghozi via juniper-nsp wrote:
I guess that the right thing to do would be to provide a licence based model
for MX304 with an entry level capacity licence priced as the MX204 currently
is...
That would, indeed, be the right thing. But it's the wild west in
On 6/27/22 18:15, Giuliano C. Medalha wrote:
MX204 was announced at EoS
We have used MX204 for last 5 years. It was a huge success for any
function it was designed.
We intend to keep running ours until the 2nd coming :-).
I don't have time for Juniper's nonsense.
Juniper only
On 6/24/22 11:01, Saku Ytti wrote:
Many ways to skin the cat. If you can dedicate small router to the
scrubber (or routing-instance if you can't) and you run BGP-LU, so you
avoid useless egress IP lookup, you just ensure that the scrubber PE
or scrubber instance doesn't have the more
On 6/24/22 09:28, Saku Ytti via juniper-nsp wrote:
In many ways filter based decapsulation is actually preferable to
interface, so I have no large qualms here. What I'd actually want is
egress filter decap, instead of ingress. So I could point my GRE
tunnels to random addresses at customer
On 6/17/22 11:05, Saku Ytti via juniper-nsp wrote:
Hi,
I'd like to return to this topic. I was confused earlier,
misattributing the issue I'm seeing to MX. And now it is clear it must
be on PTX.
I'd again solicit for input for anyone seeing in their syslogs:
a) junos: 'received pdu -
On 5/7/22 16:32, Michael Hare wrote:
Mark,
I was told by JTAC that the 19.1 default "'set protocols bgp graceful-shutdown
receiver" does exactly that [blindly trusts 65535:0 as zero] for iBGP learned
routes, but not eBGP. Unless I'm daft that's not what their public documentation implies.
On 4/18/22 17:24, Michael Hare via juniper-nsp wrote:
Hello,
Is anyone using "bgp graceful-shutdown receiver" successfully out-of-the-box
for eBGP peers without modifying their import policies to account for 65535:0?
For example our production AS peers with lab AS over eBGP. Import policy
On 5/5/22 22:46, Joel Jaeggli via juniper-nsp wrote:
What are people doing at this point to subscribe to vendor specific
juniper vulnerability publication.
We rely on the TSB (Technical Support Bulletin) e-mails that come
through with vulnerabilities, and the code in which they are
On 4/13/22 18:25, Chris Wopat via juniper-nsp wrote:
Dario -
Friendly heads up that the annual support costs on MPC7E is incredibly
expensive.
So high that pre-pandemic prices it would've been cheaper to just buy
one off of eBay than pay for a year of support (If this matters to
you)
I
--- Begin Message ---
On 4/13/22 15:50, Dario Amaya via juniper-nsp wrote:
Hello,
Does anybody know if this card (MPC4E-3D-2CGE-8XGE) is compatible with
the SCBE-MX ?
Nope, never used it before.
This site says yes:
On 3/25/22 11:21, Mihai via juniper-nsp wrote:
In my case I just upgraded one MX204 in the lab to 21.2R2, enabled
rib-sharding and increased the JunosVM memory to 24G and things look
better now.
Glad to hear!
Mark.
___
juniper-nsp mailing list
On 3/25/22 02:58, Gustavo Santos via juniper-nsp wrote:
Hi,
I think that I was the only one with this issue.
From their feedback, it seems the issue of scaling outbound updates of
full tables to eBGP neighbors is known within Juniper, because they told
us they have had to come up with
1 - 100 of 108 matches
Mail list logo
