WHAT TO EXPECT
In this article, users will learn how to configure SwXtchBridge, switch it to high performance capability, check logs and set static subscriptions.
Switching to High Performance Mode
Certain NICs can handle a high-performance version of the swXtchBridge. This should only be used if an implementation requires higher throughput than 10+ GB of traffic. For a complete list of recommended NICs, see NIC Requirements under swXtchBridge System Requirements.
To install the high-performance drivers, users need to provide the --high_perf_driver argument in the installation line.
curl http://<swxtch-ip>/swx/services/install/swx-bridge-install.sh -o swx-bridge-install.sh; chmod +x swx-bridge-install.sh; ./swx-bridge-install.sh --auto_deps --high_perf_driverTo switch from a standard mode to high-performance mode, the --persist is needed (to conserve settings):
curl http://<swxtch-ip>/swx/services/install/swx-bridge-install.sh -o swx-bridge-install.sh; chmod +x swx-bridge-install.sh; ./swx-bridge-install.sh --auto_deps --high_perf_driver --persistAccessing logs for swXtchBridge
Use the
docker pscommand to list all the Docker containers currently running on your machine.$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 27f64deaac2e swx-bridge:latest "./entrypoint.sh" 4 days ago Up 42 minutes swx-bridgeRecord the Docker name of the swXtchBridge service you would like to see logs for.
Use the
docker logscommand with the container service name:Look at the logs with
docker logs swx-bridge -f -n 100
Configuring swXtchBridge Interfaces
By default, the 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 manually. See swXtchBridge Topologies to understand the 3 interface settings.
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
{
"persistenceFolder": "/var/opt/swxtch/persistence",
"logFolder": "/var/log/swxtch",
"httpPort": 80,
"disableLogTimestamp": true,
"logStackTraceTag": null,
"logTags": [
"info",
"error"
],
"serverTlsConfig": null,
"clientTlsConfig": null,
"component": {
"ctrlInterfaceName": "ens5",
"dataInterfaceName": "ens6",
"userInterfaceName": "ens6",
"dataPort": 9999,
"nicsConfig": null,
"maxGroundSubscriptions": 2000,
"pollingIntervalMilliseconds": 1000,
"subscriptionsPollingIntervalMilliseconds": 100,
"overrideSrcIp": false,
"maxTimeStatsNs": null,
"cpu": -1,
"protocolConfig": {
"cgroupName": "swx-protocol",
"cpuSet": "",
"cpuUsage": 80
},
"processes": {
"swxCore": {
"launch": true,
"options": null,
"args": {
"--verbosity": "1"
}
},
"swxTunnelIgmp": {
"launch": true,
"options": null,
"args": {
"--verbosity": "1"
}
},
"swxTunnelSingleNic": {
"launch": false,
"options": null,
"args": {
"--tunIP": ""
}
},
"swxTunnel": {
"launch": true,
"options": null,
"args": {
"--verbosity": "2"
}
},
"swxProtocol": {
"launch": true,
"options": null,
"args": {
"--cpu-set": "",
"--cpu-usage": "80",
"--verbosity": "1"
}
},
"swxBridgeData": {
"launch": true,
"options": null,
"args": {
"--verbosity": "1"
}
}
},
"installedConnection": {
"controlAddress": {
"ip": "172.51.128.132",
"port": 80
},
"dataAddress": null
},
"nonSlpMtu": 1500,
"dataGatewayIp": 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 the bridge and then to the userInterface.
"pollingIntervalMilliseconds:" Polling consists of 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 an API call to get the swxtch-bridge.json file. See the cloudSwXtch API section, especially the Bridge API. See also swXtchBridge Topologies
For a single interface
To accomplish a single interface configuration for the swXtchBridge, users will need to specify the same Interface Name for Ctrl, Data, and User in the swxtch-bridge.json file. In the example, each interface is assigned to eth0.
"ctrlInterfaceName": "eth0",
"dataInterfaceName": "eth0",
"userInterfaceName": "eth0",For 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",For three interfaces
Alternatively to the single interface approach, a user can decide to place the swXtchBridge between three interfaces in order to redirect traffic from the control, user interface to the data interface and the user interface. In the example below, the ctrlInterfaceName is (eth2) and the dataInterfaceName is (eth1) while the userInterfaceName differs (eth0).
"ctrlInterfaceName": "eth2",
"dataInterfaceName": "eth1",
"userInterfaceName": "eth0",Using swXtchBridge cloud to ground API to Join/Leave
For cloud to ground, if there are Arista/Juniper COTS switches interconnecting devices, the bridging can forward joins and leaves. But for standard infrastructure that’s not able to handle that, there is currently no support to propagate IGMP joins and leaves. Multicast groups must be explicitly configured to let the bridge know what traffic is to be transported.
This task can be done via the API with an HTTP call to the swXtchBridge.
Examples:
To Join:
curl -X POST http://<BRIDGE_CTRL_IP>/swx/subscriptions/addGroundSubscription -d '{"MulticastGroups":["239.239.239.99:9000"],["239.2.3.4:10000"]}'To Leave:
curl -X POST http://<BRIDGE_CTRL_IP>/swx/subscriptions/removeGroundSubscription -d '{"MulticastGroups":["239.239.239.99:9000"]'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",swXtchBridge Docker Commands
After deploying your swXtchBridge, a user can execute commands to stop, start, and restart their instance. They can execute these commands in the command window of their swXtchBridge.
First, you must find the Docker name or ID.
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
e4dfedcc27d8 swx-bridge:latest "./entrypoint.sh" 2 hours ago Up 2 hours swx-bridgeSTOP
Permanently stops the swXtchBridge. In order to
docker stop swx-bridgeSTART
docker start swx-bridgeRESTART
docker restart swx-bridge