Welcome to the world, RFC9000 QUIC: A UDP-Based Multiplexed and Secure Transport”! We’re happy to have you.

But it was MTU.

If you happened to read NFD25 - Part 1, then this is an extension of what I talked about over there. This NFD25 was so packed with awesome presentations that I could not fit all of my brief thoughts on each company into a single post. Today, I’m focusing on what we were shown by Nokia, Aruba Networks, IP Infusion, and Juniper Networks.

I was invited to be a delegate at Networking Field Day 25 and it did not disappoint in the slightest. It was by far one of the best community event experiences I’ve had in networking so far. It’s hard to believe that I really only started this networking-focused journey 5 or less years ago, and I get to sit in the same virtual room as some very well-respected minds in Networking. In addition to getting to meet the other delegates, we were graced with an extremely busy schedule of presentations from the following vendors: Kemp Technologies, VMware, Arrcus, Intel, Path Solutions, Nokia, Aruba Networks, Juniper Networks, and IP Infusion.

In 2021, I have focused many of my efforts into the JNCIE-DC study journey. After passing my JNCIE-SP in November, I made a goal to bounce straight off of it and segway over to JNCIE-DC. In the world of EVPN/VXLAN, MC-LAG, IP and L2 fabrics, and scripts I was able to carve a path to a passing score, becoming JNCIE-DC #401. Also, you can find me at Networking Field Day 25 as a delegate this week Wednesday through Friday and I’m really looking forward to my first time participating on this panel.

I scheduled my JNCIE-DC attempt a few months back for end of April, purchased the official Juniper JNCIE-DC workbook, and I have hit the topics in the blueprint. I was able to complete all of the relevant labs in an EVE-NG environment with vMX and vQFX devices. But, I was unable to lab the Virtual Chassis Fabric as well as applying output traffic profiles to interfaces in the QFX Class of Service configuration. Time for some hardware!

iBGP Route Reflection is an important technique used by many iBGP-enabled networks. By relaxing the full-mesh requirement of iBGP sessions and using designated Route Reflectors per cluster, we no longer have to configure a full-mesh of neighbor statements on every PE router. However, Route Reflectors by default will not only reflect routes between clients, but will also select a best-path as would any other router running BGP. The best-path selected by the RR could often not be the same best-path that would’ve been selected by a client when IGP metric is considered in the path selection process.

Title isn’t 100% accurate, because I’m not making this post of code snippets because I’m poor and can’t run REAL BFD. Rather, recently added a transit provider who refused to config BFD on our BGP sessions. LACP in a LAG/port-channel also wasn’t an option, too many L2 devices between my router and theirs in the transport to make it useful.

In the thick of studying for JNCIE-DC, I wanted to write a blog post on using L3VPN as a DCI technology, and running EVPN over the top. L3VPN and the IP/MPLS transport network is going to provide us with routing of the VTEP addresses that we can establish our EVPN/VXLAN overlay with. I think using L3VPN for DCI makes a lot of sense for a production network where the WAN may be managed my a separate team than the server/edge networking. To the team managing the EVPN/VXLAN overlay, all they care about is having L3 connectivity between VTEPs to establish VXLAN tunnels. To the WAN team, they can manage the IP/MPLS transport network and the MPLS VPN services the same way they probably always have, without any big WAN architectural changes.

Seamless MPLS is derived from Interprovider VPN Option C, as BGP Labeled Unicast is used between administrative domains. In Interprovider VPN Option C, eBGP-LU is used to extend LSPs between two Autonomous Systems at the AS border. In Seamless MPLS, BGP-LU is used to extend the MPLS network and LSPs beyond regional administrative boundaries. The boundary can be an Autonomous System border like with Interprovider VPN Option C mentioned, but it could also be an IGP area or sub-AS.

Disclaimer - This 4 label stack has nothing to do with SR-MPLS or RSVP Pop&Forward

BGP is the answer, what was the question? When learning iBGP in the beginning stages of my SP-networking journey, I loved the idea of keeping intelligence at the edge. But, how do you actually do that? Read to find out what I’m talking about!

There were several times along the JNCIE-SP journey that I thought about stopping and starting a blog to try and collect all the information I’d learned in some sort of digital archive. But, I never started one, I kept pushing on, and did finally pass my JNCIE-SP in November 2020. I received #3023.