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: |
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 |
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 |
CVE-2021-20305, CVE-2021-3580: Debian DSA-4933-1 : nettle - security update | |
VRVDR-55399 |
7.1 |
CVE-2021-0089 CVE-2021-26313 CVE-2021-28690 CVE-2021-28692: Debian DSA-4931-1 : xen - security update | |
VRVDR-55759 |
N/A |
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.
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.
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
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
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
}
}
}
}
rule 100
matches messages with a severity ofalert
oremerg
rule 200
matches messages with a severity ofinfo
ordebug
rule 300
would match messages with a severity oferr
only
Flag selector
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:
set-facility
,set-severity
,set-indicator
,set-flag
clear-flag
console
,user
,file
,host
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
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
"*"
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
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.