Taking control of the last-mile delivery

Managed network service providers (MNSPs) and their particular issues don’t generally keep me awake at night. But in a world of SD WAN disruption and its tendency towards less and less visibility for MNSPs due to more and more closed boxes littering the last mile landscape, those MNSP engineers aren’t getting a whole lot of sleep when it comes to dealing with last mile delivery issues.

Network insight has been all the rage over the last couple of years, but that telemetry is generally exclusive to the equipment owners – leaving MNSPs, who have no access to the hardware, in the dark. As this problem becomes increasing prevalent, many of the tools designed to shine light on this issue require expensive tooling and complex integrations.

Ixia’s newly announced IxProbe offers itself as an operationally simplistic approach to this visibility gap. In a small form factor that takes minutes to install inline, IxProbe provides traffic stats, link status, and when used in conjunction with Ixia’s Hawkeye, a battery of QoS and link quality tests.

Below are just a few features this test probe brings to the table.

- Can be installed by non technical resources in the field
- Both active and synthetic test capable
- Adopts the IP address of the router (watch this video at the 7 min mark for a good discussion on how this works)
- Fail-to-wire (if the device fails, your link doesn’t)
- Only answers to your configured whitelist of management IP
- APIs for network management system integration

IxProbe isn’t just for MNSPs, and it’s not just for inline testing. While you probably have a myriad of other monitoring solutions, networking probes, and QoS testing devices inside your own network, it’s worth noting that the IxProbe performs tests out of band and can easily be deployed throughout branch networks and other edge locations, perhaps as an option for unifying your test probe solution.

There is a 1 gig limitation on the device, though, so beware you won’t be using this to analyze performance on those big ole backbone links.

If you’re interested in more information on the IxProbe and how it fits into the rest of the Ixia testing and monitoring portfolio, be sure to check out both of these short TFD21 videos here.

You can also find the data sheet here: https://www.ixiacom.com/resources/ixprobe-active-sla-monitoring-service-providers-and-enterprises

Disclaimer: While Networking Field Day, which is sponsored by the companies that present, was very generous to invite me to the fantastic NFD21 event and I am very grateful for it, my opinions are totally my own, as all redheads are far too stubborn to have it any other way.

Published 10/26/2019

Preserving and managing intent using Apstra AOS

Apstra’s Networking Field Day 16 presentations highlighted key issues engineers face every day. The traditional ways of spinning up configurations and validating expected forwarding behavior falls short of the needs of networks of any size. For anyone who has encountered a network where the documentation was woefully outdated or practically non-existent, and whose design requirements and purpose were deduced purely from rumors and vague supposition, Apstra offers AOS and its Intent Store.

More than just configuration management, the idea of Apstra is to manage not just the building of consistent configurations abstracted from the specific hardware, but also to provide a controlled manner in which to address and manage network design revisions throughout the network’s life cycle.

Changing business needs impart necessary modifications to device dependencies and performance, Apstra addresses these revisions by maintaining a single source of truth – the documented intent* – and providing tools to validate this intent. As Derick Winkworth said “it’s about moving the network [design] from being all in someone’s head” to making the design something consistent, tangible, and best of all, something that can be queried, and by extension, verified.

Under the covers, Apstra makes use of graph theory, and for those who’d rather not Google that, the upshot is nodes get added and relationships get tied to nodes. The structure allows for a flexible schema that lends itself to ever-changing quantities of connections and also to new types of inter-dependencies between objects.

For example, Apstra added the ability to create links between network nodes and the applications that run through them. This is done through some DevOps wizardary which this video highlights well, and the additional relationship mappings allow the network operator to query for application paths and diagnosis traffic flow issues.

For a short how-is-this-useful-to-me, I highly recommend this explanation by Damien Garros on using Apstra to shorten the time it takes to deploy crazy amounts of security zones, validate them, and monitor them. Snazzy stuff for any engineer who has ever faced a security auditor.

Disclaimer: While Networking Field Day, which is sponsored by the companies that present, was very generous to invite me to this fantastic event and I am very grateful for it, my opinions are totally my own, as all redheads are far too stubborn to have it any other way.

*Intent is all the buzz these days, back in my day we called it policy or design requirements. But I’ll try to avoid waving my arms and shouting get off my LAN… 🙂

Published 9/25/2017

Forward Networks – go ahead, break it.

When you’re tasked with planning for data center failover testing, you spend an awful lot of time reviewing configurations and scenarios, scrutinizing every detail to ensure that when the plug is pulled – both figuratively, and in some cases, literally, that all will go according to plan. If you are someone lucky enough to have a lab environment at your job, it’s usually only a partial reconstruction of the network at best. In many cases, the luxury of a lab is simply non-existent in the workplace. I tend to exist in that latter world…

Watching Forward Networks present at Network Field Day 13, I couldn’t help but think how great this solution would be for exactly these types of scenarios. Sure, you can plow through configurations manually and predict with some certainty that your routing is resilient. However, what if you could run through failover scenarios and network changes in advance, actually see the impacts in a lab that faithfully reconstructed your entire network? The confidence in the DR testing plan skyrockets, and the reliance on anti-anxiety meds and lucky rabbit feet plummets.

The Forward Networks solution allows you to do just that by basically pulling all your configurations from your production gear, building your network, and then letting you break it. You could also just evaluate the network as well, if you’re not feeling particularly destructive. Forward Networks has several built in checks for elements that are commonly misconfigured, such as port channels, vlans, and port duplex settings, pretty much letting the lab network point out your previously overlooked mistakes.

You can also use Forward Networks to determine the complete path of certain traffic using their rather snazzy UI, which allows for some intuitive queries formed in human-speak, not SQL-I-don’t-know-the-right-table-name-please-just-show-me-my-data format.

Forward looking at the Forward Networks solution (see what I did there?) – I do wonder if price will be an obstacle for small to medium enterprise, as several products in this space are reassuringly expensive.*

I love that there is already a long list of vendors whose gear is supported in the product, but keeping pace with new vendors and OS versions will be a certainly be a challenge – one Forward Networks sounds excited to take on.

Definitely check out David Varnum’s post on Forward Networks as well, he goes into some detail on the company, the APIs of the product, and configuration checks Forward Networks is capable of in it’s current release. He’s also included some nice screen shots of the UI.

All of the videos from NFD13 from Forward Networks are a good watch, but if you only pick one, don’t miss the simulated outage demo. You’ll laugh, you’ll cry, you’ll be totally impressed by how much fun watching a pretend network failure can be.

*reassuringly expensive: a term I credit to the one and only Greg Ferro and a term that I make frequent use of in networking.

Published: 11/28/2016