Networking Field Day 25, Part 2

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.

To check out the recorded presentations, take a look at the event page here

This is my second post (Part 2) where I want to capture my over-arching thoughts on Networking Field Day 25 and the vendor presentations. In later posts, I want to dive into specific vendors and technologies that were brought to the table at NFD25.

The main thing I wanted to talk about regarding the Nokia presentation is Nokia SR Linux. Nokia prides themselves on making their NOS as open as possible, and SR Linux is an extension of that concept. You may have read my Part 1 Post where I wrote about the ArcOS from Arrcus, so this wasn’t the first NOS in NFD25 and it actually won’t be the last in this blog either.

This slide’s goal is articulating the siloed management of applications and interaction. Application management is isolated in user-space between one another, and individual YANG modules handle interaction tasks with each application in SR Linux. For the actual management via API, all communications funnel through the SR Linux management layer of the diagram. I asked a question about the management interaction layer involving security and how granular one could be in controlling user interaction with applications. As an example, could the administrator only allow User A to manage application A and User B only manage application B? The answer by the Nokia team was yes, even though there is a single management layer for underlying applications and YANG modules, granular rules for permitting access are still available.

The interesting part of SR Linux is that Nokia can grab state and data from Applications that would otherwise possibly be abstracted away by a traditional NOS. In a demo, Nokia showed the ability to take specific action when a route is not available to a specific neighbor in the RIB. First thought that comes to mind is that something like this is already possible in traditional NOS’s with on-box monitoring and events, and triggering actoin based on those events. I think a better example of the abilities in SR Linux would be shown with a more complex example, possibly monitoring state and cross-referencing a specific application/service’s reachability with that information. I’m a firm believer that forwarding state is not representative of true network reliability. Our networks are only as good as the applications they serve (to the end user) and we may as well exist to help serve these applications. By monitioring application availability, we can make more intelligent forwarding decisions toward anycast application destinations.

Welcome to the world of WiFi 6E, and it comes with a demo from Aruba Networks! The demo was pretty impressive from Aruba, albeit it basically in a vacuum. It’s one of the first times I’ve really paid attention to the tri-band scenario from an AP (2.4/5/6GHz).

Click on the image if you’re struggling to see things, and sorry in advance if so. Basically, the aggregate throughput was 2.2Gbps for the vacuum test that Aruba demoed. Keep in mind this was using 80MHz channel not only for 6GHz but also for 5GHz, and a 2.4GHz channel width of 40MHz. Obviously, these are not going to be realistic results for the real-world applications you and I will deploy, but it was still nice seeing 6GHz in action in the demo.

After the demo, the first question that came to mind was “Can you actually take advantage of all 3 bands at once?” Think about a scenario where 6GHz could handle most clients, but if a certain limit is reached, clients are shifted to 5GHz to take off load and improve experience. The answer from Aruba was basically that they are early stages with this WiFi 6E gear, and they are very early stages as far as the programming and software is concerned. However, I look forward to seeing what Aruba and other vendors can make happen with user experience in the tri-band world.

Silver Peak acquisition

Skipping straight to Aruba Networks SD-WAN product, Aruba aquired Silver Peak in 2020. Watching the demo environment Aruba presented, you can see right away that this seems like a fairly mature SD-WAN solution. Their EdgeConnect appliances create IPSec tunnels from spokes to hubs, and hubs connect to one another, and you know the rest. Imagine the networks you’ve worked with traditionallary forever, creating spokes off of centralized hub routers, and there is a hub or two per office. That’s a simple way to visualize what you could have with Aruba’s EdgeConnect devices as well.

