WeOSMRP Over Layer 2 Tunnel
About
This document presents an example use-case where a MRP ring is configured and part of the ring is connected over a Layer 2 OpenVPN tunnel.
Introduction
This is a setup that could be used where a Layer 2 redundancy in the form of a ring topology is wanted, but where part of the ring topology needs to be connected over another network. A Layer 2 ring topology would not really be possible in this kind of situation, but if it is combined with a Layer 2 OpenVPN tunnel it becomes a possible setup.
Public Network/Internet
.--.-.
( ( )__
.----------------(_, \ ) ,_)---------------.
| '-'--`--' |
| |
| vlan2 | vlan2
| IP: 198.18.10.1 | IP: 198.18.10.2
eth1 | Untagged: eth1 eth1 | Untagged: eth1
.-------. .-------.
| | ssl0 ssl0 | |
| MRM +===================================+ MRC-1 |
| | OpenVPN L2 Tunnel | |
'---+---' '---+---'
eth2 | vlan1 eth2 | vlan1
| IP: 10.0.0.1 | IP: 10.0.0.2
| Untagged: ssl0,eth2 | Untagged: ssl0,eth2
| |
| |
| |
| |
| vlan1 | vlan1
| IP: 10.0.0.4 | IP: 10.0.0.3
eth2 | Untagged: eth1,eth2 eth2 | Untagged: eth1,eth2
.---+---. .---+---.
| | eth1 eth1 | |
| MRC-3 +-----------------------------------+ MRC-2 |
| | | |
'-------' '-------'
Figure 1: A MRP ring configured normally, except for the link between the MRM and MRC-1, that instead uses a L2 tunnel to connect as ring ports.
The devices MRM and MRC-1 both have their eth1 ports connected to the WAN (Public network/Internet). The Layer 2 Tunnel will be established over this connection. In this example it is also assumed that an OpenVPN key has already been generated and imported to both the MRM and MRC-1 and labeled psk1. Both devices have their eth2 and ssl0 ports configured as their MRP ring ports.
The devices MRC-2 and MRC-3 both have their eth1 and eth2 ports configured as their MRP ring ports.
Note
This example assumes that the vlan interfaces 1 and 2 have already been configured on the devices in the example.
Configuring the Layer 2 Tunnel
In this setup the MRM device will serve as the OpenVPN server node and the MRC-1 will be configured as a client and peer towards it.
Server Configuration
The MRM device can be configured as a OpenVPN server node in the following manner.
mrm:/#> configure mrm:/config/#> tunnel ssl 0 mrm:/config/tunnel/ssl-0/#> server mrm:/config/tunnel/ssl-0/#> method psk mrm:/config/tunnel/ssl-0/#> secret psk1 mrm:/config/tunnel/ssl-0/#> type tap mrm:/config/tunnel/ssl-0/#> leave mrm:/#>
The Layer 2 tunnel will have a virtual port interface ssl0 created on the device. This is the port interface we will use as one of the ring ports later when configuring the MRP instance.
Remember to add the newly created ssl0 port to a vlan that is intended to be used for the MRP ring ports. This must be done because the port interface must be part of the bridge, and adding it to a vlan will make it part of the bridge.
mrm:/#> configure mrm:/config/#> vlan 1 mrm:/config/tunnel/vlan-1/#> untagged ssl0 mrm:/config/tunnel/ssl-0/#> leave mrm:/#>
In this case we also need to ensure that we enable flooding to the CPU of unknown packets, because we combine virtual port interfaces with physical. Therefore, this needs to be enabled if traffic should be handled as you would expect. Enable it in the following manner:
mrm:/#> configure mrm:/config/#> system mrm:/config/system/#> flooding unicast multicast mrm:/config/system/#> leave mrm:/#>
Client Configuration
The MRC-1 device can be configured as OpenVPN client that peers against the server in the following way:
mrc-1:/#> configure mrc-1:/config/#> tunnel ssl 0 mrc-1:/config/tunnel/ssl-0/#> no server mrc-1:/config/tunnel/ssl-0/#> method psk mrc-1:/config/tunnel/ssl-0/#> secret psk1 mrc-1:/config/tunnel/ssl-0/#> type tap mrc-1:/config/tunnel/ssl-0/#> peer 198.18.10.1 mrc-1:/config/tunnel/ssl-0/#> leave mrc-1:/#>
The client will now attempt to peer against the server and establish the Layer 2 tunnel connection.
Same as with the server, we add the ssl0 port interface to the vlan that we want to use for our MRP ring ports.
mrc-1:/#> configure mrc-1:/config/#> vlan 1 mrc-1:/config/tunnel/vlan-1/#> untagged ssl0 mrc-1:/config/tunnel/ssl-0/#> leave mrc-1:/#>
Again as we did on the server, we need to enable flooding to the CPU of unknown packets:
mrc-1:/#> configure mrc-1:/config/#> system mrc-1:/config/system/#> flooding unicast multicast mrc-1:/config/system/#> leave mrc-1:/#>
Status
The status of the tunnel can be checked by either checking the port status, since the tunnel endpoint ssl0 is treated as a port:
mrm:/#> show port
PORT LINK TYPE SPEED STATE OWNER/VLAN
[...]
ssl0 Up SSL Forwarding vlan U:1
We can also check the status of the tunnel connection in the following way:
mrm:/#> show tunnel ssl
TUNNEL DESCRIPTION STATUS UPTIME
0 ssl0 UP 0 Days 2 Hours 30 Mins 44 Secs
Note
Remember that it could take a few seconds for the tunnel to establish its connection and for the tunnel status to be displayed as UP.
Adjust keepalive For Better MRP Reconfiguration
If the tunnel connection goes down it will take a while for it to notice that the connection is down, so the ssl port can be in forwarding when it is really down. This could potentially cause some instability in the MRP ring if the tunnel link goes up and down.
In order to make the tunnel more faster in detecting connection issues the keepalive setting can be adjusted:
mrm:/#> configure mrm:/config/#> tunnel ssl 0 mrm:/config/tunnel/ssl-0/#> keepalive interval 1 restart 2 mrm:/config/tunnel/ssl-0/#> leave mrm:/#>
mrc-1:/#> configure mrc-1:/config/#> tunnel ssl 0 mrc-1:/config/tunnel/ssl-0/#> keepalive interval 1 restart 2 mrc-1:/config/tunnel/ssl-0/#> leave mrc-1:/#>
Doing this could help make the MRP connection better if link changes occur in the tunnel part of the ring.
Note
This issue could be better solved with a link check protocol like IEEE 802.1ag CFM (Connectivity Fault Management). Unfortunately it is currently not available in the product.
Testing Connection
We can verify the connection by simply attempting to ping the address of the interface that is associated with the ssl0 port interface. In this example we added the ssl0 interface to vlan1 that has the ip address of 10.0.0.2 on the MRC-1. Therefore, if the tunnel have been established correctly we should be able to ping that address from the MRM device:
mrm:/#> ping 10.0.0.2 Press Ctrl-C to abort PING 10.0.0.2 (10.0.0.2): 56 data bytes 64 bytes from 10.0.0.2: seq=0 ttl=64 time=1.903 ms 64 bytes from 10.0.0.2: seq=1 ttl=64 time=0.925 ms [...]
Configuring the MRP Ring
When configuring a MRP ring only one of the devices can serve as the Media Redundancy Manager (MRM) and the rest of the devices will serve as Media Redundancy Clients (MRC). The MRM is responsible for ensuring that there will be no loop in the network by blocking one of its ring ports. If there is a link break somewhere in the ring, it is also the MRM that will ensure that all nodes in the ring will still be reachable by putting its blocking ring port into forwarding.
Tip
When configuring the ring its good to ensure that there is no closed loop while the ring is being set up. This could be done by bringing down the ports or unplugging the cable so that there is no loop. Otherwise, it is likely that a broadcast storm could occur.
MRM Configuration
mrm:/#> configure mrm:/config/#> ring mrp 1 mrm:/config/ring/mrp-1/#> mode manager mrm:/config/ring/mrp-1/#> profile 200 mrm:/config/ring/mrp-1/#> ports ssl0, eth2 mrm:/config/ring/mrp-1/#> leave mrm:/#>
MRC-1 Configuration
mrc-1:/#> configure mrc-1:/config/#> ring mrp 1 mrc-1:/config/ring/mrp-1/#> profile 200 mrc-1:/config/ring/mrp-1/#> ports ssl0, eth2 mrc-1:/config/ring/mrp-1/#> leave mrc-1:/#>
MRC-2 Configuration
mrc-2:/#> configure mrc-2:/config/#> ring mrp 1 mrc-2:/config/ring/mrp-1/#> profile 200 mrc-2:/config/ring/mrp-1/#> ports eth1, eth2 mrc-2:/config/ring/mrp-1/#> leave mrc-2:/#>
MRC-3 Configuration
mrc-3:/#> configure mrc-3:/config/#> ring mrp 1 mrc-3:/config/ring/mrp-1/#> profile 200 mrc-3:/config/ring/mrp-1/#> ports eth1, eth2 mrc-3:/config/ring/mrp-1/#> leave mrc-3:/#>
Status
When MRP have been configured on all the devices we can check the status of the MRP ring.
Tip
It is best to check the status on the MRM. It is possible to check the status on the MRCs, but the MRM will be more accurate. Since the MRCs obtain some of its status information from the MRP Test frames that are sent from the MRM, while the MRM have direct access to the status information.
The status of the MRP instance can be observed in the following manner:
mrm:/#> show mrp 1 Ring ID : 1 Enabled : Yes running as PID 2233 Mode : MRM Status : Closed (CHK_RC) Profile : 200 Port 1 : ssl0 BLOCKED (UP) Port 2 : eth2 FORWARDING (UP) VLAN ID : 0 React on link change : Enabled Transitions : 1 Last topology change : 0 Days 0 Hours 0 Mins 10 Secs MRM Src Addr : 74:69:6e:67:20:6d
Test Connections
In order to verify if all the devices in the node are reachable we can ping the addresses of the vlans that the MRP ring ports are assigned to:
mrm:/#> ping 10.0.0.2 Press Ctrl-C to abort PING 10.0.0.2 (10.0.0.2): 56 data bytes 64 bytes from 10.0.0.2: seq=0 ttl=64 time=1.903 ms [...] mrm:/#> ping 10.0.0.3 Press Ctrl-C to abort PING 10.0.0.3 (10.0.0.3): 56 data bytes 64 bytes from 10.0.0.3: seq=0 ttl=64 time=1.843 ms [...] mrm:/#> ping 10.0.0.4 Press Ctrl-C to abort PING 10.0.0.4 (10.0.0.4): 56 data bytes 64 bytes from 10.0.0.4: seq=0 ttl=64 time=1.701 ms [...]
The same could be repeated after breaking a link or bringing down a port so that the ring must reconverge. All the devices should still be accessible on the same addresses.