A mobile unit, with a BR2 with 2 cellular WANs and a LAN side with multiple devices
A mothership unit, with a BR1 with 1 cellular WAN (which can have a public IP) and a LAN side with multiple devices
I want to connect both using a high-speed long-range mesh network using Rajant Breadcrump devices. This mesh path should be the preferred path for all data, whilst a Speedfusion tunnel to the BR1’s public IP could be a fallback path for some limited outbound policy selected traffic flows.
Currently, I would think of having two different subnets and having a dedicated route over the Rajant and some outbound policy rules with priorities. What would you recommend? Thanks.
Setup is working now, having the BR1 and BR2 connected to the Rajant breadcrumps and using them as a WAN interface, in a separate IP range for the Rajant part. Using outbound policies, the remote Pepwave devices are used as gateways for their LAN networks. It works, but it’s very ugly, as it’s not scalable to multiple mobile units now.
Instead of having a “default gateway” for a “WAN interface”, I would prefer to setup my routing table myself and have different gateways for different subnets on one particular interface.
Hi Peter. I am running this configuration with USV’s with a customer. USVs travel over a significant distance at very high speed. I can say no more. literally we have two peplink units on the vessel in HA. Rajant operates at Layer 2. Routes are dynamically assessed on each node and utilise a costing algorithm. Sounds like you aren’t using a Rajant Partner here which means you probably are missing out on a great deal of information. I have asked our Sales Engineer based in Spain to make contact.
Great and very cool video! This is indeed exactly the setup as I have put it up until now, except that my Rajant devices are all on the WAN (or WAN over VLAN) ports of the Peplinks, with a fixed IP, as you suggest. In your setup, the BR1’s in the different cars get their WAN IP address through DHCP from the follower cars’ DHCP server on the BR1’s LAN interface, which sets the default gateway to this BR1 LAN IP address. In my static IP configuration, I also set the WAN IP and default gateway, whilst in a scaled solution this default gateway is not always the same. There OSPF has to kick in. Thanks!
I would expect to see the VLAN WAN (VLAN 172) interface in this list. How can I advertise the networks on the LAN part over this VLAN WAN interface to the other side over the Rajant link? Thanks.
With this config I should expect the two networks “Drone LAN” and “test VLAN” are advertised over the WAN 2 - Rajant link/interface.
When I do a PCAP on the other side, I see indeed OSPF Hello packets coming in originating from this device. However, the selected networks are not advertised:
@PeterDedecker , what Martin has described here is exactly what we are doing with the USV’s, I cant say any more than due to existing commericial agreements. on the subject of assigning IP addresses on the Rajant nodes, you can leave them in their default IP configuration… if you go down the route (no pun intended) of using gateway modes on the ethernet ports then you may have to tweak some stuff with IP addresses for our discovery protocols to work. like i said there is a Rajant guy in the EU (Spain) who would be better poised to help.
I also found out the OSPF issue is due to the implementation in the firmware: OSPF is not supported on Virtuals WANs. Swapping the virtual WAN with a real one solves the problem: OSPF does a nice job now. OSPF over Virtual WAN would be a nice feature request.
The only thing to figure out now is the handover between (Rajant) Mesh and Speedfusion (over 4G/5G). Both are different OSPF areas where Outbound policies prioritize the Mesh interface. Only when the OSPF times out and the route is lost, traffic will go over the Speedfusion tunnel. This can cause the device to stick on a poor quality mesh link, or cause a certain time out period before re-routing.
I would rather prefer some kind of Speedfusion tunnel between two Peps, bounding the mesh network and the 4G connection. However, as the 4G of both devices is not always available and certainly not on a public IP address (but behind CG-NAT) this would cause the need for another publicly available device, e.g. a Speedfusion Hub on some cloud provider. In that case, all Speedfusion traffic, even when the Speedfusion tunnel over the Rajant link is prioritized, would go back and forward over the public internet, which is an unnecessary delay.
