Configuration Examples

There are a few basic RBridge principles to keep in mind:

  • Two RBridge endpoints need to mutually authenticate to each other in order to establish a link (a virtual network cable between two distinct LANs).
  • How they actually communicate is not important, the only requirement is that they actually can exchange their UDP packets in some way.
  • If an RBridge endpoint has no idea where the other side sits, it may be configured to consult a third party in that case (an RBridge registry).
  • Traffic encryption is optional, but authentication is mandatory.
  • An RBridge endpoint never tunnels itself.

Please note that the configuration examples below contain no licensing parameters.

Example 1: Explicit communication, authentication only

Endpoint A

interface=        eth0
macsecret=        "DatacenterLink-EW"
remote_address=   ::ffff:10.3.4.11

Endpoint B

interface=        eth0
macsecret=        "DatacenterLink-EW"
remote_address=   ::ffff:10.22.8.11

Notes

  • It’s sufficient to specify the remote_address parameter on one side only.
  • Alternatively, the remote_address parameter accepts also numerical IPv6 addresses and FQDNs resolving to an A or AAAA record.

Example 2: Explicit communication, authentication and encryption

Endpoint A

interface=        eth0
macsecret=        "DatacenterLink-EW"
key=              "4c118d0eb6ec9289a7b9c796816aa07d"
remote_address=   ::ffff:10.3.4.11

Endpoint B

interface=        eth0
macsecret=        "DatacenterLink-EW"
key=              "4c118d0eb6ec9289a7b9c796816aa07d"
remote_address=   ::ffff:10.22.8.11

Notes

  • It’s sufficient to specify the remote_address parameter on one side only.
  • Alternatively, the remote_address parameter accepts also numerical IPv6 addresses and FQDNs resolving to an A or AAAA record.
  • It’s important to have the same key on both sides (otherwise complete garbage would be injected into the LANs).

Example 3: Explicit communication, authentication+encryption with true random key material

Endpoint A

interface=               eth0
true_random_keymaterial= /home/rbridge/keymaterialDCEW.bin
remote_address=          ::ffff:10.3.4.11

Endpoint B

interface=               eth0
true_random_keymaterial= /home/rbridge/keymaterialDCEW.bin
remote_address=          ::ffff:10.22.8.11

Notes

  • It’s sufficient to specify the remote_address parameter on one side only.
  • Alternatively, the remote_address parameter accepts also numerical IPv6 addresses and FQDNs resolving to an A or AAAA record.
  • Authentication is done using the SHA-2 hash of the key material.
  • Both sides are automatically selecting the encryption key out of the available key material of 2097152 keys total, changing it for every single UDP packet being sent.

Example 4: Consulting the default registry, authentication+encryption with true random key material

Endpoint A

interface=               eth0
true_random_keymaterial= /home/rbridge/keymaterialDCEW.bin
registry_linkname=       "DCLINKEW"

Endpoint B

interface=               eth0
true_random_keymaterial= /home/rbridge/keymaterialDCEW.bin
registry_linkname=       "DCLINKEW"

Notes

  • Authentication is done using the SHA-2 hash of the key material.
  • Both sides are automatically selecting the encryption key out of the available key material of 2097152 keys total, changing it for every single UDP packet being sent.
  • Our default RBridge registry (listening on r.inlab.net and r6.inlab.net) is consulted to determine the mutual communication parameters.
  • The IP-protocol (IPv4 or IPv6), the addresses and the port numbers are automatically selected as available.
  • This works the same way for examples 1+2, the remote_address parameter may be removed in these examples (but this is not mandatory, if they succeed to talk directly they will do).

Example 5: Consulting your own registry, authentication+encryption with true random key material

Endpoint A

interface=               eth0
true_random_keymaterial= /home/rbridge/keymaterialDCEW.bin
registry_address_1=      ipv4.your.own.registry.example
registry_address_2=      ipv6.your.own.registry.example
registry_macsecret=      "my-registry-authentication-secret"
registry_key=            "my-registry-encryption-key"
registry_linkname=       "DCLINKEW"

Endpoint B

interface=               eth0
true_random_keymaterial= /home/rbridge/keymaterialDCEW.bin
registry_address_1=      ipv4.your.own.registry.example
registry_address_2=      ipv6.your.own.registry.example
registry_macsecret=      "my-registry-authentication-secret"
registry_key=            "my-registry-encryption-key"
registry_linkname=       "DCLINKEW"

Notes

  • Authentication is done using the SHA-2 hash of the key material.
  • Both sides are automatically selecting the encryption key out of the available key material of 2097152 keys total, changing it for every single UDP packet being sent.
  • Your registry is consulted to determine the mutual communication parameters, communication with your registry is separately authenticated and encrypted using registry_macsecret and registry_key (in this example).
  • The IP-protocol (IPv4 or IPv6), the addresses and the port numbers are automatically selected as available.
  • This works the same way for examples 1+2, the remote_address parameter may be removed in these examples (but this is not mandatory, if they succeed to talk directly they will do).