A RECAP OF RIPE76

It's May 2018, on the south coast of France. Several hundred people are converging (heh) on Marseille for a week-long event, filled with tech talks, policy, discussions about the future (and past) of the Internet, questions and comments and statements, cheese and a lot of socializing with like-minded people. Below you will find my record and impressions of this trip, together with a few photos and links to other write-ups.

20180530 | net | #conference #notes #story

NX-OSV 9000 AUTOMATION (3)

I've been documenting my quest to make building and destroying a local lab using NXOSv 9000 as painless as possible in part 1 and part 2. This post is pretty much the TL;DR of the series, as in the meantime I figured out the best way to run multiple instances of this image through Vagrant. So here's what I've been using for the past half year together with a few Ansible playbooks to perform some basic but very necessary tasks.

20180205 | net | #cisco #nexus #automation #howto #labs

DOCKER OVERLAYS ON CISCO ACI

I started the new year troubleshooting Docker Overlay network traffic pushed through a Cisco ACI fabric that was not working despite physical connectivity and contracts being in place. Or so we thought... as VXLAN encapsulated packets (used by Docker overlays) do not follow the usual expected pattern.

20180104 | net | #cisco #dc #docker #linux #tshoot

NX-OSV 9000 AUTOMATION (2)

In part one of this series we looked at starting up a couple of Nexus9000v machines using a tool called vagrant. It went OK, but we had some unfinished business. In this post we'll look at how I try to address the MAC address issues and run my first ansible playbook against this lab.

20170623 | net | #cisco #nexus #automation #howto #labs

NX-OSV 9000 AUTOMATION (1)

A recent tweet caught my eye: a new version of NX-OSv was available, together with instructions on setting it up in vagrant. Very good timing too, as I'm building automation (a bit of orchestration and a lot of validation) for a couple projects including for both the 7K and the 9K flavours of NX-API and could really use a decent machine-local lab.

20170531 | net | #cisco #nexus #automation #howto #labs

DMVPN-OVER-MOBILE BLUES

It all started a while ago with a log message found on the hub of a large DMVPN/IPSEC deployment over mobile Internet connections. Given the increasing number of deployments that use the Internet as a cheaper, faster WAN for either primary or backup, I thought it would be useful to document the problems and the two main solutions.

20170211 | net | #cisco #routing #wan #tshoot

BFD ON INDIVIDUAL ETHERCHANNEL MEMBERS

I was recently watching BRKDCT-2333 - Data Center Network Failure Detection and, after going through the usual suspects - L1 (carrier loss, link signaling), L2 (LACP, UDLD, CFM/Link-OAM), L3 (protocol keepalives, BFD) - the presenter talks about BFD over EtherChannel. But not only for node protection (see below), but for link protection as well, running micro-BFD sessions on each individual EtherChannel member. After understanding how it is done, I started wondering what's the point (tangible benefit) of using this feature?

20170201 | net | #design #routing #cisco

DEFINING AN IMPROVED WAN

In the past couple of years I've had quite a bit of exposure to customers with large WANs in various industries (many non-IT centric) - with xDSL and DMVPN/FlexVPN playing a big role alongside simpler things like fibre based L3VPN and Internet access. I'm going to stay away from SD-anything because they are often vague marketing loaded terms, but that doesn't stop me from asking: what would an improved WAN offering look like? By improved I mean that it solves some of the challenges we're facing today (technical, user experience, cost, deployment etc.) or makes a big impact on customer experience.

20161102 | net | #wan #design

SSL PERFORMANCE

In a recent discussion with fellow network engineers about encryption in a DC network, I made an observation that in some cases it might be better to simply enforce end-to-end encryption directly between applications rather than in the underlying infrastructure (MACsec, IPSEC etc.). Looking at MACsec for example, as crypto is done by the ASIC, the general opinion was that it must be faster than doing it on a server CPU. But having no real data or comparison of that, I decided to dig a bit deeper.

20160926 | net | #crypto #dc