Re: [j-nsp] Thanks for all the fish

[Chris Kawchuk via juniper-nsp]

Shall we start taking bets on what stays, and what goes? 

Here’s my List:

Stays:
PE/Edge Routing (MX/Trio) - Stays and continues development. Reasons stated 
already in this thread. It’s the Swiss army knife to solve 
$things-you-didn’t-even-know-you-needed-to-do for some future corner case, and 
is a market leader.
P/Core Routing (PTX/Express) - Stays, mainly as it’s also a good border router 
too. Lots of DC people using it for massive eBGP at scale, but don’t need the 
HQoS and Subscriber-y stuff that MX can do. 
DC Switching (QFX/Trident) - Stays - Nice product HPE can sell to enterprise 
customers. QFabric lives again in new forms (I'm looking at you VCF). Cheap and 
cheerful high speed switching doesn’t go out of style.

Questionable:
EX - Does it make sense to have EX and QFX? or roll them into one? Dunno. I 
like them when "i just need a switch there” which doesn’t sound like a Boeing 
747 on takeoff. I’d like it to stay.
SRX - HPE can have a good security story now, but SRX needs an uplift versus 
what competitor’s NGFWs are up to these days (and no, Contrail isn’t the answer)

So — where does that leave ACX (Jericho2/2c+/Qumran)? My suspicions HPE says 
“What is this metro-E eVPN/VPWS MPLS aggregation stuff?". It doesn’t address 
any Enterprise solution for HPE that I can think of that couldn’t be covered by 
QFX/EX. It also is lagging behind Cisco NCS5700/NCS540 in both product 
maturity, and product breadth. i.e. If you want a nice small MPLS/SR capable 
pizza box that various form factors, power draw, faceplates, PFE speed, 
physical depth and size, etc... theres an NCS540 already built that does that. 
Contrast with… ACX7024 and the 7100. Basically 2 form factors from JNPR 
versus.. 12-15 different NCS540 and umpteen NCS5700 models and variants.

Again, ACX was never a competitor to the ASR920 which I know Mr Tinka was very 
fond of. And the NCS540 "is the new ASR920”. There’s some long roads ahead for 
JNPR to wrestle back some of that marketshare.

ACX also did a ‘reboot’ of the product line in the 7000-series when they went 
Jericho, versus ACX5000 which (correct me if I’m wrong) that was 
QFX/Trident/Trident+ based and earlier ACX series which were 
$no-idea-i-didnt-look-very-hard-at-them…. so its almost “a new product” which 
may not have a lot of customer nor market traction; thus easier to kill off. 
Yes — even though previous generations of ACX did exist and likely had some 
customers..somewhere…., I know of absolutely nobody that bought them nor used 
them in anger for a large Metro-E/MPLS/eVPN/SR network role.

I'm happy to be proven wrong on ACX; as I don’t like the idea of handing an 
entire market segment to a single vendor.

My $0.02

- CK.



> On 11 Jan 2024, at 9:15 am, Richard McGovern via juniper-nsp 
>  wrote:
> 
> #1 jewel HPE (Aruba) is interested in is Juniper/MIST AI. MIST AI and ML is 
> also being integrated into many other facets of Juniper, one being Apstra. 
> See this in announcement - 
> https://www.barrons.com/articles/cisco-stock-arista-juniper-hp-enterprise-acquisition-b94d6024
>  
> 
___
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

[Chris Kawchuk via juniper-nsp]

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 
>  wrote:
> 
> 
> 
> 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://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] Q. Is anyone deploying TCP Authentication Option (TCP-AO) on their BGP peering Sessions?

[Chris Kawchuk via juniper-nsp]

FWIW -- We've asked for that feature now in any RFP/RFQs we send to the usual 
gang of $vendors.

Thats our method to get adoption, else they get a black-mark/non-comply in the 
[BGP section] when it comes time to score the responses.

- CK.



> On 27 Sep 2023, at 10:49, Barry Greene via juniper-nsp 
>  wrote:
> 
> Hi Team,
> 
> 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?
> 
> This is suppose to be the “replacement” for BGP MD5, ‘but’ I’m hearing …..
> 
> 1. The Vendors are not supporting yet. Which means a lot of older systems 
> would not be able to support a BGP session with TCP-AO.
> 2. People have to tried is operationally.
> 
> Sharing you thoughts would be helpful …...
> 
> Thanks,
> 
> Barry
> ___
> 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] Junos 21+ Killing Finger Muscle Memory...

