03.6.18

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 »
02.13.18

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

10.30.16

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 »
09.29.15

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 »
04.23.15

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 | 2 Comments »
04.17.15

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.

com0com1
Read the rest of this entry »

05.17.13

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 192.168.0.0/24 subnet (vlan 1), and we will create an 'local' (inside for cisco people) subnet 192.168.10.0/24, on vlan 100, and vlan 100 should have an interface ip of 192.168.10.2 (to keep it consistent). We will need two hosts attached to the switch, one in each vlan. I have used 192.168.0.1 and 192.168.10.10 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 »