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.

System validation errors

Errors of this type occur only when Vyatta NOS detects a problem when you try to commit or validate your changes.

The nature of these errors is such that Vyatta NOS can detect and report them only when you submit a validate command in the CLI — or a commit command, which includes an implicit validate.

These errors can be tricky to troubleshoot because:

  • They may result from complex relationships between multiple command strings in your candidate configuration
  • The error messages tend to be quite general, and demand some interpretation to find the specific root cause
  • There may be more than one way to solve the specific problem — and you must decide which solution is best for your situation, depending on what you want to achieve

Example sequence for a system validation error

This example is very basic, but shows you how a more complex non- YANG-based error works in principle, and how you might troubleshoot it.

Here we create the simplest QoS policy and attach it to an interface called dp0p2s0.

user@system:~$ configure
[edit]
user@system# set policy qos name policy-1 shaper profile profile-1
[edit]
user@system# set policy qos name policy-1 shaper default profile-1
[edit]
user@system# set interface dataplane dp0p2s0 policy qos policy-1
[edit]
user@system# commit
[edit]
user@system# exit
exit
user@system:~$

If we use the operational command show policy qos then we can see that the QoS policy is now attached to dp0p2s0. (All the counters are at zero in this example, as we haven't sent any traffic through.)

user@system:~$ show policy qos
Interface          TC             Counters          
-----------------------------------------------------
dp0p2s0             0                    0 Bytes    
                                         0 Packets  
                                         0 Tail-drop
                                         0 RED-drop 
                    1                    0 Bytes    
                                         0 Packets  
                                         0 Tail-drop
                                         0 RED-drop 
                    2                    0 Bytes    
                                         0 Packets  
                                         0 Tail-drop
                                         0 RED-drop 
                    3                    0 Bytes    
                                         0 Packets  
                                         0 Tail-drop
                                         0 RED-drop

Then, we set the bandwidth to an unsupported value and try to commit the change.

user@system:~$ configure
[edit]
user@system# set policy qos name policy-1 shaper bandwidth 1kbit
[edit]
user@system# commit
[interfaces dataplane dp0p2s0 policy qos policy-1]
Bandwidth cannot be lower than 8Kbit
[[interfaces dataplane dp0p2s0 policy qos policy-1]] failed.
Commit failed!
[edit]user@system#

The actual error message is Bandwidth cannot be lower than 8Kbit.

However, the CLI also displays the lines [interfaces dataplane dp0p2s0 policy qos policy-1], [[interfaces dataplane dp0p2s0 policy qos policy-1]] failed. and Commit failed!.

This is because it's our attachment of the QoS policy onto the interface — which we did in the first configure ... commit ... exit sequence — that actually triggers checks that the QoS policy is correct and consistent.

In this case, there are three different solutions that we could apply:

  • Increase the bandwidth to 8kbit or more
  • Use the command delete interface dataplane dp0p2s0 policy qos to remove the QoS policy from the interface
  • Use the command set interfaces dataplane dp0p2s0 policy qos policy-2 to replace the unsuitable policy policy-1 on the interface with a more suitable policy, policy-2