regards,
Andrey
Nitzan Tzelniker via juniper-nsp писал(а) 2024-08-30 05:06:
Something I discovered a few days ago and I would like to understand if
others saw it and you mitigate it.
The em0/em3 (RE to PFE ) on Juniper MX is using a hardcoded MTU of
1500.
All of the traffic on that interface is
ption to mirror *OR*
not , and then accept *OR* discard, so whoever coded this just makes one
stanza for each option selected by the user, which is , HOLY SHIT stupid.
Juniper folks who I know are here : you should REALLY get them to fix this
if you're going to keep pushing that partnership. :
On Tue, 10 Sept 2024 at 22:57, Timur Maryin via juniper-nsp
wrote:
> EA utilization monitoring might not be straightforward on a first look
> But we have internal tools(script) which print data in nicely manner.
> JTAC may be able to share that.
It does have a single command to repo
On 26-Aug-24 15:43, Gustavo Santos via juniper-nsp wrote:
Awesome, thanks for the info!
Rules are like the one below.
after adjusting the detection engine to handle as /24 network instead of
/32 hosts the issue is gone..
As you said the issue was not caused by pps as the attack traffic was just
n MX240, MX480, and MX960 5G
Universal Routing Platforms when installed with a standard midplane."
https://www.juniper.net/documentation/us/en/hardware/mx-module-reference/topics/concept/mpc10e-15c-mrate.html
--Chris
_______
juniper-nsp maili
On Thu, Sep 5, 2024 at 7:37 AM Dario Amaya via juniper-nsp
wrote:
>
> We looking to upgrade to 100G using MPC7E-MRATE cards (with SCBE2-MX).
They work fine, we had several in production in both newer and older
MX480/MX960. MPC10 requires the newer backplane.
Side note about these cards
Hello
We are using MX480 routers that I understand are non-enhanced model:
Item Version Part number CLEI code FRU model number
Midplane REV 05 710-017414 CHAS-BP-MX480-S
They are the older blue/white with old Juniper logo, and not the newer
hey,
Maybe you'll find this interesting:
https://community.juniper.net/blogs/david-roy/2024/09/02/fast-lookup-tuple-an-innovative-filtering-feature
--
tarko
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/ma
On Aug 29, 2024, at 6:22 PM, Lee Starnes via juniper-nsp
wrote:
>
> Does anyone know of and can point to a document for doing a format and
> reinstall of the OS on the QFX5200 like what you can do on the EX series
> switches?
https://supportportal.juniper.net/s/article/Procedu
Something I discovered a few days ago and I would like to understand if
others saw it and you mitigate it.
The em0/em3 (RE to PFE ) on Juniper MX is using a hardcoded MTU of 1500.
All of the traffic on that interface is encapsulated with Juniper TTP
protocol
As a result, any control packet which
er technique the ACX needs which MX does not?
Chris
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
EX series
switches with the loader menu.
Best,
-Lee
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
first run into several
other actual problems, before you find the right problem.
--
++ytti
_______
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
I won’t pretend to speak for Corero. Prior to Juniper, I used to work for
another company that used flowspec for mitigations.
It’s my observation that tools in this space are good about generating
mitigations.
It’s also my observation that the underlying tooling for making sure that
the tips.
>
> As it is a "joint" solution by Corero / Juniper, they were supposed to
> know how to optimize or know platform limitations.
> Opened a Case with Corero to verify if they know something about that.
>
>
> Saku,
>
> There is a match filter / term
Thanks Jeff /Saku for the tips.
As it is a "joint" solution by Corero / Juniper, they were supposed to know
how to optimize or know platform limitations.
Opened a Case with Corero to verify if they know something about that.
Saku,
There is a match filter / term for counting all allow
. You're now making every packet hit that.
What will work nicely: Common layer4+ patterns with a prefix list.
-- Jeff
On 8/26/24, 09:43, "juniper-nsp on behalf of Gustavo Santos via juniper-nsp"
mailto:juniper-nsp-boun...@puck.nether.net> on behalf of
juniper-n
where.
>>
>> Unless you are really pushing very heavy PPS, I have difficulties
>> seeing 100 sensible FW rules impacting performance, not saying it is
>> impossible, but suspecting there is a lot more here. We'd need to deep
>> dive into the rules, PPE configurati
are
> dropping, they are absolutely accounted for somewhere.
>
> Unless you are really pushing very heavy PPS, I have difficulties
> seeing 100 sensible FW rules impacting performance, not saying it is
> impossible, but suspecting there is a lot more here. We'd need to deep
> dive i
ing it is
impossible, but suspecting there is a lot more here. We'd need to deep
dive into the rules, PPE configuration and load.
On Sat, 24 Aug 2024 at 23:35, Gustavo Santos via juniper-nsp
wrote:
>
> Hi,
>
> We have noticed that when a not so large number of firewall filters ter
nd
they are all fine ( under 50% fpc and under 10% RE).
Any thoughts?
Regards.
_______
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
.
Kind regards,
Andrey
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Hi Andrey,
can you share in what Junos version did you had these issues?
> On 23 Jul 2024, at 18:15, Andrey Kostin via juniper-nsp
> wrote:
>
> Tried to enable rib-sharding on several routers in last weeks and got bunch
> of problems.
> First, PE router with rib-s
Andrey Kostin писал(а) 2024-07-23 16:27:
Andrey Kostin via juniper-nsp писал(а) 2024-07-09 10:10:
Correction, rib-group with policy is used to copy received prefixes to
inet6.0 on in-line route-reflectors.
For off-ramp RRs to place prefixes into inet6.3 it's enough to configure
this
feature again in the
foreseeable future.
Kind regards,
Andrey
Luca Salvatore писал(а) 2024-06-26 15:18:
For what it's worth, we're happily running rib-sharding on many MX10K
devices on 22.2R3-S2.
NSR is fine and we haven't had any issues
On Sun, Jun 2, 2024 at 10:26 PM Gustavo
Andrey Kostin via juniper-nsp писал(а) 2024-07-09 10:10:
[...]
The problem here is that route-reflector selects a path with ipv4
mapped
nexthop and advertises it over ipv6 session. I'm wondering, is
anybody
already encountered this problem and found a solution how to make a
RR
to adve
a case on for sure, but this isn't going to kill drives
demonstrably faster.
On Thu, Jul 18, 2024 at 7:30 AM Joerg Staedele via juniper-nsp <
juniper-nsp@puck.nether.net> wrote:
> Hi,
>
> yes, it's the same. An no one seems to care about it? I mean, it will
> write co
Hi,
yes, it's the same. An no one seems to care about it? I mean, it will write
constantly data to the local storage and may cause the flash to fail ...
Very sad ☹
Regards
Joerg
-Original Message-
From: juniper-nsp On Behalf Of Timur
Maryin via juniper-nsp
Sent: Thursday, Ap
-option or should this just
work? I've not had this issue with the MX routers.
On 7/10/24 11:32, Jared Mauch via juniper-nsp wrote:
Here's my Juniper config:
dhcp-relay {
dhcpv6 {
overrides {
allow-snooped-clients;
}
Hi
Le lun. 8 juil. 2024 à 22:48, Wojciech Janiszewski via juniper-nsp
a écrit :
>
> Hi Phil,
>
> Seems that it's supported from 23.4
>
> https://apps.juniper.net/feature-explorer/feature-info.html?fKey=11993&fn=Logging%20support%20for%20routing%20engine%20shell%20and%
Here's my Juniper config:
dhcp-relay {
dhcpv6 {
overrides {
allow-snooped-clients;
}
relay-agent-option-79;
group FTTHCustomersv6 {
relay-agent-remote-id {
use-opti
16, 8, ":", option
dhcp6.client-linklayer-addr))),
" | PD Range: ", binary-to-ascii(16, 16, ":", suffix(option
dhcp6.ia-pd, 16)),
"/",
binary-to-ascii(10, 8, ":", substring(suffix(option
dhcp6.ia
got isc kea working with juniper acx5048 dhcpv6 relay... wanted to
circle back with y'all... the linux eng I work with said that isc kea
opensource version 2.4.1 on ubuntu 24.04 lts provides pd logging. this
might be your mention of "pretty minimal". Unsure what the "
Alexandre Snarskii писал(а) 2024-07-09 07:25:
On Mon, Jul 08, 2024 at 11:33:48AM -0400, Andrey Kostin via juniper-nsp
wrote:
[...]
The problem here is that route-reflector selects a path with ipv4
mapped
nexthop and advertises it over ipv6 session. I'm wondering, is anybody
al
On Mon, Jul 08, 2024 at 11:33:48AM -0400, Andrey Kostin via juniper-nsp wrote:
[...]
> The problem here is that route-reflector selects a path with ipv4 mapped
> nexthop and advertises it over ipv6 session. I'm wondering, is anybody
> already encountered this problem and found a s
Hi Phil,
Seems that it's supported from 23.4
https://apps.juniper.net/feature-explorer/feature-info.html?fKey=11993&fn=Logging%20support%20for%20routing%20engine%20shell%20and%20line%20card%20shell
HTH,
Wojciech
sob., 6 lip 2024, 08:27 użytkownik Phil Mawson via juniper-nsp <
>
> 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
Hi juniper-nsp readers,
Recently we encountered an issue with L3-incompletes counters started
incrementing on internal backbone links. It began after adding new PE,
core routers and route-reflectors.
After quite long investigation with TAC involved the problem was
identified: v6 traffic was
This depends greatly on how you've set up your support.
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.
But if you're going through a normal process, perhaps addition
4 at 11:07:48AM +0300, Saku Ytti via juniper-nsp wrote:
> For things like TAC use, what I've previously done is made a vendor
> shell, where the shell program is screen instead of shell, and screen
> is set up to log.
>
>
> On Sat, 6 Jul 2024 at 16:50, Job Snijders wrote
nd regards,
>
> Job
--
++ytti
___________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Kind regards,
Job
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
I don't believe there is any supported way to do this, an unsupported
way, probably, but also probably an educated operator could circumvent
it anyhow.
You probably shouldn't allow untrusted users to access the shell.
On Sat, 6 Jul 2024 at 09:26, Phil Mawson via juniper-nsp
wro
Hi,
Once a user enters the unix shell on a Juniper router/switch (Ie: start shell),
it appears all standard logging of the commands typed is not captured by syslog
and obviously not sent to AAA for authorisation.
Is there a way to capture all commands users type and send to an external
On 4 Jul 2024 at 4:42:35 AM, Aaron Gould via juniper-nsp <
juniper-nsp@puck.nether.net> wrote:
> how are we supposed to deploy ipv6 without the ability to log who has what?
>
Hi Aaron,
Are you doing subscriber services? In your first message you mention CPE,
so I presume so.
RADIU
Off topic, but one can always tcpdump and log that way.
-Michael
> -Original Message-
> From: juniper-nsp On Behalf Of Aaron
> Gould via juniper-nsp
> Sent: Wednesday, July 3, 2024 11:46 AM
> To: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] dhcpv6 IA_PD sysloggi
oh wait, i think you just answered that... pay for it.
-Aaron
On 7/3/2024 11:42 AM, Aaron Gould via juniper-nsp wrote:
how are we supposed to deploy ipv6 without the ability to log who has
what?
-Aaron
On 7/3/2024 10:10 AM, Gert Doering via juniper-nsp wrote:
Hi,
On Wed, Jul 03, 2024 at
how are we supposed to deploy ipv6 without the ability to log who has what?
-Aaron
On 7/3/2024 10:10 AM, Gert Doering via juniper-nsp wrote:
Hi,
On Wed, Jul 03, 2024 at 10:05:43AM -0500, Chris Adams via juniper-nsp wrote:
I haven't looked in a bit, but at one point Kea's built-in l
Hi,
On Wed, Jul 03, 2024 at 10:05:43AM -0500, Chris Adams via juniper-nsp wrote:
> I haven't looked in a bit, but at one point Kea's built-in logging was
> pretty minimal, with "ISP level" logging done as a paid add-on module.
> They've got to pay the bills,
x27;t looked in a bit, but at one point Kea's built-in logging was
pretty minimal, with "ISP level" logging done as a paid add-on module.
They've got to pay the bills, but I dislike that model.
--
Chris Adams
___________
juniper-nsp mailing l
uniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/dhcp-service-log-edit-systems.html
HTH,
Regards,
Wojciech
śr., 3 lip 2024, 06:26 użytkownik Aaron1 via juniper-nsp
napisał:
I see IA_PD prefix delegation logging in the local jdhcpd file. I
need the PD
Hi Aaron,
You can try log session option under dhcp-service process as described in
https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/dhcp-service-log-edit-systems.html
HTH,
Regards,
Wojciech
śr., 3 lip 2024, 06:26 użytkownik Aaron1 via juniper-nsp
prefix delegated addressing of
your customers?
Aaron
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
, * = Both
1234:abcd::1000::/56
*[Access/13] 00:13:04
> to fe80::62db:98ff:fe23:3633 via irb.1010
On 6/19/2024 2:47 PM, Jan Bacher via juniper-nsp wrote:
I am converting an older IOS-XE configuration to JunOS in a dual stack
environment.
Wh
For what it's worth, we're happily running rib-sharding on many MX10K
devices on 22.2R3-S2.
NSR is fine and we haven't had any issues
On Sun, Jun 2, 2024 at 10:26 PM Gustavo Santos via juniper-nsp <
juniper-nsp@puck.nether.net> wrote:
> I tried it again on JUNOS 21.4R3
I believe PD routes will be access route preference 13.
DCHPv6 IA_NA routes will be access-internal preference type 12, like
their IPv4 counterpart.
Bjørn
Aaron1 via juniper-nsp writes:
> When you look in the route table, do you see the v6 PD routes there? If so,
> are they
ethernet port on the ACX 5048 connected to the PC and apparently that woke up
the V6 neighbor discovery process.
Aaron
> On Jun 19, 2024, at 2:47 PM, Jan Bacher via juniper-nsp
> wrote:
>
> I am converting an older IOS-XE configuration to JunOS in a dual stack
> environ
On Jun 19, 2024, at 2:47 PM, Jan Bacher via juniper-nsp
> wrote:
>
> I am converting an older IOS-XE configuration to JunOS in a dual stack
> environment.
>
> What configuration statement(s) do I need to automatically import prefix
> delegations into ospf3? I see the
.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
s
astrology for men.
--
++ytti
___________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
r port shared with the CP,
> Perfect is the enemy of done
And enemy of security is lack of effort? Current BMCs would be
a step backward, imiho. I wish they were better; a lot of
potential..
_______
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck
we have is even worse.
--
++ytti
___________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Tue, Jun 18, 2024 at 07:20:12PM +0300, Saku Ytti via juniper-nsp:
> If you must use MGMT ETH, keep asking your vendors for true lights out
> ethernet, with its own CPU, DRAM and storage.
Yes, do that, please, but that does not really address the security
problems. BMCs typically are not u
Can always count on you. Thanks.
On Tue, Jun 18, 2024 at 12:20 PM Saku Ytti wrote:
> On Tue, 18 Jun 2024 at 18:56, Jason Iannone via juniper-nsp
> wrote:
>
> > I suppose the root question is do I have to apply a management filter on
> my
> > transit interfaces for in
On Tue, 18 Jun 2024 at 18:56, Jason Iannone via juniper-nsp
wrote:
> I suppose the root question is do I have to apply a management filter on my
> transit interfaces for in-band management traffic? Does ACX have a new (not
> fxp1) relationship between the RE and the external re0:mgmt-0
evo/overview-evo.pdf
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Dragan Jovicic via juniper-nsp писал(а) 2024-06-10 13:15:
The latter.
Can't modify STBs (they have default route).
Should be networking solution it seems.
Thanks...
IIRC, multicast topology don't have to match unicast topology. I
probably wouldn't mess up with trying to split
bted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
_____
Hi,
How do you steer traffic in GRT to 0/0 to proxy?
Extra NIC is not possible (can't modify STBs).
On Mon, Jun 10, 2024 at 6:14 PM Gert Doering wrote:
> Hi,
>
> On Mon, Jun 10, 2024 at 05:34:46PM +0200, Dragan Jovicic via juniper-nsp
> wrote:
> > Just brainstormin
Hi,
On Mon, Jun 10, 2024 at 05:34:46PM +0200, Dragan Jovicic via juniper-nsp wrote:
> Just brainstorming - what would be other possible solutions, if any?
> No source routing allowed to steer traffic to CGNAT.
> Putting another public IP on each STB is not possible.
> Putting IPv6 on
possible.
Putting IPv6 on STB just for Internet, is not possible.
Thanks
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
On Mon, 3 Jun 2024 at 05:26, Gustavo Santos via juniper-nsp
wrote:
> We will try it again later this year. If update threading / rib-sharding
> works as expected it will be better than having non stop routing running.
I think you need to contact support and work with them, NOS SW qual
tooks about 50
minutes to advertise all needed routes to one of the transit providers,
because the time it takes to send full routing tables feed to remote peers.
Em sex., 10 de mai. de 2024 às 16:45, Andrey Kostin via juniper-nsp <
juniper-nsp@puck.nether.net> escreveu:
> Hi ju
On 2024-05-30 11:52, Ola Thoresen via juniper-nsp wrote:
This is fun...
> show version
(...)
Model: acx7348
Junos: 23.4R1-S1.11-EVO
> show lldp neighbors*//*
^
'neighbors ' is ambiguous.
Possible completions:
neighbors Show LLDP neighbor information
neighbo
/ 91
degrees F
Module voltage : 3.268 V
Module max power : 2.5 W
(...)
Not sure it is worth creating a TAC-case...
/Ola (T)
___________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Hi
On Fri 17. May 2024 at 13.05, Daniel Verlouw wrote:
> Hi,
>
> On Thu, May 16, 2024 at 8:22 PM Antti Ristimäki via juniper-nsp
> wrote:
> > I thought this issue had been resolved already years ago, but I
> > noticed that JunOS still happily forwards IPv6 packets wi
Hi,
On Thu, May 16, 2024 at 8:22 PM Antti Ristimäki via juniper-nsp
wrote:
> I thought this issue had been resolved already years ago, but I
> noticed that JunOS still happily forwards IPv6 packets with link-local
> source address towards remote destinations. This of course violates
e packets? And can you drop
link-local in two forwarding-filter terms?
I know ND can be any permutation, but those can be handled in earlier
terms in iACL without matching addresses, by matching icmp6 types and
hop-limit 255.
--
++ytti
_______
juniper-ns
Hi,
On Fri, May 17, 2024 at 9:26 AM Saku Ytti wrote:
>
> On Thu, 16 May 2024 at 21:23, Antti Ristimäki via juniper-nsp
> wrote:
>
> > Does anyone have any insight into this? This issue was discussed on
> > this list already over 10 years ago, for example:
> > htt
On Thu, 16 May 2024 at 21:23, Antti Ristimäki via juniper-nsp
wrote:
> Does anyone have any insight into this? This issue was discussed on
> this list already over 10 years ago, for example:
> https://puck.nether.net/pipermail/juniper-nsp/2012-April/023134.html
Personally I'm not
anyone have any insight into this? This issue was discussed on
this list already over 10 years ago, for example:
https://puck.nether.net/pipermail/juniper-nsp/2012-April/023134.html
Antti
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https
ly no one knows what their policy regarding transit IP
packets are, and most accidentally change the policy from 'transit
all, unlimited' to 'transit none' by upgrading devices. Of course
generally this is the case for most things.
On Mon, 13 May 2024 at 13:36, Martin Tonusoo
-filters-L574:L585
Martin
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Hi juniper-nsp,
Just hit exactly the same issue as described in the message found in the
list archives:
Gustavo Santos
Mon Jan 4 15:13:18 EST 2021
Hi,
We got another MX10003 and we are updating it before get in production.
Reading the 19.4R3 release notes, we noticed that two
features
hat I
haven't spotted. Even if you sat in a lab for weeks you'd probably still be
missing something dangerous. Juniper should really come up with a better /
automated solution because the level of skill to get this right is insane.
Regards
Lee
On Thu, 2 May 2024, 16:32 Martin Tonusoo
r? Perhaps avoid an intermediate Ethernet switch between
both your routers, e.t.c.
Mark.
_______
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
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.
On Mon, Apr 29, 2024 at 9:31 AM Mark Tinka via ju
BGP-Peers-v4-VPN;
BGP-Peers-v4-LS;
}
protocol tcp;
source-port 1024-65535;
destination-port bgp;
}
then {
count :accept:tcp:BGP;
accept;
}
}
> -Original Message-
> From: juniper-nsp On Behalf Of Martin
> Tonuso
tination-port bgp;
}
then {
count accept-bgp-v4;
accept;
}
}
root@vmx1>
Martin
___________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
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 killin
path. Not being able to rely on link
state failure leaves us with requiring the use of BFD.
Again, thanks for all the replies everyone. I will check out the BFD
holddown.
-Lee
On Mon, Apr 29, 2024 at 5:43 AM Jeff Haas via juniper-nsp <
juniper-nsp@puck.nether.net> wrote:
>
> Jun
Juniper Business Use Only
On 4/29/24, 02:41, "Saku Ytti" mailto:s...@ytti.fi>> wrote:
> On Sun, 28 Apr 2024 at 21:20, Jeff Haas via juniper-nsp
> > BFD holddown is the right feature for this.
>
> But why is this desirable? Why do I want to prioritise stability
&g
g several times a year, down here, and it can get complex
especially if the route you are dealing with has no suitable alternative
options other than going round the continent and back.
Mark.
_______
juniper-nsp mailing list juniper-nsp@puck.n
nough.
My perspective is from this side of the world where backbone is not the
greatest experience in most of the inland markets. But I grant that such
scenarios are not the norm in more mature regions.
Mark.
___
juniper-nsp mailing list junipe
On Mon, 29 Apr 2024 at 10:13, Mark Tinka via juniper-nsp
wrote:
> It comes down to how you classify stable (well-behaved) vs. unstable
> (misbehaving) interfaces.
You are making this unnecessarily complicated.
You could simply configure that first down event doesn't add enough
poi
On Mon, 29 Apr 2024 at 10:07, Gert Doering via juniper-nsp
wrote:
> The interesting question is "how to react when underlay seems to be stable
> again"? "bring up upper layers right away, with exponential decay flap
> dampening" or "always wait 15 minutes
a given scenario.
Mark.
_______
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Hi,
On Mon, Apr 29, 2024 at 08:52:17AM +0200, Mark Tinka via juniper-nsp wrote:
> Protocols staying up despite the underlay being unstable means traffic dies
> and users are not happy. It's really that simple.
Yes, but that's a slightly different tangent. If the underlay is u
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
1 - 100 of 1102 matches
Mail list logo
