Re: [j-nsp] BGP timer

[Jeff Haas via juniper-nsp]

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
> always, instead of prioritising convergence on well-behaved interfaces
> and stability on poorly behaved interfaces?

This feature is "don't bring up BGP on interfaces that aren't stable enough to
let BFD stay up".  The intended use case is when you have an interface noisy
enough that TCP can fight its way through keeping BGP up... enough, but not
stable enough that you'd really want to forward over it.  The assessment for
that is "BFD will go down in short order".

> That is, if I cannot have exponential back-off, I won't kill
> convergence 'just in case', because it's not me who will feel the pain
> of my decisions, it's my customers. Netengs and particularly infosec
> people quite often are unnecessarily conservative in their policies,
> because they don't have skin in the game, they feel the upside, but
> not the downside.

People make decisions that are appropriate for their networks.  Using BFD on
your BGP sessions is probably overkill *for you*.  Don't do that then.

-- Jeff

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] BGP timer

[Jeff Haas via juniper-nsp]

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:
https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-bfd-strict-mode

BGP BFD strict was added in 23.2R1.

-- Jeff


On 4/28/24, 05:13, "juniper-nsp on behalf of Thomas Bellman via juniper-nsp" 
mailto:juniper-nsp-boun...@puck.nether.net> on behalf of 
juniper-nsp@puck.nether.net > wrote:


[External Email. Be cautious of content]





Juniper Business Use Only
On 2024-04-27 09:44, Lee Starnes via juniper-nsp wrote:


> Having difficulty finding a way to prevent BGP from re-establishing after a
> BFD down detect. I am looking for a way to keep the session from
> re-establishing for a configured amount of time (say 5 minutes) to ensure
> we don't have a flapping session for a. link having issues.


Isn't that what the holddown-interval setting does? It is limited
to 255 seconds (4 minutes 15 seconds), though, and for BGP it is
only allowed for EBGP sessions, not iBGP sessions.


The documentation also says that you need to set holddown-interval
on *both* ends. I'm gueesing that the holddown only prevents your
end from initiating the BGP session, but that it will still accept
a connection initiated from the other end.


https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/bfd-liveness-detection-edit-protocols-bgp.html
 



I haven't used BFD for BGP myself, though, only for static routes
on a couple of links. But there I do use holddown-interval, and
at least when I set it up several years ago, it seemed to do what
I expected: after the link and the BFD session came up again, it
waited (in my case) 15 seconds before enabling my static route
again.




--
Thomas Bellman, National Supercomputer Centre, Linköping Univ., Sweden
"We don't understand the software, and sometimes we don't understand
the hardware, but we can *see* the blinking lights!"





___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Jeff Haas via juniper-nsp]

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 of content]


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.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Jeff Haas via juniper-nsp]

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 and IPv6 BGP announcements

[External Email. Be cautious of content]


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 router do with this in FIB? Same as a a regular static route 
pointing to 'discard'? Or does it just stay in RIB?

Mark.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Jeff Haas via juniper-nsp]

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 in the routing table through some source. If it is an
> aggregate route, a hold-down pointing to "discard" (Null0 in Cisco) is
> enough. If it is a longer route assigned to a customer, that route
> pointing to the customer will do.

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


Juniper Business Use Only
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Jeff Haas via juniper-nsp]

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 
juniper-nsp" mailto:juniper-nsp-boun...@puck.nether.net> on behalf of 
juniper-nsp@puck.nether.net > wrote:


[External Email. Be cautious of content]




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" operational mode CLI conflict - JunOS 21+


Root Cause:
"show routing" CLI stanza was unhidden to implement "show routing 
transport-class" command for BGP CT (in JunOS 21+)


Resolution:
For finger memory convenience, hiding 'show routing' stanza again, and moving 
BGP CT command to under 'show route' stanza.
Understanding is: "show route" will now contain both:
- route table related information, AND
- routing daemon related information.




-


Looks like it's a win for the little guy!.. or at least... my little finger 
that wants to smash that [TAB] key early


- CK.






> On 19 Oct 2023, at 15:11, Mark Tinka via juniper-nsp 
> mailto:juniper-nsp@puck.nether.net>> wrote:
>
>
>

Juniper Business Use Only
> 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. However, there are ongoing discussions to introduce this into 
> 23.3R2.
>
> So we may soon see the back of this.
>
> Mark.
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net 
> 
> https://urldefense.com/v3/__https://puck.nether.net/mailman/listinfo/juniper-nsp__;!!NEt6yMaO-gk!C_6PZngMiSXTB1xXpGghoUeKt-rg44pq-PsMHtvBZylmhWDehdYkTbkgVwgj1HU0JVwhzsN8yZ4YLoXD_Cbv8ss$
>  
> 


___
juniper-nsp mailing list juniper-nsp@puck.nether.net 

https://urldefense.com/v3/__https://puck.nether.net/mailman/listinfo/juniper-nsp__;!!NEt6yMaO-gk!C_6PZngMiSXTB1xXpGghoUeKt-rg44pq-PsMHtvBZylmhWDehdYkTbkgVwgj1HU0JVwhzsN8yZ4YLoXD_Cbv8ss$
 




___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Jeff Haas via juniper-nsp]

