Re: [j-nsp] QFX5110 / EVPN-VXLAN with IPv6 underlay

[Christian Scholz via juniper-nsp]

Also might be worth mentioning that the Router-ID - although it might look like 
one and you would usually use one you already have on your loopback - is 
technically not an IP(v4)-Address. 


See: 
https://www.juniper.net/documentation/us/en/software/junos/static-routing/topics/ref/statement/router-id-edit-routing-options.html

Even if you run only OSPF3 or IPv6 BGP peering in a routing instance, a 32-bit 
router-id must be configured in the instance. This is because IPv6 routing 
protocols use the router-id for handshaking. The router ID must be configured 
as a 4 octet (32 bit) unsigned non-zero integer value. 
It's often convenient to use an IPv4 address as the router ID. However, a valid 
IPv4 address is not required. The RID does not have to be a routable IPv4 
address. You can configure any 32-bit value that is unique within the routing 
domain. If you do not configure the router-id in an IPv6 OSPF or BGP routing 
instance the IPv6 protocols will use an invalid value for the router ID 
(0.0.0.0) and the adjacency and connections will fail

CHS



> Am 28.11.2023 um 16:14 schrieb Roger Wiklund via juniper-nsp 
> :
> 
> For the QFX5110 specifically, MAC-VRF is supported:
> https://apps.juniper.net/feature-explorer/feature-info.html?fKey=9788=MAC+VRF+with+EVPN-VXLAN
> 
> But IPv6 underlay is not:
> https://apps.juniper.net/feature-explorer/feature-info.html?fKey=11165=EVPN-VXLAN+fabric+with+an+IPv6+underlay
> 
> So maybe it's an ASIC limitation as QFX5110 is using Trident 2+ and
> QFX5120/EX4400 is using Trident 3.
> 
> Regards
> Roger
> 
> 
> 
>> On Tue, Nov 28, 2023 at 3:48 PM Roger Wiklund 
>> wrote:
>> 
>> Hey
>> 
>> You're interpreting the default switch limitation incorrectly.
>> 
>> It doesn't mean the QFX5120 can't support MAC-VRFs, it means even if you
>> implement MAC-VRFs you still only have a single switch domain and can't
>> have overlapping VLANs in the different MAC-VRFs. (MX does not have this
>> limitation. It supports 32k VLANs)
>> 
>> IPv6 underlay is supported on QFX5120 in MAC-VRF from Junos 21.2R2:
>> Explore Features by Product | Juniper Networks Pathfinder Feature Explorer
>> 
>> 
>> You can configure an EVPN-VXLAN fabric with an IPv6 underlay. You can use
>> this feature only with MAC-VRF routing instances (all service types). You
>> must configure either an IPv4 or an IPv6 underlay across the EVPN instances
>> in the fabric; you can’t mix IPv4 and IPv6 underlays in the same fabric.
>> To enable this feature, include these steps when you configure the EVPN
>> underlay:
>> • Configure the underlay VXLAN tunnel endpoint (VTEP) source interface as
>> an IPv6 address:
>> • Even though the underlay uses the IPv6 address family, for BGP
>> handshaking to work in the underlay, you must configure the router ID in
>> the routing instance with an IPv4 address:
>> • Enable the Broadcom VXLAN flexible flow feature, release where the
>> feature is not enabled by default:
>> We support the following EVPN-VXLAN features with an IPv6 underlay:
>> • EVPN Type 1, Type 2, Type 3, Type 4, and Type 5 routes(excluding EX9200
>> for type 5).
>> • Shared VTEP tunnels (required with MAC-VRF instances).
>> • All-active multihoming, including Ethernet segment ID (ESI)
>> auto-generation and preferencebased DF (DF) election.
>> • EVPN core isolation.
>> • Bridged overlays.
>> • Layer 3 gateway functions in ERB and CRB overlays with IPv4 or IPv6
>> traffic.
>> • Underlay and overlay load balancing.
>> • Layer 3 protocols over IRB interfaces—BFD, BGP, OSPF.
>> • Data center interconnect (DCI)—over-the-top (OTT) full mesh only.
>> • EVPN proxy ARP and ARP suppression, and proxy NDP and NDP suppression.
>> 
>> Regards
>> Roger
>> 
>> On Mon, Nov 27, 2023 at 11:31 AM Denis Fondras via juniper-nsp <
>> juniper-nsp@puck.nether.net> wrote:
>> 
>>> Hello,
>>> 
>>> Thank you very much everyone for the help.
>>> 
>>> It seems that `netraven` nailed it.
>>> I missed the part where QFX5110 could not support multiple forwarding
>>> instances.
>>> 
>>> I will have to go back to the legacy protocol then :/
>>> Replacing IPv6 addresses with IPv4 addresses, keeping the same config,
>>> worked on
>>> first try.
>>> 
>>> Thank you again !
>>> Denis
>>> 
>>> 
>>> Le Mon, Nov 27, 2023 at 10:52:52AM +0100, netravnen+nspl...@gmail.com a
>>> écrit :
 Dennis,
 
 On Sat, 25 Nov 2023 at 15:26, Denis Fondras via juniper-nsp
  wrote:
