Configuring swXtchBridge Interfaces
By default, swXtchBridge installation will attempt to resolve the interface that is routable to the cloudSwXtch. However, if a user would like to do this manually, the swXtchBridge can be configured in one of two ways:
For hairpin forwarding on a single interface
For bridge in the middle redirection between two interfaces
This section will go into the changes a user would have to make to the swXtchBridge JSON configuration file to apply the above methods.
Where to Find swXtchBridge Configuration Files
The location of the swXtchBridge JSON file is /var/opt/swxtch/swxtch-bridge-cfg.json.
swXtchBridge Configuration JSON Example
{
"bridgeConfig": {
"ctrlInterfaceName": "eth0",
"dataInterfaceName": "e636:00:02.0",
"userInterfaceName": "e636:00:02.0",
"nicsConfig": null,
"swxtchCtrlIp": "10.2.128.10",
"swxtchCtrlPort": 80,
"swxtchDataIp": "10.2.192.116",
"swxtchDataPort": 9999,
"overwriteSenderIp": null,
"dataGatewayIp": null,
"groundToCloudSubscriptions": null,
"cloudToGroundSubscriptions": [],
"pollingIntervalMilliseconds": 1000,
"subscriptionsPollingIntervalMilliseconds": 100,
"mtuSize": 1500,
"adaptorsConfig": {},
"overrideSrcIp": false,
},
"xdpModeData": null,
"xdpModeUser": null,
"cloudTunIp": null,
"rpcPort": 10002
},
"ha": {
"producer": false,
"consumer": false,
"bufferSizeInPackets": 131072,
"maxTimeToBufferPacketsMs": 50,
"protocol": "swxtch"
},
"streamSpecs": null
}
Fields in Common Explained
Below are deeper explanations for certain fields in the cloudSwXtch config file:
"ctrlInterfaceName": NIC used for control-plane communication with cloudSwXtch
"dataInterfaceName": NIC used for the data-plane communication with cloudSwXtch. For Bridge 2, the config file uses the ethernet name. For Bridge 3, the config file uses the PCI address.
"userInterfaceName": NIC used for multicast ground traffic. For Bridge 2, the config file uses the ethernet name. For Bridge 3, the config file uses the PCI address.
"pathId": Please set this to zero.
"groundToCloudSubscriptions": Please leave blank as it is no longer necessary since ground to cloud is done dynamically via IGMP joins from the cloud client.
"cloudToGroundSubscriptions": Traffic coming into the cloudSwXtch with these addresses will be forwarded to bridge and then to the userInterface.
"pollingIntervalMilliseconds:" Polling consists on a sync with the cloudSwXtch to exchange MC groups information.
Using the status API call to get swxtch-bridge JSON file
Alternatively, users can use a /status API call to get the swxtch-bridge.json file. To do this, use the following command replacing the <bridge-ctrl-IP> with the IP address of the bridge:
curl -x GET http://<bridge-ctrl-ip>/status
For a single interface
To accomplish a single interface configuration for your swXtchBridge, users will need to specify the same InterfaceName for Ctrl, Data and User in the swxtch-bridge.json file. In the example, each are assigned to eth0.
"ctrlInterfaceName": "eth0",
"dataInterfaceName": "eth0",
"userInterfaceName": "eth0",
For bridge in the middle of two interfaces
Alternatively to the single interface approach, a user can decide to place the swXtchBridge between two interfaces in order to redirect traffic from the user interface to the data interface. In the example below, the ctrlInterfaceName and the dataInterfaceName are the same (eth1) while the userInterfaceName differs (eth0).
"ctrlInterfaceName": "eth1",
"dataInterfaceName": "eth1",
"userInterfaceName": "eth0",
Using swXtchBridge cloud to ground API to Join/Leave
swXtchBridge has the capability to do join and leaves from ground to cloud via an HTTP endpoint on the bridge. This will enable the forwarding of multicast traffic from cloud to ground.
To Join:
curl -X POST http://<BRIDGE_CTRL_IP>/addCloudToGround -d '{"MulticastGroups":["239.239.239.99:9000"],"UpdateConfigFile":false}'
To Leave:
curl -X POST http://<BRIDGE_CTRL_IP>/removeCloudToGround -d '{"MulticastGroups":["239.239.239.99:9000"],"UpdateConfigFile":false}'
Note: A user can set the UpdateConfigFile to "true" in order to make their configuration permanent. This means that the changes to swXtchBridge will persist between restarts.
Configuring swXtchBridge Static Subscriptions
The cloud to ground and ground to cloud flows are static based on entry into a json file. In order to do this, modify the bridge JSON configuration file and add the static multicast groups for either groundToCloudSubscriptions or cloudToGroundSubscriptions. This can also be accomplished using wXcked Eye. See Adding Cloud To Ground (C2G) Subscriptions via a Bridge Component Node.
Modify the JSON array attribute for "cloudToGroundSubscriptions" or "groundToCloudSubscriptions" and add the appropriate multicast groups from either option.
{
"bridgeConfig": {
"ctrlInterfaceName": "eth0",
"dataInterfaceName": "eth1",
"userInterfaceName": "eth0",
"swxtchCtrlIp": "10.0.0.1",
"swxtchCtrlPort": 80,
"swxtchDataIp": "10.0.1.1",
"swxtchDataPort": 9999,
"pathId": 0,
"groundToCloudSubscriptions": [
"226.0.23.182:13000",
"226.0.23.183:13000",
"226.0.23.184:13000",
"226.0.23.185:13000"],
"cloudToGroundSubscriptions": [
"225.0.23.182:12000",
"225.0.23.183:12000",
"225.0.23.184:12000",
"225.0.23.185:12000"],
"pollingIntervalMilliseconds": 1000
}
}
After modifying the configuration file, restart the swXtchBridge service with the following commands:
Stopping/Starting/Restarting swXtchBridge
First you must find the docker name or id.
ubuntu@ip-172-41-128-232:~$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
f8fb84bbaf53 swxtch-bridge "./entrypoint.sh" 14 minutes ago Restarting (2) 37 seconds ago swxtch-bridge-control-1
STOP
docker stop swxtch-bridge-control-1
START
docker start swxtch-bridge-control-1
RESTART
docker restart swxtch-bridge-control-1
In the example above, these multicast groups will now be sent from both cloud to ground and ground to cloud at startup for bridge.
Using a specific gateway address for swXtchBridge
By default, swXtchBridge will resolve the data gateway MAC address by arping the first IP address of the subnet for the data interface. However, if the gateway IP address is not there, then the dataGatewayIP field can be added into the configuration file. This will force the Bridge to resolve the gateway MAC address by using the IP address specified. In the example below, the user inserted their own data gateway IP address.
"dataGatewayIp": "192.168.1.2",