WeOS
5.20.1

# MRP 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.

- MRP Configuration Guide

## 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.

« Previous Next »