[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 minimally playing with it, to possibly deploying 
it.  The folk in JTAC would be able to tell us more by mining configs, but for 
good reasons they don't want us poking through customer configs too 
arbitrarily.  In terms of my experience for "bug activity as a proxy for 
deployment", I'd guess we're still moving in early stages, but it's happening.

The fact that tcp-ao support in linux is becoming more pervasive will likely 
help us close some gaps and likely provide better support for vendors that use 
that as their underlying OS.

One note to keep in mind in terms of roll-out is implementations with NSR 
support have to do rather unpleasant things to TCP stacks in order to implement 
an already tricky feature.  This is one of the reasons why deployment across 
vendors is slow.

-- Jeff

On 9/27/23, 1:35 AM, "juniper-nsp on behalf of Saku Ytti via juniper-nsp" 
mailto:juniper-nsp-boun...@puck.nether.net> on behalf of 
juniper-nsp@puck.nether.net > wrote:


[External Email. Be cautious of content]





Juniper Business Use Only
On Wed, 27 Sept 2023 at 03:50, Barry Greene via juniper-nsp
mailto:juniper-nsp@puck.nether.net>> wrote:


> Q. Is anyone deploying TCP Authentication Option (TCP-AO) on their BGP 
> peering Sessions?
>
> I’m not touching routers right now. I’m wondering if anyone has deployed, 
> your experiences, and thoughts?


For the longest time (like close to decade) no one supported it at
all, not even Juniper, because Juniper implementation was pre-RFC
which was incompatible with RFC.


To my understanding today there is support in Junos, IOS-XE, IOS-XR,
SROS, EOS and VRP. I have no operational experience to share.


--
++ytti
___
juniper-nsp mailing list juniper-nsp@puck.nether.net 

https://urldefense.com/v3/__https://puck.nether.net/mailman/listinfo/juniper-nsp__;!!NEt6yMaO-gk!D7sD_mpaj-TIBufn4Z23joLPE5sAOkFNYOp61NWZUc66Runi5hGMtg5vhM1F-mCgYZyo2cZQFupyvEgQgWODqps$
 




___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Jeff Haas via juniper-nsp]

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 03:42:41PM -0700, David Sinn via juniper-nsp:
> >> A network I operate is going with:
> >>
> >> bgp-error-tolerance {
> >> malformed-route-limit 0;
> >> }
> >>
> >> The thoughts being that there is no real reason to retain the malformed 
> >> route and the default of 1000 is arbitrary. We haven't really seen a rash 
> >> of them, so adjusting the logging hasn't proven needed yet.
> >
> > It does seem arbitrary. retaining all seems like a better choice,
> > operationally. allowing the operator diagnose why a route is missing;
> > show route  hidden.

That's the exact use case.  Otherwise it's yet another completely arbitrary
case of, "where did this route go and do we have zombies to worry about?"

> Which in theory opens a new attack vector for the future.
>
> As the update is malformed it could do $something to the handling in
> e.g. RPD or other daemons by processing them somehow wrong. By not
> holding or further process any of them that could (maybe, hopefully?) be
> minimized.

You're encouraged to engage in whatever level of paranoia here that makes you
happy operationally.  The internal behavior is we throw out the portion of the
path attribute that was decided to be bad.  We spent a fair amount of time
doing audit over various bits of code that interact with such stripped path
attribute sets, like logging and tracing.  That said, we've had bugs over the
years in logging, trace, etc. that may be fixed in current versions but perhaps
not past ones.  I can't identify any bug of concern in running releases from
memory.

Thus, if you're more comfortable with just throwing the things out and not
worrying about tracking down routes that are bad, go for it.  It's a supported
scenario.

> Of course proper code and handling of malformed things would be even
> better, but you know ...

For the moment, this depends on configuration of the error-tolerance "feature".
Making the behavior default is working its way through management for a
targeted release.

-- Jeff


Juniper Business Use Only
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Jeff Haas via juniper-nsp]

Chris,

The point was raised internally as part of this discussion.  No clue what our 
manageability folk think about the difficulty to implement this.

That said for the rest of the thread, thanks for ensuring we get some customer 
PRs in the system for the originally reported issue.  I’m hoping 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 of content]

Hi Jeff,

Any chance the CLI could make use of repeated presses of the TAB key to cycle 
through the completion options ?

For instance in the newer 21.x release for EX switches I note a 
"synchronous-ethernet" option under the show level, and my muscle memory for 
"show system" was reduced down to "show sy" - so could the CLI say show the "sy 
is ambiguous" option upon the first TAB press, but when you press TAB again it 
then autocompletes "synchronous-ethernet" and another TAB press to autocomplete 
"system" ?

root> show sy
 ^
'sy' is ambiguous.
Possible completions:
  synchronous-ethernet  Show synchronous ethernet related information
  system   Show system information
{master:0}
root>

Regards,
Chris

On Wed, Jul 12, 2023 at 11:45 PM Jeff Haas via juniper-nsp 
mailto:juniper-nsp@puck.nether.net>> 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 small things to do to bgp policy.  The policy 
stanza is already a mess.

... and that's not including the work to let users match on flowspec filter 
components.

The CLI could be taught to not include certain auto-completions as a 
user-profile, locally, with hints from TACACS, etc... but it means we get into 
an inconsistent user experience.

Feel free to spend some collective thinking time on what a "this would suck 
less" solution would look like.  I suspect that the competing opinions on what 
to do will eventually involve a cage fight match.

-- Jeff


On 7/12/23, 9:39 AM, "juniper-nsp on behalf of Chris Wopat via juniper-nsp" 
mailto:juniper-nsp-boun...@puck.nether.net>
 
<mailto:juniper-nsp-boun...@puck.nether.net<mailto:juniper-nsp-boun...@puck.nether.net>>
 on behalf of juniper-nsp@puck.nether.net<mailto:juniper-nsp@puck.nether.net> 
<mailto:juniper-nsp@puck.nether.net<mailto:juniper-nsp@puck.nether.net>>> wrote:


[External Email. Be cautious of content]




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




https://www.juniper.net/documentation/us/en/software/junos/multicast/topics/ref/statement/bgpmcast.html
 
<https://www.juniper.net/documentation/us/en/software/junos/multicast/topics/ref/statement/bgpmcast.html>
___
juniper-nsp mailing list 
juniper-nsp@puck.nether.net<mailto:juniper-nsp@puck.nether.net> 
<mailto:juniper-nsp@puck.nether.net<mailto:juniper-nsp@puck.nether.net>>
https://urldefense.com/v3/__https://puck.nether.net/mailman/listinfo/juniper-nsp__;!!NEt6yMaO-gk!GRWZYDw9dknfYLkcYhOG-D5DqdTOx4pztouooXch-W7lRlj5lUC_M0CkQf0rZBK0JIiXkU_l-ETb8ikzbZEKXVg$<https://urldefense.com/v3/__https:/puck.nether.net/mailman/listinfo/juniper-nsp__;!!NEt6yMaO-gk!GRWZYDw9dknfYLkcYhOG-D5DqdTOx4pztouooXch-W7lRlj5lUC_M0CkQf0rZBK0JIiXkU_l-ETb8ikzbZEKXVg$>
 
<https://urldefense.com/v3/__https://puck.nether.net/mailman/listinfo/juniper-nsp__;!!NEt6yMaO-gk!GRWZYDw9dknfYLkcYhOG-D5DqdTOx4pztouooXch-W7lRlj5lUC_M0CkQf0rZBK0JIiXkU_l-ETb8ikzbZEKXVg$<https://urldefense.com/v3/__https:/puck.nether.net/mailman/listinfo/juniper-nsp__;!!NEt6yMaO-gk!GRWZYDw9dknfYLkcYhOG-D5DqdTOx4pztouooXch-W7lRlj5lUC_M0CkQf0rZBK0JIiXkU_l-ETb8ikzbZEKXVg$>>




