Vyatta documentation

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

Show Page Sections

Patch release notes 2012e

Vyatta NOS patch release notes 2012e.

Released August 3, 2021

Issues Resolved

Issues resolved in 2012e.

Issue number

Priority

Summary

VRVDR-55424

Blocker

PTP: APTS profile is broken

VRVDR-55318

Blocker

FAL_BCM: fal_plugin_qos_new_sched_group: mandatory sched-group create attribute missing: max-children

VRVDR-55160

Blocker

dataplane: srvAdaptiveFrequencyReferenceTracker.c:91: getStraightenedLocalTimestampsAdaptiveFrequency: Assertion `((direction == E_srvUpLinkDirection) || (direction == E_srvDownLinkDirection))' failed

VRVDR-55136

Blocker

Ingress timestamped packets have wrong correctionFields inserted on egress ports that do not have TIMESYNC configured

VRVDR-53608

Blocker

Update smartmontools to rel 7.2

VRVDR-55286

Critical

Multicast configuration and OSPFv3 IPv4 process

VRVDR-54989

Critical

Comment text in op mode command list

VRVDR-55753

Major

Multicast: eliminate or hide FAL counter logs

VRVDR-55721

Major

Dataplane crash segfault in npf_session_tcp_state_change up on upgrade from 1912

VRVDR-55569

Major

MRIBv6 FIB: Peek error Resource temporarily unavailable

VRVDR-55463

Major

Mtrace not working

VRVDR-54426

Major

Dataplane crashes when DPI is enabled

VRVDR-50590

Major

QoS Shaper for TCP traffic with flags results in traffic being queued into default traffic-class 0

VRVDR-55547

Minor

PTP: re-send the GNSS failures periodically

Security vulnerabilities resolved

Security vulnerabilities resolved in 2012e.

Issue number

CVSS score

Advisory

Summary

VRVDR-55352

9.8

DSA-4930-1

CVE: CVE-2018-25009, CVE-2018-25010, CVE-2018-25011, CVE-2018-25013, CVE-2018-25014, CVE-2020-36328, CVE-2020-36329, CVE-2020-36330, CVE-2020-36331, CVE-2020-36332:Debian DSA-4930-1 : libwebp - security update

VRVDR-55435

8.1

DSA-4933-1

CVE-2021-20305, CVE-2021-3580: Debian DSA-4933-1 : nettle - security update

VRVDR-55399

7.1

DSA-4931-1

CVE-2021-0089 CVE-2021-26313 CVE-2021-28690 CVE-2021-28692: Debian DSA-4931-1 : xen - security update

VRVDR-55759

N/A

DSA-4942-1

CVE-2021-33910: Debian DSA-4942-1 : systemd - security update

GNSS support

A number of minor GNSS timing enhancements were added as part of this patch release.

The list of issues related to GNSS support:

  • VRVDR-54884: Implement PDV accuracy improvement that will be provided by Broadcom's part of eRAN sync 8275.2
  • VRVDR-54883: Ability to get the status of the GPS antenna connection thru CLI command as part of eRAN sync 8275.2
  • VRVDR-54882: Ability to remotely disable and enable GPS antenna connection to SIAD using a CLI modelled command as part of eRAN sync 8275.2
  • VRVDR-54881: LED support for GPS connectivity as part of eRAN sync 8275.2

Global Navigation Satellite System (GNSS) refers to a group of satellites that are used to provide navigation signals to end-users. A number of such systems exist: Europe's Galileo, the USA's NAVSTAR Global Positioning System (GPS), Russia's Global'naya Navigatsionnaya Sputnikovaya Sistema (GLONASS), and China's BeiDou Navigation Satellite System. In general, the signals available from these systems 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.

If the platform supports a GNSS, it should be continually monitored. Where possible, the antenna and signal status should be communicated on front panel LEDs. The LED capabilities of each platform are different and the exact behavior of the LEDs needs to be documented for each platform. The end-user should have the ability to query the GNSS from the CLI. The returned information vary based on the specific capabilities of the hardware, but it should include some basics such as antenna status, current time, satellites in view.

In order to debug potential problems with GNSS, the end-user may want to disable or enable the GNSS hardware. If the GNSS is disabled, it should not be used as a source of timing for any of the local services.

New operational commands

show gnss

This command is used to show the status of the GNSS hardware.

antenna-status can be the following:
  • OK: The GNSS receiver is not reporting an antenna problem.

  • short: The GNSS receiver is reporting a short-circuited antenna.

  • open: The GNSS receiver is reporting a disconnected or passive antenna.

  • unknown: The GNSS receiver's antenna connection is in an unknown state.

gnss-status can be the following:
  • acquiring: The GNSS receiver is attempting to acquire a valid signal.

  • tracking: The GNSS receiver has valid time and/or position fix.

  • unknown: The GNSS receiver is in an unknown state.

stop gnss

This command is used to stop the GNSS hardware. Once completed, the GNSS hardware will not be used a source of timing information.

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.

Hardware limitations

Not all platforms have GNSS hardware. If a platform does have GNSS hardware, the GNSS commands should be available.

On the UfiSpace S9500-30XS platform, the GPS LED shows the following behavior:

GPS LED

Status

Off

No GNSS antenna is connected, the GNSS is not initialized, or a passive antenna is connected.

Blinking green

GNSS antenna is connected, GNSS signal is present, GNSS attempting to acquire a position fix

Solid green

GNSS antenna is connected, GNSS has a valid position fix and is ready

Blinking yellow

There is some problem with the GNSS hardware; Check for antenna shorts, opens, or poor signal.

Solid yellow

GNSS antenna is connected, GNSS signal is not present (no visible satellites yet)

SYNC LED

Status

Off

The system timing core has not been configured.

Blinking green

The system timing core is frequency-locked.

Solid green

The system timing core is frequency-locked and phase-locked.

Blinking yellow

The maximum holdover time (7200 seconds) has been exceeded. The phase and frequency are likely out of specification.

Solid yellow

Both the phase clock and the frequency clock are in holdover.

Enhanced syslog

VRVDR-53476 introduced mobility syslog enhancements.

The enhanced syslog feature allows syslog to be configured using a rule-based approach, similar to firewall rules. Unlike the current configuration, where you configure a facility, severity, and regular expression to match the msg part for each target, with enhanced syslog you configure a series of match/action rules.

For each rule, you can specify a number of selectors. If all of the selectors match the message, the rule matches and the actions will be taken. The users give a number to the rules, and rules are evaluated in increasing order, until a rule with a discard action matches or the end of the rules is reached (at which point the message is discarded). Expressing the syslog configuration in this way is easier to understand, with less implicit knowledge of the implementation required, and more expressive, allowing users to accomplish things not possible under the previous model.

Message selectors

Within a rule, all selectors that are specified have to match. A single rule can have selectors of different types. if a rule with no selectors is specified, the rule matches all messages that are evaluated against it. There is no overall limit to the number of selectors but facility and severity selectors can only be used once per rule.

POSIX regular expression match of msg part

A regular expression can be specified, that will be checked against the msg part of the syslog message. The regular expression is treated as a POSIX extended regular expression. Additionally, the regular expression can have an associated "unless" regular expression, in which case a message that matches both regular expressions would not be selected.
syslog-enhanced {
       rule 100 {
               match {
                      msg {
                               posix-match "ba.*" {
                                       unless baz
                               }
                          }
               }
       }
}

In this example, any message matching "ba.*" would be selected, unless it also matches baz.

Syslog facility selector

A syslog facility can be specified. If a message has the given facility, the selector will match.

syslog-enhanced {
       rule 100 {
               match {
                       facility kern
               }
       }
}

In this example, messages with a facility of kern will be selected.

Syslog severity selector

Selectors can be specified to match based on the severity of the message.
  • The at-least selector matches messages with the given severity or higher.

  • The at-most selector matches messages with the given severity or lower.

  • The equals selector matches messages with the given severity exactly.

syslog-enhanced {
       rule 100 {
               match {
                       severity {
                               at-least alert
                       } 
               }
       }
       rule 200 {
               match {
                       severity {
                               at-most info
                       }
               }
       }
       rule 300 {
               match {
                       severity {
                               equals err
                       }
               }
       }
}
In this example, the following rules are used:
  • rule 100 matches messages with a severity of alert or emerg

  • rule 200 matches messages with a severity of info or debug

  • rule 300 would match messages with a severity of err only

Flag selector

The flag selector selects messages with the given flag set. Flags are an internal mark that can be set on messages using the set flag action, which can be used to achieve complex logic that may be difficult or impossible to implement within a single rule. Flag selectors exist for both selecting messages that have the given flag set (the with-flag selector) and for selecting messages without the given flag set (the without-flag selector). For the flag selectors to match, the message must have all of the with-flag flags set, and none of the without-flag flags. Messages can have flags that are not specified with a with-flag selector and still match, as long as that flag is not set as a without-flag selector.
syslog-enhanced {
       rule 100 {
               match {
                       with-flag important
                       with-flag to-central
                       without-flag bad-log
               }
       }
}

This example would match messages with the important and to-central flags set, as long as they do not have the bad-log flag set.

Rule actions

Actions specify what should be done to messages that match the selectors (in the case of a "then" action), or to messages that do not match the selectors (in the case of an "otherwise" action). Multiple actions of both types can be specified in a single rule, and will take effect in the following order:

  1. set-facility, set-severity, set-indicator, set-flag
  2. clear-flag
  3. console, user, file, host
  4. discard

Set facility action

The set facility action allows the facility of a message to be overridden. Within a rule, the set facility action happens first, along with the other "set" actions. This means that the override applies to the current rule and any later rules, unless the facility is subsequently overridden again.

syslog-enhanced {
       rule 100 {
               then {
                     set-facility local1
               }
       }
}

This rule sets the facility of all messages to local1.

Set severity action

The set severity action allows the severity of a message to be overridden. Within a rule, the set severity action happens first, along with the other "set" actions. This means that the override applies to the current rule and any later rules, unless the severity is subsequently overridden again.

syslog-enhanced {
       rule 100 {
               then {
                     set-severity warning
               }
       }
}

This rule sets the severity of all messages to warning.

Set indicator action

The set indicator action allows a user-visible indicator to be prepended to the msg part of the syslog message on output. The indicator does not modify the original msg part used for rule matching. Within a rule, the set indication action happens first, along with the other "set" actions. This means the indicator will be output for output actions on this and any later rules, unless the indicator is subsequently overridden.

syslog-enhanced {
       rule 100 {
               then {
                     set-indicator DAMPENED
               }
       }
}

This rule sets an indicator of DAMPENED to all messages. For example, if the message was previously "Interface dp0s3 went down", the message will now be "DAMPENED Interface dp0s3 went down".

Set flag action

The set flag action allows a flag to be set on the message. Flags are an internal mark which can be set on a message and used as a selector in later rules. This enables complex logic that may be difficult or impossible to implement in a single rule. Multiple set flag actions can be specified for a single rule, in which case all of the given flags will be set. Within a rule, the set flag action happens first, along with the other "set" actions.

syslog-enhanced {
       rule 100 {
               then {
                       set-flag to-admin
                       set-flag to-central
               }
       }
}

In this example, the to-admin and to-central flags are set on all messages.

Clear flag action

The clear flag action allows a flag to be cleared from the message. Multiple clear flag actions can be specified for a single rule, in which case all of the given flags are removed. If a message being acted on does not have the specified flag, this is ignored. Within a rule, the clear flag action happens after the set actions. In other words, if the same flag is set and cleared within a rule, the resulting message will not have the flag set.

syslog-enhanced {
       rule 100 {
               then {
                       clear-flag selected
                       clear-flag to-admin
               }
       }
}

This rule clears the selected and to-admin flags from all messages.

Output to console action

The output to console action outputs the selected message to the system console. Within a rule, the output to console action happens after the "set" and "clear" actions, but before the "discard" action.

syslog-enhanced {
       rule 100 {
               then {
                       console
                }
        }
}

In this example, all messages are outputted to the system console.

Output to user action

The output to user action outputs the selected message to the given user's terminal. Multiple output to user actions can be specified for a single rule, in which case the message is output to every specified user's terminal. Within a rule, the output to user action happens after the "set" and "clear" actions, but before the "discard" action.

syslog-enhanced {
       rule 100 {
               then {
                       user admin
                       user mrrobot
               }
       }
}

This rule outputs all messages to the terminals of users admin and mrrobot.

Output to file action

The output to file action outputs the selected message to the specified file. The file must be configured in the file list, specifying the filename and log rotation parameters for the file. Multiple output to file actions can be specified for a single rule, in which case the message is output to each specified file. Within a rule, the output to file action happens after the "set" and "clear" actions, but before the "discard" action.

syslog-enhanced {
       file mylog {
               archive {
                      files 10
               }
               filename logs2go
       }
       rule 100 {
               then {
                      file mylog
               }
       }
}

In this example, all messages are outputted to the logs2go file. 10 rotations of the file will be retained.

Output to host action

The output to host action outputs the selected message to the specified host. The host must be configured in the host list, specifying the protocol, port number, hostname/IP, etc. Multiple output to host actions can be specified for a single rule, in which case the message is output to each specified host. Within a rule, the output to file action happens after the "set" and "clear" actions, but before the "discard" action.

syslog-enhanced {
       host central {
               hostname syslog.example.com
               port 1234
               protocol udp
       }
       rule 100 {
               then {
                   host central
               }
       }
}

In this example, all messages are forwarded to syslog.example.com on UDP port 1234.

Discard action

The discard action drops messages being acted on, meaning that no further rules will be processed for those messages. Within a rule, the discard action happens last, after other actions.

syslog-enhanced {
       rule 100 {
               match {
                       severity {
                                at-most info
                       }
               }
               then {
                       discard
               }
       }
       rule 200 {
               match {
                       facility auth
               }
               otherwise {
                       discard
               }
       }
}

Rule 100 discards messages with a severity of info or below. Rule 200 discards any messages that do not have a facility of auth.

Rate limiting

Rate limit by count

Rate limit by count allows a rate limit to be specified for a given flag. Rate limits cannot be specified in the same rule as match selectors. A flag of "*" can be specified, in which case all messages evaluated against the rule will have the rate limit applied. Only 1 of every count of messages will be selected. For example, if the count is 100, only every 100th message will be selected.
syslog-enhanced {
       rule 100 {
               match {
                       severity {
                               at-most info
                       }
               }
               then {
                       set-flag to-limit
               }
       }
       rule 200 {
               rate-limit to-limit {
                       select-every-nth 10
               }
               then {
                       console
               }
               otherwise {
                       discard
               }
       }
}

In this example, messages with a severity of info or below are flagged with to-limit. Those flagged messages are then rate limited, with every 10th message being outputted to the console, and the others discarded.

Rate limit by burst in interval

Rate limit by count allows a rate limit to be specified for a given flag. Rate limits cannot be specified in the same rule as "match" selectors. A flag of "*" can be specified, in which case all messages evaluated against the rule will have the rate limit applied. Only the first burst messages in the time interval will be selected. For example, if the burst is 100 and the interval is 10, only the first 100 messages every 10 seconds will be selected.
syslog-enhanced {
       rule 100 {
               match {
                       severity {
                               at-most info
                       }
               }
               then {
                       set-flag to-limit
               }
       }
       rule 200 {
               rate-limit to-limit {
                       burst 10
                       interval 30
               }
               then {
                       console
               }
               otherwise {
                       discard
               }
       }
}

In this example, messages with a severity of info or below are flagged with to-limit. Those flagged messages are then rate limited, with the first 10 messages every 30 seconds being outputted to the console, and the others discarded.

Rate limiting input from the system journal

Rate-limiting the reading of the input messages from the system journal can be specified. Only the first burst messages in the time interval seconds will be read. Further messages up to the end of the interval are discarded.
syslog-enhanced {
        input {
                journal {
                        rate-limit {
                                burst 20000
                                interval 600
                        }
                }
        }
}

In this example, up to 20000 messages will be read from the journal every 600 seconds.