Vyatta NOS documentation

Learn how to install, configure, and operate Vyatta Network Operating System (Vyatta NOS), which helps to drive our virtual networking and physical platforms portfolio.

Show Page Sections

New features - S9500-30XS platform

Assigning forwarding class to locally originated control and management traffic based on protocol

This feature implements an egress DiffServer node classifier in order to support end-to-end QoS packet processing according to RFC 2475.

The function of the DiffServer classifier is to mark (write the DSCP field in the IP header) packets based on the content of packet headers according to defined rules or configuration which represent class of service. This is necessary to correctly map those packets to internal priority and treat them according to configured class of service in all intermediate routers along the path from the Vyatta router to the destination router. This allows, for example, to reduce a chance of dropping control plane packets like BFD or BGP in intermediate routers in case the path is overloaded with other traffic such as HTTP.

In earlier releases, this didn't exist for the S9500-30XS platform. It existed in the transit path for the DPDK platform and was partially implemented for the slow path: the path that transfers packets originated in the vRouter.

Operational mode commands

show firewall has been updated to display originate firewall information.

clear firewall interface interface_name dir direction
  • If interface_name is lo, then direction can be either local or originate. Specifying originate clears the counters for the firewall originate.
  • If interface_name is a dataplane interface, then direction may be in, out, local, or originate. Specifying originate clears the counters for the firewall originate.

Configuration data model - configuration of classification rules to interface

set interfaces loopback lo firewall originate firewall_name

After commit of this configuration, classification/firewall rules in the classification group firewall_name is activated in slow path by default for all interfaces. All slow path packets are matched against rules and the action configured is taken.

Restrictions:
  • firewall_name shall exist.
  • firewall_name can be applied only on "lo" interface.
  • firewall_name shall not have npf_rule_match_parameters session parameter configured.
  • firewall_name shall not have npf_rule_match_parameters ethertype parameter configured.
  • firewall_name shall not have npf_rule_match_parameters pcp parameter configured.
  • firewall_name shall not have npf_rule_match_parameters state parameter configured.
  • firewall_name shall not have npf_rule_match_parameters fragment parameter configured.
  • firewall_name shall not have npf_rule_match_parameters protocol = 'ipv6-frag' parameter configured.
  • firewall_name shall not have npf_rule_match_parameters protocol-group protocol = 'ipv6-frag' parameter configured.
  • firewall_name shall not have npf_rule_match_parameters source mac-address parameter configured.
  • firewall_name shall not have npf_rule_match_parameters destination mac-address parameter configured.
  • firewall_name shall not have default-action parameter configured.
  • firewall_name shall not have default-log parameter configured.

If several classification/firewall groups are added to the loopback interface, then the order in which the packet are matched against groups rules is defined by order of addition. To change the order, groups shall be removed and added again in the required order.

delete interfaces loopback lo firewall originate firewall_name

After the commit of this configuration, classification/firewall rules in the classification/firewall group firewall_name are deactivated in slow path. All slowpath packets will not be matched against rules.

Note: All slow path packets will have the DSCP values set by the application or Linux kernel and will not be remarked.
set interfaces dataplane interface_name firewall originate firewall_name

After the commit of this configuration, classification/firewall rules in classification group firewall_name are activated in slow path output from interface_name. All slow path packets are matched against rules and the configured action is taken.

Restrictions:
  • firewall_name shall exist.
  • firewall_name can be applied only on "lo" interface.
  • firewall_name shall not have npf_rule_match_parameters session parameter configured.
  • firewall_name shall not have npf_rule_match_parameters ethertype parameter configured.
  • firewall_name shall not have npf_rule_match_parameters pcp parameter configured.
  • firewall_name shall not have npf_rule_match_parameters state parameter configured.
  • firewall_name shall not have npf_rule_match_parameters fragment parameter configured.
  • firewall_name shall not have npf_rule_match_parameters protocol = 'ipv6-frag' parameter configured.
  • firewall_name shall not have npf_rule_match_parameters protocol-group protocol = 'ipv6-frag' parameter configured.
  • firewall_name shall not have npf_rule_match_parameters source mac-address parameter configured.
  • firewall_name shall not have npf_rule_match_parameters destination mac-address parameter configured.
  • firewall_name shall not have default-action parameter configured.
  • firewall_name shall not have default-log parameter configured.
