Re: [j-nsp] BGP timer

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

Re: [j-nsp] BGP timer

BFD holddown is the right feature for this. WARNING: BFD holddown is known to be problematic between Juniper and Cisco implementations due to where each start their state machines for BFD vs. BGP. It was a partial motivation for BGP BFD strict:

Re: [j-nsp] MX204 and IPv6 BGP announcements

Correcting myself, yes, it’s discard. -- Jeff Juniper Business Use Only From: Mark Tinka Date: Thursday, February 8, 2024 at 9:07 AM To: Jeff Haas , Lee Starnes , "juniper-nsp@puck.nether.net" Subject: Re: [j-nsp] MX204 and IPv6 BGP announcements [External Email. Be cautious

Re: [j-nsp] MX204 and IPv6 BGP announcements

It’s rib-only. If you wanted the usual other properties, you’d use the usual other features. -- Jeff Juniper Business Use Only From: Mark Tinka Date: Thursday, February 8, 2024 at 12:14 AM To: Jeff Haas , Lee Starnes , "juniper-nsp@puck.nether.net" Subject: Re: [j-nsp] MX204 an

Re: [j-nsp] MX204 and IPv6 BGP announcements

On 2/6/24, 11:55 AM, "juniper-nsp on behalf of Mark Tinka via juniper-nsp" mailto:juniper-nsp-boun...@puck.nether.net> on behalf of juniper-nsp@puck.nether.net > wrote: > Typically, BGP will not originate a route to its neighbors unless it > already exists

Re: [j-nsp] Junos 21+ Killing Finger Muscle Memory - Resolved

And thank you all that responded to the request to open cases. Easy contributions to make the case, and far fewer meetings to resolve than it could have been. -- Jeff (who made noise, but did no source code commits) On 10/19/23, 12:48 AM, "juniper-nsp on behalf of Chris Kawchuk via

Re: [j-nsp] Q. Is anyone deploying TCP Authentication Option (TCP-AO) on their BGP peering Sessions?

[Warning: vendor anecdata follows] In bgp-land where we're a primary motivator, but only a client of tcp-ao, we've seen a few minor bugs from the field primarily dealing with keychain configuration or rollover issues in the last few years. Basically enough activity to suggest people are

Re: [j-nsp] CVE-2023-4481

On 8/31/23, 4:28 AM, "juniper-nsp on behalf of Tobias Heister via juniper-nsp" mailto:juniper-nsp-boun...@puck.nether.net> on behalf of juniper-nsp@puck.nether.net > wrote: > Am 30.08.2023 um 18:09 schrieb heasley via juniper-nsp: > > Tue, Aug 29, 2023 at

Re: [j-nsp] Junos 21+ Killing Finger Muscle Memory...

for good news to pass along in the near future. -- Jeff Juniper Business Use Only From: Chris Lee Date: Wednesday, July 26, 2023 at 10:16 PM To: Jeff Haas , "juniper-nsp@puck.nether.net" Subject: Re: [j-nsp] Junos 21+ Killing Finger Muscle Memory... [External Email. Be cautious

Re: [j-nsp] Junos 21+ Killing Finger Muscle Memory...

Juniper Business Use Only On 7/12/23, 12:11 PM, "Jeff Haas" mailto:jh...@juniper.net>> wrote: > On 7/12/23, 11:46 AM, "Mark Tinka" mailto:m...@tinka.afri> > <mailto:m...@tinka.afri <mailto:m...@tinka.afri>>ca> wrote: > > Will any of

Re: [j-nsp] Junos 21+ Killing Finger Muscle Memory...

On 7/12/23, 11:46 AM, "Mark Tinka" mailto:m...@tinka.afri>ca> wrote: > Will any of these issues register significantly on Juniper's roadmap of > how to make customers happier? Likely unlikely. Cynically, money moves things the best. But these comments don't fall on deaf ears. Occasionally,

Re: [j-nsp] Junos 21+ Killing Finger Muscle Memory...

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 small things to do to bgp policy. The policy

Re: [j-nsp] JunOS RPKI/ROA database in non-default routing instance, but require an eBGP import policy in inet.0 (default:default LI:RI) to reference it.

[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 is long-lived enough that VRFs started as a hack on a

Re: [j-nsp] SRTBH

In circumstances where the routing table can help you mitigate an attack, including things that use uRPF, it'll usually scale significantly better that flowspec. This is primarily because flowspec is just a distributed way of programming the firewall, and firewalls on transit routers have many

Re: [j-nsp] BGP export policy, group vs neighbor level

--- Begin Message --- Mostly in the interest of having better information circulating on this topic: While the idea below is in the right idea, it's wrong in details. The key detail here is that anything that causes a peer to not share the same rib-out with peers in the same group will cause a

Re: [j-nsp] Next-table, route leaking, etc.

--- Begin Message --- > On Feb 10, 2020, at 2:52 AM, Saku Ytti wrote: > > On Mon, 10 Feb 2020 at 05:08, Nathan Ward wrote: > > Hey Nathan, > >> Anyone got any magic tricks I’ve somehow missed? > > Olivier had a cute trick for this. This issue happens because it's the > same route, there is

Re: [j-nsp] rfc8097 (rpki) communities ?

--- Begin Message --- > On Mar 5, 2019, at 02:04, Job Snijders wrote: > > On Thu, Feb 28, 2019 at 04:17:19PM +0300, Alexandre Snarskii wrote: >> Somewhat stupid question: while experimenting with rpki, I found that >> while rfc8097 declares origin validation state as extended community >>

Re: [j-nsp] FlowSpec and RTBH

--- Begin Message --- Marcin, > On Oct 9, 2019, at 07:26, Marcin Głuc wrote: > I was wondering is there a way to export family flow routes (from > inetflow.0) to non flowspec BGP speaker? > For example tag Flowspec route with community and advertise this route with > different community to

Re: [j-nsp] Juniper route age reset behavior

Niall, I'll answer clarifying questions, but hope to remain mostly silent while people offer their opinions. On Apr 19, 2018, at 3:46 PM, Niall Donaghy > wrote: Jeff> Thus, a knob is being considered to have both the "only on-the-wire"

Re: [j-nsp] BGP4-MIB-v2

> On Mar 27, 2017, at 4:15 PM, Jeff Haas <jh...@juniper.net> wrote: > > >> On Mar 27, 2017, at 3:03 PM, Vincent Bernat <ber...@luffy.cx> wrote: >> >> ❦ 27 mars 2017 19:26 GMT, Jeff Haas <jh...@juniper.net> : >> >>> To your relevan

Re: [j-nsp] BGP4-MIB-v2

> On Mar 27, 2017, at 3:03 PM, Vincent Bernat <ber...@luffy.cx> wrote: > > ❦ 27 mars 2017 19:26 GMT, Jeff Haas <jh...@juniper.net> : > >> To your relevant next point: If the junos mib is in error, what to do about >> it? >> >> Very

Re: [j-nsp] BGP4-MIB-v2

On Mar 27, 2017, at 3:03 PM, Vincent Bernat <ber...@luffy.cx<mailto:ber...@luffy.cx>> wrote: ❦ 27 mars 2017 19:26 GMT, Jeff Haas <jh...@juniper.net<mailto:jh...@juniper.net>> : To your relevant next point: If the junos mib is in error, what to do about it? Very

Re: [j-nsp] BGP4-MIB-v2

> On Mar 27, 2017, at 12:43 PM, Vincent Bernat wrote: >>> So, 192.0.2.47 should be encoded to 4.192.0.2.47. >> >> Probably no. >> >> The headache here is that the underlying type is RFC 4001's >> InetAddress. As you can see in the documentation in that RFC the >> expectation

Re: [j-nsp] BGP4-MIB-v2

> On Jan 20, 2017, at 9:29 AM, Vincent Bernat wrote: > > Hey! > > I have been reported a (simple) bug in the implementation of the > BGP4-V2-MIB-JUNIPER. I know that if I open a JTAC case about this, I > will be asked a lot of unrelated questions, then I would be told that >

Re: [j-nsp] BFD Session

> On Mar 5, 2017, at 3:05 AM, Mohammad Khalil wrote: > > Hi all > I have a BFD session between two routers (which was working normally) > Currently , the session is down from one side and init from the other side > The ISIS adjacency is up > What could be the issue? The

Re: [j-nsp] under the hood of MP-BGP

Adam, On Jan 3, 2017, at 10:10 AM, adamv0...@netconsultings.com wrote: But what happens next or in parallel? Does BGP parse through the local MP-BGP table first in attempt to import at least the local routes into the NEW VRF as soon as possible? If there's

Re: [j-nsp] under the hood of MP-BGP

Adam, > On Dec 23, 2016, at 4:24 AM, adamv0...@netconsultings.com wrote: > Does anyone know any details about what's going on under the hood of MP-BGP > when a new VRF is configured? > > > > I'm only clear about this part: > > When a new RT import is configured or when the RT import is

Re: [j-nsp] BGP apparent I/O throttling on MX960 (JUNOS 14.1R6)

On Oct 24, 2016, at 9:41 AM, Adam Chappell > wrote: Anyone any experience with situations where "show bgp neighbor X.X.X.X" on JUNOS CLI produces a small appendix to the usual output stating: "Received and buffered octets: 20". 20 in this

Re: [j-nsp] Suppressing SNMP Trap to just one packet

Serge, Looks like this will be showing up in 15.1F6. -- Jeff > On Apr 11, 2016, at 11:48 AM, serge vautour wrote: > > Neat option. I have 15.1F5 running in the lab and don't see it as a regular > or hidden knob. The Juniper PR database doesn't list a "Resolved In"

Re: [j-nsp] Suppressing SNMP Trap to just one packet

I was clearing through old inbox stuff and noted this one. Conveniently there's at least progress here to report: > On Sep 9, 2015, at 9:40 AM, Alireza Soltanian wrote: > We are implementing SNMP Trap on Juniper routers. The case is when an event > occurred, device sends

Re: [j-nsp] BGP route filtering capabilities for inet-vpn (1/128) address family

http://www.juniper.net/documentation/en_US/junos15.1/topics/reference/configuration-statement/vpn-apply-export-edit-protocols-bgp-vp.html > On Jan 29,

Re: [j-nsp] setting named communities on static routes

> On Jan 28, 2016, at 2:16 PM, Chuck Anderson wrote: > > Does anyone know why Junos doesn't accept named communities for static > routes? This doesn't work: > > set routing-options static route 192.0.2.0/24 community TEST > set policy-options community TEST members 65000:100 >

Re: [j-nsp] aspath-regex to find any prepended routes

> On Jan 28, 2016, at 2:25 PM, Christopher Costa wrote: > > Is there an aspath-regex to find any prepended as-path? For example, > something like what's listed below, but the origin AS isn't known. > > show route aspath-regex ".* 12345{2,}" The functionality you're looking

Re: [j-nsp] Multi Core on JUNOS?

> On Oct 21, 2015, at 3:05 PM, Chad Myers wrote: > > Please don't go the IOS/EOS/non-Junos method for rpd where each protocol is > completely independent and isolated from the others. It is extremely helpful > to be able to do things like put communities on static

Re: [j-nsp] Multi Core on JUNOS?

> On Oct 21, 2015, at 3:21 PM, Tarko Tikan wrote: > > hey, > >> I always found using communities on non-BGP routes a little weird, >> but everyone has their favorite operational tricks. (And I try to >> seek out people to talk about them at conferences. It often leads to

Re: [j-nsp] Multi Core on JUNOS?

Adam, > On Oct 9, 2015, at 9:45 AM, Adam Chappell wrote: >> > I can imagine that making rpd MT is probably hard to the point of almost > not being worth the benefit (with current REs), unless one can adequately > break down the problem into divisable chunks of work that

Re: [j-nsp] dynamic prefix list based on as-path .. is it possible?

On Jul 29, 2015, at 10:58 AM, Tarko Tikan ta...@lanparty.ee wrote: hey, The issue with such well, that sounds easy solutions is what it does to system scale. In the days of 2G 32-bit RPD, the addition of a single*word* (4 bytes) to the route data structures was reason for massive

Re: [j-nsp] dynamic prefix list based on as-path .. is it possible?

.] On Jul 29, 2015, at 10:16 AM, Roland Dobbins rdobb...@arbor.net wrote: On 29 Jul 2015, at 21:02, Jeff Haas wrote: I don't have a clean answer, but it's leading me to ponder some. Just origin and/or destination AS would be useful in and of themselves, irrespective of further pathing

Re: [j-nsp] dynamic prefix list based on as-path .. is it possible?

Tim, On Jul 28, 2015, at 6:49 PM, tim tiriche tim.tiri...@gmail.com wrote: Hello, Goal: on transit provider link, allow ASN XYZ to reach port 80 and drop all other destined to port 80? I don't want to build a static filter as ASN XYZ could have additional updates. Not sure if

Re: [j-nsp] Junos BGP update generation inefficiency -cause for concern?

On May 18, 2015, at 8:08 AM, Julien Goodwin jgood...@studio442.com.au wrote: On 18/05/15 21:49, Saku Ytti wrote: The update-groups are created dynamically in JunOS as far as I know. That is if you have BGP group where neighbors have unique export policies, you will have multiple

Re: [j-nsp] vMX availability

On May 6, 2015, at 12:13 AM, Nathan Ward nw...@daork.net wrote: On 6 May 2015 at 12:20:21, Jeff Haas (jh...@juniper.net mailto:jh...@juniper.net) wrote: -- Jeff (who regularly uses VMX in-house for control plane testing) Have you done any BNG stuff on it? I’ve got a number

Re: [j-nsp] vMX availability

[responding to the original poster] On Apr 30, 2015, at 3:27 PM, Josh Baird joshba...@gmail.com wrote: Does anyone know if vMX is out in the wild yet? I was under the impression that lab/trial versions would be available through re-sellers in early March, but I haven't had any luck getting

Re: [j-nsp] AS65535 rejected in recent JunOS

I'm first to admit that we've done terrible mistake years ago by choosing 65535 as CE ASN, [...] But considering that in my biases I'm reading this wrong. It seems it would still be fundamentally against robustness principles to drop these prefixes. I think vendors would benefit on