Wired

The Wired view presents the scaffolds associated with configuring the wired distribution layer of your network, and monitoring/configuring the switch ports throughout your infrastructure.

Switches

An entry in the switches scaffold defines a piece of switching equipment with which the rXg will communicate for the purpose of effecting dynamic VLAN changes when necessary due to a policy shift for a device on the network.

When a device's VLAN assignment has changed due to a policy shift, the rXg will connect to the switch associated with the device's RADIUS realm via the protocol specified in the configuration, and force a disconnect/reconnect, which will reinitiate the RADIUS authentication process, thereby resulting in the new VLAN assignment being applied to the client device.

The name field is an arbitrary string descriptor used only for administrative identification. Choose a name that reflects the purpose of the record. This field has no bearing on the configuration or settings determined by this scaffold.

The device section specifies information of equipment being configured. Fields with bold text are required. Choose the appropriate option from the supported device types drop-down menu.

Enabling the Monitoring checkbox results in the rXg attempting to import and synchronize Switch Ports from the device, as well as perform ping monitoring of the switch itself, and collect CPU and Memory statistics, where possible.

The SNMP community field specifies the SNMP community string that will be used when attempting to gather CPU and/or Memory information, as well as to collect Switch Port utilization/error/discard data for graphing.

The Switch Fabric field assigns a switch fabric profile to this switch. The Loopback IP , System name , and SPB-m nickname fields must be provided when assigning a switch fabric profile. After supplying the necessary information, the Config sync status link becomes available in the scaffold.

For switches that support configuration management, the Config sync status column contains a link that allows the operator to access bootstrap instructions and enable synchronization.

When bootstrapping a new switch, the operator may retrieve bootstrap commands that will bring a factory default switch or wireless controller into the necessary state to participate in the fabric network, which may be copy/pasted into a console session on the device.

After initial bootstrapping and network connectivity is established, the operator may download a running configuration backup or compare the current running configuration to the expected configuration, based on the associated configuration elements. If changes are needed, they may be pushed to the switch. After successfully synchronizing manually the first time, future configuration changes will be pushed to the device whenever relevant configuration changes are made in the database.

The note field is a place for the administrator to enter a comment. This field is purely informational and has no bearing on the configuration settings.

Automatic Onboarding

Supported switch types (such as Cisco Catalyst IOS-XE and EdgeCore) can be automatically onboarded from a factory-default state. This process eliminates the need to manually configure the switch via console before it can be managed by the rXg.

Prerequisites

Before initiating automatic onboarding, ensure the following:

• The switch must be connected to the network and able to obtain a DHCP address from the rXg.
• Create a switch record in the Switches scaffold with the desired target IP address (the management IP the switch will be assigned after onboarding).
• Enter the switch's MAC address in the device record. This allows the rXg to locate the switch on its temporary DHCP address.
• Configure the Management VLAN if different from VLAN 1.
• Provide valid SSH credentials (username and password) that match the switch's factory default or pre-configured credentials.

Onboarding Process

1. Click the Auto Bootstrap action link in the switch record.
2. The rXg looks up the switch's current DHCP IP address using the configured MAC address from the DHCP leases table.
3. An SSH connection is established to the switch using the temporary DHCP IP.
4. The system detects whether the switch is in factory-default state by checking for the absence of rXg-specific configuration elements (varies by switch model).
5. If factory-default state is detected, bootstrap configuration is automatically applied, including:
   • Management VLAN creation (if not VLAN 1)
   • Static IP address assignment on the management VLAN interface
   • Default gateway configuration
   • SNMP community string
   • AAA and RADIUS configuration for 802.1X
   • Uplink port trunk configuration to carry the management VLAN (with native VLAN 1)
   • NTP server configuration
6. The switch saves its configuration and reconnects on the new management IP address.

After automatic onboarding completes, the switch will appear as online at its configured management IP address and will be ready for configuration synchronization.

Uplink Port Configuration

During automatic onboarding, the uplink port (default: GigabitEthernet1/0/1) is configured as a trunk port to carry both the native VLAN 1 (untagged) and the management VLAN (tagged). This allows the switch to maintain connectivity during the transition from DHCP to static IP addressing.

The trunk configuration is applied in the following order to minimize connectivity disruption:

1. Trunk properties are configured first (native VLAN 1, allowed VLANs) while the port remains in access mode
2. Configuration is saved to startup-config
3. The port mode is changed to trunk, which causes a brief (~30 second) port flap
4. The switch reconnects on its new management IP

