Like you, I have zero idea for the use case. I'm finding that with many of the tasks in the JNCIE workbook so far. Cool to know that we
Original Message:
Sent: 08-03-2022 10:15
From: Simon Bingham
Subject: JNCIE-DC topics and documentation - need more detail
#4 I have an answer for !!
So I thought this was a difference between the MX and the QFX but it is not, they are the same apart from the location of the "switch options " and "protocols stanza.
The config under switch options is for Type 1 evpn routes
this is the gotca ........
The Route Target under protocols evpn vni-options is for non type 1 routes and if this is missing the config defaults to the target used under switch options !!! this is why I could remove this in my lab to no effect.
in the example below I defined 2 targets !!
root@mx3# show vtep-source-interface lo0.0;instance-type virtual-switch;route-distinguisher 10.0.255.3:100;vrf-target target:65000:100;protocols { evpn { encapsulation vxlan; extended-vni-list [ 100 200 ]; vni-options { vni 100 { vrf-target target:65000:123; } } }}
{master:0}[edit]root@vQFX6# show switch-options vtep-source-interface lo0.0;route-distinguisher 10.0.255.6:100;vrf-target target:65000:100;{master:0}[edit]root@vQFX6# show protocols evpn { vni-options { vni 100 { vrf-target target:65000:123; } } encapsulation vxlan; extended-vni-list [ 100 200 ];}
See how the the type 1 and type 2 are advertised with different targets
root@mx3# run show route advertising-protocol bgp 10.0.255.6 extensive * 1:10.0.255.3:0::0500000000000000c800::FFFF:FFFF/192 AD/ESI (1 entry, 1 announced) BGP group overlay type Internal Route Distinguisher: 10.0.255.3:0 Route Label: 1 Nexthop: Self Localpref: 100 AS path: [65200] I Communities: target:65000:100 encapsulation:vxlan(0x8) esi-label:0x0:all-active (label 0) * 2:10.0.255.3:100::100::aa:bb:cc:11:11:11/304 MAC/IP (1 entry, 1 announced) BGP group overlay type Internal Route Distinguisher: 10.0.255.3:100 Route Label: 100 ESI: 00:00:00:00:00:00:00:00:00:00 Nexthop: Self Localpref: 100 AS path: [65200] I Communities: target:65000:123 encapsulation:vxlan(0x8)
I have no idea of the use case for this.
------------------------------
Simon Bingham
Original Message:
Sent: 08-02-2022 20:10
From: Dakota McGee
Subject: JNCIE-DC topics and documentation - need more detail
William,
Dude, thank you very much for the detail. I'm less confused now than before I read this! I haven't had time to ingest all of this yet, but this did help point me a little bit further down the MAC-VRF rabbit hole.
My understanding here is that a MAC-VRF cannot exist without an IP-VRF (if my understanding of RFC 9135 is correct). This means two routing-instances for one tenant, which seems....a bit much. That's two unique loopbacks, at least two unique RT / RD each, and BOTH instances have EVPN config in them. Am I alone in thinking this is a ton of config just for one tenant? Am I misunderstanding the use-case?
For the Type 5 routes - if an engineer configures set protocols evpn ip-prefix-routes
+ options, would that not just advertise Type 5 routes to all neighbors in the EVI, even if they need Type 2/3?
Perhaps this is answered in one or more RFCs that I haven't fully digested yet. I've currently got 7432, 7348, 8365, 9135, and 9136 open for reading.
------------------------------
Dakota McGee
Original Message:
Sent: 08-02-2022 18:48
From: William Pincek
Subject: JNCIE-DC topics and documentation - need more detail
Hi Dakota,
#1 In relation to a data center built on QFXs, if you need to use pure Type 5 routes, you must configure CNH or the PFE will not program the tunnel next hop (See KB32854 below). I'm not too sure about the Leaf vs Spine issue that you mention.
https://supportportal.juniper.net/s/article/QFX-EVPN-VXLAN-configuration-knobs-and-caveats?language=en_US
#2 My guess is that going forward, MAC-VRF will be the preferred way to configure EVPN/VXLAN. Before MAC-VRF, a QFX could only have a one-to-one mapping between VNI and VLAN ID. I always thought of this as a bit of a limitation and also didn't really match up to RFC 7432. RFC 7432 defines several "Service Interfaces", many of which, a QFX wasn't able to do before. With MAC-VRF, a QFX can support VLAN-based (similar to non-MAC-VRF behavior), VLAN-aware, and VLAN-bundle service interfaces.
#3 Type 5 routes solve EVPN routing problems both inside a single data center and also between two data centers. The easiest one to think about is the DCI case. Assume we have two overlay VLANs, VLAN 100 (DC1) and VLAN 200 (DC2), that we want to route between. Lets also assume that each VLAN currently has 1000 learned MACs. Without type 5 routes, the border router for DC1 would have to advertise 1000 Type 2 routes to the remote DC. With type 5 routes, the border router for DC1 will only have to advertise a single Type 5 to the remote DC. If multiply the number of VLANs by any number, we can easily see how Type 5's helps our DCs scale.
The harder one to explain is how Type 5's can help a single DC scale. Assume we have two leaf nodes that are acting as both L2 and L3 EVPN/VXLAN gateways. Assume we have two overlay VLANs, VLAN 100 (on Leaf1 only) and VLAN 200 (on Leaf2 only), that we want to route between. Lets also assume that each VLAN currently has 1000 learned MACs (not sure how realistic that it but just go with it.) Without type 5 routes, Leaf1 would have to advertise 1000 Type 2 routes (for VLAN 100) to Leaf2. Why does Leaf2 need these Type 2 advertisements? Leaf2 needs the Type 2 advertisement to populate its own VLAN 100 bridge domain which has no directly attached hosts for VLAN 100. Thats right, Leaf2 only has attached hosts that belong to VLAN 200 but it still needs to populate a second bridge domain for VLAN 100. Doesn't this seem to be a waste of resources? If you said yes, you would be right. By using type 5 routes only, Leaf1 will only have to advertise a single Type 5 to Leaf2 and Leaf2 does not have to maintain a bridge domain for VLAN 100 at all. Again, if you multiply the number of VLANs by any number, we can easily see how Type 5's helps our DCs scale.
#4 Honestly, I think it relates back to pre-MAC-VRF vs MAC-VRF. The reason for so many RDs and RTs makes much more sense in the MAC-VRF scenario where each EVPN gets its own routing-instance configuration. From RFC 7432, "The policy attributes of EVPN are very similar to those of IP-VPN. An EVPN instance requires a Route Distinguisher (RD) that is unique per MAC-VRF and one or more globally unique Route Targets (RTs)." Again, I would focus on MAC-VRF configuration going forward.
#5 I do not know if vrf-table-label is needed or not. I lean towards not. The classic purpose of vrf-table-label was to allow a M/T/MX series device to perform an MPLS lookup, pop, and IP lookup in one pass through the PFE (egress PE of an MPLS VPN tunnel). It was only needed in the case that the device did not have a tunnel services pic installed. I see that the self-study bundle and the day-one book (https://www.juniper.net/documentation/en_US/day-one-books/TW_DCDeployment.v2.pdf) has it configured everywhere. I can also tell you that we don't teach it at all in the ADCX course and I can see an example of pure type 5 here, https://www.juniper.net/documentation/en_US/release-independent/solutions/information-products/pathway-pages/solutions/evpn-type5-configuring.pdf, that also does not show it configured. My gut feeling is that it doesn't hurt to have it configured but I don't think it is really doing anything. I'm happy to have anyone else enlighten us. ;)
Hope that helps.
------------------------------
William Pincek
Original Message:
Sent: 08-02-2022 14:09
From: Dakota McGee
Subject: JNCIE-DC topics and documentation - need more detail
Hi Josh,
Nice to speak with you again :)
Surprisingly, Apstra is the EASY part here. The JNCIE workbook is more than enough to get a good understanding of the tech. I've taken the on-demand version of ADCX and didn't really feel prepared for JNCIP at all. I barely passed. So I'm not sure I would agree that course is sufficient in explaining these confusing topics at all.
Here's my current confusion. All taken from the solutions sections of the JNCIE-DC workbook.
#1
set routing-options forwarding-table chained-composite-next-hop evpn ingress
- I understand what this does from a EVPN-MPLS perspective thanks to the book "MPLS In The SDN Era", but I can find NOTHING on Google that explains exactly what this does in EVPN-VXLAN. Every Juniper doc recommends enabling it on the leaf but not on the spine. Best they say is "allows the device to process greater amount of traffic".
- That's fantastic...how? Why would an engineer enable this? What is the use case? What problem does it solve? I know what composite-next-hops are and what they do in MPLS. What is this doing in VXLAN?
#2
mac-vrf
- My understanding here is that this instance-type is simply a "virtual-switch" that works in tandem with an IP-VRF (i.e. "virtual router"). Enables complete isolation at L2.
- Why would anyone enable this? VLANs are already "isolated" at L2. If the IRB doesn't route the traffic then the two VLANs can't talk anyway. Why does this instance-type need it's own RD/RT that is unique from the IP-VRF RD/RT if they work together? Just seems like over-complicating config for no real benefit.
#3
EVPN Type 5/IP Prefix routes
- I'm failing to understand why this is a thing. RFC-7432 doesn't really explain this well either imo. EVPN is mainly used for L2VPN (it's even in the AFI L2VPN in MP-BGP). If we are going to enable Type 5 routes, why are we even using EVPN vs standard MP-BGP in the context of a data center network?
#4
RD/RT under both "protcols evpn" and "switch-options"
- I'm seeing RD/RT needing to be configured under both of these hierarchies, but both are unique. Why is there so many different places that need "unique" RD/RT? What is this accomplishing?
#5
set routing-instances tenant1 vrf-table-label
- Totally understand what this does in MPLS and why someone would want to enable it. What does this do for VXLAN? I find no mention anywhere in my Juniper docs search how a "label" has an effect on VXLAN.
I think this is everything that I'm super confused on at the moment. I'm 100% sure there will be more in this journey. Thanks again for taking the time out to offer help and guidance - I can really use it.
------------------------------
Dakota McGee
Original Message:
Sent: 08-02-2022 11:54
From: Josh Verhaal
Subject: JNCIE-DC topics and documentation - need more detail
Dakota,
The JNCIE Self Study Bundles were not designed to provide you with the detailed learning of the underlying technologies. To learn that level of information you should take/review the courses that contribute to the other JNCIx level prerequisite exams. I suspect the part that you may be missing is the Apstra component since you are JNCIP-DC certified. For the Juniper Apstra knowledge I would recommend taking the Juniper Apstra course. This course provides the detailed explanations of the components that were included in the JNCIE-DC exam and SSB. For more information about EVPN/VXLAN I would recommend the ADCX course.
I hope this helps point you in the right direction
Regards,
Josh Verhaal
------------------------------
Josh Verhaal
Original Message:
Sent: 08-01-2022 14:54
From: Dakota McGee
Subject: JNCIE-DC topics and documentation - need more detail
Hi all,
I'm currently working through the new JNCIE-DC self-stufy bundle via the AAP. I'm finding many of the technologies in chapter 2 are poorly described in the workbook. Many of them are basically just "turn on this feature X because it solves Y".
This is not what I need to learn. I want to understand why I'm turning on a feature, what problem it solves, how it solves it, and what is happening on the device FIB/RIB to make that happen. Most of the Juniper documentation on EVPN-VXLAN and QFX say even less than the workbook. I've found SOME clarity via the RFCs at times, but even that is not really enough to help me truly understand some of the configuration knobs.
Has anyone else ran into this with JNCIE? This is making my impostor syndrome flare up super hard because I think I'm going to be a terrible JNCIE even if I pass because I won't be able to explain some of these knobs or why someone would use them.
------------------------------
Dakota McGee
------------------------------