So that sounds like what we are used to in managing Branches and Hub office locations. We are used to building VPN tunnels and connectivity across whatever WAN connections we have access to. Silver Peak aims to be your easy button for provisioning this connectivity, as well as monitoring and adapting to issues in the SD-WAN network. Silver Peak has what they call “Business Internet Overlays” which sounds like a marketing term for virtual networks over tunnels that act how you “intend” them to. When configuring these overlays, you can tell Silver Peak how to treat the traffic that’s sent over that overlay. An overlay can leverage a broadband connection, L3VPN WAN, DIA circuit, etc and obviously each underlay will cater to traffic differently. These rules in the “Business Intent Overlays” allow you to prioritize your traffic granularly per subnet or some LAN characteristic.

Silver Peak uses IP SLA to make decisions on what underlay to use for specific overlays. My understanding is that if an IP SLA is not reached on an overlay traveling on a specific underlay, we back that up and can forward traffic over another overlay tunnel that is meeting our IP SLA. For their IP SLA metrics, they mentioned ICMP as well as HTTP/s check. That’s fine and good, but I always love the idea of super granular options in regard to SLA-checking, especially when you’re talking about something as critical as your users’ ability to reach applications and services.

IPv6

Silver Peak is supporting IPv6 only for the underlay WAN connection, you can’t use IPv6 in the LAN right now while doing any policies or fancy overlay configurations. They mentioned VRRP and BGP are next on their roadmap, and then possibly IPv6 thereafter.

I honestly didn’t have much foresight into IP Infusion products going into their presentation. I hadn’t done my research to any level that was appropriate, and I wasn’t prepared for what was about to come our way at NFD25. For some reason beyond my control, I have a knee-jerk reaction to 5G and 5G-enabled networks due to all the marketing speak over recent years. However, the IP Infusion presentation focused on the technology and the reasons for their reference architectures - and it really made sense from a technical perspective and it was NOT all about marketing-speak.

I highly recommend you watch the video located here and pay close attention to the ability of OcNOS to help scale the network from 4G to 5G and to O-RAN. By scaling up and scaling out capacity while keeping IP/MPLS core the same, you have a modularized network that keeps intelligence at the edge. O-RAN takes that a step further by having O-RAN compliant enodeB’s and EPC’s that can tie into your network and hold almost all of the intelligence and state besides that of what is needed in the core for the IP/MPLS backbone.

Seamless MPLS

I also found the Seamless MPLS reference architecture slide from IP Infusion to be insightful. If you take a look at the diagram above, you can pick out that the MPLS EXP bit (for QoS) is end-to-end, and the LSP path is also end-to-end. However, the IGP domain is not end-to-end and BGP-LU is used to stitch together single LDP and RSVP LSP boundaries. This is an example of how to scale and tie an existing network to a network that is scaling beyond what it once was. By stretching LSPs end to end, we can keep our routing tables in the core small while keeping our edges smart. It’s refreshing to see that IP Infusion is endorsing this architecture and embracing the benefits to 5G scaling it may have.

Tibit Hardware with OcNOS-OLT

It was funny - I kept thinking during this presentation and all of the OcNOS-OLT talk that this would be great for Tibit GPON-on-a-Stick, and lo and behold here are are.

The micro-OLT from Tibit really does seem awesome. Think of all the flexibility you have being able to plug an entire OLT into your hardware router/switch of choice and be able to manage that OLT from VM/external software. No more full-chassis-OLT boxes, endless flexibility. It is really nice to see this integration into the IP Infusion software array of products, and even better seeing the partnership for Tibit hardware. It sounds as though the goal is to use OcNOS-OLT to aggregate the management of OLTs to a single software NOS solution. IP Infusion also mentioned OpenBNG toward the very end of their presentation, which I’m also interested in seeing develop.

Right off the bat, Mansour reminds us of the principles surrounding the Juniper Apstra software. As you will find if you watch their recorded presentation, Apstra not only provides the means to stand up a data center EVPN fabric, but also guides one through closed loop change management and operations. It is also rrefreshing to me that even though this is now a Juniper Networks acquired solution, that Apstra is still open and multi-vendor with automating EVPN Datacenter networking.

Automated Data Center Interconnect