Juniper Business Use Only
___
juniper-nsp mailing list 
juniper-nsp@puck.nether.net<mailto:juniper-nsp@puck.nether.net>
https://puck.nether.net/mailman/listinfo/juniper-nsp<https://urldefense.com/v3/__https:/puck.nether.net/mailman/listinfo/juniper-nsp__;!!NEt6yMaO-gk!H_Mzg5Dsl-LClWOn2Hf7PEvfnmCaJBbS22AsK8jAMErwIu9icUXgXw38H6awbx1AmZmraooHJ5EiEkVn$>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Jeff Haas via juniper-nsp]

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 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, they fall on ears 
> that just solve the problem. Sadly, for this one, that's not in my power to 
> unilaterally address.

Apparently not unilaterally.

I am in need of someone with a current support contract to open a customer
issue on the "show routing" collision and push for that issue to generate an
internal PR.  Please unicast me the case#s.

No promises though.

-- Jeff

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Jeff Haas via juniper-nsp]

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, they fall on ears 
that just solve the problem.  Sadly, for this one, that's not in my power to 
unilaterally address.

Minimally, this has prodded a conversation about "why wasn't this considered 
during our process reviews?"

-- Jeff


Juniper Business Use Only
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Jeff Haas via juniper-nsp]

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 
stanza is already a mess.

... and that's not including the work to let users match on flowspec filter 
components.

The CLI could be taught to not include certain auto-completions as a 
user-profile, locally, with hints from TACACS, etc... but it means we get into 
an inconsistent user experience.

Feel free to spend some collective thinking time on what a "this would suck 
less" solution would look like.  I suspect that the competing opinions on what 
to do will eventually involve a cage fight match.

-- Jeff


On 7/12/23, 9:39 AM, "juniper-nsp on behalf of Chris Wopat via juniper-nsp" 
mailto:juniper-nsp-boun...@puck.nether.net> on behalf of 
juniper-nsp@puck.nether.net > wrote:


[External Email. Be cautious of content]




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




https://www.juniper.net/documentation/us/en/software/junos/multicast/topics/ref/statement/bgpmcast.html
 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net 

https://urldefense.com/v3/__https://puck.nether.net/mailman/listinfo/juniper-nsp__;!!NEt6yMaO-gk!GRWZYDw9dknfYLkcYhOG-D5DqdTOx4pztouooXch-W7lRlj5lUC_M0CkQf0rZBK0JIiXkU_l-ETb8ikzbZEKXVg$
 





Juniper Business Use Only
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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.

[Jeff Haas via juniper-nsp]

[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 system that didn't have 
them.  A completely new system written from scratch likely would just assume 
arbitrary tables that can be spaghetti configured into whatever you want to do 
with them.

When I was first studying the Juniper implementation of L3VPN VRFs, some of the 
rib-group constructs didn’t make a lot of sense to me.  It was rather clearer 
after discovering that when the features were released in the 9.x (?) releases 
that all of the niceties we have today used to be completely done at a manual 
level with those same rib-groups. __

While I have a lot of sympathy for Saku's pragmatism, I prefer to file off the 
ugly edges of old justifications when I can... but it's done one commit at a 
time.

-- Jeff



On 6/5/23, 3:47 AM, "juniper-nsp on behalf of Saku Ytti via juniper-nsp" 
mailto:juniper-nsp-boun...@puck.nether.net> on behalf of 
juniper-nsp@puck.nether.net > wrote:
I consider it a design error that NOS conceptually has two types of
instances, main instance and VRF instance. This distinction makes it
more expensive to write and maintain the NOS and it makes it more
fragile.


Juniper Business Use Only
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SRTBH

[Jeff Haas via juniper-nsp]

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 dimensions 
where they don't scale nicely.

That said, the firewall on many of our platforms for "block these sources" 
should scale nicely ... but doesn't in flowspec if you have rules that 
interleave.  The interleaving rules interfere with firewall optimization.

The issue above motivates the flowspec v2 work happening in IETF, particularly 
the user-ordered rules.

-- Jeff


On 7/7/22, 10:02 AM, "juniper-nsp on behalf of Gert Doering via juniper-nsp" 
 
wrote:

[External Email. Be cautious of content]


Hi,

On Thu, Jul 07, 2022 at 08:41:56AM -0400, harbor235 via juniper-nsp wrote:
> Since Flowspec arrived, are there any uses for SRTBH?

Scaling?

My understanding of flowspec is that it is typically implemented by
programming ACL TCAM, while SRTBH is routing table lookup, so
"some 10.000 lines" vs. "2-4 million".

OTOH, SRTBH is all-or-nothing, not "only port 80"...

gert
--
"If was one thing all people took for granted, was conviction that if you
 feed honest figures into a computer, honest figures come out. Never doubted
 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


Juniper Business Use Only
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Jeff Haas via juniper-nsp]

--- 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 group split.  Threading doesn't have 
anything to do with it, but is at least conceptually part of the right thinking.

It's generally safe to update a peer's import policy since that impacts the 
per-peer rib-in.

-- Jeff


On 2/8/22, 10:23 AM, "juniper-nsp on behalf of Tom Beecher via juniper-nsp" 
 
wrote:

[External Email. Be cautious of content]


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 thread
for a given peer group that handles everything for all those peers. If you
override a specific peer , it has to move that to a different thread, which
is intrusive and requires the reset. Conversely, if you remove the
override, it also needs to reset to pull it back into the same update
thread with the others.

On Sat, Feb 5, 2022 at 4:04 AM Raph Tello via juniper-nsp <
juniper-nsp@puck.nether.net> wrote:

