Port mirroring with GRE

I recently had a requirement to mirror a port from a physical machine to a virtual machine. Initially I thought it would be pretty trivial, but when I came to implement it, it turned out to be less than straightforward. While it certainly is possible, in a complex data center environment there can be a lot of changes that need to be made which might make it an unattractive option.


If the distribution switch you are using happens to support erspan, then you can set that up and send all the traffic to the VM directly. Your traffic will have the GRE header attached to the packet, but for many applications this may be acceptable. In our case it was not, so I wrote a filter driver using WinpktFilter to strip all the GRE headers off before being passed up the stack to the protocol drivers.

In our case, we also didn't have a switch that supported erspan. So I wrote another filter driver which takes all the packets arriving on an interface, wraps them up in an GRE packet and spits them out the same or different interface. You can put this tunneling application either on the source machine itself or a dedicated machine that has the source machine mirrored to it using a regular switch port mirror - this way you can avoid modifying the source machine at all if it is running critical production processes. The source for both filters is at
https://github.com/Raggles/gremirror - gretunnel tunnels the packets and grestrip strips the GRE headers at the other end. This solution works well with the winpcap driver because winpcap is a protocol driver whereas WinpktFilter is a intermediate driver/LWP Filter driver (depending on OS). I haven't yet tested with npcap, so I'm unsure whether npcap will see the packets before or after they have the GRE headers removed.

| Posted in Networking | No Comments »

Loopback interfaces on RX1500

Recently we decided to convert a bunch of layer 3 radio links into layer 2 links in order to simplify our OSPF routing database, work around a couple of nasty OSPF bugs in the radios and achieve better balancing when there are equal cost paths.  However this took me down a bit of a rabbit hole that I wasn't expecting - consider the topology change below:

On the left, all of the central routers interfaces are in one vlan/subnet.  On the right the interfaces all have their own IP addresses.  This creates a problem - what IP address does one use when wanting to ssh into the device?  We can use any of the IP addresses of course, but what about monitoring via SNMP?  What about terminating VPN endpoints?  Which IP do we choose, when any of the radio links might be down for whatever reason, and therefore the associated IP address will be unavailable?
Read the rest of this entry »

| Posted in Networking | No Comments »

Adapting ospf-visualiser for use with RuggedCom RX1500

A handy thing to see in an OSPF network is a visual view of the active paths and costs.  There are a couple of expensive tools around that can do this very well, but there isn't much around that can do it for free.  One such free tool is ospf-visualiser which can take output from quagga and print out a pretty picture of the network.  If you have telnet enabled on a machine with quagga then you can telnet to it and everything is supposed to work, but it isn't compatible with RuggedCom devices out of the box.

Therefore I have extended ospf-visualiser so that it can SSH to a RuggedCom ROXII device, log in using the given credentials and extract the required data to build the model.  Rather than write a new parser for the RuggedCom ospf command output, I have opted to log in to the maintenance shell and run the quagga commands directly so the existing data parser can be used, which means that the total amount of code changed is actually quite small.

New SSH options for source data

New SSH options for source data

Output for example RuggedCom network

Output for example RuggedCom network

The next step will be to enable live listening to LSA packets so that the visualisation is truly live, but for now the source and binaries are on Github


Multipath routing with MimoMax and RX1500

Recently I have been working on a project that involved adding redundant paths to a couple of existing comms links, using RuggedCom RX1500 routers at the end of each link, deploying OSPF to manage the routing.  The links themselves are RF, using Mimomax NDL radios which are also routers running OSPF. The paths are equal cost so I was expecting the RX1500 to load balance the paths more or less equally.  This was indeed the case, but when we plugged it all in, our DNP communications to all of the RTUs on those links appeared to get worse, with lots of failed polls occurring.  Upon further inspection it was mostly class 0 polls that failed, and the reason was that the packets were arriving out of order.  It is important to note here that were using DNP over UDP at the time. Below is an approximate diagram of the network (subnets are represented by the circles).

Network diagram

Network diagram

Read the rest of this entry »

| Posted in Networking | No Comments »

Analysis of Mimomax Captures

Mimomax radios produce the best debugging data available to the customer that I have seen on any radio so far, and you can gain some excellent insights as to what is happening at your sites RF wise by looking at them.  Mimomax  have some tools that will produce some graphs and they are all too happy for you to send them captures and they will provide you with some graphs and commentary as to what they think is going on.  However they are unlikely to give you the tools to generate these graphs, as they like to know their customers issues and to some extent don't want people to potentially come to the wrong conclusion by looking at data they might not fully understand.  I'm ok with that, but I still wanted to analyse the data without having to wait a day or two!  So I have whipped up a few Octave scripts to do a similar job.
Read the rest of this entry »

| Posted in Networking | No Comments »

Improved guide to Firewalls, IPSec, OSPF and L2TP on the RuggedCom RX1500

Its been a while since I last played with the RX1500, and since then I've learned a few things. This post is an improved and updated version of the previous post on the topic.

The setup for this example is most easily demonstrated by the diagram below:rx1500-l2tp1
Read the rest of this entry »

| Posted in Networking | 4 Comments »

Virtual Serial Ports, com0com, RFC2217, and Radio

Tunneling com ports over tcp, and in particular over low bandwidth radio links can be a tricky business. Even more so if you are on windows and want to use free or preferably open source software. Recent work I've been involved in has required that many devices with different and proprietary protocols (all serial in nature) be tunneled over a udp radio connection from a Windows server to the client device.  The image below demonstrates the conecpt.

Read the rest of this entry »


Setting up a L2TP/IPsec VPN and firewall on a Ruggedcom RX1500

NOTE: This post has a number of mistakes in it - please refer to the new post on this subject.

This quick howto explains the setup required to get a basic L2TP/IPsec VPN up and running with a Windows 7/8 native client and a Ruggedcom RX1500 Backbone Router (and hopefully explains it better than the manual!)

First, make sure all the connected systems have the same time! This is required for some types of encryption and its generally best to make sure the time on everything is right so we can be sure it won't cause problems.

Network setup:

To keep things easy, we will stick with some defaults that come out of the box for the RX1500 - our 'outside' network is the subnet (vlan 1), and we will create an 'local' (inside for cisco people) subnet, on vlan 100, and vlan 100 should have an interface ip of (to keep it consistent). We will need two hosts attached to the switch, one in each vlan. I have used and for my external hosts (vlans 1 and 100 respectively).

Once we have assigned interface(s) to vlans 1 (should be done by default) and 100, and assigned the appropriate ip addresses to the vlan interfaces, we are ready to setup IPsec.

Read the rest of this entry »

| Posted in Networking | 6 Comments »