I was definitely excited for this section of the Juniper Networks presentation by Jeff T. Not only because I spent time watching/listening to the Between 0x2 Nerds episodes by Jeff T. and Jeff D., but also because DCI is something I like pondering the different reference architectures of.

So, Jeff shows us a diagram of two Data Centers separated by a WAN AS65533. The middle AS65533 is providing us with a L3 means of connecting our VTEPs to one another. Based solely on this design (intent), Jeff is able to deploy EVPN with Anycast Gateway for connecting the San Jose and Atlanta Data Centers. I really liked the anomaly detection that Apstra provides after changes are committed. When deploying DCI, the more help you can get the better because more often than not you have pressure to get revenue-generating service stood up in a timely fashion.

I asked the question of whether Apstra supports EVPN/VxLAN to EVPN/MPLS stitching, to which Jeff’s answer was that verify soon that would be finished and released. I think that this will be helpful to some datacenter customers that have a running EVPN/MPLS in the core but would like to extend EVPN into the data centers for whatever reason they may have. Think of a Service Provider scenario where the SP is providing EVPN/MPLS sevice to many customers, but starts doing work inside of the data centers using EVPN with VxLAN transport instead of MPLS. By making that a seamless EVPN environment, some hassle is taken away from the operators as long as they can recognize that an ethernet frame flows for example from VxLAN environment into the MPLS backbone with stitching. I’m curious to see what Apstra comes up with in terms of making this an easy-to-manage EVPN network that’s stitched together. (On the Juniper side, you may be familiar with lt- interfaces already…)

Tags and Connectivity Templates

The next thing the Apstra team hit hard on was connectivity templates and tags. Connectivity templates allow an operator to bulk-configure many client interfaces at once for example without much hassle. Tags provide the ability to run analytics given a specific tag or group of devices, interfaces, etc. I see some promise in these two features in keeping things simple to manage while keeping a sane workload.

NSX-T Demo and Automation

So, this is where some really neat stuff comes in that I think everyone can appreciate. One super cool feature is the ability to look into (read-only) the VMware NSX-T to check for missed port group VLAN and other anomolies (possibly MTU mismatch). After an anomaly is detected, Apstra could add the needed VLAN to the trunk facing the server to restore connectivity.

As you can see above, Apstra was able to notice a missing VLAN in the EVPN fabric compared to the configuration of the VMware NSX-T, and Apstra is recommending a remediation change to be made. Pretty cool stuff.

Kid in the Automation Candy Store

Calvin R. of Juniper showed us a bag of tricks with Service Now, Apstra, and some slack-bot magic. It really was very enjoyable to watch his demo so I really recommend checking it out. It was very neat watching Calvin start in ServiceNow ordering a data center project to be completed, following through with slack bot for interaction. Also, shout out to the use of EVE-NG during the demo! My favorite thing about this demo was you could really see how during a new DC deployment or with DC troubleshooting day 2 you could see how realistic this workflow can be with Apstra and APIs.

This was really my first time meeting Juniper Apstra, and I can say honestly that I’m impressed with what they have going on over there. It’s refreshing and it all feels realistic for today and tomorow’s data centers. I especially enjoyed the support for modern architectures such as forward-thinking DCI that will be flexible for Service Providers that also run data centers. I’m also impressed by the API interactibility and the overall verification and anomaly detection that comes out of the Apstra interface. This may have been my first time meeting the Juniper Apstra product but I’ll look forward to seeing more developments from this team in the future.

Disclosure

I was invited to be a delegate at NFD25, no gifts or swag influenced my decisions in writing this blog post. My participation in the event and in this content is all voluntary. Gestalt IT was nice enough to host the other delegates and myself virtually on the big screen of Networking Field Day 25. Some swag gifts were provided by the sponsors to us delegates, but I did not expect anything and there was no further requirement of delegates to participate in blog content. All thoughts are my own and straight from my keyboard to your viewing eyes.

Written on May 26, 2021