Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
AAA stands for Authentication, Authorization and Accounting. These protocols were defined by the Internet Engineering Task Force and are intended to provide an Authentication, Authorization, and Accounting (AAA) framework for applications, such as network access or IP mobility in both local and roaming situations.
TACACS uses (either TCP or UDP) port 49 by default. TACACS allows a client to accept a username and password and send a query to a TACACS authentication server, sometimes called a TACACS daemon or simply TACACSD. It would determine whether to accept or deny the authentication request and send a response back. In this way, the process of making the decision is "opened up" and the algorithms and data used to make the decision are under the complete control of the TACACS daemon.
RADIUS, which stands for Remote Authentication Dial-In User Service, is a network protocol commonly used for centralized authentication, authorization, and accounting (AAA) management. Similar to TACACS, RADIUS is designed to allow clients to authenticate and request services from a centralized server, referred to as a RADIUS server or RADIUS daemon.
This CLI Configuration Guide is designed to provide you with instructions and guidance on configuring and managing the Open Packet Broker using the command line interface.
To explore specific topics and access more detailed information, please use the left side column as a navigation tool in the guide. By selecting a particular section from the left side column, you will be able to delve deeper into that specific topic.
VLAN modes in OPB provide administrators to match flow based on the VLAN tag in the packet and redirect to the tool ports
OPB supports two VLAN modes;
VLAN-aware mode will match traffic based on both configured ingress-VLAN and VLAN configured in flow rules
VLAN-unaware mode will allow all VLAN traffic and does not follow the ingress-VLAN configuration
By default, the port is in VLAN-aware mode and will accept traffic tagged with VLAN 'n+2', where 'n' is the port number i.e. Eth2+2 = VLAN 4
Command
mode vlan-aware
mode vlan-unaware
Description
vlan-aware: used for matching packets based on VLAN id
Parameters
None
Mode
INTERFACE
This feature is only supported on the NVIDIA platforms and is applicable only for network ports.
You can verify the configuration by using the command(s) below:
You can configure the username based on the role(RBAC) using the below command:
Command
[no] username <user_name> password <user_password> role [network-operator/network-admin]
Description
username configuration
Parameters
username
Mode
CONFIG
You can verify the configuration by using the command(s) below:
FlowVision offers a user-friendly graphical interface (GUI) that allows users to configure and monitor the OPBNOS switch.
By enabling the on-box FlowVision feature on the switch, users can access the GUI through the management IP. This enables them to efficiently manage, monitor, and configure the OPBNOS using the intuitive GUI.
The GUI of FlowVision utilizes TCP port 443 & GUI will be reachable at https://<MGMT-IP>/
Users can follow the FlowVision GUI Guide to manage the device using GUI.
This feature is specific to individual switches and cannot be used to manage multiple switches
Enabling On-Box FlowVision will prevent the Switch from being added to a remote FlowVision Controller.
More information is available here.
Command
[no] flowvision enable
Description
enable/disable the flowvision tool
Parameters
NONE
Mode
CONFIG
You can configure the TACACS server using the following command:
You can verify the configuration by using the command(s) below:
To Configure Global TACACS parameters, use the below command:
You can verify the configuration by using the command(s) below:
Timestamping packets is crucial in networking, Accurately recording time references for packets as they travel through the network. This technology aids in performance monitoring, latency analysis, network troubleshooting, and system synchronization. Precise timestamps help pinpoint delays, identify network bottlenecks, optimize routing, and ensure adherence to service-level agreements.
Timestamps are also crucial for coordinating distributed systems by maintaining a consistent time reference across geographically dispersed components. To do this, Specialized hardware or software captures and records these timestamps. Protocols like Precision Time Protocol (PTP) or Network Time Protocol (NTP), facilitate high-precision synchronization.
Timestamping feature is needed for below major use-cases:
Detecting the congestion point on the path of a flow
Path Tracing
Real-time performance monitoring
Arrival sequence validation
This feature is only supported on Broadcom TD3 platforms, specifically EC7326, and EC7726.
You can configure the Timestamping glo using the following command:
To Configure Timestamping per interface, use the below command:
Command
[no] tacacs-server host <ipv4 | ipv6> [timeout<value> ] [key <value> ] [auth_type (chap |
pap | mschap | login) ] [port <value>] [priority <value> ]
Description
TACACS configuration
Parameters
IPv4 or v6 Address , timeout, key, auth_type, port, priority values
Mode
CONFIG
Command
[no] tacacs [authtype (chap | pap | mschap | login)] [passkey <value>] [timeout <value>]
Description
TACACS global configuration
Parameters
Timeout, key, auth_type, passkey values
Mode
CONFIG
Command
[no] timestamping [enable ]
Description
OPB Packet Timestamping
Parameters
enable or disable
Mode
CONFIG
Command
[no] timestamp {enable} stage {ingress | egress} source-id <23-bit value>
Description
Timestamp configuration
Parameters
enable/disable, stage, source-id
Mode
INTERFACE
When using fail-through, if the primary TACACS server fails to respond within a specified timeout period, the authentication request is automatically forwarded to the next authentication method configured, such as a local database or a different authentication server.
If we disable fail-through, the system fails to authenticate with a reachable TACACS+ server the system does not attempt to authenticate with the next TACACS+ server.
The fallback is mainly intended to provide an alternative way to authenticate users when there’s an issue with the primary authentication server or method, not to give users multiple attempts to authenticate with different methods.
Fallback operates at the AAA (Authentication, Authorization, and Accounting) level, allowing the network device or system to switch to the secondary TACACS server when the primary server is not available.
In summary, failthrough refers to the process of falling back to an alternative authentication method if the primary TACACS server fails to respond, while fallback involves switching to a backup TACACS server when the primary server is unavailable for AAA services.
You can configure the Authentication, Authorization and Accounting (AAA) using the following command:
Command
[no] aaa authentication (failthrough disable | fallback disable |login tacacs)
Description
AAA configuration
Parameters
None
Mode
CONFIG
You can verify the configuration by using the command(s) below:
You can set the hostname using the below command:
save config after changing hostname using 'save' command
The Management Interface is an external port (non-ASIC) on the switch that allows you to perform switch management tasks. It is a layer 3 interface and it cannot be configured as a layer 2 interface. The management interface cannot forward traffic.
To configure the management interface, use the following command:
When you run the aforementioned command, the system enters the Interface Configuration Mode for the management port. By default, the management interface is created by the switch and it cannot be removed.
Example
You can verify the configuration by using the command(s) below:
Physical Interfaces are switch front panel ethernet ports which are ASIC ports. The physical ports are created by default and cannot be deleted.
To change or update the physical port configuration, use the following command:
When you run the aforementioned command, the system enters the Interface Configuration mode for the specified physical port.
To change the physical port Admin status, use the following command:
You can verify the configuration by using the command(s) below:
Link Layer Discovery Protocol (LLDP) is an IEEE 802.1AB-2009 that defines messages, encapsulated in Ethernet frames for the purpose of giving devices a means of announcing basic device information to other devices on the LAN (Local Area Network) through periodic retransmissions out each port every 30 seconds by default.
This implementation of LLDP is compatible with the IEEE 802.1AB-2005 standard. LLDP uses Layer 2 (the data link layer), and allows network management applications to extend their awareness of the network by discovering devices that are direct neighbors of already known devices.
With LLDP, the switch can advertise the presence of its ports, their major capabilities, and their current status to adjacent LLDP neighbours. LLDP transmissions occur on ports at regular intervals or whenever there is a relevant change to their status. The switch can also receive LLDP information advertised from adjacent LLDP-capable network devices.
The following topics provide more information on configuring LLDP:
Command
[no] shutdown
Description
Administratively enable or disable interface
Parameters
None
Mode
INTERFACE
Command
show lldp neighbors
Description
Display LLDP neighbors
Parameters
None
Mode
EXEC
Command
show lldp neighbors detail
Description
Display LLDP neighbors in detail
Parameters
None
Mode
EXEC
Command
lldp { disabled | rx-and-tx | rx-only | tx-only }
Description
Enable/Disable LLDP receive and transmit
Parameters
disabled Disable LLDP
rx-and-tx Enable Rx and Tx
rx-only Enable Rx-Only
tx-only Enable Tx-Only
Mode
INTERFACE
When the OPBNOS boots UP, it prompts the user for a License key that can be requested by contacting Aviz Support. More information on Licensing can be found here.
Verify the currently installed license:
Use the 'License' command to change the license(if required):
The license can be upgraded without requiring a reinstallation or reset.
Maximum transmission unit (MTU) defines the largest size of the packet that can be transmitted as a single entity through the port. The size of the MTU dictates the amount of data that can be transmitted in bytes over a network.
Command
mtu <mtu val>
Description
Configure MTU in bytes
Parameters
Mtu value (MAX: 9100)
Mode
INTERFACE
Example
You can verify the configuration by using the command(s) below:
RADIUS is commonly used in enterprise and service provider networks to authenticate and authorize users before granting them access to network services.
In SONiC NOS, RADIUS is supported to achieve a crucial role in securing and managing network access by providing a centralized authentication, authorization, and accounting framework. SONiC switch performs a Client - network access server (NAS) role.
RADIUS is not supported on these platforms: EdgeCore AS5812 & EdgeCore AS7712
Command
[no] radius [auth-type <<chap|pap|mschapv2> default pap>] [nasip ] [key ] [source-ip ] [retransmit ] [timeout ]
Description
Configure RADIUS
Parameters
auth-type, nasip, key, source-ip, retransmit, timeout
Mode
CONFIG
You can verify the configuration by using the command(s) below:
Command
[no] radius-server host key [auth-type <chap|pap|mschapv2> default pap] [auth-port <range[1:65535] default 1812>] [priority <integer default 1>] source-intf [retransmit ] [timeout ]
Description
Configure RADIUS
Parameters
auth-type, auth-port, priority,source-interface, retransmit, timeout
Mode
CONFIG
You can verify the configuration by using the command(s) below:
Autonegotiation is a signalling mechanism in which two devices connected over Ethernet can choose common transmission parameters such as speed, duplex, mode and flow control.
In this process, the connected device first shares its capabilities regarding these parameters and then chooses the highest performance mode that both support.
You can verify the configuration by using the command(s) below:
Command
[no] autoneg disable
Description
Enable/disable auto negotiation
Parameters
None
Mode
INTERFACE
Command
description <string>
no description
Description
Description configuration
Parameters
string - 50 characters maximum
Mode
INTERFACE
You can configure the interface type based on the connection point. Here, “network” corresponds to the network (TAPs) and “tool” corresponds to analytics tools.
Command
type (network | tool)
no type
Description
Type Configuration
Parameters
None
Mode
INTERFACE
You can verify the configuration by using the command(s) below:
Forward error correction (FEC) is an error correction technique to detect and correct a limited number of errors in transmitted data without the need for retransmission.
In this method, the sender sends a redundant error-correcting code along with the data frame. The receiver performs necessary checks based on the additional redundant bits. If it finds that the data is free from errors, it executes the error-correcting code that generates the actual frame. It then removes the redundant bits before passing the message to the upper layers.
Command
forward-error-correction {rs | fs | none}
Description
Configure forward error correction method
Parameters
None
Mode
INTERFACE
Example
You can verify the configuration by using the command(s) below:
The Port Breakout feature allows high-speed ports to be split into multiple lower-speed ports on supported platforms through interface configuration. This enables flexibility in network deployments by adapting port speeds to specific requirements.
Supported Platforms for Port Breakout:
EC7816
EC7726
EC7326
SN4600C
For example, a 100G port can be split into:
4x 25G ports
2x 50G ports
4x 10G ports (if supported)
To view the current breakout mode for an interface, use:
Before changing the breakout configuration, check the supported breakout modes using:
From the above output, the platform supports four breakout modes for Ethernet49/1:
1x100G
2x50G
4x25G
4x10G
Ensure there are no interface-dependent configurations before applying a breakout change.
A system reboot is required after configuring port breakout.
To change the breakout mode to 4x25G, use the following command:
After the system reboots, verify the new breakout configuration using:
Now if we want to change breakout mode from "4x25G" to "2x50G" then we can do it using below commands
Loopback-mode means that a physical port can become network-port (ingress) and tool-port(egress) to which flow rules can be applied. A loopback-mode port is operated in loopback mode and avoids customers connecting a physical cable to make it operate in Loopback mode.
As soon as a port is configured as a loopback-mode port, it is internally changed to a loopback mode state. This means that the link is UP with or without cables being inserted. Traffic flows out of a loopback-mode port (Tx direction) and loops back to it (Rx direction).
loopback-mode ports can provide the following flexibility:
Support for multiple lookups on the same packet. For example, decapsulate the tunnel and look up based on the inner header.
Multiple egress actions on the same traffic. For example (shown here) send to tool as-is and add VLAN tag.
The following command is used to configure the interface to work as both network-port and tool-port. When enabled on an interface, it acts like a mac loopback which loops back the egress packets back to the device on the same port.
Command
loopback-mode no loopback-mode
Description
Activation loopback mode
Parameters
None
Mode
INTERFACE
You can verify the configuration by using the command(s) below:
You can use packet truncation, which is a unique capability available only on NVIDIA platforms, to truncate the packets which are sent to the tool. This helps tools reduce the storage capacity needed for saving packets for future analysis. It truncates the packet for the given offset.
This feature is only supported on the NVIDIA platforms
The packet will be truncated beginning at the Ethernet header
Command
truncate <offset value>
no truncate
Description
Truncate packets after offset
Parameters
Offset-value – multiple of 4 within 48 to 4088
Mode
INTERFACE
You can verify the configuration by using the command(s) below:
Command
speed {1000 | 10000 | 25000 | 40000 | 100000}
Description
Configure speed in Mbps
Parameters
1000 1G
10000 10G
25000 25G
40000 40G
100000 100G
Mode
INTERFACE
Command
{no} egress-tagging enable
Description
Egress-tagging configuration
Parameters
None
Mode
INTERFACE
LAG-Hash is used to describe the load-balancing algorithm used for distributing traffic across the links within a port channel. This algorithm plays a crucial role in determining the distribution of traffic evenly among the member links of the port channel.
OPBNOS uses the CRC2 for NVIDIA ASIC and CRC32_LO for Broadcom ASIC for load-balancing traffic across a port channel.
Command
lag-hash seed <int seed_value>
Description
seed value 0 - 4294967295
Parameters
integer seed value
Mode
CONFIG
You can verify the configuration by using the command(s) below:
You can use the port-channel command to create groups of tool ports and provide traffic load-balancing. By default, symmetric hashing is enabled for IPv4 and IPv6 traffic, redirecting the source-destination pair to the same tool-connected port.
Command
port-channel <channelid>ports<portname>[description<string>] no port-channel <channelid>ports
Description
Port-channel configuration
Parameters
channelid - within 1 to 16 portname - valid interface names delimited by (,) string - a maximum of 50 characters, within double quotes
Mode
CONFIG
PortChannel can only be configured as a Tool port in a flow
You can verify the configuration by using the command(s) below:
You can use the Ingress VLAN functionality to assign dedicated identification tags (VLAN Tags) and thereby creating a mapping between the network port and tool ports. Traffic received on network ports can be added with an additional VLAN tag and sent towards the tools for identifying the Network Port. Ingress VLAN is configured in the interface configuration of the network port.
Command
[no] ingress-vlan <value>
Description
Ingress-vlan configuration
Parameters
value within 500 to 4094
Mode
INTERFACE
This feature should only be configured on Network ports
You can verify the configuration by using the command(s) below:
You can use the Tx-only functionality to have only a Transmit link on the tool ports
This feature is only supported on Broadcom platforms
Command
{no} transmit-only
Description
Tx-only configuration
Parameters
None
Mode
INTERFACE
You can verify the configuration by using the command(s) below:
You can use the Rx-only functionality to have only a Receive link on the network ports for BiDi SFPs
This feature is only supported on Edgecore AS7816-64X
Command
{no} receive-only
Description
rx-only configuration
Parameters
None
Mode
INTERFACE
You can verify the configuration by using the command(s) below:
This section provides information about configuring flows and rules.
Broadcom ASIC
NVIDIA ASIC
You can specify the destination(s) for packets matching the flow. The supported destinations are as follows:
port-id(s): matching traffic redirected to one or more tool ports
port-channel: matching traffic redirected to multiple tool ports with symmetric load balancing
You can verify the configuration by using the command(s) below:
User Defined Filtering can be considered an inspection of a packet based on offset values. An ACL can be defined with UDF matching capabilities to give granularity and flexibility when identifying traffic patterns. It is often used for deeper packet analysis. Typical use cases include finding patterns inside the inner header when packets are tunnelled.
Using UDF, users can configure a rule to match specific bytes in the ingress packet based on a given offset to permit or deny matched packets
Offset for the L3 packet starts from the IP header in the packet
offset for the L2 packet starts from EtherType in the packet
Note: The maximum length that can be matched is 40 characters (i.e. 20 bytes), and the minimum is 4 characters (i.e. 2 bytes), excluding the "0x" prefix. The character string must be an even number of characters.
Before configuring flow rules, Network and Tool ports must be configured
This feature is supported only on NVIDIA spectrum-2/3 platforms
UDF and GTP can not be configured together on a device
You can verify the configuration by using the command(s) below:
Command
rule <ruleid> [ipv6] (deny | permit ) [description <cstring>] ([ethertype <etype>] [vlan <vid>] [src-ip (<ipv4> | <ipv6 > src-netmask <ipv6 >)] [dest-ip (<ipv4> | <ipv6 > dest-netmask <ipv6 >)] [protocol (tcp | udp | <ptype >)] [l4portsrc <sport>] [l4portdst <dport>] [tosval <sval >] [dscp <dval>] [ttl <tval>] [tcpctl <flags > tcpctlmask <tcpmask >] | match_all [ipv6]) [counters (enable | disable)]
no rule <ruleid>
Description
Rule configuration
Parameters
ruleid: It should be in the range 1 to 6000
ipv6: used to specify an ipv6 rule
description: max 50 characters
ethertype: hexadecimal value prefix with 0x. max 4 characters.
vlan: VLAN id 2 to 4094
src-ip: source IP address
dest-ip: Destination IP address
protocol: L3 Protocol
l4portsrc: L4 source port for TCP or UDP
l4portdst: L4 source port for TCP or UDP
tossval: Type of Service
dscp: Differentiated services code point.
ttl: Time-to-live
tcpctl: TCP control flags
Mode
FLOW
Command
rule <ruleid> (deny | permit ) [description <cstring>] ([ethertype <etype>] [vlan <vid>] [src-ip (<ipv4> | <ipv6 > src-netmask <ipv6 >)] [dest-ip (<ipv4> | <ipv6 > dest-netmask <ipv6 >)] [protocol (tcp | udp | <ptype >)] [l4portsrc <sport>] [l4portdst <dport>] [tosval <sval >] [dscp <dval>] [ttl <tval>] [tcpctl <flags > tcpctlmask <tcpmask >] | match_all [ipv6]) [counters (enable | disable)]
no rule <ruleid>
Description
Rule configuration
Parameters
ruleid: It should be in the range 1 to 6000
description: max 50 characters
ethertype: hexadecimal value prefix with 0x. max 4 characters.
vlan: VLAN id 2 to 4094
src-ip: source IP address
dest-ip: Destination IP address
protocol: L3 Protocol
l4portsrc: L4 source port for TCP or UDP
l4portdst: L4 source port for TCP or UDP
tossval: Type of Service
dscp: Differentiated services code point.
ttl: Time-to-live
tcpctl: TCP control flags
Mode
FLOW
Command
description <string>
Description
Description configuration
Parameters
string—maximum 50 characters, within double quotes.
Interface
FLOW
Command
network-ports <network-ports>
Description
Configure network or TAP ports
Parameters
network-ports—valid interfaces, delimited by (,)
Mode
FLOW
Command
tool-ports <tool-ports>
Description
Configure network tool or analyzer ports
Parameters
tool-ports—valid interfaces, delimited by (,)
Mode
FLOW
Command
rule <rule-id> ((deny | permit) [description ] [udf-data udf-extraction-group (l2 | l3 [udf-extraction-point ]) udf-offset ] [counters (enable | disable )]
no rule <ruleid>
Description
Rule configuration
Parameters
ruleid: It should be in the range 1 to 6000
description: max 50 characters
udf-data: data bytes that need to be matched with the incoming packet
udf-extraction-group:
l2 - match from l2 header ethertype field
l3 - match from start of IPV4 or IPV6 header
udf-extraction point: (applies for only l3 extraction point) set extraction point from start of IPV4 or IPV6 header
udf-offset: offset from which bytes will be monitored from extraction point
counters: can be enabled or disabled
Mode
FLOW
Using this command, users can configure a rule using an expression string for both inner and outer headers in encapsulated packets.
Before configuring flow rules, Network and Tool ports must be configured
This feature is supported only on NVIDIA spectrum-2/3 platforms
Command
rule ((deny | permit) [description ] [match-expression ] [counters (enable | disable )]
no rule <ruleid>
Description
Rule configuration
Parameters
ruleid: It should be in the range 1 to 6000
description: max 50 characters. match
expression: qualifiers can be added to this string
counters: can be enabled or disabled
Mode
FLOW
Expression qualifiers -
ethertype - L2 Ethertype, vlan - Vlan header value, src-ip - Source IP prefix, src-netmask - Source IP mask, dest-ip- Destination IP prefix, dest-netmask- Destination IP mask, protocol - Protocol type, l4portsrc- Transport layer source port, l4portdst - Transport layer destination port, tosval - Type of Service value, dscp - Differentiated services field value, ttl - Packet TTL, tcpctl - TCP control value, tcpctlmask - TCP control mask, teid - Encapsulation tunnel ID, inner-sip - Inner IP Source Address, inner-dip - Inner IP Destination Address, inner-protocol - Inner Header Protocol, inner_l4srcport - Inner Header UDP Source Port, inner_l4destport - Inner Header UDP Destination Port
You can verify the configuration by using the command(s) below:
Use the following command to check the rate of data flowing through a flow:
Command
show flow (all | <flow-name> ) rate
Description
Display flow rate for a flow
Parameters
flow-name - max 20 characters
Mode
EXEC
You can display the flow configuration and operational status as follows:
Command
show flow (all | <flow-name> rule <rule-id> )
Description
Displays all the flow configurations and rule configurations
Parameters
flow-name—max 20 characters
rule-id – within 1 to 6000
Mode
EXEC
Use the following command to show the flow summary:
Command
show flow summary
Description
Displays the summary of all OPB flows
Parameters
None
Mode
EXEC
Use the following command to display the counters of all the flows:
Command
show flow counters (all |<flow-name> )
Description
Displays the counters of all the OPB flows
Parameters
flow-name – max 20 characters
Mode
EXEC
You can configure flows with rules to replicate and filter traffic between the network and tool ports.
Flow can be used to create a traffic stream between the network port and tool port, The traffic can be filtered by configuring rule(s) to permit/deny matching traffic.
Command
[no] flow <flow-name>
Description
Create/Delete Flow
Parameters
Flow-name—maximum of 10 characters
Interface
CONFIG
You can configure a rule to override the configured flow action for egress ports to push and/or pop VLAN. You can also override tool port(s) for egress traffic.
override-action is per-rule and will require override-action for every rule in the flow
Command
rule 1 action
override-pop-vlan Override action to pop the VLAN override-push-vlan-tag Override action to push VLAN Tag override-to Override to configure a rule specific network tool or analyzer ports
Description
Rule actions
Parameters
● ruleid: It should be in the range 1 to 6000 ● override-to: override egress ports ● override-push-vlan: override MAP push VLAN ● override-pop-vlan: override pop VLAN
Mode
FLOW
You can verify the configuration by using the command(s) below:
VLAN aware mode provides OPB administrators with the ability to match and modify packets in the flow before forwarding them to the tool port(s).
You can configure the OPBNOS to modify the flow as below:
Push VLAN - Push a new VLAN Tag onto the egress traffic.
Pop VLAN - Pop(remove) the VLAN Tag from the egress traffic.
This feature is only supported on the NVIDIA platforms
Command
push-vlan-tag <vid>
Description
push VLAN to traffic matching the rules configured in the map
Parameters
vlanid—within 1 to 4094
Mode
flow
You can verify the configuration by using the command(s) below:
Command
pop-vlan
Description
pop Vlan Tag from ingress packets received
Parameters
disable/enable
Mode
flow
You can verify the configuration by using the command(s) below:
Command
gtp no gtp
Description
Global GTP Parsing
Parameters
None
Mode
EXEC
Using the following commands, you can configure a rule with GTP packet qualifiers to monitor the packets.
Before configuring rules, network and tool ports must be configured.
GTP must be enabled in config mode.
GTP and UDF can not be configured together on a device
Command
rule <ruleid> ( permit ) [description <cstring>] [gtp <gtpexpression> ] [counters (enable | disable)]
no rule <ruleid>
Description
Rule Configuration
Parameters
ruleid: It should be in the range 1 to 6000 description: max 50 characters.
gtp Example qualifiers: teid - Tunnel ID, match-all-ipv4 - Match all inner IPv4, match-all-ipv6 - Match all inner IPv6 ,inner-sip - Inner IP Source Address, inner-dip - Inner IP Destination Address, inner-protocol - Inner Header Protocol, inner_l4srcport - Inner Header UDP Source Port, inner_l4destport - Inner Header UDP Destination Port
Mode
FLOW
To verify flow, use the following command:
Configure this feature to strip all incoming IPv4/IPv6 VxLAN traffic.
This feature is supported only on NVIDIA spectrum-2/3 platforms
The source-IP in tunnel configuration & dest-IP in flow rule configuration should be the same for VxLAN stripping to work.
The dest-mac in the flow rule configuration should be the system-mac of the switch, this can be retrieved using the "show platform syseeprom" command.
The strip-vxlan interface in the tunnel configuration should be a configured as logical loopback.
A physical loopback is required between egress-interface from the tunnel and the tool port as Egress interface for Inner Tagged Vlan.
Use the below command to configure the flow to swap the MAC & the IP address of incoming traffic:
Command
flow <name>
network-ports <port>
tool-ports <tunnel>
rule <to wap IP & MAC>
Description
Add flow
Parameters
description Configure description for flow enable Enable the flow
end Exit to Exec Prompt
exit Exit from the Current Prompt network-ports Configure network or TAP ports
no no form
rule Configure rule
tool-ports Configure network tool or analyzer ports
Mode
FLOW
A Physical loop is required from the tunnel1-egress_interface (Ethernet41/1) to Tool port to (Ethernet42/1) egress interface for Tagged inner Vlan .
Command
tunnel <tunnelname> no tunnel <tunnelname>
Description
Create tunnel
Parameters
Tunnelname
Mode
CONFIG
Use the below command to configure the tunnel attributes:
Tunnel attributes cannot be modified directly. To make changes, delete the existing tunnel and configure a new one.
Command
[no] tunnel <tunnel-name>
Description
Create tunnel
Parameters
comment: Configure comment for tunnel
decap-vxlan: Enable Tunnel to decap VXLAN packet destined to the device
destination-ip: Destination IP address
gateway: Gateway IPv4 Address
ingress-interface: Configure tunnel port
source-ip: Source IP address
source-port: Tunnel Source Port
strip-vxlan: Enable Tunnel to STRIP all the incoming VXLAN packet
vlan-tagging: Tunnel VLAN Tagging
vni: VXLAN network identifier
Mode
TUNNEL
Use the below command to configure the flow to egress the stripped traffic
Command
flow <name>
network-ports <port>
tool-ports <port>
rule 1 permit match all
rule 2 permit match-all ipv6
Description
Add flow
Parameters
description Configure description for flow enable Enable the flow
end Exit to Exec Prompt
exit Exit from the Current Prompt network-ports Configure network or TAP ports
no no form
rule Configure rule
tool-ports Configure network tool or analyzer ports
Mode
FLOW
You can display the Vxlan tunnel configurations using this command.
Command
vxlan ("VxLAN Tunnel") tunnel ("Tunnel Information") (all ("Displays all VXLAN Tunnel configuration") | ("Displays specific VXLAN Tunnel configuration") <tunnelid:string length[10]> ("Tunnel Name")),
Description
Displays VXLAN tunnel
Simple Network Management Protocol (SNMP) is an Internet Standard protocol for collecting and organizing information about managed devices on IP networks and for modifying that information to change device behaviour.
SNMP is widely used in network management for network monitoring. SNMP exposes management data in the form of variables on the managed systems organized in a Management Information Base (MIB) which describes the system status and configuration. These variables can then be remotely queried (and, in some circumstances, manipulated) by managing applications.
Modification to the Tunnel config or Tunnel-related Flow is not supported. However, you can delete the existing configuration and create a new one as needed.
Flow with Tunnel interface cannot have an 'override-to' action in the rule configuration
Configure Tunnel Flow only after the VxLAN tunnel is operationally 'UP' in the "show vxlan tunnel all/<tunnel-id>" output
Only 1 rule can be configured in tunnel-related flow
The current release doesn't support VxLAN tunnel over a LAG interface
For remote VxLAN-VTEP(Different subnet), the below order has to be followed for configuration
Command
tunnel <tunnelname> no tunnel <tunnelname>
Description
Create tunnel
Parameters
Tunnelname
Mode
CONFIG
Using this command, you can configure the attributes of the tunnel. Gateway is provisioned only when the nodes are not directly connected
Note: Updation of the tunnel is not supported. The tunnel must be deleted and re-configured for any change
Command
[no] tunnel <tunnel-name>
Description
Create tunnel
Parameters
interface: Configure tunnel ports
source-ip : Source IP address destination-ip : Destination IP address
gateway : Gateway IPv4 Address
vni : VXLAN network identifier[ range: 4096 - 16777215]
source-port : Tunnel Source Port vlan-tagging : Tunnel VLAN Tagging
Mode
TUNNEL
Flow based Encap Configuration
You can set the rules for the VxLAN Encap using flow. Here the tool port must be the tunnel name created using tunnel config command.
Command
flow flowname
network-ports Ethernet4/1
tool-ports tunnel1
rule 1 permit match all
Description
Add flow
Parameters
description Configure description for flow enable Enable the flow
end Exit to Exec Prompt
exit Exit from the Current Prompt from Configure network or TAP ports
no no form
rule Configure rule
to Configure network tool or analyzer ports
Mode
FLOW
You can set the rules for the VxLAN Decap using flow.. Here the Network port must be the tunnel name created using tunnel config command.
Command
flow flowname
network-ports tunnel1
tool-ports Ethernet10/1
rule 1 permit match all
Description
Add flow
Parameters
description Configure description for flow enable Enable the flow
end Exit to Exec Prompt
exit Exit from the Current Prompt from Configure network or TAP ports
no no form
rule Configure rule
to Configure network tool or analyzer ports
Mode
FLOW
You can display the Vxlan tunnel configurations using this command.
Command
vxlan ("VxLAN Tunnel") tunnel ("Tunnel Information") (all ("Displays all VXLAN Tunnel configuration") | ("Displays specific VXLAN Tunnel configuration") <tunnelid:string length[10]> ("Tunnel Name")),
Description
Displays VXLAN tunnel
Traps are used when the Device needs to alert the Network Management software of an event without being polled. Traps ensure that the NMS gets information if a certain event occurs on the device that needs to be recorded without being polled by the NMS first. Managed network devices will have Trap MIBs with predefined conditions built into them. It’s crucial that the Network management system has these MIBs compiled into them to receive any traps sent by the given device/s. The primary focus of this feature is to support SNMP Trap notifications and in particular, linkUp, linkDown and config change trap notifications.
With these MIBs, you can trigger sending an SNMP trap to a configured SNMP-server host based on certain events. Also, GET/GETNext/WALK operations can be supported on these mibs. The linkUp and linkDown traps are sent to the configured host in the event that an interface Admin or Oper status changes from up to down or vice-versa. The configChange trap monitors NPB (MAP, rule, port-npb config) and port (Speed, MTU, FEC, Autoneg) configuration changes. A configChangeTrap PDU is sent to the host when any value in these tables are modified, added or removed.
It's recommended not to set up more than 4 SNMP-Trap servers.
Command
[no] snmp-server trap modify <version><ip4addr|ip6addr> [port <value>] [community
<value>]
Description
SNMP trap configuration
Parameters
Version, IPv4 or v6 Address , port, community values
Mode
CONFIG
You can verify the configuration by using the command(s) below:
Traps are only supported on SNMPv2c
Below commands can be used to disable FAN/PSU traps temporarily,
Command
snmp-server trap (psu-util/fan-util) disable
Description
disable PSU/FAN traps temperoraly
Parameters
FAN/PSU
Mode
EXEC
By default, traps are generated every 60 seconds, which may cause unnecessary stress on memory and CPU. To mitigate this, disabling the default behaviour using the above command is recommended for disabling PSU and FAN traps.
This will result in traps being generated only when the PSU/FAN state changes, reducing the load on memory and CPU.
Before sending the VXLAN encapsulated packets to the OPBNOS switch, the peer node can check the IPv6 reachability to the switch using the ping command. Here, we can configure multiple vlan and SVI configurations with multiple IPv6 to each vlan. Each IPv6 would be reachable(ping check) from the peer node. It ensures proper handling of VXLAN and ICMP packets through flow-based rules.
This feature is supported only on the Nvidia platforms
1. Create VLAN
2. SVI Configuration (Configure IPv6 to Switched Virtual Interface with VLAN)
3. VLAN Membership (Static)
4. VXLAN Encapsulation and Packet Handling
When the peer device checks for OPBNOS reachability, certain types of packets, including ARP, ICMP, and ICMPv6, need to be processed along with the VXLAN packet that needs to be forwarded. But to achieve this PING related packets are lifted to the CPU.
There are two types of traffic discussed:
ICMP/ICMPv6 Traffic for Reachability: The CPU should always process this traffic.
VXLAN Data Traffic from the Peer: This traffic should always be handled in the data path or hardware.
However, when a flow is configured to match all IP traffic, ICMP/ICMPv6 packets are also matched and forwarded to tool ports, which causes the ping to fail. To address this, we added a flow provision to send only ICMP/ICMPv6 packets to the CPU for ping handling, while the rest of the data traffic is handled and forwarded by the hardware.
If the vxlan packet is not destined to OPBNOS, add another rule and set dest-mac from the tunnel Source MAC
EtherType and Protocol Numbers to Distinguish ARP, ICMP, and ICMPv6:
ARP: EtherType 0x0806
IPv4 Ping (ICMP): Protocol Number 1
IPv6 Ping (ICMPv6): Protocol Number 58
1. Configure IPv6 on interfaces(not associated with VLAN)
2. Ping to the IPv6 address configured on the OPBNOS switch
Ping is an administration utility used to test the connectivity between two network IP devices.
Ping functions by sending an Internet Control Message Protocol (ICMP) echo request to the specified remote host and waiting for an ICMP reply from that host. Using this method, ping also determines the time interval between when the echo request is sent and when the echo reply is received. This interval is called round-trip time.
At the end of the test, ping displays the minimum, maximum, and average round-trip times, and the standard deviation of the mean. Besides the round-trip time, ping can also measure the rate of packet loss. This is determined by the number of received echo replies over the number of sent echo requests. It is displayed as a percentage.
syslog is a standard for message logging, it's the mechanism through which messages generated by different containers are reported by the switch. These messages are reported in log files, or they can be sent to a remote syslog server.
Logging messages provide operational information about software components, including the status of the application, error reports, and detailed debugging data.
It's recommended not to set up more than 8 SYSLOG servers.
You can configure the logging of messages to a remote dedicated syslog server using the below command:
You can configure the logging of messages to a remote dedicated syslog server. Syslog message whose priority is equal and higher than the configured numerical value (i.e. If the severity level "warning(4)" is set, syslog messages with severity levels of emergency(0), alert(1), critical(2), error(3), and warning(4) will be logged).
Example
You can verify the configuration by using the command(s) below:
Command
[no] snmp-server community <string>
Description
SNMP community configuration
Parameters
SNMP community string
Mode
CONFIG
Command
[no] snmp-server location <location_name>
Description
SNMP location configuration
Parameters
SNMP location
Mode
CONFIG
Command
[no] snmp-server user <user_name> priv_type [AuthNoPriv/Priv/noAuthNoPriv] access [RO/RW] auth [HMAC-SHA-2/MD5/SHA] auth-password <auth_password>
Description
SNMP user configuration
Parameters
user value, privilege type, access type, encryption type, password value
Mode
CONFIG
Command
[no] snmp-server contact contact-name <contact_name> contact-mail <Contact_mail>
Description
SNMP contact configuration
Parameters
SNMP contact
Mode
CONFIG
Command
ping <ip address> [source <source address> | interface <interface name> [count {<number>}] [interval <seconds> ] [size <bytes> ] [timeout <seconds> ]
Description
Polls or “pings” to see if the specified host is reachable
Parameters
ip address The IP address (ipv4/ipv6) of the host to ping.
source ip address Source IP address to use
interface interface name Interface to use count packets Count of ping request
size bytes Specifies the number of data bytes to be sent
timeout seconds Time to wait for a response, in seconds
Mode
EXEC
Command
[no] snmp-server trap <cpu-util/mem-util> threshold <%>
Description
SNMP trap threshold configuration
Parameters
SNMP threshold
Mode
CONFIG
Command
[no] syslog add <ip4addr | ip6addr>
Description
Syslog server configuration
Parameters
IPv4 or v6 Address - Router IP
Mode
CONFIG
Command
logging level [alert | critical | debug | emergency | error | info | notice |
warning]
Description
alert Alert level
critical Critical level
debug Debug Level
emergency Emergency Level
error Error Level
info Informational Level
notice Notice Level
warning Warning Level
Parameters
Logging level
Mode
CONFIG
Command
no logging level
Description
enable all logging (default)
Parameters
None
Mode
CONFIG
The Network Time Protocol (NTP) is used to synchronize the internal clocks of network devices. This is helpful for troubleshooting network problems by correlating events on different network devices using, for example, Syslog messages. NTP provides the switch with a mechanism to accurately update its clock to be consistent with the clocks of other network devices within a precision of one millisecond. NTP uses User Datagram Protocol (UDP) to communicate across the network.
To configure the NTP server, use the following command:
Command
[no] ntp <ip4addr | ip6addr >
Description
NTP server configuration
Parameters
IPv4 or v6 Address - Router IP
Mode
CONFIG
To display the NTP server information, use the following command:
Command
show ntp
Description
Show NTP configuration
Parameters
None
Mode
EXEC
SONiC has Ethernet naming based on the lanes like Ethernet0, Ethernet4, Ethernet8… Ethernet252, This is not very user-friendly and the CLI Ethernet names are not mapped to the Physical front panel ports.
To avoid this and provide a better user experience, Interface Mapping Feature is implemented by exposing the Front Panel ports directly to the user and all the mapping to SONiC and ASIC is handled by OPBNOS internally.
You can trace a route to a specific destination using the below command:
Command
traceroute <ip address | hostname> [source <source address>]
Description
Trace the route to a specific destination
Parameters
ip address Destination IP address (ipv4/ipv6) of the host
hostname Name of the host
source ip address Source IP address to use
Mode
EXEC
sFlow is a multi-vendor, packet sampling technology used to monitor network devices including routers, switches, host devices and wireless access points. Flow Monitor traffic monitoring software uses the sFlow data to analyze and manage network traffic and to ensure Quality of Service.
sFlow sampling process is performed by the switching/routing ASICs, thereby ensuring wire-speed performances. The sFlow agent then combines the interface counters, flow samples and the forwarding/routing table state associated with each packet into a UDP sFlow datagram. This is then sent to the sFlow collector for collection and analysis.
Command
feature sflow no feature sflow
Description
Enable/disable sFlow feature
Mode
CONFIG
Command
sflow collector <name> <ipaddr> no sflow collector <name> <ipaddr>
Description
Enable/disable sFlow collector configuration
Mode
CONFIG
Command
sflow polling-interval <interval (0..300)> no sflow collector <interval (0..300)>
Description
Enable/disable sFlow polling-interval
Mode
CONFIG
Command
sflow enable
Description
Enable/disable sFlow per interface
Mode
INTERFACE
Command
sflow sampling-rate <rate(256..8388608)>
Description
Enable/disable sFlow sampling rate
Mode
INTERFACE
Command
sflow ("Sflow related information") [interface ("Specific to an interface") <ifname:string interface_list()> ("Interface name")], showsflow();
Description
sFlow related information
You can display information about system memory information using the following command:
OPBNOS provides various commands to display various types of platform information as follows:
System Hardware Information
System Services Information
Interface Information
Use the following command to display information about system-reboot:
Use the following command to display information about your switches fan, power, and temperature:
To get information about the Interface transceiver, use the below commands:
To check system uptime, use the below command:
Use the following command to display information about device SSD:
Use the following command to display information about pcie-info:
Use the following command to display information about system fans:
Use the following command to display information about device PSU:
You can display information about docker memory-usage use the following command:
Use the following command to display information about running services on the device:
Use the following command to display information about syseeprom:
Use the following command to display information about platform version:
Use the following command to display information about device temperature sensors:
Command
copy { running-config | startup-config } { running-config | startup-config }
Description
Change the running-config and startup-config on the switch and vice-versa
Parameters
running-config Copies to the running configuration
startup-config Copies to the startup configuration
Mode
EXEC
Command
copy scp {running-config | startup-config} <server_url> [timeout <interval> ]
Description
Copy the ISCLI config file from the Switch to a remote server
Parameters
server_url username@ipaddress:filepathandname
timeout timeout
interval Specifies the maximum time (in seconds) to wait for the server to reply to the connection request. The timeout interval is from 1 to 100 seconds running-config Copies the running configuration startup-config Copies the startup configuration
Mode
EXEC
After entering ZTP mode, the switch sends a DHCP discovery message on its management interface, requesting DHCP offers from the DHCP servers present on the network. The DHCP server replies with a DHCP offer message. When the switch receives the DHCP offer message, it will look for following information in the offer:
An interface IPv4 address
A gateway IPv4 address
A TFTP or HTTP server IP address (using option 66)
Boot file name (using option 67)
The switch completes the DHCP negotiation process (request and acknowledgement) with the DHCP server, which assigns the switch with an IPv4 management address. The switch then uses the acquired TFTP or HTTP server IP address to contact that server to get the boot file, The option 67 contains the complete file path of the boot file on the remote server. The switch then downloads the boot file.
If no DHCP servers reply is received after DHCP discovery message or if the DHCP offer does not meets the ZTP requirements, the switch won't be able to complete the DHCP negotiation and the switch exits ZTP mode and continues the normal boot process.
The interface IPv4 address obtained from the DHCP server is kept and used as management address even after the ZTP process completes
DHCP servers must be configured with options 66 and 67 to ensure that the switch always obtains the TFTP server hostname and the boot file name during the ZTP process. DHCP options 66 and 67 are enabled by default on the OPBNOS. If either of them is disabled, the ZTP process results in a failure.
You can display running and start configuration using below command:
You can save running configuration using the below command:
To remove/clear startup-config use below command:
clearing startup-config will trigger a system reboot.
The boot file is written in YAML and contains switch models, and under each switch model are several fields that instruct the ZTP process. The boot file may contain up to four fields under each switch model:
Image - This instructs ZTP to update the switch firmware image to the specified image and configure it as the next boot image on the switch
Configuration - This instructs ZTP to copy the specified configuration file from the TFTP (or HTTP) server and use it as the startup configuration file on the switch. The file should be renamed to iscli_db.cfg
Script - This instructs ZTP to copy the script file and execute it on the switch
Reboot - This instructs whether to reboot the switch after ZTP
ZTP checks the boot file for the switch model and executes it according to the fields under the correct switch model. ZTP supports the execution of Python scripts, If there is a script field under the switch model in the boot file, that field has a higher priority than the other two fields (image and configuration), thus ZTP executes it first. ZTP downloads the Python script file to the switch and executes it. The script can also contain instructions to download and install a switch firmware image and a configuration file. Users can leave some of the fields empty, ZTP will just skip the corresponding options.
The platform or hardware model should be taken from the “show platform summary”
The following example shows a boot file for a TFTP server:
The following example shows a boot file for an HTTP server:
ZTP can be force enabled to start up the ZTP process. After enabling ZTP, reboot the switch which triggers the ZTP process to kick start.
To force enable/disable ZTP on the switch, use the following command:
Command
ztp force <enable/run>
Description
Trigger ZTP process
Parameters
enable,run
Mode
EXEC
When you run the above commands, the switch will:
It will Trigger the ZTP process and download the image, configuration, and script files.
Install the downloaded files.
Reboot the switch.
After rebooting, the switch will come up with the new image.
When you run the above commands, the switch will:
Trigger the ZTP process: The ZTP process will automatically kick in after the switch reboots. ZTP will download the image, configuration, and script files, if any.
Install the image, and configuration, and run any script files.
After the files are installed, the switch will automatically reboot.
Once the switch comes back up, it will be running the new image.
After any of the above methods, the ZTP will not be disabled automatically and will need to be manually enabled if required.
OPBNOS supports copying running and startup configuration file to and from the switch over the network.
The following topics provide you with more information on configuration management:
Zero Touch Provisioning (ZTP) enables a switch to automatically provision itself using the resources available on the network without manual intervention. ZTP is triggered only when it is force-enabled from ISCLI. When OPBNOS with ZTP enabled starts up, it locates a DHCP server which provides the switch with an IPv4 management IP address and a gateway IP address. The switch then obtains the IP address of a TFTP (or HTTP) server from which it downloads the necessary boot file. The switch then runs the boot file.
During the boot process, if the ZTP is enabled, the switch enters ZTP mode. The switch searches for available DHCP servers and requests them to acquire an interface address, a gateway address, the TFTP server address, and the boot file name. After the information from the DHCP server is obtained, ZTP downloads and runs the boot file, and then executes the ZTP process according to the boot file. ZTP automatically handles the process of upgrading the switch firmware image and installing configuration files.
ZTP handles firmware upgrades from ONIE to OPBNOS and OPBNOS to OPBNOS
If ZTP was force enabled and no DHCP server was found during the ZTP process, the switch will remove any management IP that may have been configured previously
Important ZTP events are logged by the switch and are available for display from a console
The following topics provide you with more information on Zero Touch Provisioning(ZTP)
To generate hardware dumps for debugging and technical support use the below commands:
You can display the tech-support information use the below command
To copy the generated file to a remote server use the below command
You can display the hardware-dump using the below command
You can generate hardware-dump for debugging
To copy the generated file to a remote server use the below command