Manual Onboarding

For switches that do not support automatic onboarding, or in situations where manual configuration is preferred, the operator may retrieve bootstrap commands and apply them manually.

1. Create a switch record with the desired management IP address and credentials.
2. Click the Config sync status link to access bootstrap instructions.
3. Retrieve the bootstrap commands that will bring a factory-default switch into the necessary state.
4. Connect to the switch via console cable or existing network access.
5. Copy and paste the bootstrap commands into the switch's CLI session.
6. After the configuration is applied, the switch will be reachable at its new management IP address.

Refer to the Switch Model-specific Configuration Details section below for detailed manual configuration steps for each supported switch type.

Switch Fabric

An entry in the Switch Fabric scaffold defines the fabric area of a 802.1aq Shortest Path Bridging-MAC (SPB-m) deployment. All participating fabric switches share the common configuration found here. In addition, each participating fabric switch should have an Infrastructure Device defined with the necessary SPB-m configuration specific to that device.

The name field is an arbitrary string descriptor used only for administrative identification. Choose a name that reflects the purpose of the record. This field has no bearing on the configuration or settings determined by this scaffold.

The Management I-SID field specifies the I-SID that will be associated with the Management VLAN for management traffic. The Management VLAN is configured per device, under the Switches scaffold.

The Manual area field specifies the IS-IS area that will be used within this fabric in the format: xx.xxxx (ex: 10.0001)

The Primary B-VLAN and Secondary B-VLAN fields indicate the VLANs which will be used for passing encapsulated traffic between participating fabric switches on switch ports designated as NNI ports. These VLANs should be unused elsewhere in your infrastructure.

Switch Ports

Entries in the Switch Ports scaffold are created automatically by enabling the Monitoring checkbox on a supported switch's Infrastructure Device. Ports are imported and speed, packet, error and discard rates are gathered via SNMP and made graphable for each switch port.

The name field represents the port's identification in the switch, and should not be changed.

The NNI Port designates this port as a Network-to-Network Interface. This option must be enabled for any port where two fabric-enabled switches interconnect.

The speed in bps field represents the port's maximum physical speed in bits per second.

Link Aggregation Groups (LAG)

Link Aggregation Groups (LAG), also known as port-channels or EtherChannels, allow multiple physical switch ports to be bundled together into a single logical interface. This provides increased bandwidth through load distribution and redundancy through automatic failover if a member link fails.

Supported Switch Types

LAG configuration management is currently supported on:

For switches that do not support LAG management through the rXg, LAG interfaces must be configured manually via the switch CLI.

LAG Types

The rXg supports two types of LAG configurations:

How LAG Ports Appear

When monitoring is enabled on a supported switch, LAG interfaces are automatically imported alongside regular switch ports. The port naming convention varies by switch vendor (e.g., on Ruckus ICX switches, LAG ports use the lg prefix such as lg1, lg2, lg3).

In the Switch Ports scaffold, LAG interfaces display:

• Name: A descriptive name for the LAG (e.g., "Uplink-LAG", "Server-Bond")
• Port: The LAG identifier (e.g., lg1 on Ruckus ICX)
• Port Type: Either "Static" or "Dynamic"
• Sub Interfaces: The member ports that belong to this LAG
• Speed: The aggregate bandwidth of all active member ports

Creating a LAG Interface

To create a new LAG interface on a supported switch (using a Ruckus ICX switch as an example):

1. Navigate to Network :: Wired :: Switch Ports
2. Click Create New to add a new switch port record
3. Select the target Infrastructure Device (must be a supported switch)
4. In the Port section:
   • Leave the Port field empty (it will be auto-assigned, e.g., lg1, lg2 on Ruckus ICX)
   • Set Port Type to either Static or Dynamic
   • Select the Sub Interfaces (member ports) to include in the LAG
5. Assign a Switch Port Profile to define VLANs and other port settings
6. Provide a descriptive Name for the LAG
7. Click Create

The following example shows LAG creation on a Ruckus ICX switch:

The rXg will automatically generate and push the appropriate LAG configuration commands to the switch during the next config sync.

Modifying a LAG Interface

To modify an existing LAG:

1. Navigate to Network :: Wired :: Switch Ports
2. Locate the LAG interface (e.g., ports starting with lg on Ruckus ICX)
3. Click Edit on the LAG record
4. Modify the desired settings:
   • Name: Change the descriptive name
   • Sub Interfaces: Add or remove member ports
   • Switch Port Profile: Change VLAN assignments or other settings
   • Shutdown: Enable to administratively disable the LAG