delete interfaces dataplane interface_name firewall originate firewall_name

After the commit of this configuration, classification/firewall rules in classification/firewall group firewall_name will be deactivated in slow path for interface interface_name. All slow path packets that set out from interface interface_name are not matched against rules.

Note: All slow path packets will have the DSCP values set by the application or Linux kernel and will not be remarked.
set interfaces switch switch_name vif vif_id firewall originate firewall_name

After the commit of this configuration, classification/firewall rules in classification group firewall_name are activated in slow path that output from interface switch_name.vif_id@switch_name. All slow path packets are matched against rules and the configured action is taken.

Restrictions:
  • firewall_name shall exist.
  • firewall_name can be applied only on "lo" interface.
  • firewall_name shall not have npf_rule_match_parameters session parameter configured.
  • firewall_name shall not have npf_rule_match_parameters ethertype parameter configured.
  • firewall_name shall not have npf_rule_match_parameters pcp parameter configured.
  • firewall_name shall not have npf_rule_match_parameters state parameter configured.
  • firewall_name shall not have npf_rule_match_parameters fragment parameter configured.
  • firewall_name shall not have npf_rule_match_parameters protocol = 'ipv6-frag' parameter configured.
  • firewall_name shall not have npf_rule_match_parameters protocol-group protocol = 'ipv6-frag' parameter configured.
  • firewall_name shall not have npf_rule_match_parameters source mac-address parameter configured.
  • firewall_name shall not have npf_rule_match_parameters destination mac-address parameter configured.
  • firewall_name shall not have default-action parameter configured.
  • firewall_name shall not have default-log parameter configured.

If several classification/firewall groups are added to the dataplane interface, then the order in which packet are matched against groups rules is defined by order of addition. To change the order, groups should be removed and added again in required order.

delete interfaces switch switch_name vif vif_id firewall originate firewall_name

After the commit of this configuration, classification/firewall rules in the classification/firewall group firewall_name are deactivated in slow path for interface switch_name.vif_id@switch_name, all slow path packets that set out from interface switch_name.vif_id@switch_name are not matched against rules.

Note: All slow path packets will have the DSCP values set by the application or Linux kernel and will not be remarked.

Configuration data model - GRE NPF filter configuration for ERSPAN protocol match

set security firewall name firewall_name rule rule_number gre protocol gre_protocol
delete security firewall name firewall_name rule rule_number gre protocol gre_protocol

If an IPv4 or IPv6 packet has protocol equal to GRE, then the payload is decoded according to RFC 2784. For example, to match the ERSPAN case, we could configure:

set security firewall name ERSPAN rule 1 protocol gre
set security firewall name ERSPAN rule 1 gre protocol erspan

While for the GRE case, we could configure:

set security firewall name ERSAPN rule 1 protocol gre

Any value in the GRE protocol is match by default.

Configuration data model - BFD DSCP configuration

set protocol bfd dscp dscp_value

After commit, all locally originated packets from QAX BFD and from CPU BFD packets have dscp_valu in its IP header. This configuration is global for all BFD connections.

VLAN-based QoS support on LAG

This feature adds support for a VLAN-based Quality of Service (QoS) policy on LAG in L2 and L3 mode.

In the switch mode (L2), VLANs can be added to a bonding interface using switch-group commands. In the router mode (L3), VLANs can be configured to a bonding interface using a VIF command. To configure per-VLAN based QoS on each LAG member, QoS parameters have been added to the existing VLAN based switch-group and VIF command under bonding interface configurations.

Operational mode commands

show policy qos and show queuing command output have been extended to display the QoS policy configured on the bonding interface VLAN.

clear policy qos interface-name

