Category: network management

In Episode 69 of Software Gone Wild we discussed ways of increasing visibility into VXLAN transport fabric. Another thing we badly need is visibility into the virtual edge behavior, and to help you get there Iwan Rahabok created a set of vRealize dashboards that include the virtual edge networking components. Hope you’ll find them useful.

If you're a networking engineer, sysadmin, or NetDevOps guru preferring the power of CLI over carpal-syndrome-inducing GUI you might like the My Looking Glass tool developed by Mehrdad Arshad Rad. Haven't tried it out, but the intro on GitHub page looks promising.

If you decide to try it out (or already did) please share your experience in a comment. Thank you!

When people started talking about OpenConfig YANG data models, my first thought (being a grumpy old XML/XSLT developer) was “that should be really easy to implement for someone with XML-based software and built-in XSLT support” (read: Junos with SLAX).

Here’s how my simplistic implementation would look like:

My friend Jeremy Stretch wrote an IPAM+DCIM tool for Digital Ocean and open-sourced it. As the tool was designed by networking engineers to manage data center networks (more in Jeremy’s blog post), it might be a better fit than other tools out there. In any case, check it out and let me know how it works.

After listening to Open-Source Network Engineer Toolbox Nick Buraglio sent me an email saying “we should do another podcast on open-source network management tools…” and so we did. In Episode 56 of Software Gone Wild Nick, Elisa Jasinska and myself discussed a whole range of network management challenges and open-source tools you can use to address them.

Imagine you’d design your network by documenting the desired traffic flow across the network under all failure conditions, and only then do a low-level design, create configurations, and deploy the network… while being able to use the desired traffic flows as a testing tool to verify that the network still behaves as expected, both in a test lab as well as in the live network.

Time for another fill-in-the-blanks survey: how many vendors support NETCONF and/or REST API in their data center switches, routers, firewalls and load balancers?

Please help me complete the tables by writing a comment – and do keep in mind that it only counts if it’s documented in a public configuration guide on vendor’s web site.

Also, I’m not aware of any vendor using standard NETMOD YANG models. If someone does, please let me know.

During my recent SDN workshops I encountered several networking engineers who use Nexus 1000V in their data center environment, and some of them claimed their organization decided to do so to ensure the separation of responsibilities between networking and virtualization teams.

There are many good reasons one would use Nexus 1000V, but the one above is definitely not one of them.

How do you capture all the flows entering or exiting a data center if your core Nexus 7000 switch cannot do it in hardware? You take an x86 server, load nProbe on it, and connect the nProbe to an analysis system built with ELK stack… at least that’s what Clay Curtis did (and documented in a blog post).

Obviously I wanted to know more about his solution and invited him to the Software Gone Wild podcast. In Episode 39 we discussed:

A recent well-publicized network outage prompted someone to start collecting fat-finger horror stories, and dozens of networking engineers were quick to chime in. Enjoy!

A while ago someone working for an IT-focused media site approached me with a short list of high-level questions. Not sure when they’ll publish the answers, so here they are in case you might find them interesting:

What can enterprises do to ensure that their infrastructure is ready for next-gen networking technology implementations emerging in the next decade?

Next-generation networks will probably rely on existing architectures and forwarding mechanisms, while being significantly more uniform and heavily automated.

A while ago Chris Young sent me a few questions about network management in the brave new SDN world. I never focused on network management, but I know a few people who do, including Terry Slattery and Matt Oswalt. Interop brought us all together, and we sat down one evening after the presentations to chat about the challenges of monitoring and managing SDN networks.

We started with easy things like comparing monitoring results from virtual and physical switches (and why they’ll never match and do we even care), and quickly diverted into all sorts of potential oscillations caused by overly-dynamic load balancing caused by flow label-based ECMP and flowlets.

PF_RING is a great open-source project that enables extremely fast packet processing on x86 servers, so I was more than delighted when Paolo Lucente of the pmacct fame introduced me to Luca Deri, the author of PF_RING.

When we started chatting, we couldn’t resist mentioning ntopng, another open-source project Luca is working on.

Christoph Jaggi, the author of Metro Ethernet and Carrier Ethernet Encryption Market Overview published an awesome follow-up document: an evaluation guide that lists most of the gotchas one has to be aware of when considering encryption gear, from deployment scenarios, network overhead and key exchange details to operational considerations. If you have to deal with any aspect of network encryption, this document is a must-read.

SDN evangelists talking about centralized traffic engineering, flow steering or bandwidth calendaring sometimes tend to gloss over the first rule of successful traffic engineering: Know Thy Traffic.

In a world ruled by OpenFlow you’d expect the OpenFlow controller to know all the traffic; in more traditional networks we use technologies like NetFlow, sFlow or IPFIX to report the traffic statistics – but regardless of the underlying mechanism, you need a tool that will collect the statistics, aggregate them in a way that makes them usable to the network operators, report them, and potentially act on the deviations.