5. Click Update

Important Notes: - The Port Type (Static/Dynamic) cannot be changed after creation. To change the LAG type, delete the LAG and recreate it with the desired type. - A LAG must have at least 1 member port and no more than 8 member ports. - LAG interfaces cannot have RADIUS authentication enabled (802.1X or MAB). The switch port profile assigned to a LAG must have RADIUS authentication set to "None".

Deleting a LAG Interface

To delete a LAG:

1. Navigate to Network :: Wired :: Switch Ports
2. Locate the LAG interface
3. Click Delete on the LAG record
4. Confirm the deletion

When a LAG is deleted: - All member ports are released and become individual ports again - Member ports are automatically disabled to prevent network loops - The ports can then be reassigned to profiles or new LAGs as needed

LAG Configuration on the Switch

The rXg automatically generates and pushes vendor-specific LAG configuration commands to the switch. The following example shows the commands generated for a Ruckus ICX switch:

! Create a dynamic LAG with LACP
lag "Uplink-LAG" dynamic id 1
  ports ethernet 1/1/1 ethernet 1/1/2
exit

! Create a static LAG without LACP
lag "Server-Bond" static id 2
  ports ethernet 1/1/5 ethernet 1/1/6
exit

VLANs configured on the LAG's switch port profile are applied to the LAG interface, not to individual member ports.

Best Practices

1. Use Dynamic LAGs when possible: LACP provides better failure detection and prevents misconfigurations from causing loops.

2. Match configuration on both ends: Ensure the remote device (switch, server, etc.) has matching LAG configuration:

   • Same number of member ports
   • Same LAG type (static requires static, dynamic requires LACP-enabled)
   • Same VLAN configuration

3. Use consistent port speeds: All member ports in a LAG should have the same speed and duplex settings for optimal load distribution.

4. Plan LAG IDs: Different switch vendors have varying limits on LAG IDs (e.g., Ruckus ICX supports IDs from 1 to 256). The rXg auto-assigns IDs, but be aware of vendor-specific limits in large deployments.

5. Monitor LAG health: Check the Link Speed field to verify all member links are active. The aggregate speed should equal the sum of all member port speeds.

Troubleshooting LAG Issues

Switch Port Profiles

Entries in the Switch Port Profiles scaffold define the behavior of downstream wired infrastructure device ports. Switch port profiles enable an operator to manage virtually unlimited switch ports, without configuring them individually.

The name field is an arbitrary string descriptor used only for administrative identification. Choose a name that reflects the purpose of the record. This field has no bearing on the configuration or settings determined by this scaffold.

The Default checkbox, declares the selected switch port profile as the default for any newly imported switches

The Move Ports checkbox, if selected, will move ports associated with a different default profile to a profile upon save. This should be used in conjunction with the Default checkbox.

The Ports field defines individual switch ports to associate with this profile.

The Native VLAN field is used to define the untagged VLAN that ports associated to a profile should use.

The Shutdown checkbox declares ports associated to this profile to be disabled.

The VLANs field defines the VLANs that should be tagged on ports associated with a profile.

The RADIUS drop-down menu can be used to enable 802.1x or MAC Authentication Bypass, on ports associated to a profile.

The native I-SID specifies the network that untagged traffic from this port should be placed into when building a Fabric configuration script.

The NNI Port designates this port as a Network-to-Network Interface. This option must be enabled for any port where two fabric-enabled switches interconnect.

Automatic Port Match Rules

The Automatic Port Match Rules feature allows operators to define rules that automatically assign switch ports to profiles based on LLDP (Link Layer Discovery Protocol) information received from neighboring devices. This powerful automation reduces manual port configuration work by dynamically matching ports to appropriate profiles.

Overview

When a Switch Port Profile is saved with match rules configured, the system automatically evaluates all switch ports against the defined patterns. Ports that match the criteria are automatically assigned to the profile and receive its configuration. This is particularly useful for standardizing configurations for access points, uplink ports to other switches, or any other devices that can be identified via LLDP.

Configuring Match Rules

Each match rule consists of three components:

• Logic: Select OR or AND operator for combining multiple rules within the same profile
• Port Attribute to Match: Select which attribute to evaluate (LLDP information, port properties, switch properties, etc.)
• Match Pattern: Enter a regular expression (regex) pattern that will be matched against the selected attribute

LLDP Field Mapping