[Chris Kawchuk via juniper-nsp]

Hi Jeff

I'll open it with my SE here in Australia (Mark Barrett). Will advise once 
complete.

- CK.


> On Jul 19, 2023, at 01:24, Jeff Haas via juniper-nsp 
>  wrote:
> 
> 
> Juniper Business Use Only
> On 7/12/23, 12:11 PM, "Jeff Haas"  > wrote:
>> 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.
> 
> 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

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

[Chris Kawchuk via juniper-nsp]

+1 Mark!

As any good problem begs for a solution, my suggestions to JNPR are as follows, 
as alternative places for this command:

"show route transport-class ..." (or really, is it even a routing thing? might 
be better w/the segment-routing or spring commands)i.e.:
"show segment-routing ..."
"show spring transport-class ."

...but whatever is done, please, for the love of 20+ years of finger-memory 
please do NOT make it conflict with "sh[TAB] rou[TAB]"

- CK.

(P.S. NOTE that since this new 'show' command is part of base JunOS 21 and 
above; it's also present on all EX, QFX, SRX, etc.. devices you would never 
ever think of ever running segment-routing on w/transport classes or colours, 
but that *do* have a basic routing table, so it's not just on PTX/ACX/EVO or 
MX/P/PE devices we run into this...)




> On Jul 12, 2023, at 18:49, Mark Tinka via juniper-nsp 
>  wrote:
> 
> So, this is going to be a very priviledged post, and I have been spending the 
> last several months mulling over even complaining about it either on here, or 
> with my SE.
> 
> But a community friend sent me the exact same annoyance he is having with 
> Junos 21 or later, which has given me a final reason to just go ahead and 
> moan about it:
> 
> tinka@router> show rout
>  ^
> 'rout' is ambiguous.
> Possible completions:
>   routeShow routing table information
>   routing  Show routing information
> {master}
> tinka@router>
> 
> I'm going to send this to my Juniper SE and AM. Not sure what they'll make of 
> it, as it is a rather priviledged complaint - but in truth, it does make 
> working with Junos on a fairly historically commonly used command rather 
> cumbersome, and annoying.
> 
> The smile that comes to my face when I touch a box running Junos 20 or 
> earlier and run this specific command, is unconscionably satisfying :-).
> 
> Mark.
> ___
> 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] 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.

[Chris Kawchuk via juniper-nsp]

Great idea! but no dice. :( didn't work. 

Seems the whole "VRF -> back to base table" operations that we'd all love to do 
easily in JunOS rears its ugly head yet again ;)  

FWIW - Some friends in the industry *do* use that knob, but they're "going the 
other way". i.e. The RPKI RV Database  is in inet.0 && Internet is in a VRF. 
Apparently that does work AOK for them; however it's "fiddly" as you say.

FWIW - here's the VRF's config... pretty darned basic.

routing-instances {
admin {
routing-options {
validation {
notification-rib [ inet.0 inet6.0 ];   ## << No impact on the 
default:default LI:RI RV database
group routinator {
session 10.x.x.x {
refresh-time 120;
port 3323;
}
}
}
}
description "Dummy admin vrf - to test RPKI inside a routing-instance";
instance-type vrf;
interface xe-0/0/3.0;   ## << the RPKI server is setting on the 
other end of this /30
vrf-target target::xxx;
}
}

FWIW using a vMX for testing - running JunOS 20.4R3-S4.8.

Basically i'm asking "is there a way to do this without having to stick the 
validator DB config into the basec onfig [routing-options validation {}] 
stanza? 

.If it must, then yeah, it's easy enough to do a rib group, a static /32 
next-table/no-readvertise/no-install, lt-x/x/x stitch, route leak, etc...to get 
the default:default instance to "use the VRF" to reach the RPKI server.  I just 
don't want to go down that road (yet) if I don't have to; as the 'technical 
elegance' (read: OCD) portion of my brain wants to avoid that if it can.

- CK.