This command has been extended to accept the bonding interface member ports with VLAN to clear QoS counters. For example, interface-name is of the form dp0xe0, or dp0xe0.10, where 10 is the VLAN identifier

Configuration data model

set interfaces bonding name switch-group port-parameters vlan-parameters qos-parameters vlan vlan-id policy qos policy-name

This command applies a QoS policy on a VLAN of a LAG. Internally, it is applied on the VLANs of each LAG member.

set interfaces bonding name vif vifnum policy qos policy-name
This command applies a QoS policy on a VIF of a LAG.

QoS support on LAG

This feature brings QoS support available for front-panel ports in L3 mode to bonding interfaces in L3 mode.

Operational mode commands

show policy qos and show queuing command outputs have been extended to display the bonding group and members with a QoS policy configured.

clear policy qos interface-name
This command now accepts a bonding interface name as an optional parameter. interface-name may now be either an optional dataplane interface (dp0xe0, dp0xe1, etc.) or a bonding interface (dp0bond0, dp0bond1, etc.).

Configuration data model

set interfaces bonding interface-name policy qos policy-name
This command configures QoS on an L3 interface.

SFP Digital Optical Monitoring

This feature allows the Vyatta NOS to poll the EEPROM periodically to determine if any of the following measures are outside the normal operating ranges and notify the operator:

  • Rx power
  • Tx power
  • Voltage
  • Temperature
  • Laser bias

Operational mode commands

show system sfp monitoring status [ interface ]
Displays the measured values for power, temperature, voltage and laser bias and any alarms/warnings for all SFPs in the system. This command displays the current SFP measured values regardless of whether the monitoring interval has been set.
show system sfp monitoring events [ interface ]
Displays any SFP warning and alarm events logged to the system journal since boot.

Configuration data model

set system sfp monitoring interval interval
This command enables monitoring the (Q)SFPs in the system and specifies the monitoring interval. SFPs plugged into all interfaces that are administratively enabled are polled at the specified interval (1-3600 seconds). Any alarms/warnings detected are logged along with the current value of the appropriate measure and the associated thresholds.

GNSS support

Global Navigation Satellite System (GNSS) refers to a group of satellites that are used to provide navigation signals to end-users. The signals available from the GPS satellite system are time, position, and an accurate pulse-per-second clock. Some platforms may have GNSS hardware that is potentially used in conjunction with PTP, SyncE, and other timing services.

Since these systems involve some physical configuration and are subject to weather-related outages, it is necessary for the end-user to be able to perform some basic diagnostics on the existing GNSS hardware.

Operational mode commands

show gnss
This command shows the status of the GNSS hardware, the satellite system, and satellites currently being used.
start gnss
This command is used to start the GNSS hardware. Once completed, the GNSS hardware will potentially be used as a source of timing information.
stop gnss
This command is used to stop the GNSS hardware. Once completed, the GNSS hardware will not be used as a source of timing information.

Configuration data model

set service gnss instance [N] antenna-delay [-10000..10000]
This command is used to compensate for the antenna cable length or processing delays associated with signal distribution networks. A typical calculation would be: cable length x velocity factor of the cable = antenna-delay.

antenna-delay was removed from set service ptp, which only compensated PTP and not the entire timing subsystem (which includes PTP).

GTP hashing for LAG and ECMP

When there are multiple members of a Link Aggregation bundle or paths installed for an ECMP route, it is necessary to decide which member or path to send a given packet out of. Typically this is done via a hash on packet header fields, with the goal to keep packets within the same "flow" out of the same interface/path. This keeps reordering to a minimum, since it can cause problems of various kinds on some end hosts.

This feature adds the GPRS Tunneling Protocol (GTP) version 1 Tunnel Endpoint Identifier (TEID) field as part of the hash for LAG members and IPv4 and IPv6 unicast ECMP paths on Broadcom Qumran-AX based platforms (such as the UfiSpace S9500-30XS), given the backhaul mobility use case where much of the traffic will be tunnelled and so otherwise have the same source/dest IP address and source/dest UDP port fields.