When matching on neighbor LLDP information, the system uses standardized LLDP field names stored in YAML format. The following table shows the mapping between switch CLI output and the internal YAML field names:

Pattern Syntax

The Match Pattern field accepts regular expressions that are matched against the YAML content of LLDP data. The basic pattern structure is:

lldpRemFieldName.*SearchText

Where: - lldpRemFieldName is the YAML key to search in - .* is a regex wildcard meaning "any characters" - SearchText is the text you want to match

Common Pattern Examples

Match Specific Text in System Description

lldpRemSysDesc.*TIP OpenWiFi

This matches any device advertising "TIP OpenWiFi" in its system description, useful for identifying OpenWiFi access points.

Match Multiple Device Models (OR Logic)

lldpRemSysDesc.*(ECS2100-10P-TIPC|ECS5550-30X|ECS4155-30P)

This matches any of three Edgecore switch models (as an example) using the | (OR) operator in the regex pattern.

Match Any Device from a Vendor

lldpRemSysDesc.*ECS

This matches any Edgecore switch (all models starting with "ECS").

Match by System Name

lldpRemSysName.*core-switch-01

This matches a specific switch by its hostname.

Match by Chassis MAC Address

lldpRemChassisId.*94:ef:97:9e:cb:b6

This matches a specific device by its chassis MAC address.

How Matching Works

The matching process follows these steps:

1. When a Switch Port Profile with match rules is saved, the system triggers automatic port matching
2. The system iterates through all switch ports and evaluates each against the match rules
3. For each port, the system retrieves the neighbor's LLDP data from the link_neighbor.lldp_yaml field
4. The regex pattern is applied against the entire YAML content
5. Match results are determined based on the logic operators:
   • OR rules: At least one rule must match
   • AND rules: All rules must match
   • Combined rules: All AND rules plus at least one OR rule must match
6. If a port matches, it is automatically assigned to the profile and receives its configuration

Preview Feature

Before saving match rules, operators can preview which ports will be affected by clicking the "Preview match rule effects" button. This shows:

• Which ports currently match the configured rules
• What changes would occur (profile assignments)
• A summary of affected ports before committing the changes

This feature helps prevent unintended mass-assignment of ports to profiles.

Available Matching Attributes

Beyond neighbor LLDP information, match rules can be created using the following attribute categories:

Switch Port Attributes: - Port Name - Port Number - Port Type - LLDP Info (local port) - Current Profile Name - Link Speed - Note

Parent Switch Attributes: - Switch Name - Switch Model - Version - MAC Address - Note

Neighbor Port Attributes: - Port Name - Port Number - Port Type - LLDP Info (neighbor port) - Most commonly used for device identification - Profile Name - Note

Parent Media Converter Attributes: - Media Converter Name - Media Converter Model - Version - MAC Address - Note

Opting Out of Automatic Matching

Individual switch ports can be excluded from automatic profile matching by setting the disable_dynamic_profile flag on the switch port. This is useful for ports that require manual configuration and should not be automatically reassigned by match rules.

Best Practices

• Use Preview First: Always preview match rules before saving to avoid unintended changes
• Be Specific: Use specific patterns to avoid matching unintended devices
• Test Incrementally: Start with one match rule and verify it works before adding more
• Document Patterns: Keep track of which patterns are used for which purposes
• Case Sensitivity: Regex patterns are case-sensitive by default; use (?i) prefix for case-insensitive matching
• Escape Special Characters: If matching literal dots, parentheses, etc., escape them with backslash: \., \(, \)

Real-World Example: OpenWiFi Access Points

Use Case: Automatically assign ports connected to TIP OpenWiFi access points to an AP profile.

Configuration: - Logic: OR - Port Attribute to Match: LLDP Info (Neighbor Port Attributes) - Match Pattern: lldpRemSysDesc.*TIP OpenWiFi

Sample LLDP Output from Access Point:

System name:                    CIG WF189H
System description:             TIP OpenWiFi
Chassis ID:                     D4:BA:BA:A4:DA:28
Port ID:                        D4:BA:BA:A4:DA:28
Port description:               eth0
Management address:             10.0.21.119

With this rule configured, any switch port that detects a neighbor advertising "TIP OpenWiFi" in its LLDP system description will automatically be assigned to this profile and receive the appropriate access point port configuration.

Real-World Example: Edgecore Switch Uplinks

Use Case: Automatically assign ports connected to Edgecore switches to an uplink profile.