> Hey,
>
> not really clear to me what that KB is exactly saying.
>
> Does it say:
>
> a) Peer will be reset when it previously hadn’t an individual 
import/export
> policy statement but the group one and then an individual one is 
configured
>
> b) Peer will be reset each time it‘s individual policy is touched while
> there is another policy in the group
>
> or
>
> c) Peer is reset the first time it receives it‘s own policy under the 
group
>
> Unfortunate that this seems to be not really well documented.
>
>
> On Fri 4. Feb 2022 at 20:15, Andrey Kostin  wrote:
>
> > Hi,
> > this KB article just came in:
> >
> >
> 
https://kb.juniper.net/InfoCenter/index?page=content=KB12008=SUBSCRIPTION
> > Symptoms:
> > Why does modifying a policy on a BGP neighbor in a group cause that
> > particular peer to be reset, when another policy is applied for the
> > whole peer group?
> > Solution:
> > Changing the export policy on a member (peer) in a group will cause that
> > member to be reset, as there is no graceful way to modify a group
> > parameter for a particular peer. Junos can gracefully change the export
> > policy, only when it is applied to the complete group.
> >
> > It's not much helpful but just provides a confirmation.
> >
> > Kind regards,
> > Andrey
> >
> > Raph Tello via juniper-nsp писал(а) 2022-02-04 09:33:
> > > I would also like to hear opinions about having ipv4 and ipv6 ebgp 
peer
> > > sessions in the same group and using the same policy instead of having
> > > two
> > > separate groups and two policies (I saw this kind policy at
> > > 
https://urldefense.com/v3/__https://bgpfilterguide.nlnog.net/guides/small_prefixes/*junos__;Iw!!NEt6yMaO-gk!SZ3o6mi78alS5Q0PKix5WQlodQB6H7lLLbN6IQ5IWkt06ynL-x6-ruO-RqKaXQU$
 ).
> > >
> > > It would nicely pack things together. Could that be considered kind of
> > > new
> > > best practice?
> > >
> > > On Thu 3. Feb 2022 at 16:12, Raph Tello  wrote:
> > >
> > >> Hi list,
> > >>
> > >> I wonder what kind of bgp group configuration would allow me to 
change
> > >> the
> > >> import/export policy of a single neighbor without resetting the
> > >> session of
> > >> this neighbor nor any other session of other neighbors. Similar to
> > >> enabling/disabling features on a single session without resetting the
> > >> sessions of others.
> > >>
> > >> Let‘s say I have a bgp group IX-peers and each peer in that group has
> > >> its
> > >> own import/export policy statement but all reference the same
> > >> policies. Now
> > >> a single IX-peer needs a different policy which is going to change
> > >> local-pref, so I would replace the policy chain of that peer with a
> > >> different one.
> > >>
> > >> Would this cause a session reset because the peer would be moved out
> > >> of
> > >> the update group?
> > >>
> > >> (I wonder mainly about group>peer>policy vs. group>policy vs. each
> > >> peer
> > >> it‘s own group)
> > >>
> > >> - Tello
> > >>
> > > ___
> > > juniper-nsp mailing list juniper-nsp@puck.nether.net
> > > 
https://urldefense.com/v3/__https://puck.nether.net/mailman/listinfo/juniper-nsp__;!!NEt6yMaO-gk!SZ3o6mi78alS5Q0PKix5WQlodQB6H7lLLbN6IQ5IWkt06ynL-x6-ruO-xixdBDA$
> >
> >
> 

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

[Jeff Haas via juniper-nsp]

--- 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 no resolve-on-import and this is something JNPR
> is open to implement where you'd have some sort of toggle when you
> want to resolve routes on import. I've not requested ER myself, as
> I've just worked around it, but might be something to talk to our
> account team and do an ER so we all get to enjoy this feature in few
> years time :)

The problem and example in the thread were past the ability of my brain to 
follow this round.

That said, there's some amount of plumbing that can permit a route that's been 
imported into a VRF to locally resolve vs. the local VRF tables rather than 
share the fate of its primary route.

This plumbing isn't generally exposed at this time.  Magic words "independent 
resolution".  Just in case that fits the ER. :-)

-- Jeff

--- End Message ---
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Jeff Haas via juniper-nsp]

--- 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
>> (0x4300:0.0.0.0:N in juniper configuration terms), Juniper documentation 
>> uses standard communities 0x4300:N for this purpose:
>> 
>> https://www.juniper.net/documentation/en_US/junos/topics/topic-map/bgp-origin-as-validation.html
> 
> I suspect this is a documentation bug, they probably meant to use
> 'arbitrary extended community' syntax.

FWIW, I don't see non-extended community syntax in this documentation page.  
It'd be a doc bug.

> 
>> Question: is it just a bit outdated documentaton and I shall follow
>> RFC and use extended communities, or there are some other reasons to
>> use standard ones ?
> 
> The "0x4300:1" syntax squats on AS 17152's community space, so that's
> not nice.
> 
> I think a nice feature of the RFC 8097 communities is that they aren't
> transitive, and you can reference the RFC for the documentation aspect
> of assigning those communities.

At some point we need to get named communities in place here.  I had the start 
of a patch a while back, but it rotted due to not getting worked on in a timely 
fashion.

-- Jeff

--- End Message ---
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] FlowSpec and RTBH

[Jeff Haas via juniper-nsp]

--- 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 blackhole on upstream network (selective RTBH).

I'm having difficulty following your use case.

Flowspec is its own address family with its own AFI/SAFI and a rather nasty 
format.

Are you asking that some internal component of a flowspec filter, like 
destination, is leaked into another address family?

-- Jeff

--- End Message ---
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Jeff Haas]

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" 
impact or the "whenever the route's properties change" impact.

Can I suggest a knob with three options – the two you mention, plus an option 
to maintain /both/ timers? If that’s not feasible (for reasons you already 
eluded), so be it.
My preference is indeed for ‘best of both’.

I don't believe we'll be adding a second timer at this time.

We have proposals in mind that may permit variable sizing of some of our core 
data structures.  Once we have such a thing, we may consider such optional 
memory-hungry features.  I know I want to do several things with them. :-)


Jeff> The question being: What's the default?

As you indicated, quite a few folk on older hardware will be sensitive to 
resource impacts.
I suggest the default should be on-the-wire as this incurs the minimal CPU hit, 
as I understand it.

Please consider the extra CPU hit to be marginal.  It's the memory hit that's 
the main concern for having more than one timer.

-- Jeff

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Jeff Haas]

> 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 relevant next point: If the junos mib is in error, what to do about 
>>> it?
>>> 
>>> Very likely fixing the issue will cause mass amounts of unhappiness as
>>> people's existing scripts and mib walking code fails due to the new
>>> sub-indices.
>>> 
>>> do the right thing, create misery? Leave it as is, document that it's
>>> wrong?
>> 
>> I totally understand it's not possible to just fix the issue. Your best
>> bet is to convert the draft into a RFC and fix the issue here! ;-)
> 
> After checking with Jürgen about RFC 4001 encoding (no better answer!) he 
> confirms that we're missing the variable length length field in our generated 
> OIDs.
> 
> I'll make a point of filing a PR on this.  As noted elsewhere in thread, 
> solving it might be ... interesting.

PR 1265504

-- Jeff

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Jeff Haas]

> 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 likely fixing the issue will cause mass amounts of unhappiness as
>> people's existing scripts and mib walking code fails due to the new
>> sub-indices.
>> 
>> do the right thing, create misery? Leave it as is, document that it's
>> wrong?
> 
> I totally understand it's not possible to just fix the issue. Your best
> bet is to convert the draft into a RFC and fix the issue here! ;-)

After checking with Jürgen about RFC 4001 encoding (no better answer!) he 
confirms that we're missing the variable length length field in our generated 
OIDs.

I'll make a point of filing a PR on this.  As noted elsewhere in thread, 
solving it might be ... interesting.

-- Jeff (trivial diff that will generate so much hate mail...)


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Jeff Haas]

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 likely fixing the issue will cause mass amounts of unhappiness as
people's existing scripts and mib walking code fails due to the new
sub-indices.

do the right thing, create misery? Leave it as is, document that it's
wrong?

I totally understand it's not possible to just fix the issue. Your best
bet is to convert the draft into a RFC and fix the issue here! ;-)

It's technically possible to fix and use a cli knob to give compliant behavior. 
 But then someone (likely me, based on on how bug work gets email dispatched) 
gets to own questions about that workaround for a decade.
(Did I mention I didn't like SNMP?)


Otherwise, use another table with the correct indexing?
jnxBgpM2PeerTableNew := jnxBgpM2PeerData.2?

Dunno if it's worth your time.

I think you misunderstood my original point:

https://tools.ietf.org/html/draft-ietf-idr-bgp4-mibv2-15

Note that the draft is long expired. It was impossible to get vendors to want 
to implement it.

Since *becoming* one of those vendors, I got some minor support to get the code 
restructured for the IETF MIB from an intern, but... well, it was intern code 
and didn't get through full commit criteria.

If this is something the operational community has passion for, it could be 
done, but it'd normally get done through the usual product manager process.  
Or, if I get supremely bored and have copious spare time (ha!) I may just 
finish it.  But I've been saying that for a few years now.

-- Jeff

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Jeff Haas]

> 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 is that the InetAddressType is used to 'cast' the
>> InetAddress to one of the underlying types; e.g. InetAddressIPv4.
>> Let's pick on that example:
>> 
>> InetAddressIPv4 ::= TEXTUAL-CONVENTION
>>DISPLAY-HINT "1d.1d.1d.1d"
>>STATUS   current
>>DESCRIPTION
>>"Represents an IPv4 network address:
>> 
>>   Octets   Contents Encoding
>>1-4 IPv4 address network-byte order
>> 
>> The corresponding InetAddressType value is ipv4(1).
>> 
>> This textual convention SHOULD NOT be used directly in object
>> definitions, as it restricts addresses to a specific format.
>> However, if it is used, it MAY be used either on its own or in
>> conjunction with InetAddressType, as a pair."
>>SYNTAX   OCTET STRING (SIZE (4))
> 
>> So, while you're correct with regard to variable types, the
>> expectation is that this is "cast" into a fixed sized octet string,
>> which has implied length.
> 
> I didn't know about RFC 4001 so I may be mistaken, but it doesn't say
> anything about the size requirement. Other than the comments in the MIB,
> there is also no way to link InetAddress and InetAddressIPv4. This is
> not just a matter of being able to pretty-print the IPv4, it's that we
> cannot know how to split the index into its components.

I generally agree with your analysis.  We've fundamentally reached a "what did 
the authors of rfc 4001 have in mind".  The whole idea of using this union was 
sort of gross and while things were still in MIB-land as IETF's main way of 
doing management stuff, confused a lot of people.  So the question is whether 
it's variably sized, and if so, how to reconcile against the casting.  
However...

> 
>> Given that net-snmp seems to recognize how to render the output from
>> the MIB, I suspect others came to a similar conclusion.
> 
> Net-SNMP is not able to render the output of the MIB correctly if the
> size is not specified. See, without the size:
> 
> $ snmptranslate -m BGP4-V2-MIB-JUNIPER 
> iso.3.6.1.4.1.2636.5.1.1.2.2.1.1.5.8.1.10.64.0.3.1.10.64.0.1
> BGP4-V2-MIB-JUNIPER::jnxBgpM2PeerLastErrorReceivedText.8.ipv4.10.64.0.3.1.10.64.0.1
> 
> If I add the size:
> 
> $ snmptranslate -m BGP4-V2-MIB-JUNIPER 
> iso.3.6.1.4.1.2636.5.1.1.2.2.1.1.5.8.1.4.10.64.0.3.1.4.10.64.0.1
> BGP4-V2-MIB-JUNIPER::jnxBgpM2PeerLastErrorReceivedText.8.ipv4."10.64.0.3".ipv4."10.64.0.1"

I know I've seen the bottom form of the output at some point. This makes me 
wonder if my memory is simply playing a trick on me, or it's what we do in one 
of our internal tool chains.

Again, get the answer of what you really expect vs. what's in the code.

To your relevant next point: If the junos mib is in error, what to do about it?

Very likely fixing the issue will cause mass amounts of unhappiness as people's 
existing scripts and mib walking code fails due to the new sub-indices.

do the right thing, create misery? Leave it as is, document that it's wrong?

Again, I hate SNMP. :-)

As mentioned, I'm conveniently at IETF.  At least one of the authors of 4001 
attends, so I should see if he's here.

> 
> Other MIB implementations also using AddrType/Addr includes the size,
> for example (on JunOS 14.1):
> 
> $ snmpgetnext net-tor-0114-1 IP-MIB::ipAddressTable
> IP-MIB::ipAddressIfIndex.ipv4."10.64.0.3" = INTEGER: 567
> $ snmpgetnext -On net-tor-0114-1 IP-MIB::ipAddressTable
> .1.3.6.1.2.1.4.34.1.3.1.4.10.64.0.3 = INTEGER: 567

And this does support the idea that the code is wrong.

-- Jeff

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Jeff Haas]

> 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
> since this never really worked, this is not the scope for JTAC.
> 
> So, as I know some Juniper people reads here, here is the bug. I'd be
> happy to provide more details if needed.

Read, yes.  Read on a timely basis, no.

I also happen to be the author of the ietf mib that Juniper based this MIB on. 
:-)

