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 – general purpose

New CLI commands associated with the new features can be found in the configuration section.

Allow descriptions to be added to static routes and tables

This feature enables the ability to add descriptions to static routes and tables.

Add CLI feature to enable rsyslog TLS

This feature details the mandatory requirements needed to configure a rsyslog TLS.

Syslog TLS config revolves around a server certificate and client certificate + client key. These files, plus a remote host name are the only mandatory requirements needed to configure a syslog TLS remote logging connection.

SNMP config obfuscation to redact community strings

This feature details the need to restrict SNMP access.

The vRouter Yang models currently model the SNMP community strings as a list key.  ​ The community string permits SNMP access to a device, so is considered as sensitive information that warrants restricted access.

Extend show bfd session to include local interface

Augment the show bfd session output to include the local interface.

Allow firewall rule logging on packets with session state by NAT or FW without affecting throughput

This feature provides greater control over network logging without impacting router performance.

Customers often want connection attempts to or through any interface of the firewall logged in order to create a record of the network activity. Vyatta only offered the ability to log per-packet and this impacted the forwarding performance of the router. This feature implements per-session logging as an alternative to per-packet logging. This will greatly reduce the number of messages logged.

Ephemeral component support

This feature has been implemented to allow for easier transition to new components and allow some reuse of code within features.

The goal of this infrastructure is to make the transition to Vyatta components easier and to allow for some code reuse with the existing implementations. Some features will benefit from this, but others are written so far outside of the recommended mechanism that they will still require significant rework. Ported and a fully developed components should be considered in those cases for performance reasons.

OSPF – Avoid database overflow - support for RFC 1765

This feature provides functionality for all non-default external LSA's originated by the router to be flushed to avoid database overflow.

In OSPF it is important that eventually each router in an OSPF area has an identical Link State Database for that area. If not routing loops can occur. If a router in an OSPF area runs out of resource (no CPU available to process LSA's or no memory left to store/flood LSA's), the Link State Database for the router may never reach the same final state as its neighbors.

To prevent any router from running out of resource, if the number of External-LSA's reaches a preconfigured limit (ospfExtLsdbLimit), all non-default external LSA's originated by the router are flushed. This limit must be provisioned identically on all routers in an OSPF autonomous system. This limit cannot be per OSPF area as External-LSA's are flooded across all areas. This trigger puts the router into OverflowState.

After a configurable timeout has elapsed (ospfExitOverflowInterval), the router can attempt to leave OverflowState. The router will only attempt to leave OverflowState if the current LSA count + the extra externals to be orginated < ospfExtLsdbLimit. If the timeout is not specified the router will not leave OverflowState until the OSPF process is restarted.

In an attempt to maintain general external network reachability, External-LSA's that carry the default route are left untouched by this feature.

Tracking feature support for VRRP/Route

This section details the VRRP tracking support in Vyatta.

VRRP currently has two tracking options in Vyatta:
  • Tracking of interfaces.
  • Tracking of path monitors.
The state of these tracked objects can modify a groups priority or take it down completely. As part of the CGNAT project as well as tracking level 1 (interface up), level 2 (ping the other side of the connection) it would be advantageous to also track the state of level 3 (has BGP converged). Rather than explicitly tracking the state of BGP tracking of when a route exists provides a more generic feature and fulfills the requirements.

For the CGNAT use case this feature will be used for checking of upstream routers. If BGP peering fails the MASTER ship can change to a router that hopefully has an active and relevant route.

IPsec RA VPN server: enable VFP support

Make use of Virtual Feature Point (VFP) interfaces to apply firewall/DNAT/SNAT rules on the IPsec RA VPN server terminated tunnel traffic.

Vyatta router for use in Azure external cloud

This feature adds support to the Vyatta NOS for operation in Azure.

There are no configuration commands to enable the functionality as all the new work is behind the scenes infrastructure. The feature consists of a DPDK Hyper-V driver, extensions to cloud_int for the Azure environment and the inclusion of Microsoft  Azure Linux Agent (waagent) within a VHD image.