> Can you give a clue ? I haven't found any information on wether it
>>> could work on
> QFX5110.
 
 Looking at the two pages below.
 1. The QFX5120 (assuming this also applies to the QFX5120-32C model)
 *only* supports the default-switch forwarding instance.
 2. And IPv6 underlays seem to be *exactly not* supported for the
 default-switch forwarding instance.
 
 If I take this from what it reads. It looks like you 

Re: [j-nsp] How to pick JUNOS Version

[Christian Scholz via juniper-nsp]

--- Begin Message ---
If you face issues, you have JTAC, ATAC, and Engineering - and also a local SE.
I would never wait and "hope" that a fix will be out there because it has been 
reported, "by someone else."
Observe, Pinpoint, Report and if needed Escalate - works very good with Juniper 
and they help you; unlike other vendors who "build bridges" and tell you to 
deploy your software while Saturn is in line with Mars and while offering a 
goat as a token of appreciation at the same time 
If there is a nasty issue that is not fixed in any release, Engineering 
provides "Special Customer Releases" to have a fix for your particular 
environment and issue to help you.
Therefore if you report the Bug, you might not have a fix tomorrow, but in the 
next 2-3 months.
And if it takes longer, there's an "escalate this case" button that works very 
well - I never had to wait longer than six weeks for a particular fix after it 
had been confirmed. Your local SE can also assist you if you have trouble.


Back to the topic:
If you start fresh, follow the "JTAC versions to consider" (as stated earlier, 
it's no longer called recommended for various reasons) and ask your local SE - 
that's the "official" way. 
In 9/10 Cases, this is an excellent version to start with if you have no idea 
where to start at all.
If you need a specific feature that's not yet in the "version to consider," or 
there's a bug in this version affecting you, your local SE can tell you what to 
do and what version to try.
This way, you get a working version or the correct pointers on what to do to 
get the right version.

Tom's approach is also an excellent idea - the important part is that you test 
everything for your environment yourself before deploying it to prod. Most of 
the time, "shit hits the fan" because folks don't check appropriately for 
themselves or have no testing environment at all because "it's expensive."
In my personal opinion, it's not the vendor's responsibility to test every 
customer topology in existence with every tiny feature.
It's your job at the end of the day to make sure that you deploy code that 
works. 
The vendor can assist you as best as possible, but it's simply not possible for 
them to test EVERY scenario out there.
Again: Observe, Pinpoint, Report.

Yes - there are often multiple bugs involved, and yes it can be a "Minesweeper 
Game" to find the one that has "everything" fixed (however, such thing does not 
exist per definition because humans are not perfect) - but it's not as 
complicated as with other vendors with 27.000 Releases and Sub-Releases out 
there that have to be "qualified" in order to get support 

Just my 2ct

-- Christian






-Ursprüngliche Nachricht-
Von: juniper-nsp  Im Auftrag von Alexandre 
Guimaraes
Gesendet: Donnerstag, 20. August 2020 15:34
An: Tom Beecher ; Colton Conor 
Cc: Juniper List 
Betreff: Re: [j-nsp] How to pick JUNOS Version

The best answer ever!

Go to Vegas, in a Cassino, play some roulette.  Wait for a number between 10 
and 20, if black, normal Junos, if red, SR Junos...  if you lose all money 
before get a code similar a release, follow Tom Beecher schemas.

IT'S A LOTTERY to pick a junos release. 

One of my case
I have deployed some QFX5120 32C and 48Y units a year ago, exactly Aug/2019, 
until today, those units are offline and waiting a code that’s fix 
RSVP/ISIS/MPLS signalization until there, wasted money, etc



Em 19/08/2020 13:32, "juniper-nsp em nome de Tom Beecher" 
 escreveu:

Start with the highest code version supported on the hardware that has all
the features you need.
Subtract 2 from the major revision number.
Pick a .3 version of that major revision.
Work towards current from there depending on test results, security needs,
etc.

On Wed, Aug 19, 2020 at 10:47 AM Colton Conor 

wrote:

> How do you plan which JUNOS version to deploy on your network? Do you 
stick
> to the KB21476 - JTAC Recommended Junos Software Versions or go a 
different
> route? Some of the JTAC recommended code seems to be very dated, but that
> is probably by design for stability.
>
> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__kb.juniper.net_InfoCenter_index-3Fpage-3Dcontent-26id-3DKB21476-26actp-3DMETADATA=DwICAg=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=d3qAF5t8mugacLDeGpoAguKDWyMVANad_HfrWBCDH1s=a6BNdZOtIAqYpPvwVFnIF4E-D-PQw3QGn-NmT5hFQag=CQxemDO4grDS8J_BXAGPC3akSwvKhy2DBPt6JlKN3nI=
>
> Just wondering if JUNOS will ever go to a unified code model like Arista
> does? The amount of PR's and bug issues in JUNOS seems overwhelming. Is
> this standard across vendors? I am impressed that Juniper takes the times