> 
> 
> The MIB says:
> 
>jnxBgpM2PeerEntry OBJECT-TYPE
>SYNTAX JnxBgpM2PeerEntry
>MAX-ACCESS not-accessible
>STATUS current
>DESCRIPTION
>"Entry containing information about the connection with
> a remote BGP peer."
>INDEX {
>jnxBgpM2PeerRoutingInstance,
>jnxBgpM2PeerLocalAddrType,
>jnxBgpM2PeerLocalAddr,
>jnxBgpM2PeerRemoteAddrType,
>jnxBgpM2PeerRemoteAddr
>}
>::= { jnxBgpM2PeerTable 1 }
> 
> And jnxBgpM2PeerLocalAddr is:
> 
>jnxBgpM2CfgPeerLocalAddr OBJECT-TYPE
>SYNTAX InetAddress (SIZE (4..20))
>MAX-ACCESS read-create
>STATUS current
>DESCRIPTION
>"The address of the local end of the peering session."
>::= { jnxBgpM2CfgPeerEntry 4 }
> 
> (and similar for RemoteAddr). The important bit is the size: variable.
> 
> With SNMP, when an index has a variable length, except if it's the last
> one _and_ the MIB says the size is IMPLIED, the length should be
> prepended to the value.
> 
> 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 is that the 
InetAddressType is used to 'cast' the InetAddress to one of the underlying 
types; e.g. InetAddressIPv4.  Let's pick on that example:

InetAddressIPv4 ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1d.1d.1d.1d"
STATUS   current
DESCRIPTION
"Represents an IPv4 network address:

   Octets   Contents Encoding
1-4 IPv4 address network-byte order

 The corresponding InetAddressType value is ipv4(1).

 This textual convention SHOULD NOT be used directly in object
 definitions, as it restricts addresses to a specific format.
 However, if it is used, it MAY be used either on its own or in
 conjunction with InetAddressType, as a pair."
SYNTAX   OCTET STRING (SIZE (4))
So, while you're correct with regard to variable types, the expectation is that 
this is "cast" into a fixed sized octet string, which has implied length.

Given that net-snmp seems to recognize how to render the output from the MIB, I 
suspect others came to a similar conclusion.

I also take your point that the idea of the InetAddress "union" would seem to 
imply a variable length.  However, this is perhaps a better question for the 
authors of RFC 4001... most of whom don't care about SNMP these days and have 
moved on to yang. :-)

-- Jeff (who has grown to know much about, and loathe, SNMP)

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] BFD Session

[Jeff Haas]

> 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 other comments in the thread support the observation here: You seem to have 
some form of half-duplexing issue.   You just need to figure out which side of 
the communication is getting dropped.

-- Jeff

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Jeff Haas]

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 no local target for l3vpn route and the box is not otherwise a
route
reflector or ebgp speaker, we'll drop the route from bgp.l3vpn.0.  (I.e.
the
box is a PE-only role.)  While we still do the import table scan, the
routes in
many cases won't be there.

This step is actually why I posted the question.
We encountered a problem where it takes 5-10 minutes for local routes, that
are already installed in other VRFs on the PE, to get installed from L3VPN
table into a newly configured VRF table.

By this, you mean you have some route that has a route-target that is already 
installed in VRF A to be installed also in VRF B that has an overlapping target?

Since I posted this question we've started testing the behaviour and in the
lab it seems that the "local routes parsing/import" is done as the first
thing, or at least right after the route refresh is sent out, so the routes
are leaked from bgp.l3vpn.0. into the NEW VRF table right away in the lab.

The work is done in parallel.  Think of it as the same type of work that is 
done when policy needs to be re-evaluated; we will walk the tables as part of 
the work until it's done.


So it must be something in the production (config) that is slowing things
down.

That usually implies scale.  Remember the work is part of general table 
re-evaluation, so it's likely the total number of routes in your system.

-- Jeff

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Jeff Haas]

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 removed, a route
> refresh is sent from the PE to RRs for the affected address families
> VPNv4/6. 
> 
> When a new VRF is configured, the PE sends a route-refresh to RRs. 
> 
> In both cases the RRs do send all VPNv4/6 prefixes to the PE. 
> 
> (In case of RT filter RRs will only send the set of routes according to the
> RT filter advertised by PE). 

All correct so far.  Junos is unfortunately a bit aggressive about route 
refreshes and really should be a bit more selective about which families it 
does the refresh for.

> 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 no local target for l3vpn route and the box is not otherwise a route 
reflector or ebgp speaker, we'll drop the route from bgp.l3vpn.0.  (I.e. the 
box is a PE-only role.)  While we still do the import table scan, the routes in 
many cases won't be there.

> 
> With regards to VPN routes coming in from RR, 
> 
> does PE wait till EOR/keepalive from RR in order to start best path
> selection and then parsing to determine which routes needs to be installed
> into the NEW VRF? 

It's done inline as Junos receive the routes.

> 
> Are there any mechanisms in use to speed up parsing through the MP-BGP table
> and installation of paths into NEW VRF? 
> 
> Are VPN routes grouped based on commonalities in RTs? 

Not at this time.  It's been a feature the BGP group has considered adding, but 
it has an additional memory cost that scales per-route and that's always scary. 
 With the advent of 64-bit junos, we've considered making some memory-burning 
features such as these able to be configured using a configuration knob but 
this class of features tends to be tricky and gives our test group hives. :-)

> These questions are OS agnostic, I'd appreciate any pointers.

FWIW, these questions are OS agnostic but the implementation may heavily vary 
by vendor.

-- Jeff

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Jeff Haas]

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 case seems to vary between
invocations, but usually under 100.  Example pseudo-sanitised output at the
end of the mail for anyone interested.

You've got the right assessment later in the message.  BGP has received a 
partial packet and is waiting for enough to move along with its work.

TCP hiccups for the extremely large variety of things that TCP does can cause 
this sort of lingering behavior.  When the box is rather busy, you'll get more 
since we may have gotten a fragment on the first read but are waiting until the 
next pass in a read to pick up more data.

-- Jeff

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Jeff Haas]

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" version. 
> Looking forward to seeing this one available.

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Jeff Haas]

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 trap for it several times(every one/two minute). Our
> trap receiver is connected to a mailing system which generate email upon
> receiving the trap. This action causes sending a lot of email for just one
> event.
> [...]

> Is there one here who can suggest any soultion for sending just one trap
> after an event. Specially when a BGP neighbor is down.
> We are using variations of M Series router and JunOS versions from version
> 9 to 12

PR: 1056230
Description: Adds a configurable snmp-option to BGP that suppresses the
sending of backward state trap notifications except for transitions
from the Established state.  This cuts down on the noise from
too many uninteresting trap notifications.

set protocols bgp snmp-options backward-traps-only-from-established

--