> On Jun 5, 2023, at 13:12, David Sinn  wrote:
> 
> I'd try the 'notification-rib' chunk in the 'validation' stanza of the 
> routing-instance and see if setting inet.0 there pushes the DB the way you 
> need. Certain versions of JunOS are quite broken going the other way, so I've 
> had to enumerate all of the routing-instances that I want to be sure have a 
> copy of the validation DB to get them to work correctly. Maybe the other way 
> will work in your case.
> 
> David
> 
>> On Jun 4, 2023, at 7:52 PM, Chris Kawchuk via juniper-nsp 
>>  wrote:
>> 
>> Hi All
>> 
>> Been scratching my head today. As per Juniper's documentation, you can 
>> indeed setup RPKI/ROA validation session inside a routing-instance. You can 
>> also have it query against that instance on an import policy for that VRF 
>> specifically, and if there's no session, it will revert to the default RPKI 
>> RV database (if configured) under the main routing-options {} stanza to 
>> check for valid/invalid, etc...
>> 
>> https://www.juniper.net/documentation/us/en/software/junos/bgp/topics/topic-map/bgp_origin_validation.html
>> 
>> Thats all fine and dandy, but it seems that JNPR's implementation of 
>> RPKI/ROA *assumes* that your RV database is always configured in the main 
>> routing instance (i.e. the main routing-options validation {} stanza, thus 
>> your RPKI server MUST be available via inet.0 ). 
>> 
>> Unfortunately, the situation I am faced with is the opposite.
>> 
>> My RPKI/ROA server is only available via our "admin" VRF (which is how we 
>> manage the device) - Our inet.0 contains the global internet/IGP and links 
>> and loopbacks/Labels/etc. all "admin" related functions RADIUS/TACACS, SNMP, 
>> RPKI, Syslog, ssh, you-name-it, etc. are all "nailed" to our admin VRF. 
>> Hence when I try to do ROA validation of an eBGP peer in inet.0 via a 
>> standard import policy, the RV "validation-database" is unfortunately locked 
>> inside the admin-vrf, and thus isn't queried for valid/invalid/unknown etc. 
>> 
>> Hence, nothing on the eBGP session in inet.0 is being validated.
>> 
>> Is there some KNOB I'm missing, to allow a policy, executed upon routes in 
>> inet.0, to use the RV database in a non-default VRF? Or copy the VRF's RV to 
>> the default's RV? or is this some oversight of JNPR's RPKI implementation, 
>> that it must be inside the default:default LI:RI?
>> 
>> - CK.
>> 
>> 
>> NOTE: my Google-fu and/or "set ?" skills aren't yielding any useful results. 
>> Apologies if there's "a simple fix" for this, or an example of this 
>> situation I haven't found.
>> ___
>> 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

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

[Chris Kawchuk via juniper-nsp]

Hi All

Been scratching my head today. As per Juniper's documentation, you can indeed 
setup RPKI/ROA validation session inside a routing-instance. You can also have 
it query against that instance on an import policy for that VRF specifically, 
and if there's no session, it will revert to the default RPKI RV database (if 
configured) under the main routing-options {} stanza to check for 
valid/invalid, etc...

https://www.juniper.net/documentation/us/en/software/junos/bgp/topics/topic-map/bgp_origin_validation.html

Thats all fine and dandy, but it seems that JNPR's implementation of RPKI/ROA 
*assumes* that your RV database is always configured in the main routing 
instance (i.e. the main routing-options validation {} stanza, thus your RPKI 
server MUST be available via inet.0 ). 

Unfortunately, the situation I am faced with is the opposite.

My RPKI/ROA server is only available via our "admin" VRF (which is how we 
manage the device) - Our inet.0 contains the global internet/IGP and links and 
loopbacks/Labels/etc. all "admin" related functions RADIUS/TACACS, SNMP, RPKI, 
Syslog, ssh, you-name-it, etc. are all "nailed" to our admin VRF. Hence when I 
try to do ROA validation of an eBGP peer in inet.0 via a standard import 
policy, the RV "validation-database" is unfortunately locked inside the 
admin-vrf, and thus isn't queried for valid/invalid/unknown etc. 

Hence, nothing on the eBGP session in inet.0 is being validated.

Is there some KNOB I'm missing, to allow a policy, executed upon routes in 
inet.0, to use the RV database in a non-default VRF? Or copy the VRF's RV to 
the default's RV? or is this some oversight of JNPR's RPKI implementation, that 
it must be inside the default:default LI:RI?

- CK.


NOTE: my Google-fu and/or "set ?" skills aren't yielding any useful results. 
Apologies if there's "a simple fix" for this, or an example of this situation I 
haven't found.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp