>
> 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
>
> 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
n 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 interaction, but not substantive
> &
>
> Is the same true for VMware?
>
Never tried it there myself.
be able to run a
> solid software-only OS than be a test-bed for cRPD in such a use-case.
AFAIK, cRPD is part of the same build pipeline as 'full' JUNOS, so if
there's a bug in any given version, it will catch you on Juniper's
>
> 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
>
> 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
>
> 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
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.
>
> 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
gt; -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.
>
>
__
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
>
> 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
17 matches
Mail list logo