This is in at least 15.1+.  No help for older version at the moment, sorry.

-- Jeff


> 
> Thank you
> Alireza
> ___
> 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

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

[Jeff Haas]

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


> On Jan 29, 2016, at 10:09 AM, Adam Chappell  wrote:
> 
> Does anyone have useful experience regarding the use of JUNOS routing
> policy to control the propagation of BGP routes where the address family
> isn't the usual family inet?
> 
> I'm looking at the typical RFC4364 chapter 10b option for VPN labelled
> traffic exchange between EBGP peers and realising that my 14.1 MX platform
> doesn't seem to apply policy to this address family in the same way at all.
> 
> adamc@Virtual2> show bgp neighbor 192.0.2.1
> Peer: 192.0.2.1+179 AS 2Local: 192.0.2.2+59927 AS 1
> Type: ExternalState: EstablishedFlags: 
> Last State: OpenConfirm   Last Event: RecvKeepAlive
> Last Error: None
> Export: [ NO-ROUTES ]
>  Options: 
>  Address families configured: inet-unicast inet-vpn-unicast
> [...]
> 
> adamc@Virtual2> show policy NO-ROUTES
> Policy NO-ROUTES:
>   Term unnamed:
>   then reject
> 
> adamc@Virtual2> show route advertising-protocol bgp 192.0.2.1
> 
> bgp.l3vpn.0: 6 destinations, 8 routes (6 active, 0 holddown, 0 hidden)
>  Prefix   Nexthop   MED LclprefAS path
>  2:100:10.100.0.0/16
> * SelfI
>  2:100:10.100.0.2/32
> * SelfI
>  2:200:10.200.0.0/16
> * SelfI
>  2:200:10.200.0.2/32
> * SelfI
> 
> [...]
> Any pointers appreciated.
> 
> -- Adam.
> ___
> 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

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

[Jeff Haas]

> 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
> 
> Instead we are forced to put the value directly:
> 
> set routing-options static route 192.0.2.0/24 community 65000:100
> set policy-options community TEST members 65000:100
> 
> Can Juniper please fix this?  Thanks :-)

Speaking unofficially, these consistency warts drive us just as crazy as they 
do you.

But in order to preserve our own sanity, and not bring down the wrath of 
everyone else's operations who use the existing behavior, it's not likely to 
get changed.

-- Jeff

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Jeff Haas]

> 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 for is called a backref in the context of a 
regular expression. E.g. the \1 behavior in egrep.

The policy language doesn't currently support that.  There's an old PR 
somewhere in the system - over a decade old - asking for the functionality.

-- Jeff

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Jeff Haas]

> 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 routes.  Even 
> protocols that don't use communities can leverage them in the export policy, 
> the community just isn't announced.  Ditto for import policies.
> 
> Sacrificing that flexibility and simplicity to multithread rpd and shifting 
> to explicit route redistribution with limited route attributes per protocol 
> would be a huge loss.

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 small features.)

That said, we are preserving the One JUNOS paradigm.  Even if we did go 
multi-process with disjoint protocol implementation (that's not what we're 
doing), we'd be keeping the same source base.  Thus, static routes could have 
communities, or color or your unusual mechanism of choice. :-)

-- Jeff

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Jeff Haas]

> 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
>> small features.)
> 
> Communities on static routes are great.
> 
> But everyone wants more :) It would be super helpful if you would support 
> communities or tags on connected routes as well.

Hijacking the thread momentarily, what would you expect that to look like in 
the config?  community/tag keywording in a interface ... family foo {} scope?

-- Jeff

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Jeff Haas]

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 are insensitive
> to execution order.  BGP peer route analysis, comparison against import
> policy and current RIB might fall into that category, but not without a lot
> of locking and potential for races.

It is non-trivial work.  But it is also somewhat easier to incrementally 
introduce threading than it is to split large hunks of code and workflow into 
multiple processes.

We're not going into deep technical detail on mailing lists such as these at 
the moment.  The work is in progress.  

> 
> I think there's more bang for buck in the 64-bit address space change what
> with Internet FIB table size, and I'm quite interested in the developments
> to make rpd 64-bit clean which I'm sure are also not insignificant. I
> notice Mr Tinka already expressed a conservative view on jumping into a
> 64-bit rpd and I can totally understand and appreciate that view. Juniper
> haven't made this a default on the 14.1R5 cut of code that we're currently
> testing, so I imagine they're still looking for bleeding-edge feedback to
> whittle out the potential nasties.

I've not quite understood our strategies for choosing whether we do 32 or 
64-bit by default.  The balance is covered somewhat by the split between having 
a RE with sufficient base memory vs. release, but the group responsible for 
that choice is being conservative.  In my opinion, 64-bit has been perceived 
internally clean for quite some time, and we do a significant portion of our 
internal testing in that environment.

The biggest reason to be cautious about the default mode is that on systems 
with insufficient memory, or systems with insufficient need, the cost of 64-bit 
may be a bit much.  Since the bulk of internal data structures are pointers, 
you tend to see at least a 2x increase in base memory use when running in 
64-bit mode.  

> 
> I'm quite intrigued by the tidbit in the Juniper docs, though, that
> suggests that switching from a 32-bit to a 64-bit rpd is not service
> affecting though which means that the wait-and-see approach is viable?  Or
> am I totally misunderstanding this?
> 
> https://www.juniper.net/documentation/en_US/junos14.1/topics/reference/configuration-statement/routing-edit-system-processes.html

Ok, I find this comment to be confusing if not misleading:
Tip: You need not restart the routing protocol process (rpd) to use the 64-bit 
mode.

I suspect the most generous reading of this is that rpd is restarted for you.  
I'll open a doc PR for clarification.

> It doesn't say that one needs NSR or any sort of "help" from the backup RE
> which might be the first assumption. So I wonder how they manage to get one
> process to exit and the other one to start up with different runtimes,
> differently sized pointers etc., and somehow share the same in-core RIB and
> protocol state etc etc.? If this really does work, there's probably someone
> sitting somewhere in Sunnydale immensely smug and under-stated right now,
> and if so I'm sure he/she'd eat the MT problem for breakfast!

I've often thought working over the hell-mouth would be interesting, but 
engineer retention in Silicon Valley is already tricky enough.  Good thing the 
office is in Sunnyvale. :-)

-- Jeff

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Jeff Haas]

 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 freak-out.  Even in 3G 32-bit RPD, it's problematic.
 
 We're now in the land of 64-bit RPD as an option.
 
 Slightly related and I totally accept if you can't/want to answer...

