Blog Home

MACsec is an interesting alternative to existing tunneling solutions, that protects Layer 2 by performing integrity, origin authentication and, optionally, encryption. Normal use-case is to use MACsec between hosts and access switches, between two hosts or between two switches. This article is a leftover from MACsec on Linux that I first tested in 2016 when support for MACsec was just included in the kernel. I will describe how MACsec is used together with a Layer 2 GRE tunnel to protect the traffic between two remote sites, over WAN or Internet, like a site-to-site VPN at Layer 2.

Welcome back to a new article about SDN - this time introducing an OpenFlow controller called Faucet, developed as a RYU application by New Zeeland Research and Education (REANNZ), Waikato University and Victoria University. In this article, I am not going to write about Faucet's architecture and features since you can read about it on its github page or here or here. Instead, I will describe the setup used for a demo presented at the Irish Network Operators Group 11th meetup (iNOG::B).

Your company has an IPsec tunnel with another company for achieving network connectivity between servers in 10.10.10.0/24 on your side to 10.20.20.0/24 on theirs. Lately they complained that their equipment has problems dealing with ESP and requested to migrate this existing IPsec tunnel from Encapsulating Security Payloads (ESP) to Authentication Headers (AH), since encryption/confidentiality was never a requirement for this tunnel. What could go wrong ?

As you noticed from the previous articles, lately I have been playing with some various tunnelling techniques and today I am presenting MACSEC. Most of the documentation resources about MACSEC implementation on the web, at this moment, are the ones showing various vendors implementation, especially Cisco's approach. Although it's not a new topic, Linux support for MACSEC was added only recently.

In my previous article I presented various encapsulation techniques used to extend Layer 2 reachability across separate networks using tunnels created with Open vSwitch. Although the initial intention was to include some iperf test results, I decided to leave these for a separate post (this one!) because I hit few problems.

Building overlay networks using tunnels was always done to achieve connectivity between isolated networks that needed to share the same policies, VLANs or security domains. In particular, they represent a strong use-case in the data center, where tunnels are created between the hypervisors in different locations allowing virtual machines to be provisioned independently from the physical network.

Over the next few articles, I will write about OpenFlow, Open vSwitch and other SDN related topics. As always, I'm combining the theory part with some hands-on practice and for this, I put this article together describing one way of building such a testing environment.

Hello and Welcome, again, to my newly brushed website !! After a long period of inactivity, I decided to resume my on-line activity and started by migrating away from Wordpress onto a new platform based on something that I use pretty often these days: Python !

This post represents the solution and explanation for quiz-24. It shows that using always option with default-information originate may have an undesired effect !...