Configuration: - Logic: OR - Port Attribute to Match: LLDP Info (Neighbor Port Attributes) - Match Pattern: lldpRemSysDesc.*(ECS2100-10P-TIPC|ECS5550-30X|ECS4155-30P)

Sample LLDP Output from ECS2100-10P-TIPC:

Chassis ID           : 94-EF-97-9E-CB-B6
Port ID              : 94-EF-97-9E-CB-B7
Port Description     : Ethernet Port on unit 1, port 1
System Description   : ECS2100-10P-TIPC
System Capabilities  : Bridge
Enabled Capabilities : Bridge

Sample LLDP Output from ECS5550-30X:

Chassis ID           : 94-EF-97-9E-B8-F8
Port ID              : 94-EF-97-9E-B8-FC
Port Description     : Ethernet Port on unit 1, port 4
System Description   : ECS5550-30X
System Capabilities  : Bridge, Router
Enabled Capabilities : Bridge, Router

With this rule configured, any switch port connecting to one of the specified Edgecore switch models will automatically be assigned to the uplink profile with appropriate VLAN tagging, speed settings, and other uplink-specific configurations.

DHCP Snooping

DHCP snooping is a security feature that protects against rogue DHCP servers on the network. When enabled, the switch inspects DHCP traffic and filters out unauthorized DHCP server responses, preventing malicious or misconfigured devices from handing out incorrect IP addresses to clients.

How DHCP Snooping Works

DHCP snooping classifies switch ports into two categories:

When a device connects to an untrusted port and sends a DHCP DISCOVER, the request passes through normally. However, if a rogue DHCP server on an untrusted port attempts to send an OFFER or ACK response, the switch drops those packets, preventing the rogue server from assigning IP addresses.

Configuration Components

DHCP snooping requires two configuration elements:

1. Trusted DHCP VLANs (Switch-level Setting)

The Trusted DHCP VLANs field on the Switch configuration specifies which VLANs should have DHCP snooping inspection enabled. Only traffic on these VLANs will be inspected; other VLANs are unaffected.

Note: VLAN 1 is automatically included when DHCP snooping is enabled, even if not explicitly configured. This ensures that daisy-chained switches can obtain their initial IP address during the onboarding/bootstrap process.

Common configurations include: - Management VLAN (e.g., VLAN 100): Target management VLAN for switches and access points - Additional VLANs where DHCP protection is desired

2. DHCP Snooping Trust (Switch Port Profile Setting)

The DHCP snooping trust checkbox on a Switch Port Profile marks ports as trusted, allowing both client and server DHCP traffic through. This setting should only be enabled on ports that face toward your legitimate DHCP server.

Which Ports Should Be Trusted?

The key principle is: only trust ports in the path toward your legitimate DHCP server.

Single Switch Deployment

Daisy-Chained Switch Deployment

In a daisy-chain topology, each switch must trust its uplink port (the port facing toward the DHCP server):

[DHCP Server/rXg]  [Switch 1]  [Switch 2]  [Switch 3]

                     Uplink       Uplink       Uplink
                    (trusted)    (trusted)    (trusted)

*Note: For simplified management, switch interconnect ports can be trusted on both sides. This is acceptable when physical access to interconnect ports is controlled, as the primary threat (rogue DHCP servers on customer ports) remains blocked.

Best Practices

1. Minimize trusted ports: Only trust ports that are in the direct path to your DHCP server
2. Protect all client-facing VLANs: Include both onboarding and production VLANs in the trusted DHCP VLANs list
3. WAP trunk ports should remain untrusted: Access points bridge client traffic but should not originate DHCP responses
4. Use a common "Trunk/Interconnect" profile: For simplified management in daisy-chain deployments, create a single profile with DHCP snooping trust enabled for all switch-to-switch links
5. Physical security matters: Since trusted interconnect ports bypass rogue server protection, ensure physical access to switch interconnects is controlled

Example Configuration

Scenario: A network with rXg providing DHCP, using VLAN 1 for onboarding and VLAN 100 for management.

Switch Settings: - Trusted DHCP VLANs: 100 (VLAN 1 is automatically included)

Switch Port Profiles:

Vendor-Specific Switch Configurations

• Adtran (DPU/ASE)
• Cambium cnMatrix
• Cisco IOS
• Cisco Catalyst IOS-XE
• Dell
• D-Link DGS
• Edgecore
• Extreme (ERS/VSP/EXOS)
• FS
• HP
• Juniper EX
• Meraki MS
• MikroTik RouterOS
• Nokia (PON/MF)
• Positron
• Ruckus ICX
• TP-Link