I'll vaguely answer since I'm up to my ears in said work and a lot of things 
are in flight.

 
 Do you have any plans how to dig yourself out from the current monolithic RPD 
 and non-SMP enabled kernel hole? Maybe move to linux userland altogether? 
 Virtualizing fbsd on top of linux doesn't necessarily make things better.

Linux only changes the problem a bit.  What's more important is the bits of 
Junos that live in the kernel.  

Here's what I'm willing to say publicly, has been said in general product 
discussions to date.  I won't say more - see your appropriate Juniper rep for 
dates, etc.

We are shipping an SMP kernel in the 15.x timeframe.  Even with no daemon 
changes, it helps by spreading the load of the daemons to some extent.
We have multi-threaded code in progress for routing. (RPD)
We will not have the whole of routing multi-threaded at once.  Work will appear 
incrementally across the releases based on providing for stable code.

So yes, we have plans.  More than plans.

-- Jeff

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Jeff Haas]

[Note that this is where I go off into speculative thinking land.  Those who 
know me from conferences are familiar with the process, but I'd really rather 
not have someone note my email address and think they should start hammering on 
product management as a result of such public discussion.]

 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 options. . .

As I mentioned in the earlier mail, I think a lot of the base problem is really 
a distributed knowledge issue.  Routers in an AS that may want to take 
advantage of origin/peer-as to prefix mappings only can do so if they use their 
local knowledge or have a distribution mechanism that handles passing along 
that remote knowledge to the rest of the AS.  That gets into some ugly scaling. 
 The big providers who do a large amount of IRR filtering combined with AS 
regex checks already understand a significant part of the state cost invovled. 
Obviously a non-CLI mechanism or a somewhat more dense policy format would 
help, but at the end of the day that state needs to end up in data structures.

Locally on a router, we have some potential ability to do this sort of mapping 
within routing.  The missing plumbing right now is the ability to jump from a 
given origin or peer-as to the set of routes containing it.  The most likely 
way to implement that plumbing is to take the existing routes and throw them 
onto a pair of doubly linked lists, one for origin and one for peer.  (Singly 
doesn't scale for removal.)  

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 freak-out.  Even in 
3G 32-bit RPD, it's problematic.

We're now in the land of 64-bit RPD as an option.  At some point, finding ways 
to enable optional features that burn memory to get cool effects but can be 
disabled for lower scale systems would be cool.  Right now, the data structures 
in question are insufficiently polymorphic for us to do such a thing, but we're 
keeping it in mind as part of future work.

But you'll note I said within routing.  Trying to push this sort of mapping 
to the line cards for firewalling won't scale.  It'd probably move into a 
triggered poll/update model.  So, for those thinking this is useful, is it 
useful if you can only do this sort of thing for a subset of your routes/ASes?

And then eventually we get back to the information hiding issue that route 
selection imposes on your AS.  You probably want all of the information, not 
just your active routes.  This *really* pushes you to some sort of external 
database and this starts smelling like policy.  Policy scales a lot better 
since it doesn't gum up the size of important data structures; it does its work 
via functional side effect.

So, hopefully having walked everyone through something policy-like perhaps 
making better sense (and if you're not convinced, I'm sure you'll let me 
know!), what does that look like?  My suspicion is it's really something a bit 
like what we have for the internals of rpki-rtr for RPKI ROA objects: An 
as-map.  E.g. AS 64512: 192.0.2/24, 10/8 24= prefixlen = 32, etc.  You can 
obviously get this functionally today with a mix of route-filters, prefix-lists 
and as-regex.  The question is whether being able to store a map and then say 
something like:

term a {
   match origin-as via as-map foo;
}

is useful.

-- Jeff


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Jeff Haas]

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 flowspec can match on as-path?

Flowspec can't currently match as-path.  It's an interesting thought, would 
have some tricky deployment issues.

Do you match only on path for active route?
All Adj-Rib-In routes?  (Restrict to ones eligible for selection?)

I think the issue would eventually devolve down to wanting to have the full set 
of eligible paths regardless of selection and regardless of where the box in 
your network is.  This is problematic.

Some solutions that suggest themselves using other tools is using IRR data or 
RPKI ROA objects to generate the list, but then you'd still need to push it to 
your router.  And of course, there's still periodic scraping of routes to 
build/update the lists.

I don't have a clean answer, but it's leading me to ponder some.

- Jeff
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Jeff Haas]

 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 update-groups in configuration group.
 But I guess if you have two neighbors with same export policies in
 different configuration group, it likely won't share same
 update-group, haven't tested though.
 
 I believe the two groups same policies do get two update-groups.

That's right.

 I'm not sure about neighbor with neighbor level policy the same as the
 group level case though.

Most neighbor level policy changes will split the groups.

When in doubt, use show bgp groups.  It will show more than one group of the 
same name when the group gets internally split by such configuration.

-- Jeff

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] vMX availability

[Jeff Haas]

 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 of customers doing BNG 
 on MX, and don’t really want to fork out for one of my own right now. A vMX 
 with BNG would be handy. I’m told the code is there but not validated or 
 supported. That’s fine by me, I don’t need to test QoS etc. - but do want to 
 be able to test RADIUS integration, putting subscribers in VRFs, all that fun 
 stuff.

I spend most of my day-job in BGP-land, so I have no experience with BNG in 
general.

-- Jeff

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] vMX availability

[Jeff Haas]

[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 my hands on anything.

A friendly PLM said the following was okay to post:
VMX FRS is 14.1R5 which is expected to be out by the 1st week of June.

-- Jeff (who regularly uses VMX in-house for control plane testing)

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Jeff Haas]

 
 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 engaging the community more actively,
 it would have not been large effort to ask in j-nsp about this, and
 use the discussion as input in your decision-making. I understand how
 hard it is to implement code based on just RFC, without having
 operational experience.
 I love JNPR is working on quality and correctness, and I understand
 mistakes do happen. But they would happen less, if customers voices
 would be heard more.
 
 Is anyone aware if there already is beta rebuild available with knob
 to change this behavior?
Speaking as one of the authors on RFC 7300, the fact that this made it
into any shipping Junos code was a mistake.  As part of work to add the
4-byte private AS numbers to the remove-private code, RFC 7300 compliance
was included as part of the work on that code.

We did poll several providers about AS 65535 and were told that we were
mistaken to restrict its use.  That code was pulled out, but unfortunately
we missed one of the places for that code change.

PR 1069307 covers the fix for those branches to restore AS 65535 to use.

-- Jeff
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp