Turbo Router
Turbo Router
Release 3.3.3
6WIND
Contents
1 Overview 1
1.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.1 Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.2 Layer 2 (Data Link Layer) and Encapsulations . . . . . . . . . . . . . . . . . . . . . . 2
1.1.3 IP Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.4 IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.5 CG-NAT (Carrier Grade Network Address Translation) . . . . . . . . . . . . . . . . . . 3
1.1.6 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.7 QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.8 IP Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.9 Management/Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.10 Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1.11 High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2 Getting Started 7
2.1 Delivery contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.1 Install on bare metal using USB stick . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.2 Install on bare metal using CDROM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.3 Install on bare metal using PXE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.4 Install as a VM (Virtual Machine) using KVM . . . . . . . . . . . . . . . . . . . . . . . 21
2.2.5 Install as a VM using OpenStack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.2.6 Install as a VM using VMware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.2.7 Install as a VM using Proxmox VE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.2.8 Install as a VM using AWS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
2.2.9 Update an existing installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
2.3 First configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
2.3.1 Logging in to the CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
2.3.2 Restoring from a backup file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
2.3.3 Day-1 configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
2.3.4 Configuring your license . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
2.3.5 Configuring the fast path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
3 User Guide 79
3.1 User Guide - CLI / NETCONF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
3.1.1 Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
3.1.2 Key features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
3.1.3 Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
3.1.4 System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
3.1.5 Network interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
3.1.6 IP Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
3.1.7 Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
3.1.8 QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
3.1.9 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507
3.1.10 High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577
3.1.11 Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 612
3.1.12 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626
3.1.13 Maximum Capacity Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 641
3.1.14 Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 642
3.1.15 Automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 650
3.2 Command Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 669
3.2.1 cmd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 669
3.2.2 show . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697
3.2.3 flush . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 779
3.2.4 system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794
3.2.5 cloud-init . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 813
3.2.6 license . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 814
3.2.7 auth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 822
3.2.8 aaa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 824
3.2.9 vrf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 825
3.2.10 ssh-server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 825
3.2.11 netconf-server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 826
3.2.12 dns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 828
3.2.13 dns-server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 832
3.2.14 lldp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 834
3.2.15 kpi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 840
3.2.16 telegraf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 841
3.2.17 tracker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 842
3.2.18 nat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854
3.2.19 cg-nat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 879
3.2.20 ntp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 904
3.2.21 firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 913
3.2.22 network-port (state only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1714
3.2.23 interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1716
3.2.24 qos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1998
4 Troubleshooting 2705
4.1 Relevant Information for Bug Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2705
4.2 Typical issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2706
4.2.1 Startup Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2706
4.2.2 Networking Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2712
4.2.3 Performance Tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2716
4.2.4 OpenStack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2717
4.2.5 Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2718
4.3 Fast Path Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2719
4.3.1 Fast Path statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2719
4.3.2 fp-cpu-usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2720
4.3.3 Turn Fast Path off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2720
4.4 System Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2720
4.4.1 CPU Pinning for VMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2720
4.4.2 fp-cli dpdk-port-stats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2722
4.4.3 lspci . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2724
4.4.4 lstopo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2725
4.4.5 meminfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2726
4.4.6 numastat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2727
4.5 Log Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2728
4.5.1 rsyslog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2728
4.5.2 journalctl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2730
4.5.3 fast path logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2731
4.5.4 fpmd logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2732
4.5.5 cmgrd logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2732
4.5.6 OpenStack logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2733
4.6 External Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2737
4.6.1 strace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2737
1. Overview
1.1 Features
1.1.1 Routing
• GRE
• VLAN (Virtual Local Area Network) (802.1Q, QinQ)
• VXLAN
• LAG (Link Aggregation) (802.3ad, LACP)
• Ethernet Bridge
1.1.3 IP Networking
1.1.4 IPsec1
• Key Management: RSA, DH MODP groups 1 (768 bits), 2 (1024 bits), 5 (1536 bits) and 14 (2048 bits), DH
PFS
• High performance (AES-NI, QAT)
• Tunnel, Transport or BEET mode
• SVTI (Secure Virtual Tunnel Interface), DVTI
1.1.6 Security
1.1.7 QoS
1.1.8 IP Services
1.1.9 Management/Monitoring
• sFlow
1.1.10 Operations
Note: Some of these numbers (CG-NAT) are empirical. They may have to be tuned according to your use
case.
See also:
Fast path limits configuration to tune these capabilities.
• CPU: Turbo Router requires at least 2 CPU cores.
• Storage: Turbo Router requires at least 1GB of storage space; 8GB are recommended to manage several
images and store configuration and log files.
2. Getting Started
This section explains how to install, update and configure Turbo Router.
2.2 Installation
Method Flavor
Install on bare metal using USB stick img.gz
Install on bare metal using CDROM or using PXE iso
Install as a VM using KVM or using OpenStack qcow2
Install as a VM using VMware ova
Install as a VM using Proxmox VE iso
Install as a VM using AWS ami1
Update an existing installation update
After you have installed Turbo Router following one of the methods above, jump to the First configuration section.
1
Contact your customer support representative to get access to a private ami.
This chapter explains how to try Turbo Router on a physical machine, and install it, using a USB stick.
The first thing to do is to create the USB stick.
When it is done, you can either:
• Test Turbo Router without changing anything on your machine
• Install Turbo Router on a local disk
You will need a 2GB USB stick at least, and a Linux system. The data on the USB stick will be lost in the process.
We need to find which device will be associated to the USB stick in the Linux system. One way to do it is to use
lsblk.
Before plugging the USB stick, run:
Warning: Please carefully check the device associated to your USB stick, or you could wipe your local drive
in the next step.
Note: Make sure that your usb device was not auto-mounted before performing the next steps with mount -l. If
it was, use the umount command to unmount each mounted partition.
Once you know this device, you can put the turbo img.gz file on the Linux system, unzip it and put it on the USB
device.
# gunzip 6wind-vrouter-tr-ae-*.img.gz
# dd if=6wind-vrouter-tr-ae-*.img of=/dev/sdc bs=8M
Note: These two commands will take several minutes to complete. The progress of the dd command can be checked
by doing kill -USR1 $(pgrep ^dd).
You will need physical access to the machine, and a keyboard and screen attached to it to complete these steps.
Alternately, you may access the machine using its first serial port.
Once the USB stick is ready, it has to be plugged in the machine on which you want to test Turbo Router.
Warning: Please make sure that there is no other Turbo Router live CDROM or live USB inserted in this
machine. Otherwise the system might fail to boot properly.
Then, you should go in the BIOS setup, select the USB stick as first boot device, save the configuration, and reboot.
After some time, you should get an output similar to the following on screen.
+----------------------------------------------------------------------------+
|*Turbo Router - X.Y.Z |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
+----------------------------------------------------------------------------+
After 10 seconds, or if you type on the Enter key, the boot will start. You should get the following output.
vrouter login:
You are ready to test the software. Your data will persist on the USB stick.
The next step is to perform your first configuration.
Once you have tried Turbo Router, you can install it on your machine.
It can be done from the CLI, using the system-image command.
But first, you need to know on which device Turbo Router should be installed. To do so, log in as admin, password
admin, and at the prompt, do:
sda is the USB stick, which we do not want to break. It is the first detected device, and its size is small (14.4G in
our case).
sdb is the device we are looking for, it is much bigger. We will install Turbo Router on sdb in our example. The
data on sdb will be lost in the process.
Warning: Please carefully check the device associated to the disk you want to use, or you could wipe the wrong
drive in the next step.
Note: Please make sure to select this disk as boot device after installation.
Now, do:
This command will install Turbo Router on /dev/sdb. The relevant configuration files will be copied from the
USB stick to the local drive. At the end of the installation, you can reboot and remove the USB stick.
Note: To restore from a backup file, add backup-url <url> to the previous command. This will restore your
configurations, private keys, certificates and licenses.
The backup file must have been generated on the same or previous minor version (e.g. a backup from 3.0.1 can be
restored on 3.0.x or 3.1.x).
You will then get the familiar GRUB screen that you got when you were testing the software, and after some time,
the login screen.
+----------------------------------------------------------------------------+
|*Turbo Router - X.Y.Z |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
+----------------------------------------------------------------------------+
(...)
vrouter login:
This chapter explains how to try Turbo Router on a physical machine, and install it, using a CDROM drive either
physical or virtual.
If your server has a physical CD/DVD drive, you first need to burn the iso file on a blank CD or DVD. If it provides
a virtual CDROM feature, simply use the iso file as input.
When you’re done, you can either:
• Test Turbo Router without changing anything on your machine
• Install Turbo Router on a local disk
You will need physical access to the machine, and a keyboard and screen attached to it to complete these steps.
Alternately, you may access the machine using its first serial port.
Once your CDROM setup is ready, it has to be inserted in the machine on which you want to test Turbo Router.
Warning: Please make sure that there is no other Turbo Router live CDROM or live USB inserted in this
machine. Otherwise the system might fail to boot properly.
Then, you should go in the BIOS setup, select the CDROM drive as first boot device, save the configuration, and
reboot.
After some time, you should get an output similar to the following on screen.
+----------------------------------------------------------------------------+
|*Turbo Router - X.Y.Z |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
+----------------------------------------------------------------------------+
After 10 seconds, or if you type on the Enter key, the boot will start. You should get the following output.
vrouter login:
You are ready to test the software. Your data will not persist after a reboot.
The next step is to perform your first configuration.
Once you have tried Turbo Router, you can install it on your machine.
It can be done from the CLI, using the system-image command.
But first, you need to know on which device Turbo Router should be installed. To do so, log in as admin, password
admin, and at the prompt, do:
sda is the device we are looking for. We will install Turbo Router on sda in our example. The data on sda will be
lost in the process.
Warning: Please carefully check the device associated to the disk you want to use, or you could wipe the wrong
drive in the next step.
Note: Please make sure to select this disk as boot device after installation.
This command will install Turbo Router on /dev/sda. The relevant configuration files will be copied from the
CDROM drive to the local drive. At the end of the installation, you can reboot and unload the CDROM.
Note: To restore from a backup file, add backup-url <url> to the previous command. This will restore your
configurations, private keys, certificates and licenses.
The backup file must have been generated on the same or previous minor version (e.g. a backup from 3.0.1 can be
restored on 3.0.x or 3.1.x).
You will then get the familiar GRUB screen that you got when you were testing the software, and after some time,
the login screen.
+----------------------------------------------------------------------------+
|*Turbo Router - X.Y.Z |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
+----------------------------------------------------------------------------+
(...)
This chapter explains how to deploy Turbo Router on a set of physical machines via PXE and make them available
for remote access (e.g. SSH, Ansible, etc.).
The procedure relies on the Turbo Router iso file and requires a deployment infrastructure enabling PXE by pro-
viding DHCP, TFTP, DNS and HTTP services.
This section describes the installation and the configuration of the required packages on an Ubuntu 16.04 server to
provide DHCP, DNS, TFTP and HTTP services for PXE.
First, install the required packages as root:
# apt-get update
# apt-get install -y apache2 apache2-bin apache2-data apache2-utils dnsmasq \
dnsmasq-base grub-common grub-pc grub-pc-bin grub2-common
Configure the network interface that will answer DHCP requests in /etc/network/interfaces (adapt address
and netmask to your environment):
[...]
auto eth1
iface eth1 inet static
address 192.168.235.1
netmask 255.255.255.0
[...]
# ifup eth1
Then, configure dnsmasq to provide DHCP, DNS and TFTP services for your network. Edit /etc/dnsmasq.conf
with the following contents:
# vi /etc/dnsmasq.conf
# Listening interfaces
interface=eth1
# DNS configuration
bogus-priv
no-hosts
domain=pxeserver.com
# DHCP configuration
dhcp-range=192.168.235.10,192.168.235.150,12h
dhcp-host=14:18:77:66:c7:23,host1,192.168.235.13,infinite
dhcp-host=52:54:00:12:34:57,host2,192.168.235.36
dhcp-boot=boot/grub/i386-pc/core.0
# TFTP configuration
enable-tftp
tftp-root=/var/lib/tftpboot
See also:
the dnsmasq man page (http://manpages.ubuntu.com/manpages/bionic/man8/dnsmasq.8.html) for more information
about the configuration options.
Create the root directory for the TFTP server:
# grub-mknetdir --net-directory=/var/lib/tftpboot
<VirtualHost *:80>
ServerAdmin webmaster@localhost
DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
RewriteEngine On
RewriteRule ^/cloud-init/(.*) /%{REMOTE_ADDR}/$1
</VirtualHost>
# a2enmod rewrite
This section describes how to use the Turbo Router deliverables and the PXE server together to finalize the PXE
infrastructure.
First, copy the Turbo Router deliverables into the proper directories.
Kernel and filesystem of the installer:
# cp 6wind-vrouter-tr-ae-*.iso $HTTP_DIR/turbo-router.iso
Then, create the $TFTP_DIR/boot/grub/grub.cfg file that will be provided to PXE targets:
# vi /var/lib/tftpboot/boot/grub/grub.cfg
set timeout=5
menuentry 'Turbo Router network installer' {
set root='(pxe)'
set kernel_image="/vmlinuz"
set ramdisk="/initrd.img"
set boot_opts="ro rd.debug console=tty1 fsck.mode=skip"
set boot_opts="$boot_opts BOOTIF=01-$net_default_mac boot=live nonetworking␣
˓→console=ttyS0,115200n8 splash"
See also:
the GRUB documentation (https://www.gnu.org/software/grub/manual/grub/grub.html) for more information about
the configuration options.
Next, prepare per-target cloud-init configurations. The previous configuration will make targets retrieve their re-
spective cloud-init meta-data and user-data configurations from $HTTP_DIR/$CLIENT_IP, $CLIENT_IP being the
address assigned to the host by DHCP.
# mkdir $HTTP_DIR/$CLIENT_IP/
users:
- name: root
lock_password: true
ssh_authorized_keys:
- ecdsa-sha2-nistp256␣
˓→AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBNqR+NMuQUywXp5+uqSc6WSFjxLRpRZoA9b7ekBeL9F
runcmd:
- [/usr/bin/wget, 'http://192.168.235.1/cloud-init/vrouter.startup', -O, /run/vrouter.
˓→startup]
• rebooting.
˓→"
]
}
]
}
},
"vrf": [
{
"name": "main",
"vrouter-interface:interface": {
"physical": [
{
"name": "mgmt0",
"ipv4": {
"dhcp": {
"enabled": true
}
},
"port": "pci-b0s8"
}
]
},
"vrouter-ssh-server:ssh-server": {
"enabled": true,
"port": 22
}
}
]
}
(continues on next page)
You target must be configured to boot in Legacy BIOS mode (UEFI is not supported) and first on the hard drive
selected for installation.
To start the installation, configure the target to boot using PXE. For example, using an IPMI request to perform a
PXE installation on next boot only:
On reboot, the normal boot sequence of the server will boot on the freshly installed hard drive, now running Turbo
Router.
Thanks to the startup configuration, an IP address will be obtained on the first network interface and the console
will be accessible through SSH. At this step, it is possible to automate other deployment tasks, for example using
Ansible.
The next step is to perform your first configuration.
Note: Most of this chapter was written for an Ubuntu 16.04 hypervisor. There should be no technical problem
when using another distribution, only some commands might vary.
Hypervisor prerequisites
We will not detail how to install a linux distribution here. Once it is installed, some tasks must be completed to
configure the distribution into an hypervisor.
1. The kvm and kvm_intel modules have to be inserted:
or
2. On the host, create two Linux bridges, each containing one physical interface.
# cp turbo-router.qcow2 /var/lib/libvirt/images/vm1.qcow2
# virt-install --name vm1 --vcpus=3,sockets=1,cores=3,threads=1 \
--os-variant ubuntu18.04 --cpu host --network=default,model=e1000 \
--ram 8192 --noautoconsole --import \
--disk /var/lib/libvirt/images/vm1.qcow2,device=disk,bus=virtio \
--network bridge=br0,model=e1000 --network bridge=br1,model=e1000
This section details how to start Turbo Router with dedicated physical NICs.
Using dedicated NICs requires some work which is detailed in Hypervisor mandatory prerequisites.
Once the hypervisor is configured properly, two technologies are available:
• whole NICs are dedicated to Turbo Router, see Passthrough mode, simpler configuration, but only one VM
can use each NIC
• portions of NICs are dedicated to Turbo Router, see SR-IOV mode, to have more VMs (Virtual Machines)
running on the hypervisor
For production setups, you might want to consider checking Optimize performance in virtual environment to get the
best performance.
Intel VT-d stands for “Intel Virtualization Technology for Directed I/O”. It is needed to give a physical NIC to a
VM. To enable it:
• it usually has to be enabled from the BIOS. The name of this feature can differ from one hardware to the other,
we advise you to check your hardware documentation to enable it.
• it has to be enabled also in the kernel, by adding intel_iommu=on iommu=pt in the kernel command line.
To do so, run:
You can check the boot logs at next boot to verify that Intel VT-d is properly enabled.
hugepages
For performance reasons, the memory used by the VMs that will harbor Turbo Router must be reserved in hugepages.
Note: A hugepage is a page that addresses more memory than the usual 4KB. Accessing a hugepage is more
efficient than accessing a regular memory page. Its default size is 2MB.
hugeadm can be used to managed hugepages. It is part of the hugepages deb package and libhugetlbfs-utils
rpm package.
To see if your system already has hugepages available, and which sizes are supported, do:
# hugeadm --pool-list
Size Minimum Current Maximum Default
2097152 0 0 0 *
1073741824 0 0 0
1. numactl can show which memory node should be chosen for a particular interface. Look for membind in the
following command output. This NIC is on memory node 1.
cpubind: 0 1
nodebind: 0 1
membind: 1
2. Add 8 1GB hugepages for one Turbo Router VM to NUMA node 1. You should add this command to a custom
startup script to make it persistent.
# hugeadm --pool-list
Size Minimum Current Maximum Default
2097152 0 0 0 *
1073741824 8 8 8
Passthrough mode
With this configuration, the Turbo Router VM will get dedicated interfaces.
The passthrough mode is only available if the hypervisor’s hardware supports Intel VT-d, and if it is enabled (see
enable Intel VT-d).
1. You must first find the pci id of the interfaces that will be dedicated to the Turbo Router VM.
05:00.0 Ethernet controller: Intel Corporation Ethernet 10G 2P X520 Adapter (rev␣
˓→01)
05:00.1 Ethernet controller: Intel Corporation Ethernet 10G 2P X520 Adapter (rev␣
˓→01)
2. Then use virt-install to spawn the VM, specifying one host-device argument for each device that you want
to dedicate. In this example, we dedicate 03:00.0 and 03:00.1.
# cp turbo-router.qcow2 /var/lib/libvirt/images/vm1.qcow2
# virt-install --name vm1 --vcpus=3,sockets=1,cores=3,threads=1 \
--os-variant ubuntu18.04 --cpu host --network=default,model=e1000 \
--ram 8192 --noautoconsole \
--import --memorybacking hugepages=yes \
--disk /var/lib/libvirt/images/vm1.qcow2,device=disk,bus=virtio \
--host-device 03:00.0 --host-device 03:00.1
To get the best performance, the VM CPUs (Central Processing Units) should be associated to physical CPUs. This
is called pinning, and is described in CPU pinning.
The next step is to perform your first configuration.
SR-IOV mode
SR-IOV enables an Ethernet port to appear as multiple, separate, physical devices called Virtual Functions (VF).
You will need compatible hardware, and Intel VT-d configured. The traffic coming from each VF can not be seen
by the other VFs. The performance is almost as good as the performance in passthrough mode.
Being able to split an Ethernet port can increase the VM density on the hypervisor compared to passthrough mode.
In this configuration, the Turbo Router VM will get Virtual Functions.
1. First check if the network interface that you want to use supports SR-IOV and how much VFs can be config-
ured. Here we check for eno1 interface.
# lspci -vvv -s $(ethtool -i eno1 | grep bus-info | awk -F': ' '{print $2}') |␣
˓→grep SR-IOV
2. Then add VFs, and check that those VFs were created. You should add this command to a custom startup
script to make it persistent.
3. You need to set eno1 up so that VFs are properly detected in the guest VM.
4. Then use virt-install to spawn the VM, specifying one host-device argument for each VF that you want to
give. In this example, we give the VF 03:10.0 to Turbo Router.
# cp turbo-router.qcow2 /var/lib/libvirt/images/vm1.qcow2
# virt-install --name vm1 --vcpus=3,sockets=1,cores=3,threads=1 \
--os-variant ubuntu18.04 --cpu host --network=default,model=e1000 \
--ram 8192 --noautoconsole --import \
--memorybacking hugepages=yes \
--disk /var/lib/libvirt/images/vm1.qcow2,device=disk,bus=virtio \
--host-device 03:10.0
To get the best performance, the VM CPUs should be associated to physical CPUs. This is called pinning, and is
described in CPU pinning.
The next step is to perform your first configuration.
resource inventory
Before identifying the resources that will be dedicated to the Turbo Router VM, you need to know which NICs and
CPUs are available.
It can be done using lstopo, which is part of the hwloc package.
# lstopo -p --merge
Machine (31GB total)
NUMANode P#0 (16GB)
Core P#0
PU P#0
PU P#20
Core P#1
PU P#1
PU P#21
(...)
Core P#12
PU P#9
PU P#29
HostBridge P#0
PCIBridge
PCI 1000:005b
PCIBridge
PCI 15b3:1013
PCI 15b3:1013
(continues on next page)
On this machine:
• logical CPUs 0 to 9, and ens1f1, mgmt0, enp5s0f1, enp5s0f2, and enp5s0f1 interfaces use NUMA node 0
• logical CPUs 10 to 19, and the ens4f0 interface use NUMA node 1
Note: NUMA (Non-uniform memory access) is a memory design, in which a hardware resource can access local
memory faster than non-local memory. The memory is organized into several NUMA nodes.
resource dedication
Now that you identified your hardware, you can select which NICs and CPUs will be dedicated.
There are some constraints:
• we leave the first cpu for Linux
• CPUs must be taken on the same node as NICs
• crossing NUMA nodes costs performance, so all NICs should be taken on the same node
We recommend to start with a few CPUs, and increase when the setup is functional if needed. The example in this
chapter use 3 virtual CPUs.
The CPUs that will be dedicated to the Turbo Router VM need to be properly isolated from other processes. The
more reliable way to achieve this is to isolate the CPUs at boot time, on the kernel command line, using the isolcpus
and rcu_nocbs directives. For instance, adding isolcpus=1-12,29-40 rcu_nocbs=1-12,29-40 will isolate
CPUs 1 to 12 and 29 to 40. It can be added to the kernel command line by doing:
# update-grub2
# reboot
CPU pinning
After the vm is created, you can use virsh vcpupin vm1 vm-cpu cpu to do the one-to-one pinning, using the
isolated CPUs. The CPUs should be taken in the list of dedicated CPUs obtained in Identifying hardware resources.
The setup is persistent.
For instance, the next commands will pin:
• virtual CPU 0 and CPU 2,
• virtual CPU 1 and CPU 10,
• virtual CPU 2 and CPU 4
CPU configuration
# update-grub2
# reboot
2. To get better performance, the CPUs should use the performance governor. You should add this command to
a custom startup script to make it persistent.
# cpupower set -b 0
# cpupower frequency-set -g performance
For persistent configuration, the previous commands can be added to a custom startup script.
Having IRQ triggered on the CPUs that are dedicated to the Turbo Router VM can result in a few packets lost from
time to time. If you don’t notice this problem during testing, you don’t need to take care of this step.
1. To do so, first ensure that the irqbalance package is removed.
or
0-4,7 should be changed to the list of CPUs that are not dedicated to the Turbo Router VM.
For persistent configuration, the previous commands can be added to a custom startup script.
Note: The following commands may change depending on your OpenStack version. The important part are that
the image must be imported in glance, the flavor with correct size created, and that the image and the flavor are used
to start the VM. It was tested with an Ubuntu 16.04 hypervisor running the Ocata OpenStack version.
This simple configuration imports a Turbo Router qcow2 in OpenStack, creates the right flavor, and starts a Turbo
Router VM.
1. [Controller] Export the Turbo Router qcow2 file path:
# TURBO_QCOW2=/path/to/6wind-turbo-*-<arch>-<version>.qcow2
2. [Controller] Use glance to create a VM image with the Turbo Router qcow2 file:
5. [Controller] Boot the Turbo Router VM with one interface on each network:
6. Connect to the VM. This steps depends on your OpenStack installation. You should get:
(...)
____ _____ _ _ ____ ____ _
/ /\ \ / /_ _| \ | | _ \ __ _| _ \ ___ _ _| |_ ___ _ __
| '_ \ \ /\ / / | || \| | | | | \ \ / / |_) / _ \| | | | __/ _ \ '__|
| (_) \ V V / | || |\ | |_| | \ V /| _ < (_) | |_| | || __/ |
\___/ \_/\_/ |___|_| \_|____/ \_/ |_| \_\___/ \__,_|\__\___|_|
This section details how to start Turbo Router with dedicated physical NICs within OpenStack.
Using dedicated NICs requires some work on your compute node which is detailed in Hypervisor mandatory pre-
requisites.
Once the hypervisor is configured properly, two technologies are available:
• whole NICs are dedicated to Turbo Router, see Passthrough mode, simpler configuration, but only one VM
can use each NIC
• portions of NICs are dedicated to Turbo Router, see SR-IOV mode, to have more VMs running on the hyper-
visor
For production setups, you might want to consider checking Optimize performance in virtual environment to get the
best performance (except the section about CPU pinning).
The crudini package has to be installed.
See also:
For more information about:
• PCI passthrough, refer to https://docs.openstack.org/nova/pike/admin/pci-passthrough.html
• SR-IOV, refer to https://docs.openstack.org/ocata/networking-guide/config-sriov.html
• CPU pinning, refer to https://docs.openstack.org/nova/pike/admin/cpu-topologies.html
• Hugepages, refer to https://docs.openstack.org/nova/pike/admin/huge-pages.html
Passthrough mode
With this configuration, the Turbo Router VM will get dedicated interfaces.
The passthrough mode is only available if the compute node hardware supports Intel VT-d, and if it is enabled (see
enable Intel VT-d).
1. [Compute] Get the vendor and product id of the dedicated interface that you want to give to the Turbo Router
VM. In this example, for the eno1 interface, we have 8086 as vendor id and 1583 as product id. Please replace
the interface name, pci id, vendor id and product id by your own values:
# IFACE=eno1
# ethtool -i $IFACE | grep bus-info | awk '{print $2}'
0000:81:00.1
# PCI=0000:81:00.1
# lspci -n -s $PCI | awk '{print $3}'
8086:1583
# VENDOR_ID=8086
# PRODUCT_ID=1583
2. [Compute] Configure a PCI device alias. It will identify the vendor_id and product_id found in first step with
the a1 alias in the next steps.
3. [Compute] Tell which PCI device can be given to VMs. Here we give the PCI device 0000:81:00.1:
Note: It is possible to add more PCI devices here, by giving a list to crudini (i.e: ‘[{ “address”: “pci1” },
{ “address”: “pci2” }]’) in the previous command.
4. [Controller] Export the previously configured variables, as well as the Turbo Router qcow2 file path:
# TURBO_QCOW2=/path/to/6wind-turbo-*-<arch>-<version>.qcow2
# IFACE=eno1
# PCI=0000:81:00.1
# VENDOR_ID=8086
# PRODUCT_ID=1583
5. [Controller] Configure nova-scheduler to activate the PciPassthroughFilter. Note that if you have en-
abled filters already, you should just add PciPassthroughFilter to your list:
˓→ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter,PciPassthroughFilter'
6. [Controller] Configure a PCI device alias. It will identify the vendor_id and product_id found in first step
with the a1 alias:
7. [Controller] Use glance to create a VM image with the Turbo Router qcow2 file:
10. [Controller] Configure the flavor to use one NUMA node and the same hyperthreads, and enable hugepages
to get deterministic performances. OpenStack will choose CPUs and memory on the same NUMA node as
the NICs:
SR-IOV mode
SR-IOV enables an Ethernet port to appear as multiple, separate, physical devices called Virtual Functions (VF).
You will need compatible hardware, and Intel VT-d configured. The traffic coming from each VF can not be seen
by the other VFs. The performance is almost as good as the performance in passthrough mode.
Being able to split an Ethernet port can increase the VM density on the hypervisor compared to passthrough mode.
In this configuration, the Turbo Router VM will get Virtual Functions (VFs).
See also:
For more information about SR-IOV, more advanced configurations, interconnecting physical and virtual networks,
please check your OpenStack documentation: https://docs.openstack.org/ocata/networking-guide/config-sriov.html
1. [Compute] First check if the network interface that you want to use supports SR-IOV and how much VFs can
be configured. Here we check for eno1 interface. Please export your own interface name instead of eno1.
# IFACE=eno1
# lspci -vvv -s $(ethtool -i $IFACE | grep bus-info | awk -F': ' '{print $2}') |␣
˓→grep SR-IOV
2. [Compute] Add VFs, and check that those VFs were created. You should add this command to a custom
startup script to make it persistent. Please export your own vf pci id instead of 81:0a.0.
# VF_PCI=0000:81:0a.0
3. [Compute] Get the vendor and product id of the dedicated VF that you want to give to the Turbo Router VM.
In this example, for the 81:0a.0 VF, we have 8086 as vendor id and 154c as product id. Let’s export the two
variables VENDOR_ID and PRODUCT_ID for further use:
4. [Compute] You need to set eno1 up so that VFs are properly detected in the guest VM.
6. [Compute] Configure a PCI device alias. It will identify the vendor_id and product_id found in first step with
the a1 alias. Also tell which PCI device can be given to VMs. Here we give all the VFs configured on eno1:
7. [Compute] Tell which PCI device can be given to VMs. Here we give all the VFs configured on eno1:
8. [Controller] Export the previously configured variables, as well as the Turbo Router qcow2 file path:
# TURBO_QCOW2=/path/to/6wind-turbo-*-<arch>-<version>.qcow2
# IFACE=eno1
# VENDOR_ID=8086
# PRODUCT_ID=154c
9. [Controller] Configure nova-scheduler to activate the PciPassthroughFilter. Note that if you have en-
abled filters already, you should just add PciPassthroughFilter to your list:
˓→ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter,PciPassthroughFilter'
10. [Controller] Configure a PCI device alias. It will identify the vendor_id and product_id found in first step
with the a1 alias:
11. [Controller] Use glance to create a VM image with the Turbo Router qcow2 file:
12. [Controller] Create a flavor with 8192MB of memory and 4 virtual CPUs.
13. [Controller] Configure the flavor to request 1 pci device in alias a1:
14. [Controller] Configure the flavor to use one NUMA node and the same hyperthreads, and enable hugepages
to get deterministic performances. OpenStack will choose CPUs and memory on the same NUMA node as
the NICs:
Turbo Router is provided in the form of an OVA (Open Virtualization Appliance) file. It is supported on:
• ESX/ESXi 5.5 and later
• vCenter Server 5.5 and later
• Fusion 6.x
• Workstation 10.x
• Player 6.x
See also:
Refer to this link (https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2007
and that one (https://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalI
for compatibility. Turbo Router’s hardware version is 10.
The image is configured to run with:
• 4 cores
• 8GB RAM
• 1 vmxnet3 NIC
If you wish to add other NICs, make sure they have the vmxnet3 virtualDev attribute, or Turbo Router will not
be able to use them.
In order to boot your Turbo Router VM, import the OVA file in your VMware product.
The next step is to perform your first configuration.
See also:
Refer to VMware documentation for details on how to deploy VM images. For instance De-
ploying using vSphere 6.5, ESXi 6.5 or vCenter Server 6.5 (https://docs.vmware.com/en/VMware-
vSphere/6.5/com.vmware.vsphere.vm_admin.doc/GUID-AFEDC48B-C96F-4088-9C1F-4F0A30E965DE.html)
Since ESXi 6.5, new tuning options are available to improve hypervisor’s performance. Before going further, all
the settings described in the previous section must be applied.
In the VM Options tab, Advanced part of the VM settings, press the Configuration Parameters button to
set:
• ethernetX.ctxPerDev to 1 (where ethernetX is the NIC which will be handled by the Turbo Router):
each NIC configured with ctxPerDev will receive a TX thread in the hypervisor. It can be checked in the
esxtop output. The ctxPerDev recommendation must be enabled for NICs that are expected to process an
high packet load.
• sched.cpu.latencySensitivity.sysContexts to numerical value: system threads (TX and
RX) are assigned exclusive physical CPU cores. The numerical value assigned to sched.cpu.
latencySensitivity.sysContexts must equal the number of active threads for the VNF. For example,
if one receive thread exists and three TX threads have been set using the ctxPerDev command, the value set
must be 4. In this example, 4 physical CPU cores must be available and unreserved.
More details are available in VMware document regarding high performance setups
(https://www.vmware.com/techpapers/2017/tuning-vmware-vcloud-nfv-for-data-plane-intensive-workloads.html).
esxtop reading
4:53:33pm up 12 days 8:06, 654 worlds, 2 VMs, 5 vCPUs; CPU load average: 0.24, 0.05,␣
˓→ 0.02
PCPU USED(%): 0.0 0.4 0.0 0.2 2.9 0.1 0.1 1.6 0.1 0.0 118 0.0 0.0 0.0 0.1 0.0 0.0 0.2␣
˓→112 0.0 0.1 1.7 0.0 0.2 AVG: 9.9
PCPU UTIL(%): 0.1 100 0.1 0.3 2.5 0.1 0.2 1.5 0.1 0.1 100 0.1 0.1 0.1 0.1 0.1 0.1 0.2␣
˓→100 0.1 0.2 1.6 0.1 0.3 AVG: 12
CORE UTIL(%): 100 0.3 2.6 1.6 0.2 100 0.2 0.2 0.3 ␣
˓→100 1.7 0.2 AVG: 25
Threads (including ctxPerDev) threads can be displayed by hitting ‘e’, with the GID number of the process. You
can check here the number of threads created for the VM, and their current load:
4:55:29pm up 12 days 8:08, 654 worlds, 2 VMs, 5 vCPUs; CPU load average: 0.26, 0.15,␣
˓→ 0.05
PCPU USED(%): 0.0 0.4 0.0 0.0 2.3 0.0 0.1 0.2 0.2 0.0 113 0.0 0.0 2.2 0.0 0.0 0.0 2.7␣
˓→118 0.0 0.0 0.0 0.0 0.1 AVG: 10
PCPU UTIL(%): 0.1 100 0.1 0.1 2.2 0.1 0.1 0.3 0.2 0.1 100 0.1 0.1 2.0 0.1 0.1 0.1 2.4␣
˓→100 0.1 0.1 0.1 0.1 0.1 AVG: 12 (continues on next page)
The network screen (accessible by hitting ‘n’) is really useful to check if the hypervisor is dropping packets:
5:00:32pm up 12 days 8:13, 649 worlds, 2 VMs, 5 vCPUs; CPU load average: 0.26, 0.26,␣
˓→0.14
The column details can be checked in the esxtop statistics reading guide
(https://communities.vmware.com/docs/DOC-9279).
This chapter explains how to start a Turbo Router VM using Proxmox VE and the .iso file.
It expects that you already installed a Proxmox VE cluster, in which you are able to spawn VMs with network
connected.
It follows the following steps:
• make the .iso file available to Proxmox VE
• create and configure a VM
• boot the VM using the .iso file
• install Turbo Router on the virtual disk
Select the local storage of your node in the left pane and visualize its content:
Press the Upload button. In the pop-up window, select ISO image as content type and point to the Turbo Router
.iso file on your local disk. Then press Upload to send this file to your Proxmox VE node:
In the top right corner, press the Create VM button to launch the creation wizard. In General tab, check the node
and the VM ID, and give a name to the VM, then press Next:
In OS tab, make sure to use the uploaded .iso file as CD/DVD and to specify a Linux with 4.X/3.X/2.X kernel as
Guest OS, then press Next:
In Hard Disk tab, keep the default qcow2 device with VirtIO SCSI storage and allocate at least 10GB, then press
Next:
In CPU tab, allocate at least 2 cores and select host as CPU type, then press Next:
In Network tab, bind the virtual management interface to a host bridge in order to have access to external network.
Select VirtIO as model type, then press Next:
In Confirm tab, review your settings and press Finish to finalize the creation and get back to the main dashboard:
The VM is now available in the left pane below your physical node. Select it and review its hardware configuration:
In the pop-up window, select an attachment bridge and choose VirtIO as model, then press Add:
The second network device can now be seen in the hardware configuration of the VM:
Warning: Please make sure that there is no other Turbo Router live CDROM or live USB inserted in this VM.
Otherwise the system might fail to boot properly.
Press Start in the top right corner to actually start the VM.
The next step consists in installing on the virtual disk.
Warning: Please carefully check the device associated to the disk you want to use, or you could wipe the wrong
drive in the next step. When following this installation guide you have only one disk attached to the VM. Thus
the device name is sda. If you attach additional virtual disks, make sure to choose the right device.
Note: Please make sure to select this disk as boot device after installation. You can access boot menu by pressing
ESC at startup in the VM console.
Once the VM has booted on the .iso file, select it in the left pane of the main dashboard and press the >_ Console
button to get access to the serial console.
Log in as admin, password admin, and at the prompt, do:
This command will install Turbo Router on /dev/sda. The relevant configuration files will be copied to the local
drive.
Note: To restore from a backup file, add backup-url <url> to the previous command. This will restore your
configurations, private keys, certificates and licenses.
The backup file must have been generated on the same or previous minor version (e.g. a backup from 3.0.1 can be
restored on 3.0.x or 3.1.x).
Reboot to finally boot Turbo Router from the virtual hard disk:
The Turbo Router private AMI image provides a simple way to deploy Turbo Router in AWS. Access to the AMI
image must be requested to the 6WIND support team through the customer zone.
Once access is granted, the Turbo Router AMI will be available in the AWS management console when selecting
AMIs > Private Images.
Select the Turbo AMI in My AMIs > Ownership > Shared with me.
This AMI requires either Intel 82599 VF adapters or ENA adapters. Please make sure to select an in-
stance type (https://aws.amazon.com/premiumsupport/knowledge-center/enable-configure-enhanced-networking/)
that supports these adapters.
In AWS, console access is provided through the network and relies on cloud-init. cloud-init configuration must be
provided in Advanced Details > User data.
In the following example, we pre-install the license file (make sure you replace the contents by your own). We also
upload a startup configuration for the CLI.
This sample CLI configuration fulfills the minimal requirements to start Turbo Router with high performance. It
consists in enabling DHCP on the first network interface, dedicating that interface to the fast path (The fast path
is the |turbo| component in charge of packet processing.) and enabling VLAN stripping.
#cloud-config
write_files:
- path: /run/vrouter.startup
content: |
{
"vrouter:config": {
"vrouter-system:system": {
"vrouter-license:license": {
"online": {
"serial": "xxx"
}
(continues on next page)
By default, AWS forbids IP forwarding. It must be enabled from the management console after the instance is
launched as follows.
Prerequisites
• Update between maintenance versions within the same minor version is supported.
• Update between consecutive minor versions is supported.
• Update between major versions requires a fresh install.
• Update between inconsecutive minor versions requires to update in several steps between consecutive minor
versions.
• Downgrade is not supported.
Examples:
Update To Supported
from
3.0.1 3.0.5 Yes
3.0.5 3.1.0 Yes
2.2.6 3.0.0 No; backup your configurations, install from scratch and restore your configurations
3.0.5 3.2.0 No; update to the latest 3.1.x, then from 3.1.x to 3.2.0.
3.0.0 2.2.6 No; install from scratch. Configuration backup/restore is not supported when downgrad-
ing.
If you are updating from Turbo Router 2.x, make sure that you update to the latest 2.x version first. Refer to Turbo
Router 2.x documentation.
1. Before updating to a new revision, ensure that you are not using a deprecated API, at least in the startup
configuration:
Note: Any use of deprecated or obsolete API should be fixed. It is advised to also check the saved configu-
rations.
Warning: The backup file contains sensitive data, like private keys. Make sure to keep it private.
See also:
The command reference for details.
If you are updating from Turbo Router 2.x, move to the installation section. Else, move to the next section.
See also:
The user guide and command reference for details.
API deprecation
When the API changes between Turbo Router versions, the new API coexists with the previous one, which is pro-
gressively deprecated, obsoleted and removed, as follows:
GA API state
ver-
sion
N API v1 is valid and fully supported.
N+1 API v2 is introduced; API v1 is deprecated and this is reported at update and when editing the config-
uration in the CLI. Both APIs are supported; switching to v2 is recommended.
N+2 API v1 is obsolete. It can still be loaded and displayed in the CLI, but it is ineffective. API v1 is not
supported; switching to v2 is required.
N+3 API v1 is removed and cannot be used.
login: admin
Password: admin
vrouter>
Warning: For security reasons, it is recommended to change the default passwords of preconfigured users.
See Changing Passwords for more information about user accounts.
If not done during the installation, you can restore the configurations, private keys, certificates and licenses from a
backup file.
The backup file must have been generated on the same or previous minor version (e.g. a backup from 3.0.1 can be
restored on 3.0.x or 3.1.x).
To import a backup file:
See also:
The command reference for details.
Turbo Router includes a Day-1 configuration mechanism that starts a DHCP client on the first interface and enables
a SSH server on it, so that the user can remotely access the console.
1. Check the VRF main state:
Here, we see that the ens3 interface in the main VRF is configured with an IP address and that SSH is enabled.
You can jump to Configuring the fast path. If the automatic Day-1 configuration doesn’t match your needs, you can
perform manual Day-1 configuration:
To configure an address on the management interface and enable SSH from the CLI, proceed as follows:
1. Start to edit the running configuration:
2. Create an interface named eth0 on top of the pci-b0s3 port, in the main vrf:
Note: use show state / network-port to see the list of available network ports with PCI ids; it can help
choosing the right management port.
4. Check that the system state for the new interface is correct:
Now the equipement can be accessed via a remote SSH client at address 192.168.0.2.
7. To make this configuration applied at each startup, make it the startup configuration:
To configure an address, a default route via DHCP on the management interface, a DNS and enable SSH from the
CLI, proceed as follows:
1. Start to edit the running configuration:
2. Create an interface named eth0 on top of the pci-b0s3 port, in the main vrf:
Note: use show state / network-port to see the list of available network ports with PCI ids; it can help
choosing the right management port.
4. Check that the system state for the new interface is correct:
Now the equipement can be accessed via a remote SSH client using the address acquired by DHCP (in our
case 10.0.2.15).
7. To make this configuration applied at each startup, make it the startup configuration:
A license key is required to unlock Turbo Router features and capacities. Refer to the User Guide for detailed
information about the Turbo Router licensing mechanisms.
Online license
The standard online license requires DNS and internet access and is configured as follows, using the serial number
provided with the software delivery:
Note: It is required to exit edit mode to take license activation into account.
Note: If your configuration relies on a feature enabled by license (BGP, IPsec) to reach the license key server and
you have not obtained a valid license yet, you are facing a catch-22 (https://en.wikipedia.org/wiki/Catch-22_(logic))
issue. You’ll need to perform a simple Day-1 configuration using static routing to install your license key first, and
then you’ll be able to move forward with a more complex configuration.
Some specific licenses can be activated offline, through a webpage on the Licensing End-User Portal.
First, request an activation certificate on the machine that will use the license token.
Note: The license certificate request commands can only be run when the license is disabled in configuration.
Then login to the Licensing End-User Portal using the credential received from 6WIND support team, go to the
Offline Activation tab, copy paste the certificate obtained at the previous step, and click on Activate.
Note: A license token can be freed using cmd license certificate request-deactivation serial
<serial>, copy paste the obtained certificate to the Licensing End-User Portal, and click on Deactivate.
The next step is to import this new certificate back on the machine that will use the license token.
OK.
Note: The import command accepts other url types, like ftp and http. The file contents can be directly pasted on
the console too. Run cmd license certificate import <?> for a complete list.
Note: It is required to exit edit mode to take license activation into account.
Offline license
In some cases, an offline license file can be provided in addition to your serial number. It must be imported before
entering the serial number, as follows:
Note: It is required to exit edit mode to take license activation into account.
Note: The import command accepts other url types, like ftp and http. The file contents can be directly pasted on
the console too. Run cmd license file import <?> for a complete list.
You will want to look for the following output to confirm that your license key is active and valid:
• Active perpetual license for Turbo Router
• Connected to license server ...
• Lease is valid until ...
• License was activated online
In case of doubt, jump to the next section to learn how to check the license service logs.
The state of the license can also be retrieved using show state / system license.
The fast path is the Turbo Router component in charge of packet processing. To accelerate ethernet NICs, they must
be dedicated to the fast path, and the fast path must be started.
1. Dedicate ports to the fast path and start it:
Note: use show state / network-port to see the list of available network ports with PCI ids; it can help
choosing the right ports.
2. Check that the fast path has been started (it can take some time):
Now that the fast path has been started and some ports have been dedicated to it, we can start the networking
configuration.
Let’s create the the dp0 and dp1 interfaces in the main VRF and associate them to these two ports. The 1.0.0.1/24
address will be added to dp0, and 2.0.0.1/24 address will be added to dp1.
If you installed Turbo Router as a new Linux system, it includes a Day-1 configuration mechanism that starts a
DHCP client on the first interface and enables a SSH server on it, so that the user can remotely access the console.
This mechanism relies on cloud-init and can be customized as described in the following sections.
Cloud-init
Cloud-init is the defacto multi-distribution package that handles early initialization of a cloud instance. Using cloud-
init, it is possible to preconfigure Turbo Router.
See also:
For more information about Cloud-init, refer to https://cloudinit.readthedocs.io/en/latest/
Customizing the Turbo Router configuration files is possible only at first boot. The turbo service is started sooner
in the next boots, before cloud-init.
Libvirt
The simpler way of using cloud-init with libvirt is to create an iso file labelled cidata.
See also:
For more information, refer to https://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html
1. Write a user-data file and a meta-data file. In this example, we setup the root password.
2. Build an iso image with the cidata label containing the user-data and meta-data and put it in the libvirt
images directory.
3. Add seed.iso as a disk to the virt-install command. For instance, for a VM with virtual NICs.
OpenStack
Examples
Here is a user-data example, where we upload a startup configuration for the CLI (you can also upload alternative
configurations).
#cloud-config
write_files:
- path: /run/vrouter.startup
content: |
{
"vrouter:config": {
"vrf": [
{
"name": "main",
"vrouter-interface:interface": {
"physical": [
{
"name": "pub1",
"port": "pci-b0s5",
"ipv4": {
"dhcp": {
"enabled": true
}
}
}
]
}
}
],
"vrouter-system:system": {
"vrouter-fast-path:fast-path": {
"port": [
"pci-b0s5"
]
},
"vrouter-license:license": {
"online": {
"serial": "xxx"
}
}
(continues on next page)
3. User Guide
6WIND command line interface (CLI) is the user interface to interact with a device running 6WIND vRouter. It
can be used to configure, monitor and troubleshoot the router.
The CLI is a NETCONF client, following a data model described in YANG. The command names and statements
follow the syntax and the hierarchical organization of the vRouter YANG models.
A NETCONF API can be used as well from any other NETCONF clients to configure and monitor the router
remotely.
About NETCONF
NETCONF is a network management protocol standardized by the IETF. It defines mechanisms to install, manip-
ulate and delete the configuration of network devices. It uses Extensible Markup Language (XML)-based data
encoding for the configuration data as well as the protocol messages. More information is available in RFC 6241
at https://tools.ietf.org/html/rfc6241
About YANG
YANG is a language used to model data for the NETCONF protocol. A YANG module defines a hierarchy of
data that can be used for NETCONF-based operations, including configuration, state data, Remote Procedure
Calls (RPCs), and notifications for network management protocols. More information is available in RFC 7950
https://tools.ietf.org/html/rfc7950
3.1.1 Preface
Conventions
Convention Description
literal CLI keywords.
<value> CLI arguments for which the user is supposed to supply values.
UPPERCASE A keyboard key or combination.
[X] Square brackets indicate optional elements.
X|Y A pipe indicates a logical or (exclusive).
Definitions
Mode A mode is an environment providing a list of CLI commands. The operational mode mostly provides com-
mands to display state, while the edition mode provides commands to modify the device configuration.
Context A context is an environment of the edition mode in which parameters can be configured or displayed.
Some CLI commands are relevant to a context.
Configuration A configuration describes a coherent programming of the device, represented in a tree.
Staging Configuration The staging configuration is the one currently beeing modified locally in the CLI, and not
yet active on the device.
Running Configuration The running configuration is the one currently active on the device.
Startup Configuration The startup configuration is the one that will be loaded at the next reboot.
Configuration File A configuration file is used to transfer a configuration to or from a remote machine for editing
or backup purposes.
• Command line
• NETCONF API
• Clear separation between configuration and state data
• Multiple logical VRF
• Compatibility with Day-1 configuration
Command line
The CLI comes with traditional features, such as completion, history and contextual help. It relies on a YANG data
model that users browse as they would browse a file system, for example, / jumps to the root of the configuration,
.. moves one level up. Relative and absolute paths can be used to refer to configuration data, making browsing very
efficient.
NETCONF API
The management system embeds a NETCONF server which can be configured to accept external connections from
a NETCONF client. It supports all the required protocol operations to read and write the configuration: <get>,
<get-config>, <edit-config>, <copy-config> and so on.
The CLI is actually a client that connects locally to this NETCONF server.
At the root of the data model, there are two trees: config and state. The items in config represent the target
configuration, while the ones in state represent the actual state of the system. As a result, state generally includes
the items in config, plus additional runtime information, such as the statistics, or the IP addresses obtained through
DHCP for example.
The management system splits the device into VRFs. Each VRF has its own set of IP addresses, routing tables,
firewall rules, and other network-related resources. The configuration of most networking services occurs inside a
VRF context. The default VRF is called main.
VRFs rely on the Linux network namespaces feature (netns). This kind of container may be used in future releases
to define limits in term of CPU resource or memory.
Cloud-init is embedded in the vRouter for Day-1 configuration, that is, the initial configuration of the vRouter to
enable basic console access. By default, cloud-init starts a DHCP client on the first interface and enables a SSH
server on it. It can be customized to configure a specific interface, use a static IP address, create users, provision
SSH keys, etc.
The management engine is compatible with cloud-init Day-1 configuration, as it does not touch the network services
(SSH, DNS, DHCP, etc.) as long as there is no configuration statement for them. When a configuration statement
is present, it takes precedence over any existing configuration coming from cloud-init. Finally, a known service like
SSH will be recognized and will not be restarted if it is not necessary.
3.1.3 Basics
Overview
The CLI is used to configure the device and monitor its state. The CLI exposes two main modes:
• The operational mode (prompt is hostname>), where the user can query the state, show the configuration,
send commands, etc. . .
• The edition mode (prompt ends with #), where the user can additionally modify the configuration of the device.
This mode is divided into several service contexts, each of them representing a part of the configuration.
At any level in the CLI, if you type a question mark (?), a list of available commands and a short help is displayed.
The CLI connects to the device using the NETCONF protocol. The contexts commands are generated from YANG
files, which also describes the NETCONF API of the device.
Here is a summary of available commands from the CLI prompt:
The CLI stores the history of typed commands in a circular memory. Typed commands can be recalled with the
UP/DOWN keys and may be modified with LEFT/RIGHT/INS/DEL keys.
Output modifiers
The cli commands can be suffixed by output modifiers to change the output of the command. The syntax is quite
similar to shell pipes.
The pager can be disabled for a specific command with:
vrouter> show state fullpath | match 'interface physical' | match 'mtu 1500' count
3
login: admin
Password: admin
vrouter>
Warning: For security reasons, it is recommended to change the default passwords of preconfigured users.
See Changing Passwords for more information about user accounts.
Getting help
The CLI provides a comprehensive help system, which can be invoked in different ways.
The command help displays a context-sensitive list of available commands. In edition mode, the general commands
are displayed first, followed by the context specific commands.
.. Go to parent.
/ Go to root.
description A textual description of the interface.
enabled The desired (administrative) state of the interface.
ethernet Top-level container for Ethernet configuration.
ipv4 Parameters for the IPv4 address family.
ipv6 Parameters for the IPv6 address family.
mtu Set the max transmission unit size in octets.
port Reference to a physical network port.
The help command is also used to display a more detailed help of a command:
== show ==
Show configuration or system state.
show config:
Show the configuration.
In edition mode, display the staging configuration.
In operational mode, display the running configuration.
(continues on next page)
The context-sensitive help can be requested at any time by entering a question mark ?. It displays a list of available
options:
Operational mode
When connecting to the CLI, it starts in operational mode, identified by the following prompt:
vrouter>
Show configuration
The show config command is used to display the configuration. In operational mode, it shows the running con-
figuration by default.
The syntax of the command is: show config [running|startup|(file <file>)] [text|xml|json]
[all|nodefault] [relative|absolute] [fullpath|nopath] [<path...>]
The default output format is text:
The output format can be customized. See the Edition Mode section for details.
Show state
The show state command is used to display the current state of the device. The arguments and the output of the
command are similar to the show config command.
The syntax of the command is show state [text|xml|json] [all|nodefault]
[relative|absolute|fullpath] [<path...>].
Example of use:
Diff configurations
The diff command shows the differences between two configurations. The syntax is the same as in edition mode,
except that the configurations to be diffed must always be specified.
See the Edition Mode section for details.
fast-path disabled
linux 3 cores, memory total 0.96GB available 0.09GB
network-port 1 port detected
vrf 1 configured
auth 2 users
cloud-init enabled
dhcp client enabled in vrf main
dns enabled in vrf main
ssh-server enabled in vrf main
The CLI is able to query the state of the device. What is called state is the current operational state of the system,
in contrast to config which contains the administrative desired state.
This operation is invoked with the show state CLI command, which is available from the operation mode and
from the edition mode.
Show all the state of the device in text format:
In edition mode, the displayed state corresponds to the service context being edited.
Show the interfaces of the device in text format:
By default, the output is in text format. But it can also be displayed in xml or json.
The edition model is transactional. The running configuration is first fetched locally. This local copy, called staging
configuration, can be modified locally, then committed. The running configuration can be set as startup configura-
tion.
edit running
Fetch running configuration
in staging.
commit
Apply changes made in staging
into the running configuration.
A ! can also be displayed at the end of the prompt when the staging configuration is invalid regarding the constraints
defined in the YANG model. The validate command can then be used to check what is invalid in the configuration:
Edition mode
The configuration is organized hierarchically. All configuration is available under the config node.
config/
system
auth
fast-path
...
vrf
dns
interface
...
To enter into a context, type its name, followed by the key in case of a list.
Note: The CLI commands are generated from YANG files, which also specifies the NETCONF API of the device.
A CLI context corresponds to a container or a list statement in the YANG file.
To set the value of a leaf, type its name and its value:
Several leaves can be set in one command, achieving the same result:
Finally, it is possible to set the value of leaves that are in a different path. In that case, specify the path, followed by
the leaves and their values. Note that the current directory remains unchanged.
vrouter running config# vrf main interface physical eth0 mtu 1500 port pci-b0s4
vrouter running config#
Note: The CLI commands are generated from YANG files, which also specifies the NETCONF API of the device.
A CLI configuration leaf corresponds to a leaf or a leaflist statement in the YANG file.
A configuration node (either a leaf or a context) can be deleted with the command del, followed by the path of the
node:
Some commands need to have a more complex syntax, because a couple name/value is not sufficient. In this case,
the CLI behavior is customized with extensions in the YANG files.
Particularly, a YANG container or list can be used to define oneliner commands. For example, the interface IP
neighbor context uses an extension to have a specific syntax:
The following example shows that it does not follow the same syntax than the simple case described above. Each
neighbor is identified by its key, and the argument attached to the neighbor is mandatory. To delete a neighbor, only
the key is needed.
Show configuration
The show config command is used to display the configuration. In edition mode, it shows the staging configuration
by default, relative to the current path.
The syntax of the command is: show config [staging|running|startup|(file <file>)]
[text|xml|json] [all|nodefault] [relative|absolute] [fullpath|nopath] [<path...>]
Note: show config (show the configuration) should not be confused with show state (get the operational state).
The configuration nodes set to the default value can be stripped from the configuration with nodefault (in this
example port set to 22 and enabled set to true are not displayed):
A path can be specified, which can be absolute, or relative to the current path:
The configuration root path can be relative (default), or absolute. If absolute is specified, all the parent containers
are displayed, but the configuration that is not in the specified path is stripped. This example demonstrates the
feature:
When the configuration is displayed in a text format, the full path can be prepended to each node. This eases
copy/paste, or filtering using the match output filter:
The show config command is also available from the operational mode. In this case, the running configuration is
displayed by default as there is no staging configuration.
Show state
The show state command is used to display the current state of the device. The arguments and the output of the
command are similar to the show config command.
The syntax of the command is show state [text|xml|json] [all|nodefault]
[relative|absolute|fullpath] [<path...>].
Without path argument, the displayed state depends on the current location in the configuration. At root, it displays
all the state:
When called from an interface context, only the state of this interface is displayed:
Like in the show config command, the path and the output format can be specified.
Diff configurations
The diff command shows the differences between two configurations. Additions are prefixed by a + and deletions
by a -. All lines changed in the same directory are prefixed by a title line starting with ===.
Without argument, it displays the differences between the origin configuration and the staging configuration in the
current directory: in other words, it shows the uncommitted user changes.
If the fullpath argument is passed, each line is expressed with an absolute path:
Once you are satisfied with your changes in the staging configuration, you can apply the changes by committing the
configuration. This operation copies the content of the staging configuration into the running configuration.
Note: After a call to commit, the running configuration is updated immediately. In contrast, the state of the system
can take some time to change, depending on the configuration.
Exiting the edition mode cancels the changes done in the staging configuration.
The startup configuration is the configuration applied when the device boots. It can be copied from the running
configuration, using the following command:
Save a configuration
In edition mode, the save command can export the staging configuration in a xml file.
Load a configuration
In edition mode, the load command sets the staging configuration from a previously saved configuration file.
The staging configuration can also be set to the startup configuration with the following command:
To be certain that the startup configuration is a valid one, only the running configuration can be copied to startup.
3.1.4 System
License
Overview
License key
A license key is required to unlock Turbo Router features and capacities, according to the purchased licenses.
A single license key is used to enable a set of features and capacities. You should have received you license key at
time of software delivery. You can retrieve your license key from the Licensing End-User Portal accessible on the
6WIND Customer Zone, or request it by filing a ticket on the 6WIND Customer Zone.
The license key must first be configured and activated on Turbo Router. This is done through a connection to the
license key server (and therefore requires the DNS and an internet route to be configured). Activating a license key
consumes an activation on the license key server. The license is valid if it is enabled on the license key server and
has enough activations left.
The license key is valid for 30 days. A health check mechanism regularly and automatically checks the license key
validity with the license server. A successful health check resets the validity period for 30 more days.
Note: During activation or health check, the following information is sent to the license server: the instance’s IP
address and geolocalization, Turbo Router information (OS, version, build) and machine information (CPU, memory,
hostname).
Note: Some specific licenses can be activated offline, through the Licensing End-User Portal accessible on the
6WIND Customer Zone. In this case the license can be activated/deactivated through a webpage, and does not
require a connection between the Turbo Router and the license server.
Note: In some cases, offline licenses may be provided, which are permanently activated and do not require a
connection to the license server.
When the license key is removed from the configuration or deactivated on the server, it becomes invalid on the
vRouter1 . The features and capacities will be restricted.
The license key has a maintenance end date associated, which corresponds to the end of the maintenance period
after the first delivery of Turbo Router. The maintenance end date is updated when the maintenance agreement is
renewed. The license key is not valid for releases of Turbo Router released after the maintenance end date.
1
The license key becomes invalid either right away when removed from the configuration, or at next health check when deactivated on
the server.
Online license
The standard online license requires DNS and internet access and is configured as follows, using the serial number
provided with the software delivery:
Note: It is required to exit edit mode to take license activation into account.
Note: If your configuration relies on a feature enabled by license (BGP, IPsec) to reach the license key server and
you have not obtained a valid license yet, you are facing a catch-22 (https://en.wikipedia.org/wiki/Catch-22_(logic))
issue. You’ll need to perform a simple Day-1 configuration using static routing to install your license key first, and
then you’ll be able to move forward with a more complex configuration.
Some specific licenses can be activated offline, through a webpage on the Licensing End-User Portal.
First, request an activation certificate on the machine that will use the license token.
Note: The license certificate request commands can only be run when the license is disabled in configuration.
Then login to the Licensing End-User Portal using the credential received from 6WIND support team, go to the
Offline Activation tab, copy paste the certificate obtained at the previous step, and click on Activate.
Note: A license token can be freed using cmd license certificate request-deactivation serial
<serial>, copy paste the obtained certificate to the Licensing End-User Portal, and click on Deactivate.
The next step is to import this new certificate back on the machine that will use the license token.
OK.
Note: The import command accepts other url types, like ftp and http. The file contents can be directly pasted on
the console too. Run cmd license certificate import <?> for a complete list.
Note: It is required to exit edit mode to take license activation into account.
Offline license
In some cases, an offline license file can be provided in addition to your serial number. It must be imported before
entering the serial number, as follows:
Note: It is required to exit edit mode to take license activation into account.
Note: The import command accepts other url types, like ftp and http. The file contents can be directly pasted on
the console too. Run cmd license file import <?> for a complete list.
You will want to look for the following output to confirm that your license key is active and valid:
• Active perpetual license for Turbo Router
• Connected to license server ...
• Lease is valid until ...
• License was activated online
In case of doubt, jump to the next section to learn how to check the license service logs.
The state of the license can also be retrieved using show state / system license.
Nominal case
The show log service license provides the licensing logs, including license activation and health check de-
tails.
In the nominal case, license key activation success is indicated by the following messages:
The following messages indicates that the licensing server could not be reached.
(...)
(...)
(...)
(...)
(...)
When the license key is replaced by a new one and activation fails, the previous license key remains valid until it
expires. This is to prevent interruption of service in case of configuration mistake or temporary connection issue.
After the new license key is successfully activated, the previous one is discarded.
However, activation may succeed but the resulting license key be invalid, for example if the key has been disabled
on the server or has no activations left. In that case, the license will be discarded and the features and capacities
will be restricted. It may be necessary to perform Day-1 configuration again to setup a valid license.
Licensing usage report is automatically provided to the licensing server upon license activation and health check. It
is also included in the troubleshooting report.
The license usage report includes the following information:
• average network throughput (measured in Rx)
• average and current number of IPsec tunnels
• average and current number of CG-NAT connections
The Licensing End-User Portal is accessible through the 6WIND Customer Zone. Your credentials should have
been provided by the Customer Support Team when purchasing the Turbo Router software.
The Licensing End-User Portal allows to:
• review your license keys,
• check the number of instances activated for a license key,
• check the number of remaining activations for a license key,
• delete an activated instance (in case of crash for example),
• activate and deactivate a license offline,
• manage your licensing user portal accounts.
Users
Overview
Warning: For security reasons, it is recommended to change the default passwords of preconfigured users.
See Changing Passwords.
Two default users are created when booting the system for the first time: admin and viewer. Their default passwords
are admin and viewer, respectively.
The admin account has the admin role, which means that it has permissions to edit the configuration and run
privileged commands.
The viewer acccount has the viewer role, which means that it has permissions to view the configuration but not
to edit it and run standard commands.
Warning: For obvious security reasons, you MUST change the passwords of these users.
You may even want to completely disable the default admin and viewer users, by setting
default-users-enabled to false:
vrouter running config# system auth default-users-enabled false
vrouter running config# commit
Configuration applied.
In this case, you must configure a user with the admin role, else you will lose access to the CLI.
Changing Passwords
CLI users
To change the admin user password, go in the system auth user admin context:
For security reasons, the password is not stored in clear-text in the configuration. A hash is stored instead.
It is also possible to directly set the password as a hashed value. To generate a hashed password on a Linux machine,
use mkpasswd, which is provided in the whois package:
root user
Changing the password for the root user is done through the Linux shell:
root@vrouter:~# passwd
Enter new UNIX password: ********
Retype new UNIX password: ********
passwd: password updated successfully
Creating Users
To create a new user, go into the config system auth context, and add a new user with the following commands:
</user>
</auth>
</system>
</config>
Now that the configuration is applied, let’s see the state of our user:
The user john has the admin role. This means he can edit the configuration, read protected nodes (such as pass-
words) and run privileged commands.
˓→1qkapobkS6yCnwauqTEveBw1GOjwuTADvqQVozBoaLbY3KGmsI= user@my-laptop
˓→1qkapobkS6yCnwauqTEveBw1GOjwuTADvqQVozBoaLbY3KGmsI= user@my-laptop"
Warning: NEVER copy the private key contents. Only the PUBLIC key.
This is done from the Linux shell. Copy the public key file contents into the /root/.ssh/authorized_keys file:
˓→1qkapobkS6yCnwauqTEveBw1GOjwuTADvqQVozBoaLbY3KGmsI= user@my-laptop
˓→1qkapobkS6yCnwauqTEveBw1GOjwuTADvqQVozBoaLbY3KGmsI= user@my-laptop
<Ctrl+D>
root@vrouter:~# chmod 600 /root/.ssh/authorized_keys
After which you may check that the remote authentication works without a password:
vrouter>
Note: If you did set a passphrase on your private key, you will need to enter it.
See also:
The command reference for details.
Overview
Note: If a local user with the same name as a remote user exists, the connection can be done by using the local or
remote password. The role of the user will be the one defined locally.
Warning: Some names are reserved by the system and cannot be used: _apt, _lldpd, _tacacs, backup, bin,
daemon, dhcpd, dnsmasq, fastpath, games, gnats, irc, list, lp, mail, man, messagebus, news, nobody, ntp, proxy,
snmp, sshd, statd, sync, sys, syslog, systemd-bus-proxy, systemd-network, systemd-resolve, systemd-timesync,
telegraf, uucp, uuidd, www-data.
If one of these names is used, the connection using a remote server will fail.
Here, 1 is the priority order in case multiple servers are configured. The lower the order, the higher the priority.
The same configuration can be made using this NETCONF XML configuration:
vrouter running config# show config xml absolute system aaa tacacs
<config xmlns="urn:6wind:vrouter">
<system xmlns="urn:6wind:vrouter/system">
<aaa xmlns="urn:6wind:vrouter/system/aaa">
<tacacs>
<order>1</order>
<port>49</port>
<timeout>3</timeout>
<address>192.168.0.1</address>
<secret>testing123</secret>
</tacacs>
</aaa>
</system>
</config>
See also:
The command reference for details.
6WIND Vendor-Specific TACACS+ Attributes can be used to configure users privileges. They are specified in
the TACACS+ server configuration file on a per-user basis. Turbo Router retrieves these attributes through an
authorization request to the TACACS+ server after authenticating a user.
To specify these attributes, include a service statement in the TACACS+ server configuration file, in a user or a
group statement:
service = 6WIND {
local-role = "admin|viewer"
}
At the moment, the local-role attribute is supported. If not specified, the viewer role is assigned by default.
Here is a complete example:
group = admins {
default service = permit
service = exec {
priv-lvl = 15
}
service = shell {
priv-lvl = 15
}
service = 6WIND {
local-role = "admin"
}
}
group = viewers {
default service = permit
service = exec {
priv-lvl = 15
}
service = shell {
priv-lvl = 15
}
service = 6WIND {
local-role = "viewer"
}
}
(continues on next page)
user = john {
name = "John C"
member = admins
pap = PAM
}
user = alice {
default service = permit
service = exec {
priv-lvl = 15
}
service = shell {
priv-lvl = 15
}
service = 6WIND {
local-role = "admin"
}
name = "Alice F"
pap = PAM
}
user = bob {
name = "Bob D"
member = viewers
pap = PAM
}
With this configuration, john and alice can connect to the product with the admin role and bob with the viewer
role.
Note: The length of the user name must be less or equal to 32 characters.
Hostname
The same configuration can be made using this NETCONF XML configuration:
Timezone
The same configuration can be made using this NETCONF XML configuration:
IP/IPv6 parameters
The behavior of the IPv4/IPv6 network stack can be customized globally, and, for some parameters, per VRF. This
behavior customization includes for instance the activation of forwarding, the filtering of packets with source routing
option, etc. . .
If there is no configuration value in a VRF, the global configuration applies.
Global configuration
..
ipv4
forwarding true
send-redirects true
accept-redirects false
accept-source-route false
log-invalid-addresses false
..
ipv6
forwarding true
accept-router-advert never
use-temporary-addresses never
(continues on next page)
The same configuration can be made using this NETCONF XML configuration:
</icmp>
<ipv6>
<forwarding>true</forwarding>
<accept-router-advert>always</accept-router-advert>
<use-temporary-addresses>always</use-temporary-addresses>
<accept-redirects>true</accept-redirects>
<accept-source-route>true</accept-source-route>
</ipv6>
</network-stack>
</system>
</config>
VRF configuration
..
ipv4
forwarding true
send-redirects true
accept-redirects false
accept-source-route false
log-invalid-addresses false
..
ipv6
forwarding true
accept-router-advert never
use-temporary-addresses never
accept-redirects false
accept-source-route false
..
..
The same configuration can be made using this NETCONF XML configuration:
Neighbor
Warning: If the fast path is running, a similar change is required in fast path limits configuration.
The same configuration can be made using this NETCONF XML configuration:
Connection Tracking
The maximum number of connection tracking objects (used for IP filtering) is limited.
To change this limit, do:
Warning: If the fast path is running, a similar change is required in fast path limits configuration.
The same configuration can be made using this NETCONF XML configuration:
Fast path
The fast path is the Turbo Router component in charge of packet processing acceleration. There is only one instance
of fast path, that can manage interfaces in several VRF.
To accelerate ethernet NICs, they must be dedicated to the fast path, and the fast path must be started:
Note: use show state / network-port to see the list of available network ports with PCI ids; it can help
choosing the right ports.
The same configuration can be made using this NETCONF XML configuration:
In the core-mask context, the assignation of cores can be customized. This includes:
• The cores which are dedicated to the fast path for dataplane operations. The accepted values are either a
policy (min, half, max) or a core mask. By default, half of the available cores on are dedicated to the fast
path for dataplane operations.
• Which dataplane cores (included in fast path mask) that receive packets from Linux. By default, all dataplane
cores.
• The control plane cores (disjoint of fast path mask) that receive exception packets. By default, the first control
plane core.
• The mapping between fast path cores and the ports, in other words which core polls which port. By default,
each port is polled by each core of the same NUMA node.
Here is an example of configuration with a custom fast path core mask and exception mask:
Note: use show state / system linux to see the list of available cores.
The same configuration can be made using this NETCONF XML configuration:
The fast path capabilities can be tuned according to your requirements in terms of scalability and memory footprint.
This is done through the fast path limits configuration.
Here is an example of configuration with a custom number of VRs and IPv4 routes:
Warning: Similar changes may be required in system neighbor configuration and in system conntrack config-
uration.
Note: Default fast path scalability limits are automatically adjusted if memory is insufficient, to prevent startup
failure due to lack of memory. show state / system fast-path limits can be used to check the actual
values.
The same configuration can be made using this NETCONF XML configuration:
For advanced users, some fast path parameters can also be customized: the number of network packet buffers,
the number of crypto buffers or sessions, the activation of advanced offload features, the exception core mask, the
hardware queue mapping etc. . .
Please refer to the fast path crypto command reference and the fast path advanced command reference for details.
In a network architecture, control packets are critical, since losing some of them has stronger consequences than
losing data packets:
• losing ARP (Address Resolution Protocol) packets can make a gateway unreachable
• losing OSPF/BGP/. . . packets can make a network unreachable
• losing IKE packets can prevent the setup of IPsec security associations
Control Plane Protection is a software mechanism that reduces the risk of dropping these control packets. It has
an impact on performance, which can be tuned depending on the required throughput and criticity of losing control
packets.
The software parser recognizes ARP, ICMP (Internet Control Message Protocol), ICMPv6, OSPF, VRRP, IKE,
DHCP, DHCPv6, BGP, LACP (Link Aggregation Control Protocol), SSH, OpenFlow, JSON RPC (TCP (Transmis-
sion Control Protocol) port 7406), Stats Collector (TCP port 39090), DPVI (Data Plane Virtual Interface) packets.
All can be encapsulated in VLAN, QinQ or FPTUN (Fast Path Tunneling Protocol).
Control Plane Protection is disabled by default. It can be enabled on a per-interface basis, for RX (Reception) or
TX (Transmission), depending on the situation:
• RX: the router is overloaded, the software is not able to dequeue the incoming packets fast enough, the hard-
ware RX ring becomes full and the NIC starts to drop packets.
• TX: the router tries to send more packets than what the network link supports, the hardware TX ring becomes
full and the software starts to drop packets.
Control Plane Protection works according to a maximum CPU budget. If control plane packets are still dropped
after enabling Control Plane Protection, it means that this budget has to be increased.
To enable Control Plane Protection on a physical interface:
The same configuration can be made using this NETCONF XML configuration:
Note: the Control Plane Protection feature only works when the fast path is enabled, if the feature is supported by
the NIC driver.
Control Plane Protection provides statistics to monitor the number of filtered packets:
When RX Control Plane Protection is enabled, fpn.rx_cp_passthrough is increased for each received packet
when machine is not overloaded. These packets are processed normally without being analyzed.
If the machine is loaded (RX ring length exceeds the threshold) and the CPU budget is not reached, fpn.
rx_cp_kept and fpn.rx_dp_drop will increase respectively for each control plane packet (kept) and for each
data plane packet (drop).
If the CPU budget is exceeded, fpn.rx_cp_overrun is increased for each received packet. These packets are
processed normally without being analyzed.
The same applies for TX.
See also:
The command reference for details.
The cores that are in charge of processing the network packets (the data plane) are dedicated to this task. The other
tasks (the control plane) run on the other cores.
To display the cores affected to control plane:
Important: To get the best performance, fast path cores should be isolated thanks to the cmd
SSH
Secure Shell (SSH) server can be configured for remote login to the router, giving a secure connection from standard
SSH clients.
Independent SSH servers can be started in any vrf.
Users can configure the address and port on which SSH listens on.
Here is an example of configuration that will start a SSH server in the main vrf:
The same configuration can be made using this NETCONF XML configuration:
vrouter running config# show config xml absolute vrf main ssh-server
<config xmlns="urn:6wind:vrouter">
<vrf>
<name>main</name>
<ssh-server xmlns="urn:6wind:vrouter/ssh-server">
<enabled>true</enabled>
<port>22</port>
</ssh-server>
</vrf>
</config>
See also:
The command reference for details.
NETCONF server
As explained in the introduction, Turbo Router provides a NETCONF API that is used by NETCONF clients to
configure and monitor the router remotely.
At startup, if the NETCONF server is not configured, it listens on all interfaces (IPv4 (Internet Protocol version 4)
and IPv6 (Internet Protocol version 6) addresses) on port 830 of the main VRF.
The VRF, IP address and port on which the NETCONF server listens can be configured. This replaces the default
configuration.
Here is an example of configuration that will start the NETCONF server in the mgmt VRF on addresses 192.168.0.5,
port 8030 and fec0::dcad:cafe:ae01:203, port 830:
The same configuration can be made using this NETCONF XML configuration:
vrouter running config# show config xml absolute vrf main netconf-server
<config xmlns="urn:6wind:vrouter">
<vrf>
<name>mgmt</name>
<netconf-server xmlns="urn:6wind:vrouter/netconf-server">
<enabled>true</enabled>
<address>
<ip>192.168.0.5</ip>
<port>8030</port>
</address>
<address>
<ip>fec0::dcad:cafe:ae01:203</ip>
<port>830</port>
</address>
</netconf-server>
(continues on next page)
Here is an example of configuration that will delete the previous configuration and reestablish the default behavior
(listen on all interfaces on port 830):
Attention: If you disable the NETCONF server, any remote operation via NETCONF will be made impossible.
If you have not disabled it into the startup configuration, a reboot will restore the default configuration.
If you have explicitly disabled the NETCONF server in your startup configuration, remote NETCONF operation
will not be enabled on boot. SSH remote access is not related to this and remains available unless you also
disabled it.
See also:
The command reference for details.
NTP
Network Time Protocol (NTP (Network Time Protocol)) is a networking protocol for clock synchronization. Basi-
cally the required parameters are the peer(s) with which you accept to exchange information, and the frequency of
updates.
Client
The same configuration can be made using this NETCONF XML configuration:
vrouter running config# show config xml absolute vrf main ntp
<config xmlns="urn:6wind:vrouter">
<vrf>
<name>main</name>
<ntp xmlns="urn:6wind:vrouter/ntp">
<enabled>true</enabled>
<server>
<address>my.timeserver.com</address>
<iburst>true</iburst>
<version>4</version>
<association-type>SERVER</association-type>
<prefer>false</prefer>
</server>
</ntp>
</vrf>
</config>
Server
Here is an example where Turbo Router will act as a server. It will answer to all synchronization requests except
from the subnet 192.168.2.0/24:
The same configuration can be made using this NETCONF XML configuration:
vrouter running config# show config xml absolute vrf main ntp
<config xmlns="urn:6wind:vrouter">
(continues on next page)
See also:
The command reference for details.
DNS client
The same configuration can be made using this NETCONF XML configuration:
vrouter running config# show config xml absolute vrf main dns
<config xmlns="urn:6wind:vrouter">
<vrf>
<name>main</name>
<dns xmlns="urn:6wind:vrouter/dns">
<server>
<address>192.168.0.254</address>
</server>
<search>example.local</search>
</dns>
</vrf>
</config>
See also:
The command reference for details.
Login banner
When logging in to the system from the console or via ssh, a pre-login banner is displayed before the login prompt,
and a post-login banner is displayed after successfully logging in.
These banners may be customized.
vrouter> exit
See also:
The command reference for details.
Rebooting
Unless you specified otherwise, you have 60 seconds to cancel the reboot with the following command:
Reboot cancelled.
vrouter>
A reboot is not possible if the startup configuration is not the same as the running configuration:
In this case, the startup configuration can be updated using copy running startup, or the use the force argu-
ment:.
See also:
The command reference for details.
Powering Off
To completely shutdown the machine, run the following command in operational mode:
Unless you specified otherwise, you have 60 seconds to cancel the operation with the following command:
Poweroff cancelled.
vrouter>
A poweroff is not possible if the startup configuration is not the same as the running configuration:
In this case, the startup configuration can be updated using copy running startup, or the use the force argu-
ment:.
See also:
The command reference for details.
System Image
<image name> Name used to identify the image. If not set, the version is used.
(default) Set if it is the default boot image.
(current) Set if it is the image on which the system is booted.
(next) Set if the image will be used for the next boot.
Download and install a new version
Note: The newly installed image becomes the next boot image, but does not automatically become the default
boot image.
This enables to test the installed image at next reboot. In case of problem, resetting the system will boot the
default image.
Of course, you can explicitly set the newly installed image as the default image whenever you wish.
Rename an image
Remove an image
Note: If the default boot image is deleted, the current image automatically becomes the default.
See also:
The command reference for details.
Logging
This section covers the configuration of the logging service. To display log messages, refer to the show log docu-
mentation.
It is possible to configure the rate limiting that is applied to all messages generated on the system by changing rate
limit interval and burst values.
If, in the time interval defined by interval (in seconds), more messages than specified in burst are logged by a
service, all further messages within the interval are dropped until the interval is over. A message about the number
of dropped messages is generated. This rate limiting is applied per-service, so that two services which log do not
interfere with each other’s limits.
Defaults to 1000 messages in 30s.
To turn off any kind of rate limiting, set either value to 0.
Let’s check the rate limit values have been applied properly:
Note that disk-usage shows the sum of the file system usage of all archived and active journal files. The journal
size is limited to half the size of the partition where the logs are located, up to a maximum of 4GB.
The same configuration can be made using this NETCONF XML configuration:
See also:
The command reference for details about the API, and the show-log command.
syslog is a standard for message logging. It allows separation of the software that generates messages, the system
that stores them, and the software that reports and analyzes them. Each message is labeled with a facility code,
indicating the software type generating the message, and assigned a level.
Here we explain how to setup remote logging to a distant server.
Client Configuration
The syslog client can be configured for sending log messages to remote servers:
In this example, logs will be sent in TCP to remote server at address 10.125.0.2 and remote port 514 (which is the
default).
To check the values have been applied in the system:
Server Configuration
# vi /etc/rsyslog.conf
Find and uncomment the following lines to make your server to listen on the udp and tcp ports:
[...]
# provides UDP syslog reception
module(load="imudp")
input(type="imudp" port="514")
[...]
# provides TCP syslog reception
module(load="imtcp")
input(type="imtcp" port="514")
[...]
Create a template file where we will create a new custom log format under the /etc/rsyslog.d/ directory:
# vi /etc/rsyslog.d/tmpl.conf
authpriv.* ?TmplAuth
*.info;mail.none;authpriv.none;cron.none ?TmplMsg
See also:
The command reference for details about the API.
Logs sent to the remote servers can be configured using the log-filter command in the remote-server sub-
context.
The first argument of the log-filter command is the facility on which the filter will be applied. Here is the list
of available facilities:
The second argument is the log level. This argument can be a single syslog severity, a list of severities, or a severity
preceded by greater-or-equal. not can also be used to negate a severity. none discards all messages for the
facility. By default all messages are selected.
This table introduces the list of syslog severities from the most serious to the least:
Note:
• By default, if no filters are set, all log messages from all facilities are sent to the remote server. This implicit
filter rule is replaced as soon as a rule is set.
• Each service has its own logging policy with regards to syslog facilities and severities. Refer to the services’
documentation for details.
The TLS (Transport Layer Security) configuration enables syslog messages encryption and servers authentication.
Entering the tls sub-context:
Client Configuration
Note:
• The certificate and the private key have to be generated from the CA.
• A minimal configuration is to add the certificate-authority and set the server-authentication
option to anonymous, which is not recommended as servers and clients are not authenticated.
Server Configuration
Configuration Example
The same configuration can be made using this NETCONF XML configuration:
Interface types
Overview
where NAME is the name of the interface and TYPE can be:
physical to create an Ethernet interface
gre to create a GRE interface
ipip to create an IPv4 and IPv6 tunneling
vlan to create a VLAN interface
vxlan to create a VXLAN interface
lag to create a LAG interface
bridge to create a bridge interface
loopback to create a loopback interface
system loopback to create a system loopback (lo) interface
veth to create a veth interface
Ethernet
Overview
The exclamation mark at the end of the prompt means that the configuration is incomplete. This is because Ethernet
interfaces require a port identifier.
The matching between port identifiers and PCI identifiers of Network Interface Cards is displayed system using the
show state / network-port command.
Use the port command to associate a port identifier to the Ethernet interface:
After committing the configuration, we can fetch the state of the interface using the following command:
The same configuration can be applied using the following NETCONF XML configuration:
vrouter> show config xml absolute vrf main interface physical eth0
<config xmlns="urn:6wind:vrouter">
<vrf>
<name>main</name>
<interface xmlns="urn:6wind:vrouter/interface">
<physical>
<name>eth0</name>
<enabled>true</enabled>
<ipv4>
<enabled>true</enabled>
</ipv4>
<ipv6>
<enabled>true</enabled>
</ipv6>
<port>pci-b0s8</port>
</physical>
</interface>
</vrf>
</config>
Control Plane Protection is a software mechanism that reduces the risk of dropping control packets. It can be
enabled on physical interfaces when the fast path is running. See the fast path control plane protection section for
details.
See also:
The command reference for details.
GRE
Basic configuration
GRE protocol provides a simple and general mechanism to encapsulate a network layer protocol in another network
layer protocol. It is defined in RFC 2784.
This interface is point to point or point to multipoint. So its configuration is different from ethernet interfaces
(arp/ndp, dhcp are not available).
To configure GRE, enter the context interface type gre from the VRF in which you plan to define a GRE interface.
Here is an example of a point to point GRE named tunnel1, with connecting the local address 1.1.1.1 and the
remote address 2.2.2.2:
The same configuration can be made using this NETCONF XML configuration:
Link VRF
A GRE interface may perform cross-VRF, i.e change the VRF of encapsulated and decapsulated packets:
The link VRF is the VRF of encapsulated packets. The interface VRF is the VRF of output packets before encap-
sulation and of input packets after decapsulation.
GRE key
The GRE key is an extension defined in RFC 2890. It is an optional 32 bit field that enables to identify an individual
traffic flow or service within a GRE tunnel.
When using this feature, each individual flow/service is processed by a different GRE interface, identified with the
key assigned to the flow/service.
An optional output key may be assigned to a GRE interface. If set, GRE packets output by this interface will have
a key field with the configured value:
An optional input key may be assigned to a GRE interface. If set, only GRE packets with a key field set to this
value will be processed by this interface. If unset, only GRE packets without a key field will be processed by this
interface.
key both assigns the same value for the input and output keys. It is overriden if key input or key output is
specified:
The use of input and output keys is independant: it is possible to assign an output key without assigning an input
key, and vice versa.
The tuple (local, remote, link-vrf, key input) must be unique among all GRE interfaces, whatever their vrf.
GRE multipoint
A point to multipoint GRE is simply defined by letting the remote address empty. As the remote address is not
specify it is needed to specify neighbors for routing operations.
10.1.1.0/28
The same configuration can be applied to point to multipoint GRE named gre2 and gre3 to connect the three
routers with a multipoint GRE.
Let’s fetch the state after committing this configuration:
The same configuration can be made using this NETCONF XML configuration:
See also:
The command reference for details.
Tunneling is a widespread technique used in networking, to resolve many problems: IPv4 / IPv6 migration, Virtual
Private Networks, routing. It consists in encapsulating a packet into a new layer 3 packet, by appending an IP header.
6WIND Turbo Router provides several techniques to tunnel IP packets into new IP packets (the inner and outer IP
versions may differ).
Tunneling techniques create a virtual layer 2 link (called a tunnel) between the source and destination of the encap-
sulating packets, and hide the network topology between these two endpoints, as if the two endpoints where directly
connected. Therefore, 6WIND Turbo Router creates a logical point-to-point interface, that appears in the list of
interfaces and that can be used by other functions, notably routing.
There are 4 different types of tunnel:
• 4in4. IPv4 in IPv4 Configured Tunnels encapsulates IPv4 traffic in an explicit IPv4 tunnel.
• 6in4. An IPv6 in IPv4 configured tunnel encapsulates IPv6 traffic in an explicit IPv4 tunnel.
• 4in6. IPv4 in IPv6 Configured Tunnels encapsulates IPv4 traffic in an explicit IPv6 tunnel. That could be
useful to simulate VLANs. That could be useful for the interconnection of IPv4 clouds on an IPv6 native
service
• 6in6. IPv6 in IPv6 Configured Tunnels encapsulates IPv6 traffic in an explicit IPv6 tunnel.
Here is an example of a 4in6 tunnel named tun4in6 in VRF main, linked to underlying interface named eth0.
The tunnel interface is configured as soon as the provided eth0 is configured in VRF main.
The same configuration can be made using this NETCONF XML configuration:
vrouter running config# show config xml absolute vrf main interface ipip tun4in6
<config xmlns="urn:6wind:vrouter">
<ha xmlns="urn:6wind:vrouter/ha"/>
<vrf>
<name>main</name>
<interface xmlns="urn:6wind:vrouter/interface">
<ipip xmlns="urn:6wind:vrouter/ipip">
<name>tun4in6</name>
<enabled>true</enabled>
<ethernet/>
<ipv4>
<enabled>true</enabled>
<address>
<ip>192.168.0.1</ip>
(continues on next page)
See also:
The command reference for details.
VLAN
Virtual Local Area Networks (VLAN) allows to divide a network into several logical networks domains. The stan-
dard 802.1Q protocol is used to add a tag identifier between 1 and 4094. VLAN stacking or QinQ is supported by
simply binding the VLAN interface to another.
To configure VLAN, enter the context interface type vlan from the VRF in which you plan to define VLAN
logical interface. The VLAN configuration is valid as soon as the VLAN ID is set and the bound interface is set.
Here is an example of VLAN named vlan-blue in VRF main, with a tag identifier 300 and bound to underlying
interface named eth0:
The same configuration can be made using this NETCONF XML configuration:
vrouter> show config xml absolute vrf main interface vlan vlan-blue
<config xmlns="urn:6wind:vrouter">
<vrf>
<name>main</name>
<interface xmlns="urn:6wind:vrouter/interface">
<vlan xmlns="urn:6wind:vrouter/vlan">
<name>vlan-blue</name>
<protocol>802.1q</protocol>
<vlan-id>300</vlan-id>
<link-interface>eth0</link-interface>
(...)
</vlan>
</interface>
</vrf>
</config>
See also:
The command reference for details.
By default, the link interface must be in the same VRF than the VLAN interface. However, a VLAN interface can
bind a link interface which is located in another VRF: this type of setup is called cross-vrf.
To change the link VRF, set the link-vrf :
VXLAN
Virtual eXtensible Local Area Networks (VXLAN) is used to address the need for overlay networks within virtual-
ized data centers accommodating multiple tenants.
To configure VXLAN, enter the context interface type vxlan from the VRF in which you plan to define VXLAN
logical interface. The VXLAN configuration is valid as soon as the VXLAN ID is set.
Here is an example of VXLAN named vxlan100 in VRF main, with a tag identifier 100 and linked to underlying
interface named eth0 using the multicast group ‘239.0.0.8’:
The same configuration can be made using this NETCONF XML configuration:
vrouter> show config xml absolute vrf main interface vxlan vxlan100
<config xmlns="urn:6wind:vrouter">
<ha xmlns="urn:6wind:vrouter/ha"/>
<vrf>
<name>main</name>
<interface xmlns="urn:6wind:vrouter/interface">
<vxlan xmlns="urn:6wind:vrouter/vxlan">
<name>vxlan100</name>
<enabled>true</enabled>
<ethernet>
<auto-negotiate>true</auto-negotiate>
<enable-flow-control>false</enable-flow-control>
</ethernet>
<ipv4>
<enabled>true</enabled>
</ipv4>
<ipv6>
<enabled>true</enabled>
</ipv6>
<learning>true</learning>
(continues on next page)
It’s also possible to directly set the remote VTEP (VXLAN Tunnel End Point) address in the VXLAN configuration.
This can be done with the remote option that takes a unicast address (unlike group that takes a multicast address):
See also:
• The command reference for details.
• The BGP EVPN chapter for configuration using the EVPN technology.
Forwarding Database
To configure the VXLAN FDB (Forwarding Database), enter the ipv4 or ipv6 sub-context then use the fdb com-
mand.
If the remote VTEP link layer address is unknown it’s possible to set it to 00:00:00:00:00:00. The VXLAN will
automatically learn the VTEP address. In this case, the learning option must be set to true:
vxlan vxlan100
enabled true
ipv4
enabled true
address 192.168.0.1/24
fdb link-layer-address 00:00:00:00:00:00 ip 10.125.0.2
..
(continues on next page)
Note: The FDB entries IP version must match the local address version. If the local option is not set, the IPv4
must be used.
The VXLAN FDB can be observed with the show vxlan fdb command.
See also:
• The command reference for details.
It’s also possible to flush one or several FDB entries with the flush vxlan fdb command:
OK.
vrouter> show vxlan fdb name vxlan100
neighbor interface link-layer-address link-interface port vni state
======== ========= ================== ============== ==== === =====
10.125.0.2 vxlan1 unknown permanent
Note: A static FDB will be automatically reconfigured if flushed. Use the del command in the edition context to
permanently remove it.
See also:
• The command reference for details.
LAG
Link Aggregation (LAG) allows to aggregate multiple network interfaces into a single logical “bonded” interface.
It can provide an active backup service assisted with LACP (802.3ad) or a load balancing to increase the bandwidth.
Multiple modes are available for load balancing: round-robin, XOR on MAC address.
Multiple policies are available to select which part of the packet header will be used to compute the hash: L2, L3,
L4, mix of L2 and L3, mix of L3 and L4, using either the outer or the most inner packet in case of encapsulation.
By default the MII link monitoring is activated and set to 100 ms. Disabling the MII link monitoring (set its value
to 0) is not recommended, the link detection and failure can have poor performance.
To configure a LAG, enter the context interface type lag from the VRF in which you plan to define the LAG
interface.
Here is an example of lag named lag0 in VRF main, using lacp mode with a hash on L2+L3 header and a slow rate
using two interfaces eth0 and eth1.
The lag interface is configured provided eth0 and eth1 are present in VRF main.
Let’s fetch the state after committing this configuration:
The same configuration can be made using this NETCONF XML configuration:
vrouter> show xml absolute config vrf main interface lag lag0
<config xmlns="urn:6wind:vrouter">
<vrf>
<name>main</name>
<interface xmlns="urn:6wind:vrouter/interface">
<lag xmlns="urn:6wind:vrouter/lag">
<name>lag0</name>
<enabled>true</enabled>
<link-interface>
<slave>eth0</slave>
</link-interface>
<link-interface>
<slave>eth1</slave>
</link-interface>
<ipv4>
<enabled>true</enabled>
</ipv4>
<ipv6>
<enabled>true</enabled>
</ipv6>
<mii-link-monitoring>100</mii-link-monitoring>
<mode>lacp</mode>
<xmit-hash-policy>layer2+3</xmit-hash-policy>
<lacp-rate>slow</lacp-rate>
</lag>
</interface>
</vrf>
</config>
See also:
The command reference for details.
Bridge
Bridge allows the connection of two separate networks as if they were a single network. It builds a database by
inspecting the destination MAC address of packets flowing through the bridged interfaces: known destination is
forwarded, unknown is broadcast to all other networks.
To configure a bridge, enter the context interface type bridge from the VRF in which you plan to define the
bridge logical interface. The bridge configuration is valid as soon as the slave interfaces are set.
Here is an example of bridge named br0 in VRF main, using two interfaces eth0 and eth1.
The bridge interface is configured provided eth0 and eth1 are present in VRF main.
Let’s fetch the state after committing this configuration:
The same configuration can be made using this NETCONF XML configuration:
vrouter running config# show config xml absolute vrf main interface bridge br0
<config xmlns="urn:6wind:vrouter">
<vrf>
<name>main</name>
<interface xmlns="urn:6wind:vrouter/interface">
<bridge xmlns="urn:6wind:vrouter/bridge">
<name>br0</name>
<enabled>true</enabled>
(...)
<link-interface>
<slave>eth0</slave>
</link-interface>
<link-interface>
<slave>eth1</slave>
</link-interface>
</bridge>
</interface>
</vrf>
</config>
See also:
The command reference for details.
Loopback
The main purpose of loopback interfaces is to provide one or more permanent addresses to a network device, re-
gardless of which network interfaces are up. A loopback address is typically announced into the routing tables, and
can therefore be used as a management address instead of a physical interface address. This is preferable since a
loopback interface is independent from any physical interface and is, therefore, always available. This also enables
to configure unnumbered point-to-point interfaces (for example with a PPPv4 server) A loopback address will typ-
ically be used in IPv4 packets. Finally, a prefix configured on a loopback interface can be used to announce some
directly connected networks via dynamic routing protocols.
To configure loopback, enter the context interface type loopback from the VRF in which you plan to define a
loopback logical interface.
The same configuration can be made using this NETCONF XML configuration:
See also:
The command reference for details.
SVTI
Secure Virtual Tunnel Interfaces are generic virtual interfaces ensuring IPsec transformation. They are used to
configure route-based VPNs.
Each SVTI interface has its own SAD (Security Association Database) and SPD (Security Policy Database).
Unlike other tunnel interfaces, an SVTI interface is not a point-to-point interface between two specific gateways, the
encapsulation addresses are determined by the SPs (Security Policies) and SAs (Security Associations) matched by
the traffic.
These interfaces have an SVTI ID parameter to associate them to IPsec SAs/SPs. This ID must be unique per-VRF1 .
To configure SVTI, enter the interface context in the desired VRF and type svti followed by the SVTI interface
name. The interface name must start with svti. The configuration is valid as soon as the SVTI identifier is set.
Here is an example of an SVTI named svti100 with an SVTI identifier 100:
The same configuration can be made using this NETCONF XML configuration:
vrouter> show config xml absolute vrf main interface svti svti100
<config xmlns="urn:6wind:vrouter">
<vrf>
<name>main</name>
<interface xmlns="urn:6wind:vrouter/interface">
<svti xmlns="urn:6wind:vrouter/svti">
<name>svti100</name>
<enabled>true</enabled>
<ipv4>
<enabled>true</enabled>
</ipv4>
<ipv6>
<enabled>true</enabled>
</ipv6>
<svti-id>100</svti-id>
</svti>
</interface>
</vrf>
</config>
Cross-VRF
Like other tunnel interfaces, an SVTI interface is defined in a VRF and is assigned a possibly different link VRF
(the VRF of encapsulated packets). SVTI interfaces can therefore be used to do cross-VRF.
The (link VRF, SVTI ID) pair uniquely identifies an SVTI interface, regardless of the interface VRF.
The SPs, SAs and IKE configuration are located in the SVTI interface link VRF.
Here is an example of an SVTI located in vrf2 but with a link-vrf in vrf1:
In this configuration, the clear traffic will be in vrf2 and the encrypted traffic in vrf1.
SVTI templates
SVTI templates are models of SVTI interfaces used for dynamic SVTI interface creation. An IKE VPN may refer-
ence an SVTI template, so that an SVTI interface is created for each established IKE SA, and the negotiated SAs
and SPs attached to it.
To configure an SVTI template, enter the interface context in the desired VRF and type svti-template followed
by the SVTI template name.
Here is an example of an SVTI template named svtitemp100:
The dynamically created SVTI interface names will start with dsvti and do not depend on the template name.
Their SVTI ID is dynamically chosen by IKE.
See also:
The command reference for details.
System Loopback
The system loopback interface is the lo interface created by the system in every VRF. It cannot be configured, but
it is advertised in the state:
See also:
The command reference for details.
veth
A usual way to connect VRF together is to use a veth interface. The veth interfaces are virtual Ethernet devices
that are always created in interconnected pairs. They can act as tunnels between network namespaces.
veth interfaces are similar to xvrf interfaces, with the following differences:
• the MAC (Medium Access Control) address can be configured on veth interfaces
• veth interfaces are not flagged NOARP, meaning that ARP or NDP (Neighbor Discovery Protocol) resolution
is done when sending an IP (Internet Protocol) packet through it
• veth interfaces support IP configuration
See also:
xvrf interfaces.
Here is an example of configuration where veth interfaces connect two VRF.
A YANG condition ensures that the binding of veth interfaces is consistent: the veth interfaces of a given pair
must bind each other.
A route can then be added in vr2 to reach a network 10.100.0.0/16 through vr1:
Let’s fetch the veth state inside vr1 afer committing this configuration:
The same configuration can be made using this NETCONF XML configuration.
See also:
The command reference for details.
XVRF
A usual way to connect VRF together is to use a xvrf interface. The xvrf interfaces are virtual Ethernet devices
that are always created in interconnected pairs. They can act as tunnels between network namespaces.
xvrf interfaces are similar to veth interfaces, with the following differences:
• xvrf interfaces have a fixed MAC address and cannot be configured
• xvrf interfaces are flagged NOARP, meaning that no ARP or NDP resolution is done when sending an IP
packet through it
• xvrf interfaces do not support IP configuration
See also:
veth interfaces.
A YANG condition ensures that the binding of xvrf interfaces is consistent: the xvrf interfaces of a given pair
must bind each other.
A route can then be added in vr2 to reach a network 10.100.0.0/16 through vr1:
Let’s fetch the xvrf state inside vr1 afer committing this configuration:
The same configuration can be made using this NETCONF XML configuration.
See also:
The command reference for details.
An example of application of Cross-VRF interfaces is to provide vrf route leaking mechanisms with BGP. Cross-
VRF interfaces are used to carry traffic from one VR to an other one. In the L3VPN case, the Cross-VRF interfaces
can be the border between overlay and underlay information, as encapsulation and decapsulation operations will take
place at this point.
See also:
The BGP L3VPN for details.
Interface management
MAC
The same configuration can be made using this NETCONF XML configuration:
vrouter> show config xml absolute vrf main interface physical eth0
<config xmlns="urn:6wind:vrouter">
<vrf>
<name>main</name>
<interface xmlns="urn:6wind:vrouter/interface">
(continues on next page)
See also:
The command reference for details.
MTU
Default MTU (Maximum Transmission Unit) interface is typically 1500. User can lower the value to cope with
tunneling, or increase the value up to 9K to leverage jumbo support on the NIC.
To configure the MTU of the existing interface eth0 in vrf main to 2000, do:
The same configuration can be made using this NETCONF XML configuration:
vrouter> show config xml absolute vrf main interface physical eth0
<config xmlns="urn:6wind:vrouter">
<vrf>
<name>main</name>
<interface xmlns="urn:6wind:vrouter/interface">
<physical>
<name>eth0</name>
<mtu>2000</mtu>
(...)
</physical>
</interface>
</vrf>
</config>
See also:
The command reference for details.
Unlike the MAC and MTU parameters which are applicable to all Ethernet interfaces, the following settings are only
applicable to physical interfaces (i.e., interfaces backed by a physical PCI port).
See also:
The command reference for details.
Auto-Negotiation
Even though it is often left enabled, auto-negotiation may be changed to cope with certain physical connections.
Duplex Mode
By default, this setting is negotiated automatically with the connected endpoint. When auto-negotiation is set
to false, you must specify the duplex mode of the connection.
Port Speed
By default, this setting is negotiated automatically with the connected endpoint. When auto-negotiation is set
to false, you must specify the port speed.
Flow Control
Pause frames are used by the NIC to ask a peer to slow down. It can be configured to automatically send pause
frames as soon as the receive buffer is getting low, and to accept or not pause frames from other devices.
The default settings vary with hardware and device drivers. You may force them with the following commands:
Statistics
Statistics about received and transmitted packets are available per interface.
To get the statistics of the eth0 interface in main vrf, do:
You can also display the input/output packet and bit rate per second:
3.1.6 IP Networking
IP
• Static IP address
• DHCP for IPv4
• Static ARP/NDP neighbour entry
Static IP address
IPv4 or IPv6 address can be added to an interface. Let’s add a static IPv4 address ‘10.0.0.1/24’ on port we name
‘giga0’:
Or an IPv6 address:
You can use the DHCP client to dynamically obtain an IP address and other parameters such as the default gateway,
DNS servers information from a DHCP server. This parameter is not available for point to point interfaces.
In this example we enable DHCP on an interface, leaving only the following options activated:
• domain-name, used when resolving hostnames with DNS
• ntp-servers, to get the list of NTP servers
• interface-mtu, to get the MTU to use on this interface
vrouter running config# show state vrf main interface physical eth0 ipv4 dhcp
dhcp
dhcp-lease-time 7200
select-timeout 0
current-lease
expire 4 2018/06/28 16:14:53
fixed-address 10.0.2.15
rebind 4 2018/06/28 13:14:53
renew 4 2018/06/28 02:49:27
..
retry 300
reboot 10
enabled true
initial-interval 10
timeout 60
request domain-name
request ntp-servers
request interface-mtu
..
Static ARP (IPv4) or NDP (IPv6) neighbour can be added to an interface. This parameter is not available for point
to point interfaces.
From ‘ipv4’ context you can add static ARP entries to bind an IP address to a fixed ethernet address:
Or from ‘ipv6’ context, you can add static NDP entries to bind an IPv6 address to a fixed ethernet address:
CG-NAT
CG-NAT, also known as Large Scale NAT (LSN), is an extension of NAT for large scale networks and ISPs (Internet
Service Providers).
The key advantages of CG-NAT compared to NAT are:
• High Transparency: CG-NAT implements multiple advanced features like Endpoint-Independent Mapping,
Endpoint-Independent Filtering, address pooling and port parity preservation. These features provide better
experience to ‘nated’ users and allow scaling.
• Fairness and Resource Sharing: CG-NAT provides options to limit the number of connections per user. This
ensures that resources are equitably shared between the different users.
• Optimized Logging system: CG-NAT can generate large amounts of logging data. CG-NAT implements a
feature called port block allocation to limit the number of log entries by grouping per port range.
• Transition between IPv6-only and IPv4-only networks thanks to NAT64, in conjunction to DNS64.
Caution: Stateful IP packet filtering and CG-NAT are exclusive. If CG-NAT is enabled, stateful IP packet
filtering must be disabled on ports bound to the fast path.
See also:
The CG-NAT command reference and the CG-NAT fast path limits command reference for details.
• Configuration
– Pool
– Rule
– Understanding Port Block Allocation
– Address Pooling
– Port algorithm
– Active Block Timeout
– Endpoint mapping
– Endpoint filtering
– Hairpinning
– Conntracks
– ALG
– Summary
• Logging
– dynamic
– deterministic
• Troubleshooting
– Invalid packet state statistics
– State/NAT/USER/Block Allocation Failures
– No IP Public errors
– NAT port allocation failures
– Maximum number of blocks reached
– Full IP Public errors
• Dimensioning
Configuration
Pool
A CG-NAT pool contains a list of IPv4 addresses used to change the IPv4 or IPv6 source address and port of a
packet.
The CG-NAT implements a feature called port block allocation. Each time a new user sent a packet through the
CG-NAT router, a block of ports (i.e. a port range) from one of the IPv4 addresses in the pool is allocated to this
one. The number of ports given to an user is configurable via the block-size option.
Here is an example of a CG-NAT pool:
Rule
static SNAT44
All packets routed through an output interface and matching the filtering criteria defined in a CG-NAT rule are
source nated with an ip.
Here is an example of a CG-NAT rule:
static DNAT44
All packets received on an input interface and matching the filtering criteria defined in a CG-NAT rule are destination
nated with an ip.
Here is an example of a CG-NAT rule:
dynamic SNAT44
All packets routed through an output interface and matching the filtering criteria defined in a CG-NAT rule are
source nated with an ip dynamically assigned from one CG-NAT pool.
Here is an example of a CG-NAT rule:
The same configuration can be made using this NETCONF XML configuration:
vrouter running config# show config xml absolute vrf main cg-nat
<config xmlns="urn:6wind:vrouter">
<vrf>
<name>main</name>
<cg-nat xmlns="urn:6wind:vrouter/cgnat">
<enabled>true</enabled>
<logging/>
<pool>
<name>mypool</name>
<port-range/>
<address>192.0.2.33-192.0.2.49</address>
<address>192.0.1.0/24</address>
<address>192.0.3.1</address>
<block-allocation-mode>dynamic<block-allocation-mode/>
<block-size>512</block-size>
</pool>
<rule>
<id>1</id>
<dynamic-snat44>
<match>
<source>
<ipv4-address>100.64.0.0/10</address>
</source>
<outbound-interface>eth1</outbound-interface>
</match>
<translate-to>
<pool-name>mypool</pool-name>
</translate-to>
</dynamic-snat44>
</rule>
</cg-nat>
</vrf>
</config>
deterministic SNAT44
The deterministic-snat44 works like dynamic-snat44, except that IP and ports from the CG-NAT pool are associated
in a deterministic manner to the user at the time of configuration: the CG-NAT pool is partitioned in chunk of port
block, so that each user has its own port block. See the Understanding Port Block Allocation/deterministic for more
information about this point.
Here is an example of a deterministic CG-NAT rule:
dynamic SNAT64
In the case of NAT64, translation between IPv6-only addresses on the private side and IPv4 addresses on the
public side is taken care of by mapping the IPv4 public addresses to a special IPv6 prefix that is configured in the
translate-to section of the rule.
DNS64 must be configured to translate IPv4 addresses DNS replies to IPv6 ones using this prefix.
The rest of the configuration is similar to dynamic NAT44.
The client option can be used to select which client the DNS64 function will apply to. The CPE (Customer
Premise Equipment) subnet in the CG-NAT rule should have the same value.
The exclude option is a safeguard to ensure that no IPv6 address matching 64:ff9b::/96 will be returned to
IPv6 clients. Without it the CG-NAT might translate IPv6 packets going to this IPv6 server into IPv4 packet with
an incorrect IPv4 address.
The mapped option can be used to avoid mapping specific IPv4 address to IPv6. For example, it is a good idea not
to embed any RFC 1918 addresses that name servers on the Internet might inadvertently return.
static SNAT64
All IPv6 packets routed through an output interface and matching the filtering criteria defined in a CG-NAT rule
are source nated with an IPv4 address.
Here is an example of a CG-NAT rule:
static DNAT46
All IPv4 packets received on an input interface and matching the filtering criteria defined in a CG-NAT rule are
destination nated with an IPv6 address.
Here is an example of a CG-NAT rule:
dynamic
It is a legal requirement for an ISP to be able to provide the mapping between a user and a public IP address at a
given point in time. With classic NAT, it means that each new user session has to be logged. This is obviously not
scalable. Additionally with classic NAT, a user can consume all the ports of the public IP.
To reduce the amount of logs and equitably share the ports of the different public IPs, CG-NAT provides the Port
Block Allocation (PBA) feature that consists in allocating blocks of ports to each user. As logging is done per block
of ports, the amount of logs is reduced. And as the number and size of the blocks can be configured, the user port
consumption is controlled. Here is how PBA works.
Each time a new user sends a packet through the vRouter, a block of ports is allocated to him from one of the
IP addresses in the pool. The public IPs are selected using a round-robin algorithm. Each public IP is divided
into blocks of ports, whose size and range is defined in the pool configuration. This prevents a single user from
consuming all ports.
Here is an example to change the number of ports per block:
vrouter running cg-nat# / vrf main cg-nat pool mypool block-size 256
vrouter running cg-nat# commit
For the next session of the same user, a port is allocated from its block of ports, until the block is exhausted. In that
case, a new block can be allocated for this user and it becomes the active block. There is only one active block per
user. The maximum number of blocks per user is defined in the rule configuration.
Here is an example to change the maximum number of blocks per user:
Since ports are allocated from the same block (until this one is empty), port prediction can potentially happen. To
randomize port allocation, it is possible to allocate a new active block if the current active block has been active for
too long, even if there are still some ports available in the active block. This feature is called active block timeout.
As it can increase the average numbers of blocks allocated per user, it is disabled by default.
Here is an example to configure an active block timeout of 60 seconds:
When all the ports are released from a non-active block, this one is released immediately. Regarding the active
block, the block is only released when the user subscription times out. The default user timeout is 120 seconds.
Here is an example to change the user timeout:
vrouter running cg-nat# / vrf main cg-nat rule 1 translate-to user-timeout 180
vrouter running cg-nat# commit
deterministic
ISPs have a legal requirement to be able to map a subscriber’s inside address with the address and port used on the
public Internet (e.g., for abuse response). With dynamic allocation, any new block of port allocated/released need
to be logged.
The port allocation algorithm for deterministic is predictable and sequential (i.e. the first block goes to address 1,
the second block to address 2, etc.).
Thanks to this allocation method, it is possible to retrieve at any time a mapping between a public IP and a private
one without any log. The following commands can be used for this purpose:
10.100.0.66
vrouter> show cg-nat deterministic-mappings | pager
10.100.0.0: 10.175.0.3 1-255
10.100.0.1: 10.175.0.3 256-510
10.100.0.2: 10.175.0.3 511-765
...
A deterministic rule needs to be associated to a pool with block-allocation-mode set to deterministic. Public IPs
cannot be shared between deterministic and dynamic rules.
For deterministic rules, the block-size option is not mandatory. It is even recommended to not use it. Because
it is automatically computed to this maximal value with the following formula: (port_range_of_the_pool * num-
ber_pool_ips) / number_of_user.
The users always have one block per protocol. As a consequence, deterministic rules don’t support the ‘max-blocks-
per-user’ option.
Address Pooling
It’s recommended to use paired address pooling for applications that require all sessions associated with one private
IP address to be translated to the same public IP address for multiple sessions.
Port algorithm
Note: As this option can increase the average number of blocks allocated per user, it is disabled by default.
Endpoint mapping
• dependent: The vRouter reuses the same port mapping for subsequent packets sent from the same internal IP
address and port to the same external IP address and port.
Endpoint filtering
• dependent: Inbound packets from external endpoints are filtered out if they don’t match an existing mapping
(source and destination IPs and ports, protocol).
Hairpinning
The hairpinning feature allows two endpoints (user 1 and user 2) on the private network to communicate together
using their public IP addresses and ports.
By default, the hairpinning feature is disabled. To enable it, use the following command.
Conntracks
It is possible to set conntrack timeouts for each protocol. UDP, ICMP and GRE protocols only handle basic conntrack
states (new, established, closed), whereas TCP offers more granularity.
ALG
Summary
The following table summarizes the different parameters for CG-NAT configuration.
Warning: Changing some configuration parameters requires to flush users. This is automatically done when
required (see the table below), and causes a service interruption.
Logging
dynamic
You can enable logs for CG-NAT to track each port block allocation/deallocation for a user :
The following fields are displayed for each port block allocation/deallocation:
• IP address of the user
• name of the CG-NAT rule matched by the user
• type of event: NEW BLOCK (a new port range is associated to this user) or DESTROY BLOCK (port range
is released for this user).
• pool and ip used to nat the user
• port range of the block
• l4 protocol (i.e. 6 for tcp, 17 for udp, 1 for icmp, 47 for gre)
• timestamp of the event
deterministic
The deterministic algorithm is predictable, so block allocation/deallocations don’t need to be logged. Anyway, to
retrieve the mapping between user and public address, the deterministic algorithm needs to know the deterministic
CG-NAT is configured.
In consequence, the deterministic CG-NAT configuration is logged.
The deterministic CG-NAT configuration can be used to retrieve a user address behind a public address/port with
the fp-cgnat-deterministic application.
10.100.0.66
Troubleshooting
If the TCP case I, II or III statistics are incremented, you may disable TCP window checks as follows.
If the TCP case RST statistic is incremented, you may disable TCP RST strict ordering as follows.
Note: Disabling these features improves performance to the detriment of TCP robustness.
If one of these statistics is incremented, it means that one of the memory pools of the vRouter is full. Memory pool
usage can be dumped using the following command.
In the example above, the connection and NAT memory pools are full. Their size must be increased as follows.
No IP Public errors
If this statistic is incremented, it means there are no blocks available in any public IP. This can be checked using the
following command.
To solve this issue, add a new public IP to the pool using the following command.
To understand why a specific user has many connections, use the following command.
If the maximum number of blocks is reached, it probably means that you have not allocated enough blocks per
user. You can collect some statistics to get average/percentile block and port usage of all users with the following
commands.
You can also check the block usage and port usage of a specific user to get more details with the following commands.
Then, you can decide to increase the number of blocks per user or the block size. Refer to the Changing parameters
section.
The paired address pooling feature ensures the assignment of the same public IP address to all sessions originating
from the same internal user, as described in RFC 4787 Req 2 (https://tools.ietf.org/html/rfc4787#page-22).
It means that when a user has started to use one public IP address, all its port blocks will be allocated from this same
IP. Adding a new public IP to the pool won’t solve the issue, as the user cannot allocate a block from a new public
IP.
A possible way to recover such situation is to add new IP address to the pool, and then flush all the current connections
of all users, as follows.
Dimensioning
The maximum numbers for NAT entries, CPEs (users), conntracks (sessions), blocks and block sizes are defined in
the configuration. These limits can be adjusted to adapt to the amount of memory available in the system.
The following table shows a list of different limit combinations and the corresponding memory requirement. This
is empirical and may have to be tuned according to your use case.
Max conntracks Max nat entries Max cpe Max blocks Required memory
1M 1M 10K 80K 5 GB
2M 2M 20K 80K 6 GB
4M 4M 20K 80K 8 GB
8M 8M 20K 80K 12 GB
16M 16M 20K 80K 24 GB
30M 30M 20K 80K 32 GB
Warning: Changing these values triggers a restart of the fast-path (hence, a service interruption). Therefore
you should carefully think about your dimensioning before launching your Turbo Router into production.
Modifying these limits will automatically restart the fast path and interrupt packet processing. To check that the fast
path is back up and running, use the following command.
NAT
NAT provides a way to translate IPv4 addresses and ports while crossing the device. This technique is typically
used to conserve addresses now that IPv4 addresses become a scarce resource.
Note: NAT rules not configured by the management system will not be displayed by show state and will be lost
when a new NAT configuration is committed.
Caution: NAT and CG-NAT are exclusive. If CG-NAT is enabled, NAT must be disabled on ports bound to
the fast path.
See also:
The command reference for details.
When configuring NAT along with IP packet filtering, you should know that:
• source NAT happens in postrouting chain, after mangle table
• destination NAT happens in prerouting chain, after raw and mangle tables
• connection tracking (conntracks) keeps track of how the packet should be changed in the two directions
See also:
IP packet filtering for details.
Source NAT
Source NAT changes the source IPv4 address or port of an outgoing packet.
Note: A destination NAT rule is not needed to do source NAT. Connection tracking keeps track of how the packet
should be changed in the two directions, so a source NAT rule is enough. A destination NAT rule can be added if
the NAT connection can be opened from both sides.
Here is an example of a rule which matches the packets with source address 1.1.1.1 output to public interface,
and translates their source address to 2.2.2.2:
..
The same configuration can be made using this NETCONF XML configuration:
vrouter running config# show config xml absolute vrf main nat
<config xmlns="urn:6wind:vrouter">
<vrf>
<name>main</name>
<nat xmlns="urn:6wind:vrouter/nat">
<source-rule>
<id>1</id>
<source>
<address>
<value>1.1.1.1/32</value>
</address>
</source>
<outbound-interface>
<name>public</name>
</outbound-interface>
<translate-to>
<address>
<value>2.2.2.2</value>
</address>
</translate-to>
</source-rule>
</nat>
</vrf>
</config>
Masquerading
Masquerading is a kind of source NAT. It is a way to use one public IPv4 address visible on the Internet for an entire
private network, using the IPv4 address of the device public interface.
Here is an example of a rule which matches the packets sent via public interface, and translates their source address
to the IPv4 address of public interface:
The same configuration can be made using this NETCONF XML configuration:
vrouter running config# show config xml absolute vrf main nat
<config xmlns="urn:6wind:vrouter">
<vrf>
<name>main</name>
<nat xmlns="urn:6wind:vrouter/nat">
<source-rule>
<id>1</id>
<outbound-interface>
<name>public</name>
</outbound-interface>
<translate-to>
<output-address/>
</translate-to>
</source-rule>
</nat>
</vrf>
</config>
Destination NAT
Destination NAT changes the destination IPv4 address or port of an incoming packet.
Note: A source NAT rule is not needed to do destination NAT. Connection tracking keeps track of how the packet
should be changed in the two directions, so a destination NAT rule is enough. A source NAT rule can be added if
the NAT connection can be opened from both sides.
Here is an example of a rule which matches the tcp packets with destination port 8080 received from public
interface, and translates their destination address to 2.2.2.2, and their destination port to 80:
..
The same configuration can be made using this NETCONF XML configuration:
vrouter running config# show config xml absolute vrf main nat
<config xmlns="urn:6wind:vrouter">
<vrf>
<name>main</name>
<nat xmlns="urn:6wind:vrouter/nat">
<destination-rule>
<id>1</id>
<protocol>
<value>tcp</value>
</protocol>
<destination>
<port>
<value>8080</value>
</port>
</destination>
<inbound-interface>
<name>public</name>
</inbound-interface>
<translate-to>
<address>
<value>2.2.2.2</value>
<port>80</port>
</address>
</translate-to>
</destination-rule>
</nat>
</vrf>
</config>
3.1.7 Routing
Static routes
Standard routing
Once the IP addresses have been configured, communication is possible between the nodes (hosts or routers) directly
connected to the same IP sub-network. It is a one hop communication. To communicate with other nodes that are
connected to a different sub-network, a dedicated node, the router, requires routes. For example, you can define
static IP routes to link sub-networks.
Static routes do not scale and are not error-free. They should be used only when dynamic routing protocols cannot
be deployed, or in case of very simple topologies.
You can implement static routing by directly manipulating the equipment routing table. It may be used with any
dynamic routing protocol. When both static and dynamic routes are set, the static ones are preferred because their
administrative distance is 1.
To add a static route, do:
The same configuration can be made using this NETCONF XML configuration:
vrouter running config# show config xml absolute vrf main routing static
<config xmlns="urn:6wind:vrouter">
<vrf>
<name>main</name>
<routing xmlns="urn:6wind:vrouter/routing">
<static>
<ipv4-route>
<destination>10.200.0.0/24</destination>
<next-hop>
<next-hop>10.125.0.2</next-hop>
</next-hop>
</ipv4-route>
</static>
</routing>
</vrf>
</config>
See also:
• The command-reference for details.
Policy-Based Routing
Turbo Router supports multiple routing tables. By default, routes are set in the main table as explained above. For
PBR, it is possible to specify the table to use using an identifier. See the Policy-Based Routing section for details.
To add a static route in a specific table, do:
vrouter running config# show config xml absolute vrf main routing static
vrouter running config# show ipv4-routes vrf main table 100
vrouter running config# show config xml absolute vrf main routing static
<config xmlns="urn:6wind:vrouter">
<vrf>
<name>main</name>
<routing xmlns="urn:6wind:vrouter/routing">
<static>
<ipv4-route>
<destination>10.200.0.0/24</destination>
<next-hop>
<next-hop>10.175.0.2</next-hop>
<table>100</table>
</next-hop>
</ipv4-route>
</static>
</routing>
</vrf>
</config>
It is possible to enable a failover mechanism that relies on nexthops configured in static routes. By monitoring
with BFD that nexthop, the route will be either validated or invalidated, according to BFD status. This mechanism
enforces the reachability. To get more information on BFD, please see BFD.
Below example illustrates how a BFD peer session context is created, associated to next-hop 10.125.0.2.
vrf customer1
routing static ipv4-route 10.200.0.0/24 next-hop 10.125.0.2 track bfd
Then you can continue the configuration as usual. For timer settings, the default emission and reception settings are
set to 300000 microseconds, which may not be what is wished. In that case, it is possible to override default timers,
by configuring general timer settings. More information is given in Configuring general BFD settings.
It’s also possible to configure a BFD or ICMP tracker manually. This enables using the same tracker in different
services. An example is available in the BGP configuration and monitoring using trackers documentation.
More information about tracker can be found in Tracker guide.
Routing utilities
Routing packets requires to handle the core element of a routing table : the prefix. Prefix is generally an IPv4 or
an IPv6 address associated with a mask. There are needs on routing protocols to have tools that permit apply some
filtering. This is true for BGP, but it is also true for OSPF. Some information is given about 2 useful tools that are
used on the above mentioned routing protocols : IPv4 Access-Lists and IPv4 Prefix-List.
Also, this chapter presents the route-map object. This objects works on the match/set mechanism. It is feeded by
input given by routing protocols, and it returns an output that is modified to be conform with the set rules contained
in the route-map.
Finally, this chapter gives an overview about routing priorities between the various routing protocols, by explaining
the distance.
• IPv4/IPv6 Access-Lists
• IP Prefix List
• Route-Maps
• Routing Administrative Distance
• Logging
IPv4/IPv6 Access-Lists
As described, a prefix will match an access-list entry if that prefix is included in that access-list entry. It is possible
to override the behaviour with the exact-match keyword so that the access-list will need to match the exact prefix
value.
Conversely, it is possible to create IPv6 Access List:
IP Prefix List
A prefix filter is more powerful than an access-list filter to process the network prefixes.
In comparison to access-list prefix-list have the following advantages:
• Can process a range of values
• Performance improvement in prefix lookup of large lists
• More flexible
Filtering by prefix list involves the following rules :
• An empty prefix list permits all prefixes.
• An implicit deny is assumed if a given prefix does not match any entries of a prefix list.
• When multiple entries of a prefix list match a given prefix, the longest match is chosen.
• The router prefix-list lookup begins at the top with sequence number 1, if a match occurs then the router do
not go through the rest of the prefix list.
The syntax to define a prefix filter is:
Let P1/m be a network prefix that matches PREFIX/M. For example PREFIX/M could be 192.168.0.0/16 and P1/m
could be 192.168.10.0/24.
Moreover, if A and B are defined, P1/M matches this rule if M is greater or equal than A and if M is less or equal
to B (A ( M ( B). For example 192.168.10.0/24 matches the rule 5, however it does not match the rule 10.
route-map:
match ip address prefix-list FILTER-NAME
match ipv6 address prefix-list FILTER-NAME
(continues on next page)
neighbor configuration:
neighbor A.B.C.D address-family ADDRESSFAMILY
prefix-list {in|out} prefix-list-name FILTER-NAME
Note:
• The command ‘match ip/ipv6 address’ can be used with an access-list too. However, you can check that the
syntax is not exactly the same: match ip address prefix-list FILTER-NAME vs. match ip address
access-list ACCESS-LIST-NAME.
Route-Maps
Route-Maps operate on the match/set mechanism. it applies a set of actions to the incoming entries that matches
the set criteria. Incoming entries stand for routing information. For instance, BGP updates.
To create a route-map object, use the following command:
Note: Some route-map actions and/or match conditions can be protocol-specific (for instance matching on
community-id makes sense only for BGP). If the associated protocol is not configured and activated, the specific
items will not be displayed in a show state but will still be visible on a show configuration.
Actually, even if prefixes can be filtered, the origin of the route entry is kept, and a weight is associated to each
route entry, according to the origin of the routing protocol. That weight is called the administrative distance. For
instance, if the same prefix has 2 entries in both static routing table, and BGP routing table, the prefix with the least
administrative distance will be chosen locally and installed in the system. Here it will be the static routing table.
We give here a reminder of the common routing protocols administrative distance:
Logging
Routing logging options are configurable from the global routing context:
All logs are sent to the daemon syslog facility. By default, only messages of severity higher than error are logged.
This can be modified by changing the level option:
severity description
emergency System is unusable.
alert Action must be taken immediately.
critical Critical conditions.
error Error conditions.
info Informational messages.
notice Normal but significant conditions.
warning Warning conditions.
debug Debug-level messages.
The verbosity of these logs is configurable per routing protocol. See the routing global command reference guide
for details.
BGP
BGP Overview
As the Internet is composed of many ASes (Autonomous Systems): ISPs, universities, multi-homed networks. . .
the inter-AS (Autonomous System) routing policies are getting more and more complex. BGP is the today’s EGP
(External Gateway Protocol), which handles these policies between the ASes. The border gateway is the router that
interconnects many ASes. BGP allows you to create loop-free interdomain routing between ASes.
IGP : AS 4
iBGP
TCP/179
eBGP
TCP/179
IGP : AS 3
IGP : AS 1
IGP
eBGP: OSPF, RIP
AS 2
TCP/179
Fig. 2: The EGP (BGP) vs. the IGPs (Internal Gateway Protocols) (RIP, RIPng, OSPF v2, OSPF v3)
BGP came up at the beginning of the 90’s. The first RFC of BGP was published in 1989. The today’s BGP is
referred to as BGP 4, which was described by the RFC 1771 (https://tools.ietf.org/html/rfc1771.html). It is an
exterior routing protocol that distributes some network reachability information. These network information are a
set of network prefixes, which could be either IPv4 or IPv6 network prefixes; and the reachability information are
a list of ASNs (Autonomous System Numbers) that are crossed to reach some network prefixes.
BGP runs over the unicast TCP on the well-known port 179. The same TCP port is used for both IPv4 and IPv6.
Any two routers which have established a TCP connection to exchange BGP routing information are called BGP
peers or BGP neighbors. The two peers begin by exchanging their full BGP table, then incremental updates are sent
when the routing tables change.
When BGP is running between two routers belonging to different ASes it is called Exterior BGP, sometimes refer-
enced as eBGP. When the two routers belong to the same AS it is called interior BGP, referenced as iBGP.
In routing protocols design rules, the BGP routing protocol is mainly used to exchange routing information between
different Autonomous Systems. Within the same AS, routing information is exchanged through an IGP (Internal
Gateway Protocol) routing protocol like RIP or OSPF.
Today, BGP is used to establish peering for various usages:
• Transit peering: Forwarding data to/from other ISP’s networks.
• Downstream peering: Forwarding data to/from enterprises.
• Private peering: Establish VPN connectivity for customers with multiple sites, for instance. L3VPN and
L2VPN (Layer 2 Virtual Private Network) are some use cases.
• Public peering with IXP (Internal Exchange Point) to benefit from numerous partners.
The BGP is handled by FRR (https://frrouting.org/).
Turbo Router provides the following features:
RFC 1771 (https://tools.ietf.org/html/rfc1771.html): A Border Gateway Protocol 4 (BGP-4 (Border Gateway
Protocol 4))
RFC 1997 (https://tools.ietf.org/html/rfc1997.html): BGP Communities Attribute
RFC 2545 (https://tools.ietf.org/html/rfc2545.html): Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-
Domain Routing
RFC 4364 (https://tools.ietf.org/html/rfc4364.html): BGP/MPLS IP Virtual Private Networks (VPNS)
RFC 2796 (https://tools.ietf.org/html/rfc2796.html): BGP Route Reflection An alternative to full mesh iBGP
RFC 2858 (https://tools.ietf.org/html/rfc2858.html): Multiprotocol Extensions for BGP-4
RFC 3065 (https://tools.ietf.org/html/rfc3065.html): AS confederations for BGP
RFC 4360 (https://tools.ietf.org/html/rfc4360.html): BGP Extended Communities Attribute
RFC 4456 (https://tools.ietf.org/html/rfc4456.html): BGP Route Reflection: An Alternative to Full Mesh Inter-
nal BGP
RFC 4384 (https://tools.ietf.org/html/rfc4384.html): bgp/mpls IP Virtual Private Networks (VPNs)
RFC 5575 (https://tools.ietf.org/html/rfc5575.html): Dissimination of Flow Specification Rules
RFC 6793 (https://tools.ietf.org/html/rfc6793.html): BGP support for Four-Octet Autonomous System (AS)
Number Space
RFC 7911 (https://tools.ietf.org/html/rfc7911.html): Advertisement of Multiple Paths in BGP
RFC 8093 (https://tools.ietf.org/html/rfc8093.html): BGP Large Communities Attribute
RFC 8212 (https://tools.ietf.org/html/rfc8212.html): Default External BGP Route Propagation Behavior without
Policies
RFC 7432 (https://tools.ietf.org/html/rfc7432.html): BGP Large Communities Attribute
RFC 8365 (https://tools.ietf.org/html/rfc8365.html): A Network Virtualization Overlay solution Using Ethernet
VPN (EVPN)
BGP configuration
There are a list of necessary elements to know when forging a BGP configuration.
When forging a BGP configuration, the local AS number, and the remote AS number, as well as the remote IP
address have to be known in order to establish peering.
An AS is an administrative set of routers, depending on an administrative authority. There are public or assigned
ASes, and private ASes. An ASes is identified by a number called ASN (Autonomous System Number).
The public ASNs are any registered ASN values that are not private. These ASNs are assigned by a RIR (Regional
Internet Registry). The private ASNs are made up of 2 ranges that can be used for local administration. These
numbers are 64512 through 65535, and 4200000000 through 4294967294.
BGP has been extended to exchange routing information not only for IPv4 routing tables, also other routing infor-
mation like IPv6, or for other purpose: flowspec, or L3VPN or L2VPN. The address-family command allows us
to identify the network protocol. It is made up of a pair of arguments AFI, SAFI. For instance, by default, IPv4,
unicast is enabled and stands for the routing information of IPv4.
Here below is an example on how to configure a sample BGP configuration with both IPv4 and IPv6 address-family
set:
vrf main
routing
bgp
(continues on next page)
The same configuration can be made using this NETCONF XML configuration:
vrouter running config# show config xml absolute vrf main routing bgp
<config xmlns="urn:6wind:vrouter">
<vrf>
<name>main</name>
<routing xmlns="urn:6wind:vrouter/routing">
<bgp xmlns="urn:6wind:vrouter/bgp">
<router-id>10.125.0.1</router-id>
<as>65501</as>
<neighbor>
<neighbor-address>10.125.0.3</neighbor-address>
<address-family>
<ipv6-unicast>
</ipv6-unicast>
</address-family>
<remote-as>65502</remote-as>
</neighbor>
</bgp>
</routing>
</vrf>
</config>
Configuring various address-family means that there are subtle differences between each address-family, that permit
benefiting from each specificity.
For instance, IPv6, unicast address-family provides 2 IPv6 next-hops : the local one and the global one.
Also, IPv4, vpn is the L3VPN combination for MPLS tunnels. While the routing information exchanged deals with
inner IPv4 information, the MPLS VPN (Virtual Private Network) SAFI (Subsequent Address-Family Identifier)
implies that the overlay will be based with MPLS. The nexthop information will stand for underlay tunnel end point
information. Here, the nexthop may be either IPv4 or IPv6, independently of the inner IPv4 prefix. The nexthop
will also contain the MPLS label identifier.
Note: You can also disable BGP, either by suppressing the configuration:
vrf main
del routing bgp
..
Alternatively, if you don’t want to lose the configuration, and disabling BGP configuration, you can use following
command:
vrf main
routing bgp
enabled false
This method can be used if the user wants to force peering with remote BGP speakers. Consecutively changing the
state of BGP will force the peering. Here, below illustration indicates how the session for 10.125.0.3 is flushed.
Note that this command can also selectively flush different parts of the routing tables, like ADJ-RIB-IN (Adjacency
RIB Inbound) by issuing the soft in prefix at the end of the command. An other possibility is to disable the whole
BGP instance.
vrf main
routing bgp enabled false
commit
routing bgp enabled true
commit
10.1.1.0/28
The above diagram depicts 3 devices, each one has a BGP instance that peers with each other. The 3 devices
configuration is like below:
rt1
routing bgp
router-id 10.1.1.1
as 65500
neighbor 10.1.1.2 remote-as 65510
neighbor 10.1.1.3 remote-as 65520
address-family ipv4-unicast redistribute connected
..
..
interface
physical eth1_0
ipv4 address 192.168.1.0/24
..
..
physical eth0_0
ipv4 address 10.1.1.1/28
(continues on next page)
rt2
routing bgp
router-id 10.1.1.2
as 65510
neighbor 10.1.1.1 remote-as 65500
neighbor 10.1.1.3 remote-as 65520
address-family ipv4-unicast redistribute connected
..
..
interface
physical eth1_0
ipv4 address 192.168.2.0/24
..
..
physical eth0_0
ipv4 address 10.1.1.2/28
..
..
rt3
routing bgp
router-id 10.1.1.3
as 65520
neighbor 10.1.1.1 remote-as 65500
neighbor 10.1.1.2 remote-as 65510
address-family ipv4-unicast redistribute connected
..
..
interface
physical eth1_0
ipv4 address 192.168.3.0/24
..
..
physical eth0_0
ipv4 address 10.1.1.3/28
(continues on next page)
After having executed the three configurations, the status of the BGP connections can be obtained. The peerings
between the devices can be visualised with the following command:
The output of the state column must be blank in case the BGP connection is established, otherwise it reflects the
state of the BGP connection. The different BGP session states are studied later in the section. Following command
gives detailed BGP information about a given neighbor:
It is also possible to dump the list of BGP entries that rt1 learnt from the other peers, by using following command
on configuration mode:
Peer-groups
Scaling BGP deployments may be useful, when one deploys multiple instances of BGP. Instead of configuring each
peer one by one, it is possible to configure peer groups.
A peer group is defined by a name, and is being applied the same configuration as the one applied to a single peer
IP, except for the IP addressing of that peer.
You can use a peer group configuration so as to define some peers with outgoing peering, with the inherited config-
uration coming from the peer-group. You can also use a peer group to permit incoming peering connections, like a
server would do. Below configuration illustrates the usage of a peer group named group:
routing bgp
listen
neighbor-range 10.135.0.0/24 neighbor-group group
..
as 65502
neighbor-group group
address-family
ipv6-unicast
..
..
remote-as 65501
update-source 10.135.0.2
..
neighbor 10.145.0.2
neighbor-group group
..
..
By default, the BGP instance will create up to 100 maximum peering connections. This is a configuration limit that
can be modified to increase the maximum number of peering connections to support:
routing bgp
listen limit 5000
..
With that extra configuration, incoming BGP connections that match its settings will be able to be peered up to
that new limit. It is also possible to limit the number of accepted incoming connections by establishing a range of
potential IP addresses, like the above example illustrates.
Note: When configuring and handling a huge number of peering connections, for example with values above 5000,
you may experience some timeout issues on the BGP connections. This is due to the increased time of processing the
incoming BGP packets. This time can be reduced by increasing the number of BGP packets to be processed by I/O
cycle. When a huge number of peering connections is used, it is recommended to use the following configuration
command:
routing bgp
packet-rw-quantum read 64
packet-rw-quantum write 200
..
As you can see, the packet-rw-quantum write value has been increased accordingly. It is recommended to keep
that value above packet-rw-quantum read value, if you do not want to experience memory exhaustion due to
accumulation of buffers in BGP process.
Note: With such big number of sessions, it may be wishable for the server to detect the failure of remote endpoint
as quick as possible. One possibility consists in enabling tcp-keepalive parameter. tcp-keepalive packets
need to be replied at remote TCP endpoints with ack packet. After a defined consecutive number of probes where
ack is not seen, TCP session is considered as down. Below configuration detects a failure of 3 probes send each 2
seconds.
routing bgp
tcp-keepalive idle 2 keepalive 2 probes 3
..
Route-Reflector
Route reflector is used in iBGP networks, where the number of BGP peers becomes too important. Instead of using
a full mesh peering, a 1-N peering topology is used. A single ( or two, in case backup is needed) BGP instance
acts as route reflector server, and receives/replies BGP updates from/to route reflector clients accordingly. This
permits scaling some setups. Creating a route reflector server consists in defining an IBGP peering session, either
via peer-group or by defining directly a peer. The option route-reflector-client must be set to true.
as 65501
neighbor-group group
address-family
ipv4-unicast
route-reflector-client true
..
..
remote-as 65501
neighbor 1.1.1.1
address-family
ipv4-unicast
route-reflector-client true
..
..
(continues on next page)
Multipath
BGP multipath permits to create ECMP routes, so that traffic can be load-shared on all the available routing entries.
By default, BGP know how to handle up to 8 ECMP route entries. It is possible to reduce per the number of
maximum-paths per address-family, and for both iBGP or eBGP sessions. Here is a configuration example, on how
to disable multipath for IPv4, unicast BGP:
router-id 10.125.0.1
address-family
ipv4-unicast
maximum-path
ebgp 1
ibgp 1
..
..
..
as 65501
The multipath is criteria are strict by default. That means that even if as-path attribute that goes along with the
prefixes differs, then the load-sharing will fail. There are some mitigations methods that permit relax the load
sharing. For instance, the as-path attribute list can be completely ignored with following command, thus permitting
to do load sharing across paths that do not share at all same path-list.
bestpath
as-path
ignore true
..
..
It is also possible to find an intermediary point, by taking into account only prefixes that share different path list,
but same as-path list count.
bestpath
as-path
multipath-relax as-set
..
..
BGP supports advertisements of multiple paths. This is an extra identifier that is encoded in the NLRI (Network
Layer Reachability Information) of the packet. It contains a separate identifier. For instance, it permits to transmit
2 ECMP entries that will be differentiated by that identifier. To enable encoding of the prefix with the add-path
option, use the following configuration command:
neighbor 10.125.0.3
remote-as 65502
address-family
ipv4-unicast
addpath
tx-all-paths true
..
..
..
..
The BGP routing protocol is very rich and offers many options. In this paragraph we will study the most used and
useful BGP options.
• Aggregation
– No aggregation flags
– Summary-only aggregation flag
– As-set aggregation flag
– Combined summary-only and as-set aggregation flags
• Confederation
• Overriding AS
• AS-Path prepending
• EBGP policy requirement
• Timers
• Routing Reconfiguration
– Route refresh
• BGP graceful restart capability
• BGP unnumbered
Aggregation
The main goal of aggregation is to summarize the number of network prefixes that are announced into the Internet.
In fact, aggregation is a requirement when the mask length is too great. Your peers or the peers of your peers will
filter some of them. They may want to reduce the number of prefixes.
However, the route aggregation can introduce some network loops or some black holes when it is not set properly.
Note:
• A BGP router can advertise an aggregated network only if one route of the aggregate network is in the BGP
table. For example if we consider four networks 192.168.0.0/24 through 192.168.3.0/24, the BGP router
can advertise the aggregate network 192.168.0.0/22 only if at least one network (192.168.1.0/24 through
192.168.3.0/24) is in the BGP table.
• If all the sub-networks of an aggregated network go down, this aggregated network will not be advertised.
• It is recommended to check that the aggregated network is not stopped by an Access List.
192.168.2.0/24
192.168.3.0/24
The aggregation of the IPv4 network prefixes within the BGP tables can be done with the following command:
The aggregate command originates a new prefix. However, how to summarize the different AS-PATH ? There are
two solutions:
• The AS-PATH is suppressed, although some network loops could be introduced.
• The AS-PATH is summarized within an unordered set (AS-SET), although some black hole could be created.
No aggregation flags
When neither the summary-only flag nor the as-set flag are set, a route with the aggregated PREFIX/M is origi-
nated from the BGP router. However the sub-prefixes are still advertised.
Example
routing bgp
as 65500
address-family
ipv4-unicast
network 192.168.3.0/24
..
network 192.168.2.0/24
..
aggregate-address 192.168.0.0/22
..
..
neighbor 10.1.1.1
remote-as 65510
..
neighbor 10.1.1.6
remote-as 65530
..
After rt1 device peers with rt2, and rt2 peers with rt3, rt1 can receive following rib entries :
Note:
• The aggregated prefix has the attribute atomic-aggregate, which means that the AS information is lost for the
aggregate prefix (192.168.0.0/22).
• Not to advertise the aggregated prefix, the flag summary-only can be set. Or a prefix-list or a distribute-list
can be defined.
When the summary-only flag is set and the as-set flag is not set, only the route with the aggregated PREFIX/M is
originated from the BGP router. The sub-prefixes are not advertised. Moreover the ID of the router is set within the
AS-PATH to help traffic engineering.
Example
If the flag summary-only is set, the router will only advertise the aggregate prefix. We can notice that on the router
which is advertising the aggregate prefix, the sub-prefixes have been suppressed, the remote peers will only see the
aggregate prefix.
When the summary-only flag is not set and the as-set flag is set, a route with the aggregated PREFIX/M is originated
from the BGP router. Moreover the information of the previous AS-PATHs is collected into an unordered list called
an AS-SET. This AS-SET, that is included within the new AS-PATH originated by the router, can help to avoid
some networks loops. However the sub-prefixes are still advertised.
When both the summary-only and the as-set flags are set, a route with the aggregated PREFIX/M is originated
from the BGP router. Moreover the information of the previous AS-PATHs is collected into an unordered list called
an AS-SET. This AS-SET, that is included within the new AS-PATH originated by the router, can help to avoid
some networks loops. The sub-prefixes are no longer advertised.
as-set true
By taking following example, rt1 will receive aggregated prefix with the as-set set.
Confederation
A confederation is a set of many private ASes that are joined to be advertised as a single AS. A confederated AS is
a confederation of many ASes that are joined by eBGP and that are themselves running an IGP.
The use cases are:
a. Join independent ASes into a single AS.
b. support multi-homed customers with a same ISP (Internet Service Provider).
c. Avoid the scaling issues of the full-mesh eBGP routers.
• Configure a BGP confederation:
Example
AS 65500
RT5 172.16.255.253/30
172.16.0.0/30
AS 65520
172.16.255.254/30
RT1 RT3
10.1.1.11/29
10.1.1.9/29 10.1.1.1/29
AS 65521 10.1.1.10/29 AS 65522 10.1.1.2/29
RT2 RT4
192.168.2.0/24 192.168.4.0/24
rt1
vrf main
interface physical eth0_0
ipv4 address 10.1.1.9/29
..
interface physical eth1_0
ipv4 address 172.16.255.254/30
..
routing bgp
as 65521
neighbor 10.1.1.11 remote-as 65522
neighbor 10.1.1.11 address-family ipv4-unicast route-map out route-map-name␣
˓→change_nexthop
rt2
vrf main
interface physical eth0_0
ipv4 address 10.1.1.10/29
..
interface physical eth1_0
ipv4 address 192.168.2.1/24
..
routing bgp
as 65521
neighbor 10.1.1.9 remote-as 65521
confederation identifier 65520
address-family ipv4-unicast network 192.168.2.0/24
..
..
rt3
vrf main
interface physical eth0_0
ipv4 address 10.1.1.11/29
..
interface physical eth1_0
ipv4 address 10.1.1.1/29
..
interface loopback loop
ipv4 address 192.168.3.1/24
..
routing bgp
as 65522
neighbor 10.1.1.9 remote-as 65521
neighbor 10.1.1.2 remote-as 65520
confederation identifier 65520
confederation peers 65521
address-family ipv4-unicast network 192.168.3.0/24
..
..
rt4
vrf main
interface physical eth0_0
ipv4 address 192.168.4.1/24
..
interface physical eth1_0
ipv4 address 10.1.1.2/29
..
routing bgp
as 65522
neighbor 10.1.1.1 remote-as 65522
confederation identifier 65520
address-family ipv4-unicast network 192.168.4.0/24
..
..
rt5
However, when rt5 peers with rt1, it peers to the AS 65520 that is rt1’s BGP confederation identifier. It does not
peer to the AS 65521 that is internal to the AS 65520:
vrf main
interface physical eth0_0
ipv4 address 172.16.0.1/16
..
interface physical eth1_0
ipv4 address 172.16.255.253/30
..
routing bgp
as 65000
neighbor 172.16.255.254 remote-as 65522
address-family ipv4-unicast network 172.16.0.0/16
..
..
• Check this configuration on rt3 that displays the confederation path between parenthesis. The fib can also be
dumped.
Note: if a route-map had not been added to rt1, 172.16.0.0/16 would not have been visible in rt3, because it has no
route to 172.16.255.253. It is a feature of BGP that requires to work with an IGP to resolve the recursives routes
that do not have a directly connected gateway. Moreover, it means that the eBGP sessions between the confederation
sub-ASes do not change the next hop attribute.
For example, you could add RIP or OSPF v2 on rt1, rt2, rt3 and rt4 that will be the IGP of all the AS65520.
Overriding AS
When working with both public BGP peers and private BGP peers, it is wished to have one single BGP instance,
and in the same time, having the ability to override the default AS value. This can be done by using local-as value,
where it is possible to override default AS value by the one that is set as local-as value.
Following configuration illustrates what the configuration could be. real AS value (65000 here) is hiddent behind
64512. Remote peer only sees 64512 value.
vrf main
routing bgp
as 65000
neighbor 10.125.0.2 remote-as 64622
neighbor 10.125.0.2 local-as as-number 64512 no-prepend true replace-as true
..
..
..
AS-Path prepending
On some situations, it is also wished to modify the as-path list. For instance, on transit routers, the as-path list
may be enlarged in order to influence incoming traffic. Actually, by increasing the as-path list size, BGP best path
selection algorithm may pick up the routers with the shortest as-path list.
The following route-map configuration can be applied to outgoing prefixes exchanged with BGP peers. as-path
prepending action will prepend as-path values to the original as-path list. The priority number configured will
determine which as-path value to insert first.
For instance, below route-map will prepend {65500, 65100} in the as-path list following the configured order 10,
20.
vrf main
routing bgp as 65500
..
routing
ipv4-prefix-list blocka
seq 10 address 10.0.0.0/8 policy permit
..
route-map bgp-export-block
seq 10
policy permit
match
ip
address
prefix-list blocka
..
..
..
set
as-path
prepend
asn 20
65100
..
asn 10
65500
..
..
..
ip
next-hop 184.106.55.69
When interoperating with eBGP peers, route propagation may become riskier if no policies are set up on those peers.
RFC 8212 (https://tools.ietf.org/html/rfc8212.html) enforces that policy by checking that incoming and outgoing
filters are applied for eBGP sessions. With this policy, no route will be either accepted ( if no incoming filter) nor
announced (if no outgoing filter). Below command can be used to enforce the behavior:
Timers
Tip: A good practice is to configure the same value on both sides of the TCP connection. Generally, these values
should not be changed; however when the processing time of the BGP table is too long for the CPU to fire the
keepalive timer, the later could be increased.
Routing Reconfiguration
Some configuration items may need the BGP routing tables to be refreshed. This is the case for multipath configu-
ration. Enabling multipath needs to analyse all the routing table to see if there are ECMP entries.
BGP provides 2 mechanisms to permit this refresh:
• either by issuing BGP route refresh messages to remote peers. This message asks remote peer to send back
all BGP updates for a defined (AFI (Address Family Identifier), SAFI) address-family.
• or by enhancing software reconfiguration inbound. An inbound RIB is created for each peer, for a defined
(AFI, SAFI). This is the ADJ-RIB-IN. All incoming BGP updates are stored in ADJ-RIB-IN and are kept
unmodified. This permits reinjecting original BGP updates of remote peer, when needed. Enhancing software
reconfiguration inbound can be configured on each address-family node.
The routing reconfiguration will be automatically triggered upon some reconfiguration elements. If software recon-
figuration is not configured, then default behaviour will issue a route refresh message with remote peer.
Anytime, ADJ-RIB-IN can be flushed by using a flush command. This will force to rebuild the ADJ-RIB-IN
command by issuing update with remote peer:
Route refresh
Route refresh is an extension to BGP that is defined in RFC 2918 (https://tools.ietf.org/html/rfc2918.html). Using
this feature, a BGP router can request a complete retransmission of the peer’s routing information without tearing
down and reestablishing the BGP session, saving a route flap. It is used to facilitate routing policy changes, without
storing an unmodified copy of the peer’s routes on the local router to save memory. The capability must be supported
by both routers of a BGP session. When both routers in the peering session support this extension, each router will
respond to requests issued from the peer without operator intervention.
Route Refresh is enabled by default.
When the command flush is used, Route Refresh messages are sent to the peers, the router receives one or more
Update packets with all the routes of the Adj-RIB-Out.
Example
routing bgp
as 65000
neighbor 172.16.255.254 remote-as 65522
address-family ipv4-unicast network 172.16.0.0/16
.. .. ..
Then the peering happens. And the RIB is feeded with remote updates from remote. No need to configure the
multipath feature, since it is enabled by default.
The local peer will mark as staled the local entries learnt from the remote peer, then will send a BGP refresh message
to the remote peer. The remote peer will send back the BGP updates, and the local instance will refresh the RIB
accoringly.
Usually when BGP on a router restarts, all the BGP peers detect that the session went down, and then came up.
This “down/up” transition results in a “routing flap” and causes BGP route re-computation, generation of BGP
routing updates and flap the forwarding tables. It could spread across multiple routing domains. Such routing flaps
may create transient forwarding blackholes and/or transient forwarding loops. They also consume resources on the
control plane of the routers affected by the flap. As such they are detrimental to the overall network performance.
This feature proposes a mechanism for BGP that would help minimize the negative effects on routing caused by
BGP restart. The graceful restart capabilities (code-64) will be exchanged between the BGP speakers through the
open messages. Routes advertised by the restarting speaker will become stale in the peer speakers’ routing table.
On expiry of restart time the stale routes will be deleted if the restarting speaker does not come up. Once
the restarting speaker re-establish the BGP session within the restart time the stale routes will be converted to
normal routes. Traffic flow through the stale routes will not be stopped while the BGP speaker is restarting.
• Enable BGP graceful restart:
BGP unnumbered
This feature permits to establish BGP connected peering using link local ipv6 addresses, without having to provision
additional ip addresses. On a given interface, BGP requests to enable router advertisement service to discover
neighbor ipv6 link local addresses. This permits to receive router advertisements messages from remote peer, and
identify the remote ipv6 link local address to connect to with BGP.
The feature can be configured by mentioning the interface BGP should establish a peering over. Below back to back
setup between 2 devices illustrates what should be done:
rt1
vrf main
interface physical eth2
port pci-b0s5
.. ..
routing bgp
as 65000
router-id 1.1.1.1
neighbor-group group
capability extended-nexthop
remote-as 65000
address-family ipv6-unicast
.. .. ..
address-family ipv4-unicast
network 10.100.0.0/24
.. .. ..
address-family ipv6-unicast
network 10:100::/64
.. .. ..
unnumbered-neighbor eth2 neighbor-group group
unnumbered-neighbor eth2 ipv6-only true
.. ..
rt2
vrf main
interface physical eth2
port pci-b0s5
.. ..
routing bgp
as 65000
router-id 1.1.1.2
neighbor-group group
capability extended-nexthop
remote-as 65000
address-family ipv6-unicast
.. .. ..
address-family ipv4-unicast
network 10.200.0.0/24
.. .. ..
address-family ipv6-unicast
network 10:200::/64
.. .. ..
unnumbered-neighbor eth2 neighbor-group group
unnumbered-neighbor eth2 ipv6-only true
.. ..
To check the peering status on the given interface, use the following command:
Hostname: rt2
Member of peer-group group for session parameters
BGP version 4, remote router ID 1.1.1.2, local router ID 1.1.1.1
BGP state = Established, up for 00:00:22
Last read 00:00:21, Last write 00:00:21
Hold time is 180, keepalive interval is 60 seconds
Neighbor capabilities:
4 Byte AS: advertised and received
AddPath:
IPv4 Unicast: RX advertised IPv4 Unicast and received
IPv6 Unicast: RX advertised IPv6 Unicast and received
Extended nexthop: advertised and received
Address families by peer:
IPv4 Unicast
Route refresh: advertised and received(old & new)
Address Family IPv4 Unicast: advertised and received
(continues on next page)
The resulting BGP routes learnt from remote peer are injected into the dataplane.
Note: BGP unnumbered works only when there is only one neighbor per interface. Peering with multiple neighbors
on the same interface is not supported.
BGP security
BGP is used for inter-domain routing, so it is a critical service for the Internet infrastructure. Therefore security
aspect of BGP, with valid routing advertisement, is a high issue and the current system is highly vulnerable to human
errors, as well as a wide range of attacks.
Filtering is currently the most used mechanism. Nevertheless complementary security features may be used to
add security with BGP. Thus, in some cases MD5 authentication may be used to control BGP routing information
advertisement, as described for OSPF.
• BGP filtering
– Configuring a BGP-4 distribute list
– Configuring a BGP-4 prefix list
– Communities Filters
• BGP Authentication
BGP filtering
Once an IPv4 Access List is created, it is possible to apply this access-list to a neighbor. The number of prefixes
will be modified/filtered so that the neighbor will not see the exact entries that local device sees.
Following configuration illustrates 2 devices rt1 and rt2, where rt2 is configured to apply filtering by using distribute
list.
rt1
routing bgp
router-id 10.1.1.1
as 65510
neighbor 10.1.1.2 remote-as 65520
rt2
routing
ipv4-access-list acl_name
remark description
deny 192.168.1.0/24
permit any
..
..
vrf main
routing bgp
router-id 10.1.1.2
address-family ipv4-unicast network 192.168.1.0/24
.. .. ..
address-family ipv4-unicast network 192.168.2.0/24
.. .. ..
as 65520
neighbor 10.1.1.1 remote-as 65510
neighbor 10.1.1.1 address-family ipv4-unicast distribute-list out access-list acl_
˓→name
..
..
..
Note: The below IPv4 prefix-list should be preferred to the IPv4 access-lists.
Communities Filters
The attribute community permits to group destinations in a community and apply routing decisions. It is an optional,
global transitive attribute in the numerical range of 1 to 4,294,967,200. Based on the community, you can control
the routing information. In BGP there are some predefined well known communities which are:
no-export The routes of this community must not be advertised to external peer. Value is 0xFFFFFF01.
no-advertise The routes must not be advertised to any peer. Value is 0xFFFFFF02.
internet The routes may be advertised to any peer. Value is 0x0.
local-as Used in confederation to avoid sending packets outside the local AS. Value is 0xFFFFFF03.
In general, BGP community has the form of AS:NN where AS is the autonomous system number, and NN is a
number.
In addition to communities, BGP introduced one new kind of communities : extended communities. It extends
the range of values. For instance, extended community can be used to store 4 AS byte value, while community is
generally used to encode only 2 AS value. The format changed compared with community, because the serviecs are
different ( for instance, L3VPN services benefit from route target extended communities).
Both communities are used to apply filtering on incoming or outgoing BGP updates. This can be done by using
route-maps.
The community and extended attribute is sent to neighbors by default with the option both (standard and extended
commnunity):
The community’s or extented community’s policies are examined in the priority order for each prefix. As soon as
a policy matches a prefix, the desired behaviour (permit or deny) is applied (when used in a “match community id
<community name>” clause of a route-map: it’s a match/it’s not a match) and the processing stops for this prefix.
There is also an implicit final deny policy in each community list that rejects any prefix that did not match any
previous defined policies. A policy applies to a prefix if and only if all of its communities are set on the prefix.
More information about how to configure BGP communities lists and BGP extended communities lists can be found
below.
Community list
Community list is a group of rules which permit to filter or set attributes based on different lists of community
numbers.
Community list has two types. It could be either a standard community list or an expanded community list.
Standard community list defines communities attributes. Thus, it will be directly compared to BGP communities
attribute in BGP updates.
On the other hand, expanded community list defines its communities attribute in a string with regular expression.
A community list is used in a match clause of a route map. To illustrate a use case, prefixes learnt from various
transit providers may bring such information per prefix. It may be desirable to append its own community tag based
on the incoming community tags already present. The syntax of community list usage in route-map is the following
one:
routing
route-map rmap_name
seq 11 policy permit|deny
seq 11 match community id com_name exact-match true
For example, the following configuration will redistribute any prefix having at least one of the communities
22850:65101 or 22850:65102:
routing
route-map myrmap
seq 1
policy permit
match
community id MYCLIST
..
bgp
community-list MYCLIST
policy 1 permit 22850:65101
policy 2 permit 22850:65102
But, the following configuration will redistribute any prefix having both communities 22850:65101 and
22850:65102:
routing
route-map myrmap
seq 1
policy permit
match
community id MYCLIST
..
bgp
community-list MYCLIST
policy 1 permit 22850:65101 22850:65102
An extended community list is a group of rules which permit to filter or set attributes based on different lists of
extended community numbers.
Extended community list has two types: standard and expanded extcommunity lists.
A standard extended community list is based on BGP extended community attribute. Two kinds of communities
can be created : route-target ( RT (Route Target)), and site-of-origin ( SOO (Site Of Origin)). The former is used to
define import and export policies across the vrfs, while the latter is used to prevent routing loops between sites.
An expanded extended community list uses regular expression to match extended communities attribute in BGP
updates.
An extended community list is used in a match clause of a route map. Like for community lists, extended com-
munity lists can be used for receiving prefixes from transit provider, that need to be appended with some extended
communities tags accordingly. The syntax of extended community list usage in route-map is the following one:
routing
route-map rmap_name
seq 11 policy permit|deny
seq 11 match extcommunity ecom_name_1
For example, the following configuration will redistribute any prefix having at least one of the extended communities
soo 65501:43 or rt 10.125.0.1:54:
routing
route-map myrmap
seq 1
policy permit
match
extcommunity MYXCLIST
..
bgp
extcommunity-list MYXCLIST
policy 1 permit soo 65501:43
policy 2 permit rt 10.125.0.1:54
But, the following configuration will redistribute any prefix having both extended communities soo 65501:43 and
rt 10.125.0.1:54:
routing
route-map myrmap
seq 1
policy permit
match
extcommunity MYXCLIST
..
bgp
extcommunity-list MYXCLIST
policy 1 permit soo 65501:43 rt 10.125.0.1:54
BGP Authentication
BGP authentication is using MD5 (Message Digest 5). This feature relies on the Operating System support for the
TCP MD5 signature option as proposed in the RFC 2385 (https://tools.ietf.org/html/rfc2385.html). This OS option
is used with the BSD-like configuration API.
The command format for BGP MD5 is as follows:
vrf main
routing bgp
neighbor 10.125.0.1 password my-secret
For information, when analyzing the BGP packets with the sniffer traffic-capture, it is possible to verify that
the option is taken into account.
BGP Flowspec
Overview
BGP flowspec introduces a new Network Layer Reachability Information (NLRI) encoding format that is used to
distribute traffic rule flow specifications. Basically, instead of simply relying on destination IP address for IP prefixes,
the IP prefix is replaced by a n-tuple consisting of a rule. That rule can be a more or less complex combination of
the following:
All below items are supported in this release.
• Network IP source/destination (can be one or the other, or both), for both IPv4 and IPv6.
• Layer 4 information for UDP (User Datagram Protocol), TCP : source port, or destination port, or any port
for both IPv4 and IPv6.
• Layer 4 information for ICMP type and ICMP code, for both IPv4 and IPv6.
• Layer 3 information : DSCP (Differentiated Services Code Point) value, Protocol type, packet length for both
IPv4 and IPv6.
• Layer 3 information : fragmentation for IPv4 suppport
• Misc layer 4 TCP flags, for both IPv4 and IPv6.
A combination of the above rules is applied for traffic filtering. This is encoded as part of specific BGP extended
communities and the action can range from the obvious rerouting (to nexthop or to separate VRF) to shaping, or
discard.
Following IETF (Internet Engineering Task Force) RFC (Request For Comment) documents have been used to
implement flowspec:
• RFC 5575 (https://tools.ietf.org/html/rfc5575.html)
• Draft Flowspec Redirect IP (https://tools.ietf.org/id/draft-ietf-idr-flowspec-redirect-ip-02.txt)
Configuration guide
In order to configure an IPv4 flowspec engine, use the following configuration. As of today, it is only possible to
configure flowspec on default VRF. To enter the BGP flowspec sub-context:
routing bgp
as 5
neighbor 1.0.0.1 remote-as 2
neighbor 1.0.0.1 address-family ipv4 flowspec
..
In a similar way, following extract illustrates how IPv6 flowspec engine can be set:
vrf main
routing bgp
as 65500
neighbor 10.125.0.2 remote-as AS
neighbor 10.125.0.2 address-family ipv6-flowspec enabled true
One nice feature to use is the ability to apply flowspec to a specific interface, instead of applying it to the whole ma-
chine. Despite the following IETF draft idr flowspec interface set (https://tools.ietf.org/html/draft-ietf-idr-flowspec-
interfaceset-03) is not implemented, it is possible to manually limit flowspec application to some incoming inter-
faces. Actually, not using it can result to some unexpected behaviour like accounting twice the traffic, or slow down
the traffic (filtering costs). To limit flowspec to one specific interface, use the following command, under BGP
flowspec family.
routing bgp
address-family ipv4-flowspec
enabled true
local-install eth1
By default, Flowspec is activated on all interfaces. Installing it to a named interface will result in allowing only this
interface. Reversely, enabling any interface will flush all previously configured interfaces.
Flowspec redirect IP
Flowspec provides also the ability for traffic to be redirected according to nexthop IP information. BGP flowspec
entries have a BGP extended community option, that tells that the flowspec information should be redirected to the
IP contained in the nexthop attribute of the BGP update received. Using that option to redirect traffic simply consists
in ensuring that the IP information is reachable through using the routing table logic. For instance, create a static
route
vrf vrf0
routing static ipv4-route 2.2.2.2/32 next-hop 10.1.2.3
An other nice feature to configure is the ability to redirect traffic to a separate VRF. This feature does not go against
the ability to configure Flowspec only on default VRF. Actually, when you receive incoming BGP flowspec entries
on that default VRF, you can redirect traffic to an other VRF.
As remind, BGP flowspec entries have a BGP extended community that contains an RT, that is to say a route target.
Finding out a local VRF based on route target consists in the following:
• A configuration of each VRF must be done, with its RT set
Each VRF is being configured within a BGP VRF instance with its own RT list. RT is defined in RFC 4364
(https://tools.ietf.org/html/rfc4364.html) and is an attribute associated to a VRF. In the VRF context, incoming
route entries have their own RT, and incoming BGP instance selects for which VRF the incoming entry is imported,
thanks to RT. route entries can be duplicated, if one route target matches several VRs. In the flowspec context,
only the first VRF matching the incoming flowpsec entry will be selected. The RT is encoded as BGP extended
communities and is 8 byte long. The first 2 byte contain the format of the RT, while the last 6 byte define the
values of the RT. Accepted format matches the following: A.B.C.D:U16, or U16:U32, U32:U16. U32 and U16
respectively stand for 4 byte integer value and 2 byte short value. Values can either be mapped to ASnumber of
VXLAN identifier in case of overlay with vxlan tunnels. A.B.C.D stands for an IP address, and can be mapped to
bgp router identifier or tunnel endpoint.
As said before, a VRF can have a list of route targets. To configure the RT list, use the following command under
BGP ipv4 unicast family:
vrf main
routing bgp
router-id 1.0.0.2
as 65500
neighbor 1.0.0.1 remote-as 65100
neighbor 1.0.0.1 address-family ipv4-flowspec enabled true
(continues on next page)
In order to illustrate, if the route target configured in the flowspec entry is 10.1.1.2:65200, then a BGP instance of
a specific VRF with the same route target will be set. That VRF will then be selected. The below full configuration
example depicts how route targets are configured and how VRF and interfaces configuration is done. Note that
the VRs are mapped on Linux Network Namespaces. For convey traffic through VRs, Cross-VRF interfaces are
needed. Basically, those are veth pair interfaces with specific properties, and without IP attributes. More information
in XVRF Interface types.
In a similar way, BGP flowspec for IPv6 uses specific ipv6 extended communities attributes, as defined in RFC
5701 (https://tools.ietf.org/html/rfc5701.html). The format of the community attribute is 20 bytes length, instead of
8 bytes length, and as such, can be used to store an IPv6 address and 2 additional extra-bytes. The format is defined
as follows :<IPV6>:AS2B.
As defined in Dissemination of Flow Specification Rules for IPv6 (https://tools.ietf.org/html/draft-ietf-idr-flow-spec-
v6-09), the BGP NLRI is sent with an extended IPv6 community attribute with community type set to 0x00 and
community sub type set to 0x0c. The BGP daemon reads the incoming parameters and compares the extended
IPv6 communnity with locally configured IPv6 route targets. The first IPv6 RT matching the incoming extended
community will represent the bgp VRF instance where traffic will be redirected to. Below example illustrates how
this can be configured:
vrf main
routing bgp
router-id 1.0.0.2
as 65500
neighbor 1.0.0.1 remote-as 65100
neighbor 1.0.0.1 address-family ipv6-flowspec enabled true
..
..
..
vrf analyser
routing bgp
as 65500
address-family ipv6-unicast
ipv6-route-target redirect-import 11::22:00
You can monitor policy-routing objects by using one of the following commands. Those command rely on the
filtering contexts configured from BGP, and get the statistics information retrieved from the underlying system. In
other words, those statistics are retrieved from linux netfilter.
About rule contexts, it is possible to know which rule has been configured to policy-route some specific traffic. The
first table identifier displayed on the former show bgp pbr iptable command can be used in the latter command
to know about routing information.
You can troubleshoot BGP flowspec, or BGP policy based routing. Ensuring that a flowspec entry has been correctly
installed and that incoming traffic is policy-routed correctly can be checked like illustrated below. First of all, you
must check whether the flowspec entry has been installed or not.
This means that the flowspec entry has been installed in a linux iptable named match0x271ce00. Once you have
confirmation it is installed, you can check whether you find the associate entry by executing following command.
You can also check whether incoming traffic has been matched by looking at counter line.
As you can see, the entry is present. Note that a linux iptable can be used to host several BGP flowspec entries.
In order to know where the matching traffic is redirected to, you have to look at the policy routing rules. The policy-
routing is done by forwarding traffic to a routing table number. That routing table number is reached by using a
linux iptable. The relationship between the routing table number and the incoming traffic is a MARKER that is set
by the iptable referencing the linux ipset. In flowspec case, linux iptable referencing the linux ipset context have the
same name.
So it is easy to know which routing table is used by issuing following command:
This allows to see where the traffic is forwarded to. Actually, in the case of redirect VRF action, a route leak has
been pushed to reach a separate VRF. Example below depicts what a route to VRF analyser looks like, since a
default route in table 257 has been installed to reach analyser.
Usually, BGP router is configured in VR main. To handle virtual routers, a separate VRF can be specified. The
routes learnt and configured will be stored in the corresponding forwarding tables. It is possible to create multiple
BGP instances on the same machine.
• Create a BGP instance on a VRF named customer1, by using following command:
vrf customer 1
routing bgp
as 54
..
..
Then you can continue the configuration as usual. The BGP peering and the redistribution will happen on the whole
VRF. All configured interfaces with addresses, and routing information on that VRF will be used.
To get routing information about BGP in that VR instance, you can use following command, that will dump all the
instances configured.
To get more information on a specific VRF, you can use following command, and the VRF name to get routing
information:
A common use case is to provide a per customer BGP peering. This use case can happen, when several customers
share physical resources of a machine, but are isolated by means of either physical interfaces or VLAN interfaces.
The following configuration gives an overview on how to create multiple BGP instances tighted with VLAN inter-
faces.
As you can see on below example, 2 instances of BGP are created, each one run over VLAN interface with its own
peer. The same autonomous system can be used for all the instances. The BGP contexts share the same system
process but will not share the same forwarding information.
vrf customer1
routing bgp
as 65555
router-id 192.168.1.1
neighbor 192.168.1.2 remote-as 65555
..
..
interface vlan vlan10
(continues on next page)
Note: With the above example, it could have been possible to use the same IP mapping for both routing entities.
An other benefit of having separate entities is that IP mapping can overlap.
An other common use case is to install cross-VRF routes between 2 BGP instances. A proposal consists in using
a mesh of BGP peerings via veth links. Below example illustrates what can be done to install cross VRF routes
routes between admin vrf and service vrf.
vrf admin
interface physical eth0
port pci-b0s5
ipv4 address 192.168.2.1/24
.. ..
interface veth service1
link-interface admin
link-vrf service1
.. ..
interface veth service2
link-interface admin
link-vrf service2
(continues on next page)
In addition to establish 2 eBGP sessions with external devices, an internal BGP peering is established between 3
VRs. Below dump gives an overview of the BGP sessions from VRF admin perspective.
Note that the above example illustrates peering with eBGP connections with external devices, but also internally
with peers on other VRs. Because /32 bit routes have been used to connect to remote veth peers, routes learnt
via those peers could not be installed locally because BGP checks against recursivity for eBGP connections. This
option has been relaxed, by using ebgp-connected-route-check command.
To distinguish the two kinds of peerings, local-as option has been used to replace the original AS number with a
private AS number to show to peers from veth links. A side effect of this usage is that the AS-PATH list is made
up of public and private ASes. To remove private AS and keep only public AS, the following command is used by
BGP before sending advertisements to external devices: as-outbound-update action remove all.
Below dump gives an extract of RIB of the configured device, and a remote device connected to VRF admin. As
you can see, on remote BGP, private ASes have been removed from AS-PATH list.
An other method to get rid of private ASes would consist in filtering the AS in incoming as-path list on the veth
peerings.
vrf admin
routing bgp
neighbor 192.168.2.2 address-family ipv4-unicast
del as-outbound-update
.. .. ..
neighbor-group local
address-family
ipv4-unicast
route-map in route-map-name alteraspath
..
..
.. .. .. ..
vrf service1
routing bgp
neighbor 10.1.2.2 address-family ipv4-unicast
del as-outbound-update
.. .. ..
neighbor-group local
address-family
ipv4-unicast
route-map in route-map-name alteraspath
..
..
.. .. .. ..
vrf service2
routing bgp
neighbor 10.2.2.2 address-family ipv4-unicast
del as-outbound-update
.. .. ..
neighbor-group local
address-family
ipv4-unicast
route-map in route-map-name alteraspath
..
..
.. .. .. ..
routing route-map alteraspath
seq 100
policy permit
match
peer 169.254.0.100
..
set
as-path
(continues on next page)
Using a full iBGP network is also an other solution to get rid of AS-PATH list handling. In that case, nexthop-self
attribute may be used under each peer address family, because the mesh will be incomplete. For instance, the peers
behind VRF admin would not be connected to peer connected behind VRF service1.
Finally, as veth is an ethernet medium like many external links, any other routing protocol can be used to transmit
routing information to remote endpoints.
The BGP4-MIB MIB (Management Information Base) is implemented. Especially, following tables are made avail-
able: bgpPeerTable, and bgp4PathAttrTable. The BGP MIB is only available for the main vrf.
Note: Some flexibility is given for bgpPeerTable, as this table will collect all peer entries from all VRs. As a
consequence, if the user configures the same peer on 2 separate VRs, only the information of the first retrieved peer
will be collected.
BGP routing protocol is very rich, and permits exchanging more complex information. With the increasing usage
of overlay information (widely used in data centers, but also deployed in ISPs), BGP evolves and is able to to carry
tunneling information through L3VPN. L3VPN stands for the ability to encapsulate IP information, into an other
payload. Here, the underlay is an IP packet, and the encapsulation used is MPLS. The overlay IP information is the
original IP packet with its payload, coming from one of the mutiple virtual private networks.
L3VPN overview
L3VPN helps in interconnecting VPNs (Virtual Private Networks) between several sites, by using a single BGP
connection, and at the same time keeping isolation between the different VPNs. L3VPN is based on MPLS tech-
nology, and separates the various VPNs connections with MPLS labels handled by BGP. Adding to this, L3VPN
offers powerful tools to share (or not) traffic between VPNs by introducing some new RT concepts (see definition
below): those tools permit to implement what we call vrf route leaking entries. Those routes can also be used with-
out MPLS for defining local importation and exportation policies between VRs. More generally, those concepts
apply to EVPN as per EVPN route target configuration use case.
RT21 Network A
Network A RT11
IPV4 unicast Signalling
(CE) (CE)
RT22 Network B
Network B RT12
Above drawing illustrates a setup made up of 2 symmetrical sites. Each site is separated with a PE (Provider Edge)
device. In the case the site is a data center, the PE could be replaced with a DC-GW (Data Center Gateway). To
simplify, each site is made up of 2 distinct VPNs. L3VPN functionality helps to exchange information about the 2
VPNs, between the 2 sites.
This functionality will subsequently enable data path forwarding. IP Traffic between the 2 PEs (Provider Edges)
will be encapsulated into an MPLS label. On each site, traffic between each CE (Customer Equipment) and the PE
is standard IP over ethernet traffic.
From the drawing, the following use cases will be more in detail leveraged successively in that document:
• how to interconnect traffic from different VPNs on a same site. This is a specific case from route-leaking.
The basic L3VPN commands will be illustrated, as well as the commmands to create Cross-VRF interfaces
across VRF. Note that this kind of method is recommended only if the user has interest in interconnecting
also VPNs traffic between sites. If this is not the case, an other method to establish cross-VRF routes is
recommended at following link: BGP use case for cross-vrf routes.
• how to interconnect traffic from a same VPN between sites. This use case will generalise usage of Cross-VRF
interfaces with default VRF, as well as explaining how to configure backbone so as to carry MPLS labels.
• how to interconnect traffic from different VPNs between sites This use case will generalise the L3VPN use
case in an MPLS based framework.
L3VPN terminology
It is important to understand some L3VPN terminology. In this paragraph we will give the most important concepts.
VPN This acronym refers here to a routing entity, also called VRF Creating a VPN consists in creating a BGP
instance in a separated VRF. More information in BGP VRF.
Route Distinguisher, RD (Route Distinguisher) : This attribute is specific for each VPN. This information is ex-
ported along with the L3VPN information of the BGP information
L3VPN This refers to creating an overlay with IP packets. In this chapter, L3VPN refers to encapsulating IP traffic
over MPLS traffic.
VPNv4 (Virtual Private Network for IPv4), VPNv6 (Virtual Private Network for IPv6) This refers to RFC
4364 (https://tools.ietf.org/html/rfc4364.html): that defines how BGP implements L3VPN with MPLS
Route Target, RT: RT and RD share the same format. A VPN can have 2 list of RTs (Route Targets). One is
dedicated for import. This will help BGP to import incoming routing entries that come from a remote BGP
entity. There is also a list for export, that is sent to remote BGP entities. Route Target is the key element for
sharing information across VPNs.
VRF route leaking: This refers to the ability to share a route from a VPN to an other entity. See chapter BGP VRF
route leak. This ability requires that the VPN that shares a common route, do not have overlapping with the
IP provisioning of the networks.
BGP configuration
Below configuration illustrates a setup made up with 2 VPNs. As can be seen, there is a BGP instance in each of
the 2 VR instances, plus the BGP core instance. The 2 instances are configured so as to create leaking between both
VPNs. Actually configuration shows the following:
• the RD is different, indicating that there are 2 distinct VPNs.
• the RT export settings of each VPN is being matched by the RT import settings of the other VPN. This
configuration means that route leaking will occur. Practically, export RT of customer1 is 11:22, and import
RT of customer2 is 11:22 and 22:44. 11:22 value matches, this means that customer2 will import
information coming from customer1.
vrf main
routing bgp
as 65500
..
..
..
vrf customer1
routing bgp
as 65500
address-family ipv4-unicast
network 192.168.3.0/24
..
l3vpn export route-distinguisher 1:55
l3vpn export route-target 11:22
l3vpn export vpn true
l3vpn import route-target 11:22 route-target 22:44
l3vpn import vpn true
..
..
..
..
..
vrf customer2
routing bgp
as 65500
address-family ipv4-unicast
network 192.168.2.0/24
..
l3vpn export route-distinguisher 2:55
l3vpn export route-target 22:44
(continues on next page)
When using above configuration, it is mandatory to create BGP core instance. Also, despite RD and RT values could
have been the same, it has been deliberately chosen to have distinct values to better understand the mechanisms put
in place when dealing with L3VPN importation and exportation. Also, it is common, when a L3VPN setup is put
in place between 2 ISPs, that the RD is self to each operator, while the RT will be chosen accordingly by operators.
Note: Above configuration details how routing information is exchanged, but does not explain in detail how data
traffic is sent through. The product design choices opted for strongly isolating traffic across VPNs. To pass traffic
across VPNs, it is required to create special interfaces by configuration. Those interfaces will make the connection
between VPNs. More information will be given about how to create those interfaces in a separate chapter. Next
chapters assume the user is familiar with interfaces used for crossing vrfs.
Using Cross-VRF interfaces to perform vrf route leaking with BGP requires a specific semantic between VRs and
interface names. VR naming must meet the requirements of interface naming. Actually, the Cross-VRF interface
name chosen must be equal to the target VR the interface is connected to. To illustrate, in order to reach VR foo from
VR bar, an Cross-VRF interface named foo has to be created in VR bar. Reversely, an Cross-VRF interface
named bar has to be created in VR foo. In this way, the interface foo and the interface bar will be connected
together. The naming convention is not only done to reflect the intent of the interface. It is mandatory to configure
it in this way, if one wants to benefit from route leaking across VRs, using Cross-VRF interfaces, and BGP.
From the user point of view, if a packet is emitted in one interface of a source VR, the same packet will be received
in the associated veth interface of destination VR. More information about Cross-VRF interfaces can be found in
XVRF Interface types. In order to have the setup working fine, the below configuration has to be appended to the
former configuration of previous chapter (BGP VRF leak).
vrf customer1
interface xvrf customer2
link-interface customer1
link-vrf customer2
..
..
..
(continues on next page)
With the above configuration applied, VR route leaking is possible. Subsequently, if BGP peering is done between
a CE and the BGP instance of each VR instance, then route importation and exportation occurs. Below output
demonstrates that the routes from customer2 have been imported to customer1. The VR route leak are visible
with the @1< indicating that the route entry is originated from VR customer2.
Routing output
Once those entries selected in the bgp RIB, nothing prevents the installation of those VRs routes in the underlying
system. Packets going from a VR to an other VR are using the Cross-VRF interface created. There is no specific
encapsulation, only a route using an interface as gateway. From above example, the following output displays the
routing entries available in VRF routing table. As can be seen, the route to reach the remote prefix first reaches
the customer2 interface (first line directly connected, customer2). Then, once the other VR reached, the
original BGP route of customer2 routes the traffic to the correct destination (via 2.2.2.3 lines). The latter entry
is only here for informational purpose. To get information about routes in VR customer2, use the associated show
command to dump route entris in the associates VR.
Being able to interconnect between sites using L3VPN technology is now possible. As explained in the introduction
of that chapter, the traffic between sites is encapsulated into an MPLS label, negotiated thanks to BGP. More exactly,
the ipv4-vpn address-family configured in BGP will obtain from remote the label, and the underlay nexthop to use,
to reach the remote. That label will be the encapsulation between 2 VPNs, in one direction. The same mechanism
will apply in reverse direction. Adding to this, this label will be conveyed by an other framework. Currently, LDP
offers that framework by conveying inner BGP labels in an outer MPLS label negoatiated by LDP. More information
on chapter (LDP configuration).
In order to activate L3VPN, use the following command under the main BGP core instance. L3VPN address-family
must be configured on the same VRF where the LDP configuration is. Usually, the backbone is the main VR
instance.
vrf main
routing bgp
as 65500
neighbor 9.9.9.9 remote-as 65512
neighbor 9.9.9.9 update-source 3.3.3.3
neighbor 9.9.9.9 address-family ipv4-vpn enabled true
..
..
..
Consequently, having an L3VPN peering will trigger importation of L3VPN entries. For instance, the presence
of remote VPNs and associated prefixes from peer 9.9.9.9 will trigger prefixes importation in the relevant VRs.
Those prefixes, if the remote VPNs match the local VPNs will be imported in the associated VR. So as to permit
that importation, the associated Cross-VRF interfaces will be created between the main VR and the relevant VRs.
The following configuration illustrates the Cross-VRF interfaces.
vrf main
interface xvrf customer1
link-interface main
link-vrf customer1
..
..
interface xvrf customer2
link-interface main
link-vrf customer2
..
..
..
vrf customer1
interface xvrf main
link-interface customer1
link-vrf main
..
..
..
vrf customer2
interface xvrf main
link-interface customer2
link-vrf main
..
..
..
Also, in order for BGP to be able to export its own labels, BGP must be configured so as to rely on its own labels,
either automatically, or by choosing its own. Below configuration illustrates the automatic label chosen by VR
customer1, while customer2 chooses to hardset its exportation label to 300.
vrf customer1
routing bgp
as 65500
address-family ipv4-unicast
network 192.168.2.0/24
..
l3vpn export label auto
..
..
(continues on next page)
Network A RT5
Network A
eth0_0
RT21
RT11
12.12.12.0/24
eth2_0
BGP 9.9.9.9
11.11.11.11 10.10.10.10
BGP 5.5.5.5
RT21
LDP backbone RT12
Network B
Network B
Above diagram illustrates a topology made up of an MPLS based backbone, with LSR (Label-Switched Router)
devices : rt3 and rt4, and LER (Label Edge Router) devices. Each LER device has a BGP core instance that has
ipv4-vpn address-family enabled. Next to each BGP instance, a BGP instance is created in each VR. Each VR
stands for a private network, either A or B. The color semantic explains the relationship between the private networks
on the various LER devices.
As can be seen with the arrows, each private network is geographically separate, but thanks to L3VPN, the private
networks act as if there were only 2 specific private networks. The BGP configuration is depicted below. The LDP
rt1
vrf main
routing bgp
router-id 5.5.5.5
as 65500
neighbor 9.9.9.9 remote-as 65500
neighbor 15.15.15.15 remote-as 65500
neighbor 9.9.9.9 update-source 5.5.5.5
neighbor 15.15.15.15 update-source 5.5.5.5
neighbor 9.9.9.9 address-family ipv4-vpn enabled true
neighbor 15.15.15.15 address-family ipv4-vpn enabled true
..
..
..
vrf customer1
routing bgp
router-id 1.1.1.1
as 65500
address-family ipv4-unicast
l3vpn export route-distinguisher 1:55
l3vpn export route-target 1:55
l3vpn export vpn true
l3vpn import route-target 1:55
l3vpn import vpn true
l3vpn export label auto
..
..
..
..
..
vrf customer2
routing bgp
router-id 2.2.2.2
as 65500
address-family ipv4-unicast
l3vpn export route-distinguisher 2:55
l3vpn export route-target 2:55
l3vpn export vpn true
l3vpn import route-target 2:55
l3vpn import vpn true
l3vpn export label auto
(continues on next page)
rt2
vrf main
routing bgp
router-id 9.9.9.9
as 65500
neighbor 5.5.5.5 remote-as 65500
neighbor 15.15.15.15 remote-as 65500
neighbor 5.5.5.5 update-source 9.9.9.9
neighbor 15.15.15.15 update-source 9.9.9.9
neighbor 5.5.5.5 address-family ipv4-vpn enabled true
neighbor 15.15.15.15 address-family ipv4-vpn enabled true
..
..
..
vrf customer1
routing bgp
router-id 1.1.1.10
as 65500
address-family ipv4-unicast
l3vpn export route-distinguisher 1:55
l3vpn export route-target 1:55
l3vpn export vpn true
l3vpn import route-target 1:55
l3vpn import vpn true
l3vpn export label auto
..
..
..
..
..
vrf customer2
routing bgp
router-id 2.2.2.2
as 65500
address-family ipv4-unicast
(continues on next page)
rt5
vrf main
routing bgp
router-id 15.15.15.15
as 65500
neighbor 5.5.5.5 remote-as 65500
neighbor 9.9.9.9 remote-as 65500
neighbor 5.5.5.5 update-source 15.15.15.15
neighbor 9.9.9.9 update-source 15.15.15.15
neighbor 5.5.5.5 address-family ipv4-vpn enabled true
neighbor 9.9.9.9 address-family ipv4-vpn enabled true
..
..
..
vrf customer1
routing bgp
router-id 1.1.1.20
as 65500
address-family ipv4-unicast
l3vpn export route-distinguisher 1:55
l3vpn export route-target 1:55
l3vpn export vpn true
l3vpn import route-target 1:55
l3vpn import vpn true
l3vpn export label auto
..
..
..
..
(continues on next page)
As can be seen, the network prefixes learnt by each BGP instance are either learnt, by adding extra CE configuration
linked to each instance, or imported thanks to L3VPN technology. Below show dumps the vpnv4 entries:
As can be seen, all the entries have an underlay nexthop defined (UN) that usually stands for the nexthop of the
remote BGP global instance. If local entries are imported, that nexthop stands will be sent to remote BGP global
instance. Along with the nexthop , an MPLS label will be sent via BGP, and used on top of the MPLS backbone.
MPLS stacking will be performed. MPLS backbone will handle the LSP (Label-Switched Path) path.
It is worth to be noted too, that the first 3 visible entries are locally exported entries. The nexthop to use 1.1.1.2
is located in the VR customer1. The relationship between the VR name and the VR identifier displayed ( the @2
value) can be done using the following command:
The label value 80 is the exported value sent to the remote BGP peers. That value is received by remote BGP
speaker 9.9.9.9 for instance, along with the undelay network:
After having checked that L3VPN peering received the correct information, it is possible to check against available
entries in the bgp vrf customer1 instance like follows:
Like for the previous dump of vpn entries, it is worth to be noted that remote vpn entries have their underlay nexthop
visible, but annotated with @0< indicating that this is a VR route leak going to the VPN. Only 1.1.1.2 ip address
is a locally reachable IP address. Actually, this is a CE of that instance.
Routing output
Once those entries selected in the bgp RIB, nothing prevents the installation of those VR routes in the underlying
system.
As remind, packets going from a VR to a remote VPN are first mpls encapsulated once. Then, a second encapsulation
takes place, as the backbone is MPLS based. Then MPLS does the job to forward the packet to the nexthop marked
UN. Reversely, because the BGP vrf instance is at the LER place, the incoming packets are only encapsulated with
the negotiated BGP label. So, to go from the backbone VR to the local VR, the packet is being popped its mpls
label.
From above example, the following output can be extracted from the VR routing table. As illustrated, the installed
route entry performs a double MPLS encapsulation (82/80). The inner value is the negotiated BGP value. The 82
value is an intermediate value that is being swapped by the negotiated MPLS value on the backbone.
VRF customer1:
B>* 10.101.0.0/24 [200/0] via 1.1.1.2, eth1_0, 00:27:24
B>* 10.101.1.0/24 [200/0] via 1.1.1.2, eth1_0, 00:27:24
B>* 10.101.2.0/24 [200/0] via 1.1.1.2, eth1_0, 00:27:24
[..]
B>* 10.101.11.0/24 [200/0] is directly connected, main, label 82/80, 00:26:43
via 9.9.9.9(vrf main) (recursive), label 80, 00:26:43
* via 6.6.6.3, eth0_0(vrf main), label 17, 00:26:43
B>* 10.101.12.0/24 [200/0] is directly connected, main, label 82/80, 00:26:43
via 9.9.9.9(vrf main) (recursive), label 80, 00:26:43
* via 6.6.6.3, eth0_0(vrf main), label 17, 00:26:43
B>* 10.101.13.0/24 [200/0] is directly connected, main, label 82/80, 00:26:43
via 9.9.9.9(vrf main) (recursive), label 80, 00:26:43
* via 6.6.6.3, eth0_0(vrf main), label 17, 00:26:43
[..]
B>* 10.101.22.0/24 [200/0] is directly connected, main, label 84/300, 00:26:40
via 15.15.15.15(vrf main) (recursive), label 300, 00:26:40
* via 6.6.6.3, eth0_0(vrf main), label 22, 00:26:40
B>* 10.101.23.0/24 [200/0] is directly connected, main, label 84/300, 00:26:40
via 15.15.15.15(vrf main) (recursive), label 300, 00:26:40
* via 6.6.6.3, eth0_0(vrf main), label 22, 00:26:40
B>* 10.101.24.0/24 [200/0] is directly connected, main, label 84/300, 00:26:40
via 15.15.15.15(vrf main) (recursive), label 300, 00:26:40
* via 6.6.6.3, eth0_0(vrf main), label 22, 00:26:40
(continues on next page)
The next command dumps the LFIB (Label Forwarding Information Base) of the backbone. As you can see, the 82
value is replaced by the 17 value, and forwarded thanks to calculated LSP. Actually, this entry stands for the path to
rt2. For reverse direction, incoming packets are being popped and redirected to the Cross-VRF interface leading
to the VRF ( here customer1).
By integrating examples of the 2 previous chapters, it becomes possible to perform interconnection between vari-
ous VPNs between sites. Also, some VR route leaking across VPNs is done. Note that like for previous chapters,
configuring BGP only is not enough, since conveying MPLS labels from BGP needs an other MPLS framework
to be configured. LDP protocol is the framework that should be used. More information on chapter (:ref: LDP
configuration <mpls-ldp-configuration>). This being said, next chapter explores how to simplify, eventu-
ally remove the usage of LDP.
Network A RT5
Network A
eth0_0
RT21
RT11
12.12.12.0/24
eth2_0
BGP 9.9.9.9
11.11.11.11 10.10.10.10
BGP 5.5.5.5
RT21
LDP backbone RT12
Network B
Network B
The same topology as for previous chapter is chosen. Black arrows indicate the traffic that will be authorised to pass
between different VPNs. For instance, network A and network B can access each other. Note that not all data flow
are illustrated in the drawing, but it is also possible to do VR route leak between network A from rt1 and network
B from rt1. The L3VPN importation and exportation rules for a defined VPN apply for that VPN, whatever its
location is, ie local or remote.
Below configurations are BGP configuration changes. Usually, that kind of configuration can be used, when some
resources are shared with other VRs: A video server located on that shared resource, or a management vr that is
only able to access to th other VRs.
rt1
vrf main
routing bgp
router-id 5.5.5.5
as 65500
neighbor 9.9.9.9 remote-as 65500
neighbor 15.15.15.15 remote-as 65500
neighbor 9.9.9.9 update-source 5.5.5.5
neighbor 15.15.15.15 update-source 5.5.5.5
neighbor 9.9.9.9 address-family ipv4-vpn enabled true
neighbor 15.15.15.15 address-family ipv4-vpn enabled true
..
(continues on next page)
rt2
vrf main
routing bgp
router-id 9.9.9.9
as 65500
neighbor 5.5.5.5 remote-as 65500
neighbor 15.15.15.15 remote-as 65500
neighbor 5.5.5.5 update-source 9.9.9.9
neighbor 15.15.15.15 update-source 9.9.9.9
neighbor 5.5.5.5 address-family ipv4-vpn enabled true
neighbor 15.15.15.15 address-family ipv4-vpn enabled true
..
..
..
vrf customer1
routing bgp
router-id 1.1.1.10
as 65500
address-family ipv4-unicast
l3vpn export route-distinguisher 1:55
l3vpn export route-target 1:55
l3vpn export vpn true
l3vpn import route-target 1:55 route-target 2:55
l3vpn import vpn true
l3vpn export label auto
..
..
..
..
..
vrf customer2
routing bgp
router-id 2.2.2.2
as 65500
address-family ipv4-unicast
l3vpn export route-distinguisher 2:55
l3vpn export route-target 2:55
l3vpn export vpn true
l3vpn import route-target 1:55 route-target 2:55
l3vpn import vpn true
l3vpn export label auto
..
..
..
(continues on next page)
rt5
vrf main
routing bgp
router-id 15.15.15.15
as 65500
neighbor 5.5.5.5 remote-as 65500
neighbor 9.9.9.9 remote-as 65500
neighbor 5.5.5.5 update-source 15.15.15.15
neighbor 9.9.9.9 update-source 15.15.15.15
neighbor 5.5.5.5 address-family ipv4-vpn enabled true
neighbor 9.9.9.9 address-family ipv4-vpn enabled true
..
..
vrf customer1
routing bgp
router-id 1.1.1.20
as 65500
address-family ipv4-unicast
l3vpn export route-distinguisher 1:55
l3vpn export route-target 1:55
l3vpn export vpn true
l3vpn import route-target 1:55 route-target 2:55
l3vpn import vpn true
l3vpn export label auto
..
..
..
..
..
vrf customer2
routing bgp
router-id 2.2.2.20
as 65500
address-family ipv4-unicast
l3vpn export route-distinguisher 2:55
l3vpn export route-target 2:55
l3vpn export vpn true
l3vpn import route-target 1:55 route-target 2:55
(continues on next page)
The following show extract on rt1 dumps the routing entries of A and B located on rt2. Two different MPLS labels
chosen by BGP of rt2, are received by rt1, for each network.
When applied to the underlying system, the encapsulation for packets leaving the customer1 VR is different, de-
pending if the target prefix belongs to A or B. 2 additional temporary labels are allocated and are swapped as the
show mpls labels indicate.
VRF customer1:
B>* 10.101.11.0/24 [200/0] is directly connected, main, label 83/80, 00:00:44
via 9.9.9.9(vrf main) (recursive), label 80, 00:00:44
* via 6.6.6.3, eth0_0(vrf main), label 18, 00:00:44
B>* 10.101.12.0/24 [200/0] is directly connected, main, label 83/80, 00:00:44
via 9.9.9.9(vrf main) (recursive), label 80, 00:00:44
* via 6.6.6.3, eth0_0(vrf main), label 18, 00:00:44
B>* 10.101.13.0/24 [200/0] is directly connected, main, label 83/80, 00:00:44
via 9.9.9.9(vrf main) (recursive), label 80, 00:00:44
* via 6.6.6.3, eth0_0(vrf main), label 18, 00:00:44
B>* 10.201.11.0/24 [200/0] is directly connected, main, label 82/81, 00:08:15
via 9.9.9.9(vrf main) (recursive), label 81, 00:08:15
* via 6.6.6.3, eth0_0(vrf main), label 19, 00:08:15
B>* 10.201.12.0/24 [200/0] is directly connected, main, label 82/81, 00:08:15
via 9.9.9.9(vrf main) (recursive), label 81, 00:08:15
* via 6.6.6.3, eth0_0(vrf main), label 19, 00:08:15
B>* 10.201.13.0/24 [200/0] is directly connected, main, label 82/81, 00:08:15
via 9.9.9.9(vrf main) (recursive), label 81, 00:08:15
* via 6.6.6.3, eth0_0(vrf main), label 19, 00:08:15
An additional specificity of the setup is the possibility to import ECMP entries coming from 2 separate locations;
here, some 32 bit host routes are retrieved. Some of the entries stand for a server with the same IP, but geographically
at 2 different places, namely rt2 and rt5. This kind of scenario can be used for servers that require availability, or
where load is split in two, to avoid starvation of the resources of one of the machines.
VRF customer1:
B>* 10.101.18.10/32 [20/0] is directly connected, main, label 19/80, 00:00:09
via 9.9.9.9(vrf main) (recursive), label 80, 00:00:09
* via 6.6.6.3, eth0_0(vrf main), label 20, 00:00:09
* is directly connected, main, label 22/300, 00:00:09
via 15.15.15.15(vrf main) (recursive), label 300, 00:00:09
* via 6.6.6.3, eth0_0(vrf main), label 21, 00:00:09
B>* 10.101.19.10/32 [20/0] is directly connected, main, label 19/80, 00:00:09
via 9.9.9.9(vrf main) (recursive), label 80, 00:00:09
* via 6.6.6.3, eth0_0(vrf main), label 20, 00:00:09
* is directly connected, main, label 22/300, 00:00:09
via 15.15.15.15(vrf main) (recursive), label 300, 00:00:09
* via 6.6.6.3, eth0_0(vrf main), label 21, 00:00:09
B>* 10.101.20.10/32 [20/0] is directly connected, main, label 19/80, 00:00:09
via 9.9.9.9(vrf main) (recursive), label 80, 00:00:09
* via 6.6.6.3, eth0_0(vrf main), label 20, 00:00:09
* is directly connected, main, label 22/300, 00:00:09
via 15.15.15.15(vrf main) (recursive), label 300, 00:00:09
* via 6.6.6.3, eth0_0(vrf main), label 21, 00:00:09
As said in previous interconnection chapters, having an MPLS framework is mandatory to interconnect several
VPNs across multiple site. Above examples use LDP. Main reason to use LDP is that MPLS technology must be
configured at each hop separating two devices (MPLS is a layer 2 technology). And the border devices should not be
aware of the number of hops that separate from remote device. One solution to simplify the configuration and to not
rely on external dependencies is to reduce to 1 hop the distance between the two devices that should interconnect.
Following examples apply:
• device acting as ASBR (Autonomous System Boundary Router), and directly connecting to remote ASBR.
In that case, eBGP is used.
• a GRE tunnel is used to interconnect two devices. As GRE tunnel is a point to point technology, then the
traffic flowing across that interface is reduced to 1 hop only, independently of the framework to be crossed.
Below configuration illustrates the configuration of the two devices interconnected. The configuration does not
include the VPN configuration part.
rt1
vrf main
routing bgp
router-id 5.5.5.5
as 65500
neighbor 9.9.9.9 remote-as 65500
neighbor 9.9.9.9 update-source 5.5.5.5
neighbor 9.9.9.9 address-family ipv4-unicast enabled false
neighbor 9.9.9.9 address-family ipv4-vpn enabled true
..
..
interface loopback loop1
ipv4 address 5.5.5.5/32
..
interface physical eth1
port pci-b0s4
ipv4 address 10.1.2.5/24
..
interface gre gre1
link-interface eth1
ipv4-address 40.0.0.5/24
local 10.1.2.5
remote 10.3.2.9
(continues on next page)
rt2
vrf main
routing bgp
router-id 9.9.9.9
as 65500
neighbor 5.5.5.5 remote-as 65500
neighbor 5.5.5.5 update-source 9.9.9.9
neighbor 5.5.5.5 address-family ipv4-unicast enabled false
neighbor 5.5.5.5 address-family ipv4-vpn enabled true
..
..
interface loopback loop1
ipv4 address 9.9.9.9/32
..
..
interface physical eth1
port pci-b0s4
ipv4 address 10.3.2.9/24
..
(continues on next page)
As shown below, an implicit-null label has been bound to the route to the next-hop of remote BGP speaker.
You can note that 40.0.0.2 is the gateway used to reach remote 9.9.9.9.
VRF main:
[..]
C>* 5.5.5.5/32 is directly connected, lo, 00:02:21
(continues on next page)
By adding VPN configuration which is not present on above configuration, one will have two VPN labels negotiated
between BGP independently of LDP; 144 is the outgoing label, and 16 is the incoming label.
The below show ipv4-routes command gives the information on the encapsulation used by a packet going from
local vrf r1-cust1 to remote r2-cust2. Outgoing packets leaving rt1 device are encapsulated with label 144/
implicit-null. You can note that intermediate step to pass over the vrf border between main and r1-cust1
happens by appending an intermediate label 17 that is popped when directed to 40.0.0.2 destination IP. The
additional implicit-null label is chosen since it stands for the label to use when wanting to reach the nexthop of
the VPN route. Actually, 9.9.9.9 is reachable via 40.0.0.2 by using implicit-null label.
VRF r1-cust1:
C>* 172.16.1.0/24 is directly connected, r1-eth0, 00:11:15
B>* 172.16.2.0/24 [200/0] is directly connected, vrf0, label 17/144, 00:09:07
via 9.9.9.9(vrf vrf0) (recursive), label 144, 00:09:07
* via 40.0.0.2, r1-gre(vrf vrf0), label implicit-null,␣
˓→00:09:07
Reversely, incoming packets are received with 16/implicit-null label. On rt1, a switching rule indicates that
16 label is popped, and packet is directed to xvrf interface r1-cust1.
Below configuration illustrates is an alternative to previous configuration. Without LDP, but by relying on static
MPLS configuration, it is possible to do convey VPN labels transparently across a backbone, inside GRE tunnels.
VPN traffic conveyed will use the static MPLS routes labels. Below static route used label number 3 that stands for
ipv4 implicit-null value.
rt1
vrf main
routing bgp
router-id 5.5.5.5
as 65500
neighbor 9.9.9.9 remote-as 65500
neighbor 9.9.9.9 update-source 5.5.5.5
neighbor 9.9.9.9 address-family ipv4-unicast enabled false
neighbor 9.9.9.9 address-family ipv4-vpn enabled true
..
..
interface loopback loop1
ipv4 address 5.5.5.5/32
..
interface physical eth1
port pci-b0s4
ipv4 address 10.1.2.5/24
..
interface gre gre1
link-interface eth1
ipv4-address 40.0.0.5/24
local 10.1.2.5
remote 10.3.2.9
..
(continues on next page)
rt2
vrf main
routing bgp
router-id 9.9.9.9
as 65500
neighbor 5.5.5.5 remote-as 65500
neighbor 5.5.5.5 update-source 9.9.9.9
neighbor 5.5.5.5 address-family ipv4-unicast enabled false
neighbor 5.5.5.5 address-family ipv4-vpn enabled true
..
..
interface loopback loop1
ipv4 address 9.9.9.9/32
..
..
interface physical eth1
port pci-b0s4
ipv4 address 10.3.2.9/24
..
..
interface gre gre1
link-interface eth1
ipv4 address 40.0.0.9/24
local 10.3.2.9
remote 10.1.2.5
..
..
routing ospf
router-id 10.3.2.9
network 10.3.2.0/24 area 0
(continues on next page)
Above configuration results in having a label bound to route to reach BGP next-hop, that is to say route via 40.0.
0.2. In that case, when resolving route from r1-cust1 VRF, the VPN label would be appended with the static
label. The show commands from above example are the same with or without LDP.
BFD In BGP
With BFD usage in BGP, the failover mechanism is greatly improved by detecting the loss of remote BGP speaker
in a few seconds, instead of generally 20/30 seconds. To get more information on BFD, please see BFD.
A BFD peer session context is created, along with BGP peering session. The session inherits from BGP settings.
For instance, if ebgp-multihop is used, then a BFD session multi-hop is created. Also, if update-source is
used, the local-address parameter is set.
vrf customer1
routing bgp
as 65555
router-id 192.168.1.1
neighbor 192.168.1.2 remote-as 65100
neighbor 192.168.1.2 ebgp-multihop 5
neighbor 192.168.1.2 update-source 192.168.1.1
neighbor 192.168.1.2 track bfd
Then you can continue the configuration as usual. For timer settings, the default emission and reception settings are
set to 300000 microseconds, which may not be what is wished. In that case, it is possible to override default timers,
by configuring general timer settings. More information is given in Configuring general BFD settings.
There are cases where the non stop forwarding mechanisms configured in BGP may have to prevent BFD to trigger
the neighbouring peer session to go down. BFD provides such feature by embedding in BFD control packet a bit
that reflects the relationship between control-plane and dataplane. This bit is called the control bit. By default, that
bit is set to 1, and means that if a BFD event happens, then the associated control-plane routing context may go
down too.
BGP graceful restart informs remote peer that the local speaker is able to keep BGP routing entries in stale mode,
during the non availability of that remote speaker. When leaving, remote BFD peer leaves too. Then, the local BFD
triggers a notification to BGP quicker than if the local BGP was detecting that the remote BGP speaker left without
saying anything (usually TCP error). When keeping BFD posted with specific BGP constraint, the incoming BFD
control packet has the C-BIT unset, which means that the control-plane and dataplane should be independent to
each other. Consequently, BGP is notified that the remote BGP speaker went down, but as the incoming C-BIT is
unset, the event is ignored, thus letting the BGP graceful restart mechanism taking the hand, and thus keeping the
routing entries.
Following configuration should be applied if the control-plane decision should be done independently of the incom-
ing BFD notification. Reversely, that configuration will also unset the C-BIT for outgoing BFD control packets.
vrf customer1
routing bgp
as 65555
router-id 192.168.1.1
graceful-restart
..
neighbor 192.168.1.2 remote-as 65100
neighbor 192.168.1.2 track bfd
neighbor 192.168.1.2 check-control-plane-failure true
It’s also possible to configure a BFD or ICMP tracker manually. This enables using the same tracker in different
services. The example below uses the same BFD tracker in a BGP neighbor and a static route. If the link becomes
unrechable, the BGP neighbor and the static route will be removed from the configuration.
Overview
BGP routing protocol is a very rich routing protocols and provide L3VPN and L2VPN features. More information
about L3VPN can be read in BGP L3VPN use case example. L2VPN stands for the ability to carry layer data
(MAC-level frames) over standard encapsulation protocols. More specifically, the underlay is an IP packet with
VXLAN header used as encapsulation technique; while the overlay is a layer 2 frame containing MAC information
and IP information. BGP is able to use the benefits of VXLAN tunnels. This permits ISPs to provide network
segmentation in VNI (VXLAN Network Identifier) (virtual network identifier in a vxlan header) instead of using
VLAN for segmenting the network. Also BGP is well suited to handle IP routing of the underlay. Generally, EVPN
sits on PE machines.
EVPN is able to carry IP information, but also MAC information in its signaling protocol. The information is col-
lected from routing tables of each VPN, but also neighboring tables, and bridge tables. Actually, layer 2 connectivity
can be obtained thanks to information contained in a virtual bridge attached to the vxlan interface.
EVPN is also able to handle BUM (Broadcast Unknown-Unicast and Multicast) traffic, like if it was a local switch.
As vxlan interface is a bridge port with possibly multiple tunnel endpoint entries on the same port, outgoing BUM
packets are duplicated and sent to various endpoints.
Also, EVPN uses the same semantic as for L3VPN by handling RTs in extended communities, and using RD in
NLRI prefixes. This permits easier interconnection between sites.
Initially, the EVPN standard has first been declined with MPLS underlay (with RFC 7432
(https://tools.ietf.org/html/rfc7432.html)). The main features of EVPN have been proposed, leveraging layer
2 connectivity. Then, the technology evolved, with the increasing usage of overlay technology in data centers.
Inter Subnet Forwarding concept has been proposed. This routing mode has been introduced in EVPN, and
permits routing overlay information between different sites, similar to what L3VPN technology does with MPLS.
Practically, once the routing information exchanged, a bridge interface is used at each side, where packets are
routed. Then the MAC layer used to forge overlay packets are the MAC addresses of the bridge interfaces.
EVPN terminology
Ethernet VPN, EVPN: This refers to creating an overlay with layer 2 frames. In this chapter, it refers to encapsu-
lating IP traffic over VXLAN tunnel. in multi protocol BGP, EVPN refers to a specific address family with
AFI identifier set to 25 and SAFI identifier set to 70.
Route Distinguisher, RD: This attribute is specific for each VPN. This information is exported along with the
EVPN information of the BGP information. By configuration, a VPN is often associated to a VNI.
Route Target, RT: RT and RD share the same format. An EVPN can have 2 list of RTs. One is dedicated for
import. This will help importing MAC entries to the appropriate VPN if it deals with route type 2 entries, or
IP to the BGP instance associated to the VPN of the instance, if it deals with route type 5 entries. The other
one is dedicated for export, and is proposed in the BGP update message where either RT2 (EVPN Route Type
5) or RT2 prefixes are encoded and shared with other VPNs.
Route type 2, RT2: This prefix refers to the list of attributes used to define a MAC entry in the EVPN concept. It
is made up of a RD, a MAC address, an optional associated IP address, an EVI (Ethernet Virtual Identifier),
and an ESI (Ethernet Segment Identifier). The two last concepts are not used in below examples, but are
respectively related to broadcast domain separation, and multi- homing. In VXLAN topology, the VNI comes
along with the prefix and is encoded in the MPLS label field of the prefix (because initially, EVPN protocol
has been made for MPLS). So, that value is not an MPLS value, and can be decoded without looking at BOS
(Bottom Of Stack) value like for MPLS.
Route type 5, RT2: This prefix refers to the list of attributes used to define an IP entry located behind a virtual
switch in routing mode. It is made up of a RD, an IP address, an EVI, and an ESI. The two last concepts are
not used in below examples, but are respectively related to broadcast domain separation, and multi-homing.
In VXLAN topology, the VNI comes along with the prefix and is encoded in the MPLS label field. In the
EVPN context, that value is not an MPLS value, and can be decoded without looking at BOS value like for
MPLS.
Route type 3, RT3 (EVPN Route Type 3): This prefix stands for the inclusive multicast ethernet tag route, and is
used to signify that a sub network defined by its RD accept BUM traffic. The prefix comes along with the
tunnel end-point; that means that BUM traffic can be sent to that tunnel endpoint.
Configuring EVPN
Principles of configuration
The following chapters enter more in detail on how to route or bridge traffic into VXLAN tunnels. The BGP services
are differently configured, whether routing mode or bridging mode is used. Let us begin with the bridge and vxlan
interfaces.
To be able to perform EVPN, the core technology relies on a VXLAN interface bridged with a bridge interface.
The VXLAN interface link-interface must be on the same VRF where the backbone is, that is to sat the main vrf.
Also you can note that you have to colocate both VXLAN and bridge interfaces on the same VRF. There is no
other restriction regarding in which VRF both interfaces should be. Regarding the VXLAN interface, VNI value
will be configured. The destination IP address of VXLAN interface does not need to be configured, as BGP will
configure its own destination IP on the underlay. The configured VXLAN and bridge interfaces will be used by
BGP to discover which VNI is present on the device, and which information to send to remote peers.
EVPN service
In order to activate EVPN, use the following command under the main BGP core instance. l2vpn-evpn address-
family must be configured. Here, the main BGP core instance will play the backbone role.
vrf main
routing
bgp
as 65500
address-family
l2vpn-evpn
enabled true
advertise-all-vni true
..
..
The advertise-all-vni keyword will trigger local discovery of all vxlan and bridge interfaces available, so that
BGP will retrieve VNI and use that information to send to remote peers. It is to be noted that the discovery takes
into account all vr-s instances. So basically, whatever where the VRF is, all VXLAN interfaces will be learnt.
For bridging mode, configuring the BGP main instance is enough. In routing mode, it is usual to configure overlay
networking information in separate VRs. For that, if a VRF is dedicated to routing network into a VXLAN interface,
then an additional BGP instance attached to the new VRF instance will need to be created in order to perform routing
mode. Also, the VRF will be mapped to the VNI by configuration. Subsequently, extra configuration can be done
under each BGP instance, directly under the address-family l2vpn-evpn address-family.
Below figure illustrates what does routing mode and bridging mode means. As can be seen, two pe devices are
interconnected with EVPN. On each device, a VXLAN interface and a bridged interface are linked together, as well
as an ethernet port connected to local host devices. The VRF where both bridge and vxlan interfaces sit does not
matter, provided that the link information of the VXLAN interface is on the main VRF.
Two data flows are illustrated. The scheme reuses the same VXLAN interface, but practically, it is necessary to create
a VXLAN interface for each kind of connectivity. On the one hand, the blue one stands for layer 2 connectivity.
Data traffic is bridged on pe devices, that is to say that traffic is bridged from ethernet port to vxlan port, where
traffic is encapsulated into vxlan header and transmitted to remote pe. From hostA to hostB, traffic is full layer 2.
On the other hand, the green one stands for layer 3 connectivity. This flow connects two networks together, namely
network B and network C. All happens as if the traffic from network B was redirected to gateway in rt2, except
that the gateway of rt2 is the remote bridged interface. The forged packet inside VXLAN packet will then be made
of the MAC addresses of the two bridged interfaces.
hostA Network A
Network A hostB
Ethernet
over VXLAN traffic
IP over Ethernet Traffic
RT21
Network B
Network D
Basic Configuration
EVPN uses a new address-family with AFI identifier set to 25 and SAFI identifier set to 70. Configuring EVPN
goes along with the configuration of a bridge interface bridged with a VXLAN interface.
Here below is an example on how to configure a sample BGP configuration with EVPN enabled. As illustrated
below, the configuration must include the presence of both vxlan interface and bridge interface.
vrf main
routing
bgp
router-id 10.125.0.1
as 65500
address-family
l2vpn-evpn
enabled true
advertise-all-vni true
vni 11
advertise-default-gw true
..
..
..
neighbor 10.125.0.3
remote-as 65500
(continues on next page)
There is a single global command to enable the EVPN control plane on a VTEP called advertise-all-vni.
This will cause the router to learn about all VNIs (VXLAN Network Identifiers) locally present on the system
and the MACs and neighbors (ARP and ND (Neighbor Discovery)) that pertain to such VNIs and advertise the
corresponding information using EVPN procedures to all BGP peers with whom the EVPN address-family has
been negotiated. It will also cause any EVPN routes learnt from BGP peers to be installed into the appropriate local
VNIs. Received EVPN type-3 routes will translate into the list of remote VTEPs (VXLAN Tunnel End Points) that
participate in a particular VNI and received EVPN type-2 routes will get installed as MAC and neighbor entries
pertaining to a specific VNI.
It is to be noted that the BGP core instance is used to carry EVPN information, while the other VRs are optionally
used to carry the overlay information, be it layer 2 and/or layer 3 information. The mapping between overlay and
underlay is based with VNI presence. That implies that the VRs configuration is optional, and for instance, the
configuration of a bridge and a virtual interface can be done in the main instance. all traffic that will go through
that bridge interface will be subsequently encapsulated, and signaling information will be detected and transmitted
within the associated VNI.
Note that we don’t define the remote endpoint of the vxlan interface, as the BGP peer defines it, using the VXLAN
interface. That vxlan interface link interface is the same interface where underlay traffic goes through.
To get information about the VXLAN interfaces detected, classified per VNI, the following command can be used
to dump the contexts. If the VXLAN interfaces have not been detected, then that implies that a misconfiguration
occurred, for instance, if the VXLAN interface has not been bridged. Below example shows that the vxl11 has
been detected on vrf custom1, and that a certain number of entries have been learnt, either via bgp learning, or by
locally listening for ARP/MAC information ( see MACs and MAC information). The first mac information learnt is
the MAC address of the bridged interface.
To get information about the BGP information exchanged, the following command can be used. Each entry stands
for an EVPN route entry. The first number stands for the kind of information shared, ie the route type. For instance,
2 stands for MAC-level information shared (RT2, while 3 (RT3) stands means that this tunnel endpoint is authorized
to exchange BUM traffic. The tunnel endpoint can be seen here with the nexthop information. As depicted below,
10.125.0.3 is the tunnel endpoint.
*> [2]:[0]:[48]:[2e:31:79:f5:72:49]:[128]:[fe80::2c31:79ff:fef5:7249]
10.125.0.1 32768 i
*>i[2]:[0]:[48]:[fe:52:b6:05:45:c7]:[128]:[2001:101::41]
10.125.0.3 100 0 i
*>i[2]:[0]:[48]:[fe:52:b6:05:45:c7]:[128]:[fe80::347a:84ff:fe51:dcca]
10.125.0.3 100 0 i
*> [3]:[0]:[32]:[10.125.0.1]
10.125.0.1 32768 i
*>i[3]:[0]:[32]:[10.125.0.3]
10.125.0.3 100 0 i
It is also possible to do some variants of the call by filtering based on the route type.
*> [3]:[0]:[32]:[10.125.0.1]
10.125.0.1 32768 i
*>i[3]:[0]:[32]:[10.125.0.3]
10.125.0.3 100 0 i
It is possible to create a route reflector configuration, then it is not necessary to call advertise-all-vni key-
word. Enabling l2vpn-evpn address-family is enough. EVPN routes received from a BGP peer are accepted and
maintained in the global EVPN routing table.
Flooding Mode
VXLAN interfaces handled by BGP can be configured with or without acceptance of BUM traffic. By default,
head-end replication is used; that implies that all BUM traffic entering to the bridge is sent to the other ports of
the bridge. That includes the VXLAN interface. For instance, ARP packets are transmitted through the VXLAN
interface. To block that traffic, it is possible to disable flooding, and configure BGP so as to forbid BUM traffic.
To inform remote peer that flooding is accepted, RT3 messages are sent. This message indicates that for a given
network defined by the RD, BUM traffic is accepted. flooding can be configured as follows:
vrf main
routing bgp
(continues on next page)
It is possible to reenable flooding by using following command. Consequently, RT3 updates will be propagated.
vrf main
routing bgp
address-family l2vpn-evpn
flooding head-end-replication
..
..
..
..
More information about route targets is given in route leaking use case. In L3VPN chapter, it was seen that RD and
RTs were used to import and export routes to different VPNs. Here, the same concepts are used, and are applied to
all kind of EVPN route types routes. This includes IP routes, but also MAC entries too. Also, the VPN concept is
mapped to VNI concept. This is why we refer to VNI.
In addition to the above essential steps, the RD and RTs can be configured for a VNI. By default, RD is automatically
derived by using IP4B:NN format, where IP4B stands for the IP address of the router-id used in BGP, and a unique
16 bit field identifier. RTs values is defined as AS:VNI, where AS stands for the AS value of the BGP instance, and
VNI is the virtual network identifier of the VXLAN interface. It is possible to redefine the RD value by using an
other semantic:
vrf main
routing bgp
router-id 10.125.0.1
as 65500
address-family l2vpn-evpn
vni 107
export route-distinguisher 65000:107
/ vrf custom1
routing bgp
router-id 10.125.1.1
as 65500
address-family l2vpn-evpn
(continues on next page)
It is also possible to override route target values, by using following command. Here, the VNI is used for encoding.
vrf main
routing bgp
router-id 10.125.0.1
as 65500
address-family l2vpn-evpn
advertise-all-vni true
vni 107
export route-target 65000:107
import route-target 65000:107
/ vrf custom1
routing bgp
router-id 10.125.1.1
as 65500
address-family l2vpn-evpn
export route-target 65000:101
import route-target 65000:101
RFC 8365 (https://tools.ietf.org/html/rfc8365.html) explains how RT auto derivation should be done in section
5.1.2.1. The lowest 4 bytes of the AA:NNNN are redefined. The new format is made up of the value 1 in the first 3-bit
field ( standing for VXLAN encapsulation), and the VNI value. This encoding is needed for proper interoperability
with RT auto-derivation in Junos. To configure this format automatically, use the following command:
vrf main
routing bgp
router-id 10.125.0.1
as 65500
address-family l2vpn-evpn
auto-route-target rfc8365
/ vrf custom1
routing bgp
router-id 10.125.1.1
as 65500
address-family l2vpn-evpn
auto-route-target rfc8365
As said in introduction chapter, EVPN can be used to carry either L2VPN information or L3VPN information. The
next chapters respectively discuss how to use EVPN as a L3VPN technology, then as a L2VPN technology.
Inter Subnet Forwarding is the ability to use a virtual bridge to route information on that bridge. BGP exchanges
this information by using RT2 messages. As underlay tunnel carries also MAC-level information, the source and
destination MAC addresses used ( and transmitted via BGP) are the MAC addresses of the bridge interface attached.
Like for L3VPN, IP prefixes can be assigned to a specific VR, and the bridged interfaces will act as both tunnel
endpoint and remote gateway to join a separate remote IP network.
To configure routing, by using a VXLAN interface, its VNI must be configured as an L3VPN vni. By default, each
VNI presence detection is seen as a EVPN one. You have to explicitly mention the VNI as a layer 3 VNI.
vrf custom1
routing l3-vni 11
interface vxlan vxlan-101 vni 11
routing bgp as 65500
The remaining configuration is same as the one presented in the first chapter, ie both a vxlan and slave to a bridge
interface in the same VR. To bring clarity, the whole configuration is reused, and is based on ref:BGP EVPN use
case example <routing-bgp-evpn-drawing>, where rt1 and rt2 devices configuration are exposed.
rt1
vrf main
routing
bgp
router-id 10.125.0.1
as 65500
address-family
l2vpn-evpn
enabled true
advertise-all-vni true
..
..
neighbor 10.125.0.2
remote-as 65500
address-family
l2vpn-evpn
enabled true
..
..
..
..
..
interface physical eth0
port pci-b0s4
mtu 1550
ipv4 address 10.125.0.1/24
..
..
..
vrf custom1
interface physical eth1
ipv4 address 10.51.0.1/24
port pci-b0s6
..
..
interface vxlan vxl11
mtu 1500
vni 11
local 10.125.0.1
link-interface eth0
link-vrf main
..
..
interface bridge br11
(continues on next page)
rt2
vrf main
routing
bgp
router-id 10.125.0.2
as 65500
address-family
l2vpn-evpn
enabled true
advertise-all-vni true
..
..
neighbor 10.125.0.1
remote-as 65500
address-family
l2vpn-evpn
enabled true
(continues on next page)
To propagate IP information in the L2VPN, a second BGP instance is created in the VR. That instance will explicitly
tell to advertise IP information to the main core instance. That second BGP instance redistributes sub networks from
eth1 interface, as depicted in below command:
*>i[5]:[0]:[24]:[10.50.0.0]
10.125.0.1 0 100 0 ?
*>i[5]:[0]:[24]:[10.51.0.0]
10.125.0.1 0 100 0 ?
* [5]:[0]:[24]:[10.51.0.0]
10.125.0.2 0 32768 ?
*> [5]:[0]:[24]:[10.52.0.0]
10.125.0.2 0 32768 ?
The below commands show that the imported route entries from remote peers have been accordingly set to the VR.
Also, the EVPN entries transmitted in the core instance are dumped too.
That second BGP instance can also be used to connect with remote CE. This permits extending the L3 connectivity
behind each PE devices. The propagated routes transmitted to the CE will use the PE as next-hop to reach that
subnetwork.
To unconfigure a layer 3 VNI and its associated BGP core instance, use the following command to remove both
configuration. Optionally, the bridge and VXLAN interface configuration can be removed:
vrf custom1
del routing l3-vni
del routing bgp
del interface vxlan vxl11
del interface bridge br11
Bridge Configuration
Bridging permits to aggregate layer 2 networks into a single one, by bridging each network with VXLAN interface.
Like for routing, a bridge and a vxlan interface are needed, and need to be bridged, so that BGP populates its VNI
list.
Subsequently, the VNI layer information is propagated in the system. BGP uses the VNI information to extract
the bridge neighboring information contained to transmit it by using RT2 entries. Based on BGP EVPN use case
example, rt1 and rt2 devices configuration are exposed below:
rt1
vrf main
routing
bgp
router-id 10.125.0.1
as 65500
address-family
l2vpn-evpn
enabled true
advertise-all-vni true
auto-route-target rfc8365
vni 11
advertise-default-gw true
export route-distinguisher 65500:11
..
..
..
neighbor 10.125.0.2
remote-as 65500
address-family
l2vpn-evpn
(continues on next page)
rt2
vrf main
routing
bgp
router-id 10.125.0.2
as 65500
address-family
l2vpn-evpn
(continues on next page)
A summary of the discovered VXLAN interfaces can be seen with following command:
You can note that advertise-default-gw keyword applied to VNI configuration transmits RT2 entries informing
about the IPs available on br11 interface. Also, because flooding mode is enabled by default, you can note RT3
entries.
*> [2]:[0]:[48]:[82:40:b3:d1:b8:3d]:[32]:[10.50.0.1]
10.125.0.1 32768 i
*> [2]:[0]:[48]:[82:40:b3:d1:b8:3d]:[128]:[fe80::90aa:89ff:fed9:c6ce]
10.125.0.1 32768 i
*>i[2]:[0]:[48]:[d2:e6:d8:87:34:5d]:[32]:[10.50.0.2]
10.125.0.2 100 0 i
*>i[2]:[0]:[48]:[d2:e6:d8:87:34:5d]:[128]:[fe80::85a:72ff:fee5:2c21]
10.125.0.2 100 0 i
*> [3]:[0]:[32]:[10.125.0.1]
10.125.0.1 32768 i
*>i[3]:[0]:[32]:[10.125.0.2]
10.125.0.2 100 0 i
Consequently, the neighboring table is populated with local entries found locally, and remote entries learnt from
BGP. For instance, 10.50.0.1 has been detected as a machine in the local network of rt1, and its MAC address
and the IP association has been propagated to the remote BGP speaker.
It is possible to extend the layer 2 network by having a private network behind eth0. On the other way, VTEPs can
be increased by multiplying the number of BGP peers and using route-reflector peers. While BUM traffic will be
transmitted as if it was a local switch engine, if MAC table gets populated with the right MAC address, then traffic
will be transmitted accordingly.
RPKI In BGP
As BGP plays an important role in the backbone infrastructure, it is important to secure it, so as to ensure for every
router the validity of learned prefixes.
There are different methods to secure exchanged BGP prefixes. The one that is presented here is a method that
relies on a server/client model. The server is part of an RPKI (Resource Public Key Infrastructure), as it stands for a
trusted cache server. The client is a BGP device that initiates a specific connection to the server, where Route Origin
Authorizations (ROA (Route Origin Authorization)) are stored, and downloads them. Subsequently, any device can
do prefix origin validation by referring to that server storage.
The specific connection done between a BGP device and the server cache uses a standard mechanism that maintains
the exchange of the prefix/origin AS mapping between the cache server and routers. This is the RPKI protocol
defined by RFC 6810 (https://tools.ietf.org/html/rfc6810.html).
RPKI/RTR (Resource Public Key Infrastructure to Router Protocol) cache configuration is made up of a list of
servers indexed in order of preference; the lowest index representing the most preferred connection that will be tried
to sync with. If the server is not reachable, then the next server with the closest preference is tested; and so on, until
the connection succeeds and the resync mechanism applies.
RPKI/RTR protocol may optionally run over a secure connection. For that, an encryption protocol should be set on
both ends (on the server and the client), with the appropriate keying material and authorizations.
An example of cache-server configuration for RPKI looks like the following:
To check if the RPKI/RTR connection did succeed, use the following command:
It is also possible to remove the RPKI/RTR synchronization either by removing the cache server entry, or by remov-
ing the whole RPKI configuration:
The Turbo Router offers the possibility to secure an RPKI/RTR connection using SSH. For that, the cache server
must be set as an SSH server, with the appropriate authorizations and users; and the client must have a public/private
key in order to authenticate to the server without interactively typing a password.
The cryptographic keys can be generated from the CLI as follows:
vrouter> cmd bgp rpki ssh-key create name keyfor_rpki type rsa-4096
Asymmetric key can either be RSA (Rivest Shamir Adleman algorithm), ECDSA (Elliptic Curve Digital Signature
Algorithm) or EDDSA (Edwards Curve Digital Signature Algorithm), and are indexed by a keyword. It is possible
to configure some parameters like key length for RSA (1024, 2048 or 4096 bits), or ECDSA (256, 384, or 512 bits).
However, EDDSA is not customizable, and its key length is automatically set to 25519 bits.
Keys stored in the system can be listed with:
˓→+edLqHpmSOzwyV9qjf2y09vbAODkhoHhH23UBBu3KvweUpvXnfj4aQlqdssHLE9td1MtlNBrPXvzA1aKzzGQ1lFeNvN5z4Y
˓→CSKFSl6RUHN3esPVV8I+tZT3MVYxRP91NRutESabuahyif+v2CxVngaqhjcrGlIiVK7BuZBpXTHUit7fKMfwx9XxIhhls+u
˓→eo5EN0RN8lpN+fFCyVuI8V3r2Qds80lwVP03GHEzNc+gsKEbnp5ghM543ChfjoUtTGIbzN5fW/
˓→Nf0m+VLV6nWmZ7890Zx6d5qFqShLCPZ3GEenzJ/R5wZA9U+l/
˓→LbtnWJW9jwPYUfMbzsm0BeAKl5KiHhhOQMRnc/HOc1shD+R6zgQdMn35kdjapXSnFK2yBqb/
˓→4xw5tlP8GbOAslP9yewpq4qjTw== root@vrouter
The public key should then be copied to the SSH server’s list of authorized_keys, under a user account created for
RPKI/RTR connections.
In addition to forging local key material, it may be necessary to learn the public keys of remote servers. This can be
done using the following command that populates the database with the keys of all the SSH hosts:
vrouter> cmd bgp rpki ssh-host add XXX.XXX.XXX.XXX port xxxxx vrf customer1
In case it is necessary to flush entries associated to a particular host from the local database, the following command
can be used:
Once the underlying SSH connection can be established from client to server using the newly generated keys, the
secure RPKI/RTR connection can be set like below:
RPKI Miscellaneous
It is possible to configure the retry interval triggered when a server becomes unreachable. By default, retries are
issued each 300 seconds. It is possible to modify this value using the following command:
vrouter running config# vrf customer1 routing bgp rpki retry-interval 400
It is also possible to configure an expiration interval for unreachable servers. The interval is set, by default, to 7200
seconds. It can be modified by issuing the following command:
vrouter running config# vrf customer1 routing bgp rpki expire-interval 7500
Similarly, it is possible to configure the polling period between two consecutive refreshes, to update the list of
prefixes. Default is 3600 seconds. It can be modified by issuing the following command:
vrouter running config# vrf customer1 routing bgp rpki polling-period 3700
RPKI Validation
Routing decisions can be made based on RPKI route announcement validity. They are implemented at BGP neighbor
level, by the means of a route-map, applied to the ingress direction. The keywords rpki valid, rpki invalid
or rpki notfound can be invoked in a given route-map sequence, thus triggering a policy when matched.
The below example depicts what can be done in order to accept valid prefixes; reject invalid prefixes; and set a low
local preference to unknown prefixes, as they can’t be fully trusted.
routing
route-map rmap
seq 1
policy permit
match rpki valid
..
seq 2
policy deny
match rpki invalid
..
(continues on next page)
MPLS
LDP
LDP Overview
The LDP daemon is a standardised protocol that permits exchanging MPLS label information between MPLS capa-
ble devices (also called LSRs (Label-Switched Routers) or LERs (Label Edge Routers)). The LDP protocol creates
peering between devices, so as to exchange FEC (Forwarding Equivalence Class) information linking networks and
labels together. This information is stored in MPLS binding tables. Then, based on available routing table, on the
one hand, an MPLS label is appended to the routing table for locally generated packets; on the other hand, LFIB
entry is created with that label information for incoming MPLS frames. By acting this way, data traffic is encapsu-
lated in MPLS header, and on each LSR, the incoming label will determine which label has to be swapped, instead
of the former one. MPLS permits carrying any transportation data through that MPLS backbone. It is possible to
carry L3VPN traffic inside, thus permitting transporting overlapping data to different place. LDP often works in
conjunction with IGP routing protocols like OSPF, thus facilitating the discovery of the backbone, and permitting
to know for some traffic having to go through that backbone what is the best path to take.
The LDP is handled by FRR (https://frrouting.org/).
LDP aims at sharing label information across devices. It tries to establish peering with remote LDP capable devices,
first by discovering using UDP port 646 and multicast address 224.0.0.2 on the connected nodes, then by peering
using TCP port 646. Once the TCP session is established, the following happens:
Note: This is the standard way for LDP sessions to peer together in a LSR. For that, LDP peers are directly
connected, so that a label can be assigned to each IGP route. Let us remind that label switching of packets is hop
per hop.
• The list of IP addresses that each device owns is sent via an Address Message LDP message. Knowing
local IP addresses permits to know that this address is reachable via an implicit-null message.
• Then Label Mapping Messages are sent. Those messages stand for each known network associatet to a
label. This is the so-called FEC information, where usually a destination IP prefix is bound to a label. It
is worth to be noted that when a route is connected, the label associated is implicit-null, which is 3 in
the case of IPv4. For the other routes, an arbitrary label value is communicated. A binding table is then
forged on each device, and contains, for each route, the local label emitted for each network, and the remote
label received from remote peer. This table is then used to apply labels to already present routes.
There are different methods to send label advertisement modes. The implementation actually supports the following
: Liberal Label Retention + Downstream Unsolicited + Independent Control. The other advertising modes are
depicted below, and compared with the current implementation.
• Liberal label retention versus conservative mode: In liberal mode, every label sent by every LSR is stored in
the MPLS table. In conservative mode, only the label that was sent by the best next hop (determined by the
IGP metric) for that particular FEC is stored in the MPLS table.
• Independent LSP Control versus ordered LSP Control MPLS has two ways of binding labels to FEC; either
through ordered LSP control, or independent LSP control. Ordered LSP control only binds a label to a FEC
if it is the egress LSR, or the router received a label binding for a FEC from the next hop router. In this mode,
an MPLS router will create a label binding for each FEC and distribute it to its neighbors so long as he has
a entry in the RIB for the destination. In the other mode, label bindings are made without any dependencies
on another router advertising a label for a particular FEC. Each router makes it own independent decision
to create a label for each FEC. By default IOS uses Independent LSP Control, while Juniper implements the
Ordered Control. Both modes are interoperable, the difference is that Ordered Control prevent blackholing
during the LDP convergence process, at cost of slowing down the convergence itself
• unsolicited downstream versus downstream on demand Downstream on demand label distribution is where an
LSR must explicitly request that a label be sent from its downstream router for a particular FEC. Unsolicited
label distribution is where a label is sent from the downstream router without the original router requesting it.
LDP has by default the PHP (Penultimate Hop Popping) functionality. That functionality stipulates that the outer-
most label of an MPLS tagged packet is removed by a LSR before the packet is passed to an adjacent LER. This
behaviour permits sparing one cpu cycle on the LER, by not popping that last label. However, LDP provides the
configuration mean to disable that feature, by using explicit-null labels.
RFC
LDP configuration
There are a list of necessary elements to know when forging a LDP configuration.
When forging a LDP configuration, a router-id has to be defined. It is usually the IP address of one loopback
interface. Then the address-family where LDP will operate the discovery has to be configured, as well as the
interfaces, and the IP transportation to use.
Here below is an example on how to configure a sample LDP configuration with IPv4 address-family set:
vrf main
routing mpls ldp
router-id 5.5.5.5
address-family ipv4
discovery transport-address 5.5.5.5
interface eth0_0
..
..
..
..
..
..
commit
Note: You can also disable LDP, either by suppressing the configuration:
vrf main
del routing mpls ldp
..
Alternatively, if you don’t want to lose the configuration, and disabling LDP configuration, you can use following
command:
vrf main
routing mpls ldp
enabled false
This method can be used if the user wants to force the reset of LDP configuration.
vrf main
routing mpls ldp enabled false
commit
routing mpls ldp enabled true
commit
Instantiating a basic back to back configuration setup between two devices is a first step towards understanding
LDP but is not enough. Below configuration illustrates this, with rt1 and rt2 configurations. The basic neighbour
discovery mechanism is used to make the peering work. You can note that LDP operates over loopback interfaces,
like most IGP do. Following drawing illustrates the networking topology and information.
.1 .2
10.1.2.0/24 LER RT1 6.6.6.0/24 LER RT2
600::0/64
loopback
loopback
5.5.5.5/32
10.10.10.10/32
5:5::5:5/128
10:10::10:10/128
rt1
vrf main
routing mpls ldp
router-id 5.5.5.5
dual-stack transport-preference ipv4
address-family ipv4
discovery transport-address 5.5.5.5
interface eth0_0
..
..
..
address-family ipv6
discovery transport-address 5:5::5:5
interface eth0_0
..
..
..
..
..
..
routing static
ipv4-route 10.10.10.10/32 next-hop 6.6.6.2
(continues on next page)
rt2
vrf main
routing mpls ldp
router-id 10.10.10.10
dual-stack transport-preference ipv4
discovery hello holdtime 2
discovery hello interval 2
address-family ipv4
discovery transport-address 10.10.10.10
interface eth0_0
..
..
..
address-family ipv6
discovery transport-address 10:10::10:10
interface eth0_0
..
..
..
..
..
..
routing static
ipv4-route 5.5.5.5/32 next-hop 6.6.6.1
ipv6-route 5:5::5:5/128 next-hop 6000::1
..
..
(continues on next page)
After having executed the two configurations, the status of the LDP discovery can be obtained, by using following
command:
Also, to know about the status of the peering connections, there is a specific command for that (see below). You
can note that the two neighbors successfully peered together, as you can see that the state of the connection is
OPERATIONAL. The discovery process on UDP port 646 resulted in creating a TCP session between both sides.
Subsequently, destination prefixes and labels were exchanged.
It is worth to be noted that the destination prefixes exchanges rely on the address family to be configured. Not
configuring it will result in not having destination prefixes of that address-family. Also, if chosen, the discovery
transport-address is necessary. Also, it is worth to be noted that LDP protocol plans to use ipv6 if both address-
families are chosen. To mitigate this, an extra command has been added (dual-stack transport-preference
ipv4) to the configuration so as to fallback over ipv4.
The above configuration results in having the following list of bindings. As said previously, the establishment of
TCP sessions between ldp peers, leads to exchange of label mapping messages that permit exchange FEC. In
our usage, the FEC stands for the relationship between a Label and a destination IP. The Local Label column
stands for locally generated messages and outgoing label to be applied, while Remote Labels stand for received
messages from peers. The remote label information is used to establish switching rules. Nexthop stands for the
ldp remote peer IP address that sent the message.
The In Use column tells if the system has routing or switching support to add label information or not. 5.5.5.
5/32 and 5:5::5:5/128 are local networks, so do not need to be used with MPLS. However, as we have static
routes for reaching 10.10.10.10/32 and 10:10::10:10/128 networks, the binding MPLS information will be
used. Practically, an implicit-null label is appended to route entry.
Also, an MPLS switching entry is put in place, so that incoming MPLS packets coming with a label of 16 or 17 be
switched with an implicit-null label to go to respective nexthop 6.6.6.2 and 6000::2.
rt1> show mpls table
Inbound Outbound Label Type Nexthop Label
——– ——- ————— ——– 16 LDP 6.6.6.2 implicit-null 17 LDP 6000::2 implicit-null
Above example illustrates that back to back configurations, the label used is an implicit-null label. That label is
used when the nexthop is adjacent, that is to say connected. This is called the penultimate hop popping feature. PHP
feature avoids having an outermost label between the last LSR and the LER where traffic is heading to. However,
that feature can be interesting to disable on some cases. For instance, when working on a back to back operating
mode. Below example gives an example on how explicit-null labels can be configured instead of using implicit-null
labels on the LER side.
rt1
vrf main
routing mpls ldp
router-id 5.5.5.5
address-family ipv4
discovery transport-address 5.5.5.5
label local advertise explicit-null
interface eth0_0
..
..
..
..
..
..
routing static
ipv4-route 10.10.10.10/32 next-hop 6.6.6.2
(continues on next page)
rt2
vrf main
[..]
routing mpls ldp
router-id 10.10.10.10
dual-stack transport-preference ipv4
address-family ipv4
discovery transport-address 10.10.10.10
label local advertise explicit-null
[..]
On the peer router receiving the LDP advertisements, an explicit-null label is received, associated with the
10.10.10.10 next-hop address.
Note: explicit-null label must be only used if it is the last label, that is to say that the label will have BOS
bit. In other case will trigger packet drops ( as per RFC 3032 (https://tools.ietf.org/html/rfc3032.html)). Example
scenario where that value can be used will only involve LDP, not L3VPN with multiple stacking.
LDP Interoperability
LDP specification stipulates to use ipv6 transporation when both address-families are negotiated. Adding to this,
Cisco uses a non-compliant format to send and interpret the dual-stack capabilities TLV contained in LDP packets.
For that, it is possible to align with cisco behaviour and a configuration command is available :
vrf main
routing mpls ldp
router-id 10.10.10.10
dual-stack cisco-interop true
address-family ipv4
discovery transport-address 10.10.10.10
interface eth0_0
..
..
..
address-family ipv6
discovery transport-address 10:10::10:10
interface eth0_0
..
..
..
..
eth1_0 eth2_0
RT5
16.16.16.0/24
14.14.14.0/24
eth0_0
12.12.12.0/24
eth1_0 eth2_0
eth2_0
Fig. 11: LDP backbone illustration with multiple nodes, and multiple paths
Following setup illustrates what a backbone looks like. Actually, to prevent from link failure or node failure, you
can see that there are several paths available to link some nodes together. For instance, to link rt1 with rt2, either
rt5 or rt4 can be used, thus preventing from link failure. Also, to prevent from r4 node failure, you can note that
there is a path that links rt2 to rt3 by relying on rt5 instead.
By default, multipath is enabled. That implies that unless you rely on some IGP like OSPF to help in finding out
some routing decisions, available paths will be equal. ( for example, lowering the bandwidth or configuring the cost
of the interface between rt2 and rt5 will trigger in proposing only one route).
The above diagram relies on both OSPF and LDP routing daemons. OSPF is used for IP discovery, while LDP will
allocate labels for LSR and LER. Below is shown the aggregated LDP and OSPF configuration.
rt1
routing ospf
router-id 5.5.5.5
network 5.5.5.5/32 area 0
network 6.6.6.0/24 area 0
passive-interface loop1
..
..
(continues on next page)
rt2
routing ospf
router-id 9.9.9.9
network 9.9.9.9/32 area 0
network 8.8.8.0/24 area 0
network 16.16.16.0/24 area 0
passive-interface loop1
..
interface eth1_0
ip ospf cost 100
..
..
routing mpls ldp
router-id 9.9.9.9
address-family ipv4
discovery transport-address 9.9.9.9
interface eth0_0
..
interface eth1_0
..
(continues on next page)
rt3
routing ospf
router-id 10.10.10.10
network 10.10.10.10/32 area 0
network 6.6.6.0/24 area 0
network 7.7.7.0/24 area 0
passive-interface loop1
..
..
routing mpls ldp
router-id 10.10.10.10
address-family ipv4
discovery transport-address 10.10.10.10
interface eth0_0
..
interface eth1_0
..
interface eth2_0
..
..
..
..
(continues on next page)
rt4
routing ospf
router-id 11.11.11.11
network 11.11.11.11/32 area 0
network 12.12.12.0/24 area 0
network 7.7.7.0/24 area 0
passive-interface loop1
..
..
routing mpls ldp
router-id 11.11.11.11
address-family ipv4
discovery transport-address 11.11.11.11
interface eth0_0
..
interface eth1_0
..
interface eth2_0
..
..
..
(continues on next page)
rt5
routing ospf
router-id 15.15.15.15
network 15.15.15.15/32 area 0
network 12.12.12.0/24 area 0
network 16.16.16.0/24 area 0
network 14.14.14.0/24 area 0
passive-interface loop1
..
interface eth1_0
ip ospf cost 100
..
..
routing mpls ldp
router-id 15.15.15.15
address-family ipv4
discovery transport-address 15.15.15.15
interface eth0_0
..
interface eth1_0
(continues on next page)
After having executed the above configurations, the status of the LDP connections can be obtained. The peerings
between the devices can be visualised with the following command:
It is possible to get the whole list of bindings that LDP made, on each IP route. As LDP obtains labels for all
networks, those labels are bound and installed, upon availability of associated network entries on the underlying
system. The redistributed OSPF routes are then useful for that.
Note that some entries are not in use, since OSPF did choose to prefer rt4 link over rt5 link. Subsequently, it is
also possible what are the bindings currently installed on the system:
It is also possible to dump the contexts of the LSR. For instance, on rt3 or rt4, one can see the LFIB:
LDP security
LDP is a critical service for the internet infrastructure. Security aspects for LDP are important.
In order to avoid peering with unexpected neighbors, it is possible to configure a password on both sides. A TCP
MD5 digest is then calculated, thus preventing to create a peering with a misconfigured peer.
vrf main
routing mpls ldp
router-id 10.10.10.10
neighbor 5.5.5.5 password secret_phrase
address-family ipv4
discovery transport-address 10.10.10.10
interface eth0_0
..
..
..
..
..
..
RFC 6720 (https://tools.ietf.org/html/rfc6720.html) stipulates that only nodes from connected links are considered
as accepted, when it comes to LDP peering with basic discovery mode. This is where ttl-security acts, since it
ensures that the node is really connected, by not only looking up the ttl value, but also appending some values on the
LDP options. It is however possible to disable that security check in some cases, for instance, to keep compatibility
with old RFC 5082 (https://tools.ietf.org/html/rfc5082.html). To disable ttl-security checking, use the following
command:
vrf main
mpls ldp
(continues on next page)
LDP filtering
There are some set of commands that permit filtering the LDP behavior, either by filtering incoming requests or
filtering outgoing requests. For instance, it is possible to accept incoming ipv4 or ipv6 incoming, by filtering based
on the remote LDP peer.Below configuration illustrates this:
vrf main
routing mpls ldp
router-id 10.10.10.10
address-family ipv4
discovery transport-address 10.10.10.10
interface eth0_0
..
label remote accept from 11
..
..
..
..
..
..
routing
ipv4-access-list 11 permit 10.10.10.10/32
It is also possible to apply filtering on incoming requests, based on the incoming destination prefixes, like suggests
below configuration with an incoming prefix 4.4.4.0/24.
vrf main
routing mpls ldp
router-id 10.10.10.10
address-family ipv4
discovery transport-address 10.10.10.10
(continues on next page)
It is also possible to apply filtering on the allocated labels. Locally, a label may be allocated only for host routes,
thus sparing labels.
vrf main
routing mpls ldp
router-id 10.10.10.10
address-family ipv4
discovery transport-address 10.10.10.10
interface eth0_0
..
label local allocate host-routes
..
..
..
..
..
..
Adding to this, if it is not enough, it is also possible to control the allocation of labels by explicitly listing the
destination prefixes that should gain a binding.
vrf main
routing mpls ldp
router-id 10.10.10.10
address-family ipv4
discovery transport-address 10.10.10.10
interface eth1_0
..
interface eth0_0
..
label local allocate for 13
..
(continues on next page)
Finally, it is possible to do outgoing filtering, by selecting which peer or which destination prefix deserves to be sent
or not. Like below example suggests, only the destination prefix 4.4.4.0/24 will only be sent to peer 5.5.5.5.
vrf main
routing mpls ldp
router-id 10.10.10.10
address-family ipv4
discovery transport-address 10.10.10.10
interface eth0_0
..
label local advertise to 14 for 15
..
..
..
..
..
..
routing
ipv4-access-list 14 permit 5.5.5.5/32
ipv4-access-list 15 permit 4.4.4.0/24
MPLS
MPLS aims at combining the switching technique at network layer 2 of labels, with the layer 3 protocols. Nowa-
days, many backbone networks use MPLS as the switching technology carrying any kind of traffic. MPLS permits
performance, thanks to the switching technique very close to what ATM or Frame-Relay was doing a few years ago.
Initially, IP networks were carried by MPLS. Today, because any transport over MPLS is possible ( ATOM (Any
Transport Over MPLS)), it is also used to carry L3VPN and L2VPN traffic.
This chapter aims at explaining how MPLS works, explains the main concepts, and explains the differences with
classical routing.
MPLS terminology
It is important to understand the MPLS terminology. In this paragraph we will give the most important concepts.
LSR Labeled Switch Router. Networking devices handling labels used to forward traffic between and through them.
LER Labeled Edge Router. A Labeled edge router is located at the edge of an MPLS network, generally between
an IP network and an MPLS network.
LFIB Label Forwarding Information Base. A data structure in which incoming interface and incoming labels are
associated with outgoing interfaces and labels.
label binding An association between a label and a set of packets, which can be advertised to neighbors so that a
label switched path can be established.
FEC Forwarding Equivalent Class. It is a term used in Multiprotocol Label Switching (MPLS) to describe a set of
packets with similar or identical characteristics which may be forwarded the same way; that is, they may be
bound to the same MPLS label. In classical IP routing, the FEC choice is usually done according to destination
IP address.
MPLS label The MPLS label is a 4 byte field that contains a 20 bit label value, a 3 bit cos value, an 8 bit ttl value,
and 1 BOS bit indicating that the label is the last one of the stack. Actually, MPLS can be stacked (then we
could use the term LSP Tunneling or Label Stacking). This BOS information indicates that next payload
is not an MPLS packet.
MPLS operations
Here are the operations that are applied coming from A and going to B, through an MPLS network.
Packet will first be sent to a LER that stands for the ingress node.
On classical IP routing using Ethernet as medium, an incoming IP packet will be routed, by using its destination IP
address; the FIB is inspected, a nexthop IP is returned if everyting went well; then the MAC information is appended
to the packet; source mac address is the mac address of the outgoing interface, while destination mac address will
be obtained by using the destination mac address of the resolved nexthop.
On a LER, if the nexthop information is reachable through a MPLS network, an extra information called FEC will
be located in the FIB. A Label will be pushed between the IP layer and the MAC layer. This extra relationship is
called label binding.
Then, the encapsulated MPLS packet will be sent to the destination mac address indicated by its packet. It is
received by an incoming LSR. Here, the LFIB is looked up, based on the incoming MPLS label. LFIB returns a
swap operation: the incoming label will be replaced by an outgoing label; the new MPLS packet is being sent to the
next hop. Before reaching the final destination, the MPLS label must be popped. This happens if the LFIB indicates
to pop the label; for instance, the label is being replaced by an implicit-Null label. Here, the IP packet has reached
the egress node.
The whole path between the ingress and the egress node is called the LSP. The incoming label set at the ingress node,
will determine the whole path the packet uses to reach the egress node. By setting the appropriate FEC information
at the LER, it is possible to apply specific path, depending on the characteristics of the incoming traffic. Note also
that because that FEC information can be applied to all kind of traffic, one can have multiple criteria.
Label Distribution
Establishing a LSP requires coordination between all LER and LSR. This is done by distributing protocols. For
instance, this can be done by using LDP protocol. Please see Label Distribution Protocol for details.
Label Stacking
Several services can rely on MPLS framework, and not only IP. One example if L3VPN technology. BGP provides
the capability to exchange VPN information, by exchanging labels. Label stacking is then used. More information
can be found in BGP L3VPN.
RFC
DMVPN is a dynamic tunneling form of a VPN, that enables to create a dynamic-mesh VPN network without
having to statically pre-configure all possible tunnel endpoint peers.
The DMVPN solution enables to dynamically build an NBMA (Non-Broadcast Multiple Access) network that in-
terconnects scattered sites via GRE tunnels.
Static or dynamic GRE tunnels are used to interconnect the sites, the NHRP protocol is used to determine a route
with the fewest hops from a sender to a receiver.
The DMVPN solution relies on a hub and spoke model, but supports optimizing routes, so that spokes can directly
communicate together via dynamic GRE tunnels.
Finally, DMVPN supports an automatic IPsec protection with limited configuration.
Hub and Spoke model A computer network topology in which a series of spokes connect to a central hub. Com-
munication between spokes transits via the hub. The hub dispatches traffic or information among the spokes.
NBMA, Non-Broadcast Multiple-Access network A computer network to which multiple hosts are attached, but
data is transmitted only directly from one computer to another single host, typically over a virtual circuit. In
the DMVPN case, the virtual circuits are GRE tunnels.
NHRP, Next Hop Resolution Protocol A client-server protocol used to determine a route with the fewest hops
from a sender to a receiver in an NBMA network.
NHC (Next Hop Clients), NHRP client A client of the NHRP protocol, that runs on a spoke.
NHS (Next Hop Servers), NHRP server The server of the NHRP protocol, that runs on the hub.
DMVPN, Dynamic Multipoint Virtual Private Network A dynamic tunneling form of a VPN, that enables to
create a dynamic-mesh VPN network without having to statically pre-configure all possible tunnel endpoint
peers.
A DMVPN network is an NBMA network composed of spokes (NHC devices) connected to a central hub (NHS
device) via GRE tunnels.
Each device has an internal IP address, named the protocol address, typically configured on its GRE interface, and
an outer IP address, named the NBMA address, which is the source address of the GRE packets.
The hub and all spokes are considered IP neighbors in the NBMA network, whose IP addresses are their protocol
address.
All members of the DMVPN network register their protocol address and NBMA address to the NHS via the NHRP
protocol.
The NHRP protocol enables to resolve the next-hop to reach the protocol address of a neighbor in the NBMA
network, i.e. the destination IP address of GRE packets in which the packets should be encapsulated.
Depending on the situation, the next hop may be the NBMA address of the NHS (the traffic will transit via the hub)
or the NBMA address of the destination spoke (if a shortcut optimization is established).
Spokes
spoke1
Protocol Address
192.168.1.0/24 10.255.255.1
NBMA Address GR
11.11.11.11 E 11.
11.
11.
11
<->
GRE 11.11.11.11 <-> 22.22.22.22 44.
44.
44.
44 Hub
spoke2 NBMA network hub
Protocol Address GRE 22.22.22.22 <-> 44.44.44.44 Protocol Address
192.168.2.0/24 10.255.255.2 10.255.255.4 192.168.4.0/24
NBMA Address NBMA Address
44
22.22.22.22
4. 44. 44.44.44.44
4 4.4
<->
.33
33.33
E 33.
GR
spoke3
Protocol Address
192.168.3.0/24 10.255.255.3
NBMA Address
33.33.33.33
The diagram above illustrates the use case that will be used across all the phases proposed. It is a NBMA network
with 4 devices. One of those devices acts as the hub, while the others stand for the spokes. Here are some details:
• NBMA network spans over Internet and the nodes use public IPv4 addresses.
• each device has a GRE interface with an IP address on GRE interface named protocol address. That IP
address will need to be a 32 bit mask or 128 bit mask, whether it is an IPv4 or an IPv6 address. Configuring an
other bitmask will lead to a misconfiguration problem. Once done, NHRP will use that IP address to associate
with its NBMA address. NHRP is able to mount dynamically or statically routes to a remote NBMA address.
• each device is attached to its own private network 192.168.y.z/24. More than one private network can be used
behind GRE interface.
• a gre tunnel is established. This tunnel relies on NBMA source ip address of the device.
• Optionally, all traffic going through the gre interface is encrypted.
NHRP can help in establishing traffic between two devices, either between spoke and hub, or between two spokes.
In the former case, it is possible to avoid configuring multipoint GRE interfaces, as traffic is redirected to hub.
Note: DMVPN is partially supported on cross-vrf GRE interfaces, i.e. GRE interfaces with a link-vrf different
from their vrf: their cross-vrf must be vrf main.
The first two paragraphs describe how to use GRE interfaces and NHRP to establish connections between the spokes
via the hub, either statically or dynamically.
The last paragraph introduces the redirect feature that enables dynamic tunnel establishment between spokes.
Once the GRE interface is set up on the spokes, it is possible to use NHRP to mount routes to reach remote networks
from hub.
It is possible to configure NHRP static entries on both hub and spoke sides, so that NHRP routes will be automatically
added in the system. Note that this mechanism does not involve any communication between both sides, from NHRP
protocol point of view.
The other solution involves a transaction between the spokes and the hub. A spoke configures the NHRP service,
and declares a NHS. Actually NHS stands for the hub device. Once done, a spoke begins the transaction by sending
a NHRP registration request. This request contains the NBMA IP address associated to the protocol IP address of
the GRE interface. For the hub, the reception of incoming requests will lead to a registration reply indicating the
success (or the failure) of the operation, along with its NBMA and protocol IP address.
It is possible to send the traffic directly between spokes, by relying on point to multipoint GRE interfaces on the
spokes side too.
Tunnels are dynamically established, based on a nhrp redirect feature located on the hub side. NHRP helps
on the hub side by identifying traffic that is flowing in and out through the same GRE interface. The hub takes a
snapshot and sends some NHRP redirect information to the relevant spokes. At the end, the negotiation finalises
between the spokes.
RFC
Spokes
spoke1
Protocol Address
192.168.1.0/24 10.255.255.1
NBMA Address GR
11.11.11.11 E 11.
11.
11.
11
<->
GRE 11.11.11.11 <-> 22.22.22.22 44.
44.
44.
44 Hub
spoke2 NBMA network hub
Protocol Address GRE 22.22.22.22 <-> 44.44.44.44 Protocol Address
192.168.2.0/24 10.255.255.2 10.255.255.4 192.168.4.0/24
NBMA Address NBMA Address
.44
22.22.22.22
44 .44 44.44.44.44
44.
<->
3. 33
3.3
3.3
E3
GR
spoke3
Protocol Address
192.168.3.0/24 10.255.255.3
NBMA Address
33.33.33.33
The following configuration examples apply on the topology described in the above picture: 3 spokes connected to
a hub. The first two chapters describe how to use GRE interfaces and NHRP to establish connections between the
spokes via the hub, either statically or dynamically. The last chapter introduces the redirect feature that enables
dynamic tunnel establishment between spokes.
For all those examples, NHRP configuration requires that the IP address of GRE interface be configured with 32
bitmask, as follows. Configuring an other bitmask will lead to a misconfiguration problem.
spoke1
Static configuration
We can define static NHRP entries for remote endpoints on each node. From a protocol point of view, hub and
spokes don’t exchange messages then. The hub declares the protocol address and the NBMA address of the spokes.
The spokes only declare a NHRP entry for the hub. In that case, spoke-to-spoke communications flow through the
hub. Therefore the hub declares a multipoint GRE interface facing all the spokes and the spokes declare a GRE
interface facing the hub only. In addition, each node runs a BGP instance to advertise its private network and learn
the route towards the private subnets of the other nodes.
First we configure the three spokes with a static NHRP entry for the hub:
spoke1
spoke2
spoke3
Similarly, we configure static NHRP entries for each spoke on the hub. The main difference is that we configure a
multipoint GRE on this node, by omitting a remote address, to be able to reach each spoke:
hub
We can see that there is a NHRP connection between the hub and each device:
As a consequence, a NHRP route towards the protocol address of the hub is installed on each spoke. This way, they
can establish a BGP peering and learn the routes to other nodes:
The hub installs a NHRP route for each spoke and learns the remote private networks through BGP:
Dynamic configuration
Static configuration doesn’t scale well as you have to declare each spoke individually on the hub. We can fully
leverage NHRP and use dynamic configuration instead. In this configuration, the NHRP server on the hub listens
for registration requests. Each spoke declares the hub as a NHRP server and thus registers upon startup using NHRP
control packets. With the basic setup below, spoke-to-spoke communication still runs through the hub but can then
be improved to allow Direct spoke-to-spoke communication. That’s why we configure point to multipoint GRE
interface on both spoke and hub side.
BGP configuration
In addition, each node runs a BGP instance to advertise its private network. As the chapter deals with spoke to hub
communication, only hub is interested in getting the private networks located behind spokes.
iBGP configuration
It is possible to keep using iBGP sessions between spokes and hub, like it has been done on previous experiment. In
that case, spokes will install iBGP routes to reach private networks from other spokes, but by using hub as nexthop.
A snapshot of configuration can be illustrated below with spoke1, spoke2 and hub devices:
Below dump gives the initial ipv4 routing table on spoke1. One can see routes installed to reach spoke2, spoke3
and hub.
eBGP configuration
It is also possible to avoid transmitting the private networks information to all spokes. Two reasons for that:
• In that setup where data is always passing through the hub, there is no point giving this information to spokes
that always point to hub.
• This routing information is redundant with NHRP when direct spoke to spoke communication will be put in
place. Even if iBGP routes were used, NHRP routes to those private networks would override those BGP
routes, and NHRP routes would directly have the nexthop set to the appropriate spoke.
For the rest of this chapter, We choose to use eBGP configuration. The hub will transmit two aggregated networks,
192.168.0.0/16 and 10.255.255.0/24. This stands for the subnetworks to all spokes. You can note that eBGP
requires peers to be directly connected. As the route to reach the hub IP on the spoke is a NHRP route and not a
connected route, an additional configuration is put in place, in order to inject incoming BGP network. This is done
via ebgp-connected-route-check BGP configuration command:
Note: Using eBGP avoids spokes to learn BGP route entries from spokes on same AS coming from an external
AS. This specificity works because the spokes BGP configurations use the same AS and are not fully meshed.
Note: An other alternative to defining aggregated networks on hub side is to define a default-route at hub side, like
below BGP command shows it:
For that, there must not be any conflicts with learnt default route of the ISPs of local spokes. A good practice would
be to build GRE interfaces on separate VRF from wan interface. Below example illustrates how to move NHRP
contexts and lan interface to a VRF nhrp. In that case, NHRP routes will be visible from the VRF nhrp.
Configuration
The following configuration applies on the same topology with one hub and three spokes.
spoke1
spoke2
spoke3
Similarly, we do not declare any spoke entry on the hub. This node only listens for NHRP registration requests and
then for BGP peerings coming from the spokes.
hub
And the NHRP connections: each spoke has an NHRP connection with the hub:
We can also dump the link layer contexts of gre4 interface on the hub, to check the status of connected spokes, by
using following command:
As a consequence, a NHRP route towards the protocol address of the hub is installed on each spoke. This way, each
spoke can establish a BGP peering session and learn the routes to the hub:
The hub installs a NHRP route for each spoke and learns the remote private networks through BGP:
As you can see, the remote networks are learnt via BGP server from hub, and NHRP routes are set up with a higher
priority (10) compared with BGP (20).
All traffic goes through the hub device. This is also the main drawback of this configuration, since it is not possible
to establish spoke-to-spoke traffic.
This enhancement enables direct spoke-to-spoke traffic, without routing through the hub. It uses the NHRP redirect
feature and must be applied on top of a Dynamic configuration.
This feature, once enabled on the hub, detects a traffic flow that enters and exits the hub through the same GRE
interface. This traffic flow can be redirected as the hub is only routing the flow between two spokes. Then the
NHRP daemon of the hub issues a NHRP traffic indication message containing the detected packet to the
emitter. A spoke receiving such a message performs a NHRP resolution request to find the NBMA address of the
destination and then continues the communication directly with the destination spoke.
Note: The traffic flow detection mechanism is implemented by the fast path. Therefore, the fast path must be
enabled on the hub to benefit from the spoke-to-spoke direct communication.
This enables the sampling of the overlay traffic of the gre4 interface. Only the packets that come from this interface
and are forwarded through the same interface are eligible for capture. In order to avoid exhausting the device CPU,
the NHRP daemon applies a default sampling rate of 1 packet out of 400. If the destination address matches
one of the registered spokes, the hub attaches the packet to a NHRP traffic indication packet, and sends it to
the sender spoke.
Then we enable the shortcut feature on the spokes so that these messages get processed:
As the message contains the original destination IP, upon reception, the spoke sends a NHRP resolution request,
routed by the hub and replied by the destination spoke. Then both spokes continue the communication bypassing
the hub.
On direct spoke to spoke communication, one can distinguish two kinds of traffic. Each traffic will result in NHRP
messages exchange involving spokes and hub, as depicted above.
• The protocol address to protocol address communication between spokes. This is done by issuing
traffic between those IP addresses. It will result in the creation of a dynamic cache entry.
• The traffic between private networks located behind GRE interfaces. In addition to the creation of the above
mentioned dynamic cache entry, it will result in the creation of a shortcut entry.
Let’s perform traffic between protocol address of each spoke. To achieve this communication, NHRP protocol
will create a dynamic cache entry identifying the two spokes that want to communicate together. From dataplane
perspective, a NHRP connected route will be setup on the GRE interface, after the mutual resolution. Example is
given below by issuing following cmd ping command:
spoke1 running config# cmd ping 10.255.255.2 source 10.255.255.1 vrf main rate 100
It is worth to be noted that in the last spoke2 dump, NBMA address can be the hub NBMA address, because
the resolution request coming from spoke1 has been forwarded by hub, and no direct resolution request has been
received by spoke2 from spoke1. To be sure that the association between spoke1 protocol address and its NBMA
address has been correctly done, the attribute NBMA-NAT-OA-Address in show nhrp command indicates the real
NBMA address used.
We can see that there is now an additional NHRP connection from spoke1 to spoke2:
Like it has been noted for spoke2 with show nhrp cache dump, the remote entry to 11.11.11.11 may not be
present, while no direct resolution has been identified by spoke2.
As indicated below, a new NHRP connected route entry has been set up. Note that up to now, only traffic between
Protocol Address of spokes has been initiated; and that traffic between private networks (192.168.x.0/24) still
uses the hub.
Shortcut entry
Now, let us perform a cmd ping command between private networks. This command will result in the capture of
this traffic on the hub and will lead to the creation of a shortcut entry on spokes.
spoke1 running config# cmd ping 192.168.2.1 source 192.168.1.1 vrf main rate 100
The NHRP entries help in creating route entries linked to private networks behind each GRE device. For instance,
sub-network 192.168.2.0/24 is discovered by NHRP, on spoke1, when traffic is issued from spoke1 to that
destination network. On hub, the traffic is intercepted and sent to spoke2 for NHRP resolution. spoke2 parses the
available networks hidden behind GRE interface, and if present, transmits a resolution response to spoke1 which
creates a nexthop route entry linked to spoke2 dynamic entry, as follows:
As can be seen, a NHRP onlink route has been created, and reflects the NHRP shortcut entry created. This entry
relies on the NHRP dynamic cache entry previously created when initiating traffic between Protocol Address of
spokes.
Note: To bring more clarity, the chapter presented how the cache entry is created, then how the shortcut entry is
created, according to each incoming traffic. This said, in reality, launching private network traffic will result in the
creation of the two NHRP routes necessary to make spoke-to-spoke communication.
Nexthop route to 192.168.2.0/24 is introduced, and partially overrides 192.168.0.0/16 defined by BGP. As
illustrated, the routing decision in NHRP is made thanks to routing information the protocol has when receiving a
resolution request. The traffic indication was about a specific IP whereas the resulting route reflects the route of the
remote spoke. In our case, the network 192.168.2.0/24 network information is sent from spoke2 to spoke1.
All routing information contained in the vrf where GRE interface sits can be used. A design recommendation when
setting up NHRP network would be to isolate GRE inner network in a specific VRF.
Note: Securing DMVPN connections with IPsec requires a Turbo IPsec Application License.
Securing a DMVPN connection requires to configure an IKE VPN. More information on how to configure IKE is
given in IKE user guide.
A VPN is defined in the IKE context, that requires to encrypt GRE traffic in IPsec transport mode, and specifies
the necessary IKE and IPsec settings.
The local and remote addresses of the VPN are left unspecified, they will be dynamically provided by the NHRP
layer.
Spokes
spoke1
Protocol Address
192.168.1.0/24 10.255.255.1
NBMA Address GR
11.11.11.11 E 11.
11.
11.
11
<->
GRE 11.11.11.11 <-> 22.22.22.22 44.
44.
44.
44 Hub
spoke2 NBMA network hub
Protocol Address GRE 22.22.22.22 <-> 44.44.44.44 Protocol Address
192.168.2.0/24 10.255.255.2 10.255.255.4 192.168.4.0/24
NBMA Address NBMA Address
44
22.22.22.22
4. 44. 44.44.44.44
4 4.4
<->
.33
33.33
E 33.
GR
spoke3
Protocol Address
192.168.3.0/24 10.255.255.3
NBMA Address
33.33.33.33
We will now configure all devices of the DMVPN network to encrypt GRE encapsulated traffic with IPsec.
The procedure consists in configuring an IKE VPN with a security-policy for GRE traffic, then to request that
the NHRP connection uses this security-policy to protect the GRE tunnels (NHRP and data traffic).
The below configuration defines a VPN with a security-policy named dmvpn-gre. It has the IKE identity
spoke1. Each device must have a distinct identity. For example, hub identity would be hub.
Each instance that wants to secure its connection has to set up similar IKE settings. Basically, only the VPN
local-id will change.
spoke1
The same configuration can be applied to other spokes and hub. However, ensure that each device has its own
local-id.
spoke2
[..]
spoke2 running# vrf main
spoke2 running vrf main# ike
spoke2 running ike# vpn dmvpn
spoke2 running vpn dmvpn# local-id spoke2
spoke2 running vpn dmvpn# commit
spoke3
[..]
spoke3 running# vrf main
spoke3 running vrf main# ike
spoke3 running ike# vpn dmvpn
spoke3 running vpn dmvpn# local-id spoke3
spoke3 running vpn dmvpn# commit
hub
[..]
hub running# vrf main
hub running vrf main# ike
hub running ike# vpn dmvpn
hub running vpn dmvpn# local-id hub
hub running vpn dmvpn# commit
Then, the NHRP configuration specifies that the NHRP connection must be protected by an IPsec
security-policy named dmvpn-gre. The name of the ipsec-profile must match the name of the
security-policy.
spoke1
spoke2
spoke3
hub
IPsec establishment
Thanks to this configuration, prior to sending NHRP packets, the NHRP layer on the spokes will trigger an IKE
negotiation between the NBMA addresses of the spoke and the hub, and request the GRE traffic between these
addresses to be encrypted in IPsec transport mode.
Only then the NHRP packets may be exchanged. Both NHRP and data traffic sent through the GRE tunnels will be
encrypted by IPsec.
The command below displays the established IKE SA (Security Association) and their installed child SAs.
spoke1
We can now verify that the NHRP connections are protected by IPsec. As can be seen, the SAs column stands for
the number of child SA used. Identity is the IKE id of the peer.
hub
spoke1
The same processing occurs between spokes before establishing shortcuts. If the hub and spokes are set up to allow
direct spoke-to-spoke communication, a spoke that receives a traffic indication from the hub will trigger an IKE
negotiation with the other spoke, in order to encrypt the GRE traffic between the NBMA addresses of the spokes.
Only then the spoke-to-spoke NHRP exchanges may start. The spoke-to-spoke data traffic will also be protected by
IPsec.
spoke1
OSPF
OSPF v2 Overview
OSPF is the most known routing protocol among the family of so called Link State routing protocols. The OSPF
algorithm is based on the Dijkstra algorithm.
OSPF was developed by the IETF in 1988. It is described in RFC 2328 (https://tools.ietf.org/html/rfc2328.html).
OSPF v2 was designed as an IGP which addresses issues like scalability and convergence.
To understand OSPF advantages, it is common to compare it to the RIP routing protocol (which is a distance vector
routing protocol). Compared to RIP, OSPF has the following advantages:
• OSPF is scalable, there is no hop count limitation, while RIP is limited to 15,
• As a link state protocol, OSPF converges very rapidly in comparison to RIP (which is a Distance Vector
protocol),
• OSPF introduces the notion of PATH cost, while RIP only considers the cost in term of hop count,
• OSPF networks can be large and complex. This is possible thanks to the concept of OSPF areas. RIP doesn’t
offer this facility.
• OSPF terminology
• OSPF operation
• OSPF packets
• RFC
OSPF terminology
It is important to understand the OSPF terminology. In this paragraph we will give the most important concepts.
Link An interface or router,
Link state The status of the link,
Link state database [LSD (Link State Database)] It gathers all LSA (Link State Advertisement) entries. This
database is common for a defined area.
Cost The cost of the link, which mainly depends on the speed of interfaces. Cost is associated to interfaces, or
paths.
Area Collection of networks or routers that have the same area identifier. 0 value is reserved for backbone opera-
tions.
Note: Within an area, each router has the same link-state information.
Backbone area In a multi-area environnement, it is the transit area to which all other areas are connected (area 0)
Stub area Routers in this area accept routing information only from OSPF routers
Internal router Router having all its interfaces in a single area.
Backbone router Router having at least one interface in the backbone area.
BDR (Backup Designated Router) Designated router backup (Backup)
DR (Designated Router) Designated router (DR Other) Router designated by the others to represent a network.
The election takes place generally by taking the lowest OSPF router-id. The election can be modified by
configuring the priority of OSPF.
ASBR Autonomous system border router is defined by some routing information that is external to the OSPF
domain.
OSPF operation
The OSPF operation for a defined area is based on the Dijkstra algorithm. The detailed description of this mechanism
in a single area or in multiple areas is out of the scope of this document.
OSPF runs directly over IP and uses protocol number 89.
OSPF packets
OSPF exchanges information through various kinds of messages. First of all, OSPF sends type 1 hello messages
to 224.0.0.5 broadcast IP address. The hello message contains information about DR and BDR. Hello message
has specific fields that designates the master router and the designated backup router. Those fields are filled in by
exchanging those hello messages. Note that the 224.0.0.5 broadcast address it not the only one to be used. Specific
broadcast information to DR and BDR is using 224.0.0.6.
OSPF is a connection oriented protocol. once hello messages have been exchanged, OSPF exchanges unicast packets.
Various message types can then be exchanged:
• type 2 database description. It describes the link-state database of OSPF devices. This information is sent by
OSPF routing device itself.
• type 3 link state requests (LSA. It is a request from one OSPF device that needs a specific link-state database
information of a remote peer.
• type 4 link state update. It is the information about link state advertisements. The LSA provides information
to reach the ASBR.
• type 5 link state ack. This message acknowledges thanks to a sequence number the previous reception of a
link state update.
There are subtypes of link state updates. As remind, OSPF is used to share link state database, based on the local
and remote devices interfaces ( including IP, neighbors ..). On most cases, following link state updates can be found:
• type 1 router link entry
RFC
RFC 1587 (https://tools.ietf.org/html/rfc1587.html): The OSPF NSSA (Not So Stubby Area) option
RFC 2328 (https://tools.ietf.org/html/rfc2328.html): OSPF version 2
RFC 5709 (https://tools.ietf.org/html/rfc5709.html): OSPF version 2 HMAC-SHA Cryptographic Authentica-
tion
See also:
The command reference for details.
Configuring OSPF
1. Enable OSPF:
vrf main
routing ospf
router-id 10.125.0.1
network 10.125.0.0/30 area 0
..
..
Above example shows an OSPF instance configured on main VRF. The configuration of the router-id is not manda-
tory, since an election process takes place inside OSPF: the router-id is first based on the IP given by manual
configuration, followed by the highest IP available on loopback interface, then followed by the highest IP available
on non loopback interface.
Network command permits enabling OSPF on the network interface whose address and network mask is included
into this prefix, and will announce a link connected to a stub or transit network defined by the interface address
and prefix. As the 10.100.0.0/24 network belongs to eth1 interface, then OSPF will establish adjacencies over that
interface. The network entry passed as parameter will be passed in the Type 3 LSA.
The area identifier is a 32 bit id by which an area is identified. Note that area value is 0, usually reserved for backbone
operations. Having multiple areas in a complex IGP topology permits simplifying the route calculation of OSPF.
Only ABR routers will know both areas defined.
It is possible to use an alternative OSPF configuration by defining networks based on interface and area configu-
rations. Below configuration relies on interface eth0_0 where the 10.125.0.0/30 network is configured. The
below configuration assumes that there is only one IPv4 address under eth0_0 so that both configurations are the
same.
vrf main
routing
ospf
router-id 10.125.0.1
..
interface eth0_0
ip ospf area 0
..
..
interface physical eth0_0
ipv4 address 10.125.0.1/30
Using above configuration can simplify network deployments, since the address configuration is tightly linked with
the IP provisioning done on the interfaces.
You can also disable OSPF, without having to remove the configuration, by using following command:
vrf main
routing ospf
enabled false
vrf main
routing ospf
del network 10.125.0.0/24
..
..
del routing ospf
..
• Display the OSPF v2 Link-State databases and information about LSAs (Link State Advertisements)
AREA 0
10.1.1.0/28
rt1
vrf main
routing ospf
network 10.1.1.0/28 area 0
..
..
interface
physical eth1_0
ipv4 address 192.168.1.0/24
..
physical eth0_0
ipv4 address 10.1.1.1/28
..
..
rt2
vrf main
routing ospf
network 10.1.2.0/28 area 0
..
..
interface
physical eth1_0
ipv4 address 192.168.2.0/24
..
physical eth0_0
ipv4 address 10.1.1.2/28
..
..
rt3
vrf main
routing ospf
network 10.1.3.0/28 area 0
..
..
interface
physical eth1_0
ipv4 address 192.168.3.0/24
..
physical eth0_0
ipv4 address 10.1.1.3/28
..
..
Note: The state must be Full. In this state, routers are fully adjacent with each other. All the router and network
LSAs (Link State Advertisements) are exchanged and the routers’ databases are fully synchronized.
When you get used with the semantic of the OSPF v2 database, it can be displayed with the following command.
The details about these entries are out of the scope of this document.
Following example illustrates how OSPF can be used to redistribute routes to BGP. The above drawing is reused,
with some changes on rt1 and rt2.
rt1
vrf main
routing bgp
router-id 10.1.1.1
address-family
ipv4-unicast
redistribute ospf
..
..
as 55
neighbor 192.168.1.10
remote-as 55
..
..
..
(continues on next page)
rt2
vrf main
routing ospf
network 10.1.2.0/28 area 0
network 192.168.2.0/28 area 0
..
..
interface
physical eth1_0
ipv4 address 192.168.2.0/24
..
physical eth0_0
ipv4 address 10.1.1.2/28
..
..
The BGP routing table of rt1 is updated with the information from rt2.
There is a wide variety of per-interface OSPF configuration items. Using same parameters between 2 OSPF in-
stances is mandatory, and it is often useful to rely on that. Below example shows it is possible to change the network
type of an interface. The OSPF network of interface eth0_0 is defined as a non broadcast type. Adding to that
configuration, the retransmit interval timer has been changed.
vrf main
routing ospf
router-id 10.125.0.1
..
..
routing interface eth1_0
ip ospf network non-broadcast
ip ospf area 0
ip ospf retransmit-interval 6
..
..
The need for using multiple areas is dictated by scalability issues. A single area OSPF network with many routers
implies frequent SPF (Shortest Path First) calculations, large routing tables, large link-state tables, and so on. . .
The design of the OSPF protocol is hierarchical, that is why OSPF scales well. OSPF v2 achieves this through the
use of many areas.
In an OSPF v2 multiple area environnement the route to a specified destination is calculated as follows:
• If the destination is in the same area, the normal SPF calculation is performed
• If the destination is a network in another area, the route to the destination will be the route to the best ABR.
Thus, packets addressed to the network will be received by an ABR, which will route them through the
backbone area up to an ABR of the remote area. Finally, the remote ABR will forward the packets within the
remote area up to the destination.
Configuration procedure
Below drawing illustrates how to configure a backbone network with 2 devices. At each side of the 2 devices, other
area are defined. As you can see, all areas have one direct link connection to area 0.
RT4
192.168.1.2/24
eth1_0 eth0_0 eth1_0
10.1.1.2/30 10.1.1.5/30
RT1 RT2 RT3 192.168.1.1/24
10.1.1.6/30 eth0_0
10.1.1.1/30
eth1_0 eth0_0
AREA 2
AREA 1 AREA 0
(backbone area)
rt1
vrf main
routing ospf
network 10.1.1.0/30 area 1
network 172.16.1.0/24 area 1
..
..
interface
physical eth0_0
ipv4 address 172.16.1.1/24
..
physical eth1_0
ipv4 address 10.1.1.1/30
..
..
vrf main
routing ospf
network 10.1.1.0/30 area 1
network 172.16.1.4/30 area 0
..
..
interface
physical eth0_0
ipv4 address 10.1.1.5/30
..
physical eth1_0
ipv4 address 10.1.1.2/30
..
..
vrf main
routing ospf
network 10.1.1.4/30 area 0
network 192.168.1.0/24 area 2
..
..
interface
physical eth0_0
ipv4 address 10.1.1.6/30
..
physical eth1_0
ipv4 address 192.168.1.1/24
..
..
rt4
vrf main
routing ospf
network 192.168.1.0/24 area 2
..
..
interface
(continues on next page)
In this type of configuration, the most important thing to check is the OSPF v2 database.
Area 1 ABR
rt1
Route summarization
Summarization is the aggregation of multiple routes into one advertisement. The functionality of route summariza-
tion has the obvious advantage of reducing routing tables, and positively affects the amount of bandwidth and CPU
consumed, but proper summarization operation requires a contiguous network address space.
There are two types of summarization:
Inter-area route summarization Done on ABR routers.
External route summarization Done on ASBR routers, this type of summarization is specific to external routes
redistributed from BGP, static, or other external routing information.
Above figure 6 example (Figure 6 - OSPF v2 router configuration in multi-area environment) illustrates an inter-area
configuration example. Assuming that prefix 10.2.1.0/24 has been delegated to area 1, then the area 1 administrator
may want to advertise a summarized route to all sub-networks of this prefix.
In the previous example, the ABR router rt2 is now configured to advertise the aggregated prefix 10.2.1.0/24, and
rt1 is configured to announce network 10.2.1.0/28.
Added configuration lines are written below:
rt1
vrf main
routing ospf
network 10.1.1.0/30 area 1
network 172.16.1.0/24 area 1
network 10.2.1.0/30 area 1
..
..
interface
physical eth0_0
ipv4 address 172.16.1.1/24
..
physical eth1_0
ipv4 address 10.1.1.1/30
ipv4 address 10.2.1.1/28
..
..
rt2
vrf main
routing ospf
network 10.1.1.0/30 area 1
network 172.16.1.4/30 area 0
area 1 range 10.2.1.0/24
..
..
interface
(continues on next page)
rt1
On rt1, which is in area 1, the new route to the 10.2.1.0/28 prefix has appeared in the OSPF RIB.
rt2
On rt2, which is the ABR of area 1, the new route to the 10.2.1.0/28 prefix has appeared in the OSPF RIB. This
route will not be advertised beyond area 1. The summary route will instead be advertised. To avoid routing loops
(since the 10.2.1.0/24 address space has not be entirely assigned to networks), a reject route will be injected in the
ABR forwarding table (hence a discard entry appears in the OSPF RIB).
rt3
The rt3 router, does not belong to area 1. Its OSPF RIB only contains a route to the summary route 10.2.1.0/24.
When configuring OSPF in multi-area environnement, one area must be defined as a backbone area, this is the area
0. All communications between two areas go through the backbone area, what means that all other areas must be
directly connected to the backbone area.
In some situations, a new area is added after the OSPF network has been designed, and it is not possible to have
direct connection between the backbone area and the newly added area. The concept of virtual link enables to create
this direct connection.
Virtual links cannot be configured over stub area.
The virtual link has two requirements:
• It must be established between two routers in the same area
• At least one of the two routers must have a connection to the backbone area.
A multi-area environment will be configured, and two routers will form the virtual link. Those two routers must be
ABRs (Area Border Routers), with one router connected to the backbone area.
RT11
172.16.1.2
AREA 3
RT4
172.16.1.1
192.168.1.2/24
eth1_0 eth0_0 eth1_0
10.1.1.2/30 10.1.1.5/30
RT1 RT2 RT3 192.168.1.1/24
10.1.1.6/30 eth0_0
10.1.1.1/30
eth1_0 eth0_0
AREA 2
AREA 1 AREA 0
(backbone area)
rt11
vrf main
routing ospf
network 172.16.1.0/24 area 3
..
..
interface
physical eth0_0
ipv4 address 172.16.1.2/24
..
..
rt1
vrf main
routing ospf
area 1 virtual-link 10.1.1.5
network 172.16.1.0/24 area 3
network 10.1.1.0/24 area 1
..
..
interface
physical eth0_0
ipv4 address 172.16.1.1/24
..
physical eth1_0
ipv4 address 10.1.1.1/30
..
..
rt2
vrf main
routing ospf
network 10.1.1.0/30 area 1
network 10.1.1.4/30 area 0
area 1 virtual-link 172.16.1.1
..
..
interface
physical eth0_0
(continues on next page)
1. Check on both routers (rt1 and rt2) that the virtual link interface is up:
2. Check the OSPF LSA advertisement. That is to say that rt1, which is in area 3, should receive summmary
link states from other areas.
In some ASes, the majority of the link-state database may consist of AS-external-LSAs. An OSPF AS-external-LSA
is usually flooded throughout the entire AS. However, OSPF allows certain areas to be configured as “stub areas”.
AS-external-LSAs are not flooded into/throughout stub areas; routing to AS external destinations in these areas is
based on a default route. This reduces the link-state database size, and therefore the memory requirements, for a
stub area’s internal routers.
To configure a stub area, enter for example:
routing ospf
area 1 stub
This feature prevents the ospf ABR from injecting inter-area summary into the considered area.
A Stub Area restricts the LSA types being injected into a stub area from other areas to Type 3 Summary LSA’s.
Type 4’s and 5’s are represented by a default route to the Area Border Router. A totally stubby area takes this further
by restricting Type 3’s as well, so all traffic being injected into a totally stubby area are represented by a default
route.
To sum up, this means that the AS-external-LSAs (Type-5 LSA) and ASBR-Summary-LSA (Type-4 LSA) and
Network summary LSA (Type-3 LSA) are not flooded into a totally stub areas.
Example
vrf main
routing ospf
area 1 stub summary false
Turbo Router software supports the OSPF NSSA. This concept was first described in RFC 1587
(https://tools.ietf.org/html/rfc1587.html). An OSPF area is said to be NSSA if it can send some external links
to other areas. These routes are said to be LSA type 7, which carry essentially type 5 LSA. Then, at the ASBR, it is
converted in LSA type 5, which can flood the information to the rest of other areas networks.
Example
vrf main
routing ospf
area 1 nssa
RT11
172.16.1.2
AREA 3
RT4
172.16.1.1
192.168.1.2/24
eth1_0 eth0_0 eth1_0
10.1.1.2/30 10.1.1.5/30
RT1 RT2 RT3 192.168.1.1/24
10.1.1.6/30 eth0_0
10.1.1.1/30
eth1_0 eth0_0
AREA 2
AREA 1 AREA 0
(backbone area)
In this example, the routers will be configured so that rt1 and rt2 will have a virtual-link. Route summarization will
be configured on rt1. rt2 and rt3 will be ABRs. Also, OSPF priority on rt2 will be changed. The last device, rt3,
will be configured in area 2. It will be checked how routes announced by rt1 will be propagated.
rt11
vrf main
routing ospf
network 172.16.0.0/22 area 3
..
..
interface
physical eth0_0
ipv4 address 172.16.1.2/24
..
physical eth1_0
ipv4 address 172.16.0.2/24
..
..
rt1
vrf main
routing ospf
area 1 virtual-link 10.1.1.5
area 3 range 172.16.0.0/22
network 172.16.0.0/22 area 3
network 10.1.1.0/24 area 1
..
..
interface
physical eth0_0
ipv4 address 172.16.1.1/24
..
physical eth1_0
ipv4 address 10.1.1.1/30
..
..
rt2
vrf main
routing ospf
network 10.1.1.0/30 area 1
network 10.1.1.4/30 area 0
area 1 virtual-link 172.16.1.1
..
..
routing interface eth1_0
ip ospf priority 3
..
..
interface
physical eth0_0
ipv4 address 10.1.1.5/30
..
physical eth1_0
ipv4 address 10.1.1.2/30
..
..
rt3
vrf main
routing ospf
network 10.1.1.4/30 area 0
network 192.168.1.0/24 area 2
..
interface
physical eth0_0
ipv4 address 10.1.1.6/30
..
physical eth1_0
ipv4 address 192.168.1.1/24
..
..
rt4
vrf main
routing ospf
network 192.168.1.0/24 area 2
..
..
interface
physical eth1_0
ipv4 address 192.168.1.2/24
..
..
rt1
rt2
Neighbor ID Pri State Dead Time Address Interface RXmtL RqstL DBsmL
rt3
rt2
On above show command, a summary LSA exists for networks 172.16.0.0/24 and 172.16.0.1/24 in area 1 (although
these networks are in area 3), thanks to the virtual link between rt1 and rt2. The LSAs for these two networks are
aggregated in area 0 as a summary link state, thanks to route summarization on router rt1, hence only a route to
network 172.16.0.0/22 is advertised on the backbone area.
rt3
The aggregated route to network 172.16.0.0/22 is received by rt3 thanks to the virtual link and route summarization.
rt1
The routes to area 3 networks (172.16.0.0/24 and 172.16.1.0/24) appear in the RIB, as well as a reject route to the
aggregated network (172.16.0.0/22), to avoid routing loops. Only the aggregated route will be advertised to other
areas. Routes to networks in remote areas have also been received by rt1.
Routes are now installed on all routers, so that packets can flow from rt11 to rt4.
OSPF v2 security
Security problems could lead to DoS (Denial of Service) if falsified routing information are exchanged between
routers.
Turbo Router OSPF v2 implementation supports two kinds of authentication, plain text authentication and more
secure MD5 authentication.
Note: If this option is adopted, then it must be configured in the whole area. For plain text authentication, passwords
must be the same between neighbors.
1. For each interface, type the following command at the interface level:
vrf main
routing interface eth0_0
ip ospf authentication simple
ip ospf authentication-key secret
..
..
The secret password is being used in the OSPF header of OSPF messages, and is in clear form.
1. Enable ospf authentication in the corresponding area, in the router ospf context.
vrf main
routing ospf
area 0 authentication
..
..
vrf main
routing interface eth0_0
del ip ospf authentication-key
del ip ospf authentication
..
..
routing ospf
del area 0 authentication
..
..
1. For each interface, type the following command at the interface level:
vrf main
routing interface eth0_0
ip ospf authentication message-digest
ip ospf message-digest-key 1 md5 d215
(continues on next page)
A key identifier is carried in OSPF messages, along with authentication crypted data, and area identifier ( by default
backbone).
1. Enable context authentication in the corresponding area, in the router ospf context.
vrf main
routing ospf
area 0 authentication message-digest true
vrf main
routing interface eth0_0
del ip ospf authentication
del ip ospf message-digest-key 1
..
..
routing ospf
del area 0 authentication
..
..
Filtering OSPF
Like for BGP protocol, it is possible to apply filtering thanks to route map. Below example illustrates what can
be done by using Prefix List. OSPF will be configured to redistribute BGP entries, however some filtering will be
applied.
1. Specify the prefix-list and route-map:
vrf main
routing
ipv4-prefix-list plist
seq 1 address 10.100.0.0/24 policy permit
seq 2 address 10.200.0.0/24 policy deny
seq 3 address 10.150.0.0/24 policy permit
..
route-map rmap seq 1 plicy permit
route-map rmap seq 1 match ip address prefix-list plist
..
1. Configuration of a BGP instance that peers with remote located outside of OSPF area.
vrf main
routing bgp
as 55
router-id 1.1.1.1
neighbor 10.110.0.10 remote-as 55
..
..
vrf main
routing ospf
redistribute bgp route-map rmap
Subsequently, the rt1 device has imported filtered BGP route entries.
BFD In OSPF
With BFD usage in OSPF, the failover mechanism is greatly improved by detecting the loss of remote OSPF neigh-
bors. Instead of relying on standard hello mechanisms, BFD permits faster convergence. To get more information
on BFD, please see BFD.
A BFD peer session context is created, along with discovering OSPF neighbors. Due to the nature of OSPF, all
created BFD peer contexts are single-hop.
vrf customer1
routing ospf
router-id 10.125.0.1
.. ..
routing interface eth1_0
ip ospf area 0.0.0.1
ip ospf track bfd
Then you can continue the configuration as usual. For timer settings, the default emission and reception settings are
set to 300000 microseconds, which may not be what is wished. In that case, it is possible to override default timers,
by configuring general timer settings. More information is given in Configuring general BFD settings.
LS age: 70
Options: 0x2 : *|-|-|-|-|-|E|-
LS Flags: 0x3
Flags: 0x2 : ASBR
LS Type: router-LSA
Link State ID: 10.125.0.2
Advertising Router: 10.125.0.2
LS Seq Number: 80000004
Checksum: 0xb65d
Length: 36
Number of Links: 1
LS age: 70
Options: 0x2 : *|-|-|-|-|-|E|-
LS Flags: 0x6
Flags: 0x2 : ASBR
LS Type: router-LSA
Link State ID: 10.125.0.2
Advertising Router: 10.125.0.2
LS Seq Number: 80000003
Checksum: 0x9a79
Length: 36
Number of Links: 1
RIP
RIP Overview
RIP came up at the end of the 80’s. It is a routing protocol that computes the shortest path between networks. It is
based on the Bellman-Ford algorithm that distributes the computation of the shortest path among the nodes (routers).
The metric of the path is related to the number of hops. Consequently it is one of the most famous distance vector
protocol that is used on the IP networks and on the Internet.
The first release RIP v1, that is described by the IETF RFC 1058 (https://tools.ietf.org/html/rfc1058.html), was
designed for the IPv4 class oriented Internet. RIP v1 uses broadcast UDP on the well-known port 520.
Nowadays, the second release of RIP (RIP v2), which is described by the IETF RFC 2453
(https://tools.ietf.org/html/rfc2453.html), fits the IPv4 CIDR (Classless InterDomain Routing) that uses VLSMs
(Variable Length Subnet Masks). RIP v2 uses multicast UDP on the well-known group 224.0.0.9 and port 520.
You can use it as in IGP within a small simple network.
The maximum network size that RIP can handle is 16 hops.
RFC
RIP Configuration
Starting RIP can be done by using a very simple configuration. Example below illustrates a basic configuration
setup with one network configured. Automatically, RIP will operate over all the interfaces where an IP address
is defined, whose network address is included in the provided network prefix. Network addresses included in this
prefix and defined on these interfaces will be advertised.
vrf main
routing rip
network 10.125.0.0/30
..
..
commit
As mentioned in above config, RIP is activated, with providing network prefix. It is also possible to provide interface
name. If an interface name is provided, RIP will then be activated on this interface and all IPv4 network prefixes
defined on this interface will be advertised.
vrf main
routing rip
interface eth1_0
vrf main
del routing rip
commit
Alternatively, it is also possible to just disable RIP without having to remove the whole configuration.
vrf main
routing rip enabled false
commit
Currently, only one RIP instance is supported for the whole Turbo Router. However, it is possible to store the
configuration and set it to false. Below example illustrates that only rip instance from VRF vrf1 is available on the
Turbo Router.
vrf main
routing rip enabled false
routing rip network 1.2.3.0/24
commit
..
..
vrf vrf1
routing rip network 5.5.5.0/24
commit
..
..
show rip
The display of show rip is composed of 7 columns, and describes the RIB of the RIP routing protocol:
Code describes the RIB source, the differents codes are explained in the beginning of the output of show rip
command
Network describes the learnt prefix (Destination prefix) with its subnet mask
Next Hop indicates the next hop to this destination (0.0.0.0 means itself).
Metric indicates the hop count to the destination prefix
See also:
See the corresponding RIP options described in this document.
Enabling ECMP
vrf main
routing rip
allow-ecmp true
..
..
By default, RIP is configured to handle both incoming v1 and v2 requests. However, it is possible to globally
configure the default RIP version. Below configuration example illustrates how to disable v1.
vrf main
routing rip
version
receive 2
send 2
..
..
..
It is also possible to disable some rip versioning handling per interface. Below example illustrates how to handle
both reception and emission with RIP v1 only:
vrf main
routing interface eth1_0
ip rip version send 1
ip rip version receive 1
..
..
..
Note: These commands can be useful to interconnect some old RIP v1 networks to a new RIP v2 network, or
during a migration period.
Passive interface
A passive RIP interface can receive and process the RIP packets, however it does not send any RIP information
(except to the neighbor listed by the neighbor command).
• Make an interface passive:
vrf main
routing rip
passive-interface eth1_0
network 10.1.1.0/28
..
..
In this example, routing updates will not be advertised out the interface eth1_0.
Unicast announces
Although RIP v1 is a broadcast protocol and RIP v2 is a multicast protocol, the RIP routing updates can be unicasted
too. Consequently, the IPv4 address of the unicast neighbors can be defined in order for RIP to send the routing
updates to a set of specific RIP nodes.
To add the address of the neighbors, use the following command :
vrf main
routing rip
neighbor 10.125.0.2
..
..
Note:
• This command is not required to enable RIP on point-to-point interfaces or tunnels, the network command is
enough to activate RIP on these interfaces.
• This command does NOT prevent RIP multicast packet to be sent on an interface. To suppress any RIP
multicast packets, this command must be used jointly with the passive-interface command
Modifying timers
The routing protocols are based on many timers that control the stability of your network and the time convergence
of the algorithms. RIP is based on three timers:
The update-interval default value is 30 seconds. This is the time between each update message emission.
The holddown interval default value is 180 seconds.
The flush interval default value is 120 seconds.
It is possible to change the timers values by using following command:
vrf main
routing rip
timers update-interval 30 holddown-interval 180 flush-interval 120
..
..
Note: Do not change any default value if you are deploying a RIP network over a LAN (Local Area Network).
They should only be changed over some very low bandwidth links (about 32 Kbit/s or less) or over cost expensive
links.
Split horizon
When split-horizon is used, the learnt prefixes are not announced on the interface from which they come from. It
has been designed to decrease traffic load and to avoid routing loops. To decrease the traffic load when the routing
table is advertised, split-horizon is activated by default on each interface.
• Disable split-horizon:
vrf main
routing interface eth0_0
ip rip split-horizon disabled
..
..
..
• Enable split-horizon:
vrf main
routing interface eth0_0
ip rip split-horizon simple
..
..
..
Note:
• Split-horizon is enabled or disabled on a per interface basis, and the corresponding commands are executed
at the interface level.
• Disable split-horizon when many interfaces on a broadcast area do not share the same connected prefix. In
this case, it is enough to disable split-horizon on the routers that have the common connected prefixes because
it will act as a gateway for the different connected prefixes.
To enable RIP and to demonstrate the split-horizon feature, the above figure will be used.
1. Announce the different networks:
The announcing of networks is configured like below on rt1:
vrf main
routing interface eth1_0
ip rip split-horizon simple
..
..
routing rip
network 10.1.1.0/28
interface eth0_0
..
..
Example
By default, with this previous configuration, rt1 does not announce 192.168.2.0/24, neither 192.168.3.0/24
on the eth1_0 interface due to the split-horizon feature. When split-horizon is disabled, they are announced.
The goal of poisoning the reverse path is to increase the convergence of the RIP algorithm to quickly kill the RIP
routing loops. When split-horizon with poisoned reverse path is enabled, the prefixes which are learned via an
interface, are announced back each 30 seconds with a metric of 16 (i.e. infinite).
To increase the time convergence of the RIP algorithm, the originator routes may be poisoned. It means that the
routes will be announced with an infinite metric (16) via the interface that should be used for the shortest path.
However it increases the traffic load. By default Turbo Router does not activate the split-horizon with poisoned
reverse path on each interface.
• Enable split-horizon with poisoned reverse path:
vrf main
routing interface eth0_0
ip rip split-horizon poisoned-reverse
..
..
vrf main
routing interface eth0_0
ip rip split-horizon simple
..
..
This will disable the poisoned-reverse option in the RIP configuration. It will fall back to the default split-horizon
option.
The split horizon with poisoned reverse policy is configured on a per interface basis.
Next-hop option
When sending a RIP message, the router will if necessary add a next-hop option to the routes it advertises. This
option indicates the gateway via which the router can reach the advertised destinations. It enables the routers that
receive the RIP message to create local shortcuts.
If the next-hop option is not set, then the router that originated the RIP packet is used as the next-hop.
It is possible to force the next-hop value by using the default-information originate keyword.
Allow RIP to advertise the default route ` 0.0.0.0/0`:
vrf main
routing rip
default-information-originate true
..
..
vrf main
routing rip
default-information-originate false
..
..
Note:
• When a router is advertising a default route, it is advised that it is itself configured with its own default IPv4
route to avoid that it becomes a blackhole:
vrf main
routing static ipv4-route 0.0.0.0/0 next-hop 10.1.1.2
..
It is also possible to use the command redistribute static under routing rip mode, when a static route is
defined.
It is possible to configure a route-map with a a set clause. More information on route-map is given in route map.
Below example illustrates a RIP configuration, where nexthop is forced to be a hard set value.
vrf main
routing rip
interface eth1_0
route-map eth1_0 out route-map-name rmap_name
..
..
..
routing
route-map rmap_name seq 11
policy permit
set ip next-hop 10.1.0.101
..
..
Example
Example
For example, if rt3 has a static route to the network 172.16.1.0/24 via a gateway - 10.1.1.4 - on the eth1_0 interface,
rt2 and rt1 know that they can directly reach this gateway without sending packets to rt3, so they conclude that there
is a shorter route to network 172.16.1.0/24 via the 10.1.1.4 gateway.
RT4 172.16.1.0/24
10.1.1.4/28
rt1
vrf main
routing rip
network 10.1.1.0/28
network 192.168.1.0/24
..
..
rt2
vrf main
routing rip
network 10.1.1.0/28
network 192.168.2.0/24
..
..
rt3
vrf main
routing rip
network 10.1.1.0/28
network 192.168.3.0/24
..
..
rt1 and rt2 are using the same next-hop to join the network 172.16.1.0/24 without sending the data to rt3 that
originates the route.
Note: When the next-hop is not reachable, the router should use the originator of the RIP packet as the gateway.
Then, if this originator is not reachable too, the RIP entry should be ignored. Another router could announce better
information.
The RIP process can announce a route that has no origin. It means that it has not been introduced into the RIP RIB
by the redistribute command.
• Add a route into the RIP RIB:
vrf main
routing rip
static-route 1.2.2.0/24
..
..
Note: Configuring a static RIP route is very useful for testing purpose.
The RIP signaling process can learn the network prefixes either from another routing protocol such as BGP or OSPF
from the connected network prefixes that have been set on the interfaces, or from the static routes that have been set.
• Redistribute prefixes:
vrf main
routing rip
redistribute connected
redistribute static
redistribute bgp
redistribute ospf
..
..
The redistribution of static routes applies to the default route too. It is a good practice to announce the default route
from a CPE that provides a NAT service for the traffic through the public interface.
Note: The prefixes, which are announced with the redistribute command, are named Connected-redistribute (C(r)).
Redistributed connected routes appear with the sub-code C(r) in the show rip output.
Default route appears with the (d) sub-code, while a connected interface (announced in the router rip context with
the network {A.B.C.D/M|IFNAME} command) appears with the (i) sub-code.
Note: If the same prefix is learnt via different means (redistribution, interface, or default) the route learnt via
redistribution is the less preferred.
When many IGPs and EGPs (External Gateway Protocols) are provisioning a same active route into the IPv4 FIB,
the one from the preferred routing protocols is selected; for example the static routes are preferred to the OSPF v2
routes that are preferred to the RIP routes that are preferred to the eBGP routes.
The default RIP distance is 120. It is however possible to override that behaviour by using the following command:
vrf main
routing rip
administrative-distance default 123
..
..
More information about administrative distance of other routing protocols can be found on following reference
Administrative Distance
Since the routing protocols are not the same (BGP, static, connected), the associated metrics cannot be compared,
and hence cannot be kept within the RIP advertisements. An arbitrary distance, which is assimilated to a hop count,
can be set with the redistribute SOURCE metric N command into the RIP context.
vrf main
routing rip
redistribute static metric 3
redistribute connected metric 2
redistribute bgp metric 9
redistribute ospf metric 4
..
..
Note: Due to the maximum RIP metric (16), these commands decrease the size of your network.
Note: When redistributing a routing protocol into RIP, special care must be taken for the metric control, because
not all routing protocols have the same metric. Remember that RIP uses the hop count as metric.
In this example we will configure 4 routers rt1, rt2, rt3 and rt4 to support the RIP options.
RT4 172.16.1.0/24
10.1.1.20/28
10.1.1.0/28 10.1.1.16/28
Required features
rt1
vrf main
interface
physical eth0_0
ipv4 address 192.168.1.1/24
..
physical eth1_0
ipv4 address 10.1.1.1/28
..
..
routing rip
network 10.1.1.0/28
network 192.168.1.0/24
static-route 192.168.4.0/24
..
..
routing static ipv4-route 192.168.4.0/24 next-hop 192.168.1.25
rt2
vrf main
interface
physical eth0_0
ipv4 address 10.1.1.18/28
..
physical eth1_0
ipv4 address 10.1.1.2/28
..
physical eth2_0
ipv4 address 192.168.2.2/24
..
..
routing
interface eth0_0
ip rip split-horizon poisoned-reverse
..
interface eth1_0
ip rip split-horizon disabled
..
rip
network 10.1.1.0/27
network 192.168.2.0/24
(continues on next page)
rt3
vrf main
interface
physical eth0_0
ipv4 address 192.168.3.3/24
..
physical eth1_0
ipv4 address 10.1.1.19/28
..
..
routing rip
network 10.1.1.16/28
redistribute connected metric 4
rt4
vrf main
interface
physical eth0_0
ipv4 address 172.16.1.4/24
..
physical eth1_0
ipv4 address 10.1.1.20/28
..
..
routing rip
network 10.1.1.16/28
network eth0_0
timers update-interval 30 holddown-interval 180 flush-interval 120
..
..
The 10.1.1.0/28 and 192.168.1.0/24 routes are routes to directly connected interfaces (C(i) flag), their next
hop is consequently rt1 itself and the metric is 1. The 192.168.4.0/24 route is redistributed from a static route (R(s)
flag), its next hop is consequently rt1 itself and the metric is 1.
The 10.1.1.16/28, 172.16.1.0/24, and 192.168.2.0/24 routes were acquired via the RIP protocol (R(n) flag),
their next hop is rt2 and their metrics correspond to the number of hops up to the destination. The 192.168.3.0/24
route’s metric is 6 instead of 2, due to rt3 configuration, which increased the metric by 4.
RIP security
Like in other dynamic systems, the advantage of dynamic routing is that the routes are learnt automatically by
routers, so the configuration tasks are limited for the network administrator, but the counterpart is that there are
risks. Security problems could lead to a DoS. For instance a hacked router could announce falsified routing data
that could be automatically propagated in the whole network. As RIP is an IGP, i.e. an internal protocol, other
security measures could prevent this risk. However, to limit these security problems, security features have been
implemented.
In this context, the advantage of RIP v2 compared to RIP v1 is that the former allows to authenticate routing
information when they are transmitted between routers. Only authenticated data are allowed to be used by routers.
RIP authentication
RIP security is based on authentication with a shared secret that can be transmitted to a broadcast area. RIP v2
supports the two authentication methods: plain-text authentication and MD5 authentication. The authentication is
interface specific (scope). It means that different authentications can be defined according to the RIP interfaces.
For both authentication methods (plain text or MD5), an interface specific shared secret has to be defined. The
authentication keys are shared and must be the same between neighbors.
Note: This feature is supported in RIP v2 only. Plain text authentication is the default setting in every RIP v2
packet. Encrypted authentication is based on the MD5 algorithm. In this mode of authentication, the routing update
carries a 128-bit message that includes the password encrypted by the MD5 algorithm. The transmitted routing
information remains in clear text.
Except to limit error configurations consequences where a clear text password may be enough, MD5 authentication
is obviously advised for security reasons.
Filtering is a complementary feature used to provide a better security to RIP protocol. The concept is based on a
list that contains the addresses and or prefixes allowed to be advertised or learnt amongst routing information.
1. Specify the access-list:
routing
ipv4-access-list INTERNAL permit 192.168.0.0/16
ipv4-access-list INTERNAL deny 192.168.0.0/16
..
vrf main
routing rip
distribute-list eth0_0 out access-list INTERNAL
distribute-list eth2_0 out access-list INTERNAL
High availability
It is sometimes useful for High Availability purpose to have redundancy between two routers. In some cases, this
redundancy MUST not be associated with load balancing, hence in case of router swap, the routing convergence
time must be addressed. This will be done, without any modification to RIP itself, but rather, with configuration
tuning.
The basic idea will be:
• To share a common IP address on the shared link between the two routers (and possibly a common L2 address).
• Elect a router on the link, that will be master and real owner of the IP address, the other being the slaves
• On the Master, run RIP normally
• On Slaves, run RIP in a passive mode on the shared link, so that routing table is already present in the router
• When a router comes to Master state:
– If no L2 adress is shared, send some gratuitous ARP to update ARP caches.
– Change the RIP interface behaviour to active: it will then announce itself .
This can be achieved by using VRRP. In addition to IP address management the protocol will have to re-configure
each RIP daemon on the fly, reproducing the same result as the following commands:
1. On the Slave(s), be in passive mode
vrf main
routing rip
passive-interface eth0_0
vrf main
routing rip
passive-interface eth0_0
OSPFv3
OSPF v3 Overview
OSPF v3 is a redesign of OSPF v2 which adds support for a generic address family. Up to now,
only the IPv6 address family has been defined. The OSPF v3 protocol is first described in RFC 2740
(https://tools.ietf.org/html/rfc2740.html). It inherits most of the OSPF v2 mechanisms (Flooding, DR, LSU (Link
State Update),. . . ) with little changes.
In OSPF v3, router-id has the same format as OSPF v2, new and modified LSAs have been created to handle the
flow of IPv6 addresses and prefixes in an OSPF v3 network. The new LSAs introduced in OSPF v3 are the Link
LSA, and the Intra-Area-Prefix LSA.
To get more information about OSPF v2, please look at the following reference OSPF v2.
OSPF v3 terminology
Most of the acronyms used for OSPF v3 are common with OSPF v2. More information at following link OSPF v2
terminology.
OSPF v3 packets
OSPF v3 operates over IP protocol number 89, like with IPv4. Also, hello messages are carried over ff02:5.
Similarly, ff02:6 is used for messages to DR and BDR
All basic OSPF packet types can be found on OSPF v3 too. It is worth to be noted that LSA of OSPF v2 can be
found on OSPF v3.
There are however some specificities:
• The link state type values are different. Router LSA type id is 0x2001 ( formerly 1 in OSPF v2). Network
LSA value is 0x2002, inter-Area Prefix LSA is 0x2003 (formerly network summary LSA type 3), inter-Area
Router LSA is 0x2004 (formerly ASBR summary LSA type 4), AS-external LSA type id is 0x4005 (formerly
type 5), Group Membership LSA tpye id is 0x2006 (formerly type 6), Type-7 LSA type id is 0x2007 (formerly
NSSA external LSA).
• A new link state type is available : Link LSA type id is 0x0008. This message is dedicated to local link
information only.
• Another link state type is available : The Intra-area Prefix LSA with type id value set to 0x2009. That
message is used to carry intra-area network information previously included in Network LSA used with SPF
calculation. This separation permits adding or removing IP subnets without modifying the SPF tree.
RFC
Configuring OSPF v3
The configuration of OSPF v3 in a single area is similar to the configuration of OSPF v2, with slight changes. The
creation of the routing instance is similar with what has been done for OSPF v2.
Here is a sample OSPF v3 configuration. OSPF v3 is activated on interfaces eth0_0 and eth1_0. The interface
eth1_0 is in passive mode, which means it only emits OSPF packets and does not receive them.
vrf main
routing ospf6
router-id 10.125.0.1
interface eth1_0 area 0.0.0.0
interface eth0_0 area 0.0.0.0
..
..
routing interface eth1_0
ipv6 ospf6 passive true
You can disable OSPF v3 without having to remove the configuration, by using following command:
vrf main
routing ospf6
enabled false
vrf main
del routing ospf6
..
Verifying operation
Area 0.0.0.0
Number of Area scoped LSAs is 2
Interface attached to this area: eth0_0 eth1_0
SPF last executed 22.662241s ago
Configuration example
AREA 0
eth1_0
2001:500:2::3/64
RT1 RT2 RT3
eth1_0
2001:500:2::2/64
eth0_0 eth0_0
2001:500:1::1/64 2001:500:1::2/64
10.1.1.0/28
rt1
vrf main
routing ospf6
router-id 10.1.1.1
interface eth0_0 area 0.0.0.0
interface eth1_0 area 0.0.0.0
..
(continues on next page)
rt2
vrf main
routing ospf6
router-id 10.1.1.2
interface eth0_0 area 0.0.0.0
interface eth1_0 area 0.0.0.0
interface eth2_0 area 0.0.0.0
..
..
interface
physical eth2_0
ipv6 address 3ffe:2::2/64
..
..
physical eth0_0
ipv6 address 2001:500:1::2/64
..
..
physical eth1_0
ipv6 address 2001:500:2::2/64
..
..
rt3
vrf main
routing ospf6
router-id 10.1.1.3
interface eth0_0 area 0.0.0.0
interface eth1_0 area 0.0.0.0
..
..
interface
physical eth0_0
ipv6 address 3ffe:3::3/64
..
..
physical eth1_0
ipv6 address 2001:500:2::3/64
..
..
Note: The state must be at Full, otherwise, this means that the OSPF v3 neighberhood is not correctly formed.
• Display the OSPF v3 Link-State databases and information about LSAs (Link State Advertisements)
Like in IPv4 with OSPF v2, OSPF v3 permits the use of multiple areas, and an OSPF v3 router may be an ABR;
that is to say that it is a router having at least one interface in one area and another interface in a different area.
OSPF v3 implement supports stub area like with OSPF v2. Below example illustrates how to declare area 1 as a
stub area.
vrf main
routing ospf6
area 1 stub
OSPF v3 implement supports totally stub area like with OSPF v2. Below example illustrates how to declare area 1
as a totally stubby area.
vrf main
routing ospf6
area 1 stub summary false
OSPF v3 options
Below is given some illustration that help on how to configure OSPF v3.
OSPF v3 cost
Following example sets the interface output cost. If not set, the value is automatically calculated based on the
bandwidth of the interface. By default, cost is set to 1 for a 100MB link.
vrf main
routing interface eth0_0
ipv6 ospf6 cost 20
As said before, if not explicitly set, the cost is determined by the bandwidth of the interface. It is possible to impact
the cost value by changing the default reference bandwidth used. By default, it is 100MB. Below example illustrates
a reference of 1GB.
vrf main
routing ospf6
auto-cost 1000
OSPF v3 priority
The interface’s router Priority for election of designated router can be modified, by using following command on
routing interface mode.
vrf main
routing interface eth0_0
ipv6 ospf6 priority 10
Default value is 1.
Below example illustrates how to set interval for hello messages, per interface.
vrf main
routing interface eth0_0
ipv6 ospf6 hello-interval 20
OSPF v3 transmit-delay
vrf main
routing interface eth0_0
ipv6 ospf6 transmit-delay 3
Default value is 1.
Passive interface
This feature should be used when it is required to prevent some router’s interfaces from forming OSPF adjacencies.
It may be for instance to include a subnet into the OSPF routing process (and LSD), without actually running OSPF
on the interface of the router connected to that subnet. This is useful to announce stub networks instead of external
LSA. This is particularly adapted for interfaces that are used as BGP peering links or for customer connectivity.
vrf main
routing interface eth0_0
ipv6 ospf6 passive true
..
..
(continues on next page)
ECMP
There might be some situation in which, for a common destination, OSPF has different paths, of equal cost to reach
that destination. In such situation, network traffic may be distributed equally among all the equal cost paths. This
situation relies on the ECMP capabilities.
BFD In OSPF v3
With BFD usage in OSPF v3, the failover mechanism is greatly improved by detecting the loss of remote OSPF
v3 neighbors. Instead of relying on standard hello mechanisms, BFD permits faster convergence. To get more
information on BFD, please see BFD.
A BFD peer session context is created, along with discovering OSPF v3 neighbors. Due to the nature of OSPF v3,
all created BFD peer contexts are single-hop, and are based on IPv6.
vrf customer1
routing ospf6
router-id 10.125.0.1
interface eth1_0 area 0.0.0.1
.. ..
routing interface eth1_0
ipv6 ospf6 track bfd
Then you can continue the configuration as usual. For timer settings, the default emission and reception settings are
set to 300000 microseconds, which may not be what is wished. In that case, it is possible to override default timers,
by configuring general timer settings. More information is given in Configuring general BFD settings.
BFD Peer:
peer fe80::347c:8fff:fe10:e2b4 local-address fe80::bcda:24ff:fef7:38d3 interface␣
˓→eth1_0
ID: 322201613
Remote ID: 2746639856
Status: up
Uptime: 9 minute(s), 49 second(s)
Diagnostics: ok
Remote diagnostics: ok
Local timers:
Receive interval: 600ms
Transmission interval: 600ms
Echo transmission interval: 50ms
Remote timers:
Receive interval: 300ms
Transmission interval: 300ms
Echo transmission interval: 50ms
RIPNG
Overview
RIPng is the equivalent of RIP, but for IPv6 networks. It uses the Bellman-Ford algorithm, ans as RIP, the network
diameter is limited to 15 hops. It is described by the IETF RFC 2080 (https://tools.ietf.org/html/rfc2080.html), it is
a RIP v2 redesign that supports the 128 bit IPv6 addresses. It uses multicast UDP on the well-known group ff02::9
and port 521. Due to the IPsec requirement of IPv6 stacks, RIPng does not have the security features that RIP v2
provides: it has to be handled by the IPv6 security layer (IPsec).
RFC
RIPng Configuration
Starting RIPng can be done by using a very simple configuration. Example below illustrates a basic configuration
setup with one network configured. Automatically, RIPng will operate over all the interfaces where an IP address
is defined, whose network address is included in the provided network prefix. Network addresses included in this
prefix and defined on these interfaces will be advertised.
It is worth to be noted that RIPng does not announce the link-local prefixes (fe80::).
vrf main
routing ripng
network 2001::/16
..
..
commit
As mentioned in above config, RIPng is activated, with providing network prefix. It is also possible to provide
interface name. If an interface name is provided, RIPng will then be activated on this interface and all IPv6 network
prefixes defined on this interface will be advertised.
vrf main
routing ripng
interface eth1_0
vrf main
del routing ripng
commit
Alternatively, it is also possible to just disable RIPng without having to remove the whole configuration.
vrf main
routing ripng enabled false
commit
show ripng
Like RIP, RIPng has many options, besides with RIPng there is a possibility to aggregate the addresses and to
declare one network, these options are described in detail in the following sections.
Split horizon
Like RIP, RIPng does not announce the learnt prefixes on the interfaces from which they were learnt. This is the
default behavior of Turbo Router.
To disable the split horizon feature on a given interface type the following command at the interface level of the
routing context.
vrf main
routing interface eth0_0
ipv6 ripng split-horizon disabled
..
..
..
To come back to default behavior and enable split-horizon, use the following command:
vrf main
routing interface eth0_0
ipv6 ripng split-horizon simple
..
..
..
The goal of poisoning the reverse path is to increase the convergence of the RIPng algorithm to quickly kill the
RIPng routing loops. When split-horizon with poisoned reverse path is enabled, the prefixes which are learnt via
an interface are announced back each 30 seconds with a metric of 16 (i.e. infinite).
This option is configured at the interface level at the routing context by typing the following command at the interface
level of the routing context.
vrf main
routing interface eth0_0
ipv6 ripng split-horizon poisoned-reverse
..
..
..
• Disable poisoned-reverse:
vrf main
routing interface eth0_0
ipv6 ripng split-horizon simple
..
..
..
This will disable the poisoned-reverse option in the RIPng configuration and remain in the split-horizon RIPng
policy.
The default-information originate command can be used to allow RIPng to advertise the default route (::/0).
vrf main
routing ripng
default-information-originate true
..
..
..
When enabling this option, default route will be displayed in the list of entries that RIPng displays:
Note: When a router is advertising a default route, it is advised that it is itself configured with its own default IPv6
route to avoid it becomes a blackhole:
vrf main
routing static
ipv6-route 0::0/0 next-hop eth1_0
The RIPng process can announce a route that has no origin. It means that it has not been introduced into the RIPng
RIB by the redistribute command.
• Add a route to the RIPng RIB (in the RIPng context):
vrf main
routing ripng
static-route 2003::/64
..
..
This static route appears in the RIB with the R(s) tag.
It is announced as RIPng route but with the subcode (s) which means that the prefix was learned by a static route.
With this command, a black-hole could be announced.
Since the routing protocols are not the same (BGP, static, connected), the associated metrics cannot be compared.
An administrative distance, that is composed of hop count, can be set with the following command into the RIPng
context.
vrf main
routing ripng
redistribute connected metric 3
redistribute static metric 4
redistribute bgp metric 8
..
..
Note: Due to the maximum RIPng metric of 16, these commands decrease the size of your network.
Modify timers
The routing protocols are based on many timers that control the stability of your network and the time convergence
of the algorithms. RIPng is based on three timers:
a. The routing table update in seconds: default 30 s,
b. The routing information timeout in seconds: default 180 s.,
c. The garbage collection in seconds: default 120 s.
• Change the default timers:
vrf main
routing ripng
timers update-interval 30 holddown-interval 180 flush-interval 120
..
..
Note: Do not change any default value if you are deploying a RIPng network over a LAN. They should be changed
only over some very low bandwidth links (about 32 Kbit/s or less) or over the cost expensive links.
Route aggregation
The routes redistributed by RIPng can be aggregated to decrease the FIB table or to hide the internal architecture
of your network. This aggregation can be done with the following command:
• Aggregate routes:
vrf main
routing ripng
aggregate 3ffe:501:ffff:4000::/52
..
..
Note: This feature is specific to RIPng and is not available with RIP.
Example
vrf main
interface
physical eth0_0
ipv6 address 3ffe:501:ffff:4001::4/64
..
physical eth1_0
ipv6 address 3ffe:501:ffff:4000::4/64
..
physical eth2_0
ipv6 address 3ffe:501:ffff:1::4/64
..
..
routing ripng
aggregate-address 3ffe:501:ffff:4000::/52
network 3ffe:501:ffff::/48
..
..
The tag R(a) means that the prefix 3ffe:501:ffff:4000::/52 is an aggregated one.
In this example we will configure 4 routers rt1, rt2, rt3 and rt4 to support the RIPng options.
RT3 3ffe:cafe:8:1::/64
3ffe:cafe:8:2::/64
rt1
vrf main
interface
physical eth0_0
ipv6 address 2001:1::1/64
..
physical eth1_0
ipv6 address fec0:1::1/64
..
..
routing ripng
network 2001::/16
network fec0:1::/64
static-route fec0:1::/16
..
..
rt2
vrf main
interface
physical eth0_0
ipv6 address 2001:2::1/64
..
physical eth1_0
ipv6 address fec0:2::1/64
..
..
routing
ripng
network 2001::/16
..
..
interface eth0_0
ipv6 ripng split-horizon disable
(continues on next page)
rt3
vrf main
interface
physical eth0_0
ipv6 address 2001:3::1/64
..
physical eth1_0
ipv6 address 2001:cafe:3::1/64
..
..
routing ripng
network 2001::/16
redistribute connected metric 5
..
..
rt4
vrf main
routing ripng
aggregate 3ffe:cafe:8::/48
default-information-originate true
network 3ffe:cafe:8:1::/64
network 3ffe:cafe:8:2::/64
timers update-interval 30 holddown-interval 180 flush-interval 90
..
..
BFD
BFD Overview
Bidirectional Forwarding Detection is a network protocol that permits low overhead and rapid detection of changes
in paths reachability between two network devices.
There was a need to have a replaceholder for other keepalive and hello mechanisms provided by other routing proto-
cols. Actually, BFD detects faster failures, than those mentioned mechanisms, and as such it becomes a mandatory
requirement in today deployments.
BFD principle consists in exchanging specific packets with remote peer. As such, it is needed to configure both
endpoints with BFD. The rate of emission and failover criterium are embedded in the packets. Based on the non
reception of packets, the BFD endpoint will accordingly detect a failover with remote endpoint.
The protocol has improved along the years, and became a standard, from 2011. Initially, protocol was supporting
only connected links, with single-hop. Now, BFD is able to monitor non directly connected links, with the
multi-hop. BFD can also work in echo-mode. Both IPv4 or IPv6 links can be monitored.
BFD notifies the user about the reachability of such paths, and can also interact with other routing protocols. This
is the case with BGP, where neighbors can be monitored by using BFD. This is also the case with OSPF and OSPF
v3. As such, BFD notifies daemons of the rapid change on path reachability, and as consequence, routing protocols
update routing tables quicker.
BFD Packets
BFD operates over UDP protocol. Destination port 3784 is used by BFD single-hop, while 4784 port is used by
BFD multi-hop. echo-mode uses 3785 port. Moreover, the source port range is limited by the standard, as it can
operate over the range from 49152 to 65535.
The BFD control packets payload contains some fields that determine how the BFD operates. For instance, if
echo-mode is used, a field indicates that echo mode is used. It contains a discriminator ID, that is locally generated
and determines the BFD session itself. the remote discriminator of remote endpoint is also mentioned in the BFD
packet.
As mentioned before, BFD operates on time constraints. Those time constraints are chosen, after exchanging be-
tween both endpoints. The timer constraints are encoded in the BFD control packet. For instance, the local endpoint
indicates the desired received interval that the remote endpoint can use to send BFD control packets. Reversely, the
desired transmitted interval is also encoded in the packet.
BFD Operation
The main operation of BFD is to detect the quickest possible the loss of a remote peer. The detection time is
calculated independently in each direction by the receiving system based on the negotiated transmit interval and the
detection multiplier. For instance, if the agreed transmit interval is set to 100 ms, and the detection multiplier is set
to three, the timeout calculation will be around 300 ms.
RFC
BFD Configuration
When forging a BFD configuration, the destination IP and the kind of BFD variant determine a BFD session.
Three additional parameters determine the BFD session: the source address, the interface name and the vrf
name. The source and interface options permit to stick with routing constraints.
tracker bfd other type single-hop address 10.125.0.2 source 10.125.0.1 vrf main
BFD provides low overhead. However, it provides a per peer custom configuration, that permits lowering (or in-
creasing) the timers that determine how, and when BFD packets are sent, and received.
It is possible to disable bfd session usage, by using following command. Note that you will have to check that no
other daemon is using BFD. Otherwise, the command will not be successful.
It is possible to change general timer settings that will apply to the BFD sessions automatically created by routing
protocols (like BGP). This facility avoids the heavy task to configure for each session the newly wished parameters.
Note that configured values are expressed in microseconds.
routing bfd
detection-multiplier 7
required-receive-interval 800000
desired-transmission-interval 200000
Reversely, it is possible to revert to default settings. By default, detect multiplier is set to 3, while default required-
receive-interval and transmit-interval is set to 300 milliseconds.
routing bfd
del detection-multiplier
del required-receive-interval
del desired-transmission-interval
You can use the show bfd commands to watch for BFD sessions.
Following commands gives detailed BFD information about the BFD sessions status and statistics.
In addition to be able to create BFD peer sessions by using nc-cli of bfd, it is possible to dynamically create BFD
peer sessions by relying on remote daemons.
See also:
• Using BFD with BGP, see Configuring BGP with BFD.
• Using BFD with OSPF, see Configuring OSPF with BFD.
• Using BFD with BGP, see Configuring OSPFv3 with BFD.
• Using BFD with static routes, see Configuring Static Routes with BFD.
Path Monitoring
The tracker service provides helpers to monitor the availability of IP addresses, using ICMP echo requests.
In the following example, the router has two links to reach the server: the main link and the backup link. Trackers
can be used to monitor the availability of the server through both links, and configure static routing accordingly. An
higher priority is assigned to the main link, using the distance parameter in the static routing context.
10.10.0.254
in link
ma
vrouter server
gateway2
Monitor availability of server
vrouter running tracker# icmp backup vrf main address 10.100.0.1 gateway 10.20.0.254␣
˓→source 10.20.0.1
˓→icmp-echo
icmp backup address 10.100.0.1 vrf main source 10.20.0.1 gateway 10.20.0.254␣
˓→period 500 threshold 1 total 1 discriminator 489368122 state up diagnostic ok type␣
˓→icmp-echo
The same configuration can be made using this NETCONF XML configuration:
See also:
• The ICMP tracker commands reference.
• The static routing commands reference.
Policy-based routing
Policy-based routing (for IPv4 and IPv6) is a way to forward packets based on multiple criteria, not only the IP
destination.
For that a set of policy routing rules is created. Each policy routing rule consists of a match (source address, input
interface, protocol . . . ) and an action predicate (lookup in a specific table, nat . . . ). The rules are scanned in order
of decreasing precedence. As soon as the packet matches a rule its action is performed.
Only a subset of policy-based routing options are provided. These options are:
• key:
– priority of the rule (high number means lower priority)
• match:
– source: source address or prefix
– destination: destination address or prefix
– mark: filter for the packet firewall mark
The same configuration can be made using this NETCONF XML configuration:
vrouter running config# show config xml absolute vrf main routing policy-based-routing
<config xmlns="urn:6wind:vrouter">
<vrf>
<name>main</name>
<routing xmlns="urn:6wind:vrouter/routing">
<policy-based-routing xmlns="urn:6wind:vrouter/pbr">
<ipv4-rule>
<priority>5</priority>
<match>
<source>192.15.24.0/24</source>
</match>
<action>
<lookup>12</lookup>
</action>
(continues on next page)
Example The following configuration allows to forward packets to subnet 192.165.1.0/24 through different inter-
faces. Packets from subnet 192.168.1.0/24 are forwarded through eth0, other packets through eth1.
See also:
The command reference for details.
3.1.8 QoS
Rate limiting
The traffic received and sent on network interfaces can be rate limited in order to prevent the device or the network
to be overloaded, or to enforce maximum bit rate agreements.
Rate limiting is available on all physical and logical interfaces, in both ingress and egress of the device.
The rate limit of an interface is controlled by a policer, in charge of dropping traffic that does not fulfill a given
traffic profile.
The policer specifies the maximum commited bandwidth of the regular traffic. It may optionally specify an autho-
rized excess bandwidth, to accommodate temporary excess use.
• the traffic profile is measured by a three-color marker (see RFC 4115
(https://tools.ietf.org/html/rfc4115.html)), composed of a token bucket for regular traffic and an optional
token bucket for excess traffic.
• packets are then either granted access or dropped, whether they conform to the traffic profile or not:
– if a packet fulfills the bandwidth/burst specification (green packet), it can pass.
– else if the excess-bandwidth is non-zero and the packet fulfills the excess-bandwidth/excess-burst spec-
ification (yellow packet), it can pass.
– otherwise the packet is out of profile (red packet), it is dropped.
Up to 4 parameters may be defined:
• bandwidth: maximum frame bit rate of regular traffic, a.k.a. CIR (Committed Information Rate), in bits per
second (mandatory),
• burst: maximum burst size of regular traffic, a.k.a. CBS (Committed Burst Size), in bytes (defaults to
bandwidth/80, so that the system is able to handle a burst of 100 ms at the targeted bandwidth),
• excess-bandwidth: maximum frame bit rate of excess traffic, a.k.a. EIR (Excess Information Rate), in bits
per second (default 0),
• excess-burst: maximum burst size of excess traffic, a.k.a. EBS (Excess Burst Size), in bytes (defaults to
bandwidth/80, so that the system is able to handle a burst of 100 ms at the targeted bandwidth).
bandwidth excess-bandwidth
burst excess-burst
Policer templates
Policer templates are created in the global qos context with the policer command. They can then be referenced
by interfaces or by shared policers.
Enter the global qos context:
Interfaces that use this policer will have their frame rate limited to 1 Gbps, with bursts up to 2 Kbytes. Frames that
would cause this profile to be exceeded will be dropped.
Create a policer template with authorized excess traffic:
Interfaces that use this policer will have their frame rate limited to 2 Gbps, with bursts up to the default bandwidth/80
bytes. Excess traffic is authorized up to 15 Mbps with bursts up to the default excess-bandwidth/80 bytes. Frames
that would cause this profile to be exceeded will be dropped.
Show the qos configuration:
The same configuration can be made using this NETCONF XML configuration:
Note: The policer command defines traffic profile templates. They can be used by one or more network interfaces
or shared-policers. Each use of a policer instanciates a new three color marker.
Note: Bandwidth and burst values can be typed as plain integers (e.g. 2000000), or with a standard power-of-1000
multiplier letter to write the value in a more compact way (e.g. 2M):
• K (for kilo): multiply by 1000
• M (for mega): multiply by 10002
• G (for giga): multiply by 10003
• T (for tera): multiply by 10004
The output of show config and show state will always use the most compact form (e.g. 2M, regardless if you
typed 2M, 2000K or 2000000).
This compact notation is only used in the CLI. The NETCONF XML configuration uses plain integers.
Shared Policers
Shared policer are created in the global qos context with the shared-policer command. They can then be refer-
enced by interfaces.
Enter the global qos context:
Create a policer template with no authorized excess traffic, as explained in the previous section:
The same configuration can be made using this NETCONF XML configuration:
Note: While the policer command defines traffic profile templates, that are instantiated whenever they are refer-
enced, the shared-policer command defines unique objects.
Physical and logical interfaces can rate limit their ingress and egress traffic by attaching a dedicated policer, defined
in the qos context.
Enter the qos context of physical interface eth0:
The same settings can be made using the following NETCONF XML configuration:
Each interface that specifies rate-limit policer pol1 instanciates a new policer dedicated to the interface in
the specified direction (ingress or egress).
Physical and logical interfaces can rate limit their ingress and egress traffic by binding to a shared policer, defined
in the qos context.
Enter the qos context of physical interface eth0:
The same settings can be made using the following NETCONF XML configuration:
<config xmlns="urn:6wind:vrouter">
<qos xmlns="urn:6wind:vrouter/qos">
<policer>
<name>pol1</name>
<burst>2000</burst>
<excess-bandwidth>0</excess-bandwidth>
<excess-burst>1</excess-burst>
<bandwidth>1000000000</bandwidth>
</policer>
<shared-policer>
<name>shared-pol1</name>
<policer>pol1</policer>
</shared-policer>
</qos>
<vrf>
<name>main</name>
<interface xmlns="urn:6wind:vrouter/interface">
<physical>
<name>eth0</name>
(...)
<qos>
<egress>
(continues on next page)
Each interface that specifies rate-limit shared-policer pol1 uses the same shared policer object.
A given shared-policer may be shared by interfaces in different vrfs and directions.
See also:
The command reference for details on the qos global context:
• qos context
and for configuring qos on network interfaces:
• bridge interfaces qos
• gre interfaces qos
• ipip interfaces qos
• lag interfaces qos
• loopback interfaces qos
• physical interfaces qos
• veth interfaces qos
• vlan interfaces qos
• vxlan interfaces qos
• xvrf interfaces qos
Shaping
Shaping causes a traffic flow to conform to a bandwidth value referred to as the shaping rate. Excess traffic beyond
the shaping rate is queued inside the shaper and transmitted only when doing so does not violate the defined shaping
rate.
A shaper is implemented using a token bucket. If a packet fulfills the bandwidth/burst specification, it can pass.
Otherwise, the packet is kept in a delay queue until it fulfills the bandwidth/burst specification. As soon as the delay
queue is full, the incoming packets are dropped.
Shaping is applied to egress traffic on physical interfaces.
bandwidth
burst
shaped traffic
token bucket
incoming traffic outgoing traffic
Shaper templates
Shaper templates are created in the global qos context with the shaper command. They can then be referenced by
a physical interface for egress.
Enter the global qos context and create a shaper:
Interfaces that use this shaper will have their frame bandwidth shaped to 1 Gbps, with bursts up to 2 Kbytes. Frames
that would cause this profile to be exceeded will be temporary saved in a delay queue to be sent later to fulfill the
frame rate limitation. When the delay queue is full, the incoming frames are dropped.
By default the size of the delay queue is 256 packets. It can be changed via the queue-size command.
Note: If a scheduler and a shaper template are applied on an interface, the queue size of the shaper template is
ignored. In this case the different queues of the scheduler are also used as delay queues.
In order to take into account bytes added to the frame size by the layer 1 level (by default 24 bytes for Ethernet CRC,
Internet Frame Gap and preamble), you can specify an amount of bytes to add to the frame size in rate and burst
calculations via the layer1-overhead command.
The same settings can be applied using the following NETCONF XML configuration:
vrouter running config# show state vrf main interface physical eth0
physical eth0
qos
egress
rate-limit
shaper
bandwidth 10G
burst 125M
queue-size 256
layer1-overhead 24
stats
pass-packets 0
drop-packets 0
..
..
..
..
..
..
..
The same settings can be applied using the following NETCONF XML configuration:
When configuring a simple shaper on the output of an interface that is constantly fed with traffic over the limit, a
part of the traffic is necessarily dropped. There is a risk that critical control plane traffic be dropped.
In order to protect this critical control plane and preserve it from being dropped, a simple QoS scheduler and traffic
filter should be configured in addition to the shaper. Please refer to chapter Shaping the output while protecting
critical control plane traffic.
Scheduling
Scheduling allows to apply different types of processing to different egress queues configured on an interface. It
assumes that the traffic is mapped to each queue, thanks to the concept of traffic class.
Scheduling provides two different queueing processings: Priority Queueing and PB-DWRR (Priority-Based Deficit
Weighted Round Robin).
Each queue has several parameters:
• The size of the queue defines how many packets can be stored in the queue. Longer queues mean longer
delays.
• The list of traffic classes that are submitted to the queue. Traffic classes are defined in the firewall section.
• An input policer to rate limit incoming traffic.
Scheduler
Flow 1
queue1's queue1's
queue 1
policer shaper
Flow 2
Flow output
classifier queue2's queue2's scheduler's
queue 2 shaper algorithm
policer
(priority
....
queuring or
Flow p pb-dwrr)
queueN's ...
queue N
queueN's
policer shaper
Traffic classes
A class specifies a set of traffic flows, identified by their mark and/or the value of the CP flag (critical Control Plane
traffic flag).
A class is attached to the queue in which traffic flows will be scheduled. One or more classes may be attached to the
same queue.
The CP flag is a flag set on critical packets sent by the control plane, i.e. the same traffic as the one protected by
the Control Plane Protection feature, as described in the control plane protection.
This flag is automatically set when the Linux kernel outputs such a packet. It can be matched by the QoS classifi-
cation stage.
Classes are defined by the mark of the packets and/or the value of the CP flag. Packet marking is done before QoS
processing and must be configured at the IP packet filtering level.
QoS classification is usually based on the DSCP field of the IP header. In practice, this field is set for incoming
packets by the border routers of a QoS network, allowing core routers to work with it without giving up too much
processing power.
This example shows how to mark packets based on DSCP field:
This example shows how to mark packets based on DSCP field, and change the DSCP value. Only one action is
allowed per rule, therefore this requires to either use a chain or repeat the same rule with different actions.
Here, the chain policy is return, which means that matching packets will be processed by the remaining rules after
being marked. Use policy accept if marked packets should not be processed further by the firewall.
Note: Refer to the mark action of the rule command in the command reference.
Classification
Classes are created in the global qos context with the class command. They can then be referenced by any sched-
uler.
A class is defined by a packet mark and/or the value of the CP flag.
Enter the global qos context and create classes:
By default, all bits of the mark are used to specify classes. Therefore, up to 2**32 different marks are supported. It
is possible to specify which bits are used for QoS in order to use the mark for different purposes. In this case, the
number of different marks is 2**n where n is the number of bits reserved for the QoS in the mark.
To modify the mask used by the QoS enter the global qos context and edit the class-mask:
With this configuration, the first 8 bits of the mark are used to specify classes for QoS, so that 256 different marks
can be used.
Note: The class-mask bitmask indicates which bits of the packet and class marks are taken into account. Other
bits are ignored.
A packet belongs to a class if:
the 2 classes class42 and class542 match the same packets, those with a mark whose last byte is 0x42; for example
packets with marks 0x42, 0x542, 0xff42 or 0x424242. Which class these packets will be assigned is undefined.
Therefore, care must be taken to avoid defining two classes for which (class-mark AND class-mask) equals the same
value.
A class can also be configured to match (or to not match) the output critical control plane traffic.
The following class matches all critical control plane traffic:
The following class matches all critical control plane traffic with mark 0x30:
The following class matches traffic with mark 0x30, except critical control plane traffic:
Note: At most one mark and the value of the CP flag may be specified in a class. A packet belongs to a class
if it matches all parameters specified in the class. The following combinations are supported, and evaluated in this
order:
• cp true + mark
• cp true
• cp false + mark
• mark
Note: A packet that does not belong to any class or whose class is not bound to any queue will be submitted to the
last queue.
Scheduling algorithms
Priority Queueing
When the scheduling algorithm is Priority Queueing, N queues are defined. Each queue has a different priority. The
first queue has the highest priority, the last one has the lowest. Queues are served by order of priority: the scheduler
first takes packets from the highest priority queue and submits them to the network hardware. When the queue is
empty, it starts processing the next queue and so on.
PB-DWRR
When the scheduling algorithm is PB-DWRR, N queues and two priority levels are defined: high and low.
Among the N queues, one has the high priority, and the N-1 others the low priority. Each low priority queue has a
quantum that defines the share of the remaining bandwidth it will receive.
The high priority queue is served first. Once it is empty, other queues are served in a round robin fashion: the
scheduler performs DWRR rounds between low priority queues. At each round, it checks each queue in sequence
and enables it to send bytes up to its quantum. Then it serves the next queue, and so on.
When queue priorities are not set, all queues are served according to their quantum. This is the simple DWRR
mode, which prevents starvation.
Scheduler templates
Scheduler templates are created in the global qos context with the scheduler command. They can then be refer-
enced by a physical interface for egress.
Enter the global qos context and create a scheduler using Priority Queueing:
Enter the global qos context and create a scheduler using PB-DWRR:
Note: A scheduler runs on a dedicated core which is chosen automatically if not set.
Note: To send several types of traffic flows to the same queue, you can define a class for each traffic flow, and attach
all classes to the queue. (e.g. classes control and voip attached to queue 1 in examples above).
The same settings can be applied using the following NETCONF XML configuration:
Note: When a scheduler is configured on an interface, it is mandatory to also configure a rate limit shaper on the
same interface.
qos
egress
rate-limit
shaper
bandwidth 10G
burst 48K
layer1-overhead 24
queue-size 256
stats
pass-packets 0
drop-packets 0
..
..
..
scheduler
core 2
pq
nb-queue 3
queue 1
size 256
shaper
bandwidth 1G
burst 2K
stats
pass-packets 0
drop-packets 0
..
..
class cp
stats
match-packets 0
..
..
class 0x00000001
stats
match-packets 0
..
..
(continues on next page)
The same settings can be applied using the following NETCONF XML configuration:
vrouter running config# show config xml absolute vrf main interface physical eth0
<config xmlns="urn:6wind:vrouter">
<vrf>
<name>main</name>
<interface xmlns="urn:6wind:vrouter/interface">
(continues on next page)
When configuring a simple shaper on the output of an interface that is constantly fed with traffic over the limit, a
part of the traffic is necessarily dropped. There is a risk that critical control plane traffic be dropped.
A simple solution is to configure a Priority Queueing scheduler with 2 queues, one for the critical control plane
traffic, the other for the rest of the traffic.
In this example, we configure an output shaper at 100Mbps, and the 2 queue Priority Queueing scheduler:
Configure the shaper wanshaper:
Configure the scheduler wansched, and attach class control to the high priority queue:
vrouter running config# show state vrf main interface physical eth0
qos
egress
rate-limit
shaper
bandwidth 1M
burst 1250
layer1-overhead 0
queue-size 256
stats
pass-packets 311640
drop-packets 329125
..
..
..
scheduler
core 1
pq
nb-queue 2
queue 1
size 256
class cp
stats
match-packets 90
..
..
stats
enqueue-packets 90
xmit-packets 90
drop-queue-full 0
..
..
queue 2
size 256
class default
stats
match-packets 640583
..
..
stats
enqueue-packets 311550
xmit-packets 311550
drop-queue-full 329125
(continues on next page)
The same settings can be applied using the following NETCONF XML configuration:
<config xmlns="urn:6wind:vrouter">
(...)
<vrf>
<name>main</name>
<interface xmlns="urn:6wind:vrouter/interface">
<physical>
<name>eth0</name>
<port>pci-b0s5</port>
<qos>
<egress>
<rate-limit>
<shaper>wanshaper</shaper>
</rate-limit>
<scheduler>wansched</scheduler>
</egress>
</qos>
</physical>
</vrf>
<qos xmlns="urn:6wind:vrouter/qos">
<class>
<name>control</name>
<cp>true</cp>
</class>
<shaper>
<name>wanshaper</name>
<burst>125000</burst>
<bandwidth>100000000</bandwidth>
</shaper>
<scheduler>
<name>wansched</name>
<pq>
<nb-queue>2</nb-queue>
<queue>
<id>1</id>
(continues on next page)
3.1.9 Security
IKE
Internet Key Exchange (IKE) is the control plane protocol providing authentication and key exchange mechanisms
to establish secure VPNs over IPsec.
IKE peers authenticate each other via native IKE methods (pre-shared keys or certificates), or via various EAP
(Extensible Authentication Protocol) methods.
About IPsec
IPsec (Internet Protocol Security) is a suite of protocols that provides security to Internet communications at the
IP layer. The most common current use of IPsec is to provide a Virtual Private Network (VPN), either between
two locations (gateway-to-gateway) or between a remote user and an enterprise network (host-to-gateway). More
information is available in RFC4301.
About IKE
IKE (Internet Key Exchange) is the key negotiation and management protocol that is most commonly used to
provide dynamically negotiated and updated keying material for IPsec. IPsec and IKE can be used in conjunction
with both IPv4 and IPv6.
More information is available in RFC2409 and the latest update RFC7296.
The following sections explain the basics of IKE configuration, then present a couple of use cases and finally detail
advanced configuration and performance tuning.
Enabling IKE
Next, a VPN must be defined to specify the security parameters and policies to apply to the traffic, as well as
authentication credentials for the IKE negotiation. To simplify the configuration of VPNs, VPN templates are
proposed.
VPN templates
The number of parameters for IKE is very high and it would be painful to repeat all of them for each VPN configu-
ration. Therefore a template system is available to ease the configuration:
• several VPNs can share the same settings by referring to the same template,
• each parameter present in a template can be overridden by the VPN.
The IKE protocol consists of two phases:
• The first phase performs mutual authentication of two IKE peers and establishes an IKE Security Association
(IKE SA), i.e. a secure communication channel between the two parties.
• The second phase enables to create or update pairs of ESP or AH SAs. Each pair of ESP or AH SAs is called
a CHILD SA.
IKE policy templates enable to define a model of IKE SA parameters. VPNs inherit their IKE SA parameters from
such template, then can override each of them.
Create an IKE policy template:
One or more IKE cryptographic algorithm proposals may then be defined in the ike-policy-template, or directly
in the VPN ike-policy:
Each IKE proposal must contain either:
• a list of encryption algorithms (enc-alg).
• a list of authentication algorithms (auth-alg).
• a list of diffie hellman groups (dh-group) for key exchanges.
• optionally a list of pseudo-random function algorithms (prf-alg). If no prf-alg is provided, then the
authentication algorithms will be used for generating random numbers.
Or:
• a list of combined mode algorithms (aead-alg), which provide both encryption and authentication.
• a list of diffie hellman groups (dh-group) for key exchanges.
• a list of pseudo-random function algorithms (prf-alg) for generating random numbers.
As supported by the IKE protocol, the IKE daemon may submit several IKE proposals in a negotiation, and (for
IKEv2 only), each proposal may contain several algorithms of the same type (for example several encryption algo-
rithms).
All other parameters of an ike-policy-template have a default value. Each parameter (including
ike-proposal) may be overridden by the VPN, for example the authentication method.
IPsec policy templates enable to define a model of CHILD SA parameters. VPNs inherit their IPsec SA parameters
from such template, then can overridde each of them.
Create an IPsec policy template:
One or more ESP and AH cryptographic algorithm proposals may then be defined in the ipsec-policy-template,
or directly in the VPN ipsec-policy.
Each ESP proposal must contain either:
• a list of encryption algorithms (enc-alg).
Each ESP and AH proposal may optionally activate Perfect Forward Secrecy (PFS) by specifying a list of diffie hell-
man groups. This will trigger an additional diffie hellman exchange to exchange CHILD SA keys. If no dh-group
is specified, CHILD SA keys will be derived from former keys.
A proposal may also optionally enable Extended Sequence Numbers (ESN) (see Extended Sequence Number (ESN)).
As supported by the IKE protocol, the IKE daemon may submit several ESP or AH proposals in a negotiation, and
(for IKEv2 only), each proposal may contain several algorithms of the same type (for example several encryption
algorithms).
All other parameters of an ipsec-policy-template have a default value. Each parameter (including
esp-proposal and ah-proposal) may be overridden by the VPN, for example the replay window size.
An important parameter is start-action that defaults to trap, meaning that the tunnel will be triggered as soon
as outgoing matching traffic is detected.
See also:
The command reference for details about template parameters.
To display the configuration, from the ike context, type:
After VPN templates have been created, you may use them in one or several VPNs.
Creating a VPN
A VPN defines the security parameters between the local host and a remote IKE peer (or a group of IKE peers), and
the IPsec security policies to apply to the IP traffic that transits through these peers.
Creating a VPN basically consists in:
• specifying which IKE and IPsec template to apply,
• optionally overriding some parameters of these templates,
Then define an IPsec security-policy trunk between subnets 192.168.0.0/24 and 192.168.99.0/24, with the
default action (do ESP in tunnel mode).
Finally, define a pre-shared key hq-secgw for mutual authentication with the remote peer:
IKE authentication
Pre-shared keys are secret symmetric keys shared by two IKE peers. They are configured in the pre-shared-key
list.
When using pre-shared key authentication for the local host or remote peer authentication, the shared key must be
declared as follows:
Each pre-shared key is identified by this name and is composed of two parts, a secret key and optional IKE identity
selectors (a list of IKE identities).
The secret key itself, secret, may be encoded either:
• as a sequence of characters delimited by double-quotes,
secret 0xd2c79a277d517f31cd46f5121f4a14620ef39d35b4
secret 0seaJ31RfzHNRvUSH0oUYg7znTW0I=
The optional IKE identity selector list id, specifies for which peers this key must be used. To authenticate a con-
nection between two hosts, the entry that most specifically matches the host and peer IDs is used.
An entry with a single selector matches if the peer ID matches the selector. An entry with multiple selectors matches
if both the local host ID and peer ID each match one of the selectors. An entry with no ID matches all peers, it is
the default pre-shared key.
For more information, see strongSwan’s IKE secrets ID selectors (https://wiki.strongswan.org/projects/strongswan/wiki/IpsecSecr
selectors).
To authenticate the local host by pre-shared keys, the local-auth-method must be set to pre-shared-key in the
ike-policy-template used by the VPN, or overriden in the VPN ike-policy.
or:
Similarly, to authenticate the remote peer by pre-shared keys, the remote-auth-method must be set to
pre-shared-key in the ike-policy-template used by the VPN, or overriden in the VPN ike-policy.
Pre-shared keys is the default authentication method.
Certificate authentication
CA
CA
Certificates enable to easily deploy a large number of IKE clients without maintaining and distributing a large list
of secret keys (one for each pair of IKE peers) or weakening the system by using a single secret key shared between
all IKE peers. It also avoids to modify the configuration of each peer when a new one is added.
user1
l
tunne user1
IPsec
user1
SecGW-A
IPsec tunnel
user2
CA user2
IPs
ec user2
tun
ne ...
l
userN
userN
userN
Each IKE peer owns a digital certificate and a private key. The certificate embeds identity information and the
matching public key. The certificate is delivered and signed by a certificate autority (CA), whose public key is
stored in a CA (Certification Authority) certificate. The CA certificate enables to validate the authenticity of all
certificates that it delivered.
Like for bank cards, CAs (Certification Authorities) may also revoke a valid certificate before its expiration, for
example in case of disclosure of the public key or the departure of an employee. To proceed, the CA may deliver a
signed certificate revocation list (CRL), that lists revoked certificates.
Certificates, private keys and certificate revocation lists are stored in the Privacy Enhanced Mail (PEM) format in
the configuration.
The local host certificate and private key must be installed in the certificate list:
Then the local-auth-method must be set to certificate in the ike-policy-template used by the VPN (or
overriden in the VPN ike-policy).
Finally, the list of certificate candidates to use for authentication is specified in the VPN certificate command.
The certificate used for authentication is selected based on the received certificate request payloads. If no appropriate
CA can be located, the first certificate is used.
The IKE id used by the local host must be stored in its certificate, in the subjectName or in the subjectAltNames
section.
The certificate authority that issued the certificates that remote peers will present must be declared in the
certificate-authority list:
... MIIC2zCCAkSgAwIBAgIJAJpUB7T8zBYBMA0GCSqGSIb3DQEBBAUAMFMxEzARBgNV
... BAoTCjZXSU5EIFMuQS4xDjAMBgNVBAcTBVBhcmlzMQswCQYDVQQGEwJGUjEfMB0G
... A1UEAxMWSGVhZHF1YXJ0ZXJzIEF1dGhvcml0eTAeFw0xODA5MTkxMzE5MTNaFw0x
... ODEwMTkxMzE5MTNaMFMxEzARBgNVBAoTCjZXSU5EIFMuQS4xDjAMBgNVBAcTBVBh
... cmlzMQswCQYDVQQGEwJGUjEfMB0GA1UEAxMWSGVhZHF1YXJ0ZXJzIEF1dGhvcml0
... eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA2mWsQQ14SSkx0Qp5eXXHMkAV
... OEyIJVD3dVPrcQkeCUR38KPrA8Dmlt/KLTrTfat6+/wxS1HywCLYR3U1+CrEQmR+
... kC/NgcNC+QqXyevb+2LTT606oHMQ6XckWIDhhD6JszN0dtcAci1SMgaKIoaoxElu
... TwIdDBkj8W7gnpn84k8CAwEAAaOBtjCBszAMBgNVHRMEBTADAQH/MB0GA1UdDgQW
... BBSN5H+zxbYDk/kVJuqimYsT2oDGDTCBgwYDVR0jBHwweoAUjeR/s8W2A5P5FSbq
... opmLE9qAxg2hV6RVMFMxEzARBgNVBAoTCjZXSU5EIFMuQS4xDjAMBgNVBAcTBVBh
... cmlzMQswCQYDVQQGEwJGUjEfMB0GA1UEAxMWSGVhZHF1YXJ0ZXJzIEF1dGhvcml0
... eYIJAJpUB7T8zBYBMA0GCSqGSIb3DQEBBAUAA4GBAEvu9Rj1dUcQsFywseZdZcC7
... 9jxhHtml1naxqDp/krPG/GJiSiCypQOGjbcXlRa2NOtLU7DwZTKH3S3fw8TBIAen
... 7vbQFLUtzrZ07TW4wnmtBtGd7GVqAZVIoUnkldVHhHL6hGy2DM+3e8+lptx8+tb6
... U/7s2V3Bm/HkQRq8+Gji
... -----END CERTIFICATE-----"
vrouter running certificate-authority hq-authority# ..
vrouter running ike#
Then to authenticate the remote peer by certificates, the remote-auth-method must be set to certificate in the
ike-policy-template used by the VPN (or overriden in the VPN ike-policy).
Finally, the CA certificates to trust for the authentication of the remote peer must be specified in the VPN
remote-ca-certificate list.
The IKE id used by the remote peer must be stored in its certificate, in the subjectName or in the subjectAltNames
section.
To add a CRL distribution point, specify the LDAP (Lightweight Directory Access Protocol) or HTTP (HyperText
Transfer Protocol) URI (Uniform Resource Identifier). CRLs (Certificate Revocation Lists) must be encoded in
DER (Distinguished Encoding Rules) binary format on the distribution server.
Note: IKE service can use certificates that exist in the local database just by providing the certificate’s name. Note
also that the service is refreshing those certificates whenever an update is made.
See also:
Check certificates management commands for more details about how certificates are managed in the local database.
EAP authentication
EAP is typically used by a VPN concentrator accepting IKE connections, to authenticate remote clients via external
methods (legacy methods such as EAP-MD5 (EAP - Message Digest 5) or EAP-MSCHAPv2 (EAP - Microsoft
CHAP v2), mobile network methods such as EAP-SIM (EAP - Subscriber Identity Module) or EAP-AKA (EAP -
Authentication and Key Agreement). . . ). The authentication methods are usually asymmetric: the server is authen-
tified by pre-shared keys or a certificate, and the clients by EAP.
Local and remote EAP keys may be stored in a local database. They are similar to pre-shared keys, but are used by
EAP authentication methods. They are configured in the eap-key list.
These keys are looked up to authenticate IKE peers if the local-auth-method or remote-auth-method is set to
eap-md5 or eap-mschapv2.
Like pre-shared keys, EAP keys are assigned a name and are composed of two parts, a secret key and optional EAP
identity selectors (a list of EAP identities).
The encodings and selection rules are the same as for pre-shared keys, except that the EAP ID is taken into account
instead of the IKE ID.
To authenticate the local host by EAP keys, the local-auth-method must be set to the right EAP method
eap-mschapv2 or eap-md5 in the ike-policy-template used by the VPN, or overriden in the VPN
ike-policy.
or:
Similarly, to authenticate the remote peer by pre-shared keys, the remote-auth-method must be set to
eap-mschapv2 or eap-md5 in the ike-policy-template used by the VPN, or overriden in the VPN
ike-policy.
On the server side, the EAP authentication of remote peers can be delegated to one or more RADIUS servers, the
IKE daemon then acts as a simple proxy.
This delegation of EAP authentication to RADIUS servers is configured by selecting eap-radius as the remote
authentication method, and by declaring one or more EAP RADIUS servers in the eap-radius list.
Select eap-radius as the remote authentication method in the VPN IKE policy:
Configure an EAP RADIUS server. The minimal parameters are the server IP address and an authentication secret.
A RADIUS server may be in a VRF different from the IKE daemon, typically in a corporate network instead of the
public network. It can be specified in the server configuration:
Since RADIUS exchanges are synchronous, it is recommended to enable parallel exchanges by setting the sockets
parameter: it specifies the number of concurrent requests that can be sent to a RADIUS server (each from a different
local UDP port).
A common parameter exists:
IKE state
Note: Child SAs traffic selector proposed by the remote peer can include unsupported stuff (like port range). In
this case, the flag unsupported is set:
local-ts subnet 10.100.0.0/24 protocol 17 port 50000-54000 unsupported
Route-based VPNs
To bind a security policy to an SVTI interface, specify the svti-id of the interface on inbound and outbound
policies:
Create SVTI interface svti100:
The security policy is bound to the SVTI interface with SVTI ID 100 and link VRFID main, namely svti100.
Note: The decision to bind to an SVTI interface is done per security-policy and per direction. The configuration
may differ between two security-policies and between two directions of the same security-policy. For example:
vrouter running vpn my_vpn# security-policy mytunnel1 svti-id-in 100 svti-id-out 200
vrouter running vpn my_vpn# security-policy mytunnel2 svti-id-out 150
vrouter running vpn my_vpn# security-policy mytunnel3
SVTI interfaces may be dynamically created and attached to IKE SAs as they are established.
To proceed, first create an SVTI template:
Note: A separate SVTI interface is created for each established IKE SA spawn from this VPN definition. All its
child SAs are bound to the SVTI, for both the inbound and outbound traffic.
Routes are automatically added or deleted via the dynamically created SVTI interface as child SAs are established
or torn down. Which routes should be added is configurable in the SVTI template with the install-routes-to
command.
Add routes to the IKE SA remote host virtual IPs, if any, else to the child SA remote traffic selector. This is the
default behavior:
See Dynamic SVTI for details about creating SVTI interface templates.
Like other tunnel interfaces, SVTI interfaces enable to perform cross-vrf encapsulation: encapsulated packets are
not in the same vrf as the original packets.
IKE
local site SecGW-A SVTI interface remote remote site
peer
(link-vrf wan)
(vrf private) (vrf private)
To proceed, configure the SVTI interface in the VRF of original packets, specify a link VRF equal to the VRF of
encapsulated packets.
Dynamic SVTI interfaces also enable to perform cross-vrf encapsulation. The link-vrf of a dynamic interface is the
vrf of the VPN that triggered its creation.
IKE
local site SecGW-A SVTI interface remote remote site
peer
(link-vrf wan)
(vrf private) (vrf private)
Then create a VPN in the link VRF and bind it to the SVTI template, by specifying its name and VRF.
Note: If a VPN in VRF wan specifies an SVTI template, then no static SVTI must be configured with its link VRF
in wan.
Use cases
In this use case, two sites A and B must be interconnected via a public network. An IPsec VPN is configured
between the two security gateways SecGW-A and SecGW-B.
192.0.2.1 198.51.100.1
site A site B
192.168.0.0/24 SecGW-A IPsec tunnel SecGW-B 192.168.99.0/24
The IP addresses of the security gateways and of the sites are well known. The peers identify themselves with a
Fully Qualified Domain Name (FQDN) and authenticate via a pre-shared key.
In this use case, remote users must be given access to the local site A via a public network. The traffic must be
secured by IPsec VPNs between users and the security gateways SecGW-A.
192.0.2.1 @pub1
@vip1
user1
l 192.168.99.X
tunne
IPsec
site A @pub2
192.168.0.0/24 SecGW-A @vip2
IPsec tunnel user2
192.168.99.Y
IPs ...
ec
tun
user-vips ne
l
192.168.99.0/24
@vipN
userN
192.168.99.Z
@pubN
IKE negotiations are initiated by the remote users. Their public IP addresses are dynamically assigned by their
access point. Each user requests the security gateway to assign it a virtual private address. The security gateway
picks this virtual IP from a local pool.
The peers identify themselves with a user Fully Qualified Domain Name (user FQDN) and authenticate via pre-
shared keys. Remote hosts use different VPN clients that support different cryptographic algorithms and key lengths.
In this use case, remote users must be given access to the local site A via a public network. The traffic must be secured
by IPsec VPNs between users and the security gateways SecGW-A. Dynamic SVTI interfaces and cross-VRF are
used.
192.0.2.1 @pub1
(vrf wan) @vip1
e user1
I in terfac 192.168.99.X
ic SVT
dynam
site A @pub2
192.168.0.0/24 SecGW-A @vip2
dynamic SVTI interface user2
192.168.99.Y
(vrf private) dy
na
mi
cS ...
VT
user-vips I in
ter
192.168.99.0/24 fac
e
@vipN
userN
192.168.99.Z
@pubN
IKE negotiations are initiated by the remote users. Their public IP addresses are dynamically assigned by their
access point. Each user requests the security gateway to assign it a virtual private address. The security gateway
picks this virtual IP from a local pool.
The peers identify themselves with a user Fully Qualified Domain Name (user FQDN) and authenticate via pre-
shared keys.
Plaintext traffic is in VRF private, while encrypted traffic is in vrf wan.
The base of the IKE control plane is the open source StrongSwan distribution.
In this section we focus on parameters useful to tune the scalability and performance of IKE.
Logging
The IKE service is liable to issue many log messages. The verbosity of these logs is configurable per subsystem.
Messages issued by the IKE service are classified in 5 levels:
Where:
• FACILITY is the syslog facility (daemon or authpriv),
• SUBSYSTEM is the subsystem (see IKE log subsystems), or default to specify the default log level for all
subsystems,
• LEVEL is the maximum log level of messages in the specified subsystem, (see IKE log levels) or disable
to disable all messages,
Example
The following commands modify which log messages are sent to facility authpriv:
• messages up to level 2 from the ike subsystem are logged to facility authpriv,
• messages up to level 1 from other subsystems are logged to facility authpriv.
Note: Depending on the configuration, messages may be logged twice, once in facility daemon, and a second time
in facility authpriv.
According to the configuration, log messages are sent to the daemon and/or authpriv syslog facilities with the
notice severity. The severity is not configurable.
With throughputs getting higher and higher, the 32 bit IPsec sequence number may reach its maximum value
before it is expected, so much that an Extended Sequence Number (ESN) option was defined (see RFC 4304
(https://tools.ietf.org/html/rfc4304.html)), that extends the sequence number to 64 bits.
The use of ESN can be configured in each esp-proposal or ah-proposal in the ipsec-policy-template or
vpn ipsec-policy. By default, ESN is disabled.
Require the use of ESN:
To specify that ESN is not mandatory but should be negotiated, specify both esn true and esn false, by order
of preference:
There is no guarantee that IPsec packets are received by the security gateway in the same order as they were sent.
With throughputs getting higher and higher, out-of-order IPsec packets may be dropped by the IPsec replay pro-
tection system if their lateness exceeds the replay window size. The size of the replay window can be increased to
avoid such problem.
The replay window size option can be configured in the ipsec-policy-template (or vpn ipsec-policy):
replay-window is an integer number of packets, in the range 0 to 4096 packets (default 32, 0 disables replay
protection).
Note that the replay window size is a local choice, it does not impact the replay window size chosen by the remote
peer.
Virtual IP pools
IKEv1 and IKEv2 enable to assign a virtual IP during an IKE negotiation, i.e. an IKE initiator may request an
additional IP address from the responder to use as inner IPsec tunnel address.
Virtual IPs are exchanged using the mode config extension in IKEv1, or using configuration payloads in IKEv2.
Additional parameters may be assigned during this exchange, such as a DNS server address, a NetBIOS server
address or a DHCP server address.
To proceed, the responder maintains one or more pools of virtual IPs:
• address is a list of addresses that can be assigned. Each list item can be a single address, a range of addresses
or a subnet (IPv4 or IPv6).
• dns is an optional list of DNS server addresses (IPv4 or IPv6).
• nbns is an optional list of NetBIOS server addresses (IPv4 or IPv6).
• dhcp is an optional list of DHCP server addresses (IPv4 or IPv6).
A VPN can then reference a list of pools in its configuration:
To include this dynamically assigned address in a security policy, make sure that no remote-ts is configured, or
at least that the remote-ts subnet is unset (other fields such as the protocol may still be specified):
If an IKE initiator requests a virtual IP, it will be assigned one of the addresses in the vip-pool(s), and the optional
attributes (dns, nbns, dhcp).
Retransmission constants
The IKE daemon uses an exponential backoff algorithm to calculate the timeout of packets before retransmission:
the timeout grows exponentially with the number of tries, following the formula:
timeouttry = retransmit-timeout × retransmit-basetry
Where try ranges from 0 to retransmit-tries. After retransmit-tries unsuccessful retransmissions, the
IKE daemon gives up the negotiation.
The retransmission constants can be configured in the global-options section:
By default IKE negotiations are triggered by outgoing traffic (ipsec-policy-template start-action trap).
When an outgoing packet matches a security policy that requires IPsec protection, but no suitable SA is available,
an SA acquire message is raised to trigger the negotiation and a temporary IPsec SA is created in the IPsec stack.
This acquire SA prevents further acquire messages to be raised until the negotiation succeeds, or the acquire SA
times out.
The default lifetime of an acquire SA is 165 seconds, this matches the total retransmission time of an IKE message
that would receive no answer, with default retransmission constants.
This lifetime may be adjusted in the global-options section:
DoS protection
The IKE daemon provides Deny of Service (DoS) protection using cookies and aggressiveness checks.
All DoS protection mechanisms are configured in the global-options dos-protection section.
• cookie-threshold is the number of half-open IKE SAs that activate the cookie mechanism. It is an integer
number or the keyword always (default 10). 0 disables the cookie mechanism. always activates it whatever
the number of half-open SAs.
• block-threshold is the maximum number of half-open IKE SAs for a single peer IP. It is an integer number
(default 5). 0 disables the limit.
• init-limit-half-open fixes a limit to the number of half open IKE SAs. New connections are refused if
this limit is reached. It is an integer number (default 0). 0 disables the limit.
For more details, please refer to the charon.cookie_threshold and charon.block_threshold
and charon.init_limit_half_open options in strongSwan’s strongswan.conf configuration file
(https://wiki.strongswan.org/projects/strongswan/wiki/StrongswanConf#Defined-keys).
The IKE SA hash table size can be increased to improve performance when a high number of SAs is managed by
the IKE daemon. It can be split into segments to improve performance when a high number of SAs is managed by
the IKE daemon on multiple cores. Each segment will get its own lock.
It can be configured in the global-options section.
The IPsec security policy database (SPD) is an ordered list of rules, the security policies (SPs), that specify what
IPsec processing must be applied to packets. They are composed of a packet selector (direction, source subnet,
destination subnet, protocol, port) and an action (esp, ah, pass or drop). By default, these SPs are stored in a linked
list. The time to browse this list increases with the number of SPs in O(n).
When the IKE daemon establishes a child SA, it configures SPs in the IPsec stack. If the number of SPs grows, the
time to add SPs grows in O(n), which slows down the negotiation rate.
When the network stack processes traffic, it looks up for the IPsec policy to apply to outbound and inbound packets.
If the number of SPs grows, the time to lookup for the right policy grows in O(n), which slows down the throughput,
regardless if packets need IPsec processing or not.
To solve this scalability issue, the IPsec stack maintains a hash table of security policies. SPs are hashed based on
the source and destination address of their selector. These addresses are subnets with variable prefix lengths, which
prevents from hashing on all bits of the addresses. Some SPs cannot be hashed because their selector is too wide
(the address prefix lengths are too small). These un-hashed SPs are stored in the linked list.
Thresholds are defined, to select which SPs will be hashed and how many bits of address will be included in the
hash key:
• sp-hash-ipv4 local and remote are the local and remote address minimum prefix lengths of hashed IPv4
SPs. They range from 0 to 32 (default 32).
• sp-hash-ipv6 local and remote are the local and remote address minimum prefix lengths of hashed IPv6
SPs. They range from 0 to 128 (default 128).
SPs whose local and remote address prefix lengths are greater or equal to the thresholds are hashed (which speeds
up the lookup and insertion), others are simply looked up in sequence. For hashed SPs, the high order bits of the
address (up to the threshold) are included in the hash key calculation.
Example:
Hash thresholds not only determine which policies will be hashed, but also the number of bits of the local and
remote address that will be used to calculate the hash key. Big thresholds mean potentially fewer hashed policies,
but better distribution in the hash table, and vice versa.
A good trade off must be found depending on the prefix lengths used in the SPD.
Routes can be inserted into a separate routing table for established IPsec tunnels. This enables to inject routes to
the remote network discovered during an IKE negotiation.
MOBIKE (RFC 4555) allows the IP addresses associated with IKEv2 and tunnel mode IPsec Security Associations
to change. A mobile Virtual Private Network (VPN) client could use MOBIKE to keep the connection with the
VPN gateway active while moving from one address to another. Similarly, a multihomed host could use MOBIKE
to move the traffic to a different interface if, for instance, the one currently being used stops working.
MOBIKE can be enabled in the IKE policy template:
By default, when MOBIKE is enabled, the SA addresses are not modified if the routing path is still usable. Enabling
mobike-prefer-best-path in global options dynamically changes this behavior: on routing change, if a cheaper
path exists, the SA will be updated dynamically.
To enable the mobike-prefer-best-path option:
See also:
The command reference.
IP packet filtering
This is where IPv4 and IPv6 packet filtering is configured. The device monitors incoming and outgoing traffic, and
determines whether to allow or deny traffic, based on sequenced list of rules. Each rule contains a packet selector
and the related action.
The IP packet filtering module leverages Netfilter, and re-uses its concepts.
Note: Filtering rules not configured by the management system will not be displayed by show state and will be lost
when a new firewall configuration is committed.
Caution: Stateful IP packet filtering and CG-NAT are exclusive. If CG-NAT is enabled, stateful IP packet
filtering must be disabled on ports bound to the fast path.
See also:
The command reference for details.
• Definitions
– Chains
– Tables
– Rules
– Groups
– Connection tracking
• Stateless filtering
• Stateful filtering
Definitions
Chains
A chain is a list of rules. It is responsible for determining how an incoming, outgoing or forwarded packet should
be processed by the filtering module.
There are several default chains, associated to hooks in the routing stack:
• prerouting is called as soon as packets are received
• input is called for locally delivered packets
• forward is called when the packet is being routed
• output is called for locally generated packets
• postrouting is called when the packets are about to be sent
If a packet entering a default chain does not match any rule, it will be processed by the chain’s default policy.
User-chains can be defined as well, and called from the default chains.
Tables
Several tables are available. Each table has a specific purpose and defines some specific default chains. The chains
cross the different tables in a predefined priority.
The raw table is mainly used to exempt packets from connection tracking. Only the prerouting and output chains
are available in this table. It is always crossed first (before connection tracking).
The mangle table is the packet alteration table. All the default chains are available in this table. It is called before
filter, and after connection tracking.
The filter table is the default table. Only the input, forward and output chains are available in this table. This
is where packets are actually filtered. It is called after the mangle table.
Rules
A rule is defined by a sequence number, a packet selector and an action. It specifies what action to apply to packets
that match the selector. Packets are compared to each rule until it matches one rule selector. The action is then
applied to the packet and look up into the chain is stopped. If a packet does not match any of the rules in a default
chain, it is applied the default policy.
Groups
A group is a set of IP addresses or networks. The rule packet selector can reference a group as source or destination.
Connection tracking
To perform stateful filtering or NAT, the device can monitor the connections and maintain their state, using the
connection tracking module. Each connection is stored in a conntrack, defined by its source and destination
address, its source and destination port in the two directions (named origin and reply), and the state of the connection.
Here is an example of a conntrack defining an SSH connection from 10.0.2.2 port 58242 to 10.0.2.15 port 22.
The connection is established, meaning that packets were seen in the two directions.
The connection tracking module is called in prerouting and output chains, after the raw table. It is enabled for
all packets, unless disabled using the notrack action.
Stateless filtering
vrouter running chain outside# rule 2 source group trusted description "allow trusted"␣
˓→action accept
vrouter running chain outside# rule 3 protocol tcp destination port 22 description
˓→"allow ssh" action accept
vrouter running chain outside# rule 4 protocol tcp destination port 830 description
˓→"allow netconf" action accept
Note: This configuration is partial, and only shown as an example. It should not be used as is in production.
..
forward
bytes 0
policy accept
packets 0
..
output
bytes 811590
policy accept
packets 2400
..
chain outside
bytes 0
packets 0
rule 1 description "allow 1.1.1.1" counters bytes 0 packets 0 source address 1.
˓→1.1.1/32 action accept
..
..
The same configuration can be made using this NETCONF XML configuration:
Stateful filtering
Using the connection tracking, it is possible to match packets that are part of an existing connection.
The following configuration adds to the previous stateless configuration some stateful filtering rules, by allowing
packets from an existing connection, but denying packets for a new one.
vrouter running chain outside# rule 6 conntrack state new description "deny new␣
˓→connections" action drop
Certificates
An X.509 certificate is a digital document that securely associates cryptographic key pairs with identities such as
individuals, organizations, machines or services. It is used by public key infrastructures (PKI) to verify that a public
key belongs to the identity contained within the certificate.
An X.509 certificate contains information about the identity to which a certificate is issued and the identity that
issued it. Common issuance fields included in X.509 certificate are:
• Version: X.509 version applies to the certificate.
• Serial Number: a serial number that distinguishes a certificate from other certificates.
• Algorithm information: the algorithm used by the issuer to sign the certificate.
• Issuer Distinguished Name: the name of the entity issuing the certificate.
• Validity: period in which the certificate can be trusted (start/end date).
• Subject Distinguished Name: the name of the identity the certificate is issued to.
• Subject Public Key Information: the public key associated with the identity.
• Extensions (optional): other useful fields such Subject Alternative Name(s) and Key Usage.
The following sections explain various supported operations used to manage certificates in the Turbo Router’s local
database using nc-cli commands.
• Import a Certificate
• Export a certificate
• Add a certificate
• Delete a certificate
• Show certificate list
• Show certificate detail
• Show certificate private key
• Enroll/Update Certificates using CMP
– Certificate enroll
– Certificate update
Import a Certificate
Use the command cmd certificate import name <cert-name> url <remote-url> to import a root CA or
an intermediate CA to the local database. As an example we use this command to import two CAs named rootca
and 6WIND:
vrouter running config# cmd certificate import name rootca url http://10.16.0.190:8999/
˓→rootca.pem
OK.
..
We can use also the previous command to import a user certificate user01 with its private key:
vrouter running config# cmd certificate import name user01 url http://10.16.0.190:8999/
˓→user01_cert.pem private-key-url http://10.16.0.190:8999/user01_key.pem
OK.
..
Use the show certificate list command to show the imported certificates:
See also:
The Import certificate command reference for details.
Export a certificate
Use command cmd certificate export name <cert-name> url <remote-url> to export a certificate
stored in the local database to a remote location:
See also:
The Export certificate command reference for details.
Add a certificate
Use this command cmd certificate add <cert-name> data <pem-format-input>, to add certificate as a
string input (the pem encoded format):
See also:
The Add certificate command reference for details.
Delete a certificate
Use the command cmd certificate delete name <cert-name> to delete a certificate from the local database.
In this example we delete the certificate user01 stored before:
See also:
The Delete certificate command reference for details.
Use command show certificate list is used to list certificates stored in the local database, these certificates
might be imported using the ‘cmd certificate import’ or by another service:
See also:
The Show certificate list command reference for details.
Use show certificate name <cert-name> to show certificate content in ASCII format:
Include base64 option to print the PEM format of the certificate, show certificate name <cert-name>
base64:
See also:
The Show certificate detail command reference for details.
Use show certificate key name <cert-name> to show the private key of the given certificate in PEM format:
See also:
The Show certificate key command reference for details.
The Certificate Management Protocol (CMP) is an Internet protocol standardized by the IETF used for obtaining
X.509 digital certificates in a public key infrastructure (PKI). HTTP protocol is mainly used to transport CMP
messages. The common exchanged requests are ‘Initialization Request’, ‘Key Update Request’ and ‘Revocation
Request’.
Certificate enroll
To issue a new end user certificate from a given PKI (Public Key Infrastructure), the rpc command cmd
certificate cmp enroll can be used. In addition to the certificate subject name, optional Subject
Alternative Name(s) may be specified with the san argument:
vrouter running config# cmd certificate cmp enroll ca-name 6WIND name userEE url http:/
˓→/pki_host:port/cmp/client secret password subject /CN=test/O=it san *test.com,10.2.
˓→3.5
OK.
vrouter running config# show certificate name userEE
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
40:5a:ae:72:ab:ef:ce:06:02:e2:d5:e2:57:07:0d:ed:
81:8e:06:de
Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
(continues on next page)
The CA certificate must have been imported beforehand. Its name is specified via the ca-name argument.
See also:
The the cmp enroll command reference for details.
Certificate update
Updating a previously enrolled certificate can be done through the rpc cmd cmp certificate update. Note that
a new private key will be used and the old certificate is overwritten. A new private key length or different Subject
alternative Name(s) can be used:
vrouter running config# cmd certificate cmp update ca-name 6WIND name userEE url http:/
˓→/pki_host:port/cmp/client private-key-length 4096 san new.com,172.0.1.2
OK.
vrouter running config# show certificate name testEE
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
79:80:c5:ac:71:0a:b5:39:1b:fd:df:82:ac:49:e5:95:
0a:20:19:74
Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
Issuer: "CN=6WIND"
Validity:
(continues on next page)
The CA certificate must have been imported beforehand. Its name is specified via the ca-name argument.
See also:
The The cmp update command reference for details.
High-availability Groups
A high-availability group is used to list a set of services whose state (master or backup) switch together.
The state of the high-availability group can be defined in the configuration, or it can be driven by another service
(for instance, vrrp) which declares itself as a controller for this high-availability group. There is one and only one
controller for a group.
Some services like ike can subscribe to this high-availability group to be notified when the state of the group changes.
A group can have several subscribers.
To create a high-availability group called my-ha-group, statically controlled by configuration:
The state command defines the administrative state of this group. If it is omitted, the state has to be driven by
another service.
Let’s fetch the state afer committing this configuration:
The same configuration can be made using this NETCONF XML configuration:
High Availability neighbor enables synchronizing dynamic ARP/NDP entries between two HA (High Availability)
nodes in master/backup mode.
If the HA state is switched between the two nodes, the new master node will be able to take over dataplane traffic
and synchonize its dynamic ARP/NDP entries with the backup node.
Caution: Static ARP/NDP entries (i.e. in the neighbor permanent state) are not synchronized. They must be
configured on both nodes.
The HA state of a node can be statically configured using CLI/netconf or dynamically using the VRRP service.
ha1
(node-id 1)
.1
eth3
10.150.0.0/24
eth3 GW
.2
ha2
(node-id 2)
In this example, ARP/NDP entries learned by the ha1 (the master) will be sent to ha2 (the backup) through eth3.
HA neighbor parameters are configured in the ha-neighbor context:
• node-id is a unique identifier for this node in the HA cluster. It ranges from 1 to 15.
• interface is the network interface on which synchronization packets are exchanged
• local-address is the IPv4 or IPv6 addresses of the other HA node.
• listen-ha-group is the high-availability group that controls the activity state of this HA node. See High-
availability Groups for more information.
Display ha1 HA neighbor state:
High Availability conntrack enables synchronizing conntracks between two or more HA nodes in master/backup
mode.
It maintains an internal cache (reflecting the conntracks in the dataplane) and an external cache (conntracks adver-
tised by the other HA node). The content of the caches is used only when the system changes HA states:
• when switching to master, these 4 steps are executed:
– commit the external cache into the dataplane
– flush the internal and the external caches
– resynchronize the internal cache to the dataplane
– then send a bulk update to backups
• when switching to backup:
– shorten dataplane conntrack timers to remove the zombie entries
ha1
(node-id 1)
.1
eth3
10.150.0.0/24
eth3 GW
.2
ha2
(node-id 2)
In this example, conntracks are synchronized from ha1 to ha2 external table as time goes along, and configured in
ha2’s dataplane when ha2 becomes master.
HA conntrack parameters are configured per VRF in the ha-conntrack context:
Note: Protocols and IP addresses events can also be filtered respectively through protocol-list and
address-list options. This filter can be an include or exclude logic depending on the accept true|false
option value. See the HA conntrack command reference for details.
High Availability Internet Key Exchange (HA IKE) is an IKE extension that enables to perform stateful synchro-
nization of IKE between two HA nodes in active/backup mode.
HA IKE may be configured between two nodes forming an HA cluster: the IKE internal states (IKE SAs and CHILD
SAs) and IPsec SAs sequence numbers are synchronized from the active node to the backup node.
If the HA state is switched between the two nodes, the new master node will be able to take over the IKE negotiations
and IPsec dataplane traffic.
• Overview
• Use case: HA IKE cluster with VRRP
– ha1 CLI configuration
– ha2 CLI configuration
• Advanced options
– Sequence number synchronization parameters
– HA-compatible virtual IP pools
Overview
The HA state of a node can be statically configured using CLI/netconf or dynamically using the VRRP service.
IPse
c tu
nne
l
ha1
(node-id 1)
.1
eth3
10.150.0.0/24
eth3 SecGW
.2
ha2
(node-id 2)
• node-id is a unique identifier for this node in the HA cluster. It ranges from 1 to 15.
• interface is the network interface on which synchronization packets are exchanged
• local-address and remote-address are the IPv4 or IPv6 addresses of the two HA nodes.
• listen-ha-group is the high-availability group that controls the activity state of this HA node. See High-
availability Groups for more information.
Display HA IKE parameters:
On ha2, the node-id and interface must be adjusted and the local-address and remote-address swapped:
10.175.0.1/32
loopback0 IPse
c tu
nne
l
loopback0
10.175.0.1/32
In this use case, two devices ha1 and ha2 are configured as a redundant security gateway, performing IKE negotia-
tions with a remote security gateway SecGW.
The activity of each HA node is determined by the VRRP protocol (see VRRP command reference for details about
VRRP).
The two HA devices must be configured exactly the same, except for HA parameters (VRRP and HA IKE).
Note: The ha-group maintains the node high-availability state. It is controlled by the VRRP protocol (via the
notify-ha-group command) and monitored by HA IKE (via the listen-ha-group command). Only one con-
troller can be defined for an ha-group.
Configure routes:
Configure VRRP:
Configure IKE:
Configure HA IKE:
A similar configuration is used for ha2. The differences are the hostname, the physical interfaces addresses, VRRP
parameters and IKE HA parameters.
The IKE parameters (except HA ones) must be strictly identical.
Advanced options
IPsec SAs sequence numbers are regularly synchronized from the active node to the backup node. In case of switch
over, this enables the new master node to take over the IPsec dataplane processing with proper sequence numbers:
For an output SA, the output sequence number1 on the backup node should be greater or equal to the last sequence
number used by this SA on the master node. Otherwise, the remote IPsec peer is likely to drop some IPsec packets
sent by the new master until the sequence numbers comply to its replay window state.
For an input SA, the input sequence number2 on the backup node should be close to the highest sequence number
received on the master node. Otherwise the new master node is vulnerable to accepting replayed packets sent by an
attacker, because its replay window is too late.
The pace at which sequence number synchronization is performed is configurable in the ha seqnum-sync sub-
context:
• sync-period-time is the minimum time between two sequence number updates. An update is sent to the
backup node only if the sequence number changed since last update (default 10s, 0 disables the time-based
periodic update).
• sync-period-packets is the number of packets between two sequence number updates: if the input or
output sequence number of an IPsec SA changes of at least that number since last synchronization, then an
update is sent to the backup node (default 2, 0 disables the packet-based periodic update).
• oseq-shift is the optional IPsec SA output sequence number advance on the backup node: since sequence
number cannot be synchronized in real time, the output sequence numbers on the inactive node are always
late compared to the active mode. This value is added to the current output sequence number, in order to
reduce or eliminate the gap between the active and the inactive node. Ideally, it should be greater or equal to
the number of packets processed between two sequence number updates (default 65536).
1
i.e. the record of the highest SA sequence number of a sent packet protected with this SA
2
i.e. the record of the highest SA sequence number of a received packet protected with this SA
IKEv1 and IKEv2 enable to assign a virtual IP during an IKE negotiation, i.e. an IKE initiator may request an
additional IP address from the responder to use as inner IPsec tunnel address.
To proceed, the responder maintains a pool of virtual IPs (see IKE virtual IP pools).
If the IKE configuration makes use of virtual IP pools and HA IKE is enabled, then virtual IP leases must be
synchronized between the master and the backup node.
This requires using specific HA-synchronized virtual IP pools. These pools are less flexible than standard virtual
IP pools:
• address pools can only be defined as subnets, not ranges of addresses.
• no other parameters can be provided (such as a DNS, NetBIOS or DHCP server address).
• there is no state information about these pools
When enabling HA IKE, be careful of using a virtual pool defined in the ha context, because virtual pools defined
directly in the ike context are not synchronized between the master and backup node.
Define the pool:
Use it in a vpn:
See also:
The IKE command reference for details.
VRRP
Virtual Router Redundancy Protocol provides a way, for a set of routers, to control a virtual address and MAC
address, including automatic fail-over mechanism. Such an address may be used by hosts for some service access,
e.g. as static default gateway. The gain from using VRRP is a higher availability of the service without requiring
automatic reconfiguration of end hosts.
The VRRP protocol is defined in RFC 3768 (VRRP v2) and RFC 5798 (VRRP v3). The major differences between
VRRP v2 and VRRP v3 are the support of IPv6 and the support of low failover timer values which are only available
in the latter.
• Overview
• VRRP states
• VRRP interface settings
– Version
– Link interface
– Priority
– Init state
– Virtual router identifier
– Preemption
– Advertisement interval and preempt delay
– Gratuitous ARP delay
– Trackers
∗ IP address tracker
∗ Fast path status tracker
• Synchronization of instance states
– Failover groups configuration
– Track a group in a different vrf
– High-availability group notification
• High-availability split-brain situation
– Possible causes
– Consequences
– Solutions
∗ Change the topology
∗ Use a HA link
∗ Configure a startup delay
• VRRP settings for virtual environments
– Virtual MAC address
– Unicast peering
Overview
rtr1 rtr2
(Master) (Backup)
(VRID=5) (VRID=5)
eth1
H1 H2 H3 H4
Note: The link interface eth1 must be up and have an IP address configured.
The same configuration can be made using this NETCONF XML configuration:
<config xmlns="urn:6wind:vrouter">
<vrf>
<name>main</name>
<vrrp xmlns="urn:6wind:vrouter/vrrp">
<enabled>true</enabled>
<router-id>vrrp_router1</router-id>
<traps-enabled>false</traps-enabled>
</vrrp>
<interface xmlns="urn:6wind:vrouter/interface">
<vrrp xmlns="urn:6wind:vrouter/vrrp">
<name>vrrp51</name>
<enabled>true</enabled>
<init-state>backup</init-state>
<version>2</version>
<garp-delay>5</garp-delay>
<use-vmac>true</use-vmac>
<vmac-xmit-base>false</vmac-xmit-base>
<priority>200</priority>
<preempt>true</preempt>
<preempt-delay>0</preempt-delay>
<advertisement-interval>1000</advertisement-interval>
<authentication/>
<link-interface>eth1</link-interface>
<vrid>5</vrid>
<virtual-address>
<ip>10.22.0.1/24</ip>
</virtual-address>
</vrrp>
</interface>
</vrf>
</config>
vrouter running config# show config xml absolute vrf main vrrp
vrouter running config# show config xml absolute vrf main interface vrrp vrrp51
The configuration on the second router (backup) is similar, except the priority which should be lower than 200, and
the router-id which is set to vrrp_router2.
See also:
The command reference for details.
VRRP states
Version
version defines whether version 2 or 3 is used. Using version 3 allows faster failovers thanks to low timer values
and is recommended. See information about timers.
Caution: Setting IPv6 VRRP does not imply version 3. Turbo Router allows using IPv6 on VRRP version 2
although its support is deprecated.
Link interface
link-interface is the interface the VRRP instance is bound to. VRRP announcements are send from the IP
address of the link interface.
On an IPv6 VRRP instances, setting an IPv6 global address on the link interface is not mandatory because the IPv6
link-local address is sufficient.
Priority
The router with the highest priority will be elected master. The other one will remain backup.
We recommend to set a priority higher than the default value of 100 on one of the routers. Otherwise, on VRRP
version 2, having the same priority on both routers makes the router with the highest IP to be the master. On VRRP
version 3, the first router that appears on the network is elected as master.
Init state
init-state is a deprecated option that defines on which state the VRRP instance is initialized before the election
occurs, at startup and after a link goes to up state.
We recommend to let it at the default value of backup. If you want the router election to converge quickly, use
lower timers values.
The virtual router identifier vrid identifies a set of VRRP routers on a LAN. Several groups of VRRP routers can
coexist on the same broadcast domain as long as they all have a different vrid. For a given VRRP instance, the
vrid value must be identical on both routers. We recommend to set the same vrid on all instances within a HA
group of routers.
Caution: A vMAC (virtual MAC address) is built from the vrid value. Setting the same vrid value on several
groups of routers within the same broadcast domain would mean that the same vMAC is re-used at different
places. See Virtual MAC address.
Preemption
“To preempt” in the context of VRRP means to take over as master when the other router is master. The condition
for a router to preempt is basically to receive three times a lower priority announcement than its own.
The preemption feature is enabled by default and should remain enabled. For some special cases, it can be configured
using the preempt option:
See also:
The timers section gives information about the preemption convergence time.
advertisement-interval specifies the rate at which VRRP advertisements are sent. The configured values in
our CLI are in milliseconds.
Note: We strongly recommend to put the same value of advertisement-interval on both routers.
The master router sends every advertisement-interval a VRRP announcement on all instances. If it receives
a higher priority advertisement, it will switch to backup state after Master_Down_Interval.
The backup router sends no advertisement and it listens for advertisements from the other router.
• If it stops receiving advertisements, it considers that the master router might not be available anymore. It
waits for Master_Down_Interval for confirmation before switching to master state.
• If it receives an advertisement from the master router with a priority of 0, it considers that the master is faulty.
Similarly, it waits for Master_Down_Interval before switching to master state.
• If it receives an advertisement from the master router with a non-zero priority less than its own, it
considers that it should become the master router unless the preempt option is disabled. It waits for
Master_Down_Interval + preempt-delay before switching to master state. Default preempt-delay
is 0.
Note: preempt-delay does not apply if no advertisements are received when the link interface goes up.
Note: A preempt-delay value of 0 will not allow to preempt immediately, as Master_Down_Interval always
applies.
For example, if you need a failover time of 1 second, you can set:
Note: We recommend to use the same version, priority and timers on all VRRP instances within a router.
A gratuitous ARP is a special type of ARP packets that broadcasts without being requested an IP address resolution
to all hosts.
After transiting to master state, the router sends immediately several gratuitous ARP for each virtual address it
owns. Then, it waits for garp-delay before sending a second set of gratuitous ARP. This mechanism is actually
useful when the use-vmac option is disabled. When use-vmac is enabled (which is the default mode), the virtual
address resolution is always the same.
Note: Since it is a delay, reducing garp-delay will not speed up the failover. Its default value of 5 seconds should
not be changed.
Trackers
A tracker is used to set a VRRP instance into fault state when a tracking condition fails.
Caution: The up state and the presence of an IP address on the link interface are tracked by the VRRP instance
by default. When configuring a new VRRP instance in a failover group, make sure the link interface matches
these conditions. Otherwise, the HA group would go to fault state.
IP address tracker
A VRRP instance can track IP addresses. When a tracked address is unreachable, the instance goes to fault state.
To enable IP tracking:
See also:
The Tracker guide.
A VRRP instance can track the fast path status. If the fast path status does not match the configuration, the instance
goes to fault state. This occurs for instance when the fast path is starting or stopping, or if the fast path configuration
cannot be applied.
To enable fast path tracking:
This section explains how to configure VRRP on Turbo Router to synchronize the instance states within a VRF and
to work with the HA features such as HA conntrack and HA IKE .
A VRRP group is used to group VRRP interfaces from a given VRF that should share the same VRRP state.
The VRRP instances of a group run VRRP independently but share their state with the group. This way, all group
instances are in a consistent state and follow the following rules:
• If an instance goes to fault state, all the instances of its group will go to fault state as well.
• If any backup instance stops receiving announcements from the master router, the group will not go to the
master state unless all instances stop receiving announcements as well.
Caution: All the instances of a group must have the same priority. If they don’t, it will lead to constant
re-elections.
A VRRP group can track a group in another VRF, and apply a penalty to its own priority when the tracked group
goes to fault state.
This feature is used to ensure that, when two VRRP groups are configured in two different vrfs, both groups will
share the same fate.
The priority penalty should be calculated so that (master priority - penalty) < backup priority. Its
value has to be between 1 and 253, and is set to 253 by default. We recommend to keep the default value.
Caution: A configuration where one side has a priority of 254 and the other has a priority of 1 is not compatible
with this feature.
(VRID=6) (VRID=6)
(Master) (Backup)
prio 200 prio 100
vrf wan vrf wan
eth1
When the vrrp51 instance goes to fault on rtr1, the main vrf VRRP group my-group will go fault as well.
The VRRP instance in the main vrf on rtr2 will take over.
Thanks to the specified track-group group my-group vrf main command, the wan vrf VRRP group
my-group will have its priority of 200 reduced by 253, to the minimum value of 1. This value is lower than
the priority of the corresponding group on rtr2 (100). The VRRP instance in the wan vrf on rtr2 will take over.
Note: The vrf option accepts a all keyword. When vrf all is set, all the groups with the specified name in all
the vrfs (except the current one) will be tracked. The priority will be reduced by (number of faulty instance)
* (priority-penalty value). The minimum reduced priority is 1.
A VRRP group or VRRP instance can control the state of a high-availability group: when the VRRP state changes,
all the subscribers of the high-availability group are notified and can act accordingly.
The following example configures a VRRP instance as a controller for the high-availability group my-ha-group.
See also:
High-availability Groups for details.
Other services support high-availability can declare themselves as subscribers for this group.
A HA split-brain situation is a situation where both VRRP routers are in master state because a network outage
stops them from exchanging VRRP announcements between them.
Note: If you are not using HA conntrack or HA IKE , HA split-brain situation will not affect Turbo Router packet
processing. You can skip reading until the Startup delay section. Configuring vrrp-startup-delay has some
other benefits.
Possible causes
The cause of a broken communication between instances that causes a double master HA topology are the following:
• An interface may only receive traffic several seconds after the link comes up. The common causes are:
– a switch with STP (Spanning Tree Protocol) configured in non-edge (or portfast) mode,
– a LACP bonding coming up before its slaves interface are in LACP collecting state.
Since all instance interfaces are likely to face this issue at the same time at system startup, we recommend to
use a vrrp-startup-delay of 30 seconds. To avoid an issue where all the instance interfaces would flap at the
same time, it is advised as well to avoid the VRRP instance to rely on a unique logical interface or on several
interfaces linked to the same switch. Consider adding a HA link if all the instances relies on one switch.
• There is a defect on the network on a single point of failure between all the instances. See topology solutions.
Consequences
The consequences of a HA split-brain depend on the services the Turbo Router is running:
• If the nodes are using HA conntrack or HA IKE , the sequence numbers of packets are synchronized from the
master to the backup or fault router. The data plane traffic is only accepted and forwarded on the master router.
If the routers are all in master state, they will both forward a part of the traffic and increment their sequence
numbers independently. They will not synchronize their sequence numbers one with another because a master
router cannot accept synchronized information by design. As soon as the unlegitimate master router returns
to the backup state, the master router will receive its traffic. However the master’s sequence number table is
outdated, so this traffic will be dropped.
• Without HA conntrack and HA IKE , having several master routers in the HA topology does not affect their
packet processing because the routers forward packets without checking any sequence number. The split-
brain situation is the result of a fault on the network that might lead to a traffic outage but that is not caused
by the routers.
Solutions
We recommend to use different physical links and switches for the instances of a group to avoid this the split-brain
situation.
Here is a network topology with two routers running Turbo Router. Each router has a HA group containing instances
on link interfaces bond0.2 and bond0.3 that are respectively vlan 2 and 3 sub-interfaces of bond0.
rtr1 rtr2
(Master) (Backup)
bond0.2
bond0.3
Switch1 Switch2
H1 H2
The link between switch1 and switch2 is now broken. The communication is totally broken between routers. As a
result, both routers are master.
rtr1 rtr2
(Master) (Backup)
bond0.2
bond0.3
Switch1 X Switch2
A solution to avoid the problem is to dispatch the VRRP instances on several switching domains to ensure that
VRRP announcements for different VRRP instances take a different path. It requires adding some switches.
Switch3 Switch4
bond0.3
rtr1 rtr2
(Master) (Backup)
bond0.2
Switch1 Switch2
Use a HA link
The HA link is a dedicated link between two routers that is used to exchange VRRP announcements on an addi-
tional path. In case of failure on the network, when the main instances are prevented from exchanging their VRRP
announcements, VRRP announcements are still exchanged on this link. The backup router knows that the other
router is still up and does not switch to master state. Without the HA link, this condition would have lead to have
two master routers.
The following diagram shows a HA link implemented on eth0. When communication is broken between bond0
interfaces of rtr1 and rtr2, VRRP announcements are still exchanged on the HA link between rtr1 eth0 and rtr2 eth0.
bond0.2
bond0.3
Switch1 Switch2
To check the availability of the other router on the HA link, a VRRP instance must be bound to the link and added
to the same VRRP group as the other instances.
Like any other VRRP instance, a HA link VRRP instance has an associated virtual address. It must not be used for
receiving data plane traffic.
Here are some recommendations to make the HA link reliable enough:
• To be reliable enough, the HA link must not use a same path as the main interfaces.
– If Turbo Router is running on a bare-metal server, it should be a dedicated physical link between the
servers.
– If Turbo Router is running on a virtual machine, the link should take a different physical path.
• the HA link must be bound to a physical interface, which excludes for example a bonding or a virtual interface.
• the HA interface must not be a fast path port.
• the HA link should not go through a switch if Turbo Router is running on a bare-metal server.
Also, the HA link VRRP instance:
• must use IPv4, even if the main instances are all of IPv6 type.
• must use the same VRRP version as the other instances.
We recommend to use the HA link to synchronize stateful information between the routers. local-address and
remote-address would refer to the HA link ip addresses. Refer to HA neighbor, HA conntrack and HA IKE for
details.
The track-link-interface option must be disabled. It prevents the VRRP HA link instance (and the instances
of its group) from switching to fault state in case the HA link goes down.
vrrp-startup-delay is a delay that is applied at system startup before starting to listen for VRRP advertisement.
This way, no VRRP election happens before the router is ready.
We recommend to set a 30s vrrp-startup-delay value.
Note: vrrp-startup-delay only applies at system startup but not after a link state is flapping.
Note: Before the vrrp-startup-delay timer expires, the initial state set by the init-state leaf in the VRRP
interface configuration applies. Make sure to let it at the default backup value.
Using Turbo Router on VMs with VRRP may require to adjust the following settings:
• Virtual MAC address
• Unicast peering
Note: We recommend to keep default value of these settings if Turbo Router is running on bare-metal servers.
By default, a vMAC is associated to the virtual IP address in the host ARP and NDP neighbor table. It is also used
as a source MAC address for VRRP announcements.
Some virtual network switches (eg. VMware vSwitch) are unable to deal with vMAC because they only know MAC
addresses that the hypervisor has assigned to the VMs. In this case, use-vmac must be set to false so that the MAC
address of the link interface is used instead.
Caution: When disabling use-vmac, make sure the ARP or NDP protocols are correctly propagated. Other-
wise, some hosts might not be informed of the new master MAC address after a failover. We recommend to test
some manual failovers.
• The storm control feature, if it is enabled on switches, may affect the flooding of ARP broadcasts.
• The reception of gratuitous ARP may be disabled on hosts for security reasons.
Note: Since IPv4 and IPv6 vMAC formats are different, it is not possible to define IPv4 and IPv6 virtual adresses
on the same VRRP instance.
Note: vmac-xmit-based setting is only effective if use-vmac is true. Its default value is false. If true, the MAC
address of the link interface is used for sending VRRP announcements. It should be left configured to its default
value.
Unicast peering
Note: When using values for advertisement-interval lower than 1s and unicast peering, we recommend to
use static ARP / NDP entries to avoid latency induced by ARP / NDP requests.
3.1.11 Monitoring
KPIs
6WIND KPI (Key Performance Indicator) monitoring provides the ability to monitor and export Turbo Router KPIs
to an InfluxDB (https://www.influxdata.com/time-series-platform/influxdb/) time-series database, which can then
be integrated with an analytics frontend, such as Grafana (https://grafana.com/). An example of InfluxDB/Grafana
setup is described on 6WIND’s github (https://github.com/6WIND/supervision-grafana).
Configuring KPIs requires to:
• enable and configure the KPIs daemon to specify which KPIs to collect
• enable and configure the Telegraf (https://www.influxdata.com/time-series-platform/telegraf) agent to export
the specified KPIs to a remote InfluxDB database
To configure the KPIs daemon with everything it can collect, and the Telegraf agent to send data to the InfluxDB
server located at http://1.1.1.1:8086, in the test database, do:
Note: To connect Telegraf to a secured InfluxDB instance (https URL) that is using a self-signed certificate, you
must enable insecure-skip-verify.
By default, the network interfaces that are exported to the InfluxDB server are the fast path ports. This can be
changed be specifying the list of interfaces:
Note: If a list of interfaces is specified, the default will not apply anymore and the fast path ports will have to be
added manually to the kpi interface list to be exported.
The same configuration can be made using this NETCONF XML configuration:
sFlow
sFlow is a technology for monitoring traffic in data networks containing switches and routers. It consists of an sFlow
Agent running on the router, and a central sFlow Collector.
The sFlow Agent uses sampling technology to capture traffic statistics from the device it is monitoring. sFlow
Datagrams are used to immediately forward the sampled traffic statistics to an sFlow Collector for analysis.
More information is available in RFC 3176 and sflow.org.
To configure sFlow you need to specify the collector endpoint and which interfaces will be polled.
For each interface, you can tune the sampling interval or let the system choose a value according to the speed of
interface.
Configuration example:
The same configuration can be made using this NETCONF XML configuration:
See also:
The command reference for details.
SNMP
Overview
Simple Network Management Protocol (SNMP) is an Internet Standard protocol for collecting and organizing in-
formation about managed devices on IP networks and for modifying that information to change device behavior. It
is specified in RFC 1157 (https://tools.ietf.org/html/rfc1157.html).
Configuration example:
The same configuration can be made using this NETCONF XML request:
vrouter running config# show config xml absolute vrf main snmp
<config xmlns="urn:6wind:vrouter">
<vrf>
<name>main</name>
<snmp xmlns="urn:6wind:vrouter/snmp">
<static-info>
<contact>[email protected]</contact>
<location>Copacabana, Rio de Janeiro</location>
</static-info>
<traps>
<destination>
<host>10.0.0.200</host>
<notification-type>TRAP2</notification-type>
<community>public</community>
<port>162</port>
</destination>
<process-check>
<frequency>2s</frequency>
<enabled>true</enabled>
</process-check>
<link-status-check>
<frequency>60s</frequency>
<enabled>true</enabled>
</link-status-check>
<load-check>
<threshold>95</threshold>
<enabled>true</enabled>
</load-check>
</traps>
<community>
<name>public</name>
<authorization>read-only</authorization>
<source>10.0.0.0/24</source>
</community>
</snmp>
</vrf>
</config>
Configuration
Monitoring different VRFs relies on a master VRF that provides access to the management network. Slave VRFs
(that don’t have access to the management network) are linked to the master VRF.
To link a slave VRF:
• add it to the list of monitored VRFs in the SNMP context of the master VRF,
• configure an identifier for the slave VRF, which will act as:
– a community for SNMP v1, v2c and traps,
– a context for SNMP v3.
Here is a configuration example to link VRF vrf1 with identifier vrf1 to VRF main:
Note:
• When a VRF is linked to another one, its SNMP context must be disabled.
• For SNMP v3, both user and identifier authorizations are applied. Therefore, the most restrictive one is taken
into account (in the example above: read-only).
The same configuration can be made using this NETCONF XML request:
vrouter running config# show config xml absolute vrf slave snmp
<config xmlns="urn:6wind:vrouter">
<vrf>
<name>slave</name>
<snmp xmlns="urn:6wind:vrouter/snmp">
<enabled>false</enabled>
<static-info/>
<access-control/>
<traps/>
</snmp>
</vrf>
</config>
vrouter running config# show config xml absolute vrf main snmp
<config xmlns="urn:6wind:vrouter">
<vrf>
<name>main</name>
<snmp xmlns="urn:6wind:vrouter/snmp">
<enabled>true</enabled>
<static-info>
<contact>[email protected]</contact>
<location>Santa Barbara</location>
</static-info>
<access-control>
<user>
<name>alice</name>
<auth-password>Password</auth-password>
<auth-method>sha</auth-method>
<priv-protocol>aes</priv-protocol>
</user>
<group>
<name>admin</name>
<user>alice</user>
<authorization>read-write</authorization>
<security-level>auth</security-level>
</group>
</access-control>
<traps>
<destination>
<host>10.0.0.200</host>
<notification-type>TRAP2</notification-type>
<community>public</community>
<port>162</port>
<protocol>udp</protocol>
</destination>
(continues on next page)
SNMP requests
1
2
3
1
2
eth_out
SNMP traps
The SNMP traps from the different VRFs can be distinguished thanks to the community name.
Here is a snmptrapd configuration example, using the public community for trap events from the main VRF and
the vrf1 community for the vrf1 VRF.
/etc/snmp/snmptrapd.conf:
Start the snmptrapd daemon and log the trap events into /tmp/snmptrapd.log.
Here are some log examples when interfaces get down in the vrf1 and main VRFs.
# cat /tmp/snmptrapd.log
2019-12-10 10:38:44 TRAP2, SNMP v2c, community vrf1 <UNKNOWN> [UDP: [10.0.0.2]:42616->
˓→[10.0.0.200]:162]:
2019-12-10 10:41:04 TRAP2, SNMP v2c, community public <UNKNOWN> [UDP: [10.0.0.2]:51157-
˓→>[10.0.0.200]:162]:
See also:
The SNMP command reference for details.
Supported mibs
Interface Alias
Supported MIBs:
HA VRRP
Supported MIBs:
IPsec/IKE
• IPsec monitoring
• IKE monitoring
Supported MIB:
3.1.12 Services
LLDP
802.1AB Link-Layer Discovery Protocol (LLDP) provides information to devices that are directly adjacent to them
on the local LAN.
LLDP sends information periodically and at link status change time to indicate the configuration parameters of the
device.
This protocol allows the router to:
• advertise its identity and capabilities on the local network
• receive the same information from a physically adjacent layer 2 peer
LLDP uses Ethernet as its transport protocol, the Ethernet type for LLDP is 0x88CC.
User can control which information is being sent from the router:
• description of the device
• system name
• the IP address to reach the device on LLDP port
User has to define the list of interfaces on which LLDP is active.
The chassis ID will be set automatically.
To configure LLDP to start on the eth0 interface, reachable on the 10.0.0.1 address, with name vrouter and
description Router, do:
The same configuration can be made using this NETCONF XML configuration:
See also:
The command reference for details.
DHCP server
• Overview
• Subnet configuration
– Address range management
– Subnet interface
– Default gateway
– Host management and static address assignment
• DHCP options
– Domain name
– DNS server address
– NetBIOS name server
– NetBIOS node type
– Lease lengths management
• Configuration example
• Displaying DHCP server leases
Overview
A DHCP server is typically used to configure the IPv4 addresses of the hosts connected to its different LAN subnets,
upon their request.
It needs at least one IPv4 subnet on which one interface is configured and a range of addresses to be allocated to
DHCP clients.
You can configure the DHCP server in the dhcp server context:
Subnet configuration
Note: The A1.B1.C1.D1 – A1.B2.C2.D2 address range must be included in the configured subnet.
Subnet interface
Note:
• The interface must be able to receive broadcast packets.
• If this option is not set, the DHCP server will use the first interface that has an IP address corresponding to
the subnet.
Default gateway
• Specify the list of default gateways to provide to DHCP clients, by order of preference:
You can reserve a specific IPv4 address for a given host (mainly servers, whose IPv4 address is supposed to be
stable).
• Define a fixed IPv4 address for a host:
Note: Like ranges, the host IP address must be included in the configured subnet.
Warning: Static address assignments are not written in the machine leases, only the dynamic addresses are.
As a consequence, they are neither displayed in show dhcp-server nor in show state.
DHCP options
DHCP options can be specified in the root DHCP server context or overwritten per subnet.
Domain name
• Specify the NetBIOS node as broadcast mode and ignore WINS server address:
• Specify the NetBIOS node as always point-to-point and never broadcast request:
• Specify the NetBIOS node as try broadcast first if it fails to use WINS address:
• Specify the NetBIOS node as hybrid mode (starts with WINS address, then use broadcast request).
You can define the lease lengths for the DHCP clients.
• Define the default lease length:
Configuration example
The same configuration can be made using this NETCONF XML configuration:
Example
server-duid "\000\001\000\001#\310\357\010\336\355\001\320\220\235";
lease 10.100.0.3 {
starts 3 2019/01/09 17:42:36;
ends 3 2019/01/09 18:42:36;
cltt 3 2019/01/09 17:42:36;
binding state active;
next binding state free;
rewind binding state free;
hardware ethernet de:ed:01:e4:13:29;
}
DHCP relay
• Overview
• DHCP relay configuration
• DHCP configuration options
– Handle option
– Drop unmatched packets
– Maximum hop
– Maximum packet size
• Configuration example
Overview
The DHCP relay listens for DHCP queries and responses. When a query is received from a client, it is forwarded
to the specified DHCP server(s). When a reply is received from a server, it is forwarded to the client that made the
initial request.
The DHCP relay needs at least the IP address of a reachable DHCP server.
You can configure the DHCP relay parameters in the dhcp relay context.
• To relay the DHCP clients’ requests to DHCP servers, the DHCP relay must know the IPv4 address of a
DHCP server.
DHCP relay options can be specified in the root DHCP relay context or overwritten per dhcp-server.
Handle option
• Specify the handling policy of DHCPv4 packets that already contain relay agent options:
• Packets coming from upstream servers who contains relay agent information options that indicate they were
generated in response to a query that came via a different relay agent can be dropped:
Maximum hop
• Specify the maximum packet size to send to a DHCPv4 server. If a DHCP packet size surpasses this value it
will be forwarded without appending relay agent information:
Configuration example
The same configuration can be made using this NETCONF XML configuration:
DNS proxy
The same configuration can be made using this NETCONF XML configuration:
vrouter running config# show config xml absolute vrf main dns proxy
<config xmlns="urn:6wind:vrouter">
<vrf>
<name>main</name>
<dns xmlns="urn:6wind:vrouter/dns">
<proxy>
<enabled>true</enabled>
<forward>
<server>192.168.0.254</server>
</forward>
</proxy>
</dns>
</vrf>
</config>
See also:
The DNS proxy command reference and the DNS proxy clear-cache description for more details
DNS server
the DNS server also forwards queries for the hosts that are not configured locally to other servers. These servers are
the one configured in the DNS client configuration context.
This feature can be disabled with the use-system-servers configuration option:
The same configuration can be made using this NETCONF XML configuration:
vrouter running config# show config xml absolute vrf main dns-server
<config xmlns="urn:6wind:vrouter">
<vrf>
<name>main</name>
<dns-server xmlns="urn:6wind:vrouter/dns-server">
<enabled>true</enabled>
<use-system-servers>false</use-system-servers>
<record>
<name>example1.local</name>
<ip>10.0.0.2</ip>
<ip>2010::2</ip>
</record>
<record>
<name>example2</name>
<ip>12.0.0.2</ip>
</record>
<bind>eth0</bind>
</dns-server>
</vrf>
</config>
See also:
The DNS server command reference for details and the DNS system server command reference for details.
For debugging purpose, it’s possible to log queries received by the DNS server in the logging configuration context.
Be careful, with this option the DNS server can be very verbose:
Then you can use the show log command to see DNS server logs:
See also:
The show log command reference for details about log filtering.
It’s also possible to display statistics about the dns-server cache and queries with the show dns-server command:
See also:
The show dns-server command reference for details.
This section shows maximum sizes and numbers of various objects/features that can be configured on a Turbo Router.
Note: The limits and timings in this article are only indicative and may vary with hardware capacity. Here is the
reference platform that was used to produce the following numbers:
Important: The timings reported in the following table are given when configuring objects all at once: starting
with 0 configured objects and creating N new ones in a single <edit-config> or commit operation.
Configuring objects one by one (or incrementally) will be slower. Processing the difference between the current
configuration and the increment takes more time, the bigger the configuration is.
However, this limitation only becomes significant when reaching the upper limits. For reasonably small setups, you
can assume that the configuration time is linear with the number of configured objects.
Bridge 500 10 s 40 s 2 ,3
GRE 500 10 s 20 s ?
LAG 500 10 s 20 s ?
Loopback 500 10 s 20 s
Loopback 5000 60 s 250 s
Static routes 500 5s 2s
Static routes 5000 30 s 10 s
SVTI 500 10 s 30 s ?
VLAN 500 15 25 s ?
VXLAN 500 15 25 s ?
3.1.14 Troubleshooting
Troubleshooting Report
This command allows collecting various diagnostics of the system that can be provided to 6WIND support to help
debugging a problem.
The troubleshooting report includes the following information:
• Linux networking information
– ethtool on all known links
– interfaces, addresses, routes, neighbours and IPsec
– active network connections
– Netfilter tables, bridge
• system information
– topology
– processors hierarchy
– interrupts
– memory
– PCI peripherals
– DMI/MBIOS
– kernel version, logs, cmdline and loaded modules
– distribution
– services list
– logs
– processes list
– cpuset
– devices (/dev)
– IRQ affinity
– mounted partitions
• core dumps
1
VRFs are the most limiting feature. We do not recommend using more than 100 different ones on a single system.
2
Bridges are much slower to delete than other interfaces.
3
With all interfaces in the same VRF. Configuration will be slower when doing cross VRF tunnels.
4
Cross VRF interfaces are inherently limited by the number of VRFs.
OK.
vrouter> cmd troubleshooting-report export 2018-09-24_17-27-07.tgz url smtp://10.
˓→1.2.100/[email protected]
OK.
vrouter>
It is possible to export via multiple protocols: FTP, HTTP, TFTP, SCP, SFTP and SMTP (for the later, you will
need to specify an email address instead of a file path).
Flush all existing reports
See also:
The command reference for details.
System
Operating system
Product
Log
vrouter> show log [service <NAME>] [facility <NAME>] [level <LEVEL>] [vrf <NAME>]
Note: Each service has its own logging policy with regards to syslog facilities and severities. Refer to the services’
documentation for details.
Example:
-- Reboot --
Sep 25 11:51:58 vrouter kernel: #2
Sep 25 11:51:58 vrouter kernel: acpi PNP0A03:00: fail to add MMCONFIG information, can
˓→'t access extended PCI configuration space under this bridge.
Sep 25 11:51:58 vrouter kernel: ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11
See also:
• The command reference for details about the API.
• The Remote Log Filtering Configuration for details about syslog facilities and severities.
If you ever need to, you can have a specific port of a physical NIC on the router blink to visually identify it.
To do that, run the following command:
It means that your network adapter does not support LED control.
Tip: To display the list of all network-ports and their description, you may use the following command:
See also:
The command reference for more details.
Network
Ping
To send ICMP ECHO_REQUESTs to network hosts, you can use the following command:
Traffic Capture
These commands enable displaying, capturing, managing and exporting network traffic flowing through a given
network interface.
Display the network traffic flowing through a given network interface.
˓→length 48
˓→48
^C
3 packets captured
3 packets received by filter
(continues on next page)
Then a specific capture can be read or exported with the read and export commands:
See also:
• The command reference for details about the list command.
• The command reference for details about the delete command.
• The command reference for details about the flush command.
˓→length 48
˓→48
See also:
• The command reference for details about the read command.
• The command reference for details about the export command.
3.1.15 Automation
Cloud-init
Cloud-init handles early initialization of a cloud instance. More information is available at https://cloudinit.
readthedocs.io/en/latest/.
Cloud-init is enabled by default. It can be disabled after the first boot using the following configuration. At the next
reboot, cloud-init won’t be called.
The same configuration can be made using this NETCONF XML configuration:
See also:
The command reference for details.
Create a netconf.py file with this content. This script will use the following NETCONF operations:
• lock, unlock
• get
• edit-config
• validate
• commit
It will configure the hostname twice, and it will check whether the system state has properly changed after each
change.
#!/usr/bin/env python
# pip install xmltodict ncclient
import json
from ncclient import manager
import time
import xmltodict
state = """
(continues on next page)
conf = """
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<config xmlns="urn:6wind:vrouter">
<system xmlns="urn:6wind:vrouter/system">
<hostname>router</hostname>
</system>
</config>
</config>
"""
new_hostname_conf = """
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<config xmlns="urn:6wind:vrouter">
<system xmlns="urn:6wind:vrouter/system">
<hostname>myhostname</hostname>
</system>
</config>
</config>
"""
conn.lock()
check_config = conn.validate()
conn.commit()
conn.commit()
get_state = conn.get(state % '/vrouter:state/vrouter-system:system/hostname')
print "***************** hostname is now 'router' ****************"
print json.dumps(xmltodict.parse(get_state.data_xml), indent=2)
conn.unlock()
conn.close_session()
if __name__ == '__main__':
connect('<myip>', 'root', '<rootpass>')
Update the connect line to put the router IP, and the root password of the router, and launch the script. The following
output is displayed.
# python netconf.py
***************** hostname before configuration ****************
{
"data": {
"@xmlns": "urn:ietf:params:xml:ns:netconf:base:1.0",
"@xmlns:nc": "urn:ietf:params:xml:ns:netconf:base:1.0",
"state": {
"@xmlns": "urn:6wind:vrouter",
"system": {
"@xmlns": "urn:6wind:vrouter/system",
"hostname": "router"
}
}
}
}
***************** set hostname to 'myhostname' ****************
***************** hostname is now 'myhostname' ****************
{
"data": {
"@xmlns": "urn:ietf:params:xml:ns:netconf:base:1.0",
"@xmlns:nc": "urn:ietf:params:xml:ns:netconf:base:1.0",
"state": {
"@xmlns": "urn:6wind:vrouter",
"system": {
"@xmlns": "urn:6wind:vrouter/system",
(continues on next page)
Ansible supports configuring remote hosts using NETCONF (instead of the default SSH connection along with
Linux shell commands). This guide explains how to leverage Ansible to configure multiple Turbo Router instances.
Dependencies
This guide assumes that you have two (or more) Turbo Router instances that are booted and accessible on the network
(NETCONF uses TCP port 830). Also, for clarity purposes, these machines should be reachable with their respective
hostnames (thus, DNS or /etc/hosts must be configured accordingly).
To make sure it works, ansible version greater than 2.7.10 along with the ncclient and jxmlease python libraries
are required. Here is how to install this in a python virtualenv:
Configuration
Inventory
We need an “inventory” file that will reference all machines that we want to control with Ansible. Here we are using
the YAML inventory format which is more readable than the default INI format.
# /tmp/ansible-netconf/hosts.yml
---
vrouters:
vars:
ansible_connection: netconf
ansible_user: admin
ansible_ssh_pass: admin # using default admin user/password
ansible_python_interpreter: python
hosts:
vrouter1:
peer: vrouter2
ifname: int0
port: pci-b0s4
ipaddr: 172.16.200.1
vrouter2:
peer: vrouter1
ifname: ext0
port: pci-b0s4
ipaddr: 172.16.200.2
Playbook
We also need to write a playbook. Here is a basic example that configures the hostname depending on the Ansible
inventory name, and that configures a physical interface on both machines. Then, it runs the ping NETCONF RPC
to check that the IP addresses have been properly configured on both machines.
# /tmp/ansible-netconf/playbook.yml
---
- hosts: vrouters
gather_facts: false # facts gathering is not supported at the moment
tasks:
- name: fetch initial state
netconf_get:
display: json
filter: "{{lookup('file', 'filter.xml')}}"
register: state
- name: configure
netconf_config:
content: "{{lookup('template', 'config.xml')}}"
</system>
</config>
</config>
<address>
<ip>{{ipaddr}}/24</ip>
</address>
</ipv4>
</physical>
</interface>
</vrf>
</config>
</config>
See also:
The official Ansible documentation of the netconf_get (https://docs.ansible.com/ansible/latest/modules/netconf_get_module.html
netconf_config (https://docs.ansible.com/ansible/latest/modules/netconf_config_module.html) and netconf_rpc
(https://docs.ansible.com/ansible/latest/modules/netconf_rpc_module.html) modules.
Two additional XML files are referenced. They should be placed next to the playbook file itself.
Config
The structure of config.xml may be generated by running the following CLI commands:
Important: By default, the contents of the <config> XML node are merged with the current configuration. This
is explained extensively in RFC 6241, Section 7.2. (https://tools.ietf.org/html/rfc6241#section-7.2).
In order to replace or delete some parts of the configuration, the operation XML attribute must be specified on
the related XML nodes. The example playbook makes use of this attribute to unset a previously set hostname and
replace an IPv4 address.
Filter
The structure of filter.xml may be generated from combining the output of the following CLI commands:
Note: The playbook.yml and config.xml files contain templating placeholders that will be replaced by respec-
tive host variables when the playbook is executed.
See Ansible official documentation (https://docs.ansible.com/ansible/latest/user_guide/playbooks_templating.html)
Execution
Once all these files are created, you may run ansible-playbook as follows:
Additional examples
3.2.1 cmd
cmd banner
Input Parameters
pre-login [message <string>] [reset] Manage banner before a user logs in.
message <string> Message to display.
reset Reset message to factory defaults.
post-login [message <string>] [reset] Manage banner after a user logs in.
message <string> Message to display.
reset Reset message to factory defaults.
cmd reboot
Input Parameters
delay <uint32> The number of seconds to wait before reboot. During that time, it is possible to cancel the reboot.
cancel If defined, cancel a pending reboot.
force If defined, force reboot even if startup configuration is different than running configuration.
cmd poweroff
Input Parameters
delay <uint32> The number of seconds to wait before poweroff. During that time, it is possible to cancel the
poweroff.
cancel If defined, cancel a pending poweroff.
force If defined, force poweroff even if startup configuration is different than running configuration.
cmd ping
vrouter> cmd ping [vrf <string>] [count <uint16>] [packetsize <uint16>] [nodns] \
... [ipv6] [source <string>] [rate <uint16>] <destination>
Send ICMP ECHO_REQUEST messages to network hosts and print their responses.
Input Parameters
vrf <string> The VRF in which to send the ICMP ECHO_REQUESTs. By default, they are sent in the ‘main’
vrf.
count <uint16> Stop after sending count ECHO_REQUEST packets.
packetsize <uint16> Specifies the number of data bytes to be sent. The default is 56, which translates into 64
ICMP data bytes when combined with the 8 bytes of ICMP header data.
nodns Numeric output only. No attempt will be made to lookup symbolic names for host addresses.
ipv6 Force IPv6 operation only. By default, it is detected from the destination. If destination is a host name, ipv4
is used by default unless this flag is set.
source <string> Either an address, or an interface name. If interface is an address, it sets source address to
specified interface address. If interface in an interface name, it sets source interface to specified interface.
For IPv6, when doing ping to a link-local scope address, link specification (by the ‘%’-notation in destination,
or by this option) is required.
rate <uint16> The number of packets to send per second. By default, 1 packet is sent every second.
<destination> (mandatory) The destination host (name or IP address).
cmd traceroute
vrouter> cmd traceroute [vrf <string>] [nodns] [ipv6] [source <string>] <host>
Display the route (path) that was used to connect to a certain IP address or hostname. It also measures the transit
delays among hops.
Input Parameters
vrf <string> The VRF in which the packets are sent by traceroute. By default, they are sent in the ‘main’ vrf.
nodns Do not try to map IP addresses to host names when displaying them.
ipv6 Force IPv6 operation only. By default, it is detected from the destination. If destination is a host name, ipv4
is used by default unless this flag is set.
source <string> Chooses an alternative source address. Note that an address of one of the interfaces must be
selected. By default, the address of the outgoing interface is used.
<host> (mandatory) The destination host (name or IP address).
cmd show-traffic
vrouter> cmd show-traffic [vrf <string>] [count <uint16>] [filter <pcap-expr>] <ifname>
Input Parameters
vrf <string> The VRF in which to capture traffic. This must be the VRF the interface belongs to. By default,
the interface is assumed to be in the ‘main’ vrf.
count <uint16> Stop after capturing count packets.
filter <pcap-expr> Optional filter expression. This must be a valid PCAP filter. See https://www.tcpdump.
org/manpages/pcap-filter.7.html for more details.
<ifname> (mandatory) The name of the network interface on which to monitor traffic.
cmd traffic-capture
Input Parameters
vrf <string> The VRF in which to capture traffic. This must be the VRF the interface belongs to. By default,
the interface is assumed to be in the ‘main’ vrf.
count <uint16> Stop after capturing count packets.
filter <pcap-expr> Optional filter expression. This must be a valid PCAP filter. See https://www.tcpdump.
org/manpages/pcap-filter.7.html for more details.
<ifname> (mandatory) The name of the network interface on which to monitor traffic.
vrouter> cmd traffic-capture new [name <name>] [vrf <string>] [count <uint16>] [filter
˓→<pcap-expr>] \
... <ifname>
Input Parameters
name <name> The name of the capture file. If not set a unique name will be automatically chosen (in format
YYYY-MM-DD_HH-MM-SS.<ifname>.pcap). otherwise, if the file already exists it will be overwritten.
vrf <string> The VRF in which to capture traffic. This must be the VRF the interface belongs to. By default,
the interface is assumed to be in the ‘main’ vrf.
count <uint16> Stop after capturing count packets.
filter <pcap-expr> Optional filter expression. This must be a valid PCAP filter. See https://www.tcpdump.
org/manpages/pcap-filter.7.html for more details.
<ifname> (mandatory) The name of the network interface on which to monitor traffic.
Input Parameters
vrouter> cmd traffic-capture export [vrf <string>] url URL [user <string>] [password
˓→<string>] <name>
Input Parameters
vrf <string> The VRF in which remote access is done. By default, they are sent in the ‘main’ vrf.
url URL (mandatory) The destination URL.
user <string> The URL user name (not percent-encoded). If specified, the user name should not be included in
the URL.
password <string> The URL password (not percent-encoded). If specified, the user name should not be in-
cluded in the URL.
<name> (mandatory) The name of the capture to export.
Input Parameters
cmd identify-port
Initiate adapter-specific action intended to enable an operator to easily identify a physical network interface by sight.
Typically this involves blinking one or more LEDs on the specific network port.
Input Parameters
vrouter> cmd certificate cmp enroll url URL ca-name CA-NAME name NAME secret <string>␣
˓→subject <string> \
Input Parameters
url URL (mandatory) The HTTP URL of the CMP server where enrollment requests will be addressed.
URL An HTTP(S) file URL. IPv6 addresses must be surrounded by square brackets [1234:bada::2]. The
:/?#[]@!$&’()*+,;= characters in the user and password must be percent-encoded (e.g: ‘?’ becomes
‘%3f’). See RFC 3986 section 2.1. For convenience, you should use the separate user and password
fields.
ca-name CA-NAME (mandatory) The name of the certificate authority used to issue certificates, this certificate
must be imported to the database before any enrollment request.
secret <string> (mandatory) The passphrase used to protect the outgoing messages and for validating the
incoming messages.
subject <string> (mandatory) The distinguished name (DN) of subject to use in the requested certificate, ex-
ample: /CN=6WIND/O=IT.
private-key-length <uint16> The length of the private key used to generate the end user certificate.
san <string> One or more IP addresses, DNS names, or URIs separated by commas to add as Subject Alternative
Name(s) in the certificate extension extension, example: 10.1.2.3,6wind.com,http://trustcer.xy/enrollcert/.
vrouter> cmd certificate cmp update url URL ca-name CA-NAME name NAME [private-key-
˓→length <uint16>] \
Input Parameters
url URL (mandatory) The HTTP URL of the CMP server where update requests will be addressed.
URL An HTTP(S) file URL. IPv6 addresses must be surrounded by square brackets [1234:bada::2]. The
:/?#[]@!$&’()*+,;= characters in the user and password must be percent-encoded (e.g: ‘?’ becomes
‘%3f’). See RFC 3986 section 2.1. For convenience, you should use the separate user and password
fields.
ca-name CA-NAME (mandatory) The name of the certificate authority used to issue certificates, this certificate
must be imported to the database before any update request.
private-key-length <uint16> The length of the private key used to generate the end user certificate.
san <string> One or more IP addresses, DNS names, or URIs separated by commas to add as Subject Alternative
Name(s) in the certificate extension extension, example: 10.1.2.3,6wind.com,http://trustcer.xy/enrollcert/.
cmd system-image
... <device>
vrouter> cmd system-image import [name <name>] [vrf <string>] [user <string>]␣
˓→[password <string>] \
Input Parameters
BACKUP-URL Description
values
<sftp://[user[:passwd]@]host[:port]/path/to/file>
An SFTP file URL. IPv6 addresses must be surrounded by square brackets
[1234:bada::2]. The :/?#[]@!$&’()*+,;= characters in the user and password must
be percent-encoded (e.g: ‘?’ becomes ‘%3f’). See RFC 3986 section 2.1. For
convenience, you should use the separate user and password fields.
<scp://[user[:passwd]@]host[:port]/path/to/file>
An SCP file URL. IPv6 addresses must be surrounded by square brackets
[1234:bada::2]. The :/?#[]@!$&’()*+,;= characters in the user and password must
be percent-encoded (e.g: ‘?’ becomes ‘%3f’). See RFC 3986 section 2.1. For
convenience, you should use the separate user and password fields.
<ftp: An FTP file URL. IPv6 addresses must be surrounded by square brackets
//{[}user{[}: [1234:bada::2]. The :/?#[]@!$&’()*+,;= characters in the user and password must
passwd{]}@ be percent-encoded (e.g: ‘?’ becomes ‘%3f’). See RFC 3986 section 2.1. For
{]}host{[}: convenience, you should use the separate user and password fields.
port{]}/path/to/
file>
<tftp://host{[}: A TFTP file URL. IPv6 addresses must be surrounded by square brackets
port{]}/path/to/ [1234:bada::2].
file>
<http[s]://[user[:passwd]@]host[:port]/path/to/file>
An HTTP(S) file URL. IPv6 addresses must be surrounded by square brackets
[1234:bada::2]. The :/?#[]@!$&’()*+,;= characters in the user and password must
be percent-encoded (e.g: ‘?’ becomes ‘%3f’). See RFC 3986 section 2.1. For
convenience, you should use the separate user and password fields.
user <string> The URL user name (not percent-encoded). If specified, the user name should not be in-
cluded in the URL.
password <string> The URL password (not percent-encoded). If specified, the user name should not be
included in the URL.
<device> (mandatory) The device on which to install the currently booted image (example: sda).
import [name <name>] [vrf <string>] [user <string>] [password <string>] URL [md5 MD5]
Import a new system .update image from a remote URL.
name <name> The custom name to assign of the .update image.
vrf <string> The VRF in which remote access is done. By default, they are sent in the ‘main’ vrf.
user <string> The URL user name (not percent-encoded). If specified, the user name should not be in-
cluded in the URL.
password <string> The URL password (not percent-encoded). If specified, the user name should not be
included in the URL.
URL (mandatory) The URL from which to download the .update image.
cmd backup
vrouter> cmd backup import [vrf <string>] url URL [user <string>] [password <string>]
vrouter> cmd backup export [vrf <string>] url URL [user <string>] [password <string>]
Input Parameters
import [vrf <string>] url URL [user <string>] [password <string>] Import backup archive from
a remote server. WARNING: it will overwrite current configurations.
vrf <string> The VRF in which remote access is done. By default, they are sent in the ‘main’ vrf.
url URL (mandatory) The source URL.
user <string> The URL user name (not percent-encoded). If specified, the user name should not be in-
cluded in the URL.
password <string> The URL password (not percent-encoded). If specified, the user name should not be
included in the URL.
export [vrf <string>] url URL [user <string>] [password <string>] Export backup archive to a
remote server.
vrf <string> The VRF in which remote access is done. By default, they are sent in the ‘main’ vrf.
url URL (mandatory) The destination URL.
user <string> The URL user name (not percent-encoded). If specified, the user name should not be in-
cluded in the URL.
password <string> The URL password (not percent-encoded). If specified, the user name should not be
included in the URL.
cmd set-next-boot-params
Set boot parameters, taking effect at next reboot. Image must be installed on disk.
Input Parameters
intel-iommu true|false Enable intel iommu driver. Control intel_iommu=on|off kernel option.
iommu-allow-unsafe-interrupts true|false Enable PCI passthrough on hardware that does not support
interrupt remapping, when VM are trusted. Control vfio_iommu_type1.allow_unsafe_interrupts=0|1 kernel
option.
ixgbe-allow-unsupported-sfp true|false Bypass SFPs types restrictions on Intel ixgbe NICs. Control
ixgbe.allow_unsupported_sfp=0|1 kernel option.
isolate-cpus ISOLATE-CPUS Isolate cpus from kernel threads, rcu callbacks, and reduce the scheduler ticks. A
good value for this parameter is the fast path coremask.
vrouter> cmd license certificate import [url URL] [user <string>] [password <string>]␣
˓→[content <string>] \
Manage license certificate requests for offline activation through an activation webpage.
Input Parameters
import [url URL] [user <string>] [password <string>] [content <string>] serial <string>
Import a license certificate. It will be used to activate the license on the device. The certificate will be
deleted when the first configuration using it is committed.
url URL The URL from which to download the license certificate.
user <string> The URL user name (not percent-encoded). If specified, the user name should not be in-
cluded in the URL.
password <string> The URL password (not percent-encoded). If specified, the user name should not be
included in the URL.
content <string> The raw contents of the license certificate.
serial <string> (mandatory) The serial number associated with the license certificate.
list List downloaded license certificates that not are consumed yet.
delete <string> Delete a license certificate.
<string> (mandatory) The name of license certificate to delete.
request-activation serial <string> Request an activation certificate for a serial number. The resulting
certificate must then be entered on the Licensing User Portal, in the Offline Activation tab. The resulting
certificate must be imported using the cmd license certificate import command. The licensing has to be
disabled in configuration to use this rpc.
serial <string> (mandatory) The serial number associated to this activation request.
request-deactivation serial <string> Request an deactivation certificate for a serial number. The result-
ing certificate must then be entered on the Licensing User Portal, in the Offline Activation tab. Requesting
the certificate will disable the license on this device. The licensing has to be disabled in configuration to use
this rpc.
serial <string> (mandatory) The serial number associated to this deactivation request.
cancel-request Cancel any request in progress.
vrouter> cmd license file import [url URL] [user <string>] [password <string>]␣
˓→[content <string>] \
Input Parameters
import [url URL] [user <string>] [password <string>] [content <string>] serial <string>
Import a license file.
url URL The URL from which to download the license file.
user <string> The URL user name (not percent-encoded). If specified, the user name should not be in-
cluded in the URL.
password <string> The URL password (not percent-encoded). If specified, the user name should not be
included in the URL.
content <string> The raw contents of the license file.
serial <string> (mandatory) The serial number associated with the license file. It will be used as ref-
erence in the configuration.
list List downloaded license files.
delete <string> Delete a license file.
<string> (mandatory) The name of license file to delete.
cmd troubleshooting-report
... <name>
Input Parameters
user <string> The URL user name (not percent-encoded). If specified, the user name should not be in-
cluded in the URL.
password <string> The URL password (not percent-encoded). If specified, the user name should not be
included in the URL.
<name> (mandatory) The name of the report to export.
Input Parameters
Input Parameters
vrouter> cmd bgp rpki ssh-key create type TYPE name <string>
Input Parameters
Input Parameters
Input Parameters
vrouter> cmd bgp rpki ssh-host add HOST [port PORT] [vrf VRF]
Input Parameters
HOSTThe domain-name type represents a DNS domain name. Fully quallified left to the models which
utilize this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 rec-
ommends a syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow
for current practice in domain name use, and some possible future expansion. It is designed to hold
various types of domain names, including names used for A or AAAA records (host names) and
other records, such as SRV records. Note that Internet host names have a stricter syntax (described
in RFC 952) than the DNS recommendations in RFCs 1034 and 1123, and that systems that want
to store host names in schema nodes using the domain-name type are recommended to adhere to
this stricter standard to ensure interoperability. The encoding of DNS names in the DNS protocol is
limited to 255 characters. Since the encoding consists of labels prefixed by a length bytes and there
is a trailing NULL byte, only 253 characters can appear in the textual dotted notation. Domain-name
values use the US-ASCII encoding. Their canonical format uses lowercase US-ASCII characters.
Internationalized domain names MUST be encoded in punycode as described in RFC 3492.
PORT A 16-bit port number used by a transport protocol such as TCP or UDP.
Input Parameters
HOST-The domain-name type represents a DNS domain name. Fully quallified left to the models which
NAMEutilize this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 rec-
ommends a syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow
for current practice in domain name use, and some possible future expansion. It is designed to hold
various types of domain names, including names used for A or AAAA records (host names) and
other records, such as SRV records. Note that Internet host names have a stricter syntax (described
in RFC 952) than the DNS recommendations in RFCs 1034 and 1123, and that systems that want
to store host names in schema nodes using the domain-name type are recommended to adhere to
this stricter standard to ensure interoperability. The encoding of DNS names in the DNS protocol is
limited to 255 characters. Since the encoding consists of labels prefixed by a length bytes and there
is a trailing NULL byte, only 253 characters can appear in the textual dotted notation. Domain-name
values use the US-ASCII encoding. Their canonical format uses lowercase US-ASCII characters.
Internationalized domain names MUST be encoded in punycode as described in RFC 3492.
vrouter> cmd certificate import [name NAME] url URL [private-key-url PRIVATE-KEY-URL]␣
˓→[user <string>] \
Input Parameters
url URL (mandatory) The URL from which to download the certificate in PEM format.
private-key-url PRIVATE-KEY-URL The URL from which to download the certificate private key in PEM
format.
PRIVATE-KEY-URL Description
values
<http[s]://[user[:passwd]@]host[:port]/path/to/file>
An HTTP(S) file URL. IPv6 addresses must be surrounded by square brackets
[1234:bada::2]. The :/?#[]@!$&’()*+,;= characters in the user and password must
be percent-encoded (e.g: ‘?’ becomes ‘%3f’). See RFC 3986 section 2.1. For conve-
nience, you should use the separate user and password fields.
<sftp://[user[:passwd]@]host[:port]/path/to/file>
An SFTP file URL. IPv6 addresses must be surrounded by square brackets
[1234:bada::2]. The :/?#[]@!$&’()*+,;= characters in the user and password must
be percent-encoded (e.g: ‘?’ becomes ‘%3f’). See RFC 3986 section 2.1. For conve-
nience, you should use the separate user and password fields.
<scp://[user[:passwd]@]host[:port]/path/to/file>
An SCP file URL. IPv6 addresses must be surrounded by square brackets
[1234:bada::2]. The :/?#[]@!$&’()*+,;= characters in the user and password must
be percent-encoded (e.g: ‘?’ becomes ‘%3f’). See RFC 3986 section 2.1. For conve-
nience, you should use the separate user and password fields.
<ftp: An FTP file URL. IPv6 addresses must be surrounded by square brackets
//{[}user{[}: [1234:bada::2]. The :/?#[]@!$&’()*+,;= characters in the user and password must
passwd{]}@ be percent-encoded (e.g: ‘?’ becomes ‘%3f’). See RFC 3986 section 2.1. For conve-
{]}host{[}: nience, you should use the separate user and password fields.
port{]}/path/to/
file>
<tftp://host{[}: A TFTP file URL. IPv6 addresses must be surrounded by square brackets
port{]}/path/to/ [1234:bada::2].
file>
user <string> Both the url and private-key-url user name (NOT URL-encoded). If specified, the user name must
NOT be included in the URLs.
password <string> Both the url and private-key-url password (NOT URL-encoded). If specified, the password
must NOT be included in the URLs.
force Delete the certificate if it exists, this will allow update behavior for the import command.
vrouter> cmd certificate export [name NAME] url URL [user <string>] [password <string>]
Input Parameters
user <string> The URL user name (not percent-encoded). If specified, the user name should not be included in
the URL.
password <string> The URL password (not percent-encoded). If specified, the user name should not be in-
cluded in the URL.
vrouter> cmd certificate add [name NAME] data <string> [private-key <string>]
Input Parameters
Input Parameters
3.2.2 show
show summary
show interface
vrouter> show interface [vrf <string>] [type <identityref>] [LEVEL] [name <string>]
Input Parameters
vrouter> show interface throughput [vrf <string>] [type <identityref>] [name <string>]␣
˓→[count <uint16>] \
... [raw]
Input Parameters
show ipv4-routes
vrouter> show ipv4-routes [vrf <string>] [protocol <identityref>] [table <uint32>] [to␣
˓→TO] \
... [summary]
Input Parameters
TO values Description
<A.B.C.D> An IPv4 address.
<A.B.C.D/M> An IPv4 prefix: address and CIDR mask.
show ipv6-routes
vrouter> show ipv6-routes [vrf <string>] [protocol <identityref>] [table <uint32>] [to␣
˓→TO] \
... [summary]
Input Parameters
TO values Description
<X:X::X:X> An IPv6 address.
<X:X::X:X/M> An IPv6 prefix: address and CIDR mask.
Input Parameters
show bgp
vrouter> show bgp pbr ipset [set <string>] iptable [chain <string>] [vrf <string>] \
... [vrfs] [summary] [neighbors] neighbor [id ID] unnumbered-neighbor \
... [interface INTERFACE] community-list extcommunity-list as-path-access-
˓→list \
... [routes] [neighbors] l2vpn evpn [vnis] [vni VNI] [NET] summary \
... [failed] [overlay] [tags] neighbor NEIGHBOR [advertised-routes] \
... [routes] [route-distinguisher ROUTE-DISTINGUISHER] route [type TYPE] \
... [detail]
Input Parameters
pbr ipset [set <string>] iptable [chain <string>] Display information about PBR configured by
BGP.
ipset [set <string>] Display information about PBR IPSETs configured by BGP.
set <string> Display information about this set.
iptable [chain <string>] Display information about PBR IPTables chainsa configured by BGP.
chain <string> Display information about this chain.
vrf <string> Specify the VRF.
vrfs Show BGP VRFs.
summary Summary of BGP neighbor status.
neighbors Display information about all BGP neighbors.
neighbor [id ID] Display information about one BGP neighbor.
id ID Display information about one BGP neighbor.
ID values Description
<A.B.C.D> An IPv4 address.
<X:X::X:X> An IPv6 address.
community-list Display information about BGP community lists (standard and expanded).
extcommunity-list Display information about BGP extcommunity lists (standard and expanded).
as-path-access-list [name <string>] Display information about AS-path access lists.
name <string> Display information about a certain AS-Path access list.
route-map <string> Display information about this route map.
ipv4 ip [VALUE] [bestpath] [multipath] prefix [value VALUE] [bestpath] [multipath] [longer-prefix
Display information about BGP IPv4.
ip [VALUE] [bestpath] [multipath] Display this address in the BGP routing table.
VALUE Display this address in the BGP routing table.
ID values Description
<A.B.C.D> An IPv4 address.
<X:X::X:X> An IPv6 address.
ID values Description
<A.B.C.D> An IPv4 address.
<X:X::X:X> An IPv6 address.
ID values Description
<A.B.C.D> An IPv4 address.
<X:X::X:X> An IPv6 address.
Description
ROUTE-DISTINGUISHER
values
<string> Type definition for extended community attributes. In the case that common com-
munities are utilised, they are represented as a string of the form: - <2b AS>:<4b
value> per RFC4360 section 3.1 - <4b IPv4>:<2b value> per RFC4360 section
3.2.
<string> Type definition for extended community attributes. In the case that common com-
munities are utilised, they are represented as a string of the form: - <2b AS>:<4b
value> per RFC4360 section 3.1 - <4b IPv4>:<2b value> per RFC4360 section
3.2.
ID values Description
<A.B.C.D> An IPv4 address.
<X:X::X:X> An IPv6 address.
ID values Description
<A.B.C.D> An IPv4 address.
<X:X::X:X> An IPv6 address.
ID values Description
<A.B.C.D> An IPv4 address.
<X:X::X:X> An IPv6 address.
ID values Description
<A.B.C.D> An IPv4 address.
<X:X::X:X> An IPv6 address.
ID values Description
<A.B.C.D> An IPv4 address.
<X:X::X:X> An IPv6 address.
ID values Description
<A.B.C.D> An IPv4 address.
<X:X::X:X> An IPv6 address.
ID values Description
<A.B.C.D> An IPv4 address.
<X:X::X:X> An IPv6 address.
l2vpn evpn [vnis] [vni VNI] [NET] summary [failed] [overlay] [tags] neighbor NEIGHBOR [advertised
Display Layer 2 Virtual Private Network information.
evpn [vnis] [vni VNI] [NET] summary [failed] [overlay] [tags] neighbor NEIGHBOR [advertised-r
Display Ethernet Virtual Private Network information.
vnis Display all VNIs information.
vni VNI Display VNI information.
VNI Type definition representing VXLAN Segment ID / VXLAN Network Identifier value.
Description
ROUTE-DISTINGUISHER
values
<string> Type definition for extended community attributes. In the case that common com-
munities are utilised, they are represented as a string of the form: - <2b AS>:<4b
value> per RFC4360 section 3.1 - <4b IPv4>:<2b value> per RFC4360 section
3.2.
<string> Type definition for extended community attributes. In the case that common com-
munities are utilised, they are represented as a string of the form: - <2b AS>:<4b
value> per RFC4360 section 3.1 - <4b IPv4>:<2b value> per RFC4360 section
3.2.
route [type TYPE] [detail] Detailed information BPG L2VPN EVPN routes.
type TYPE Specify route type.
Input Parameters
Input Parameters
vrouter> show bgp rpki prefix-table [vrf VRF] [PREFIX] [as AS]
Input Parameters
as AS Lookup by AS number.
AS A numeric identifier for an autonomous system (AS). An AS is a single domain, under common
administrative control, which forms a unit of routing policy. Autonomous systems can be assigned
a 2-byte identifier, or a 4-byte identifier which may have public or private scope. Private ASNs are
assigned from dedicated ranges. Public ASNs are assigned from ranges allocated by IANA to the
regional internet registries (RIRs).
show evpn
Input Parameters
show ospf
vrouter> show ospf [vrf <string>] [vrfs] [route] database [default] [max-age] router \
... [ADDRESS] [advertising-router ADVERTISING-ROUTER] asbr-summary \
... [ADDRESS] [advertising-router ADVERTISING-ROUTER] external [ADDRESS] \
... [advertising-router ADVERTISING-ROUTER] network [ADDRESS] [advertising-
˓→router ADVERTISING-ROUTER] \
Input Parameters
show rip
Input Parameters
show ospf6
vrouter> show ospf6 [vrf <string>] route [DESTINATION] database [default] [router] \
... [neighbor] interface [NAME]
Input Parameters
show ripng
Input Parameters
vrouter> show mpls ldp discovery [detail] [interface] [capabilities] neighbor [LSR-ID]␣
˓→\
Input Parameters
show bfd
vrouter> show bfd [vrf VRF] [address ADDRESS] [HOP-TYPE] [source SOURCE] [interface␣
˓→INTERFACE] \
... [counters]
Input Parameters
show path-monitoring
Input Parameters
show nhrp
vrouter> show nhrp [vrf <string>] [cache] [nhs] [opennhrp] [shortcut] [default]
Input Parameters
show nhrp6
vrouter> show nhrp6 [vrf <string>] [cache] [nhs] [opennhrp] [shortcut] [default]
Input Parameters
show license
show boot-params
Output Data
ixgbe-allow-unsupported-sfp true|false Bypass SFPs types restrictions on Intel ixgbe NICs. Con-
trol ixgbe.allow_unsupported_sfp=0|1 kernel option.
isolate-cpus ISOLATE-CPUS Isolate cpus from kernel threads, rcu callbacks, and reduce the scheduler
ticks. A good value for this parameter is the fast path coremask.
show log
Print log.
Input Parameters
greater-or-equal GREATER-OR-EQUAL Filter messages with a greater or equal level than the selected
one.
show ntp
Input Parameters
Output Data
enabled true|false Enable or disable the NTP protocol and indicates that the system should attempt to syn-
chronize the system clock with an NTP server from the servers defined in the ‘ntp/server’ list.
server List of NTP servers to use for system clock synchronization. If ‘/system/ntp/enabled’ is ‘true’, then the
system will attempt to contact and utilize the specified NTP servers.
address ADDRESS The address or hostname of the NTP server.
ADDRESSDescription
val-
ues
<A.B.C.D>
An IPv4 address.
<X:X::X:X>
An IPv6 address.
<host- The domain-name type represents a DNS domain name. Fully quallified left to the models
name>which utilize this type. Internet domain names are only loosely specified. Section 3.5 of RFC
1034 recommends a syntax (modified in Section 2.1 of RFC 1123). The pattern above is in-
tended to allow for current practice in domain name use, and some possible future expansion.
It is designed to hold various types of domain names, including names used for A or AAAA
records (host names) and other records, such as SRV records. Note that Internet host names
have a stricter syntax (described in RFC 952) than the DNS recommendations in RFCs 1034
and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The
encoding of DNS names in the DNS protocol is limited to 255 characters. Since the encod-
ing consists of labels prefixed by a length bytes and there is a trailing NULL byte, only 253
characters can appear in the textual dotted notation. Domain-name values use the US-ASCII
encoding. Their canonical format uses lowercase US-ASCII characters. Internationalized do-
main names MUST be encoded in punycode as described in RFC 3492.
Description
ASSOCIATION-TYPE
values
SERVER Use client association mode. This device will not provide synchronization to the con-
figured NTP server.
PEER Use symmetric active association mode. This device may provide synchronization to
the configured NTP server.
POOL Use client association mode with one or more of the NTP servers found by DNS
resolution of the domain name given by the ‘address’ leaf. This device will not provide
synchronization to the servers.
LOCAL- Use a local reference clock.
CLOCK
INVALID Invalid use of the client/symmetric active association mode. This device can not be
synchronized or provide synchronization to the servers.
iburst true|false Indicates whether this server should enable burst synchronization or not.
prefer true|false Indicates whether this server should be preferred or not.
stratum <uint8> Indicates the level of the server in the NTP hierarchy. As stratum number increases, the
accuracy is degraded. Primary servers are stratum while a maximum value of 16 indicates unsynchro-
nized. The values have the following specific semantics: | 0 | unspecified or invalid | 1 | primary server
(e.g., equipped with a GPS receiver) | 2-15 | secondary server (via NTP) | 16 | unsynchronized | 17-255
| reserved.
root-delay <uint32> The round-trip delay to the server, in milliseconds.
root-dispersion <uint64> Dispersion (epsilon) represents the maximum error inherent in the measure-
ment.
offset <uint64> Estimate of the current time offset from the peer. This is the time difference between the
local and reference clock.
poll-interval <uint32> Polling interval of the peer.
synchronized true|false True if we are synchronized with this server.
state STATE The server status in the clock selection process.
STATE Description
values
rejected Not synchronized. Indicates sources to which connectivity has been lost or whose pack-
ets do not pass all tests.
falsetick Not synchronized. Indicates a clock which chronyd thinks is a falseticker (i.e. its time is
inconsistent with a majority of other sources).
candi- Not synchronized. Indicates acceptable sources which are combined with the selected
date source.
system- Synchronized. Indicates the source to which chronyd is currently synchronized.
peer
excluded Not synchronized. Indicates acceptable sources which are excluded by the combining
algorithm.
inconsis- Not synchronized. Indicates a source whose time appears to have too much variability.
tent
auth-key-id <uint16> Integer identifier used by the client and server to designate a secret key. The client
and server must use the same key id.
Input Parameters
Output Data
HOST Description
val-
ues
<A.B.C.D>
An IPv4 address.
<X:X::X:X>
An IPv6 address.
<host- The domain-name type represents a DNS domain name. Fully quallified left to the models
name>which utilize this type. Internet domain names are only loosely specified. Section 3.5 of RFC
1034 recommends a syntax (modified in Section 2.1 of RFC 1123). The pattern above is in-
tended to allow for current practice in domain name use, and some possible future expansion.
It is designed to hold various types of domain names, including names used for A or AAAA
records (host names) and other records, such as SRV records. Note that Internet host names
have a stricter syntax (described in RFC 952) than the DNS recommendations in RFCs 1034
and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The
encoding of DNS names in the DNS protocol is limited to 255 characters. Since the encod-
ing consists of labels prefixed by a length bytes and there is a trailing NULL byte, only 253
characters can appear in the textual dotted notation. Domain-name values use the US-ASCII
encoding. Their canonical format uses lowercase US-ASCII characters. Internationalized do-
main names MUST be encoded in punycode as described in RFC 3492.
show dhcp-server
Input Parameters
show conntracks
Show conntracks.
Input Parameters
show product
Input Parameters
Input Parameters
Output Data
ip-dropped-blackhole <uint64> Number of IP packets discarded due to matching blackhole route (Ip-
DroppedBlackhole).
ip-dropped-filtering <uint64> Number of IP packets discarded by filtering processing (IpDropped-
Netfilter).
ip-dropped-forwarding <uint64> Number of IP packets discarded due to forwarding being disabled
(IpDroppedForwarding).
ip-dropped-invalid-interface <uint64> Number of IP packets discarded due to invalid outgoing in-
terface (IpDroppedInvalidInterface).
ip-dropped-ipsec <uint64> Number of IP packets discarded by IPsec processing (IpDroppedIPsec).
ip-dropped-no-arp <uint64> Number of IP packets discarded due to missing ARP resolution (Ip-
DroppedNoArp).
ip-dropped-no-memory <uint64> Number of IP packets discarded due to memory allocation errors (Ip-
DroppedNoMemory).
ip-dropped-out-operative <uint64> Number of IP packets discarded because the outgoing interface
is down (IPDroppedOutOperative).
ip-dropped-route-exception <uint64> Number of IP packets sent to exception due to specific route
(IpDroppedRouteException).
ip-nhrp-packet <uint64> Number of IP NHRP packets (IpNhrpPacket).
ip-nhrp-error-send <uint64> Number of discarded sent IP NHRP packets (IpNhrpErrorSend).
ipv6 IPv6 service statistics.
ip6-forwarded-datagrams <uint64> Number of IPv6 packets forwarded (IpForwDatagrams).
ip6-in-delivered <uint64> Number of IPv6 packets delivered to user-protocols (IpInDelivers).
ip6-in-received <uint64> Number of IPv6 packets received (IpInReceives).
ip6-in-truncated-packets <uint64> Number of IPv6 packets discarded due to a truncate IP header
(IpInTruncatedPkts).
ip6-in-address-errors <uint64> Number of IPv6 packets discarded due to invalid IPv6 address (Ip-
InAddrErrors).
ip6-in-header-errors <uint64> Number of IPv6 packets discarded due to errors in header (IpInHdr-
Errors).
ip6-fragment-created <uint64> Number of IPv6 fragment packets created on fragmentation process-
ing (IpFragCreates).
ip6-fragment-ok <uint64> Number of IPv6 fragment packets sent successfully (IpFragOKs).
ip6-fragment-failures <uint64> Number of IPv6 packets discarded due to failures during fragmenta-
tion processing (IpFragFails).
gre-dropped-in-operative <uint64> Number of input packets dropped in GRE because the ingoing
interface is down (GREDroppedInOperative).
gre-dropped-missing-checksum <uint64> Number of input packets dropped in GRE due to a missing
checksum (GREDroppedMissingChecksum).
gre-dropped-out-operative <uint64> Number of output packets dropped in GRE because the outgo-
ing interface is down (GREDroppedOutOperative).
gre-dropped-parse-ipv4-header-failure <uint64> Number of input packets dropped in GRE due
to failure to parse IPv4 header (GREDroppedParseIPv4HeaderFailure).
gre-dropped-parse-ipv6-header-failure <uint64> Number of input packets dropped in GRE due
to failure to parse IPv6 header (GREDroppedParseIPv6HeaderFailure).
gre-dropped-pullup-ipv4-header-failure <uint64> Number of input packets dropped in IPv4
GRE due to pullup failure on gre header (GREDroppedPullupIPv4HeaderFailure).
gre-dropped-pullup-ipv6-header-failure <uint64> Number of input packets dropped in IPv6
GRE due to pullup failure on gre header (GREDroppedPullupIPv6HeaderFailure).
gre-dropped-unexpected-checksum <uint64> Number of input packets dropped in GRE due to an un-
expected checksum (GREDroppedUnexpectedChecksum).
gre-dropped-wrong-checksum <uint64> Number of input packets dropped in GRE due to an incorrect
checksum (GREDroppedWrongChecksum).
gre-exception-input-unsupported-protocol <uint64> Number of input packets sent to exception
by GRE due to unsupported GRE protocol (GREExceptionInputUnsupportedProtocol).
gre-exception-ipv4-route <uint64> Number of output packets sent to exception by GRE due to spe-
cific route (for IPv4 packet) (GREExceptionIPv4Route).
gre-exception-ipv4-source-select-failed <uint64> Number of output packets sent to exception
by GRE due to no src address can be set (for IPv4 packet) (GREExceptionIPv4SourceSelectFailed).
gre-exception-ipv6-route <uint64> Number of output packets sent to exception by GRE due to spe-
cific route (for IPv6 packet) (GREExceptionIPv6Route).
gre-exception-output-unsupported-protocol <uint64> Number of output packets sent to excep-
tion by GRE due to unsupported GRE protocol (GREExceptionOutputUnsupportedProtocol).
gre-exception-unknown-iface <uint64> Number of output packets sent to exception by GRE due to
an invalid GRE interface id (GREExceptionUnknownIface).
gre-exception-unsupported-ethernet-type <uint64> Number of output packets sent to exception
by GRE due to unsupported ethernet type (GREExceptionUnsupportedEtherType).
gre-invalid-header <uint64> Number of input packets not managed by GRE due to routing flags set
(see rfc 1701) or version number different to 0. The packet can be dropped or sent to exception later in
other fast path processing part (GREInvalidHeader).
gre-protocol-not-supported <uint64> Number of input packets not supported by GRE (GREProto-
colNotSupported).
fast-path-dropped-tc <uint64> Number of packets dropped by fast path in generic traffic conditioning
(fp_dropped_tc).
fast-path-dropped-tc-erl <uint64> Number of packets dropped by fast path in traffic conditioning
by exception rate limitation (fp_dropped_tc_erl).
fast-path-dropped-tunnel <uint64> Number of packets dropped by fast path in IPinIP tunnel
(fp_dropped_tunnel).
fast-path-dropped-vethernet <uint64> Number of packets dropped by fast path in vEthernet
(fp_dropped_veth).
fast-path-dropped-vlan <uint64> Number of packets dropped by fast path in VLAN
(fp_dropped_vlan).
fast-path-dropped-vxlan <uint64> Number of packets dropped by fast path in VXLAN
(fp_dropped_vxlan).
fast-path-missing-ipsec-license <uint64> Number of packets dropped in fast path due to missing
ipsec license (fp_missing_ipsec_license).
fast-path-missing-product-license <uint64> Number of packets dropped in fast path due to miss-
ing product license (fp_missing_product_license).
interface Interface statistics.
name <string> Interface name.
accelerated true|false True if the interface is managed by the fast-path, else false.
input-bytes <uint64> The number of input received bytes (ifs_ibytes).
input-errors <uint64> The number of input received errors (ifs_ierrors).
input-last-error <uint64> The number of input received last errors (ifs_ilasterror).
input-multicasts <uint64> The number of input received multicast packets (ifs_imcasts).
input-no-mbuf <uint64> The number of input packets dropped because no mbuf was available
(ifs_inombuf).
input-packets <uint64> The number of input received packets (ifs_ipackets).
missed-input-packets <uint64> The number of missed input packets (ifs_imissed).
multicasts <uint64> The number of multicasts (ifs_mcasts).
output-bytes <uint64> The number of output sent bytes (ifs_obytes).
output-errors <uint64> The number of output sent errors (ifs_oerrors).
output-packets <uint64> The number of ouput sent packets (ifs_opackets).
exception Exception service statistics.
exception-by-module Exceptions by module statistics.
show ike
vrouter> show ike [vrf VRF] counters [vpn <string>] ike-sa [details] [vpn <string>] \
... [remote-ip <string>] [remote-id <string>] [state STATE] ike-sa-count \
... [state STATE] ipsec-sa-count [fastpath]
Input Parameters
vrouter> show cg-nat pool-usage [vrf <string>] pool-name <string> [address ADDRESS]
Input Parameters
vrouter> show cg-nat port-usage [vrf <string>] rule-id <uint16> user-address USER-
˓→ADDRESS
Input Parameters
vrouter> show cg-nat user [vrf <string>] rule-id <uint16> [user-address USER-ADDRESS]␣
˓→[threshold-errors <uint32>] \
Input Parameters
vrouter> show cg-nat blocks [vrf <string>] rule-id <uint16> user-address USER-ADDRESS
Input Parameters
vrouter> show cg-nat conntracks [vrf <string>] rule-id <uint16> user-address USER-
˓→ADDRESS forward \
Input Parameters
forward [peer-address PEER-ADDRESS] Filter by IP and/or port using the forward tuple (the default).
peer-address PEER-ADDRESS Forward peer IPv4/IPv6 address.
backward [peer-address PEER-ADDRESS] Filter by IP and/or port using the backward tuple.
peer-address PEER-ADDRESS Backward peer IPv4 address.
protocol tcp [peer-port PEER-PORT] udp [peer-port PEER-PORT] icmp [peer-id <uint16>] icmpv6 [peer
Filter contracks per protocol.
tcp [peer-port PEER-PORT] Show only conntracks using the TCP protocol.
PEER-PORT A 16-bit port number used by a transport protocol such as TCP or UDP.
udp [peer-port PEER-PORT] Show only conntracks using the UDP protocol.
peer-port PEER-PORT Peer port.
PEER-PORT A 16-bit port number used by a transport protocol such as TCP or UDP.
icmp [peer-id <uint16>] Show only conntracks using the ICMP protocol.
peer-id <uint16> ICMP peer identifier.
icmpv6 [peer-id <uint16>] Show only conntracks using the ICMPv6 protocol.
peer-id <uint16> ICMPv6 peer identifier.
gre-pptp [key <uint16>] Show only conntracks using the GRE-PPTP protocol.
key <uint16> GRE key.
Input Parameters
Input Parameters
Input Parameters
show ha-neighbor
Input Parameters
show ha-conntrack
Input Parameters
Input Parameters
Output Data
ip IP (mandatory) The IP address of the destination VXLAN tunnel endpoint where the Ethernet
MAC ADDRESS resides.
IP An IPv4 address.
link-interface LINK-INTERFACE The outgoing interface for the VXLAN device driver to
reach the remote VXLAN tunnel endpoint.
port PORT The UDP destination PORT number to use to connect to the remote VXLAN tunnel
endpoint (default: the VXLAN dst).
PORT A 16-bit port number used by a transport protocol such as TCP or UDP.
vni VNI The VXLAN VNI Network Identifier (or VXLAN Segment ID) to use to connect to the
remote VXLAN tunnel endpoint (default: the VXLAN vni).
STATE Description
values
reach- The neighbor is known to have been reachable recently (within tens of seconds
able ago).
stale The neighbor is no longer known to be reachable, but until traffic is sent to the
neighbor no attempt should be made to verify its reachability.
perma- The FDB has been permanently configured.
nent
static The FDB has been statically configured.
other The FDB state is none of the above.
ip IP (mandatory) The IP address of the destination VXLAN tunnel endpoint where the Ethernet
MAC ADDRESS resides.
IP An IPv6 address.
link-interface LINK-INTERFACE The outgoing interface for the VXLAN device driver to
reach the remote VXLAN tunnel endpoint.
port PORT The UDP destination PORT number to use to connect to the remote VXLAN tunnel
endpoint (default: the VXLAN dst).
PORT A 16-bit port number used by a transport protocol such as TCP or UDP.
vni VNI The VXLAN VNI Network Identifier (or VXLAN Segment ID) to use to connect to the
remote VXLAN tunnel endpoint (default: the VXLAN vni).
STATE Description
values
reach- The neighbor is known to have been reachable recently (within tens of seconds
able ago).
stale The neighbor is no longer known to be reachable, but until traffic is sent to the
neighbor no attempt should be made to verify its reachability.
perma- The FDB has been permanently configured.
nent
static The FDB has been statically configured.
other The FDB state is none of the above.
show dns-server
Input Parameters
Output Data
PORT A 16-bit port number used by a transport protocol such as TCP or UDP.
show certificate
Input Parameters
Input Parameters
3.2.3 flush
flush bgp
vrouter> flush bgp [vrf <string>] ipv4 unicast [as AS] [all] [neighbor NEIGHBOR] \
... [unnumbered-neighbor UNNUMBERED-NEIGHBOR] [external] [neighbor-group
˓→<string>] \
... [soft SOFT] multicast [as AS] [all] [neighbor NEIGHBOR] [unnumbered-
˓→neighbor UNNUMBERED-NEIGHBOR] \
Input Parameters
ipv6 unicast [as AS] [all] [neighbor NEIGHBOR] [unnumbered-neighbor UNNUMBERED-NEIGHBOR] [externa
Flush information about BGP IPv6.
unicast [as AS] [all] [neighbor NEIGHBOR] [unnumbered-neighbor UNNUMBERED-NEIGHBOR] [external
Flush information for unicast address family.
as AS Flush neighbors with the AS number.
l2vpn evpn [as AS] [all] [neighbor NEIGHBOR] [unnumbered-neighbor UNNUMBERED-NEIGHBOR] [external]
Flush information about BGP L2VPN.
evpn [as AS] [all] [neighbor NEIGHBOR] [unnumbered-neighbor UNNUMBERED-NEIGHBOR] [external] [
Flush information for evpn address family.
flush ospf
Input Parameters
flush ospf6
Input Parameters
flush nhrp
Input Parameters
flush nhrp6
Input Parameters
vrouter> flush ike ike-sa [vrf VRF] [vpn <string>] [unique-id <string>]
Input Parameters
vrouter> flush ike child-sa [vrf VRF] [name <string>] [unique-id <string>]
Input Parameters
Reset statistics.
vrouter> flush cg-nat user [vrf <string>] rule-id <uint16> [user-address USER-ADDRESS]
Input Parameters
Input Parameters
vrouter> flush vxlan fdb [vrf <string>] name NAME [link-layer-address LINK-LAYER-
˓→ADDRESS] \
Input Parameters
neighbor NEIGHBOR The IP address of the destination VXLAN tunnel endpoint where the Ethernet MAC AD-
DRESS resides.
link-interface LINK-INTERFACE The outgoing interface for the VXLAN device driver to reach the remote
VXLAN tunnel endpoint.
port PORT The UDP destination PORT number used to connect to the remote VXLAN tunnel endpoint.
PORT A 16-bit port number used by a transport protocol such as TCP or UDP.
vni VNI The VXLAN VNI Network Identifier (or VXLAN Segment ID) used to connect to the remote VXLAN
tunnel endpoint.
VNI Type definition representing VXLAN Segment ID / VXLAN Network Identifier value.
3.2.4 system
hostname
The hostname of the device – should be a single domain label, without the domain.
HOST-The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
NAMEthis type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
cp-mask
Default value
default
timezone
TIMEZONE values
UTC
GMT
Antarctica/McMurdo
Antarctica/South_Pole
Antarctica/Rothera
Antarctica/Palmer
Antarctica/Mawson
Antarctica/Davis
Antarctica/Casey
Antarctica/Vostok
Antarctica/DumontDUrville
Antarctica/Syowa
Antarctica/Macquarie
America/Argentina/Buenos_Aires
America/Argentina/Cordoba
America/Argentina/Salta
America/Argentina/Jujuy
TIMEZONE values
America/Argentina/Tucuman
America/Argentina/Catamarca
America/Argentina/La_Rioja
America/Argentina/San_Juan
America/Argentina/Mendoza
America/Argentina/San_Luis
America/Argentina/Rio_Gallegos
America/Argentina/Ushuaia
Australia/Lord_Howe
Australia/Hobart
Australia/Currie
Australia/Melbourne
Australia/Sydney
Australia/Broken_Hill
Australia/Brisbane
Australia/Lindeman
Australia/Adelaide
Australia/Darwin
Australia/Perth
Australia/Eucla
America/Noronha
America/Belem
America/Fortaleza
America/Recife
America/Araguaina
America/Maceio
America/Bahia
America/Sao_Paulo
America/Campo_Grande
America/Cuiaba
America/Santarem
America/Porto_Velho
America/Boa_Vista
America/Manaus
America/Eirunepe
America/Rio_Branco
America/St_Johns
America/Halifax
America/Glace_Bay
America/Moncton
America/Goose_Bay
TIMEZONE values
America/Blanc-Sablon
America/Montreal
America/Toronto
America/Nipigon
America/Thunder_Bay
America/Iqaluit
America/Pangnirtung
America/Resolute
America/Atikokan
America/Rankin_Inlet
America/Winnipeg
America/Rainy_River
America/Regina
America/Swift_Current
America/Edmonton
America/Cambridge_Bay
America/Yellowknife
America/Inuvik
America/Creston
America/Dawson_Creek
America/Vancouver
America/Whitehorse
America/Dawson
Africa/Kinshasa
Africa/Lubumbashi
America/Santiago
Pacific/Easter
Asia/Shanghai
Asia/Harbin
Asia/Chongqing
Asia/Urumqi
Asia/Kashgar
America/Guayaquil
Pacific/Galapagos
Europe/Madrid
Africa/Ceuta
Atlantic/Canary
Pacific/Chuuk
Pacific/Pohnpei
Pacific/Kosrae
America/Godthab
TIMEZONE values
America/Danmarkshavn
America/Scoresbysund
America/Thule
Asia/Jakarta
Asia/Pontianak
Asia/Makassar
Asia/Jayapura
Pacific/Tarawa
Pacific/Enderbury
Pacific/Kiritimati
Asia/Almaty
Asia/Qyzylorda
Asia/Aqtobe
Asia/Aqtau
Asia/Oral
Pacific/Majuro
Pacific/Kwajalein
Asia/Ulaanbaatar
Asia/Hovd
Asia/Choibalsan
America/Mexico_City
America/Cancun
America/Merida
America/Monterrey
America/Matamoros
America/Mazatlan
America/Chihuahua
America/Ojinaga
America/Hermosillo
America/Tijuana
America/Santa_Isabel
America/Bahia_Banderas
Asia/Kuala_Lumpur
Asia/Kuching
Pacific/Auckland
Pacific/Chatham
Pacific/Tahiti
Pacific/Marquesas
Pacific/Gambier
Asia/Gaza
Asia/Hebron
TIMEZONE values
Europe/Lisbon
Atlantic/Madeira
Atlantic/Azores
Europe/Kaliningrad
Europe/Moscow
Europe/Volgograd
Europe/Samara
Asia/Yekaterinburg
Asia/Omsk
Asia/Novosibirsk
Asia/Novokuznetsk
Asia/Krasnoyarsk
Asia/Irkutsk
Asia/Yakutsk
Asia/Vladivostok
Asia/Sakhalin
Asia/Magadan
Asia/Kamchatka
Asia/Anadyr
Europe/Kiev
Europe/Uzhgorod
Europe/Zaporozhye
Europe/Simferopol
Pacific/Johnston
Pacific/Midway
Pacific/Wake
America/New_York
America/Detroit
America/Kentucky/Louisville
America/Kentucky/Monticello
America/Indiana/Indianapolis
America/Indiana/Vincennes
America/Indiana/Winamac
America/Indiana/Marengo
America/Indiana/Petersburg
America/Indiana/Vevay
America/Chicago
America/Indiana/Tell_City
America/Indiana/Knox
America/Menominee
America/North_Dakota/Center
TIMEZONE values
America/North_Dakota/New_Salem
America/North_Dakota/Beulah
America/Denver
America/Boise
America/Shiprock
America/Phoenix
America/Los_Angeles
America/Anchorage
America/Juneau
America/Sitka
America/Yakutat
America/Nome
America/Adak
America/Metlakatla
Pacific/Honolulu
Asia/Samarkand
Asia/Tashkent
Europe/Andorra|Asia/Dubai|Asia/Kabul|America/Antigua|America/Anguilla|Europe/Tirane|Asia/Yerevan|Africa/Luanda|Pacifi
network-stack
bridge
call-ipv4-filtering
Default value
false
call-ipv6-filtering
Default value
false
icmp
ignore-icmp-echo-broadcast
Ignore all ICMP ECHO and TIMESTAMP requests sent via broadcast or multicast.
Default value
false
rate-limit-icmp
The minimum time space that separates the sending of two consecutive ICMP packets. By default, such space is
1000 ms.
Default value
1000
rate-mask-icmp
Mask made of ICMP types for which rates are being limited.
Default value
destination-unreachable source-quench time-exceeded parameter-problem
ipv4
forwarding
Enable IP forwarding.
Default value
true
send-redirects
Default value
true
accept-redirects
Accept redirect when acting as a host. It is always disabled when acting as a router.
Default value
false
accept-source-route
Default value
false
arp-announce
Define different restriction levels for announcing the local source IP address from IP packets in ARP requests sent
on interface. Increasing the restriction level gives more chance for receiving answer from the resolved target while
decreasing the level announces more valid sender’s information.
Description
ARP-ANNOUNCE
val-
ues
any Use any local address, configured on any interface.
avoid- Try to avoid local addresses that are not in the target’s subnet for this interface. This mode is useful when
not- target hosts reachable via this interface require the source IP address in ARP requests to be part of their
in- logical network configured on the receiving interface. When we generate the request we will check all our
subnet subnets that include the target IP and will preserve the source address if it is from such subnet. If there is
no such subnet we select source address according to the rules for level 2, ‘best-local’.
best- Always use the best local address for this target. In this mode we ignore the source address in the IP packet
local and try to select local address that we prefer for talks with the target host. Such local address is selected
by looking for primary IP addresses on all our subnets on the outgoing interface that include the target
IP address. If no suitable local address is found we select the first local address we have on the outgoing
interface or on all other interfaces, with the hope we will receive reply for our request and even sometimes
no matter the source IP address we announce.
Default value
any
arp-filter
Allows to have multiple network interfaces on the same subnet, and have the ARPs for each interface be answered
based on whether or not the kernel would route a packet from the ARP’d IP out that interface (therefore you must
use source based routing for this to work). In other words it allows control of which cards (usually 1) will respond
to an arp request.
Default value
false
arp-ignore
Define different modes for sending replies in response to received ARP requests that resolve local target IP addresses.
ARP-IGNORE Description
values
any Reply for any local target IP address, configured on any interface.
check- Reply only if the target IP address is local address configured on the incoming interface.
interface
check- Reply only if the target IP address is local address configured on the incoming interface and
interface- both with the sender’s IP address are part from same subnet on this interface.
and-subnet
ignore-scope Do not reply for local addresses configured with scope host, only resolutions for global and
link addresses are replied.
ignore-all Do not reply for all local addresses.
Default value
any
log-invalid-addresses
Default value
false
ipv6
forwarding
Default value
true
autoconfiguration
Default value
true
accept-router-advert
Default value
never
accept-redirects
Accept redirect when acting as a host. It is always disabled when acting as a router.
Default value
false
accept-source-route
Default value
false
router-solicitations
Default value
-1
use-temporary-addresses
Preference for Privacy Extensions (RFC4941). Not applied to point-to- point and loopback devices (always 0).
USE-TEMPORARY-ADDRESSESDescription
values
never Disable Privacy Extensions, i.e. use the public address, subnet prefix/interface id,
where interface id is always the same.
prefer-public-addresses Enable Privacy Extensions, but prefer public addresses over temporary addresses.
always Enable Privacy Extensions and prefer temporary addresses over public addresses.
Default value
never
neighbor
ipv4-max-entries
ipv6-max-entries
ipv4-base-reachable-time
ipv6-base-reachable-time
conntrack
max-entries
tcp-timeout-close
tcp-timeout-close-wait
tcp-timeout-established
tcp-timeout-fin-wait
tcp-timeout-last-ack
tcp-timeout-max-retrans
tcp-timeout-syn-recv
tcp-timeout-syn-sent
tcp-timeout-time-wait
tcp-timeout-unacknowledged
udp-timeout
udp-timeout-stream
3.2.5 cloud-init
Cloud-init configuration.
enabled
3.2.6 license
License configuration.
enabled
Default value
true
online
serial (mandatory)
vrf
Default value
main
proxy-host
The hostname or address of an HTTP proxy to use for connecting to the online license server.
Description
PROXY-HOST
val-
ues
<A.B.C.D>
An IPv4 address.
<X:X::X:X>
An IPv6 address.
<host- The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
proxy-port
PROXY-PORT A 16-bit port number used by a transport protocol such as TCP or UDP.
proxy-user
proxy-password
export-analytics
If activated, exports information necessary for finding the instance on the licensing portal. It is recommended to
leave this enabled.
Default value
true
use-ipv6-dns
If activated, the licensing server will be accessed using IPv6 instead of IPv4.
Default value
false
offline-certificate
serial (mandatory)
The license serial number of a license file imported with the license certificate import command. After
the first successful commit, the certificate is deleted.
offline
serial (mandatory)
The license serial number of a license file imported with the license-file import command.
Network throughput.
CG-NAT conntracks.
IPsec tunnels.
3.2.7 auth
user
role (mandatory)
ROLE Description
val-
ues
viewer The user can view configuration and state and run standard commands. However, he/she cannot edit the
configuration, read protected config/state nodes (such as passwords) nor run privileged commands (such
as reboot, poweroff, etc.).
ad- The user can view all configuration and state, including protected nodes (such as password). He/she may
min edit the configuration and run any command including privileged ones (such as reboot, poweroff, etc.).
password
The user password, supplied as a hashed value using the notation described in the definition of the crypt-hash type.
PASS-The crypt-hash type is used to store passwords using a hash function. The algorithms for applying the
WORDhash function and encoding the result are implemented in various UNIX systems as the function crypt(3).
A value of this type matches one of the forms: $0$<clear text password> $<id>$<salt>$<password hash>
$<id>$<parameter>$<salt>$<password hash> The ‘$0$’ prefix signals that the value is clear text. When
such a value is received by the server, a hash value is calculated, and the string ‘$<id>$<salt>$’ or
$<id>$<parameter>$<salt>$ is prepended to the result. This value is stored in the configuration data
store. If a value starting with ‘$<id>$’, where <id> is not ‘0’, is received, the server knows that the value
already represents a hashed value and stores it ‘as is’ in the data store. When a server needs to verify
a password given by a user, it finds the stored password hash string for that user, extracts the salt, and
calculates the hash with the salt and given password as input. If the calculated hash value is the same as
the stored value, the password given by the client is accepted. This type defines the following hash func-
tions: id | hash function | feature —+—————+——————- 1 | MD5 | crypt-hash-md5 5 | SHA-256
| crypt-hash-sha-256 6 | SHA-512 | crypt-hash-sha-512 The server indicates support for the different hash
functions by advertising the corresponding feature.
authorized-key
A public SSH key for this user in the OpenSSH format. This key is allowed for SSH authentication without a
password to both the NETCONF and SSH servers. You may use the ssh-keygen utility to generate a new key-pair
and paste the contents of the *.pub file (the public key) here.
3.2.8 aaa
tacacs
<uint32> Order for TACACS+ servers. They will be reached by increasing order value.
address (mandatory)
TACACS+ server IPv4 or IPv6 address. It has to be accessible from vrf ‘main’.
port
Default value
49
secret (mandatory)
timeout
Default value
3
3.2.9 vrf
Vrf list.
3.2.10 ssh-server
enabled
Default value
true
address
The IP address of the interface to listen on. The SSH server will listen on all interfaces if no value is specified.
port
The local port number on this interface the SSH server listens on.
PORT A 16-bit port number used by a transport protocol such as TCP or UDP.
Default value
22
3.2.11 netconf-server
enabled
Enable or disable NETCONF server. If no addresses are specified, NETCONF will listen on all IPv4 and IPv6
addresses on port 830.
Default value
true
idle-timeout
Specifies the maximum number of seconds that a NETCONF session may remain idle. A NETCONF session will
be dropped if it is idle for an interval longer than this number of seconds. If set to zero, then the server will never
drop a session because it is idle. Sessions that have a notification subscription active are never dropped.
Default value
3600
address
port
port PORT
PORT A 16-bit port number used by a transport protocol such as TCP or UDP.
Default value
830
description
description <string>
3.2.12 dns
search
SEARCH
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
server
List of the DNS servers that the resolver should query. When the resolver is invoked by a calling application, it
sends the query to the first name server in this list. If no response has been received within ‘timeout’ seconds, the
resolver continues with the next server in the list. If no response is received from any server, the resolver continues
with the first server again. When the resolver has traversed the list ‘attempts’ times without receiving any response,
it gives up and returns an error to the calling application. Implementations MAY limit the number of entries in this
list.
proxy
enabled
Enable or disable DNS proxy. By default, DNS proxy listens to requests on all networks and forwards them to local
DNS servers (configured statically or obtained through DHCP).
Default value
true
listen-to
Configure networks on which to listen to DNS requests. If not specified, DNS proxy listens to all networks.
forward
Configure name servers to forward the DNS requests to. If not specified, requests are forwarded to local DNS servers
(configured statically or obtained through DHCP).
server
local
Forward DNS requests to local DNS servers (configured statically or obtained through DHCP).
dns64
DNS64 configuration.
client
exclude
mapped
IPv4 prefixes to be map in the corresponding A resource record set. If not defined it defaults to any.
not
not
PREFIX
PREFIX
3.2.13 dns-server
enabled
Default value
true
use-system-servers
Enable forwarding queries for not locally known hosts to upstream servers. These servers are defined in /con-
fig/vrf/dns/server.
Default value
true
bind
record
<record>
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
IP
IP
IP values Description
<A.B.C.D> An IPv4 address.
<X:X::X:X> An IPv6 address.
logging
enabled
3.2.14 lldp
enabled
Default value
true
hello-timer
system-name
The system name field shall contain an alpha-numeric string that indicates the system’s administratively assigned
name. The system name should be the system’s fully qualified domain name. If implementations support IETF RFC
3418, the sysName object should be used for this field.
system-description
The system description field shall contain an alpha-numeric string that is the textual description of the network
entity. The system description should include the full name and version identification of the system’s hardware type,
software operating system, and networking software. If implementations support IETF RFC 3418, the sysDescr
object should be used for this field.
management-address
The Management Address is a mandatory TLV which identifies a network address associated with the local LLDP
agent, which can be used to reach the agent on the port identified in the Port ID TLV.
The Chassis ID is a mandatory TLV which identifies the chassis component of the endpoint identifier associated
with the transmitting LLDP agent.
This field identifies the format and source of the chassis identifier string. It is an enumerator defined by the Lld-
pChassisIdSubtype object from IEEE 802.1AB MIB.
interface
enabled
Default value
true
vrouter> show state vrf <vrf> lldp interface <interface> counters frame-in
vrouter> show state vrf <vrf> lldp interface <interface> counters frame-out
vrouter> show state vrf <vrf> lldp interface <interface> counters frame-discard
vrouter> show state vrf <vrf> lldp interface <interface> counters tlv-discard
The Port ID is a mandatory TLV which identifies the port component of the endpoint identifier associated with the
transmitting LLDP agent. If the specified port is an IEEE 802.3 Repeater port, then this TLV is optional.
vrouter> show state vrf <vrf> lldp interface <interface> neighbor id <string> port-id
This field identifies the format and source of the port identifier string. It is an enumerator defined by the PtopoPor-
tIdType object from RFC2922.
vrouter> show state vrf <vrf> lldp interface <interface> neighbor id <string> port-id-
˓→type
The binary string containing the actual port identifier for the port which this LLDP PDU was transmitted. The
source and format of this field is defined by PtopoPortId from RFC2922.
vrouter> show state vrf <vrf> lldp interface <interface> neighbor id <string> port-
˓→description
The Management Address is a mandatory TLV which identifies a network address associated with the local LLDP
agent, which can be used to reach the agent on the port identified in the Port ID TLV.
vrouter> show state vrf <vrf> lldp interface <interface> neighbor id <string>␣
˓→management-address
The system name field shall contain an alpha-numeric string that indicates the system’s administratively assigned
name. The system name should be the system’s fully qualified domain name. If implementations support IETF RFC
3418, the sysName object should be used for this field.
vrouter> show state vrf <vrf> lldp interface <interface> neighbor id <string> system-
˓→name
The system description field shall contain an alpha-numeric string that is the textual description of the network
entity. The system description should include the full name and version identification of the system’s hardware type,
software operating system, and networking software. If implementations support IETF RFC 3418, the sysDescr
object should be used for this field.
vrouter> show state vrf <vrf> lldp interface <interface> neighbor id <string> system-
˓→description
The Chassis ID is a mandatory TLV which identifies the chassis component of the endpoint identifier associated
with the transmitting LLDP agent.
vrouter> show state vrf <vrf> lldp interface <interface> neighbor id <string> chassis-
˓→id
This field identifies the format and source of the chassis identifier string. It is an enumerator defined by the Lld-
pChassisIdSubtype object from IEEE 802.1AB MIB.
vrouter> show state vrf <vrf> lldp interface <interface> neighbor id <string> chassis-
˓→id-type
vrouter> show state vrf <vrf> lldp interface <interface> neighbor id <string>␣
˓→capability <capability> enabled
3.2.15 kpi
interface
Tell which interfaces should be polled by network-nic-* services in this vrf. Default is to take the ones polled by the
fast path.
3.2.16 telegraf
Telegraf configuration.
enabled
Default value
true
interval
Default value
10
influxdb-output
database (mandatory)
The target database for metrics (telegraf will create it if not exists).
database <string>
username
username <string>
password
password <string>
insecure-skip-verify
insecure-skip-verify
3.2.17 tracker
Track IP addresses.
bfd
type
Session type.
Default value
single-hop
source
Local IP address.
address (mandatory)
interface
vrf (mandatory)
VRF name.
echo-mode
detection-multiplier
Default value
3
desired-transmission-interval
Default value
300000
required-receive-interval
Minimum required control packet receive interval (use disable to not receive any control packet).
Default value
300000
desired-echo-transmission-interval
Time and date of the last time session was down (in seconds).
Time and date of the last time session was up (in seconds).
icmp
address
address ADDRESS
ADDRESSDescription
val-
ues
<A.B.C.D>
An IPv4 address.
<X:X::X:X>
An IPv6 address.
<host- The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
vrf (mandatory)
The vrf in which the ping must be sent. Default is the current netns.
vrf VRF
source
source SOURCE
interface
interface INTERFACE
dhcp-interface
The address, gateway and source will be taken from DHCP on this interface unless explicitly specified in the tracker.
dhcp-interface DHCP-INTERFACE
gateway
gateway GATEWAY
GATEWAYDescription
val-
ues
<A.B.C.D>
An IPv4 address.
<X:X::X:X>
An IPv6 address.
<host- The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
period
period <uint16>
Default value
500
threshold
threshold <uint8>
Default value
1
total
Check the threshold among this number of last pings to consider peer as reachable.
total <uint8>
Default value
1
packet-size
Packet size.
packet-size <uint16>
Default value
100
packet-tos
packet-tos <uint8>
Default value
192
timeout
Time during which a ping reply is considered as valid. If unset, it timeouts after a ping period.
timeout <uint16>
3.2.18 nat
NAT configuration.
source-rule
description
description <string>
protocol
Match a protocol.
not
not
VALUE (mandatory)
VALUE
destination
destination \
address [not] VALUE \
port [not] VALUE \
port-range [not] VALUE \
group [not] <string>
address
not
not
VALUE (mandatory)
VALUE
VALUEDescription
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<A.B.C.D>
An IPv4 address.
<A.B.C.D/M>
An IPv4 prefix: address and CIDR mask.
port
not
not
VALUE (mandatory)
VALUE
VALUE A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
not
not
VALUE (mandatory)
VALUE
group
not
Not match-set.
not
<string> (mandatory)
<string>
source
source \
address [not] VALUE \
port [not] VALUE \
port-range [not] VALUE \
group [not] <string>
address
not
not
VALUE (mandatory)
VALUE
VALUEDescription
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<A.B.C.D>
An IPv4 address.
<A.B.C.D/M>
An IPv4 prefix: address and CIDR mask.
port
not
not
VALUE (mandatory)
VALUE
VALUE A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
not
not
VALUE (mandatory)
VALUE
group
not
Not match-set.
not
<string> (mandatory)
<string>
mark
not
not
<0x0-0xffffffff> (mandatory)
The mark value. Packets in connections are matched against this value.
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
outbound-interface
Name of an interface via which a packet is going to be sent. Only for forward, output and postrouting.
not
not
<string> (mandatory)
<string>
translate-to
Translate to.
map
Translate a whole network of addresses onto another network of addresses. All ‘one’ bits in the mask are filled in
from the new address. All bits that are zero in the mask are filled in from the original address.
map MAP
output-address
output-address
address
VALUE (mandatory)
Translate to an address.
VALUE
port
Translate to a port.
port PORT
PORT A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
START (mandatory)
START
START A 16-bit port number used by a transport protocol such as TCP or UDP.
END (mandatory)
END
END A 16-bit port number used by a transport protocol such as TCP or UDP.
address-range
START (mandatory)
START
END (mandatory)
END
port
Translate to a port.
port PORT
PORT A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
START (mandatory)
START
START A 16-bit port number used by a transport protocol such as TCP or UDP.
END (mandatory)
END
END A 16-bit port number used by a transport protocol such as TCP or UDP.
Counters.
Packets.
vrouter> show state vrf <vrf> nat source-rule <uint64> counters packets
Bytes.
vrouter> show state vrf <vrf> nat source-rule <uint64> counters bytes
destination-rule
description
description <string>
protocol
Match a protocol.
not
not
VALUE (mandatory)
VALUE
destination
destination \
address [not] VALUE \
port [not] VALUE \
port-range [not] VALUE \
group [not] <string>
address
not
not
VALUE (mandatory)
VALUE
VALUEDescription
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<A.B.C.D>
An IPv4 address.
<A.B.C.D/M>
An IPv4 prefix: address and CIDR mask.
port
not
not
VALUE (mandatory)
VALUE
VALUE A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
not
not
VALUE (mandatory)
VALUE
group
not
Not match-set.
not
<string> (mandatory)
<string>
source
source \
address [not] VALUE \
port [not] VALUE \
port-range [not] VALUE \
group [not] <string>
address
not
not
VALUE (mandatory)
VALUE
VALUEDescription
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<A.B.C.D>
An IPv4 address.
<A.B.C.D/M>
An IPv4 prefix: address and CIDR mask.
port
not
not
VALUE (mandatory)
VALUE
VALUE A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
not
not
VALUE (mandatory)
VALUE
group
not
Not match-set.
not
<string> (mandatory)
<string>
mark
not
not
<0x0-0xffffffff> (mandatory)
The mark value. Packets in connections are matched against this value.
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
inbound-interface
Name of an interface via which a packet was received. Only for input, forward and prerouting.
not
not
<string> (mandatory)
<string>
translate-to
Translate to.
map
Translate a whole network of addresses onto another network of addresses. All ‘one’ bits in the mask are filled in
from the new address. All bits that are zero in the mask are filled in from the original address.
map MAP
address
VALUE (mandatory)
Translate to an address.
VALUE
port
Translate to a port.
port PORT
PORT A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
START (mandatory)
START
START A 16-bit port number used by a transport protocol such as TCP or UDP.
END (mandatory)
END
END A 16-bit port number used by a transport protocol such as TCP or UDP.
address-range
START (mandatory)
START
END (mandatory)
END
port
Translate to a port.
port PORT
PORT A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
START (mandatory)
START
START A 16-bit port number used by a transport protocol such as TCP or UDP.
END (mandatory)
END
END A 16-bit port number used by a transport protocol such as TCP or UDP.
Counters.
Packets.
vrouter> show state vrf <vrf> nat destination-rule <uint64> counters packets
Bytes.
vrouter> show state vrf <vrf> nat destination-rule <uint64> counters bytes
3.2.19 cg-nat
CG-NAT configuration.
enabled
Default value
true
alg
Application-Level Gateway.
pool
address
block-allocation-mode
BLOCK-ALLOCATION-MODE Description
values
dynamic Blocks are allocated dynamically to any user.
deterministic Blocks are allocated deterministically. It means the same block is always allo-
cated to the same user.
Default value
dynamic
block-size
port-range
START
START
START A 16-bit port number used by a transport protocol such as TCP or UDP.
END
END
END A 16-bit port number used by a transport protocol such as TCP or UDP.
rule
<uint16> Id and priority of the rule. Higher number means lower priority.
deterministic-snat44
match
Match parameters.
vrouter running config# vrf <vrf> cg-nat rule <uint16> deterministic-snat44 match
outbound-interface (mandatory)
vrouter running config# vrf <vrf> cg-nat rule <uint16> deterministic-snat44 match
vrouter running match# outbound-interface OUTBOUND-INTERFACE
source
vrouter running config# vrf <vrf> cg-nat rule <uint16> deterministic-snat44 match␣
˓→source
ipv4-address
vrouter running config# vrf <vrf> cg-nat rule <uint16> deterministic-snat44 match␣
˓→source
translate-to
Translate to.
vrouter running config# vrf <vrf> cg-nat rule <uint16> deterministic-snat44 translate-
˓→to
pool-name (mandatory)
vrouter running config# vrf <vrf> cg-nat rule <uint16> deterministic-snat44 translate-
˓→to
max-conntracks-per-user
Maximum number of conntracks assigned to a user. When set to 0, the number of conntracks is not limited.
vrouter running config# vrf <vrf> cg-nat rule <uint16> deterministic-snat44 translate-
˓→to
port-algo
vrouter running config# vrf <vrf> cg-nat rule <uint16> deterministic-snat44 translate-
˓→to
PORT-ALGO Description
values
parity Preserve port parity: an even port will be mapped to an even port, and an odd port will be
mapped to an odd port.
random Choose port randomly.
endpoint-mapping
vrouter running config# vrf <vrf> cg-nat rule <uint16> deterministic-snat44 translate-
˓→to
ENDPOINT-MAPPING Description
values
dependent Reuse port mapping for subsequent packets sent from the same internal IP address and
port to the same external IP address and port.
independent Reuse the port mapping for subsequent packets sent from the same internal IP address and
port to any external IP address and port.
endpoint-filtering
vrouter running config# vrf <vrf> cg-nat rule <uint16> deterministic-snat44 translate-
˓→to
Description
ENDPOINT-FILTERING
values
dependent Inbound packets from external endpoints are filtered out if they don’t fully match an existing
mapping (IP/port src/dst).
independent Inbound packets from external endpoints are filtered out only if their destination IP address
and port don’t match an existing mapping (IP/port src can differ).
hairpinning
Enable communication between two hosts on the internal network, using their mapped endpoint.
vrouter running config# vrf <vrf> cg-nat rule <uint16> deterministic-snat44 translate-
˓→to
address-pooling
vrouter running config# vrf <vrf> cg-nat rule <uint16> deterministic-snat44 translate-
˓→to
ADDRESS-POOLING Description
values
paired In paired mode, the same IP of the pool is used to translate all the sessions originating
from the same CPE.
no-paired In no-paired mode, different IPs of the pool can be used to translate different sessions
originating from the same CPE.
dynamic-snat44
match
Match parameters.
vrouter running config# vrf <vrf> cg-nat rule <uint16> dynamic-snat44 match
outbound-interface (mandatory)
vrouter running config# vrf <vrf> cg-nat rule <uint16> dynamic-snat44 match
vrouter running match# outbound-interface OUTBOUND-INTERFACE
source
vrouter running config# vrf <vrf> cg-nat rule <uint16> dynamic-snat44 match source
ipv4-address
vrouter running config# vrf <vrf> cg-nat rule <uint16> dynamic-snat44 match source
vrouter running source# ipv4-address IPV4-ADDRESS
translate-to
Translate to.
vrouter running config# vrf <vrf> cg-nat rule <uint16> dynamic-snat44 translate-to
pool-name (mandatory)
vrouter running config# vrf <vrf> cg-nat rule <uint16> dynamic-snat44 translate-to
vrouter running translate-to# pool-name <leafref>
max-blocks-per-user
vrouter running config# vrf <vrf> cg-nat rule <uint16> dynamic-snat44 translate-to
vrouter running translate-to# max-blocks-per-user <uint16>
active-block-timeout
Interval during which the the current block is used to allocate sessions. When set to 0, the current block is always
used.
vrouter running config# vrf <vrf> cg-nat rule <uint16> dynamic-snat44 translate-to
vrouter running translate-to# active-block-timeout <uint16>
user-timeout
Interval during which the current block remains active after all user flows have expired.
vrouter running config# vrf <vrf> cg-nat rule <uint16> dynamic-snat44 translate-to
vrouter running translate-to# user-timeout <uint16>
max-conntracks-per-user
Maximum number of conntracks assigned to a user. When set to 0, the number of conntracks is not limited.
vrouter running config# vrf <vrf> cg-nat rule <uint16> dynamic-snat44 translate-to
vrouter running translate-to# max-conntracks-per-user <uint32>
port-algo
vrouter running config# vrf <vrf> cg-nat rule <uint16> dynamic-snat44 translate-to
vrouter running translate-to# port-algo PORT-ALGO
PORT-ALGO Description
values
parity Preserve port parity: an even port will be mapped to an even port, and an odd port will be
mapped to an odd port.
random Choose port randomly.
endpoint-mapping
vrouter running config# vrf <vrf> cg-nat rule <uint16> dynamic-snat44 translate-to
vrouter running translate-to# endpoint-mapping ENDPOINT-MAPPING
ENDPOINT-MAPPING Description
values
dependent Reuse port mapping for subsequent packets sent from the same internal IP address and
port to the same external IP address and port.
independent Reuse the port mapping for subsequent packets sent from the same internal IP address and
port to any external IP address and port.
endpoint-filtering
vrouter running config# vrf <vrf> cg-nat rule <uint16> dynamic-snat44 translate-to
vrouter running translate-to# endpoint-filtering ENDPOINT-FILTERING
Description
ENDPOINT-FILTERING
values
dependent Inbound packets from external endpoints are filtered out if they don’t fully match an existing
mapping (IP/port src/dst).
independent Inbound packets from external endpoints are filtered out only if their destination IP address
and port don’t match an existing mapping (IP/port src can differ).
hairpinning
Enable communication between two hosts on the internal network, using their mapped endpoint.
vrouter running config# vrf <vrf> cg-nat rule <uint16> dynamic-snat44 translate-to
vrouter running translate-to# hairpinning true|false
address-pooling
vrouter running config# vrf <vrf> cg-nat rule <uint16> dynamic-snat44 translate-to
vrouter running translate-to# address-pooling ADDRESS-POOLING
ADDRESS-POOLING Description
values
paired In paired mode, the same IP of the pool is used to translate all the sessions originating
from the same CPE.
no-paired In no-paired mode, different IPs of the pool can be used to translate different sessions
originating from the same CPE.
dynamic-snat64
match
Match parameters.
vrouter running config# vrf <vrf> cg-nat rule <uint16> dynamic-snat64 match
outbound-interface (mandatory)
vrouter running config# vrf <vrf> cg-nat rule <uint16> dynamic-snat64 match
vrouter running match# outbound-interface OUTBOUND-INTERFACE
source
vrouter running config# vrf <vrf> cg-nat rule <uint16> dynamic-snat64 match source
ipv6-address
vrouter running config# vrf <vrf> cg-nat rule <uint16> dynamic-snat64 match source
vrouter running source# ipv6-address IPV6-ADDRESS
translate-to
Translate to.
vrouter running config# vrf <vrf> cg-nat rule <uint16> dynamic-snat64 translate-to
pool-name (mandatory)
vrouter running config# vrf <vrf> cg-nat rule <uint16> dynamic-snat64 translate-to
vrouter running translate-to# pool-name <leafref>
max-blocks-per-user
vrouter running config# vrf <vrf> cg-nat rule <uint16> dynamic-snat64 translate-to
vrouter running translate-to# max-blocks-per-user <uint16>
active-block-timeout
Interval during which the the current block is used to allocate sessions. When set to 0, the current block is always
used.
vrouter running config# vrf <vrf> cg-nat rule <uint16> dynamic-snat64 translate-to
vrouter running translate-to# active-block-timeout <uint16>
user-timeout
Interval during which the current block remains active after all user flows have expired.
vrouter running config# vrf <vrf> cg-nat rule <uint16> dynamic-snat64 translate-to
vrouter running translate-to# user-timeout <uint16>
max-conntracks-per-user
Maximum number of conntracks assigned to a user. When set to 0, the number of conntracks is not limited.
vrouter running config# vrf <vrf> cg-nat rule <uint16> dynamic-snat64 translate-to
vrouter running translate-to# max-conntracks-per-user <uint32>
port-algo
vrouter running config# vrf <vrf> cg-nat rule <uint16> dynamic-snat64 translate-to
vrouter running translate-to# port-algo PORT-ALGO
PORT-ALGO Description
values
parity Preserve port parity: an even port will be mapped to an even port, and an odd port will be
mapped to an odd port.
random Choose port randomly.
endpoint-mapping
vrouter running config# vrf <vrf> cg-nat rule <uint16> dynamic-snat64 translate-to
vrouter running translate-to# endpoint-mapping ENDPOINT-MAPPING
ENDPOINT-MAPPING Description
values
dependent Reuse port mapping for subsequent packets sent from the same internal IP address and
port to the same external IP address and port.
independent Reuse the port mapping for subsequent packets sent from the same internal IP address and
port to any external IP address and port.
endpoint-filtering
vrouter running config# vrf <vrf> cg-nat rule <uint16> dynamic-snat64 translate-to
vrouter running translate-to# endpoint-filtering ENDPOINT-FILTERING
Description
ENDPOINT-FILTERING
values
dependent Inbound packets from external endpoints are filtered out if they don’t fully match an existing
mapping (IP/port src/dst).
independent Inbound packets from external endpoints are filtered out only if their destination IP address
and port don’t match an existing mapping (IP/port src can differ).
hairpinning
Enable communication between two hosts on the internal network, using their mapped endpoint.
vrouter running config# vrf <vrf> cg-nat rule <uint16> dynamic-snat64 translate-to
vrouter running translate-to# hairpinning true|false
address-pooling
vrouter running config# vrf <vrf> cg-nat rule <uint16> dynamic-snat64 translate-to
vrouter running translate-to# address-pooling ADDRESS-POOLING
ADDRESS-POOLING Description
values
paired In paired mode, the same IP of the pool is used to translate all the sessions originating
from the same CPE.
no-paired In no-paired mode, different IPs of the pool can be used to translate different sessions
originating from the same CPE.
destination-prefix
vrouter running config# vrf <vrf> cg-nat rule <uint16> dynamic-snat64 translate-to
vrouter running translate-to# destination-prefix DESTINATION-PREFIX
static-dnat44
match
Match parameters.
vrouter running config# vrf <vrf> cg-nat rule <uint16> static-dnat44 match
inbound-interface (mandatory)
vrouter running config# vrf <vrf> cg-nat rule <uint16> static-dnat44 match
vrouter running match# inbound-interface INBOUND-INTERFACE
destination
vrouter running config# vrf <vrf> cg-nat rule <uint16> static-dnat44 match destination
ipv4-address
vrouter running config# vrf <vrf> cg-nat rule <uint16> static-dnat44 match destination
vrouter running destination# ipv4-address IPV4-ADDRESS
translate-to
Translate to.
vrouter running config# vrf <vrf> cg-nat rule <uint16> static-dnat44 translate-to
ipv4-address (mandatory)
Translated Address.
vrouter running config# vrf <vrf> cg-nat rule <uint16> static-dnat44 translate-to
vrouter running translate-to# ipv4-address IPV4-ADDRESS
static-dnat46
match
Match parameters.
vrouter running config# vrf <vrf> cg-nat rule <uint16> static-dnat46 match
inbound-interface (mandatory)
vrouter running config# vrf <vrf> cg-nat rule <uint16> static-dnat46 match
vrouter running match# inbound-interface INBOUND-INTERFACE
destination
vrouter running config# vrf <vrf> cg-nat rule <uint16> static-dnat46 match destination
ipv4-address
vrouter running config# vrf <vrf> cg-nat rule <uint16> static-dnat46 match destination
vrouter running destination# ipv4-address IPV4-ADDRESS
translate-to
Translate to.
vrouter running config# vrf <vrf> cg-nat rule <uint16> static-dnat46 translate-to
ipv6-address (mandatory)
Translated Address.
vrouter running config# vrf <vrf> cg-nat rule <uint16> static-dnat46 translate-to
vrouter running translate-to# ipv6-address IPV6-ADDRESS
source-prefix
vrouter running config# vrf <vrf> cg-nat rule <uint16> static-dnat46 translate-to
vrouter running translate-to# source-prefix SOURCE-PREFIX
static-snat44
match
Match parameters.
vrouter running config# vrf <vrf> cg-nat rule <uint16> static-snat44 match
outbound-interface (mandatory)
vrouter running config# vrf <vrf> cg-nat rule <uint16> static-snat44 match
vrouter running match# outbound-interface OUTBOUND-INTERFACE
source
vrouter running config# vrf <vrf> cg-nat rule <uint16> static-snat44 match source
ipv4-address
vrouter running config# vrf <vrf> cg-nat rule <uint16> static-snat44 match source
vrouter running source# ipv4-address IPV4-ADDRESS
translate-to
Translate to.
vrouter running config# vrf <vrf> cg-nat rule <uint16> static-snat44 translate-to
ipv4-address (mandatory)
Translated Address.
vrouter running config# vrf <vrf> cg-nat rule <uint16> static-snat44 translate-to
vrouter running translate-to# ipv4-address IPV4-ADDRESS
static-snat64
match
Match parameters.
vrouter running config# vrf <vrf> cg-nat rule <uint16> static-snat64 match
outbound-interface (mandatory)
vrouter running config# vrf <vrf> cg-nat rule <uint16> static-snat64 match
vrouter running match# outbound-interface OUTBOUND-INTERFACE
source
vrouter running config# vrf <vrf> cg-nat rule <uint16> static-snat64 match source
ipv6-address
vrouter running config# vrf <vrf> cg-nat rule <uint16> static-snat64 match source
vrouter running source# ipv6-address IPV6-ADDRESS
translate-to
Translate to.
vrouter running config# vrf <vrf> cg-nat rule <uint16> static-snat64 translate-to
ipv4-address (mandatory)
Translated Address.
vrouter running config# vrf <vrf> cg-nat rule <uint16> static-snat64 translate-to
vrouter running translate-to# ipv4-address IPV4-ADDRESS
destination-prefix
vrouter running config# vrf <vrf> cg-nat rule <uint16> static-snat64 translate-to
vrouter running translate-to# destination-prefix DESTINATION-PREFIX
conntrack
Conntrack options.
behavior
enabled (mandatory)
Enable option.
enabled true|false
timeouts
icmp
<uint32> (mandatory)
Timeout in seconds.
<uint32>
udp
<uint32> (mandatory)
Timeout in seconds.
<uint32>
gre-pptp
<uint32> (mandatory)
Timeout in seconds.
<uint32>
tcp
<uint32> (mandatory)
Timeout in seconds.
<uint32>
nat64
option
true|false (mandatory)
Option state.
true|false
mtu
<uint16> (mandatory)
<uint16>
logging
enabled
Enable log.
3.2.20 ntp
enabled
Enable or disable the NTP protocol and indicates that the system should attempt to synchronize the system clock
with an NTP server from the servers defined in the ‘ntp/server’ list.
Default value
true
ntp-source-address
auth-key
<uint16> Integer identifier used by the client and server to designate a secret key. The client and server must
use the same key id.
key-value
server-subnet
allow
allow ALLOW
deny
deny DENY
server (deprecated)
Attention:
Deprecated since: 2020-05-06
Obsolete in release: 22q3
Description: Adding time-sources to clarify wrt server mode.
Replacement: / vrf ntp time-sources server
List of NTP servers to use for system clock synchronization. If ‘/system/ntp/enabled’ is ‘true’, then the system will
attempt to contact and utilize the specified NTP servers.
Description
<server>
val-
ues
<A.B.C.D>
An IPv4 address.
<X:X::X:X>
An IPv6 address.
<host- The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
version (deprecated)
association-type (deprecated)
Description
ASSOCIATION-TYPE
values
SERVER Use client association mode. This device will not provide synchronization to the configured
NTP server.
PEER Use symmetric active association mode. This device may provide synchronization to the con-
figured NTP server.
POOL Use client association mode with one or more of the NTP servers found by DNS resolution of
the domain name given by the ‘address’ leaf. This device will not provide synchronization to
the servers.
iburst (deprecated)
prefer (deprecated)
auth-key-id (deprecated)
Integer identifier used by the client and server to designate a secret key. The client and server must use the same
key id.
Indicates the level of the server in the NTP hierarchy. As stratum number increases, the accuracy is degraded.
Primary servers are stratum while a maximum value of 16 indicates unsynchronized. The values have the following
specific semantics: | 0 | unspecified or invalid | 1 | primary server (e.g., equipped with a GPS receiver) | 2-15 |
secondary server (via NTP) | 16 | unsynchronized | 17-255 | reserved.
Estimate of the current time offset from the peer. This is the time difference between the local and reference clock.
time-sources
List of servers.
server
List of NTP servers to use for system clock synchronization. If ‘/system/ntp/enabled’ is ‘true’, then the system will
attempt to contact and utilize the specified NTP servers.
Description
<server>
val-
ues
<A.B.C.D>
An IPv4 address.
<X:X::X:X>
An IPv6 address.
<host- The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
version
Default value
4
association-type
Description
ASSOCIATION-TYPE
values
SERVER Use client association mode. This device will not provide synchronization to the configured
NTP server.
PEER Use symmetric active association mode. This device may provide synchronization to the con-
figured NTP server.
POOL Use client association mode with one or more of the NTP servers found by DNS resolution of
the domain name given by the ‘address’ leaf. This device will not provide synchronization to
the servers.
Default value
SERVER
iburst
Default value
false
prefer
Default value
false
auth-key-id
Integer identifier used by the client and server to designate a secret key. The client and server must use the same
key id.
Indicates the level of the server in the NTP hierarchy. As stratum number increases, the accuracy is degraded.
Primary servers are stratum while a maximum value of 16 indicates unsynchronized. The values have the following
specific semantics: | 0 | unspecified or invalid | 1 | primary server (e.g., equipped with a GPS receiver) | 2-15 |
secondary server (via NTP) | 16 | unsynchronized | 17-255 | reserved.
vrouter> show state vrf <vrf> ntp time-sources server <server> stratum
vrouter> show state vrf <vrf> ntp time-sources server <server> root-delay
vrouter> show state vrf <vrf> ntp time-sources server <server> root-dispersion
Estimate of the current time offset from the peer. This is the time difference between the local and reference clock.
vrouter> show state vrf <vrf> ntp time-sources server <server> offset
vrouter> show state vrf <vrf> ntp time-sources server <server> poll-interval
vrouter> show state vrf <vrf> ntp time-sources server <server> synchronized
vrouter> show state vrf <vrf> ntp time-sources server <server> state
3.2.21 firewall
ipv4 filter
Default table.
input
policy
Default value
accept
Packets.
vrouter> show state vrf <vrf> firewall ipv4 filter input packets
Bytes.
vrouter> show state vrf <vrf> firewall ipv4 filter input bytes
rule
description
description <string>
protocol
not
not
VALUE (mandatory)
VALUE
VALUE Description
values
tcp TCP protocol.
udp UDP protocol.
sctp SCTP protocol.
icmp ICMP protocol.
esp IPsec ESP protocol.
ah IPsec AH protocol.
gre GRE protocol.
l2tp L2TP protocol.
ipip IP-in-IP protocol.
vrrp VRRP protocol.
all All protocols.
<uint16> Protocol. The list can be obtained from the ‘show filter protocols’ command or the show-filter-
protocols rpc.
<string> Protocol. The list can be obtained from the ‘show filter protocols’ command or the show-filter-
protocols rpc.
destination
destination \
address [not] VALUE \
port [not] VALUE \
port-range [not] VALUE \
group [not] <string>
address
not
not
VALUE (mandatory)
VALUE
VALUEDescription
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<A.B.C.D>
An IPv4 address.
<A.B.C.D/M>
An IPv4 prefix: address and CIDR mask.
port
not
not
VALUE (mandatory)
VALUE
VALUE A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
not
not
VALUE (mandatory)
VALUE
group
not
Not match-set.
not
<string> (mandatory)
<string>
source
source \
address [not] VALUE \
port [not] VALUE \
port-range [not] VALUE \
group [not] <string>
address
not
not
VALUE (mandatory)
VALUE
VALUEDescription
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<A.B.C.D>
An IPv4 address.
<A.B.C.D/M>
An IPv4 prefix: address and CIDR mask.
port
not
not
VALUE (mandatory)
VALUE
VALUE A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
not
not
VALUE (mandatory)
VALUE
group
not
Not match-set.
not
<string> (mandatory)
<string>
ipv4
not
not
fragment (mandatory)
fragment
icmp-type
not
not
VALUE (mandatory)
VALUE
tcp-flags
not
not
set
Set flags.
set SET
examined
Examined flags.
examined EXAMINED
conntrack
conntrack \
status [not] VALUE \
state [not] VALUE
status
not
not
VALUE
VALUE
state
not
not
VALUE
VALUE
connmark
not
not
<0x0-0xffffffff> (mandatory)
The mark value. Packets in connections are matched against this value.
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
limit
Matches packets at a limited rate. If not set, the rate value is 3/hour and the burst value is 5.
burst
Maximum initial number of packets to match. This number gets recharged by one every time the rate is not reached,
up to this number.
burst <uint32>
rate
<uint32> (mandatory)
The rate.
<uint32>
UNIT
UNIT
dscp
not
not
VALUE (mandatory)
VALUE
tos
not
not
<0x0-0xff> (mandatory)
The tos value. Packets in connections are matched against this value.
<0x0-0xff>
mask
mask <0x0-0xff>
mark
not
not
<0x0-0xffffffff> (mandatory)
The mark value. Packets in connections are matched against this value.
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
sctp-chunk-types
not
not
SCOPE (mandatory)
SCOPE
init
INIT chunk.
init
init-ack
init-ack
sack
SACK chunk.
sack
heartbeat
HEARTBEAT chunk.
heartbeat
heartbeat-ack
heartbeat-ack
shutdown
SHUTDOWN chunk.
shutdown
shutdown-ack
shutdown-ack
error
ERROR chunk.
error
cookie-echo
cookie-echo
cookie-ack
cookie-ack
ecn-ecne
ecn-ecne
ecn-cwr
ecn-cwr
asconf
ASCONF chunk.
asconf
asconf-ack
asconf-ack
forward-tsn
forward-tsn
data
DATA chunk.
examined
Examined flags.
examined EXAMINED
EXAMINED Description
values
I SACK chunk should be sent back without delay.
U Indicates this data is an unordered chunk and the stream sequence number is invalid. If an un-
ordered chunk is fragmented then each fragment has this flag set.
B Marks the beginning fragment. An unfragmented chunk has this flag set.
E Marks the end fragment. An unfragmented chunk has this flag set.
set
Set flags.
set SET
SET Description
values
I SACK chunk should be sent back without delay.
U Indicates this data is an unordered chunk and the stream sequence number is invalid. If an unordered
chunk is fragmented then each fragment has this flag set.
B Marks the beginning fragment. An unfragmented chunk has this flag set.
E Marks the end fragment. An unfragmented chunk has this flag set.
abort
ABORT chunk.
examined
Examined flags.
examined EXAMINED
EXAMINED Means the sender sent its own Verification Tag (that receiver should check).
set
Set flags.
set SET
SET Means the sender sent its own Verification Tag (that receiver should check).
shutdown-complete
examined
Examined flags.
examined EXAMINED
EXAMINED Means the sender sent its own Verification Tag (that receiver should check).
set
Set flags.
set SET
SET Means the sender sent its own Verification Tag (that receiver should check).
inbound-interface
Name of an interface via which a packet was received. Only for input, forward and prerouting.
not
not
<string> (mandatory)
<string>
action
STANDARD
Standard action.
STANDARD
chain
chain <leafref>
reject
reject REJECT
connmark
Sets the mark value associated with a connection. The mark is 32 bits wide.
connmark \
set-xmark <0x0-0xffffffff> mask <0x0-0xffffffff> \
save-mark nfmask <0x0-0xffffffff> ctmask <0x0-0xffffffff> \
restore-mark nfmask <0x0-0xffffffff> ctmask <0x0-0xffffffff>
set-xmark
Zero out the bits given by mask and XOR value into the ctmark.
<0x0-0xffffffff> (mandatory)
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
save-mark
Copy the packet mark (nfmark) to the connection mark (ctmark) using the given masks. The new value is determined
as follows: ctmark = (ctmark & ~ctmask) ^ (nfmark & nfmask) i.e. ctmask defines what bits to clear and nfmask
what bits of the nfmark to XOR into the ctmark. ctmask and nfmask default to 0xFFFFFFFF.
nfmask
nfmask <0x0-0xffffffff>
ctmask
ctmask <0x0-0xffffffff>
restore-mark
Copy the connection mark (ctmark) to the packet mark (nfmark) using the given masks. The new ctmark value is
determined as follows: nfmark = (nfmark & ~nfmask) ^ (ctmark & ctmask) i.e. nfmask defines what bits to clear
and ctmask what bits of the ctmark to XOR into the packet mark. ctmask and nfmask default to 0xFFFFFFFF.
restore-mark is only valid in the mangle table.
nfmask
nfmask <0x0-0xffffffff>
ctmask
ctmask <0x0-0xffffffff>
log
level
Level of logging.
level LEVEL
prefix
prefix <string>
additional-infos
additional-infos ADDITIONAL-INFOS
mark
<0x0-0xffffffff> (mandatory)
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
tcpmss
Alters the MSS value of TCP SYN packets, to control the maximum size for that connection.
set-mss
set-mss <uint32>
clamp-mss-to-pmtu
clamp-mss-to-pmtu
Packets.
vrouter> show state vrf <vrf> firewall ipv4 filter input rule <uint64> counters packets
Bytes.
vrouter> show state vrf <vrf> firewall ipv4 filter input rule <uint64> counters bytes
forward
policy
Default value
accept
Packets.
vrouter> show state vrf <vrf> firewall ipv4 filter forward packets
Bytes.
vrouter> show state vrf <vrf> firewall ipv4 filter forward bytes
rule
description
description <string>
protocol
not
not
VALUE (mandatory)
VALUE
VALUE Description
values
tcp TCP protocol.
udp UDP protocol.
sctp SCTP protocol.
icmp ICMP protocol.
esp IPsec ESP protocol.
ah IPsec AH protocol.
gre GRE protocol.
l2tp L2TP protocol.
ipip IP-in-IP protocol.
vrrp VRRP protocol.
all All protocols.
<uint16> Protocol. The list can be obtained from the ‘show filter protocols’ command or the show-filter-
protocols rpc.
<string> Protocol. The list can be obtained from the ‘show filter protocols’ command or the show-filter-
protocols rpc.
destination
destination \
address [not] VALUE \
port [not] VALUE \
port-range [not] VALUE \
group [not] <string>
address
not
not
VALUE (mandatory)
VALUE
VALUEDescription
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<A.B.C.D>
An IPv4 address.
<A.B.C.D/M>
An IPv4 prefix: address and CIDR mask.
port
not
not
VALUE (mandatory)
VALUE
VALUE A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
not
not
VALUE (mandatory)
VALUE
group
not
Not match-set.
not
<string> (mandatory)
<string>
source
source \
address [not] VALUE \
port [not] VALUE \
port-range [not] VALUE \
group [not] <string>
address
not
not
VALUE (mandatory)
VALUE
VALUEDescription
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<A.B.C.D>
An IPv4 address.
<A.B.C.D/M>
An IPv4 prefix: address and CIDR mask.
port
not
not
VALUE (mandatory)
VALUE
VALUE A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
not
not
VALUE (mandatory)
VALUE
group
not
Not match-set.
not
<string> (mandatory)
<string>
ipv4
not
not
fragment (mandatory)
fragment
icmp-type
not
not
VALUE (mandatory)
VALUE
tcp-flags
not
not
set
Set flags.
set SET
examined
Examined flags.
examined EXAMINED
conntrack
conntrack \
status [not] VALUE \
state [not] VALUE
status
not
not
VALUE
VALUE
state
not
not
VALUE
VALUE
connmark
not
not
<0x0-0xffffffff> (mandatory)
The mark value. Packets in connections are matched against this value.
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
limit
Matches packets at a limited rate. If not set, the rate value is 3/hour and the burst value is 5.
burst
Maximum initial number of packets to match. This number gets recharged by one every time the rate is not reached,
up to this number.
burst <uint32>
rate
<uint32> (mandatory)
The rate.
<uint32>
UNIT
UNIT
dscp
not
not
VALUE (mandatory)
VALUE
tos
not
not
<0x0-0xff> (mandatory)
The tos value. Packets in connections are matched against this value.
<0x0-0xff>
mask
mask <0x0-0xff>
mark
not
not
<0x0-0xffffffff> (mandatory)
The mark value. Packets in connections are matched against this value.
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
sctp-chunk-types
not
not
SCOPE (mandatory)
SCOPE
init
INIT chunk.
init
init-ack
init-ack
sack
SACK chunk.
sack
heartbeat
HEARTBEAT chunk.
heartbeat
heartbeat-ack
heartbeat-ack
shutdown
SHUTDOWN chunk.
shutdown
shutdown-ack
shutdown-ack
error
ERROR chunk.
error
cookie-echo
cookie-echo
cookie-ack
cookie-ack
ecn-ecne
ecn-ecne
ecn-cwr
ecn-cwr
asconf
ASCONF chunk.
asconf
asconf-ack
asconf-ack
forward-tsn
forward-tsn
data
DATA chunk.
examined
Examined flags.
examined EXAMINED
EXAMINED Description
values
I SACK chunk should be sent back without delay.
U Indicates this data is an unordered chunk and the stream sequence number is invalid. If an un-
ordered chunk is fragmented then each fragment has this flag set.
B Marks the beginning fragment. An unfragmented chunk has this flag set.
E Marks the end fragment. An unfragmented chunk has this flag set.
set
Set flags.
set SET
SET Description
values
I SACK chunk should be sent back without delay.
U Indicates this data is an unordered chunk and the stream sequence number is invalid. If an unordered
chunk is fragmented then each fragment has this flag set.
B Marks the beginning fragment. An unfragmented chunk has this flag set.
E Marks the end fragment. An unfragmented chunk has this flag set.
abort
ABORT chunk.
examined
Examined flags.
examined EXAMINED
EXAMINED Means the sender sent its own Verification Tag (that receiver should check).
set
Set flags.
set SET
SET Means the sender sent its own Verification Tag (that receiver should check).
shutdown-complete
examined
Examined flags.
examined EXAMINED
EXAMINED Means the sender sent its own Verification Tag (that receiver should check).
set
Set flags.
set SET
SET Means the sender sent its own Verification Tag (that receiver should check).
inbound-interface
Name of an interface via which a packet was received. Only for input, forward and prerouting.
not
not
<string> (mandatory)
<string>
outbound-interface
Name of an interface via which a packet is going to be sent. Only for forward, output and postrouting.
not
not
<string> (mandatory)
<string>
action
STANDARD
Standard action.
STANDARD
chain
chain <leafref>
reject
reject REJECT
connmark
Sets the mark value associated with a connection. The mark is 32 bits wide.
connmark \
set-xmark <0x0-0xffffffff> mask <0x0-0xffffffff> \
save-mark nfmask <0x0-0xffffffff> ctmask <0x0-0xffffffff> \
restore-mark nfmask <0x0-0xffffffff> ctmask <0x0-0xffffffff>
set-xmark
Zero out the bits given by mask and XOR value into the ctmark.
<0x0-0xffffffff> (mandatory)
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
save-mark
Copy the packet mark (nfmark) to the connection mark (ctmark) using the given masks. The new value is determined
as follows: ctmark = (ctmark & ~ctmask) ^ (nfmark & nfmask) i.e. ctmask defines what bits to clear and nfmask
what bits of the nfmark to XOR into the ctmark. ctmask and nfmask default to 0xFFFFFFFF.
nfmask
nfmask <0x0-0xffffffff>
ctmask
ctmask <0x0-0xffffffff>
restore-mark
Copy the connection mark (ctmark) to the packet mark (nfmark) using the given masks. The new ctmark value is
determined as follows: nfmark = (nfmark & ~nfmask) ^ (ctmark & ctmask) i.e. nfmask defines what bits to clear
and ctmask what bits of the ctmark to XOR into the packet mark. ctmask and nfmask default to 0xFFFFFFFF.
restore-mark is only valid in the mangle table.
nfmask
nfmask <0x0-0xffffffff>
ctmask
ctmask <0x0-0xffffffff>
log
level
Level of logging.
level LEVEL
prefix
prefix <string>
additional-infos
additional-infos ADDITIONAL-INFOS
mark
<0x0-0xffffffff> (mandatory)
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
tcpmss
Alters the MSS value of TCP SYN packets, to control the maximum size for that connection.
set-mss
set-mss <uint32>
clamp-mss-to-pmtu
clamp-mss-to-pmtu
Packets.
vrouter> show state vrf <vrf> firewall ipv4 filter forward rule <uint64> counters␣
˓→packets
Bytes.
vrouter> show state vrf <vrf> firewall ipv4 filter forward rule <uint64> counters bytes
output
Locally-generated packets.
policy
Default value
accept
Packets.
vrouter> show state vrf <vrf> firewall ipv4 filter output packets
Bytes.
vrouter> show state vrf <vrf> firewall ipv4 filter output bytes
rule
description
description <string>
protocol
not
not
VALUE (mandatory)
VALUE
VALUE Description
values
tcp TCP protocol.
udp UDP protocol.
sctp SCTP protocol.
icmp ICMP protocol.
esp IPsec ESP protocol.
ah IPsec AH protocol.
gre GRE protocol.
l2tp L2TP protocol.
ipip IP-in-IP protocol.
vrrp VRRP protocol.
all All protocols.
<uint16> Protocol. The list can be obtained from the ‘show filter protocols’ command or the show-filter-
protocols rpc.
<string> Protocol. The list can be obtained from the ‘show filter protocols’ command or the show-filter-
protocols rpc.
destination
destination \
address [not] VALUE \
port [not] VALUE \
port-range [not] VALUE \
group [not] <string>
address
not
not
VALUE (mandatory)
VALUE
VALUEDescription
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<A.B.C.D>
An IPv4 address.
<A.B.C.D/M>
An IPv4 prefix: address and CIDR mask.
port
not
not
VALUE (mandatory)
VALUE
VALUE A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
not
not
VALUE (mandatory)
VALUE
group
not
Not match-set.
not
<string> (mandatory)
<string>
source
source \
address [not] VALUE \
port [not] VALUE \
port-range [not] VALUE \
group [not] <string>
address
not
not
VALUE (mandatory)
VALUE
VALUEDescription
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<A.B.C.D>
An IPv4 address.
<A.B.C.D/M>
An IPv4 prefix: address and CIDR mask.
port
not
not
VALUE (mandatory)
VALUE
VALUE A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
not
not
VALUE (mandatory)
VALUE
group
not
Not match-set.
not
<string> (mandatory)
<string>
ipv4
not
not
fragment (mandatory)
fragment
icmp-type
not
not
VALUE (mandatory)
VALUE
tcp-flags
not
not
set
Set flags.
set SET
examined
Examined flags.
examined EXAMINED
conntrack
conntrack \
status [not] VALUE \
state [not] VALUE
status
not
not
VALUE
VALUE
state
not
not
VALUE
VALUE
connmark
not
not
<0x0-0xffffffff> (mandatory)
The mark value. Packets in connections are matched against this value.
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
limit
Matches packets at a limited rate. If not set, the rate value is 3/hour and the burst value is 5.
burst
Maximum initial number of packets to match. This number gets recharged by one every time the rate is not reached,
up to this number.
burst <uint32>
rate
<uint32> (mandatory)
The rate.
<uint32>
UNIT
UNIT
dscp
not
not
VALUE (mandatory)
VALUE
tos
not
not
<0x0-0xff> (mandatory)
The tos value. Packets in connections are matched against this value.
<0x0-0xff>
mask
mask <0x0-0xff>
mark
not
not
<0x0-0xffffffff> (mandatory)
The mark value. Packets in connections are matched against this value.
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
sctp-chunk-types
not
not
SCOPE (mandatory)
SCOPE
init
INIT chunk.
init
init-ack
init-ack
sack
SACK chunk.
sack
heartbeat
HEARTBEAT chunk.
heartbeat
heartbeat-ack
heartbeat-ack
shutdown
SHUTDOWN chunk.
shutdown
shutdown-ack
shutdown-ack
error
ERROR chunk.
error
cookie-echo
cookie-echo
cookie-ack
cookie-ack
ecn-ecne
ecn-ecne
ecn-cwr
ecn-cwr
asconf
ASCONF chunk.
asconf
asconf-ack
asconf-ack
forward-tsn
forward-tsn
data
DATA chunk.
examined
Examined flags.
examined EXAMINED
EXAMINED Description
values
I SACK chunk should be sent back without delay.
U Indicates this data is an unordered chunk and the stream sequence number is invalid. If an un-
ordered chunk is fragmented then each fragment has this flag set.
B Marks the beginning fragment. An unfragmented chunk has this flag set.
E Marks the end fragment. An unfragmented chunk has this flag set.
set
Set flags.
set SET
SET Description
values
I SACK chunk should be sent back without delay.
U Indicates this data is an unordered chunk and the stream sequence number is invalid. If an unordered
chunk is fragmented then each fragment has this flag set.
B Marks the beginning fragment. An unfragmented chunk has this flag set.
E Marks the end fragment. An unfragmented chunk has this flag set.
abort
ABORT chunk.
examined
Examined flags.
examined EXAMINED
EXAMINED Means the sender sent its own Verification Tag (that receiver should check).
set
Set flags.
set SET
SET Means the sender sent its own Verification Tag (that receiver should check).
shutdown-complete
examined
Examined flags.
examined EXAMINED
EXAMINED Means the sender sent its own Verification Tag (that receiver should check).
set
Set flags.
set SET
SET Means the sender sent its own Verification Tag (that receiver should check).
outbound-interface
Name of an interface via which a packet is going to be sent. Only for forward, output and postrouting.
not
not
<string> (mandatory)
<string>
action
STANDARD
Standard action.
STANDARD
chain
chain <leafref>
reject
reject REJECT
connmark
Sets the mark value associated with a connection. The mark is 32 bits wide.
connmark \
set-xmark <0x0-0xffffffff> mask <0x0-0xffffffff> \
save-mark nfmask <0x0-0xffffffff> ctmask <0x0-0xffffffff> \
restore-mark nfmask <0x0-0xffffffff> ctmask <0x0-0xffffffff>
set-xmark
Zero out the bits given by mask and XOR value into the ctmark.
<0x0-0xffffffff> (mandatory)
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
save-mark
Copy the packet mark (nfmark) to the connection mark (ctmark) using the given masks. The new value is determined
as follows: ctmark = (ctmark & ~ctmask) ^ (nfmark & nfmask) i.e. ctmask defines what bits to clear and nfmask
what bits of the nfmark to XOR into the ctmark. ctmask and nfmask default to 0xFFFFFFFF.
nfmask
nfmask <0x0-0xffffffff>
ctmask
ctmask <0x0-0xffffffff>
restore-mark
Copy the connection mark (ctmark) to the packet mark (nfmark) using the given masks. The new ctmark value is
determined as follows: nfmark = (nfmark & ~nfmask) ^ (ctmark & ctmask) i.e. nfmask defines what bits to clear
and ctmask what bits of the ctmark to XOR into the packet mark. ctmask and nfmask default to 0xFFFFFFFF.
restore-mark is only valid in the mangle table.
nfmask
nfmask <0x0-0xffffffff>
ctmask
ctmask <0x0-0xffffffff>
log
level
Level of logging.
level LEVEL
prefix
prefix <string>
additional-infos
additional-infos ADDITIONAL-INFOS
mark
<0x0-0xffffffff> (mandatory)
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
tcpmss
Alters the MSS value of TCP SYN packets, to control the maximum size for that connection.
set-mss
set-mss <uint32>
clamp-mss-to-pmtu
clamp-mss-to-pmtu
Packets.
vrouter> show state vrf <vrf> firewall ipv4 filter output rule <uint64> counters␣
˓→packets
Bytes.
vrouter> show state vrf <vrf> firewall ipv4 filter output rule <uint64> counters bytes
chain
User chain.
vrouter running config# vrf <vrf> firewall ipv4 filter chain <string>
policy
vrouter running config# vrf <vrf> firewall ipv4 filter chain <string>
vrouter running chain <string># policy POLICY
Default value
accept
Packets.
vrouter> show state vrf <vrf> firewall ipv4 filter chain <string> packets
Bytes.
vrouter> show state vrf <vrf> firewall ipv4 filter chain <string> bytes
rule
vrouter running config# vrf <vrf> firewall ipv4 filter chain <string>
vrouter running chain <string># rule <uint64> description <string> \
... protocol [not] VALUE \
... destination \
... address [not] VALUE \
... port [not] VALUE \
... port-range [not] VALUE \
... group [not] <string> \
(continues on next page)
description
description <string>
protocol
not
not
VALUE (mandatory)
VALUE
VALUE Description
values
tcp TCP protocol.
udp UDP protocol.
sctp SCTP protocol.
icmp ICMP protocol.
esp IPsec ESP protocol.
ah IPsec AH protocol.
gre GRE protocol.
l2tp L2TP protocol.
ipip IP-in-IP protocol.
vrrp VRRP protocol.
all All protocols.
<uint16> Protocol. The list can be obtained from the ‘show filter protocols’ command or the show-filter-
protocols rpc.
<string> Protocol. The list can be obtained from the ‘show filter protocols’ command or the show-filter-
protocols rpc.
destination
destination \
address [not] VALUE \
port [not] VALUE \
port-range [not] VALUE \
group [not] <string>
address
not
not
VALUE (mandatory)
VALUE
VALUEDescription
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<A.B.C.D>
An IPv4 address.
<A.B.C.D/M>
An IPv4 prefix: address and CIDR mask.
port
not
not
VALUE (mandatory)
VALUE
VALUE A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
not
not
VALUE (mandatory)
VALUE
group
not
Not match-set.
not
<string> (mandatory)
<string>
source
source \
address [not] VALUE \
port [not] VALUE \
port-range [not] VALUE \
group [not] <string>
address
not
not
VALUE (mandatory)
VALUE
VALUEDescription
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<A.B.C.D>
An IPv4 address.
<A.B.C.D/M>
An IPv4 prefix: address and CIDR mask.
port
not
not
VALUE (mandatory)
VALUE
VALUE A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
not
not
VALUE (mandatory)
VALUE
group
not
Not match-set.
not
<string> (mandatory)
<string>
ipv4
not
not
fragment (mandatory)
fragment
icmp-type
not
not
VALUE (mandatory)
VALUE
tcp-flags
not
not
set
Set flags.
set SET
examined
Examined flags.
examined EXAMINED
conntrack
conntrack \
status [not] VALUE \
state [not] VALUE
status
not
not
VALUE
VALUE
state
not
not
VALUE
VALUE
connmark
not
not
<0x0-0xffffffff> (mandatory)
The mark value. Packets in connections are matched against this value.
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
limit
Matches packets at a limited rate. If not set, the rate value is 3/hour and the burst value is 5.
burst
Maximum initial number of packets to match. This number gets recharged by one every time the rate is not reached,
up to this number.
burst <uint32>
rate
<uint32> (mandatory)
The rate.
<uint32>
UNIT
UNIT
dscp
not
not
VALUE (mandatory)
VALUE
tos
not
not
<0x0-0xff> (mandatory)
The tos value. Packets in connections are matched against this value.
<0x0-0xff>
mask
mask <0x0-0xff>
mark
not
not
<0x0-0xffffffff> (mandatory)
The mark value. Packets in connections are matched against this value.
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
sctp-chunk-types
not
not
SCOPE (mandatory)
SCOPE
init
INIT chunk.
init
init-ack
init-ack
sack
SACK chunk.
sack
heartbeat
HEARTBEAT chunk.
heartbeat
heartbeat-ack
heartbeat-ack
shutdown
SHUTDOWN chunk.
shutdown
shutdown-ack
shutdown-ack
error
ERROR chunk.
error
cookie-echo
cookie-echo
cookie-ack
cookie-ack
ecn-ecne
ecn-ecne
ecn-cwr
ecn-cwr
asconf
ASCONF chunk.
asconf
asconf-ack
asconf-ack
forward-tsn
forward-tsn
data
DATA chunk.
examined
Examined flags.
examined EXAMINED
EXAMINED Description
values
I SACK chunk should be sent back without delay.
U Indicates this data is an unordered chunk and the stream sequence number is invalid. If an un-
ordered chunk is fragmented then each fragment has this flag set.
B Marks the beginning fragment. An unfragmented chunk has this flag set.
E Marks the end fragment. An unfragmented chunk has this flag set.
set
Set flags.
set SET
SET Description
values
I SACK chunk should be sent back without delay.
U Indicates this data is an unordered chunk and the stream sequence number is invalid. If an unordered
chunk is fragmented then each fragment has this flag set.
B Marks the beginning fragment. An unfragmented chunk has this flag set.
E Marks the end fragment. An unfragmented chunk has this flag set.
abort
ABORT chunk.
examined
Examined flags.
examined EXAMINED
EXAMINED Means the sender sent its own Verification Tag (that receiver should check).
set
Set flags.
set SET
SET Means the sender sent its own Verification Tag (that receiver should check).
shutdown-complete
examined
Examined flags.
examined EXAMINED
EXAMINED Means the sender sent its own Verification Tag (that receiver should check).
set
Set flags.
set SET
SET Means the sender sent its own Verification Tag (that receiver should check).
inbound-interface
Name of an interface via which a packet was received. Only for input, forward and prerouting.
not
not
<string> (mandatory)
<string>
outbound-interface
Name of an interface via which a packet is going to be sent. Only for forward, output and postrouting.
not
not
<string> (mandatory)
<string>
rpfilter
Performs a reverse path filter test on a packet. If a reply to the packet would be sent via the same interface that the
packet arrived on, the packet will match.
invert
This will invert the sense of the match. Instead of matching packets that passed the reverse path filter test, match
those that have failed it.
invert true|false
Default value
false
action
STANDARD
Standard action.
STANDARD
chain
chain <leafref>
dscp
Alters the value of the DSCP bits within the tos header of the IPv4 packet.
dscp DSCP
reject
reject REJECT
connmark
Sets the mark value associated with a connection. The mark is 32 bits wide.
connmark \
set-xmark <0x0-0xffffffff> mask <0x0-0xffffffff> \
save-mark nfmask <0x0-0xffffffff> ctmask <0x0-0xffffffff> \
restore-mark nfmask <0x0-0xffffffff> ctmask <0x0-0xffffffff>
set-xmark
Zero out the bits given by mask and XOR value into the ctmark.
<0x0-0xffffffff> (mandatory)
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
save-mark
Copy the packet mark (nfmark) to the connection mark (ctmark) using the given masks. The new value is determined
as follows: ctmark = (ctmark & ~ctmask) ^ (nfmark & nfmask) i.e. ctmask defines what bits to clear and nfmask
what bits of the nfmark to XOR into the ctmark. ctmask and nfmask default to 0xFFFFFFFF.
nfmask
nfmask <0x0-0xffffffff>
ctmask
ctmask <0x0-0xffffffff>
restore-mark
Copy the connection mark (ctmark) to the packet mark (nfmark) using the given masks. The new ctmark value is
determined as follows: nfmark = (nfmark & ~nfmask) ^ (ctmark & ctmask) i.e. nfmask defines what bits to clear
and ctmask what bits of the ctmark to XOR into the packet mark. ctmask and nfmask default to 0xFFFFFFFF.
restore-mark is only valid in the mangle table.
nfmask
nfmask <0x0-0xffffffff>
ctmask
ctmask <0x0-0xffffffff>
log
level
Level of logging.
level LEVEL
prefix
prefix <string>
additional-infos
additional-infos ADDITIONAL-INFOS
mark
<0x0-0xffffffff> (mandatory)
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
tcpmss
Alters the MSS value of TCP SYN packets, to control the maximum size for that connection.
set-mss
set-mss <uint32>
clamp-mss-to-pmtu
clamp-mss-to-pmtu
tos
<0x0-0xff> (mandatory)
<0x0-0xff>
mask
mask <0x0-0xff>
Packets.
vrouter> show state vrf <vrf> firewall ipv4 filter chain <string> rule <uint64>␣
˓→counters packets
Bytes.
vrouter> show state vrf <vrf> firewall ipv4 filter chain <string> rule <uint64>␣
˓→counters bytes
ipv4 mangle
prerouting
policy
Default value
accept
Packets.
vrouter> show state vrf <vrf> firewall ipv4 mangle prerouting packets
Bytes.
vrouter> show state vrf <vrf> firewall ipv4 mangle prerouting bytes
rule
description
description <string>
protocol
not
not
VALUE (mandatory)
VALUE
VALUE Description
values
tcp TCP protocol.
udp UDP protocol.
sctp SCTP protocol.
icmp ICMP protocol.
esp IPsec ESP protocol.
ah IPsec AH protocol.
gre GRE protocol.
l2tp L2TP protocol.
ipip IP-in-IP protocol.
vrrp VRRP protocol.
all All protocols.
<uint16> Protocol. The list can be obtained from the ‘show filter protocols’ command or the show-filter-
protocols rpc.
<string> Protocol. The list can be obtained from the ‘show filter protocols’ command or the show-filter-
protocols rpc.
destination
destination \
address [not] VALUE \
port [not] VALUE \
port-range [not] VALUE \
group [not] <string>
address
not
not
VALUE (mandatory)
VALUE
VALUEDescription
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<A.B.C.D>
An IPv4 address.
<A.B.C.D/M>
An IPv4 prefix: address and CIDR mask.
port
not
not
VALUE (mandatory)
VALUE
VALUE A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
not
not
VALUE (mandatory)
VALUE
group
not
Not match-set.
not
<string> (mandatory)
<string>
source
source \
address [not] VALUE \
port [not] VALUE \
port-range [not] VALUE \
group [not] <string>
address
not
not
VALUE (mandatory)
VALUE
VALUEDescription
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<A.B.C.D>
An IPv4 address.
<A.B.C.D/M>
An IPv4 prefix: address and CIDR mask.
port
not
not
VALUE (mandatory)
VALUE
VALUE A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
not
not
VALUE (mandatory)
VALUE
group
not
Not match-set.
not
<string> (mandatory)
<string>
ipv4
not
not
fragment (mandatory)
fragment
icmp-type
not
not
VALUE (mandatory)
VALUE
tcp-flags
not
not
set
Set flags.
set SET
examined
Examined flags.
examined EXAMINED
conntrack
conntrack \
status [not] VALUE \
state [not] VALUE
status
not
not
VALUE
VALUE
state
not
not
VALUE
VALUE
connmark
not
not
<0x0-0xffffffff> (mandatory)
The mark value. Packets in connections are matched against this value.
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
limit
Matches packets at a limited rate. If not set, the rate value is 3/hour and the burst value is 5.
burst
Maximum initial number of packets to match. This number gets recharged by one every time the rate is not reached,
up to this number.
burst <uint32>
rate
<uint32> (mandatory)
The rate.
<uint32>
UNIT
UNIT
dscp
not
not
VALUE (mandatory)
VALUE
tos
not
not
<0x0-0xff> (mandatory)
The tos value. Packets in connections are matched against this value.
<0x0-0xff>
mask
mask <0x0-0xff>
mark
not
not
<0x0-0xffffffff> (mandatory)
The mark value. Packets in connections are matched against this value.
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
sctp-chunk-types
not
not
SCOPE (mandatory)
SCOPE
init
INIT chunk.
init
init-ack
init-ack
sack
SACK chunk.
sack
heartbeat
HEARTBEAT chunk.
heartbeat
heartbeat-ack
heartbeat-ack
shutdown
SHUTDOWN chunk.
shutdown
shutdown-ack
shutdown-ack
error
ERROR chunk.
error
cookie-echo
cookie-echo
cookie-ack
cookie-ack
ecn-ecne
ecn-ecne
ecn-cwr
ecn-cwr
asconf
ASCONF chunk.
asconf
asconf-ack
asconf-ack
forward-tsn
forward-tsn
data
DATA chunk.
examined
Examined flags.
examined EXAMINED
EXAMINED Description
values
I SACK chunk should be sent back without delay.
U Indicates this data is an unordered chunk and the stream sequence number is invalid. If an un-
ordered chunk is fragmented then each fragment has this flag set.
B Marks the beginning fragment. An unfragmented chunk has this flag set.
E Marks the end fragment. An unfragmented chunk has this flag set.
set
Set flags.
set SET
SET Description
values
I SACK chunk should be sent back without delay.
U Indicates this data is an unordered chunk and the stream sequence number is invalid. If an unordered
chunk is fragmented then each fragment has this flag set.
B Marks the beginning fragment. An unfragmented chunk has this flag set.
E Marks the end fragment. An unfragmented chunk has this flag set.
abort
ABORT chunk.
examined
Examined flags.
examined EXAMINED
EXAMINED Means the sender sent its own Verification Tag (that receiver should check).
set
Set flags.
set SET
SET Means the sender sent its own Verification Tag (that receiver should check).
shutdown-complete
examined
Examined flags.
examined EXAMINED
EXAMINED Means the sender sent its own Verification Tag (that receiver should check).
set
Set flags.
set SET
SET Means the sender sent its own Verification Tag (that receiver should check).
inbound-interface
Name of an interface via which a packet was received. Only for input, forward and prerouting.
not
not
<string> (mandatory)
<string>
rpfilter
Performs a reverse path filter test on a packet. If a reply to the packet would be sent via the same interface that the
packet arrived on, the packet will match.
invert
This will invert the sense of the match. Instead of matching packets that passed the reverse path filter test, match
those that have failed it.
invert true|false
Default value
false
action
STANDARD
Standard action.
STANDARD
chain
chain <leafref>
dscp
Alters the value of the DSCP bits within the tos header of the IPv4 packet.
dscp DSCP
connmark
Sets the mark value associated with a connection. The mark is 32 bits wide.
connmark \
set-xmark <0x0-0xffffffff> mask <0x0-0xffffffff> \
save-mark nfmask <0x0-0xffffffff> ctmask <0x0-0xffffffff> \
restore-mark nfmask <0x0-0xffffffff> ctmask <0x0-0xffffffff>
set-xmark
Zero out the bits given by mask and XOR value into the ctmark.
<0x0-0xffffffff> (mandatory)
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
save-mark
Copy the packet mark (nfmark) to the connection mark (ctmark) using the given masks. The new value is determined
as follows: ctmark = (ctmark & ~ctmask) ^ (nfmark & nfmask) i.e. ctmask defines what bits to clear and nfmask
what bits of the nfmark to XOR into the ctmark. ctmask and nfmask default to 0xFFFFFFFF.
nfmask
nfmask <0x0-0xffffffff>
ctmask
ctmask <0x0-0xffffffff>
restore-mark
Copy the connection mark (ctmark) to the packet mark (nfmark) using the given masks. The new ctmark value is
determined as follows: nfmark = (nfmark & ~nfmask) ^ (ctmark & ctmask) i.e. nfmask defines what bits to clear
and ctmask what bits of the ctmark to XOR into the packet mark. ctmask and nfmask default to 0xFFFFFFFF.
restore-mark is only valid in the mangle table.
nfmask
nfmask <0x0-0xffffffff>
ctmask
ctmask <0x0-0xffffffff>
log
level
Level of logging.
level LEVEL
prefix
prefix <string>
additional-infos
additional-infos ADDITIONAL-INFOS
mark
<0x0-0xffffffff> (mandatory)
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
tcpmss
Alters the MSS value of TCP SYN packets, to control the maximum size for that connection.
set-mss
set-mss <uint32>
clamp-mss-to-pmtu
clamp-mss-to-pmtu
tos
<0x0-0xff> (mandatory)
<0x0-0xff>
mask
mask <0x0-0xff>
Packets.
vrouter> show state vrf <vrf> firewall ipv4 mangle prerouting rule <uint64> counters␣
˓→packets
Bytes.
vrouter> show state vrf <vrf> firewall ipv4 mangle prerouting rule <uint64> counters␣
˓→bytes
input
policy
Default value
accept
Packets.
vrouter> show state vrf <vrf> firewall ipv4 mangle input packets
Bytes.
vrouter> show state vrf <vrf> firewall ipv4 mangle input bytes
rule
description
description <string>
protocol
not
not
VALUE (mandatory)
VALUE
VALUE Description
values
tcp TCP protocol.
udp UDP protocol.
sctp SCTP protocol.
icmp ICMP protocol.
esp IPsec ESP protocol.
ah IPsec AH protocol.
gre GRE protocol.
l2tp L2TP protocol.
ipip IP-in-IP protocol.
vrrp VRRP protocol.
all All protocols.
<uint16> Protocol. The list can be obtained from the ‘show filter protocols’ command or the show-filter-
protocols rpc.
<string> Protocol. The list can be obtained from the ‘show filter protocols’ command or the show-filter-
protocols rpc.
destination
destination \
address [not] VALUE \
port [not] VALUE \
port-range [not] VALUE \
group [not] <string>
address
not
not
VALUE (mandatory)
VALUE
VALUEDescription
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<A.B.C.D>
An IPv4 address.
<A.B.C.D/M>
An IPv4 prefix: address and CIDR mask.
port
not
not
VALUE (mandatory)
VALUE
VALUE A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
not
not
VALUE (mandatory)
VALUE
group
not
Not match-set.
not
<string> (mandatory)
<string>
source
source \
address [not] VALUE \
port [not] VALUE \
port-range [not] VALUE \
group [not] <string>
address
not
not
VALUE (mandatory)
VALUE
VALUEDescription
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<A.B.C.D>
An IPv4 address.
<A.B.C.D/M>
An IPv4 prefix: address and CIDR mask.
port
not
not
VALUE (mandatory)
VALUE
VALUE A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
not
not
VALUE (mandatory)
VALUE
group
not
Not match-set.
not
<string> (mandatory)
<string>
ipv4
not
not
fragment (mandatory)
fragment
icmp-type
not
not
VALUE (mandatory)
VALUE
tcp-flags
not
not
set
Set flags.
set SET
examined
Examined flags.
examined EXAMINED
conntrack
conntrack \
status [not] VALUE \
state [not] VALUE
status
not
not
VALUE
VALUE
state
not
not
VALUE
VALUE
connmark
not
not
<0x0-0xffffffff> (mandatory)
The mark value. Packets in connections are matched against this value.
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
limit
Matches packets at a limited rate. If not set, the rate value is 3/hour and the burst value is 5.
burst
Maximum initial number of packets to match. This number gets recharged by one every time the rate is not reached,
up to this number.
burst <uint32>
rate
<uint32> (mandatory)
The rate.
<uint32>
UNIT
UNIT
dscp
not
not
VALUE (mandatory)
VALUE
tos
not
not
<0x0-0xff> (mandatory)
The tos value. Packets in connections are matched against this value.
<0x0-0xff>
mask
mask <0x0-0xff>
mark
not
not
<0x0-0xffffffff> (mandatory)
The mark value. Packets in connections are matched against this value.
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
sctp-chunk-types
not
not
SCOPE (mandatory)
SCOPE
init
INIT chunk.
init
init-ack
init-ack
sack
SACK chunk.
sack
heartbeat
HEARTBEAT chunk.
heartbeat
heartbeat-ack
heartbeat-ack
shutdown
SHUTDOWN chunk.
shutdown
shutdown-ack
shutdown-ack
error
ERROR chunk.
error
cookie-echo
cookie-echo
cookie-ack
cookie-ack
ecn-ecne
ecn-ecne
ecn-cwr
ecn-cwr
asconf
ASCONF chunk.
asconf
asconf-ack
asconf-ack
forward-tsn
forward-tsn
data
DATA chunk.
examined
Examined flags.
examined EXAMINED
EXAMINED Description
values
I SACK chunk should be sent back without delay.
U Indicates this data is an unordered chunk and the stream sequence number is invalid. If an un-
ordered chunk is fragmented then each fragment has this flag set.
B Marks the beginning fragment. An unfragmented chunk has this flag set.
E Marks the end fragment. An unfragmented chunk has this flag set.
set
Set flags.
set SET
SET Description
values
I SACK chunk should be sent back without delay.
U Indicates this data is an unordered chunk and the stream sequence number is invalid. If an unordered
chunk is fragmented then each fragment has this flag set.
B Marks the beginning fragment. An unfragmented chunk has this flag set.
E Marks the end fragment. An unfragmented chunk has this flag set.
abort
ABORT chunk.
examined
Examined flags.
examined EXAMINED
EXAMINED Means the sender sent its own Verification Tag (that receiver should check).
set
Set flags.
set SET
SET Means the sender sent its own Verification Tag (that receiver should check).
shutdown-complete
examined
Examined flags.
examined EXAMINED
EXAMINED Means the sender sent its own Verification Tag (that receiver should check).
set
Set flags.
set SET
SET Means the sender sent its own Verification Tag (that receiver should check).
inbound-interface
Name of an interface via which a packet was received. Only for input, forward and prerouting.
not
not
<string> (mandatory)
<string>
action
STANDARD
Standard action.
STANDARD
chain
chain <leafref>
dscp
Alters the value of the DSCP bits within the tos header of the IPv4 packet.
dscp DSCP
connmark
Sets the mark value associated with a connection. The mark is 32 bits wide.
connmark \
set-xmark <0x0-0xffffffff> mask <0x0-0xffffffff> \
save-mark nfmask <0x0-0xffffffff> ctmask <0x0-0xffffffff> \
restore-mark nfmask <0x0-0xffffffff> ctmask <0x0-0xffffffff>
set-xmark
Zero out the bits given by mask and XOR value into the ctmark.
<0x0-0xffffffff> (mandatory)
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
save-mark
Copy the packet mark (nfmark) to the connection mark (ctmark) using the given masks. The new value is determined
as follows: ctmark = (ctmark & ~ctmask) ^ (nfmark & nfmask) i.e. ctmask defines what bits to clear and nfmask
what bits of the nfmark to XOR into the ctmark. ctmask and nfmask default to 0xFFFFFFFF.
nfmask
nfmask <0x0-0xffffffff>
ctmask
ctmask <0x0-0xffffffff>
restore-mark
Copy the connection mark (ctmark) to the packet mark (nfmark) using the given masks. The new ctmark value is
determined as follows: nfmark = (nfmark & ~nfmask) ^ (ctmark & ctmask) i.e. nfmask defines what bits to clear
and ctmask what bits of the ctmark to XOR into the packet mark. ctmask and nfmask default to 0xFFFFFFFF.
restore-mark is only valid in the mangle table.
nfmask
nfmask <0x0-0xffffffff>
ctmask
ctmask <0x0-0xffffffff>
log
level
Level of logging.
level LEVEL
prefix
prefix <string>
additional-infos
additional-infos ADDITIONAL-INFOS
mark
<0x0-0xffffffff> (mandatory)
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
tcpmss
Alters the MSS value of TCP SYN packets, to control the maximum size for that connection.
set-mss
set-mss <uint32>
clamp-mss-to-pmtu
clamp-mss-to-pmtu
tos
<0x0-0xff> (mandatory)
<0x0-0xff>
mask
mask <0x0-0xff>
Packets.
vrouter> show state vrf <vrf> firewall ipv4 mangle input rule <uint64> counters packets
Bytes.
vrouter> show state vrf <vrf> firewall ipv4 mangle input rule <uint64> counters bytes
forward
policy
Default value
accept
Packets.
vrouter> show state vrf <vrf> firewall ipv4 mangle forward packets
Bytes.
vrouter> show state vrf <vrf> firewall ipv4 mangle forward bytes
rule
description
description <string>
protocol
not
not
VALUE (mandatory)
VALUE
VALUE Description
values
tcp TCP protocol.
udp UDP protocol.
sctp SCTP protocol.
icmp ICMP protocol.
esp IPsec ESP protocol.
ah IPsec AH protocol.
gre GRE protocol.
l2tp L2TP protocol.
ipip IP-in-IP protocol.
vrrp VRRP protocol.
all All protocols.
<uint16> Protocol. The list can be obtained from the ‘show filter protocols’ command or the show-filter-
protocols rpc.
<string> Protocol. The list can be obtained from the ‘show filter protocols’ command or the show-filter-
protocols rpc.
destination
destination \
address [not] VALUE \
port [not] VALUE \
port-range [not] VALUE \
group [not] <string>
address
not
not
VALUE (mandatory)
VALUE
VALUEDescription
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<A.B.C.D>
An IPv4 address.
<A.B.C.D/M>
An IPv4 prefix: address and CIDR mask.
port
not
not
VALUE (mandatory)
VALUE
VALUE A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
not
not
VALUE (mandatory)
VALUE
group
not
Not match-set.
not
<string> (mandatory)
<string>
source
source \
address [not] VALUE \
port [not] VALUE \
port-range [not] VALUE \
group [not] <string>
address
not
not
VALUE (mandatory)
VALUE
VALUEDescription
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<A.B.C.D>
An IPv4 address.
<A.B.C.D/M>
An IPv4 prefix: address and CIDR mask.
port
not
not
VALUE (mandatory)
VALUE
VALUE A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
not
not
VALUE (mandatory)
VALUE
group
not
Not match-set.
not
<string> (mandatory)
<string>
ipv4
not
not
fragment (mandatory)
fragment
icmp-type
not
not
VALUE (mandatory)
VALUE
tcp-flags
not
not
set
Set flags.
set SET
examined
Examined flags.
examined EXAMINED
conntrack
conntrack \
status [not] VALUE \
state [not] VALUE
status
not
not
VALUE
VALUE
state
not
not
VALUE
VALUE
connmark
not
not
<0x0-0xffffffff> (mandatory)
The mark value. Packets in connections are matched against this value.
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
limit
Matches packets at a limited rate. If not set, the rate value is 3/hour and the burst value is 5.
burst
Maximum initial number of packets to match. This number gets recharged by one every time the rate is not reached,
up to this number.
burst <uint32>
rate
<uint32> (mandatory)
The rate.
<uint32>
UNIT
UNIT
dscp
not
not
VALUE (mandatory)
VALUE
tos
not
not
<0x0-0xff> (mandatory)
The tos value. Packets in connections are matched against this value.
<0x0-0xff>
mask
mask <0x0-0xff>
mark
not
not
<0x0-0xffffffff> (mandatory)
The mark value. Packets in connections are matched against this value.
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
sctp-chunk-types
not
not
SCOPE (mandatory)
SCOPE
init
INIT chunk.
init
init-ack
init-ack
sack
SACK chunk.
sack
heartbeat
HEARTBEAT chunk.
heartbeat
heartbeat-ack
heartbeat-ack
shutdown
SHUTDOWN chunk.
shutdown
shutdown-ack
shutdown-ack
error
ERROR chunk.
error
cookie-echo
cookie-echo
cookie-ack
cookie-ack
ecn-ecne
ecn-ecne
ecn-cwr
ecn-cwr
asconf
ASCONF chunk.
asconf
asconf-ack
asconf-ack
forward-tsn
forward-tsn
data
DATA chunk.
examined
Examined flags.
examined EXAMINED
EXAMINED Description
values
I SACK chunk should be sent back without delay.
U Indicates this data is an unordered chunk and the stream sequence number is invalid. If an un-
ordered chunk is fragmented then each fragment has this flag set.
B Marks the beginning fragment. An unfragmented chunk has this flag set.
E Marks the end fragment. An unfragmented chunk has this flag set.
set
Set flags.
set SET
SET Description
values
I SACK chunk should be sent back without delay.
U Indicates this data is an unordered chunk and the stream sequence number is invalid. If an unordered
chunk is fragmented then each fragment has this flag set.
B Marks the beginning fragment. An unfragmented chunk has this flag set.
E Marks the end fragment. An unfragmented chunk has this flag set.
abort
ABORT chunk.
examined
Examined flags.
examined EXAMINED
EXAMINED Means the sender sent its own Verification Tag (that receiver should check).
set
Set flags.
set SET
SET Means the sender sent its own Verification Tag (that receiver should check).
shutdown-complete
examined
Examined flags.
examined EXAMINED
EXAMINED Means the sender sent its own Verification Tag (that receiver should check).
set
Set flags.
set SET
SET Means the sender sent its own Verification Tag (that receiver should check).
inbound-interface
Name of an interface via which a packet was received. Only for input, forward and prerouting.
not
not
<string> (mandatory)
<string>
outbound-interface
Name of an interface via which a packet is going to be sent. Only for forward, output and postrouting.
not
not
<string> (mandatory)
<string>
action
STANDARD
Standard action.
STANDARD
chain
chain <leafref>
dscp
Alters the value of the DSCP bits within the tos header of the IPv4 packet.
dscp DSCP
connmark
Sets the mark value associated with a connection. The mark is 32 bits wide.
connmark \
set-xmark <0x0-0xffffffff> mask <0x0-0xffffffff> \
save-mark nfmask <0x0-0xffffffff> ctmask <0x0-0xffffffff> \
restore-mark nfmask <0x0-0xffffffff> ctmask <0x0-0xffffffff>
set-xmark
Zero out the bits given by mask and XOR value into the ctmark.
<0x0-0xffffffff> (mandatory)
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
save-mark
Copy the packet mark (nfmark) to the connection mark (ctmark) using the given masks. The new value is determined
as follows: ctmark = (ctmark & ~ctmask) ^ (nfmark & nfmask) i.e. ctmask defines what bits to clear and nfmask
what bits of the nfmark to XOR into the ctmark. ctmask and nfmask default to 0xFFFFFFFF.
nfmask
nfmask <0x0-0xffffffff>
ctmask
ctmask <0x0-0xffffffff>
restore-mark
Copy the connection mark (ctmark) to the packet mark (nfmark) using the given masks. The new ctmark value is
determined as follows: nfmark = (nfmark & ~nfmask) ^ (ctmark & ctmask) i.e. nfmask defines what bits to clear
and ctmask what bits of the ctmark to XOR into the packet mark. ctmask and nfmask default to 0xFFFFFFFF.
restore-mark is only valid in the mangle table.
nfmask
nfmask <0x0-0xffffffff>
ctmask
ctmask <0x0-0xffffffff>
log
level
Level of logging.
level LEVEL
prefix
prefix <string>
additional-infos
additional-infos ADDITIONAL-INFOS
mark
<0x0-0xffffffff> (mandatory)
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
tcpmss
Alters the MSS value of TCP SYN packets, to control the maximum size for that connection.
set-mss
set-mss <uint32>
clamp-mss-to-pmtu
clamp-mss-to-pmtu
tos
<0x0-0xff> (mandatory)
<0x0-0xff>
mask
mask <0x0-0xff>
Packets.
vrouter> show state vrf <vrf> firewall ipv4 mangle forward rule <uint64> counters␣
˓→packets
Bytes.
vrouter> show state vrf <vrf> firewall ipv4 mangle forward rule <uint64> counters bytes
output
policy
Default value
accept
Packets.
vrouter> show state vrf <vrf> firewall ipv4 mangle output packets
Bytes.
vrouter> show state vrf <vrf> firewall ipv4 mangle output bytes
rule
description
description <string>
protocol
not
not
VALUE (mandatory)
VALUE
VALUE Description
values
tcp TCP protocol.
udp UDP protocol.
sctp SCTP protocol.
icmp ICMP protocol.
esp IPsec ESP protocol.
ah IPsec AH protocol.
gre GRE protocol.
l2tp L2TP protocol.
ipip IP-in-IP protocol.
vrrp VRRP protocol.
all All protocols.
<uint16> Protocol. The list can be obtained from the ‘show filter protocols’ command or the show-filter-
protocols rpc.
<string> Protocol. The list can be obtained from the ‘show filter protocols’ command or the show-filter-
protocols rpc.
destination
destination \
address [not] VALUE \
port [not] VALUE \
port-range [not] VALUE \
group [not] <string>
address
not
not
VALUE (mandatory)
VALUE
VALUEDescription
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<A.B.C.D>
An IPv4 address.
<A.B.C.D/M>
An IPv4 prefix: address and CIDR mask.
port
not
not
VALUE (mandatory)
VALUE
VALUE A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
not
not
VALUE (mandatory)
VALUE
group
not
Not match-set.
not
<string> (mandatory)
<string>
source
source \
address [not] VALUE \
port [not] VALUE \
port-range [not] VALUE \
group [not] <string>
address
not
not
VALUE (mandatory)
VALUE
VALUEDescription
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<A.B.C.D>
An IPv4 address.
<A.B.C.D/M>
An IPv4 prefix: address and CIDR mask.
port
not
not
VALUE (mandatory)
VALUE
VALUE A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
not
not
VALUE (mandatory)
VALUE
group
not
Not match-set.
not
<string> (mandatory)
<string>
ipv4
not
not
fragment (mandatory)
fragment
icmp-type
not
not
VALUE (mandatory)
VALUE
tcp-flags
not
not
set
Set flags.
set SET
examined
Examined flags.
examined EXAMINED
conntrack
conntrack \
status [not] VALUE \
state [not] VALUE
status
not
not
VALUE
VALUE
state
not
not
VALUE
VALUE
connmark
not
not
<0x0-0xffffffff> (mandatory)
The mark value. Packets in connections are matched against this value.
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
limit
Matches packets at a limited rate. If not set, the rate value is 3/hour and the burst value is 5.
burst
Maximum initial number of packets to match. This number gets recharged by one every time the rate is not reached,
up to this number.
burst <uint32>
rate
<uint32> (mandatory)
The rate.
<uint32>
UNIT
UNIT
dscp
not
not
VALUE (mandatory)
VALUE
tos
not
not
<0x0-0xff> (mandatory)
The tos value. Packets in connections are matched against this value.
<0x0-0xff>
mask
mask <0x0-0xff>
mark
not
not
<0x0-0xffffffff> (mandatory)
The mark value. Packets in connections are matched against this value.
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
sctp-chunk-types
not
not
SCOPE (mandatory)
SCOPE
init
INIT chunk.
init
init-ack
init-ack
sack
SACK chunk.
sack
heartbeat
HEARTBEAT chunk.
heartbeat
heartbeat-ack
heartbeat-ack
shutdown
SHUTDOWN chunk.
shutdown
shutdown-ack
shutdown-ack
error
ERROR chunk.
error
cookie-echo
cookie-echo
cookie-ack
cookie-ack
ecn-ecne
ecn-ecne
ecn-cwr
ecn-cwr
asconf
ASCONF chunk.
asconf
asconf-ack
asconf-ack
forward-tsn
forward-tsn
data
DATA chunk.
examined
Examined flags.
examined EXAMINED
EXAMINED Description
values
I SACK chunk should be sent back without delay.
U Indicates this data is an unordered chunk and the stream sequence number is invalid. If an un-
ordered chunk is fragmented then each fragment has this flag set.
B Marks the beginning fragment. An unfragmented chunk has this flag set.
E Marks the end fragment. An unfragmented chunk has this flag set.
set
Set flags.
set SET
SET Description
values
I SACK chunk should be sent back without delay.
U Indicates this data is an unordered chunk and the stream sequence number is invalid. If an unordered
chunk is fragmented then each fragment has this flag set.
B Marks the beginning fragment. An unfragmented chunk has this flag set.
E Marks the end fragment. An unfragmented chunk has this flag set.
abort
ABORT chunk.
examined
Examined flags.
examined EXAMINED
EXAMINED Means the sender sent its own Verification Tag (that receiver should check).
set
Set flags.
set SET
SET Means the sender sent its own Verification Tag (that receiver should check).
shutdown-complete
examined
Examined flags.
examined EXAMINED
EXAMINED Means the sender sent its own Verification Tag (that receiver should check).
set
Set flags.
set SET
SET Means the sender sent its own Verification Tag (that receiver should check).
outbound-interface
Name of an interface via which a packet is going to be sent. Only for forward, output and postrouting.
not
not
<string> (mandatory)
<string>
action
STANDARD
Standard action.
STANDARD
chain
chain <leafref>
dscp
Alters the value of the DSCP bits within the tos header of the IPv4 packet.
dscp DSCP
connmark
Sets the mark value associated with a connection. The mark is 32 bits wide.
connmark \
set-xmark <0x0-0xffffffff> mask <0x0-0xffffffff> \
save-mark nfmask <0x0-0xffffffff> ctmask <0x0-0xffffffff> \
restore-mark nfmask <0x0-0xffffffff> ctmask <0x0-0xffffffff>
set-xmark
Zero out the bits given by mask and XOR value into the ctmark.
<0x0-0xffffffff> (mandatory)
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
save-mark
Copy the packet mark (nfmark) to the connection mark (ctmark) using the given masks. The new value is determined
as follows: ctmark = (ctmark & ~ctmask) ^ (nfmark & nfmask) i.e. ctmask defines what bits to clear and nfmask
what bits of the nfmark to XOR into the ctmark. ctmask and nfmask default to 0xFFFFFFFF.
nfmask
nfmask <0x0-0xffffffff>
ctmask
ctmask <0x0-0xffffffff>
restore-mark
Copy the connection mark (ctmark) to the packet mark (nfmark) using the given masks. The new ctmark value is
determined as follows: nfmark = (nfmark & ~nfmask) ^ (ctmark & ctmask) i.e. nfmask defines what bits to clear
and ctmask what bits of the ctmark to XOR into the packet mark. ctmask and nfmask default to 0xFFFFFFFF.
restore-mark is only valid in the mangle table.
nfmask
nfmask <0x0-0xffffffff>
ctmask
ctmask <0x0-0xffffffff>
log
level
Level of logging.
level LEVEL
prefix
prefix <string>
additional-infos
additional-infos ADDITIONAL-INFOS
mark
<0x0-0xffffffff> (mandatory)
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
tcpmss
Alters the MSS value of TCP SYN packets, to control the maximum size for that connection.
set-mss
set-mss <uint32>
clamp-mss-to-pmtu
clamp-mss-to-pmtu
tos
<0x0-0xff> (mandatory)
<0x0-0xff>
mask
mask <0x0-0xff>
Packets.
vrouter> show state vrf <vrf> firewall ipv4 mangle output rule <uint64> counters␣
˓→packets
Bytes.
vrouter> show state vrf <vrf> firewall ipv4 mangle output rule <uint64> counters bytes
postrouting
policy
Default value
accept
Packets.
vrouter> show state vrf <vrf> firewall ipv4 mangle postrouting packets
Bytes.
vrouter> show state vrf <vrf> firewall ipv4 mangle postrouting bytes
rule
description
description <string>
protocol
not
not
VALUE (mandatory)
VALUE
VALUE Description
values
tcp TCP protocol.
udp UDP protocol.
sctp SCTP protocol.
icmp ICMP protocol.
esp IPsec ESP protocol.
ah IPsec AH protocol.
gre GRE protocol.
l2tp L2TP protocol.
ipip IP-in-IP protocol.
vrrp VRRP protocol.
all All protocols.
<uint16> Protocol. The list can be obtained from the ‘show filter protocols’ command or the show-filter-
protocols rpc.
<string> Protocol. The list can be obtained from the ‘show filter protocols’ command or the show-filter-
protocols rpc.
destination
destination \
address [not] VALUE \
port [not] VALUE \
port-range [not] VALUE \
group [not] <string>
address
not
not
VALUE (mandatory)
VALUE
VALUEDescription
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<A.B.C.D>
An IPv4 address.
<A.B.C.D/M>
An IPv4 prefix: address and CIDR mask.
port
not
not
VALUE (mandatory)
VALUE
VALUE A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
not
not
VALUE (mandatory)
VALUE
group
not
Not match-set.
not
<string> (mandatory)
<string>
source
source \
address [not] VALUE \
port [not] VALUE \
port-range [not] VALUE \
group [not] <string>
address
not
not
VALUE (mandatory)
VALUE
VALUEDescription
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<A.B.C.D>
An IPv4 address.
<A.B.C.D/M>
An IPv4 prefix: address and CIDR mask.
port
not
not
VALUE (mandatory)
VALUE
VALUE A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
not
not
VALUE (mandatory)
VALUE
group
not
Not match-set.
not
<string> (mandatory)
<string>
ipv4
not
not
fragment (mandatory)
fragment
icmp-type
not
not
VALUE (mandatory)
VALUE
tcp-flags
not
not
set
Set flags.
set SET
examined
Examined flags.
examined EXAMINED
conntrack
conntrack \
status [not] VALUE \
state [not] VALUE
status
not
not
VALUE
VALUE
state
not
not
VALUE
VALUE
connmark
not
not
<0x0-0xffffffff> (mandatory)
The mark value. Packets in connections are matched against this value.
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
limit
Matches packets at a limited rate. If not set, the rate value is 3/hour and the burst value is 5.
burst
Maximum initial number of packets to match. This number gets recharged by one every time the rate is not reached,
up to this number.
burst <uint32>
rate
<uint32> (mandatory)
The rate.
<uint32>
UNIT
UNIT
dscp
not
not
VALUE (mandatory)
VALUE
tos
not
not
<0x0-0xff> (mandatory)
The tos value. Packets in connections are matched against this value.
<0x0-0xff>
mask
mask <0x0-0xff>
mark
not
not
<0x0-0xffffffff> (mandatory)
The mark value. Packets in connections are matched against this value.
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
sctp-chunk-types
not
not
SCOPE (mandatory)
SCOPE
init
INIT chunk.
init
init-ack
init-ack
sack
SACK chunk.
sack
heartbeat
HEARTBEAT chunk.
heartbeat
heartbeat-ack
heartbeat-ack
shutdown
SHUTDOWN chunk.
shutdown
shutdown-ack
shutdown-ack
error
ERROR chunk.
error
cookie-echo
cookie-echo
cookie-ack
cookie-ack
ecn-ecne
ecn-ecne
ecn-cwr
ecn-cwr
asconf
ASCONF chunk.
asconf
asconf-ack
asconf-ack
forward-tsn
forward-tsn
data
DATA chunk.
examined
Examined flags.
examined EXAMINED
EXAMINED Description
values
I SACK chunk should be sent back without delay.
U Indicates this data is an unordered chunk and the stream sequence number is invalid. If an un-
ordered chunk is fragmented then each fragment has this flag set.
B Marks the beginning fragment. An unfragmented chunk has this flag set.
E Marks the end fragment. An unfragmented chunk has this flag set.
set
Set flags.
set SET
SET Description
values
I SACK chunk should be sent back without delay.
U Indicates this data is an unordered chunk and the stream sequence number is invalid. If an unordered
chunk is fragmented then each fragment has this flag set.
B Marks the beginning fragment. An unfragmented chunk has this flag set.
E Marks the end fragment. An unfragmented chunk has this flag set.
abort
ABORT chunk.
examined
Examined flags.
examined EXAMINED
EXAMINED Means the sender sent its own Verification Tag (that receiver should check).
set
Set flags.
set SET
SET Means the sender sent its own Verification Tag (that receiver should check).
shutdown-complete
examined
Examined flags.
examined EXAMINED
EXAMINED Means the sender sent its own Verification Tag (that receiver should check).
set
Set flags.
set SET
SET Means the sender sent its own Verification Tag (that receiver should check).
outbound-interface
Name of an interface via which a packet is going to be sent. Only for forward, output and postrouting.
not
not
<string> (mandatory)
<string>
action
STANDARD
Standard action.
STANDARD
chain
chain <leafref>
dscp
Alters the value of the DSCP bits within the tos header of the IPv4 packet.
dscp DSCP
connmark
Sets the mark value associated with a connection. The mark is 32 bits wide.
connmark \
set-xmark <0x0-0xffffffff> mask <0x0-0xffffffff> \
save-mark nfmask <0x0-0xffffffff> ctmask <0x0-0xffffffff> \
restore-mark nfmask <0x0-0xffffffff> ctmask <0x0-0xffffffff>
set-xmark
Zero out the bits given by mask and XOR value into the ctmark.
<0x0-0xffffffff> (mandatory)
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
save-mark
Copy the packet mark (nfmark) to the connection mark (ctmark) using the given masks. The new value is determined
as follows: ctmark = (ctmark & ~ctmask) ^ (nfmark & nfmask) i.e. ctmask defines what bits to clear and nfmask
what bits of the nfmark to XOR into the ctmark. ctmask and nfmask default to 0xFFFFFFFF.
nfmask
nfmask <0x0-0xffffffff>
ctmask
ctmask <0x0-0xffffffff>
restore-mark
Copy the connection mark (ctmark) to the packet mark (nfmark) using the given masks. The new ctmark value is
determined as follows: nfmark = (nfmark & ~nfmask) ^ (ctmark & ctmask) i.e. nfmask defines what bits to clear
and ctmask what bits of the ctmark to XOR into the packet mark. ctmask and nfmask default to 0xFFFFFFFF.
restore-mark is only valid in the mangle table.
nfmask
nfmask <0x0-0xffffffff>
ctmask
ctmask <0x0-0xffffffff>
log
level
Level of logging.
level LEVEL
prefix
prefix <string>
additional-infos
additional-infos ADDITIONAL-INFOS
mark
<0x0-0xffffffff> (mandatory)
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
tcpmss
Alters the MSS value of TCP SYN packets, to control the maximum size for that connection.
set-mss
set-mss <uint32>
clamp-mss-to-pmtu
clamp-mss-to-pmtu
tos
<0x0-0xff> (mandatory)
<0x0-0xff>
mask
mask <0x0-0xff>
Packets.
vrouter> show state vrf <vrf> firewall ipv4 mangle postrouting rule <uint64> counters␣
˓→packets
Bytes.
vrouter> show state vrf <vrf> firewall ipv4 mangle postrouting rule <uint64> counters␣
˓→bytes
chain
User chain.
vrouter running config# vrf <vrf> firewall ipv4 mangle chain <string>
policy
vrouter running config# vrf <vrf> firewall ipv4 mangle chain <string>
vrouter running chain <string># policy POLICY
Default value
accept
Packets.
vrouter> show state vrf <vrf> firewall ipv4 mangle chain <string> packets
Bytes.
vrouter> show state vrf <vrf> firewall ipv4 mangle chain <string> bytes
rule
vrouter running config# vrf <vrf> firewall ipv4 mangle chain <string>
vrouter running chain <string># rule <uint64> description <string> \
... protocol [not] VALUE \
... destination \
... address [not] VALUE \
... port [not] VALUE \
... port-range [not] VALUE \
... group [not] <string> \
... source \
... address [not] VALUE \
... port [not] VALUE \
... port-range [not] VALUE \
... group [not] <string> \
... ipv4 [not] fragment \
... icmp-type [not] VALUE \
... tcp-flags [not] set SET examined EXAMINED \
... conntrack \
... status [not] VALUE \
... state [not] VALUE \
... connmark [not] <0x0-0xffffffff> mask <0x0-0xffffffff> \
... limit burst <uint32> \
... rate <uint32> UNIT \
(continues on next page)
description
description <string>
protocol
not
not
VALUE (mandatory)
VALUE
VALUE Description
values
tcp TCP protocol.
udp UDP protocol.
sctp SCTP protocol.
icmp ICMP protocol.
esp IPsec ESP protocol.
ah IPsec AH protocol.
gre GRE protocol.
l2tp L2TP protocol.
ipip IP-in-IP protocol.
vrrp VRRP protocol.
all All protocols.
<uint16> Protocol. The list can be obtained from the ‘show filter protocols’ command or the show-filter-
protocols rpc.
<string> Protocol. The list can be obtained from the ‘show filter protocols’ command or the show-filter-
protocols rpc.
destination
destination \
address [not] VALUE \
port [not] VALUE \
port-range [not] VALUE \
group [not] <string>
address
not
not
VALUE (mandatory)
VALUE
VALUEDescription
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<A.B.C.D>
An IPv4 address.
<A.B.C.D/M>
An IPv4 prefix: address and CIDR mask.
port
not
not
VALUE (mandatory)
VALUE
VALUE A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
not
not
VALUE (mandatory)
VALUE
group
not
Not match-set.
not
<string> (mandatory)
<string>
source
source \
address [not] VALUE \
port [not] VALUE \
port-range [not] VALUE \
group [not] <string>
address
not
not
VALUE (mandatory)
VALUE
VALUEDescription
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<A.B.C.D>
An IPv4 address.
<A.B.C.D/M>
An IPv4 prefix: address and CIDR mask.
port
not
not
VALUE (mandatory)
VALUE
VALUE A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
not
not
VALUE (mandatory)
VALUE
group
not
Not match-set.
not
<string> (mandatory)
<string>
ipv4
not
not
fragment (mandatory)
fragment
icmp-type
not
not
VALUE (mandatory)
VALUE
tcp-flags
not
not
set
Set flags.
set SET
examined
Examined flags.
examined EXAMINED
conntrack
conntrack \
status [not] VALUE \
state [not] VALUE
status
not
not
VALUE
VALUE
state
not
not
VALUE
VALUE
connmark
not
not
<0x0-0xffffffff> (mandatory)
The mark value. Packets in connections are matched against this value.
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
limit
Matches packets at a limited rate. If not set, the rate value is 3/hour and the burst value is 5.
burst
Maximum initial number of packets to match. This number gets recharged by one every time the rate is not reached,
up to this number.
burst <uint32>
rate
<uint32> (mandatory)
The rate.
<uint32>
UNIT
UNIT
dscp
not
not
VALUE (mandatory)
VALUE
tos
not
not
<0x0-0xff> (mandatory)
The tos value. Packets in connections are matched against this value.
<0x0-0xff>
mask
mask <0x0-0xff>
mark
not
not
<0x0-0xffffffff> (mandatory)
The mark value. Packets in connections are matched against this value.
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
sctp-chunk-types
not
not
SCOPE (mandatory)
SCOPE
init
INIT chunk.
init
init-ack
init-ack
sack
SACK chunk.
sack
heartbeat
HEARTBEAT chunk.
heartbeat
heartbeat-ack
heartbeat-ack
shutdown
SHUTDOWN chunk.
shutdown
shutdown-ack
shutdown-ack
error
ERROR chunk.
error
cookie-echo
cookie-echo
cookie-ack
cookie-ack
ecn-ecne
ecn-ecne
ecn-cwr
ecn-cwr
asconf
ASCONF chunk.
asconf
asconf-ack
asconf-ack
forward-tsn
forward-tsn
data
DATA chunk.
examined
Examined flags.
examined EXAMINED
EXAMINED Description
values
I SACK chunk should be sent back without delay.
U Indicates this data is an unordered chunk and the stream sequence number is invalid. If an un-
ordered chunk is fragmented then each fragment has this flag set.
B Marks the beginning fragment. An unfragmented chunk has this flag set.
E Marks the end fragment. An unfragmented chunk has this flag set.
set
Set flags.
set SET
SET Description
values
I SACK chunk should be sent back without delay.
U Indicates this data is an unordered chunk and the stream sequence number is invalid. If an unordered
chunk is fragmented then each fragment has this flag set.
B Marks the beginning fragment. An unfragmented chunk has this flag set.
E Marks the end fragment. An unfragmented chunk has this flag set.
abort
ABORT chunk.
examined
Examined flags.
examined EXAMINED
EXAMINED Means the sender sent its own Verification Tag (that receiver should check).
set
Set flags.
set SET
SET Means the sender sent its own Verification Tag (that receiver should check).
shutdown-complete
examined
Examined flags.
examined EXAMINED
EXAMINED Means the sender sent its own Verification Tag (that receiver should check).
set
Set flags.
set SET
SET Means the sender sent its own Verification Tag (that receiver should check).
inbound-interface
Name of an interface via which a packet was received. Only for input, forward and prerouting.
not
not
<string> (mandatory)
<string>
outbound-interface
Name of an interface via which a packet is going to be sent. Only for forward, output and postrouting.
not
not
<string> (mandatory)
<string>
rpfilter
Performs a reverse path filter test on a packet. If a reply to the packet would be sent via the same interface that the
packet arrived on, the packet will match.
invert
This will invert the sense of the match. Instead of matching packets that passed the reverse path filter test, match
those that have failed it.
invert true|false
Default value
false
action
STANDARD
Standard action.
STANDARD
chain
chain <leafref>
dscp
Alters the value of the DSCP bits within the tos header of the IPv4 packet.
dscp DSCP
reject
reject REJECT
connmark
Sets the mark value associated with a connection. The mark is 32 bits wide.
connmark \
set-xmark <0x0-0xffffffff> mask <0x0-0xffffffff> \
save-mark nfmask <0x0-0xffffffff> ctmask <0x0-0xffffffff> \
restore-mark nfmask <0x0-0xffffffff> ctmask <0x0-0xffffffff>
set-xmark
Zero out the bits given by mask and XOR value into the ctmark.
<0x0-0xffffffff> (mandatory)
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
save-mark
Copy the packet mark (nfmark) to the connection mark (ctmark) using the given masks. The new value is determined
as follows: ctmark = (ctmark & ~ctmask) ^ (nfmark & nfmask) i.e. ctmask defines what bits to clear and nfmask
what bits of the nfmark to XOR into the ctmark. ctmask and nfmask default to 0xFFFFFFFF.
nfmask
nfmask <0x0-0xffffffff>
ctmask
ctmask <0x0-0xffffffff>
restore-mark
Copy the connection mark (ctmark) to the packet mark (nfmark) using the given masks. The new ctmark value is
determined as follows: nfmark = (nfmark & ~nfmask) ^ (ctmark & ctmask) i.e. nfmask defines what bits to clear
and ctmask what bits of the ctmark to XOR into the packet mark. ctmask and nfmask default to 0xFFFFFFFF.
restore-mark is only valid in the mangle table.
nfmask
nfmask <0x0-0xffffffff>
ctmask
ctmask <0x0-0xffffffff>
log
level
Level of logging.
level LEVEL
prefix
prefix <string>
additional-infos
additional-infos ADDITIONAL-INFOS
mark
<0x0-0xffffffff> (mandatory)
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
tcpmss
Alters the MSS value of TCP SYN packets, to control the maximum size for that connection.
set-mss
set-mss <uint32>
clamp-mss-to-pmtu
clamp-mss-to-pmtu
tos
<0x0-0xff> (mandatory)
<0x0-0xff>
mask
mask <0x0-0xff>
Packets.
vrouter> show state vrf <vrf> firewall ipv4 mangle chain <string> rule <uint64>␣
˓→counters packets
Bytes.
vrouter> show state vrf <vrf> firewall ipv4 mangle chain <string> rule <uint64>␣
˓→counters bytes
ipv4 raw
prerouting
policy
Default value
accept
Packets.
vrouter> show state vrf <vrf> firewall ipv4 raw prerouting packets
Bytes.
vrouter> show state vrf <vrf> firewall ipv4 raw prerouting bytes
rule
description
description <string>
protocol
not
not
VALUE (mandatory)
VALUE
VALUE Description
values
tcp TCP protocol.
udp UDP protocol.
sctp SCTP protocol.
icmp ICMP protocol.
esp IPsec ESP protocol.
ah IPsec AH protocol.
gre GRE protocol.
l2tp L2TP protocol.
ipip IP-in-IP protocol.
vrrp VRRP protocol.
all All protocols.
<uint16> Protocol. The list can be obtained from the ‘show filter protocols’ command or the show-filter-
protocols rpc.
<string> Protocol. The list can be obtained from the ‘show filter protocols’ command or the show-filter-
protocols rpc.
destination
destination \
address [not] VALUE \
port [not] VALUE \
port-range [not] VALUE \
group [not] <string>
address
not
not
VALUE (mandatory)
VALUE
VALUEDescription
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<A.B.C.D>
An IPv4 address.
<A.B.C.D/M>
An IPv4 prefix: address and CIDR mask.
port
not
not
VALUE (mandatory)
VALUE
VALUE A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
not
not
VALUE (mandatory)
VALUE
group
not
Not match-set.
not
<string> (mandatory)
<string>
source
source \
address [not] VALUE \
port [not] VALUE \
port-range [not] VALUE \
group [not] <string>
address
not
not
VALUE (mandatory)
VALUE
VALUEDescription
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<A.B.C.D>
An IPv4 address.
<A.B.C.D/M>
An IPv4 prefix: address and CIDR mask.
port
not
not
VALUE (mandatory)
VALUE
VALUE A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
not
not
VALUE (mandatory)
VALUE
group
not
Not match-set.
not
<string> (mandatory)
<string>
ipv4
not
not
fragment (mandatory)
fragment
icmp-type
not
not
VALUE (mandatory)
VALUE
tcp-flags
not
not
set
Set flags.
set SET
examined
Examined flags.
examined EXAMINED
conntrack
conntrack \
status [not] VALUE \
state [not] VALUE
status
not
not
VALUE
VALUE
state
not
not
VALUE
VALUE
connmark
not
not
<0x0-0xffffffff> (mandatory)
The mark value. Packets in connections are matched against this value.
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
limit
Matches packets at a limited rate. If not set, the rate value is 3/hour and the burst value is 5.
burst
Maximum initial number of packets to match. This number gets recharged by one every time the rate is not reached,
up to this number.
burst <uint32>
rate
<uint32> (mandatory)
The rate.
<uint32>
UNIT
UNIT
dscp
not
not
VALUE (mandatory)
VALUE
tos
not
not
<0x0-0xff> (mandatory)
The tos value. Packets in connections are matched against this value.
<0x0-0xff>
mask
mask <0x0-0xff>
mark
not
not
<0x0-0xffffffff> (mandatory)
The mark value. Packets in connections are matched against this value.
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
sctp-chunk-types
not
not
SCOPE (mandatory)
SCOPE
init
INIT chunk.
init
init-ack
init-ack
sack
SACK chunk.
sack
heartbeat
HEARTBEAT chunk.
heartbeat
heartbeat-ack
heartbeat-ack
shutdown
SHUTDOWN chunk.
shutdown
shutdown-ack
shutdown-ack
error
ERROR chunk.
error
cookie-echo
cookie-echo
cookie-ack
cookie-ack
ecn-ecne
ecn-ecne
ecn-cwr
ecn-cwr
asconf
ASCONF chunk.
asconf
asconf-ack
asconf-ack
forward-tsn
forward-tsn
data
DATA chunk.
examined
Examined flags.
examined EXAMINED
EXAMINED Description
values
I SACK chunk should be sent back without delay.
U Indicates this data is an unordered chunk and the stream sequence number is invalid. If an un-
ordered chunk is fragmented then each fragment has this flag set.
B Marks the beginning fragment. An unfragmented chunk has this flag set.
E Marks the end fragment. An unfragmented chunk has this flag set.
set
Set flags.
set SET
SET Description
values
I SACK chunk should be sent back without delay.
U Indicates this data is an unordered chunk and the stream sequence number is invalid. If an unordered
chunk is fragmented then each fragment has this flag set.
B Marks the beginning fragment. An unfragmented chunk has this flag set.
E Marks the end fragment. An unfragmented chunk has this flag set.
abort
ABORT chunk.
examined
Examined flags.
examined EXAMINED
EXAMINED Means the sender sent its own Verification Tag (that receiver should check).
set
Set flags.
set SET
SET Means the sender sent its own Verification Tag (that receiver should check).
shutdown-complete
examined
Examined flags.
examined EXAMINED
EXAMINED Means the sender sent its own Verification Tag (that receiver should check).
set
Set flags.
set SET
SET Means the sender sent its own Verification Tag (that receiver should check).
inbound-interface
Name of an interface via which a packet was received. Only for input, forward and prerouting.
not
not
<string> (mandatory)
<string>
rpfilter
Performs a reverse path filter test on a packet. If a reply to the packet would be sent via the same interface that the
packet arrived on, the packet will match.
invert
This will invert the sense of the match. Instead of matching packets that passed the reverse path filter test, match
those that have failed it.
invert true|false
Default value
false
action
STANDARD
Standard action.
STANDARD
chain
chain <leafref>
notrack (deprecated)
Attention:
Deprecated since: 2021-09-07
Obsolete in release: 22q1
Description: notrack action is no longer supported.
Replacement: none
notrack
connmark
Sets the mark value associated with a connection. The mark is 32 bits wide.
connmark \
set-xmark <0x0-0xffffffff> mask <0x0-0xffffffff> \
save-mark nfmask <0x0-0xffffffff> ctmask <0x0-0xffffffff> \
restore-mark nfmask <0x0-0xffffffff> ctmask <0x0-0xffffffff>
set-xmark
Zero out the bits given by mask and XOR value into the ctmark.
<0x0-0xffffffff> (mandatory)
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
save-mark
Copy the packet mark (nfmark) to the connection mark (ctmark) using the given masks. The new value is determined
as follows: ctmark = (ctmark & ~ctmask) ^ (nfmark & nfmask) i.e. ctmask defines what bits to clear and nfmask
what bits of the nfmark to XOR into the ctmark. ctmask and nfmask default to 0xFFFFFFFF.
nfmask
nfmask <0x0-0xffffffff>
ctmask
ctmask <0x0-0xffffffff>
restore-mark
Copy the connection mark (ctmark) to the packet mark (nfmark) using the given masks. The new ctmark value is
determined as follows: nfmark = (nfmark & ~nfmask) ^ (ctmark & ctmask) i.e. nfmask defines what bits to clear
and ctmask what bits of the ctmark to XOR into the packet mark. ctmask and nfmask default to 0xFFFFFFFF.
restore-mark is only valid in the mangle table.
nfmask
nfmask <0x0-0xffffffff>
ctmask
ctmask <0x0-0xffffffff>
log
level
Level of logging.
level LEVEL
prefix
prefix <string>
additional-infos
additional-infos ADDITIONAL-INFOS
mark
<0x0-0xffffffff> (mandatory)
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
tcpmss
Alters the MSS value of TCP SYN packets, to control the maximum size for that connection.
set-mss
set-mss <uint32>
clamp-mss-to-pmtu
clamp-mss-to-pmtu
Packets.
vrouter> show state vrf <vrf> firewall ipv4 raw prerouting rule <uint64> counters␣
˓→packets
Bytes.
vrouter> show state vrf <vrf> firewall ipv4 raw prerouting rule <uint64> counters bytes
output
policy
Default value
accept
Packets.
vrouter> show state vrf <vrf> firewall ipv4 raw output packets
Bytes.
vrouter> show state vrf <vrf> firewall ipv4 raw output bytes
rule
description
description <string>
protocol
not
not
VALUE (mandatory)
VALUE
VALUE Description
values
tcp TCP protocol.
udp UDP protocol.
sctp SCTP protocol.
icmp ICMP protocol.
esp IPsec ESP protocol.
ah IPsec AH protocol.
gre GRE protocol.
l2tp L2TP protocol.
ipip IP-in-IP protocol.
vrrp VRRP protocol.
all All protocols.
<uint16> Protocol. The list can be obtained from the ‘show filter protocols’ command or the show-filter-
protocols rpc.
<string> Protocol. The list can be obtained from the ‘show filter protocols’ command or the show-filter-
protocols rpc.
destination
destination \
address [not] VALUE \
port [not] VALUE \
port-range [not] VALUE \
group [not] <string>
address
not
not
VALUE (mandatory)
VALUE
VALUEDescription
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<A.B.C.D>
An IPv4 address.
<A.B.C.D/M>
An IPv4 prefix: address and CIDR mask.
port
not
not
VALUE (mandatory)
VALUE
VALUE A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
not
not
VALUE (mandatory)
VALUE
group
not
Not match-set.
not
<string> (mandatory)
<string>
source
source \
address [not] VALUE \
port [not] VALUE \
port-range [not] VALUE \
group [not] <string>
address
not
not
VALUE (mandatory)
VALUE
VALUEDescription
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<A.B.C.D>
An IPv4 address.
<A.B.C.D/M>
An IPv4 prefix: address and CIDR mask.
port
not
not
VALUE (mandatory)
VALUE
VALUE A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
not
not
VALUE (mandatory)
VALUE
group
not
Not match-set.
not
<string> (mandatory)
<string>
ipv4
not
not
fragment (mandatory)
fragment
icmp-type
not
not
VALUE (mandatory)
VALUE
tcp-flags
not
not
set
Set flags.
set SET
examined
Examined flags.
examined EXAMINED
conntrack
conntrack \
status [not] VALUE \
state [not] VALUE
status
not
not
VALUE
VALUE
state
not
not
VALUE
VALUE
connmark
not
not
<0x0-0xffffffff> (mandatory)
The mark value. Packets in connections are matched against this value.
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
limit
Matches packets at a limited rate. If not set, the rate value is 3/hour and the burst value is 5.
burst
Maximum initial number of packets to match. This number gets recharged by one every time the rate is not reached,
up to this number.
burst <uint32>
rate
<uint32> (mandatory)
The rate.
<uint32>
UNIT
UNIT
dscp
not
not
VALUE (mandatory)
VALUE
tos
not
not
<0x0-0xff> (mandatory)
The tos value. Packets in connections are matched against this value.
<0x0-0xff>
mask
mask <0x0-0xff>
mark
not
not
<0x0-0xffffffff> (mandatory)
The mark value. Packets in connections are matched against this value.
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
sctp-chunk-types
not
not
SCOPE (mandatory)
SCOPE
init
INIT chunk.
init
init-ack
init-ack
sack
SACK chunk.
sack
heartbeat
HEARTBEAT chunk.
heartbeat
heartbeat-ack
heartbeat-ack
shutdown
SHUTDOWN chunk.
shutdown
shutdown-ack
shutdown-ack
error
ERROR chunk.
error
cookie-echo
cookie-echo
cookie-ack
cookie-ack
ecn-ecne
ecn-ecne
ecn-cwr
ecn-cwr
asconf
ASCONF chunk.
asconf
asconf-ack
asconf-ack
forward-tsn
forward-tsn
data
DATA chunk.
examined
Examined flags.
examined EXAMINED
EXAMINED Description
values
I SACK chunk should be sent back without delay.
U Indicates this data is an unordered chunk and the stream sequence number is invalid. If an un-
ordered chunk is fragmented then each fragment has this flag set.
B Marks the beginning fragment. An unfragmented chunk has this flag set.
E Marks the end fragment. An unfragmented chunk has this flag set.
set
Set flags.
set SET
SET Description
values
I SACK chunk should be sent back without delay.
U Indicates this data is an unordered chunk and the stream sequence number is invalid. If an unordered
chunk is fragmented then each fragment has this flag set.
B Marks the beginning fragment. An unfragmented chunk has this flag set.
E Marks the end fragment. An unfragmented chunk has this flag set.
abort
ABORT chunk.
examined
Examined flags.
examined EXAMINED
EXAMINED Means the sender sent its own Verification Tag (that receiver should check).
set
Set flags.
set SET
SET Means the sender sent its own Verification Tag (that receiver should check).
shutdown-complete
examined
Examined flags.
examined EXAMINED
EXAMINED Means the sender sent its own Verification Tag (that receiver should check).
set
Set flags.
set SET
SET Means the sender sent its own Verification Tag (that receiver should check).
outbound-interface
Name of an interface via which a packet is going to be sent. Only for forward, output and postrouting.
not
not
<string> (mandatory)
<string>
action
STANDARD
Standard action.
STANDARD
chain
chain <leafref>
notrack (deprecated)
Attention:
Deprecated since: 2021-09-07
Obsolete in release: 22q1
Description: notrack action is no longer supported.
Replacement: none
notrack
connmark
Sets the mark value associated with a connection. The mark is 32 bits wide.
connmark \
set-xmark <0x0-0xffffffff> mask <0x0-0xffffffff> \
save-mark nfmask <0x0-0xffffffff> ctmask <0x0-0xffffffff> \
restore-mark nfmask <0x0-0xffffffff> ctmask <0x0-0xffffffff>
set-xmark
Zero out the bits given by mask and XOR value into the ctmark.
<0x0-0xffffffff> (mandatory)
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
save-mark
Copy the packet mark (nfmark) to the connection mark (ctmark) using the given masks. The new value is determined
as follows: ctmark = (ctmark & ~ctmask) ^ (nfmark & nfmask) i.e. ctmask defines what bits to clear and nfmask
what bits of the nfmark to XOR into the ctmark. ctmask and nfmask default to 0xFFFFFFFF.
nfmask
nfmask <0x0-0xffffffff>
ctmask
ctmask <0x0-0xffffffff>
restore-mark
Copy the connection mark (ctmark) to the packet mark (nfmark) using the given masks. The new ctmark value is
determined as follows: nfmark = (nfmark & ~nfmask) ^ (ctmark & ctmask) i.e. nfmask defines what bits to clear
and ctmask what bits of the ctmark to XOR into the packet mark. ctmask and nfmask default to 0xFFFFFFFF.
restore-mark is only valid in the mangle table.
nfmask
nfmask <0x0-0xffffffff>
ctmask
ctmask <0x0-0xffffffff>
log
level
Level of logging.
level LEVEL
prefix
prefix <string>
additional-infos
additional-infos ADDITIONAL-INFOS
mark
<0x0-0xffffffff> (mandatory)
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
tcpmss
Alters the MSS value of TCP SYN packets, to control the maximum size for that connection.
set-mss
set-mss <uint32>
clamp-mss-to-pmtu
clamp-mss-to-pmtu
Packets.
vrouter> show state vrf <vrf> firewall ipv4 raw output rule <uint64> counters packets
Bytes.
vrouter> show state vrf <vrf> firewall ipv4 raw output rule <uint64> counters bytes
chain
User chain.
vrouter running config# vrf <vrf> firewall ipv4 raw chain <string>
policy
vrouter running config# vrf <vrf> firewall ipv4 raw chain <string>
vrouter running chain <string># policy POLICY
Default value
accept
Packets.
vrouter> show state vrf <vrf> firewall ipv4 raw chain <string> packets
Bytes.
vrouter> show state vrf <vrf> firewall ipv4 raw chain <string> bytes
rule
vrouter running config# vrf <vrf> firewall ipv4 raw chain <string>
vrouter running chain <string># rule <uint64> description <string> \
... protocol [not] VALUE \
... destination \
... address [not] VALUE \
... port [not] VALUE \
... port-range [not] VALUE \
... group [not] <string> \
... source \
... address [not] VALUE \
... port [not] VALUE \
... port-range [not] VALUE \
... group [not] <string> \
... ipv4 [not] fragment \
... icmp-type [not] VALUE \
... tcp-flags [not] set SET examined EXAMINED \
... conntrack \
... status [not] VALUE \
... state [not] VALUE \
... connmark [not] <0x0-0xffffffff> mask <0x0-0xffffffff> \
... limit burst <uint32> \
... rate <uint32> UNIT \
... dscp [not] VALUE \
... tos [not] <0x0-0xff> mask <0x0-0xff> \
... mark [not] <0x0-0xffffffff> mask <0x0-0xffffffff> \
... sctp-chunk-types [not] SCOPE init init-ack sack heartbeat heartbeat-ack \
(continues on next page)
description
description <string>
protocol
not
not
VALUE (mandatory)
VALUE
VALUE Description
values
tcp TCP protocol.
udp UDP protocol.
sctp SCTP protocol.
icmp ICMP protocol.
esp IPsec ESP protocol.
ah IPsec AH protocol.
gre GRE protocol.
l2tp L2TP protocol.
ipip IP-in-IP protocol.
vrrp VRRP protocol.
all All protocols.
<uint16> Protocol. The list can be obtained from the ‘show filter protocols’ command or the show-filter-
protocols rpc.
<string> Protocol. The list can be obtained from the ‘show filter protocols’ command or the show-filter-
protocols rpc.
destination
destination \
address [not] VALUE \
port [not] VALUE \
port-range [not] VALUE \
group [not] <string>
address
not
not
VALUE (mandatory)
VALUE
VALUEDescription
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<A.B.C.D>
An IPv4 address.
<A.B.C.D/M>
An IPv4 prefix: address and CIDR mask.
port
not
not
VALUE (mandatory)
VALUE
VALUE A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
not
not
VALUE (mandatory)
VALUE
group
not
Not match-set.
not
<string> (mandatory)
<string>
source
source \
address [not] VALUE \
port [not] VALUE \
port-range [not] VALUE \
group [not] <string>
address
not
not
VALUE (mandatory)
VALUE
VALUEDescription
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<A.B.C.D>
An IPv4 address.
<A.B.C.D/M>
An IPv4 prefix: address and CIDR mask.
port
not
not
VALUE (mandatory)
VALUE
VALUE A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
not
not
VALUE (mandatory)
VALUE
group
not
Not match-set.
not
<string> (mandatory)
<string>
ipv4
not
not
fragment (mandatory)
fragment
icmp-type
not
not
VALUE (mandatory)
VALUE
tcp-flags
not
not
set
Set flags.
set SET
examined
Examined flags.
examined EXAMINED
conntrack
conntrack \
status [not] VALUE \
state [not] VALUE
status
not
not
VALUE
VALUE
state
not
not
VALUE
VALUE
connmark
not
not
<0x0-0xffffffff> (mandatory)
The mark value. Packets in connections are matched against this value.
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
limit
Matches packets at a limited rate. If not set, the rate value is 3/hour and the burst value is 5.
burst
Maximum initial number of packets to match. This number gets recharged by one every time the rate is not reached,
up to this number.
burst <uint32>
rate
<uint32> (mandatory)
The rate.
<uint32>
UNIT
UNIT
dscp
not
not
VALUE (mandatory)
VALUE
tos
not
not
<0x0-0xff> (mandatory)
The tos value. Packets in connections are matched against this value.
<0x0-0xff>
mask
mask <0x0-0xff>
mark
not
not
<0x0-0xffffffff> (mandatory)
The mark value. Packets in connections are matched against this value.
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
sctp-chunk-types
not
not
SCOPE (mandatory)
SCOPE
init
INIT chunk.
init
init-ack
init-ack
sack
SACK chunk.
sack
heartbeat
HEARTBEAT chunk.
heartbeat
heartbeat-ack
heartbeat-ack
shutdown
SHUTDOWN chunk.
shutdown
shutdown-ack
shutdown-ack
error
ERROR chunk.
error
cookie-echo
cookie-echo
cookie-ack
cookie-ack
ecn-ecne
ecn-ecne
ecn-cwr
ecn-cwr
asconf
ASCONF chunk.
asconf
asconf-ack
asconf-ack
forward-tsn
forward-tsn
data
DATA chunk.
examined
Examined flags.
examined EXAMINED
EXAMINED Description
values
I SACK chunk should be sent back without delay.
U Indicates this data is an unordered chunk and the stream sequence number is invalid. If an un-
ordered chunk is fragmented then each fragment has this flag set.
B Marks the beginning fragment. An unfragmented chunk has this flag set.
E Marks the end fragment. An unfragmented chunk has this flag set.
set
Set flags.
set SET
SET Description
values
I SACK chunk should be sent back without delay.
U Indicates this data is an unordered chunk and the stream sequence number is invalid. If an unordered
chunk is fragmented then each fragment has this flag set.
B Marks the beginning fragment. An unfragmented chunk has this flag set.
E Marks the end fragment. An unfragmented chunk has this flag set.
abort
ABORT chunk.
examined
Examined flags.
examined EXAMINED
EXAMINED Means the sender sent its own Verification Tag (that receiver should check).
set
Set flags.
set SET
SET Means the sender sent its own Verification Tag (that receiver should check).
shutdown-complete
examined
Examined flags.
examined EXAMINED
EXAMINED Means the sender sent its own Verification Tag (that receiver should check).
set
Set flags.
set SET
SET Means the sender sent its own Verification Tag (that receiver should check).
inbound-interface
Name of an interface via which a packet was received. Only for input, forward and prerouting.
not
not
<string> (mandatory)
<string>
outbound-interface
Name of an interface via which a packet is going to be sent. Only for forward, output and postrouting.
not
not
<string> (mandatory)
<string>
rpfilter
Performs a reverse path filter test on a packet. If a reply to the packet would be sent via the same interface that the
packet arrived on, the packet will match.
invert
This will invert the sense of the match. Instead of matching packets that passed the reverse path filter test, match
those that have failed it.
invert true|false
Default value
false
action
STANDARD
Standard action.
STANDARD
chain
chain <leafref>
dscp
Alters the value of the DSCP bits within the tos header of the IPv4 packet.
dscp DSCP
reject
reject REJECT
connmark
Sets the mark value associated with a connection. The mark is 32 bits wide.
connmark \
set-xmark <0x0-0xffffffff> mask <0x0-0xffffffff> \
save-mark nfmask <0x0-0xffffffff> ctmask <0x0-0xffffffff> \
restore-mark nfmask <0x0-0xffffffff> ctmask <0x0-0xffffffff>
set-xmark
Zero out the bits given by mask and XOR value into the ctmark.
<0x0-0xffffffff> (mandatory)
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
save-mark
Copy the packet mark (nfmark) to the connection mark (ctmark) using the given masks. The new value is determined
as follows: ctmark = (ctmark & ~ctmask) ^ (nfmark & nfmask) i.e. ctmask defines what bits to clear and nfmask
what bits of the nfmark to XOR into the ctmark. ctmask and nfmask default to 0xFFFFFFFF.
nfmask
nfmask <0x0-0xffffffff>
ctmask
ctmask <0x0-0xffffffff>
restore-mark
Copy the connection mark (ctmark) to the packet mark (nfmark) using the given masks. The new ctmark value is
determined as follows: nfmark = (nfmark & ~nfmask) ^ (ctmark & ctmask) i.e. nfmask defines what bits to clear
and ctmask what bits of the ctmark to XOR into the packet mark. ctmask and nfmask default to 0xFFFFFFFF.
restore-mark is only valid in the mangle table.
nfmask
nfmask <0x0-0xffffffff>
ctmask
ctmask <0x0-0xffffffff>
log
level
Level of logging.
level LEVEL
prefix
prefix <string>
additional-infos
additional-infos ADDITIONAL-INFOS
mark
<0x0-0xffffffff> (mandatory)
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
tcpmss
Alters the MSS value of TCP SYN packets, to control the maximum size for that connection.
set-mss
set-mss <uint32>
clamp-mss-to-pmtu
clamp-mss-to-pmtu
tos
<0x0-0xff> (mandatory)
<0x0-0xff>
mask
mask <0x0-0xff>
Packets.
vrouter> show state vrf <vrf> firewall ipv4 raw chain <string> rule <uint64> counters␣
˓→packets
Bytes.
vrouter> show state vrf <vrf> firewall ipv4 raw chain <string> rule <uint64> counters␣
˓→bytes
Address group.
address
AD- An IPv4 address without a zone index. This type, derived from ipv4-address, may be used in situations
DRESS where the zone is known from the context and hence no zone index is needed.
Network group.
network
ipv6 filter
Default table.
input
policy
Default value
accept
Packets.
vrouter> show state vrf <vrf> firewall ipv6 filter input packets
Bytes.
vrouter> show state vrf <vrf> firewall ipv6 filter input bytes
rule
description
description <string>
protocol
not
not
VALUE (mandatory)
VALUE
VALUE Description
values
tcp TCP protocol.
udp UDP protocol.
sctp SCTP protocol.
ipv6-icmp ICMPv6 protocol.
esp IPsec ESP protocol.
ah IPsec AH protocol.
gre GRE protocol.
l2tp L2TP protocol.
ipip IP-in-IP protocol.
vrrp VRRP protocol.
all All protocols.
<uint16> Protocol. The list can be obtained from the ‘show filter protocols’ command or the show-filter-
protocols rpc.
<string> Protocol. The list can be obtained from the ‘show filter protocols’ command or the show-filter-
protocols rpc.
destination
destination \
address [not] VALUE \
port [not] VALUE \
port-range [not] VALUE \
group [not] <string>
address
not
not
VALUE (mandatory)
VALUE
VALUEDescription
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<X:X::X:X>
An IPv6 address.
<X:X::X:X/M>
An IPv6 prefix: address and CIDR mask.
port
not
not
VALUE (mandatory)
VALUE
VALUE A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
not
not
VALUE (mandatory)
VALUE
group
not
Not match-set.
not
<string> (mandatory)
<string>
source
source \
address [not] VALUE \
port [not] VALUE \
port-range [not] VALUE \
group [not] <string>
address
not
not
VALUE (mandatory)
VALUE
VALUEDescription
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<X:X::X:X>
An IPv6 address.
<X:X::X:X/M>
An IPv6 prefix: address and CIDR mask.
port
not
not
VALUE (mandatory)
VALUE
VALUE A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
not
not
VALUE (mandatory)
VALUE
group
not
Not match-set.
not
<string> (mandatory)
<string>
icmpv6-type
not
not
VALUE (mandatory)
VALUE
tcp-flags
not
not
set
Set flags.
set SET
examined
Examined flags.
examined EXAMINED
conntrack
conntrack \
status [not] VALUE \
state [not] VALUE
status
not
not
VALUE
VALUE
state
not
not
VALUE
VALUE
connmark
not
not
<0x0-0xffffffff> (mandatory)
The mark value. Packets in connections are matched against this value.
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
limit
Matches packets at a limited rate. If not set, the rate value is 3/hour and the burst value is 5.
burst
Maximum initial number of packets to match. This number gets recharged by one every time the rate is not reached,
up to this number.
burst <uint32>
rate
<uint32> (mandatory)
The rate.
<uint32>
UNIT
UNIT
dscp
not
not
VALUE (mandatory)
VALUE
tos
not
not
<0x0-0xff> (mandatory)
The tos value. Packets in connections are matched against this value.
<0x0-0xff>
mask
mask <0x0-0xff>
mark
not
not
<0x0-0xffffffff> (mandatory)
The mark value. Packets in connections are matched against this value.
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
sctp-chunk-types
not
not
SCOPE (mandatory)
SCOPE
init
INIT chunk.
init
init-ack
init-ack
sack
SACK chunk.
sack
heartbeat
HEARTBEAT chunk.
heartbeat
heartbeat-ack
heartbeat-ack
shutdown
SHUTDOWN chunk.
shutdown
shutdown-ack
shutdown-ack
error
ERROR chunk.
error
cookie-echo
cookie-echo
cookie-ack
cookie-ack
ecn-ecne
ecn-ecne
ecn-cwr
ecn-cwr
asconf
ASCONF chunk.
asconf
asconf-ack
asconf-ack
forward-tsn
forward-tsn
data
DATA chunk.
examined
Examined flags.
examined EXAMINED
EXAMINED Description
values
I SACK chunk should be sent back without delay.
U Indicates this data is an unordered chunk and the stream sequence number is invalid. If an un-
ordered chunk is fragmented then each fragment has this flag set.
B Marks the beginning fragment. An unfragmented chunk has this flag set.
E Marks the end fragment. An unfragmented chunk has this flag set.
set
Set flags.
set SET
SET Description
values
I SACK chunk should be sent back without delay.
U Indicates this data is an unordered chunk and the stream sequence number is invalid. If an unordered
chunk is fragmented then each fragment has this flag set.
B Marks the beginning fragment. An unfragmented chunk has this flag set.
E Marks the end fragment. An unfragmented chunk has this flag set.
abort
ABORT chunk.
examined
Examined flags.
examined EXAMINED
EXAMINED Means the sender sent its own Verification Tag (that receiver should check).
set
Set flags.
set SET
SET Means the sender sent its own Verification Tag (that receiver should check).
shutdown-complete
examined
Examined flags.
examined EXAMINED
EXAMINED Means the sender sent its own Verification Tag (that receiver should check).
set
Set flags.
set SET
SET Means the sender sent its own Verification Tag (that receiver should check).
inbound-interface
Name of an interface via which a packet was received. Only for input, forward and prerouting.
not
not
<string> (mandatory)
<string>
action
STANDARD
Standard action.
STANDARD
chain
chain <string>
reject
reject REJECT
connmark
Sets the mark value associated with a connection. The mark is 32 bits wide.
connmark \
set-xmark <0x0-0xffffffff> mask <0x0-0xffffffff> \
save-mark nfmask <0x0-0xffffffff> ctmask <0x0-0xffffffff> \
restore-mark nfmask <0x0-0xffffffff> ctmask <0x0-0xffffffff>
set-xmark
Zero out the bits given by mask and XOR value into the ctmark.
<0x0-0xffffffff> (mandatory)
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
save-mark
Copy the packet mark (nfmark) to the connection mark (ctmark) using the given masks. The new value is determined
as follows: ctmark = (ctmark & ~ctmask) ^ (nfmark & nfmask) i.e. ctmask defines what bits to clear and nfmask
what bits of the nfmark to XOR into the ctmark. ctmask and nfmask default to 0xFFFFFFFF.
nfmask
nfmask <0x0-0xffffffff>
ctmask
ctmask <0x0-0xffffffff>
restore-mark
Copy the connection mark (ctmark) to the packet mark (nfmark) using the given masks. The new ctmark value is
determined as follows: nfmark = (nfmark & ~nfmask) ^ (ctmark & ctmask) i.e. nfmask defines what bits to clear
and ctmask what bits of the ctmark to XOR into the packet mark. ctmask and nfmask default to 0xFFFFFFFF.
restore-mark is only valid in the mangle table.
nfmask
nfmask <0x0-0xffffffff>
ctmask
ctmask <0x0-0xffffffff>
log
level
Level of logging.
level LEVEL
prefix
prefix <string>
additional-infos
additional-infos ADDITIONAL-INFOS
mark
<0x0-0xffffffff> (mandatory)
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
tcpmss
Alters the MSS value of TCP SYN packets, to control the maximum size for that connection.
set-mss
set-mss <uint32>
clamp-mss-to-pmtu
clamp-mss-to-pmtu
Packets.
vrouter> show state vrf <vrf> firewall ipv6 filter input rule <uint64> counters packets
Bytes.
vrouter> show state vrf <vrf> firewall ipv6 filter input rule <uint64> counters bytes
forward
policy
Default value
accept
Packets.
vrouter> show state vrf <vrf> firewall ipv6 filter forward packets
Bytes.
vrouter> show state vrf <vrf> firewall ipv6 filter forward bytes
rule
description
description <string>
protocol
not
not
VALUE (mandatory)
VALUE
VALUE Description
values
tcp TCP protocol.
udp UDP protocol.
sctp SCTP protocol.
ipv6-icmp ICMPv6 protocol.
esp IPsec ESP protocol.
ah IPsec AH protocol.
gre GRE protocol.
l2tp L2TP protocol.
ipip IP-in-IP protocol.
vrrp VRRP protocol.
all All protocols.
<uint16> Protocol. The list can be obtained from the ‘show filter protocols’ command or the show-filter-
protocols rpc.
<string> Protocol. The list can be obtained from the ‘show filter protocols’ command or the show-filter-
protocols rpc.
destination
destination \
address [not] VALUE \
port [not] VALUE \
port-range [not] VALUE \
group [not] <string>
address
not
not
VALUE (mandatory)
VALUE
VALUEDescription
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<X:X::X:X>
An IPv6 address.
<X:X::X:X/M>
An IPv6 prefix: address and CIDR mask.
port
not
not
VALUE (mandatory)
VALUE
VALUE A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
not
not
VALUE (mandatory)
VALUE
group
not
Not match-set.
not
<string> (mandatory)
<string>
source
source \
address [not] VALUE \
port [not] VALUE \
port-range [not] VALUE \
group [not] <string>
address
not
not
VALUE (mandatory)
VALUE
VALUEDescription
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<X:X::X:X>
An IPv6 address.
<X:X::X:X/M>
An IPv6 prefix: address and CIDR mask.
port
not
not
VALUE (mandatory)
VALUE
VALUE A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
not
not
VALUE (mandatory)
VALUE
group
not
Not match-set.
not
<string> (mandatory)
<string>
icmpv6-type
not
not
VALUE (mandatory)
VALUE
tcp-flags
not
not
set
Set flags.
set SET
examined
Examined flags.
examined EXAMINED
conntrack
conntrack \
status [not] VALUE \
state [not] VALUE
status
not
not
VALUE
VALUE
state
not
not
VALUE
VALUE
connmark
not
not
<0x0-0xffffffff> (mandatory)
The mark value. Packets in connections are matched against this value.
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
limit
Matches packets at a limited rate. If not set, the rate value is 3/hour and the burst value is 5.
burst
Maximum initial number of packets to match. This number gets recharged by one every time the rate is not reached,
up to this number.
burst <uint32>
rate
<uint32> (mandatory)
The rate.
<uint32>
UNIT
UNIT
dscp
not
not
VALUE (mandatory)
VALUE
tos
not
not
<0x0-0xff> (mandatory)
The tos value. Packets in connections are matched against this value.
<0x0-0xff>
mask
mask <0x0-0xff>
mark
not
not
<0x0-0xffffffff> (mandatory)
The mark value. Packets in connections are matched against this value.
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
sctp-chunk-types
not
not
SCOPE (mandatory)
SCOPE
init
INIT chunk.
init
init-ack
init-ack
sack
SACK chunk.
sack
heartbeat
HEARTBEAT chunk.
heartbeat
heartbeat-ack
heartbeat-ack
shutdown
SHUTDOWN chunk.
shutdown
shutdown-ack
shutdown-ack
error
ERROR chunk.
error
cookie-echo
cookie-echo
cookie-ack
cookie-ack
ecn-ecne
ecn-ecne
ecn-cwr
ecn-cwr
asconf
ASCONF chunk.
asconf
asconf-ack
asconf-ack
forward-tsn
forward-tsn
data
DATA chunk.
examined
Examined flags.
examined EXAMINED
EXAMINED Description
values
I SACK chunk should be sent back without delay.
U Indicates this data is an unordered chunk and the stream sequence number is invalid. If an un-
ordered chunk is fragmented then each fragment has this flag set.
B Marks the beginning fragment. An unfragmented chunk has this flag set.
E Marks the end fragment. An unfragmented chunk has this flag set.
set
Set flags.
set SET
SET Description
values
I SACK chunk should be sent back without delay.
U Indicates this data is an unordered chunk and the stream sequence number is invalid. If an unordered
chunk is fragmented then each fragment has this flag set.
B Marks the beginning fragment. An unfragmented chunk has this flag set.
E Marks the end fragment. An unfragmented chunk has this flag set.
abort
ABORT chunk.
examined
Examined flags.
examined EXAMINED
EXAMINED Means the sender sent its own Verification Tag (that receiver should check).
set
Set flags.
set SET
SET Means the sender sent its own Verification Tag (that receiver should check).
shutdown-complete
examined
Examined flags.
examined EXAMINED
EXAMINED Means the sender sent its own Verification Tag (that receiver should check).
set
Set flags.
set SET
SET Means the sender sent its own Verification Tag (that receiver should check).
inbound-interface
Name of an interface via which a packet was received. Only for input, forward and prerouting.
not
not
<string> (mandatory)
<string>
outbound-interface
Name of an interface via which a packet is going to be sent. Only for forward, output and postrouting.
not
not
<string> (mandatory)
<string>
action
STANDARD
Standard action.
STANDARD
chain
chain <string>
reject
reject REJECT
connmark
Sets the mark value associated with a connection. The mark is 32 bits wide.
connmark \
set-xmark <0x0-0xffffffff> mask <0x0-0xffffffff> \
save-mark nfmask <0x0-0xffffffff> ctmask <0x0-0xffffffff> \
restore-mark nfmask <0x0-0xffffffff> ctmask <0x0-0xffffffff>
set-xmark
Zero out the bits given by mask and XOR value into the ctmark.
<0x0-0xffffffff> (mandatory)
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
save-mark
Copy the packet mark (nfmark) to the connection mark (ctmark) using the given masks. The new value is determined
as follows: ctmark = (ctmark & ~ctmask) ^ (nfmark & nfmask) i.e. ctmask defines what bits to clear and nfmask
what bits of the nfmark to XOR into the ctmark. ctmask and nfmask default to 0xFFFFFFFF.
nfmask
nfmask <0x0-0xffffffff>
ctmask
ctmask <0x0-0xffffffff>
restore-mark
Copy the connection mark (ctmark) to the packet mark (nfmark) using the given masks. The new ctmark value is
determined as follows: nfmark = (nfmark & ~nfmask) ^ (ctmark & ctmask) i.e. nfmask defines what bits to clear
and ctmask what bits of the ctmark to XOR into the packet mark. ctmask and nfmask default to 0xFFFFFFFF.
restore-mark is only valid in the mangle table.
nfmask
nfmask <0x0-0xffffffff>
ctmask
ctmask <0x0-0xffffffff>
log
level
Level of logging.
level LEVEL
prefix
prefix <string>
additional-infos
additional-infos ADDITIONAL-INFOS
mark
<0x0-0xffffffff> (mandatory)
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
tcpmss
Alters the MSS value of TCP SYN packets, to control the maximum size for that connection.
set-mss
set-mss <uint32>
clamp-mss-to-pmtu
clamp-mss-to-pmtu
Packets.
vrouter> show state vrf <vrf> firewall ipv6 filter forward rule <uint64> counters␣
˓→packets
Bytes.
vrouter> show state vrf <vrf> firewall ipv6 filter forward rule <uint64> counters bytes
output
Locally-generated packets.
policy
Default value
accept
Packets.
vrouter> show state vrf <vrf> firewall ipv6 filter output packets
Bytes.
vrouter> show state vrf <vrf> firewall ipv6 filter output bytes
rule
description
description <string>
protocol
not
not
VALUE (mandatory)
VALUE
VALUE Description
values
tcp TCP protocol.
udp UDP protocol.
sctp SCTP protocol.
ipv6-icmp ICMPv6 protocol.
esp IPsec ESP protocol.
ah IPsec AH protocol.
gre GRE protocol.
l2tp L2TP protocol.
ipip IP-in-IP protocol.
vrrp VRRP protocol.
all All protocols.
<uint16> Protocol. The list can be obtained from the ‘show filter protocols’ command or the show-filter-
protocols rpc.
<string> Protocol. The list can be obtained from the ‘show filter protocols’ command or the show-filter-
protocols rpc.
destination
destination \
address [not] VALUE \
port [not] VALUE \
port-range [not] VALUE \
group [not] <string>
address
not
not
VALUE (mandatory)
VALUE
VALUEDescription
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<X:X::X:X>
An IPv6 address.
<X:X::X:X/M>
An IPv6 prefix: address and CIDR mask.
port
not
not
VALUE (mandatory)
VALUE
VALUE A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
not
not
VALUE (mandatory)
VALUE
group
not
Not match-set.
not
<string> (mandatory)
<string>
source
source \
address [not] VALUE \
port [not] VALUE \
port-range [not] VALUE \
group [not] <string>
address
not
not
VALUE (mandatory)
VALUE
VALUEDescription
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<X:X::X:X>
An IPv6 address.
<X:X::X:X/M>
An IPv6 prefix: address and CIDR mask.
port
not
not
VALUE (mandatory)
VALUE
VALUE A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
not
not
VALUE (mandatory)
VALUE
group
not
Not match-set.
not
<string> (mandatory)
<string>
icmpv6-type
not
not
VALUE (mandatory)
VALUE
tcp-flags
not
not
set
Set flags.
set SET
examined
Examined flags.
examined EXAMINED
conntrack
conntrack \
status [not] VALUE \
state [not] VALUE
status
not
not
VALUE
VALUE
state
not
not
VALUE
VALUE
connmark
not
not
<0x0-0xffffffff> (mandatory)
The mark value. Packets in connections are matched against this value.
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
limit
Matches packets at a limited rate. If not set, the rate value is 3/hour and the burst value is 5.
burst
Maximum initial number of packets to match. This number gets recharged by one every time the rate is not reached,
up to this number.
burst <uint32>
rate
<uint32> (mandatory)
The rate.
<uint32>
UNIT
UNIT
dscp
not
not
VALUE (mandatory)
VALUE
tos
not
not
<0x0-0xff> (mandatory)
The tos value. Packets in connections are matched against this value.
<0x0-0xff>
mask
mask <0x0-0xff>
mark
not
not
<0x0-0xffffffff> (mandatory)
The mark value. Packets in connections are matched against this value.
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
sctp-chunk-types
not
not
SCOPE (mandatory)
SCOPE
init
INIT chunk.
init
init-ack
init-ack
sack
SACK chunk.
sack
heartbeat
HEARTBEAT chunk.
heartbeat
heartbeat-ack
heartbeat-ack
shutdown
SHUTDOWN chunk.
shutdown
shutdown-ack
shutdown-ack
error
ERROR chunk.
error
cookie-echo
cookie-echo
cookie-ack
cookie-ack
ecn-ecne
ecn-ecne
ecn-cwr
ecn-cwr
asconf
ASCONF chunk.
asconf
asconf-ack
asconf-ack
forward-tsn
forward-tsn
data
DATA chunk.
examined
Examined flags.
examined EXAMINED
EXAMINED Description
values
I SACK chunk should be sent back without delay.
U Indicates this data is an unordered chunk and the stream sequence number is invalid. If an un-
ordered chunk is fragmented then each fragment has this flag set.
B Marks the beginning fragment. An unfragmented chunk has this flag set.
E Marks the end fragment. An unfragmented chunk has this flag set.
set
Set flags.
set SET
SET Description
values
I SACK chunk should be sent back without delay.
U Indicates this data is an unordered chunk and the stream sequence number is invalid. If an unordered
chunk is fragmented then each fragment has this flag set.
B Marks the beginning fragment. An unfragmented chunk has this flag set.
E Marks the end fragment. An unfragmented chunk has this flag set.
abort
ABORT chunk.
examined
Examined flags.
examined EXAMINED
EXAMINED Means the sender sent its own Verification Tag (that receiver should check).
set
Set flags.
set SET
SET Means the sender sent its own Verification Tag (that receiver should check).
shutdown-complete
examined
Examined flags.
examined EXAMINED
EXAMINED Means the sender sent its own Verification Tag (that receiver should check).
set
Set flags.
set SET
SET Means the sender sent its own Verification Tag (that receiver should check).
outbound-interface
Name of an interface via which a packet is going to be sent. Only for forward, output and postrouting.
not
not
<string> (mandatory)
<string>
action
STANDARD
Standard action.
STANDARD
chain
chain <string>
reject
reject REJECT
connmark
Sets the mark value associated with a connection. The mark is 32 bits wide.
connmark \
set-xmark <0x0-0xffffffff> mask <0x0-0xffffffff> \
save-mark nfmask <0x0-0xffffffff> ctmask <0x0-0xffffffff> \
restore-mark nfmask <0x0-0xffffffff> ctmask <0x0-0xffffffff>
set-xmark
Zero out the bits given by mask and XOR value into the ctmark.
<0x0-0xffffffff> (mandatory)
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
save-mark
Copy the packet mark (nfmark) to the connection mark (ctmark) using the given masks. The new value is determined
as follows: ctmark = (ctmark & ~ctmask) ^ (nfmark & nfmask) i.e. ctmask defines what bits to clear and nfmask
what bits of the nfmark to XOR into the ctmark. ctmask and nfmask default to 0xFFFFFFFF.
nfmask
nfmask <0x0-0xffffffff>
ctmask
ctmask <0x0-0xffffffff>
restore-mark
Copy the connection mark (ctmark) to the packet mark (nfmark) using the given masks. The new ctmark value is
determined as follows: nfmark = (nfmark & ~nfmask) ^ (ctmark & ctmask) i.e. nfmask defines what bits to clear
and ctmask what bits of the ctmark to XOR into the packet mark. ctmask and nfmask default to 0xFFFFFFFF.
restore-mark is only valid in the mangle table.
nfmask
nfmask <0x0-0xffffffff>
ctmask
ctmask <0x0-0xffffffff>
log
level
Level of logging.
level LEVEL
prefix
prefix <string>
additional-infos
additional-infos ADDITIONAL-INFOS
mark
<0x0-0xffffffff> (mandatory)
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
tcpmss
Alters the MSS value of TCP SYN packets, to control the maximum size for that connection.
set-mss
set-mss <uint32>
clamp-mss-to-pmtu
clamp-mss-to-pmtu
Packets.
vrouter> show state vrf <vrf> firewall ipv6 filter output rule <uint64> counters␣
˓→packets
Bytes.
vrouter> show state vrf <vrf> firewall ipv6 filter output rule <uint64> counters bytes
chain
User chain.
vrouter running config# vrf <vrf> firewall ipv6 filter chain <string>
policy
vrouter running config# vrf <vrf> firewall ipv6 filter chain <string>
vrouter running chain <string># policy POLICY
Default value
accept
Packets.
vrouter> show state vrf <vrf> firewall ipv6 filter chain <string> packets
Bytes.
vrouter> show state vrf <vrf> firewall ipv6 filter chain <string> bytes
rule
vrouter running config# vrf <vrf> firewall ipv6 filter chain <string>
vrouter running chain <string># rule <uint64> description <string> \
... protocol [not] VALUE \
... destination \
... address [not] VALUE \
... port [not] VALUE \
... port-range [not] VALUE \
... group [not] <string> \
(continues on next page)
description
description <string>
protocol
not
not
VALUE (mandatory)
VALUE
VALUE Description
values
tcp TCP protocol.
udp UDP protocol.
sctp SCTP protocol.
ipv6-icmp ICMPv6 protocol.
esp IPsec ESP protocol.
ah IPsec AH protocol.
gre GRE protocol.
l2tp L2TP protocol.
ipip IP-in-IP protocol.
vrrp VRRP protocol.
all All protocols.
<uint16> Protocol. The list can be obtained from the ‘show filter protocols’ command or the show-filter-
protocols rpc.
<string> Protocol. The list can be obtained from the ‘show filter protocols’ command or the show-filter-
protocols rpc.
destination
destination \
address [not] VALUE \
port [not] VALUE \
port-range [not] VALUE \
group [not] <string>
address
not
not
VALUE (mandatory)
VALUE
VALUEDescription
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<X:X::X:X>
An IPv6 address.
<X:X::X:X/M>
An IPv6 prefix: address and CIDR mask.
port
not
not
VALUE (mandatory)
VALUE
VALUE A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
not
not
VALUE (mandatory)
VALUE
group
not
Not match-set.
not
<string> (mandatory)
<string>
source
source \
address [not] VALUE \
port [not] VALUE \
port-range [not] VALUE \
group [not] <string>
address
not
not
VALUE (mandatory)
VALUE
VALUEDescription
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<X:X::X:X>
An IPv6 address.
<X:X::X:X/M>
An IPv6 prefix: address and CIDR mask.
port
not
not
VALUE (mandatory)
VALUE
VALUE A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
not
not
VALUE (mandatory)
VALUE
group
not
Not match-set.
not
<string> (mandatory)
<string>
icmpv6-type
not
not
VALUE (mandatory)
VALUE
tcp-flags
not
not
set
Set flags.
set SET
examined
Examined flags.
examined EXAMINED
conntrack
conntrack \
status [not] VALUE \
state [not] VALUE
status
not
not
VALUE
VALUE
state
not
not
VALUE
VALUE
connmark
not
not
<0x0-0xffffffff> (mandatory)
The mark value. Packets in connections are matched against this value.
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
limit
Matches packets at a limited rate. If not set, the rate value is 3/hour and the burst value is 5.
burst
Maximum initial number of packets to match. This number gets recharged by one every time the rate is not reached,
up to this number.
burst <uint32>
rate
<uint32> (mandatory)
The rate.
<uint32>
UNIT
UNIT
dscp
not
not
VALUE (mandatory)
VALUE
tos
not
not
<0x0-0xff> (mandatory)
The tos value. Packets in connections are matched against this value.
<0x0-0xff>
mask
mask <0x0-0xff>
mark
not
not
<0x0-0xffffffff> (mandatory)
The mark value. Packets in connections are matched against this value.
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
sctp-chunk-types
not
not
SCOPE (mandatory)
SCOPE
init
INIT chunk.
init
init-ack
init-ack
sack
SACK chunk.
sack
heartbeat
HEARTBEAT chunk.
heartbeat
heartbeat-ack
heartbeat-ack
shutdown
SHUTDOWN chunk.
shutdown
shutdown-ack
shutdown-ack
error
ERROR chunk.
error
cookie-echo
cookie-echo
cookie-ack
cookie-ack
ecn-ecne
ecn-ecne
ecn-cwr
ecn-cwr
asconf
ASCONF chunk.
asconf
asconf-ack
asconf-ack
forward-tsn
forward-tsn
data
DATA chunk.
examined
Examined flags.
examined EXAMINED
EXAMINED Description
values
I SACK chunk should be sent back without delay.
U Indicates this data is an unordered chunk and the stream sequence number is invalid. If an un-
ordered chunk is fragmented then each fragment has this flag set.
B Marks the beginning fragment. An unfragmented chunk has this flag set.
E Marks the end fragment. An unfragmented chunk has this flag set.
set
Set flags.
set SET
SET Description
values
I SACK chunk should be sent back without delay.
U Indicates this data is an unordered chunk and the stream sequence number is invalid. If an unordered
chunk is fragmented then each fragment has this flag set.
B Marks the beginning fragment. An unfragmented chunk has this flag set.
E Marks the end fragment. An unfragmented chunk has this flag set.
abort
ABORT chunk.
examined
Examined flags.
examined EXAMINED
EXAMINED Means the sender sent its own Verification Tag (that receiver should check).
set
Set flags.
set SET
SET Means the sender sent its own Verification Tag (that receiver should check).
shutdown-complete
examined
Examined flags.
examined EXAMINED
EXAMINED Means the sender sent its own Verification Tag (that receiver should check).
set
Set flags.
set SET
SET Means the sender sent its own Verification Tag (that receiver should check).
inbound-interface
Name of an interface via which a packet was received. Only for input, forward and prerouting.
not
not
<string> (mandatory)
<string>
outbound-interface
Name of an interface via which a packet is going to be sent. Only for forward, output and postrouting.
not
not
<string> (mandatory)
<string>
rpfilter
Performs a reverse path filter test on a packet. If a reply to the packet would be sent via the same interface that the
packet arrived on, the packet will match.
invert
This will invert the sense of the match. Instead of matching packets that passed the reverse path filter test, match
those that have failed it.
invert true|false
Default value
false
action
STANDARD
Standard action.
STANDARD
chain
chain <string>
reject
reject REJECT
connmark
Sets the mark value associated with a connection. The mark is 32 bits wide.
connmark \
set-xmark <0x0-0xffffffff> mask <0x0-0xffffffff> \
save-mark nfmask <0x0-0xffffffff> ctmask <0x0-0xffffffff> \
restore-mark nfmask <0x0-0xffffffff> ctmask <0x0-0xffffffff>
set-xmark
Zero out the bits given by mask and XOR value into the ctmark.
<0x0-0xffffffff> (mandatory)
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
save-mark
Copy the packet mark (nfmark) to the connection mark (ctmark) using the given masks. The new value is determined
as follows: ctmark = (ctmark & ~ctmask) ^ (nfmark & nfmask) i.e. ctmask defines what bits to clear and nfmask
what bits of the nfmark to XOR into the ctmark. ctmask and nfmask default to 0xFFFFFFFF.
nfmask
nfmask <0x0-0xffffffff>
ctmask
ctmask <0x0-0xffffffff>
restore-mark
Copy the connection mark (ctmark) to the packet mark (nfmark) using the given masks. The new ctmark value is
determined as follows: nfmark = (nfmark & ~nfmask) ^ (ctmark & ctmask) i.e. nfmask defines what bits to clear
and ctmask what bits of the ctmark to XOR into the packet mark. ctmask and nfmask default to 0xFFFFFFFF.
restore-mark is only valid in the mangle table.
nfmask
nfmask <0x0-0xffffffff>
ctmask
ctmask <0x0-0xffffffff>
log
level
Level of logging.
level LEVEL
prefix
prefix <string>
additional-infos
additional-infos ADDITIONAL-INFOS
mark
<0x0-0xffffffff> (mandatory)
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
tcpmss
Alters the MSS value of TCP SYN packets, to control the maximum size for that connection.
set-mss
set-mss <uint32>
clamp-mss-to-pmtu
clamp-mss-to-pmtu
Packets.
vrouter> show state vrf <vrf> firewall ipv6 filter chain <string> rule <uint64>␣
˓→counters packets
Bytes.
vrouter> show state vrf <vrf> firewall ipv6 filter chain <string> rule <uint64>␣
˓→counters bytes
ipv6 mangle
prerouting
policy
Default value
accept
Packets.
vrouter> show state vrf <vrf> firewall ipv6 mangle prerouting packets
Bytes.
vrouter> show state vrf <vrf> firewall ipv6 mangle prerouting bytes
rule
description
description <string>
protocol
not
not
VALUE (mandatory)
VALUE
VALUE Description
values
tcp TCP protocol.
udp UDP protocol.
sctp SCTP protocol.
ipv6-icmp ICMPv6 protocol.
esp IPsec ESP protocol.
ah IPsec AH protocol.
gre GRE protocol.
l2tp L2TP protocol.
ipip IP-in-IP protocol.
vrrp VRRP protocol.
all All protocols.
<uint16> Protocol. The list can be obtained from the ‘show filter protocols’ command or the show-filter-
protocols rpc.
<string> Protocol. The list can be obtained from the ‘show filter protocols’ command or the show-filter-
protocols rpc.
destination
destination \
address [not] VALUE \
port [not] VALUE \
port-range [not] VALUE \
group [not] <string>
address
not
not
VALUE (mandatory)
VALUE
VALUEDescription
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<X:X::X:X>
An IPv6 address.
<X:X::X:X/M>
An IPv6 prefix: address and CIDR mask.
port
not
not
VALUE (mandatory)
VALUE
VALUE A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
not
not
VALUE (mandatory)
VALUE
group
not
Not match-set.
not
<string> (mandatory)
<string>
source
source \
address [not] VALUE \
port [not] VALUE \
port-range [not] VALUE \
group [not] <string>
address
not
not
VALUE (mandatory)
VALUE
VALUEDescription
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<X:X::X:X>
An IPv6 address.
<X:X::X:X/M>
An IPv6 prefix: address and CIDR mask.
port
not
not
VALUE (mandatory)
VALUE
VALUE A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
not
not
VALUE (mandatory)
VALUE
group
not
Not match-set.
not
<string> (mandatory)
<string>
icmpv6-type
not
not
VALUE (mandatory)
VALUE
tcp-flags
not
not
set
Set flags.
set SET
examined
Examined flags.
examined EXAMINED
conntrack
conntrack \
status [not] VALUE \
state [not] VALUE
status
not
not
VALUE
VALUE
state
not
not
VALUE
VALUE
connmark
not
not
<0x0-0xffffffff> (mandatory)
The mark value. Packets in connections are matched against this value.
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
limit
Matches packets at a limited rate. If not set, the rate value is 3/hour and the burst value is 5.
burst
Maximum initial number of packets to match. This number gets recharged by one every time the rate is not reached,
up to this number.
burst <uint32>
rate
<uint32> (mandatory)
The rate.
<uint32>
UNIT
UNIT
dscp
not
not
VALUE (mandatory)
VALUE
tos
not
not
<0x0-0xff> (mandatory)
The tos value. Packets in connections are matched against this value.
<0x0-0xff>
mask
mask <0x0-0xff>
mark
not
not
<0x0-0xffffffff> (mandatory)
The mark value. Packets in connections are matched against this value.
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
sctp-chunk-types
not
not
SCOPE (mandatory)
SCOPE
init
INIT chunk.
init
init-ack
init-ack
sack
SACK chunk.
sack
heartbeat
HEARTBEAT chunk.
heartbeat
heartbeat-ack
heartbeat-ack
shutdown
SHUTDOWN chunk.
shutdown
shutdown-ack
shutdown-ack
error
ERROR chunk.
error
cookie-echo
cookie-echo
cookie-ack
cookie-ack
ecn-ecne
ecn-ecne
ecn-cwr
ecn-cwr
asconf
ASCONF chunk.
asconf
asconf-ack
asconf-ack
forward-tsn
forward-tsn
data
DATA chunk.
examined
Examined flags.
examined EXAMINED
EXAMINED Description
values
I SACK chunk should be sent back without delay.
U Indicates this data is an unordered chunk and the stream sequence number is invalid. If an un-
ordered chunk is fragmented then each fragment has this flag set.
B Marks the beginning fragment. An unfragmented chunk has this flag set.
E Marks the end fragment. An unfragmented chunk has this flag set.
set
Set flags.
set SET
SET Description
values
I SACK chunk should be sent back without delay.
U Indicates this data is an unordered chunk and the stream sequence number is invalid. If an unordered
chunk is fragmented then each fragment has this flag set.
B Marks the beginning fragment. An unfragmented chunk has this flag set.
E Marks the end fragment. An unfragmented chunk has this flag set.
abort
ABORT chunk.
examined
Examined flags.
examined EXAMINED
EXAMINED Means the sender sent its own Verification Tag (that receiver should check).
set
Set flags.
set SET
SET Means the sender sent its own Verification Tag (that receiver should check).
shutdown-complete
examined
Examined flags.
examined EXAMINED
EXAMINED Means the sender sent its own Verification Tag (that receiver should check).
set
Set flags.
set SET
SET Means the sender sent its own Verification Tag (that receiver should check).
inbound-interface
Name of an interface via which a packet was received. Only for input, forward and prerouting.
not
not
<string> (mandatory)
<string>
rpfilter
Performs a reverse path filter test on a packet. If a reply to the packet would be sent via the same interface that the
packet arrived on, the packet will match.
invert
This will invert the sense of the match. Instead of matching packets that passed the reverse path filter test, match
those that have failed it.
invert true|false
Default value
false
action
STANDARD
Standard action.
STANDARD
chain
chain <string>
connmark
Sets the mark value associated with a connection. The mark is 32 bits wide.
connmark \
set-xmark <0x0-0xffffffff> mask <0x0-0xffffffff> \
save-mark nfmask <0x0-0xffffffff> ctmask <0x0-0xffffffff> \
restore-mark nfmask <0x0-0xffffffff> ctmask <0x0-0xffffffff>
set-xmark
Zero out the bits given by mask and XOR value into the ctmark.
<0x0-0xffffffff> (mandatory)
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
save-mark
Copy the packet mark (nfmark) to the connection mark (ctmark) using the given masks. The new value is determined
as follows: ctmark = (ctmark & ~ctmask) ^ (nfmark & nfmask) i.e. ctmask defines what bits to clear and nfmask
what bits of the nfmark to XOR into the ctmark. ctmask and nfmask default to 0xFFFFFFFF.
nfmask
nfmask <0x0-0xffffffff>
ctmask
ctmask <0x0-0xffffffff>
restore-mark
Copy the connection mark (ctmark) to the packet mark (nfmark) using the given masks. The new ctmark value is
determined as follows: nfmark = (nfmark & ~nfmask) ^ (ctmark & ctmask) i.e. nfmask defines what bits to clear
and ctmask what bits of the ctmark to XOR into the packet mark. ctmask and nfmask default to 0xFFFFFFFF.
restore-mark is only valid in the mangle table.
nfmask
nfmask <0x0-0xffffffff>
ctmask
ctmask <0x0-0xffffffff>
log
level
Level of logging.
level LEVEL
prefix
prefix <string>
additional-infos
additional-infos ADDITIONAL-INFOS
mark
<0x0-0xffffffff> (mandatory)
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
tcpmss
Alters the MSS value of TCP SYN packets, to control the maximum size for that connection.
set-mss
set-mss <uint32>
clamp-mss-to-pmtu
clamp-mss-to-pmtu
Packets.
vrouter> show state vrf <vrf> firewall ipv6 mangle prerouting rule <uint64> counters␣
˓→packets
Bytes.
vrouter> show state vrf <vrf> firewall ipv6 mangle prerouting rule <uint64> counters␣
˓→bytes
input
policy
Default value
accept
Packets.
vrouter> show state vrf <vrf> firewall ipv6 mangle input packets
Bytes.
vrouter> show state vrf <vrf> firewall ipv6 mangle input bytes
rule
description
description <string>
protocol
not
not
VALUE (mandatory)
VALUE
VALUE Description
values
tcp TCP protocol.
udp UDP protocol.
sctp SCTP protocol.
ipv6-icmp ICMPv6 protocol.
esp IPsec ESP protocol.
ah IPsec AH protocol.
gre GRE protocol.
l2tp L2TP protocol.
ipip IP-in-IP protocol.
vrrp VRRP protocol.
all All protocols.
<uint16> Protocol. The list can be obtained from the ‘show filter protocols’ command or the show-filter-
protocols rpc.
<string> Protocol. The list can be obtained from the ‘show filter protocols’ command or the show-filter-
protocols rpc.
destination
destination \
address [not] VALUE \
port [not] VALUE \
port-range [not] VALUE \
group [not] <string>
address
not
not
VALUE (mandatory)
VALUE
VALUEDescription
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<X:X::X:X>
An IPv6 address.
<X:X::X:X/M>
An IPv6 prefix: address and CIDR mask.
port
not
not
VALUE (mandatory)
VALUE
VALUE A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
not
not
VALUE (mandatory)
VALUE
group
not
Not match-set.
not
<string> (mandatory)
<string>
source
source \
address [not] VALUE \
port [not] VALUE \
port-range [not] VALUE \
group [not] <string>
address
not
not
VALUE (mandatory)
VALUE
VALUEDescription
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<X:X::X:X>
An IPv6 address.
<X:X::X:X/M>
An IPv6 prefix: address and CIDR mask.
port
not
not
VALUE (mandatory)
VALUE
VALUE A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
not
not
VALUE (mandatory)
VALUE
group
not
Not match-set.
not
<string> (mandatory)
<string>
icmpv6-type
not
not
VALUE (mandatory)
VALUE
tcp-flags
not
not
set
Set flags.
set SET
examined
Examined flags.
examined EXAMINED
conntrack
conntrack \
status [not] VALUE \
state [not] VALUE
status
not
not
VALUE
VALUE
state
not
not
VALUE
VALUE
connmark
not
not
<0x0-0xffffffff> (mandatory)
The mark value. Packets in connections are matched against this value.
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
limit
Matches packets at a limited rate. If not set, the rate value is 3/hour and the burst value is 5.
burst
Maximum initial number of packets to match. This number gets recharged by one every time the rate is not reached,
up to this number.
burst <uint32>
rate
<uint32> (mandatory)
The rate.
<uint32>
UNIT
UNIT
dscp
not
not
VALUE (mandatory)
VALUE
tos
not
not
<0x0-0xff> (mandatory)
The tos value. Packets in connections are matched against this value.
<0x0-0xff>
mask
mask <0x0-0xff>
mark
not
not
<0x0-0xffffffff> (mandatory)
The mark value. Packets in connections are matched against this value.
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
sctp-chunk-types
not
not
SCOPE (mandatory)
SCOPE
init
INIT chunk.
init
init-ack
init-ack
sack
SACK chunk.
sack
heartbeat
HEARTBEAT chunk.
heartbeat
heartbeat-ack
heartbeat-ack
shutdown
SHUTDOWN chunk.
shutdown
shutdown-ack
shutdown-ack
error
ERROR chunk.
error
cookie-echo
cookie-echo
cookie-ack
cookie-ack
ecn-ecne
ecn-ecne
ecn-cwr
ecn-cwr
asconf
ASCONF chunk.
asconf
asconf-ack
asconf-ack
forward-tsn
forward-tsn
data
DATA chunk.
examined
Examined flags.
examined EXAMINED
EXAMINED Description
values
I SACK chunk should be sent back without delay.
U Indicates this data is an unordered chunk and the stream sequence number is invalid. If an un-
ordered chunk is fragmented then each fragment has this flag set.
B Marks the beginning fragment. An unfragmented chunk has this flag set.
E Marks the end fragment. An unfragmented chunk has this flag set.
set
Set flags.
set SET
SET Description
values
I SACK chunk should be sent back without delay.
U Indicates this data is an unordered chunk and the stream sequence number is invalid. If an unordered
chunk is fragmented then each fragment has this flag set.
B Marks the beginning fragment. An unfragmented chunk has this flag set.
E Marks the end fragment. An unfragmented chunk has this flag set.
abort
ABORT chunk.
examined
Examined flags.
examined EXAMINED
EXAMINED Means the sender sent its own Verification Tag (that receiver should check).
set
Set flags.
set SET
SET Means the sender sent its own Verification Tag (that receiver should check).
shutdown-complete
examined
Examined flags.
examined EXAMINED
EXAMINED Means the sender sent its own Verification Tag (that receiver should check).
set
Set flags.
set SET
SET Means the sender sent its own Verification Tag (that receiver should check).
inbound-interface
Name of an interface via which a packet was received. Only for input, forward and prerouting.
not
not
<string> (mandatory)
<string>
action
STANDARD
Standard action.
STANDARD
chain
chain <string>
dscp
Alters the value of the DSCP bits within the tos header of the IPv4 packet.
dscp DSCP
connmark
Sets the mark value associated with a connection. The mark is 32 bits wide.
connmark \
set-xmark <0x0-0xffffffff> mask <0x0-0xffffffff> \
save-mark nfmask <0x0-0xffffffff> ctmask <0x0-0xffffffff> \
restore-mark nfmask <0x0-0xffffffff> ctmask <0x0-0xffffffff>
set-xmark
Zero out the bits given by mask and XOR value into the ctmark.
<0x0-0xffffffff> (mandatory)
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
save-mark
Copy the packet mark (nfmark) to the connection mark (ctmark) using the given masks. The new value is determined
as follows: ctmark = (ctmark & ~ctmask) ^ (nfmark & nfmask) i.e. ctmask defines what bits to clear and nfmask
what bits of the nfmark to XOR into the ctmark. ctmask and nfmask default to 0xFFFFFFFF.
nfmask
nfmask <0x0-0xffffffff>
ctmask
ctmask <0x0-0xffffffff>
restore-mark
Copy the connection mark (ctmark) to the packet mark (nfmark) using the given masks. The new ctmark value is
determined as follows: nfmark = (nfmark & ~nfmask) ^ (ctmark & ctmask) i.e. nfmask defines what bits to clear
and ctmask what bits of the ctmark to XOR into the packet mark. ctmask and nfmask default to 0xFFFFFFFF.
restore-mark is only valid in the mangle table.
nfmask
nfmask <0x0-0xffffffff>
ctmask
ctmask <0x0-0xffffffff>
log
level
Level of logging.
level LEVEL
prefix
prefix <string>
additional-infos
additional-infos ADDITIONAL-INFOS
mark
<0x0-0xffffffff> (mandatory)
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
tcpmss
Alters the MSS value of TCP SYN packets, to control the maximum size for that connection.
set-mss
set-mss <uint32>
clamp-mss-to-pmtu
clamp-mss-to-pmtu
tos
<0x0-0xff> (mandatory)
<0x0-0xff>
mask
mask <0x0-0xff>
Packets.
vrouter> show state vrf <vrf> firewall ipv6 mangle input rule <uint64> counters packets
Bytes.
vrouter> show state vrf <vrf> firewall ipv6 mangle input rule <uint64> counters bytes
forward
policy
Default value
accept
Packets.
vrouter> show state vrf <vrf> firewall ipv6 mangle forward packets
Bytes.
vrouter> show state vrf <vrf> firewall ipv6 mangle forward bytes
rule
description
description <string>
protocol
not
not
VALUE (mandatory)
VALUE
VALUE Description
values
tcp TCP protocol.
udp UDP protocol.
sctp SCTP protocol.
ipv6-icmp ICMPv6 protocol.
esp IPsec ESP protocol.
ah IPsec AH protocol.
gre GRE protocol.
l2tp L2TP protocol.
ipip IP-in-IP protocol.
vrrp VRRP protocol.
all All protocols.
<uint16> Protocol. The list can be obtained from the ‘show filter protocols’ command or the show-filter-
protocols rpc.
<string> Protocol. The list can be obtained from the ‘show filter protocols’ command or the show-filter-
protocols rpc.
destination
destination \
address [not] VALUE \
port [not] VALUE \
port-range [not] VALUE \
group [not] <string>
address
not
not
VALUE (mandatory)
VALUE
VALUEDescription
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<X:X::X:X>
An IPv6 address.
<X:X::X:X/M>
An IPv6 prefix: address and CIDR mask.
port
not
not
VALUE (mandatory)
VALUE
VALUE A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
not
not
VALUE (mandatory)
VALUE
group
not
Not match-set.
not
<string> (mandatory)
<string>
source
source \
address [not] VALUE \
port [not] VALUE \
port-range [not] VALUE \
group [not] <string>
address
not
not
VALUE (mandatory)
VALUE
VALUEDescription
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<X:X::X:X>
An IPv6 address.
<X:X::X:X/M>
An IPv6 prefix: address and CIDR mask.
port
not
not
VALUE (mandatory)
VALUE
VALUE A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
not
not
VALUE (mandatory)
VALUE
group
not
Not match-set.
not
<string> (mandatory)
<string>
icmpv6-type
not
not
VALUE (mandatory)
VALUE
tcp-flags
not
not
set
Set flags.
set SET
examined
Examined flags.
examined EXAMINED
conntrack
conntrack \
status [not] VALUE \
state [not] VALUE
status
not
not
VALUE
VALUE
state
not
not
VALUE
VALUE
connmark
not
not
<0x0-0xffffffff> (mandatory)
The mark value. Packets in connections are matched against this value.
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
limit
Matches packets at a limited rate. If not set, the rate value is 3/hour and the burst value is 5.
burst
Maximum initial number of packets to match. This number gets recharged by one every time the rate is not reached,
up to this number.
burst <uint32>
rate
<uint32> (mandatory)
The rate.
<uint32>
UNIT
UNIT
dscp
not
not
VALUE (mandatory)
VALUE
tos
not
not
<0x0-0xff> (mandatory)
The tos value. Packets in connections are matched against this value.
<0x0-0xff>
mask
mask <0x0-0xff>
mark
not
not
<0x0-0xffffffff> (mandatory)
The mark value. Packets in connections are matched against this value.
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
sctp-chunk-types
not
not
SCOPE (mandatory)
SCOPE
init
INIT chunk.
init
init-ack
init-ack
sack
SACK chunk.
sack
heartbeat
HEARTBEAT chunk.
heartbeat
heartbeat-ack
heartbeat-ack
shutdown
SHUTDOWN chunk.
shutdown
shutdown-ack
shutdown-ack
error
ERROR chunk.
error
cookie-echo
cookie-echo
cookie-ack
cookie-ack
ecn-ecne
ecn-ecne
ecn-cwr
ecn-cwr
asconf
ASCONF chunk.
asconf
asconf-ack
asconf-ack
forward-tsn
forward-tsn
data
DATA chunk.
examined
Examined flags.
examined EXAMINED
EXAMINED Description
values
I SACK chunk should be sent back without delay.
U Indicates this data is an unordered chunk and the stream sequence number is invalid. If an un-
ordered chunk is fragmented then each fragment has this flag set.
B Marks the beginning fragment. An unfragmented chunk has this flag set.
E Marks the end fragment. An unfragmented chunk has this flag set.
set
Set flags.
set SET
SET Description
values
I SACK chunk should be sent back without delay.
U Indicates this data is an unordered chunk and the stream sequence number is invalid. If an unordered
chunk is fragmented then each fragment has this flag set.
B Marks the beginning fragment. An unfragmented chunk has this flag set.
E Marks the end fragment. An unfragmented chunk has this flag set.
abort
ABORT chunk.
examined
Examined flags.
examined EXAMINED
EXAMINED Means the sender sent its own Verification Tag (that receiver should check).
set
Set flags.
set SET
SET Means the sender sent its own Verification Tag (that receiver should check).
shutdown-complete
examined
Examined flags.
examined EXAMINED
EXAMINED Means the sender sent its own Verification Tag (that receiver should check).
set
Set flags.
set SET
SET Means the sender sent its own Verification Tag (that receiver should check).
inbound-interface
Name of an interface via which a packet was received. Only for input, forward and prerouting.
not
not
<string> (mandatory)
<string>
outbound-interface
Name of an interface via which a packet is going to be sent. Only for forward, output and postrouting.
not
not
<string> (mandatory)
<string>
action
STANDARD
Standard action.
STANDARD
chain
chain <string>
connmark
Sets the mark value associated with a connection. The mark is 32 bits wide.
connmark \
set-xmark <0x0-0xffffffff> mask <0x0-0xffffffff> \
save-mark nfmask <0x0-0xffffffff> ctmask <0x0-0xffffffff> \
restore-mark nfmask <0x0-0xffffffff> ctmask <0x0-0xffffffff>
set-xmark
Zero out the bits given by mask and XOR value into the ctmark.
<0x0-0xffffffff> (mandatory)
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
save-mark
Copy the packet mark (nfmark) to the connection mark (ctmark) using the given masks. The new value is determined
as follows: ctmark = (ctmark & ~ctmask) ^ (nfmark & nfmask) i.e. ctmask defines what bits to clear and nfmask
what bits of the nfmark to XOR into the ctmark. ctmask and nfmask default to 0xFFFFFFFF.
nfmask
nfmask <0x0-0xffffffff>
ctmask
ctmask <0x0-0xffffffff>
restore-mark
Copy the connection mark (ctmark) to the packet mark (nfmark) using the given masks. The new ctmark value is
determined as follows: nfmark = (nfmark & ~nfmask) ^ (ctmark & ctmask) i.e. nfmask defines what bits to clear
and ctmask what bits of the ctmark to XOR into the packet mark. ctmask and nfmask default to 0xFFFFFFFF.
restore-mark is only valid in the mangle table.
nfmask
nfmask <0x0-0xffffffff>
ctmask
ctmask <0x0-0xffffffff>
log
level
Level of logging.
level LEVEL
prefix
prefix <string>
additional-infos
additional-infos ADDITIONAL-INFOS
mark
<0x0-0xffffffff> (mandatory)
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
tcpmss
Alters the MSS value of TCP SYN packets, to control the maximum size for that connection.
set-mss
set-mss <uint32>
clamp-mss-to-pmtu
clamp-mss-to-pmtu
Packets.
vrouter> show state vrf <vrf> firewall ipv6 mangle forward rule <uint64> counters␣
˓→packets
Bytes.
vrouter> show state vrf <vrf> firewall ipv6 mangle forward rule <uint64> counters bytes
output
policy
Default value
accept
Packets.
vrouter> show state vrf <vrf> firewall ipv6 mangle output packets
Bytes.
vrouter> show state vrf <vrf> firewall ipv6 mangle output bytes
rule
description
description <string>
protocol
not
not
VALUE (mandatory)
VALUE
VALUE Description
values
tcp TCP protocol.
udp UDP protocol.
sctp SCTP protocol.
ipv6-icmp ICMPv6 protocol.
esp IPsec ESP protocol.
ah IPsec AH protocol.
gre GRE protocol.
l2tp L2TP protocol.
ipip IP-in-IP protocol.
vrrp VRRP protocol.
all All protocols.
<uint16> Protocol. The list can be obtained from the ‘show filter protocols’ command or the show-filter-
protocols rpc.
<string> Protocol. The list can be obtained from the ‘show filter protocols’ command or the show-filter-
protocols rpc.
destination
destination \
address [not] VALUE \
port [not] VALUE \
port-range [not] VALUE \
group [not] <string>
address
not
not
VALUE (mandatory)
VALUE
VALUEDescription
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<X:X::X:X>
An IPv6 address.
<X:X::X:X/M>
An IPv6 prefix: address and CIDR mask.
port
not
not
VALUE (mandatory)
VALUE
VALUE A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
not
not
VALUE (mandatory)
VALUE
group
not
Not match-set.
not
<string> (mandatory)
<string>
source
source \
address [not] VALUE \
port [not] VALUE \
port-range [not] VALUE \
group [not] <string>
address
not
not
VALUE (mandatory)
VALUE
VALUEDescription
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<X:X::X:X>
An IPv6 address.
<X:X::X:X/M>
An IPv6 prefix: address and CIDR mask.
port
not
not
VALUE (mandatory)
VALUE
VALUE A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
not
not
VALUE (mandatory)
VALUE
group
not
Not match-set.
not
<string> (mandatory)
<string>
icmpv6-type
not
not
VALUE (mandatory)
VALUE
tcp-flags
not
not
set
Set flags.
set SET
examined
Examined flags.
examined EXAMINED
conntrack
conntrack \
status [not] VALUE \
state [not] VALUE
status
not
not
VALUE
VALUE
state
not
not
VALUE
VALUE
connmark
not
not
<0x0-0xffffffff> (mandatory)
The mark value. Packets in connections are matched against this value.
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
limit
Matches packets at a limited rate. If not set, the rate value is 3/hour and the burst value is 5.
burst
Maximum initial number of packets to match. This number gets recharged by one every time the rate is not reached,
up to this number.
burst <uint32>
rate
<uint32> (mandatory)
The rate.
<uint32>
UNIT
UNIT
dscp
not
not
VALUE (mandatory)
VALUE
tos
not
not
<0x0-0xff> (mandatory)
The tos value. Packets in connections are matched against this value.
<0x0-0xff>
mask
mask <0x0-0xff>
mark
not
not
<0x0-0xffffffff> (mandatory)
The mark value. Packets in connections are matched against this value.
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
sctp-chunk-types
not
not
SCOPE (mandatory)
SCOPE
init
INIT chunk.
init
init-ack
init-ack
sack
SACK chunk.
sack
heartbeat
HEARTBEAT chunk.
heartbeat
heartbeat-ack
heartbeat-ack
shutdown
SHUTDOWN chunk.
shutdown
shutdown-ack
shutdown-ack
error
ERROR chunk.
error
cookie-echo
cookie-echo
cookie-ack
cookie-ack
ecn-ecne
ecn-ecne
ecn-cwr
ecn-cwr
asconf
ASCONF chunk.
asconf
asconf-ack
asconf-ack
forward-tsn
forward-tsn
data
DATA chunk.
examined
Examined flags.
examined EXAMINED
EXAMINED Description
values
I SACK chunk should be sent back without delay.
U Indicates this data is an unordered chunk and the stream sequence number is invalid. If an un-
ordered chunk is fragmented then each fragment has this flag set.
B Marks the beginning fragment. An unfragmented chunk has this flag set.
E Marks the end fragment. An unfragmented chunk has this flag set.
set
Set flags.
set SET
SET Description
values
I SACK chunk should be sent back without delay.
U Indicates this data is an unordered chunk and the stream sequence number is invalid. If an unordered
chunk is fragmented then each fragment has this flag set.
B Marks the beginning fragment. An unfragmented chunk has this flag set.
E Marks the end fragment. An unfragmented chunk has this flag set.
abort
ABORT chunk.
examined
Examined flags.
examined EXAMINED
EXAMINED Means the sender sent its own Verification Tag (that receiver should check).
set
Set flags.
set SET
SET Means the sender sent its own Verification Tag (that receiver should check).
shutdown-complete
examined
Examined flags.
examined EXAMINED
EXAMINED Means the sender sent its own Verification Tag (that receiver should check).
set
Set flags.
set SET
SET Means the sender sent its own Verification Tag (that receiver should check).
outbound-interface
Name of an interface via which a packet is going to be sent. Only for forward, output and postrouting.
not
not
<string> (mandatory)
<string>
action
STANDARD
Standard action.
STANDARD
chain
chain <string>
dscp
Alters the value of the DSCP bits within the tos header of the IPv4 packet.
dscp DSCP
connmark
Sets the mark value associated with a connection. The mark is 32 bits wide.
connmark \
set-xmark <0x0-0xffffffff> mask <0x0-0xffffffff> \
save-mark nfmask <0x0-0xffffffff> ctmask <0x0-0xffffffff> \
restore-mark nfmask <0x0-0xffffffff> ctmask <0x0-0xffffffff>
set-xmark
Zero out the bits given by mask and XOR value into the ctmark.
<0x0-0xffffffff> (mandatory)
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
save-mark
Copy the packet mark (nfmark) to the connection mark (ctmark) using the given masks. The new value is determined
as follows: ctmark = (ctmark & ~ctmask) ^ (nfmark & nfmask) i.e. ctmask defines what bits to clear and nfmask
what bits of the nfmark to XOR into the ctmark. ctmask and nfmask default to 0xFFFFFFFF.
nfmask
nfmask <0x0-0xffffffff>
ctmask
ctmask <0x0-0xffffffff>
restore-mark
Copy the connection mark (ctmark) to the packet mark (nfmark) using the given masks. The new ctmark value is
determined as follows: nfmark = (nfmark & ~nfmask) ^ (ctmark & ctmask) i.e. nfmask defines what bits to clear
and ctmask what bits of the ctmark to XOR into the packet mark. ctmask and nfmask default to 0xFFFFFFFF.
restore-mark is only valid in the mangle table.
nfmask
nfmask <0x0-0xffffffff>
ctmask
ctmask <0x0-0xffffffff>
log
level
Level of logging.
level LEVEL
prefix
prefix <string>
additional-infos
additional-infos ADDITIONAL-INFOS
mark
<0x0-0xffffffff> (mandatory)
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
tcpmss
Alters the MSS value of TCP SYN packets, to control the maximum size for that connection.
set-mss
set-mss <uint32>
clamp-mss-to-pmtu
clamp-mss-to-pmtu
tos
<0x0-0xff> (mandatory)
<0x0-0xff>
mask
mask <0x0-0xff>
Packets.
vrouter> show state vrf <vrf> firewall ipv6 mangle output rule <uint64> counters␣
˓→packets
Bytes.
vrouter> show state vrf <vrf> firewall ipv6 mangle output rule <uint64> counters bytes
postrouting
policy
Default value
accept
Packets.
vrouter> show state vrf <vrf> firewall ipv6 mangle postrouting packets
Bytes.
vrouter> show state vrf <vrf> firewall ipv6 mangle postrouting bytes
rule
description
description <string>
protocol
not
not
VALUE (mandatory)
VALUE
VALUE Description
values
tcp TCP protocol.
udp UDP protocol.
sctp SCTP protocol.
ipv6-icmp ICMPv6 protocol.
esp IPsec ESP protocol.
ah IPsec AH protocol.
gre GRE protocol.
l2tp L2TP protocol.
ipip IP-in-IP protocol.
vrrp VRRP protocol.
all All protocols.
<uint16> Protocol. The list can be obtained from the ‘show filter protocols’ command or the show-filter-
protocols rpc.
<string> Protocol. The list can be obtained from the ‘show filter protocols’ command or the show-filter-
protocols rpc.
destination
destination \
address [not] VALUE \
port [not] VALUE \
port-range [not] VALUE \
group [not] <string>
address
not
not
VALUE (mandatory)
VALUE
VALUEDescription
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<X:X::X:X>
An IPv6 address.
<X:X::X:X/M>
An IPv6 prefix: address and CIDR mask.
port
not
not
VALUE (mandatory)
VALUE
VALUE A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
not
not
VALUE (mandatory)
VALUE
group
not
Not match-set.
not
<string> (mandatory)
<string>
source
source \
address [not] VALUE \
port [not] VALUE \
port-range [not] VALUE \
group [not] <string>
address
not
not
VALUE (mandatory)
VALUE
VALUEDescription
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<X:X::X:X>
An IPv6 address.
<X:X::X:X/M>
An IPv6 prefix: address and CIDR mask.
port
not
not
VALUE (mandatory)
VALUE
VALUE A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
not
not
VALUE (mandatory)
VALUE
group
not
Not match-set.
not
<string> (mandatory)
<string>
icmpv6-type
not
not
VALUE (mandatory)
VALUE
tcp-flags
not
not
set
Set flags.
set SET
examined
Examined flags.
examined EXAMINED
conntrack
conntrack \
status [not] VALUE \
state [not] VALUE
status
not
not
VALUE
VALUE
state
not
not
VALUE
VALUE
connmark
not
not
<0x0-0xffffffff> (mandatory)
The mark value. Packets in connections are matched against this value.
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
limit
Matches packets at a limited rate. If not set, the rate value is 3/hour and the burst value is 5.
burst
Maximum initial number of packets to match. This number gets recharged by one every time the rate is not reached,
up to this number.
burst <uint32>
rate
<uint32> (mandatory)
The rate.
<uint32>
UNIT
UNIT
dscp
not
not
VALUE (mandatory)
VALUE
tos
not
not
<0x0-0xff> (mandatory)
The tos value. Packets in connections are matched against this value.
<0x0-0xff>
mask
mask <0x0-0xff>
mark
not
not
<0x0-0xffffffff> (mandatory)
The mark value. Packets in connections are matched against this value.
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
sctp-chunk-types
not
not
SCOPE (mandatory)
SCOPE
init
INIT chunk.
init
init-ack
init-ack
sack
SACK chunk.
sack
heartbeat
HEARTBEAT chunk.
heartbeat
heartbeat-ack
heartbeat-ack
shutdown
SHUTDOWN chunk.
shutdown
shutdown-ack
shutdown-ack
error
ERROR chunk.
error
cookie-echo
cookie-echo
cookie-ack
cookie-ack
ecn-ecne
ecn-ecne
ecn-cwr
ecn-cwr
asconf
ASCONF chunk.
asconf
asconf-ack
asconf-ack
forward-tsn
forward-tsn
data
DATA chunk.
examined
Examined flags.
examined EXAMINED
EXAMINED Description
values
I SACK chunk should be sent back without delay.
U Indicates this data is an unordered chunk and the stream sequence number is invalid. If an un-
ordered chunk is fragmented then each fragment has this flag set.
B Marks the beginning fragment. An unfragmented chunk has this flag set.
E Marks the end fragment. An unfragmented chunk has this flag set.
set
Set flags.
set SET
SET Description
values
I SACK chunk should be sent back without delay.
U Indicates this data is an unordered chunk and the stream sequence number is invalid. If an unordered
chunk is fragmented then each fragment has this flag set.
B Marks the beginning fragment. An unfragmented chunk has this flag set.
E Marks the end fragment. An unfragmented chunk has this flag set.
abort
ABORT chunk.
examined
Examined flags.
examined EXAMINED
EXAMINED Means the sender sent its own Verification Tag (that receiver should check).
set
Set flags.
set SET
SET Means the sender sent its own Verification Tag (that receiver should check).
shutdown-complete
examined
Examined flags.
examined EXAMINED
EXAMINED Means the sender sent its own Verification Tag (that receiver should check).
set
Set flags.
set SET
SET Means the sender sent its own Verification Tag (that receiver should check).
outbound-interface
Name of an interface via which a packet is going to be sent. Only for forward, output and postrouting.
not
not
<string> (mandatory)
<string>
action
STANDARD
Standard action.
STANDARD
chain
chain <string>
connmark
Sets the mark value associated with a connection. The mark is 32 bits wide.
connmark \
set-xmark <0x0-0xffffffff> mask <0x0-0xffffffff> \
save-mark nfmask <0x0-0xffffffff> ctmask <0x0-0xffffffff> \
restore-mark nfmask <0x0-0xffffffff> ctmask <0x0-0xffffffff>
set-xmark
Zero out the bits given by mask and XOR value into the ctmark.
<0x0-0xffffffff> (mandatory)
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
save-mark
Copy the packet mark (nfmark) to the connection mark (ctmark) using the given masks. The new value is determined
as follows: ctmark = (ctmark & ~ctmask) ^ (nfmark & nfmask) i.e. ctmask defines what bits to clear and nfmask
what bits of the nfmark to XOR into the ctmark. ctmask and nfmask default to 0xFFFFFFFF.
nfmask
nfmask <0x0-0xffffffff>
ctmask
ctmask <0x0-0xffffffff>
restore-mark
Copy the connection mark (ctmark) to the packet mark (nfmark) using the given masks. The new ctmark value is
determined as follows: nfmark = (nfmark & ~nfmask) ^ (ctmark & ctmask) i.e. nfmask defines what bits to clear
and ctmask what bits of the ctmark to XOR into the packet mark. ctmask and nfmask default to 0xFFFFFFFF.
restore-mark is only valid in the mangle table.
nfmask
nfmask <0x0-0xffffffff>
ctmask
ctmask <0x0-0xffffffff>
log
level
Level of logging.
level LEVEL
prefix
prefix <string>
additional-infos
additional-infos ADDITIONAL-INFOS
mark
<0x0-0xffffffff> (mandatory)
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
tcpmss
Alters the MSS value of TCP SYN packets, to control the maximum size for that connection.
set-mss
set-mss <uint32>
clamp-mss-to-pmtu
clamp-mss-to-pmtu
Packets.
vrouter> show state vrf <vrf> firewall ipv6 mangle postrouting rule <uint64> counters␣
˓→packets
Bytes.
vrouter> show state vrf <vrf> firewall ipv6 mangle postrouting rule <uint64> counters␣
˓→bytes
chain
User chain.
vrouter running config# vrf <vrf> firewall ipv6 mangle chain <string>
policy
vrouter running config# vrf <vrf> firewall ipv6 mangle chain <string>
vrouter running chain <string># policy POLICY
Default value
accept
Packets.
vrouter> show state vrf <vrf> firewall ipv6 mangle chain <string> packets
Bytes.
vrouter> show state vrf <vrf> firewall ipv6 mangle chain <string> bytes
rule
vrouter running config# vrf <vrf> firewall ipv6 mangle chain <string>
vrouter running chain <string># rule <uint64> description <string> \
... protocol [not] VALUE \
... destination \
... address [not] VALUE \
... port [not] VALUE \
... port-range [not] VALUE \
... group [not] <string> \
... source \
... address [not] VALUE \
... port [not] VALUE \
... port-range [not] VALUE \
... group [not] <string> \
... icmpv6-type [not] VALUE \
... tcp-flags [not] set SET examined EXAMINED \
... conntrack \
... status [not] VALUE \
... state [not] VALUE \
... connmark [not] <0x0-0xffffffff> mask <0x0-0xffffffff> \
... limit burst <uint32> \
... rate <uint32> UNIT \
... dscp [not] VALUE \
... tos [not] <0x0-0xff> mask <0x0-0xff> \
... mark [not] <0x0-0xffffffff> mask <0x0-0xffffffff> \
... sctp-chunk-types [not] SCOPE init init-ack sack heartbeat heartbeat-ack \
... shutdown shutdown-ack error cookie-echo cookie-ack ecn-ecne ecn-cwr asconf \
(continues on next page)
description
description <string>
protocol
not
not
VALUE (mandatory)
VALUE
VALUE Description
values
tcp TCP protocol.
udp UDP protocol.
sctp SCTP protocol.
ipv6-icmp ICMPv6 protocol.
esp IPsec ESP protocol.
ah IPsec AH protocol.
gre GRE protocol.
l2tp L2TP protocol.
ipip IP-in-IP protocol.
vrrp VRRP protocol.
all All protocols.
<uint16> Protocol. The list can be obtained from the ‘show filter protocols’ command or the show-filter-
protocols rpc.
<string> Protocol. The list can be obtained from the ‘show filter protocols’ command or the show-filter-
protocols rpc.
destination
destination \
address [not] VALUE \
port [not] VALUE \
port-range [not] VALUE \
group [not] <string>
address
not
not
VALUE (mandatory)
VALUE
VALUEDescription
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<X:X::X:X>
An IPv6 address.
<X:X::X:X/M>
An IPv6 prefix: address and CIDR mask.
port
not
not
VALUE (mandatory)
VALUE
VALUE A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
not
not
VALUE (mandatory)
VALUE
group
not
Not match-set.
not
<string> (mandatory)
<string>
source
source \
address [not] VALUE \
port [not] VALUE \
port-range [not] VALUE \
group [not] <string>
address
not
not
VALUE (mandatory)
VALUE
VALUEDescription
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<X:X::X:X>
An IPv6 address.
<X:X::X:X/M>
An IPv6 prefix: address and CIDR mask.
port
not
not
VALUE (mandatory)
VALUE
VALUE A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
not
not
VALUE (mandatory)
VALUE
group
not
Not match-set.
not
<string> (mandatory)
<string>
icmpv6-type
not
not
VALUE (mandatory)
VALUE
tcp-flags
not
not
set
Set flags.
set SET
examined
Examined flags.
examined EXAMINED
conntrack
conntrack \
status [not] VALUE \
state [not] VALUE
status
not
not
VALUE
VALUE
state
not
not
VALUE
VALUE
connmark
not
not
<0x0-0xffffffff> (mandatory)
The mark value. Packets in connections are matched against this value.
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
limit
Matches packets at a limited rate. If not set, the rate value is 3/hour and the burst value is 5.
burst
Maximum initial number of packets to match. This number gets recharged by one every time the rate is not reached,
up to this number.
burst <uint32>
rate
<uint32> (mandatory)
The rate.
<uint32>
UNIT
UNIT
dscp
not
not
VALUE (mandatory)
VALUE
tos
not
not
<0x0-0xff> (mandatory)
The tos value. Packets in connections are matched against this value.
<0x0-0xff>
mask
mask <0x0-0xff>
mark
not
not
<0x0-0xffffffff> (mandatory)
The mark value. Packets in connections are matched against this value.
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
sctp-chunk-types
not
not
SCOPE (mandatory)
SCOPE
init
INIT chunk.
init
init-ack
init-ack
sack
SACK chunk.
sack
heartbeat
HEARTBEAT chunk.
heartbeat
heartbeat-ack
heartbeat-ack
shutdown
SHUTDOWN chunk.
shutdown
shutdown-ack
shutdown-ack
error
ERROR chunk.
error
cookie-echo
cookie-echo
cookie-ack
cookie-ack
ecn-ecne
ecn-ecne
ecn-cwr
ecn-cwr
asconf
ASCONF chunk.
asconf
asconf-ack
asconf-ack
forward-tsn
forward-tsn
data
DATA chunk.
examined
Examined flags.
examined EXAMINED
EXAMINED Description
values
I SACK chunk should be sent back without delay.
U Indicates this data is an unordered chunk and the stream sequence number is invalid. If an un-
ordered chunk is fragmented then each fragment has this flag set.
B Marks the beginning fragment. An unfragmented chunk has this flag set.
E Marks the end fragment. An unfragmented chunk has this flag set.
set
Set flags.
set SET
SET Description
values
I SACK chunk should be sent back without delay.
U Indicates this data is an unordered chunk and the stream sequence number is invalid. If an unordered
chunk is fragmented then each fragment has this flag set.
B Marks the beginning fragment. An unfragmented chunk has this flag set.
E Marks the end fragment. An unfragmented chunk has this flag set.
abort
ABORT chunk.
examined
Examined flags.
examined EXAMINED
EXAMINED Means the sender sent its own Verification Tag (that receiver should check).
set
Set flags.
set SET
SET Means the sender sent its own Verification Tag (that receiver should check).
shutdown-complete
examined
Examined flags.
examined EXAMINED
EXAMINED Means the sender sent its own Verification Tag (that receiver should check).
set
Set flags.
set SET
SET Means the sender sent its own Verification Tag (that receiver should check).
inbound-interface
Name of an interface via which a packet was received. Only for input, forward and prerouting.
not
not
<string> (mandatory)
<string>
outbound-interface
Name of an interface via which a packet is going to be sent. Only for forward, output and postrouting.
not
not
<string> (mandatory)
<string>
rpfilter
Performs a reverse path filter test on a packet. If a reply to the packet would be sent via the same interface that the
packet arrived on, the packet will match.
invert
This will invert the sense of the match. Instead of matching packets that passed the reverse path filter test, match
those that have failed it.
invert true|false
Default value
false
action
STANDARD
Standard action.
STANDARD
chain
chain <string>
reject
reject REJECT
connmark
Sets the mark value associated with a connection. The mark is 32 bits wide.
connmark \
set-xmark <0x0-0xffffffff> mask <0x0-0xffffffff> \
save-mark nfmask <0x0-0xffffffff> ctmask <0x0-0xffffffff> \
restore-mark nfmask <0x0-0xffffffff> ctmask <0x0-0xffffffff>
set-xmark
Zero out the bits given by mask and XOR value into the ctmark.
<0x0-0xffffffff> (mandatory)
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
save-mark
Copy the packet mark (nfmark) to the connection mark (ctmark) using the given masks. The new value is determined
as follows: ctmark = (ctmark & ~ctmask) ^ (nfmark & nfmask) i.e. ctmask defines what bits to clear and nfmask
what bits of the nfmark to XOR into the ctmark. ctmask and nfmask default to 0xFFFFFFFF.
nfmask
nfmask <0x0-0xffffffff>
ctmask
ctmask <0x0-0xffffffff>
restore-mark
Copy the connection mark (ctmark) to the packet mark (nfmark) using the given masks. The new ctmark value is
determined as follows: nfmark = (nfmark & ~nfmask) ^ (ctmark & ctmask) i.e. nfmask defines what bits to clear
and ctmask what bits of the ctmark to XOR into the packet mark. ctmask and nfmask default to 0xFFFFFFFF.
restore-mark is only valid in the mangle table.
nfmask
nfmask <0x0-0xffffffff>
ctmask
ctmask <0x0-0xffffffff>
log
level
Level of logging.
level LEVEL
prefix
prefix <string>
additional-infos
additional-infos ADDITIONAL-INFOS
mark
<0x0-0xffffffff> (mandatory)
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
tcpmss
Alters the MSS value of TCP SYN packets, to control the maximum size for that connection.
set-mss
set-mss <uint32>
clamp-mss-to-pmtu
clamp-mss-to-pmtu
Packets.
vrouter> show state vrf <vrf> firewall ipv6 mangle chain <string> rule <uint64>␣
˓→counters packets
Bytes.
vrouter> show state vrf <vrf> firewall ipv6 mangle chain <string> rule <uint64>␣
˓→counters bytes
ipv6 raw
prerouting
policy
Default value
accept
Packets.
vrouter> show state vrf <vrf> firewall ipv6 raw prerouting packets
Bytes.
vrouter> show state vrf <vrf> firewall ipv6 raw prerouting bytes
rule
description
description <string>
protocol
not
not
VALUE (mandatory)
VALUE
VALUE Description
values
tcp TCP protocol.
udp UDP protocol.
sctp SCTP protocol.
ipv6-icmp ICMPv6 protocol.
esp IPsec ESP protocol.
ah IPsec AH protocol.
gre GRE protocol.
l2tp L2TP protocol.
ipip IP-in-IP protocol.
vrrp VRRP protocol.
all All protocols.
<uint16> Protocol. The list can be obtained from the ‘show filter protocols’ command or the show-filter-
protocols rpc.
<string> Protocol. The list can be obtained from the ‘show filter protocols’ command or the show-filter-
protocols rpc.
destination
destination \
address [not] VALUE \
port [not] VALUE \
port-range [not] VALUE \
group [not] <string>
address
not
not
VALUE (mandatory)
VALUE
VALUEDescription
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<X:X::X:X>
An IPv6 address.
<X:X::X:X/M>
An IPv6 prefix: address and CIDR mask.
port
not
not
VALUE (mandatory)
VALUE
VALUE A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
not
not
VALUE (mandatory)
VALUE
group
not
Not match-set.
not
<string> (mandatory)
<string>
source
source \
address [not] VALUE \
port [not] VALUE \
port-range [not] VALUE \
group [not] <string>
address
not
not
VALUE (mandatory)
VALUE
VALUEDescription
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<X:X::X:X>
An IPv6 address.
<X:X::X:X/M>
An IPv6 prefix: address and CIDR mask.
port
not
not
VALUE (mandatory)
VALUE
VALUE A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
not
not
VALUE (mandatory)
VALUE
group
not
Not match-set.
not
<string> (mandatory)
<string>
icmpv6-type
not
not
VALUE (mandatory)
VALUE
tcp-flags
not
not
set
Set flags.
set SET
examined
Examined flags.
examined EXAMINED
conntrack
conntrack \
status [not] VALUE \
state [not] VALUE
status
not
not
VALUE
VALUE
state
not
not
VALUE
VALUE
connmark
not
not
<0x0-0xffffffff> (mandatory)
The mark value. Packets in connections are matched against this value.
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
limit
Matches packets at a limited rate. If not set, the rate value is 3/hour and the burst value is 5.
burst
Maximum initial number of packets to match. This number gets recharged by one every time the rate is not reached,
up to this number.
burst <uint32>
rate
<uint32> (mandatory)
The rate.
<uint32>
UNIT
UNIT
dscp
not
not
VALUE (mandatory)
VALUE
tos
not
not
<0x0-0xff> (mandatory)
The tos value. Packets in connections are matched against this value.
<0x0-0xff>
mask
mask <0x0-0xff>
mark
not
not
<0x0-0xffffffff> (mandatory)
The mark value. Packets in connections are matched against this value.
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
sctp-chunk-types
not
not
SCOPE (mandatory)
SCOPE
init
INIT chunk.
init
init-ack
init-ack
sack
SACK chunk.
sack
heartbeat
HEARTBEAT chunk.
heartbeat
heartbeat-ack
heartbeat-ack
shutdown
SHUTDOWN chunk.
shutdown
shutdown-ack
shutdown-ack
error
ERROR chunk.
error
cookie-echo
cookie-echo
cookie-ack
cookie-ack
ecn-ecne
ecn-ecne
ecn-cwr
ecn-cwr
asconf
ASCONF chunk.
asconf
asconf-ack
asconf-ack
forward-tsn
forward-tsn
data
DATA chunk.
examined
Examined flags.
examined EXAMINED
EXAMINED Description
values
I SACK chunk should be sent back without delay.
U Indicates this data is an unordered chunk and the stream sequence number is invalid. If an un-
ordered chunk is fragmented then each fragment has this flag set.
B Marks the beginning fragment. An unfragmented chunk has this flag set.
E Marks the end fragment. An unfragmented chunk has this flag set.
set
Set flags.
set SET
SET Description
values
I SACK chunk should be sent back without delay.
U Indicates this data is an unordered chunk and the stream sequence number is invalid. If an unordered
chunk is fragmented then each fragment has this flag set.
B Marks the beginning fragment. An unfragmented chunk has this flag set.
E Marks the end fragment. An unfragmented chunk has this flag set.
abort
ABORT chunk.
examined
Examined flags.
examined EXAMINED
EXAMINED Means the sender sent its own Verification Tag (that receiver should check).
set
Set flags.
set SET
SET Means the sender sent its own Verification Tag (that receiver should check).
shutdown-complete
examined
Examined flags.
examined EXAMINED
EXAMINED Means the sender sent its own Verification Tag (that receiver should check).
set
Set flags.
set SET
SET Means the sender sent its own Verification Tag (that receiver should check).
inbound-interface
Name of an interface via which a packet was received. Only for input, forward and prerouting.
not
not
<string> (mandatory)
<string>
rpfilter
Performs a reverse path filter test on a packet. If a reply to the packet would be sent via the same interface that the
packet arrived on, the packet will match.
invert
This will invert the sense of the match. Instead of matching packets that passed the reverse path filter test, match
those that have failed it.
invert true|false
Default value
false
action
STANDARD
Standard action.
STANDARD
chain
chain <string>
notrack (deprecated)
Attention:
Deprecated since: 2021-09-07
Obsolete in release: 22q1
Description: notrack action is no longer supported.
Replacement: none
notrack
connmark
Sets the mark value associated with a connection. The mark is 32 bits wide.
connmark \
set-xmark <0x0-0xffffffff> mask <0x0-0xffffffff> \
save-mark nfmask <0x0-0xffffffff> ctmask <0x0-0xffffffff> \
restore-mark nfmask <0x0-0xffffffff> ctmask <0x0-0xffffffff>
set-xmark
Zero out the bits given by mask and XOR value into the ctmark.
<0x0-0xffffffff> (mandatory)
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
save-mark
Copy the packet mark (nfmark) to the connection mark (ctmark) using the given masks. The new value is determined
as follows: ctmark = (ctmark & ~ctmask) ^ (nfmark & nfmask) i.e. ctmask defines what bits to clear and nfmask
what bits of the nfmark to XOR into the ctmark. ctmask and nfmask default to 0xFFFFFFFF.
nfmask
nfmask <0x0-0xffffffff>
ctmask
ctmask <0x0-0xffffffff>
restore-mark
Copy the connection mark (ctmark) to the packet mark (nfmark) using the given masks. The new ctmark value is
determined as follows: nfmark = (nfmark & ~nfmask) ^ (ctmark & ctmask) i.e. nfmask defines what bits to clear
and ctmask what bits of the ctmark to XOR into the packet mark. ctmask and nfmask default to 0xFFFFFFFF.
restore-mark is only valid in the mangle table.
nfmask
nfmask <0x0-0xffffffff>
ctmask
ctmask <0x0-0xffffffff>
log
level
Level of logging.
level LEVEL
prefix
prefix <string>
additional-infos
additional-infos ADDITIONAL-INFOS
mark
<0x0-0xffffffff> (mandatory)
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
tcpmss
Alters the MSS value of TCP SYN packets, to control the maximum size for that connection.
set-mss
set-mss <uint32>
clamp-mss-to-pmtu
clamp-mss-to-pmtu
Packets.
vrouter> show state vrf <vrf> firewall ipv6 raw prerouting rule <uint64> counters␣
˓→packets
Bytes.
vrouter> show state vrf <vrf> firewall ipv6 raw prerouting rule <uint64> counters bytes
output
policy
Default value
accept
Packets.
vrouter> show state vrf <vrf> firewall ipv6 raw output packets
Bytes.
vrouter> show state vrf <vrf> firewall ipv6 raw output bytes
rule
description
description <string>
protocol
not
not
VALUE (mandatory)
VALUE
VALUE Description
values
tcp TCP protocol.
udp UDP protocol.
sctp SCTP protocol.
ipv6-icmp ICMPv6 protocol.
esp IPsec ESP protocol.
ah IPsec AH protocol.
gre GRE protocol.
l2tp L2TP protocol.
ipip IP-in-IP protocol.
vrrp VRRP protocol.
all All protocols.
<uint16> Protocol. The list can be obtained from the ‘show filter protocols’ command or the show-filter-
protocols rpc.
<string> Protocol. The list can be obtained from the ‘show filter protocols’ command or the show-filter-
protocols rpc.
destination
destination \
address [not] VALUE \
port [not] VALUE \
port-range [not] VALUE \
group [not] <string>
address
not
not
VALUE (mandatory)
VALUE
VALUEDescription
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<X:X::X:X>
An IPv6 address.
<X:X::X:X/M>
An IPv6 prefix: address and CIDR mask.
port
not
not
VALUE (mandatory)
VALUE
VALUE A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
not
not
VALUE (mandatory)
VALUE
group
not
Not match-set.
not
<string> (mandatory)
<string>
source
source \
address [not] VALUE \
port [not] VALUE \
port-range [not] VALUE \
group [not] <string>
address
not
not
VALUE (mandatory)
VALUE
VALUEDescription
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<X:X::X:X>
An IPv6 address.
<X:X::X:X/M>
An IPv6 prefix: address and CIDR mask.
port
not
not
VALUE (mandatory)
VALUE
VALUE A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
not
not
VALUE (mandatory)
VALUE
group
not
Not match-set.
not
<string> (mandatory)
<string>
icmpv6-type
not
not
VALUE (mandatory)
VALUE
tcp-flags
not
not
set
Set flags.
set SET
examined
Examined flags.
examined EXAMINED
conntrack
conntrack \
status [not] VALUE \
state [not] VALUE
status
not
not
VALUE
VALUE
state
not
not
VALUE
VALUE
connmark
not
not
<0x0-0xffffffff> (mandatory)
The mark value. Packets in connections are matched against this value.
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
limit
Matches packets at a limited rate. If not set, the rate value is 3/hour and the burst value is 5.
burst
Maximum initial number of packets to match. This number gets recharged by one every time the rate is not reached,
up to this number.
burst <uint32>
rate
<uint32> (mandatory)
The rate.
<uint32>
UNIT
UNIT
dscp
not
not
VALUE (mandatory)
VALUE
tos
not
not
<0x0-0xff> (mandatory)
The tos value. Packets in connections are matched against this value.
<0x0-0xff>
mask
mask <0x0-0xff>
mark
not
not
<0x0-0xffffffff> (mandatory)
The mark value. Packets in connections are matched against this value.
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
sctp-chunk-types
not
not
SCOPE (mandatory)
SCOPE
init
INIT chunk.
init
init-ack
init-ack
sack
SACK chunk.
sack
heartbeat
HEARTBEAT chunk.
heartbeat
heartbeat-ack
heartbeat-ack
shutdown
SHUTDOWN chunk.
shutdown
shutdown-ack
shutdown-ack
error
ERROR chunk.
error
cookie-echo
cookie-echo
cookie-ack
cookie-ack
ecn-ecne
ecn-ecne
ecn-cwr
ecn-cwr
asconf
ASCONF chunk.
asconf
asconf-ack
asconf-ack
forward-tsn
forward-tsn
data
DATA chunk.
examined
Examined flags.
examined EXAMINED
EXAMINED Description
values
I SACK chunk should be sent back without delay.
U Indicates this data is an unordered chunk and the stream sequence number is invalid. If an un-
ordered chunk is fragmented then each fragment has this flag set.
B Marks the beginning fragment. An unfragmented chunk has this flag set.
E Marks the end fragment. An unfragmented chunk has this flag set.
set
Set flags.
set SET
SET Description
values
I SACK chunk should be sent back without delay.
U Indicates this data is an unordered chunk and the stream sequence number is invalid. If an unordered
chunk is fragmented then each fragment has this flag set.
B Marks the beginning fragment. An unfragmented chunk has this flag set.
E Marks the end fragment. An unfragmented chunk has this flag set.
abort
ABORT chunk.
examined
Examined flags.
examined EXAMINED
EXAMINED Means the sender sent its own Verification Tag (that receiver should check).
set
Set flags.
set SET
SET Means the sender sent its own Verification Tag (that receiver should check).
shutdown-complete
examined
Examined flags.
examined EXAMINED
EXAMINED Means the sender sent its own Verification Tag (that receiver should check).
set
Set flags.
set SET
SET Means the sender sent its own Verification Tag (that receiver should check).
outbound-interface
Name of an interface via which a packet is going to be sent. Only for forward, output and postrouting.
not
not
<string> (mandatory)
<string>
action
STANDARD
Standard action.
STANDARD
chain
chain <string>
notrack (deprecated)
Attention:
Deprecated since: 2021-09-07
Obsolete in release: 22q1
Description: notrack action is no longer supported.
Replacement: none
notrack
connmark
Sets the mark value associated with a connection. The mark is 32 bits wide.
connmark \
set-xmark <0x0-0xffffffff> mask <0x0-0xffffffff> \
save-mark nfmask <0x0-0xffffffff> ctmask <0x0-0xffffffff> \
restore-mark nfmask <0x0-0xffffffff> ctmask <0x0-0xffffffff>
set-xmark
Zero out the bits given by mask and XOR value into the ctmark.
<0x0-0xffffffff> (mandatory)
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
save-mark
Copy the packet mark (nfmark) to the connection mark (ctmark) using the given masks. The new value is determined
as follows: ctmark = (ctmark & ~ctmask) ^ (nfmark & nfmask) i.e. ctmask defines what bits to clear and nfmask
what bits of the nfmark to XOR into the ctmark. ctmask and nfmask default to 0xFFFFFFFF.
nfmask
nfmask <0x0-0xffffffff>
ctmask
ctmask <0x0-0xffffffff>
restore-mark
Copy the connection mark (ctmark) to the packet mark (nfmark) using the given masks. The new ctmark value is
determined as follows: nfmark = (nfmark & ~nfmask) ^ (ctmark & ctmask) i.e. nfmask defines what bits to clear
and ctmask what bits of the ctmark to XOR into the packet mark. ctmask and nfmask default to 0xFFFFFFFF.
restore-mark is only valid in the mangle table.
nfmask
nfmask <0x0-0xffffffff>
ctmask
ctmask <0x0-0xffffffff>
log
level
Level of logging.
level LEVEL
prefix
prefix <string>
additional-infos
additional-infos ADDITIONAL-INFOS
mark
<0x0-0xffffffff> (mandatory)
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
tcpmss
Alters the MSS value of TCP SYN packets, to control the maximum size for that connection.
set-mss
set-mss <uint32>
clamp-mss-to-pmtu
clamp-mss-to-pmtu
Packets.
vrouter> show state vrf <vrf> firewall ipv6 raw output rule <uint64> counters packets
Bytes.
vrouter> show state vrf <vrf> firewall ipv6 raw output rule <uint64> counters bytes
chain
User chain.
vrouter running config# vrf <vrf> firewall ipv6 raw chain <string>
policy
vrouter running config# vrf <vrf> firewall ipv6 raw chain <string>
vrouter running chain <string># policy POLICY
Default value
accept
Packets.
vrouter> show state vrf <vrf> firewall ipv6 raw chain <string> packets
Bytes.
vrouter> show state vrf <vrf> firewall ipv6 raw chain <string> bytes
rule
vrouter running config# vrf <vrf> firewall ipv6 raw chain <string>
vrouter running chain <string># rule <uint64> description <string> \
... protocol [not] VALUE \
... destination \
... address [not] VALUE \
... port [not] VALUE \
... port-range [not] VALUE \
... group [not] <string> \
... source \
... address [not] VALUE \
... port [not] VALUE \
... port-range [not] VALUE \
... group [not] <string> \
... icmpv6-type [not] VALUE \
... tcp-flags [not] set SET examined EXAMINED \
... conntrack \
... status [not] VALUE \
... state [not] VALUE \
... connmark [not] <0x0-0xffffffff> mask <0x0-0xffffffff> \
... limit burst <uint32> \
... rate <uint32> UNIT \
... dscp [not] VALUE \
... tos [not] <0x0-0xff> mask <0x0-0xff> \
... mark [not] <0x0-0xffffffff> mask <0x0-0xffffffff> \
... sctp-chunk-types [not] SCOPE init init-ack sack heartbeat heartbeat-ack \
... shutdown shutdown-ack error cookie-echo cookie-ack ecn-ecne ecn-cwr asconf \
(continues on next page)
description
description <string>
protocol
not
not
VALUE (mandatory)
VALUE
VALUE Description
values
tcp TCP protocol.
udp UDP protocol.
sctp SCTP protocol.
ipv6-icmp ICMPv6 protocol.
esp IPsec ESP protocol.
ah IPsec AH protocol.
gre GRE protocol.
l2tp L2TP protocol.
ipip IP-in-IP protocol.
vrrp VRRP protocol.
all All protocols.
<uint16> Protocol. The list can be obtained from the ‘show filter protocols’ command or the show-filter-
protocols rpc.
<string> Protocol. The list can be obtained from the ‘show filter protocols’ command or the show-filter-
protocols rpc.
destination
destination \
address [not] VALUE \
port [not] VALUE \
port-range [not] VALUE \
group [not] <string>
address
not
not
VALUE (mandatory)
VALUE
VALUEDescription
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<X:X::X:X>
An IPv6 address.
<X:X::X:X/M>
An IPv6 prefix: address and CIDR mask.
port
not
not
VALUE (mandatory)
VALUE
VALUE A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
not
not
VALUE (mandatory)
VALUE
group
not
Not match-set.
not
<string> (mandatory)
<string>
source
source \
address [not] VALUE \
port [not] VALUE \
port-range [not] VALUE \
group [not] <string>
address
not
not
VALUE (mandatory)
VALUE
VALUEDescription
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<X:X::X:X>
An IPv6 address.
<X:X::X:X/M>
An IPv6 prefix: address and CIDR mask.
port
not
not
VALUE (mandatory)
VALUE
VALUE A 16-bit port number used by a transport protocol such as TCP or UDP.
port-range
not
not
VALUE (mandatory)
VALUE
group
not
Not match-set.
not
<string> (mandatory)
<string>
icmpv6-type
not
not
VALUE (mandatory)
VALUE
tcp-flags
not
not
set
Set flags.
set SET
examined
Examined flags.
examined EXAMINED
conntrack
conntrack \
status [not] VALUE \
state [not] VALUE
status
not
not
VALUE
VALUE
state
not
not
VALUE
VALUE
connmark
not
not
<0x0-0xffffffff> (mandatory)
The mark value. Packets in connections are matched against this value.
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
limit
Matches packets at a limited rate. If not set, the rate value is 3/hour and the burst value is 5.
burst
Maximum initial number of packets to match. This number gets recharged by one every time the rate is not reached,
up to this number.
burst <uint32>
rate
<uint32> (mandatory)
The rate.
<uint32>
UNIT
UNIT
dscp
not
not
VALUE (mandatory)
VALUE
tos
not
not
<0x0-0xff> (mandatory)
The tos value. Packets in connections are matched against this value.
<0x0-0xff>
mask
mask <0x0-0xff>
mark
not
not
<0x0-0xffffffff> (mandatory)
The mark value. Packets in connections are matched against this value.
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
sctp-chunk-types
not
not
SCOPE (mandatory)
SCOPE
init
INIT chunk.
init
init-ack
init-ack
sack
SACK chunk.
sack
heartbeat
HEARTBEAT chunk.
heartbeat
heartbeat-ack
heartbeat-ack
shutdown
SHUTDOWN chunk.
shutdown
shutdown-ack
shutdown-ack
error
ERROR chunk.
error
cookie-echo
cookie-echo
cookie-ack
cookie-ack
ecn-ecne
ecn-ecne
ecn-cwr
ecn-cwr
asconf
ASCONF chunk.
asconf
asconf-ack
asconf-ack
forward-tsn
forward-tsn
data
DATA chunk.
examined
Examined flags.
examined EXAMINED
EXAMINED Description
values
I SACK chunk should be sent back without delay.
U Indicates this data is an unordered chunk and the stream sequence number is invalid. If an un-
ordered chunk is fragmented then each fragment has this flag set.
B Marks the beginning fragment. An unfragmented chunk has this flag set.
E Marks the end fragment. An unfragmented chunk has this flag set.
set
Set flags.
set SET
SET Description
values
I SACK chunk should be sent back without delay.
U Indicates this data is an unordered chunk and the stream sequence number is invalid. If an unordered
chunk is fragmented then each fragment has this flag set.
B Marks the beginning fragment. An unfragmented chunk has this flag set.
E Marks the end fragment. An unfragmented chunk has this flag set.
abort
ABORT chunk.
examined
Examined flags.
examined EXAMINED
EXAMINED Means the sender sent its own Verification Tag (that receiver should check).
set
Set flags.
set SET
SET Means the sender sent its own Verification Tag (that receiver should check).
shutdown-complete
examined
Examined flags.
examined EXAMINED
EXAMINED Means the sender sent its own Verification Tag (that receiver should check).
set
Set flags.
set SET
SET Means the sender sent its own Verification Tag (that receiver should check).
inbound-interface
Name of an interface via which a packet was received. Only for input, forward and prerouting.
not
not
<string> (mandatory)
<string>
outbound-interface
Name of an interface via which a packet is going to be sent. Only for forward, output and postrouting.
not
not
<string> (mandatory)
<string>
rpfilter
Performs a reverse path filter test on a packet. If a reply to the packet would be sent via the same interface that the
packet arrived on, the packet will match.
invert
This will invert the sense of the match. Instead of matching packets that passed the reverse path filter test, match
those that have failed it.
invert true|false
Default value
false
action
STANDARD
Standard action.
STANDARD
chain
chain <string>
reject
reject REJECT
connmark
Sets the mark value associated with a connection. The mark is 32 bits wide.
connmark \
set-xmark <0x0-0xffffffff> mask <0x0-0xffffffff> \
save-mark nfmask <0x0-0xffffffff> ctmask <0x0-0xffffffff> \
restore-mark nfmask <0x0-0xffffffff> ctmask <0x0-0xffffffff>
set-xmark
Zero out the bits given by mask and XOR value into the ctmark.
<0x0-0xffffffff> (mandatory)
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
save-mark
Copy the packet mark (nfmark) to the connection mark (ctmark) using the given masks. The new value is determined
as follows: ctmark = (ctmark & ~ctmask) ^ (nfmark & nfmask) i.e. ctmask defines what bits to clear and nfmask
what bits of the nfmark to XOR into the ctmark. ctmask and nfmask default to 0xFFFFFFFF.
nfmask
nfmask <0x0-0xffffffff>
ctmask
ctmask <0x0-0xffffffff>
restore-mark
Copy the connection mark (ctmark) to the packet mark (nfmark) using the given masks. The new ctmark value is
determined as follows: nfmark = (nfmark & ~nfmask) ^ (ctmark & ctmask) i.e. nfmask defines what bits to clear
and ctmask what bits of the ctmark to XOR into the packet mark. ctmask and nfmask default to 0xFFFFFFFF.
restore-mark is only valid in the mangle table.
nfmask
nfmask <0x0-0xffffffff>
ctmask
ctmask <0x0-0xffffffff>
log
level
Level of logging.
level LEVEL
prefix
prefix <string>
additional-infos
additional-infos ADDITIONAL-INFOS
mark
<0x0-0xffffffff> (mandatory)
<0x0-0xffffffff>
mask
mask <0x0-0xffffffff>
tcpmss
Alters the MSS value of TCP SYN packets, to control the maximum size for that connection.
set-mss
set-mss <uint32>
clamp-mss-to-pmtu
clamp-mss-to-pmtu
Packets.
vrouter> show state vrf <vrf> firewall ipv6 raw chain <string> rule <uint64> counters␣
˓→packets
Bytes.
vrouter> show state vrf <vrf> firewall ipv6 raw chain <string> rule <uint64> counters␣
˓→bytes
Address group.
address
AD- An IPv6 address without a zone index. This type, derived from ipv6-address, may be used in situations
DRESS where the zone is known from the context and hence no zone index is needed.
Network group.
network
Attention:
Deprecated since: 2021-04-23
Obsolete in release: 22q3
Description: The leaf has been renamed to bus-addr for clarity.
Replacement: / network-port bus-addr
The port number, in case there are several ports per PCI device.
3.2.23 interface
bridge
mtu
promiscuous
description
enabled
Default value
true
ageing-time
Configure the bridge’s FDB entries ageing time, ie the time a MAC address will be kept in the FDB after a packet
has been received from that address. After this time has passed, entries are cleaned up.
System assigned number for each interface. Corresponds to ifIndex object in SNMP Interface MIB.
The desired state of the interface. In RFC 7223 this leaf has the same read semantics as ifAdminStatus. Here, it
reflects the administrative state as set by enabling or disabling the interface.
The current operational state of the interface. This leaf has the same semantics as ifOperStatus.
This timestamp indicates the time of the last state change of the interface (e.g., up-to-down transition). This corre-
sponds to the ifLastChange object in the standard interface MIB. The value is the timestamp in nanoseconds relative
to the Unix Epoch (Jan 1, 1970 00:00:00 UTC).
ethernet
mac-address
Assigns a MAC address to the Ethernet interface. If not specified, the corresponding operational state leaf is expected
to show the system-assigned MAC address.
MAC- An IEEE 802 unicast MAC address i.e. the second digit is an even number. Moreover the mac
ADDRESS address must not be 00:00:00:00:00:00.
ipv4
enabled
Controls whether IPv4 is enabled or disabled on this interface. When IPv4 is enabled, this interface is connected to
an IPv4 stack, and the interface can send and receive IPv4 packets.
Default value
true
address
peer
The IPv4 address of the remote endpoint for point to point interfaces.
peer PEER
The origin of this address, e.g., statically configured, assigned by DHCP, etc..
vrouter> show state vrf <vrf> interface bridge <bridge> ipv4 address <address> origin
neighbor
A list of mappings from IPv4 addresses to link-layer addresses. Entries in this list are used as static entries in the
ARP Cache.
link-layer-address (mandatory)
link-layer-address LINK-LAYER-ADDRESS
vrouter> show state vrf <vrf> interface bridge <bridge> ipv4 neighbor <neighbor> state
dhcp
vrouter running config# vrf <vrf> interface bridge <bridge> ipv4 dhcp
enabled
vrouter running config# vrf <vrf> interface bridge <bridge> ipv4 dhcp
vrouter running dhcp# enabled true|false
Default value
true
timeout
Time before deciding that it’s not going to be able to contact a server.
vrouter running config# vrf <vrf> interface bridge <bridge> ipv4 dhcp
vrouter running dhcp# timeout <uint32>
Default value
60
retry
vrouter running config# vrf <vrf> interface bridge <bridge> ipv4 dhcp
vrouter running dhcp# retry <uint32>
Default value
300
select-timeout
Time at which the client stops waiting for other offers from servers.
vrouter running config# vrf <vrf> interface bridge <bridge> ipv4 dhcp
vrouter running dhcp# select-timeout <uint32>
Default value
0
reboot
Time after trying to reacquire its old address before trying to discover a new address.
vrouter running config# vrf <vrf> interface bridge <bridge> ipv4 dhcp
vrouter running dhcp# reboot <uint32>
Default value
10
initial-interval
Time between the first attempt to reach a server and the second attempt to reach a server.
vrouter running config# vrf <vrf> interface bridge <bridge> ipv4 dhcp
vrouter running dhcp# initial-interval <uint32>
Default value
10
dhcp-lease-time
vrouter running config# vrf <vrf> interface bridge <bridge> ipv4 dhcp
vrouter running dhcp# dhcp-lease-time <uint32>
Default value
7200
dhcp-client-identifier-ascii
vrouter running config# vrf <vrf> interface bridge <bridge> ipv4 dhcp
vrouter running dhcp# dhcp-client-identifier-ascii <string>
dhcp-client-identifier-hexa
vrouter running config# vrf <vrf> interface bridge <bridge> ipv4 dhcp
vrouter running dhcp# dhcp-client-identifier-hexa <string>
host-name
vrouter running config# vrf <vrf> interface bridge <bridge> ipv4 dhcp
vrouter running dhcp# host-name <string>
request
DHCP requests.
vrouter running config# vrf <vrf> interface bridge <bridge> ipv4 dhcp
vrouter running dhcp# request REQUEST
Default value
subnet-mask
broadcast-address
time-offset
routers
domain-name
domain-search
domain-name-servers
host-name
nis-domain
nis-servers
ntp-servers
interface-mtu
Current lease.
vrouter> show state vrf <vrf> interface bridge <bridge> ipv4 dhcp current-lease fixed-
˓→address
Time at which the client should begin trying to contact its server to renew its lease.
vrouter> show state vrf <vrf> interface bridge <bridge> ipv4 dhcp current-lease renew
Time at which the client should begin to try to contact any dhcp server to renew its lease.
vrouter> show state vrf <vrf> interface bridge <bridge> ipv4 dhcp current-lease rebind
Time at which the client must stop using a lease if it has not been able to renew it.
vrouter> show state vrf <vrf> interface bridge <bridge> ipv4 dhcp current-lease expire
ipv6
enabled
Controls whether IPv6 is enabled or disabled on this interface. When IPv6 is enabled, this interface is connected to
an IPv6 stack, and the interface can send and receive IPv6 packets.
Default value
true
address
peer
The IPv6 address of the remote endpoint for point to point interfaces.
peer PEER
vrouter> show state vrf <vrf> interface bridge <bridge> ipv6 address <address> origin
The status of an address. Most of the states correspond to states from the IPv6 Stateless Address Autoconfiguration
protocol.
vrouter> show state vrf <vrf> interface bridge <bridge> ipv6 address <address> status
neighbor
link-layer-address (mandatory)
link-layer-address LINK-LAYER-ADDRESS
vrouter> show state vrf <vrf> interface bridge <bridge> ipv6 neighbor <neighbor> router
vrouter> show state vrf <vrf> interface bridge <bridge> ipv6 neighbor <neighbor> state
network-stack
ipv4
IPv4 parameters.
vrouter running config# vrf <vrf> interface bridge <bridge> network-stack ipv4
send-redirects
vrouter running config# vrf <vrf> interface bridge <bridge> network-stack ipv4
vrouter running ipv4# send-redirects true|false
accept-redirects
Accept redirect when acting as a host. It is always disabled when acting as a router. Must be activated at vrf or
system level too to be activated.
vrouter running config# vrf <vrf> interface bridge <bridge> network-stack ipv4
vrouter running ipv4# accept-redirects true|false
accept-source-route
Accept packets with source route option. Must be activated at vrf or system level too to be activated.
vrouter running config# vrf <vrf> interface bridge <bridge> network-stack ipv4
vrouter running ipv4# accept-source-route true|false
arp-announce
Define different restriction levels for announcing the local source IP address from IP packets in ARP requests sent
on interface. Increasing the restriction level gives more chance for receiving answer from the resolved target while
decreasing the level announces more valid sender’s information.
vrouter running config# vrf <vrf> interface bridge <bridge> network-stack ipv4
vrouter running ipv4# arp-announce ARP-ANNOUNCE
Description
ARP-ANNOUNCE
val-
ues
any Use any local address, configured on any interface.
avoid- Try to avoid local addresses that are not in the target’s subnet for this interface. This mode is useful when
not- target hosts reachable via this interface require the source IP address in ARP requests to be part of their
in- logical network configured on the receiving interface. When we generate the request we will check all our
subnet subnets that include the target IP and will preserve the source address if it is from such subnet. If there is
no such subnet we select source address according to the rules for level 2, ‘best-local’.
best- Always use the best local address for this target. In this mode we ignore the source address in the IP packet
local and try to select local address that we prefer for talks with the target host. Such local address is selected
by looking for primary IP addresses on all our subnets on the outgoing interface that include the target
IP address. If no suitable local address is found we select the first local address we have on the outgoing
interface or on all other interfaces, with the hope we will receive reply for our request and even sometimes
no matter the source IP address we announce.
arp-filter
Allows to have multiple network interfaces on the same subnet, and have the ARPs for each interface be answered
based on whether or not the kernel would route a packet from the ARP’d IP out that interface (therefore you must
use source based routing for this to work). In other words it allows control of which cards (usually 1) will respond
to an arp request.
vrouter running config# vrf <vrf> interface bridge <bridge> network-stack ipv4
vrouter running ipv4# arp-filter true|false
arp-ignore
Define different modes for sending replies in response to received ARP requests that resolve local target IP addresses.
vrouter running config# vrf <vrf> interface bridge <bridge> network-stack ipv4
vrouter running ipv4# arp-ignore ARP-IGNORE
ARP-IGNORE Description
values
any Reply for any local target IP address, configured on any interface.
check- Reply only if the target IP address is local address configured on the incoming interface.
interface
check- Reply only if the target IP address is local address configured on the incoming interface and
interface- both with the sender’s IP address are part from same subnet on this interface.
and-subnet
ignore-scope Do not reply for local addresses configured with scope host, only resolutions for global and
link addresses are replied.
ignore-all Do not reply for all local addresses.
log-invalid-addresses
vrouter running config# vrf <vrf> interface bridge <bridge> network-stack ipv4
vrouter running ipv4# log-invalid-addresses true|false
ipv6
IPv6 parameters.
vrouter running config# vrf <vrf> interface bridge <bridge> network-stack ipv6
autoconfiguration
vrouter running config# vrf <vrf> interface bridge <bridge> network-stack ipv6
vrouter running ipv6# autoconfiguration true|false
accept-router-advert
vrouter running config# vrf <vrf> interface bridge <bridge> network-stack ipv6
vrouter running ipv6# accept-router-advert ACCEPT-ROUTER-ADVERT
accept-redirects
Accept redirect when acting as a host. It is always disabled when acting as a router.
vrouter running config# vrf <vrf> interface bridge <bridge> network-stack ipv6
vrouter running ipv6# accept-redirects true|false
accept-source-route
vrouter running config# vrf <vrf> interface bridge <bridge> network-stack ipv6
vrouter running ipv6# accept-source-route true|false
router-solicitations
vrouter running config# vrf <vrf> interface bridge <bridge> network-stack ipv6
vrouter running ipv6# router-solicitations <int16>
use-temporary-addresses
Preference for Privacy Extensions (RFC4941). Not applied to point-to- point and loopback devices (always 0).
vrouter running config# vrf <vrf> interface bridge <bridge> network-stack ipv6
vrouter running ipv6# use-temporary-addresses USE-TEMPORARY-ADDRESSES
USE-TEMPORARY-ADDRESSESDescription
values
never Disable Privacy Extensions, i.e. use the public address, subnet prefix/interface id,
where interface id is always the same.
prefer-public-addresses Enable Privacy Extensions, but prefer public addresses over temporary addresses.
always Enable Privacy Extensions and prefer temporary addresses over public addresses.
stp
enabled
Default value
true
priority
Set this bridge’s spanning tree priority, used during STP root bridge election.
forward-delay
Set the forwarding delay, ie the time spent in LISTENING state (before moving to LEARNING) and in LEARNING
state (before moving to FORWARDING).
max-age
Set the hello packet timeout, ie the time until another bridge in the spanning tree is assumed to be dead, after
reception of its last hello message.
hello-time
Set the time between hello packets sent by the bridge, when it is a root bridge or a designated bridges.
link-interface
learning
learning true|false
Default value
true
qos
QoS configuration.
ingress
vrouter running config# vrf <vrf> interface bridge <bridge> qos ingress
rate-limit
vrouter running config# vrf <vrf> interface bridge <bridge> qos ingress rate-limit
vrouter running config# vrf <vrf> interface bridge <bridge> qos ingress rate-limit
vrouter running rate-limit# policer <leafref>
vrouter running config# vrf <vrf> interface bridge <bridge> qos ingress rate-limit
vrouter running rate-limit# shared-policer <leafref>
Traffic policer.
Maximum bandwidth of regular traffic, a.k.a. CIR (Committed Information Rate), in bps. 0 allows no regular traffic.
vrouter> show state vrf <vrf> interface bridge <bridge> qos ingress rate-limit policer␣
˓→bandwidth
Maximum burst size of shaped traffic, a.k.a. CBS (Committed Burst Size), in bytes. The default value is set to
bandwidth / 80 to handle a burst of 100 ms at the targeted bandwidth. If not set or set to 0, the default value is
applied.
vrouter> show state vrf <vrf> interface bridge <bridge> qos ingress rate-limit policer␣
˓→burst
Maximum bandwidth of excess traffic, a.k.a. EIR (Excess Information Rate), in bps. 0 allows no excess traffic.
vrouter> show state vrf <vrf> interface bridge <bridge> qos ingress rate-limit policer␣
˓→excess-bandwidth
Maximum burst size of excess traffic, a.k.a. EBS (Excess Burst Size), in bytes. The default value is set to excess-
bandwidth / 80 to handle a burst of 100 ms at the targeted bandwidth. If not set or set to 0, the default value is
applied.
vrouter> show state vrf <vrf> interface bridge <bridge> qos ingress rate-limit policer␣
˓→excess-burst
vrouter> show state vrf <vrf> interface bridge <bridge> qos ingress rate-limit policer␣
˓→shared-policer
Number of packets passed (regular traffic that conforms to (bandwidth, burst) specification.
vrouter> show state vrf <vrf> interface bridge <bridge> qos ingress rate-limit policer␣
˓→stats pass-packets
Number of bytes passed (regular traffic that conforms to (bandwidth, burst) specification.
vrouter> show state vrf <vrf> interface bridge <bridge> qos ingress rate-limit policer␣
˓→stats pass-bytes
Number of excess packets passed (excess traffic that conforms to (excess-bandwidth, excess-burst) specification.
vrouter> show state vrf <vrf> interface bridge <bridge> qos ingress rate-limit policer␣
˓→stats pass-excess-packets
Number of excess bytes passed (excess traffic that conforms to (excess-bandwidth, excess-burst) specification.
vrouter> show state vrf <vrf> interface bridge <bridge> qos ingress rate-limit policer␣
˓→stats pass-excess-bytes
Number of packets dropped (traffic that does not conform to bandwidth or excess-bandwidth).
vrouter> show state vrf <vrf> interface bridge <bridge> qos ingress rate-limit policer␣
˓→stats drop-packets
Number of bytes dropped (traffic that does not conform to bandwidth or excess-bandwidth).
vrouter> show state vrf <vrf> interface bridge <bridge> qos ingress rate-limit policer␣
˓→stats drop-bytes
egress
vrouter running config# vrf <vrf> interface bridge <bridge> qos egress
rate-limit
vrouter running config# vrf <vrf> interface bridge <bridge> qos egress rate-limit
vrouter running config# vrf <vrf> interface bridge <bridge> qos egress rate-limit
vrouter running rate-limit# policer <leafref>
vrouter running config# vrf <vrf> interface bridge <bridge> qos egress rate-limit
vrouter running rate-limit# shared-policer <leafref>
Traffic policer.
Maximum bandwidth of regular traffic, a.k.a. CIR (Committed Information Rate), in bps. 0 allows no regular traffic.
vrouter> show state vrf <vrf> interface bridge <bridge> qos egress rate-limit policer␣
˓→bandwidth
Maximum burst size of shaped traffic, a.k.a. CBS (Committed Burst Size), in bytes. The default value is set to
bandwidth / 80 to handle a burst of 100 ms at the targeted bandwidth. If not set or set to 0, the default value is
applied.
vrouter> show state vrf <vrf> interface bridge <bridge> qos egress rate-limit policer␣
˓→burst
Maximum bandwidth of excess traffic, a.k.a. EIR (Excess Information Rate), in bps. 0 allows no excess traffic.
vrouter> show state vrf <vrf> interface bridge <bridge> qos egress rate-limit policer␣
˓→excess-bandwidth
Maximum burst size of excess traffic, a.k.a. EBS (Excess Burst Size), in bytes. The default value is set to excess-
bandwidth / 80 to handle a burst of 100 ms at the targeted bandwidth. If not set or set to 0, the default value is
applied.
vrouter> show state vrf <vrf> interface bridge <bridge> qos egress rate-limit policer␣
˓→excess-burst
vrouter> show state vrf <vrf> interface bridge <bridge> qos egress rate-limit policer␣
˓→shared-policer
Number of packets passed (regular traffic that conforms to (bandwidth, burst) specification.
vrouter> show state vrf <vrf> interface bridge <bridge> qos egress rate-limit policer␣
˓→stats pass-packets
Number of bytes passed (regular traffic that conforms to (bandwidth, burst) specification.
vrouter> show state vrf <vrf> interface bridge <bridge> qos egress rate-limit policer␣
˓→stats pass-bytes
Number of excess packets passed (excess traffic that conforms to (excess-bandwidth, excess-burst) specification.
vrouter> show state vrf <vrf> interface bridge <bridge> qos egress rate-limit policer␣
˓→stats pass-excess-packets
Number of excess bytes passed (excess traffic that conforms to (excess-bandwidth, excess-burst) specification.
vrouter> show state vrf <vrf> interface bridge <bridge> qos egress rate-limit policer␣
˓→stats pass-excess-bytes
Number of packets dropped (traffic that does not conform to bandwidth or excess-bandwidth).
vrouter> show state vrf <vrf> interface bridge <bridge> qos egress rate-limit policer␣
˓→stats drop-packets
Number of bytes dropped (traffic that does not conform to bandwidth or excess-bandwidth).
vrouter> show state vrf <vrf> interface bridge <bridge> qos egress rate-limit policer␣
˓→stats drop-bytes
The total number of octets received on the interface, including framing characters. Discontinuities in the value of
this counter can occur at re-initialization of the management system, and at other times as indicated by the value of
‘last-clear’.
vrouter> show state vrf <vrf> interface bridge <bridge> counters in-octets
The number of packets, delivered by this sub-layer to a higher (sub-)layer, that were not addressed to a multicast or
broadcast address at this sub-layer. Discontinuities in the value of this counter can occur at re-initialization of the
management system, and at other times as indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface bridge <bridge> counters in-unicast-pkts
The number of inbound packets that were chosen to be discarded even though no errors had been detected to prevent
their being deliverable to a higher-layer protocol. One possible reason for discarding such a packet could be to free
up buffer space. Discontinuities in the value of this counter can occur at re-initialization of the management system,
and at other times as indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface bridge <bridge> counters in-discards
For packet-oriented interfaces, the number of inbound packets that contained errors preventing them from being
deliverable to a higher- layer protocol. For character- oriented or fixed-length interfaces, the number of inbound
transmission units that contained errors preventing them from being deliverable to a higher-layer protocol. Discon-
tinuities in the value of this counter can occur at re- initialization of the management system, and at other times as
indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface bridge <bridge> counters in-errors
The total number of octets transmitted out of the interface, including framing characters. Discontinuities in the
value of this counter can occur at re-initialization of the management system, and at other times as indicated by the
value of ‘last-clear’.
vrouter> show state vrf <vrf> interface bridge <bridge> counters out-octets
The total number of packets that higher-level protocols requested be transmitted, and that were not addressed to a
multicast or broadcast address at this sub-layer, including those that were discarded or not sent. Discontinuities in
the value of this counter can occur at re- initialization of the management system, and at other times as indicated by
the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface bridge <bridge> counters out-unicast-pkts
The number of outbound packets that were chosen to be discarded even though no errors had been detected to
prevent their being transmitted. One possible reason for discarding such a packet could be to free up buffer space.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other
times as indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface bridge <bridge> counters out-discards
For packet-oriented interfaces, the number of outbound packets that could not be transmitted because of errors. For
character-oriented or fixed-length interfaces, the number of outbound transmission units that could not be transmitted
because of errors. Discontinuities in the value of this counter can occur at re-initialization of the management system,
and at other times as indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface bridge <bridge> counters out-errors
gre
mtu
promiscuous
description
enabled
Default value
true
ttl
The time-to-live (or hop limit) that should be utilised for the IP packets used for the tunnel transport. If not set, the
ttl is inherited from the inner packet for IPv4 tunnels, and is 64 for IPv6 tunnels.
tos
link-interface
link-vrf
local (mandatory)
remote
checksum
sequence-number
System assigned number for each interface. Corresponds to ifIndex object in SNMP Interface MIB.
The desired state of the interface. In RFC 7223 this leaf has the same read semantics as ifAdminStatus. Here, it
reflects the administrative state as set by enabling or disabling the interface.
The current operational state of the interface. This leaf has the same semantics as ifOperStatus.
This timestamp indicates the time of the last state change of the interface (e.g., up-to-down transition). This corre-
sponds to the ifLastChange object in the standard interface MIB. The value is the timestamp in nanoseconds relative
to the Unix Epoch (Jan 1, 1970 00:00:00 UTC).
ipv4
enabled
Controls whether IPv4 is enabled or disabled on this interface. When IPv4 is enabled, this interface is connected to
an IPv4 stack, and the interface can send and receive IPv4 packets.
Default value
true
address
peer
The IPv4 address of the remote endpoint for point to point interfaces.
peer PEER
The origin of this address, e.g., statically configured, assigned by DHCP, etc..
vrouter> show state vrf <vrf> interface gre <gre> ipv4 address <address> origin
neighbor
link-layer-address (mandatory)
link-layer-address LINK-LAYER-ADDRESS
vrouter> show state vrf <vrf> interface gre <gre> ipv4 neighbor <neighbor> state
ipv6
enabled
Controls whether IPv6 is enabled or disabled on this interface. When IPv6 is enabled, this interface is connected to
an IPv6 stack, and the interface can send and receive IPv6 packets.
Default value
true
address
peer
The IPv6 address of the remote endpoint for point to point interfaces.
peer PEER
vrouter> show state vrf <vrf> interface gre <gre> ipv6 address <address> origin
The status of an address. Most of the states correspond to states from the IPv6 Stateless Address Autoconfiguration
protocol.
vrouter> show state vrf <vrf> interface gre <gre> ipv6 address <address> status
neighbor
link-layer-address (mandatory)
link-layer-address LINK-LAYER-ADDRESS
vrouter> show state vrf <vrf> interface gre <gre> ipv6 neighbor <neighbor> state
network-stack
ipv4
IPv4 parameters.
vrouter running config# vrf <vrf> interface gre <gre> network-stack ipv4
send-redirects
vrouter running config# vrf <vrf> interface gre <gre> network-stack ipv4
vrouter running ipv4# send-redirects true|false
accept-redirects
Accept redirect when acting as a host. It is always disabled when acting as a router. Must be activated at vrf or
system level too to be activated.
vrouter running config# vrf <vrf> interface gre <gre> network-stack ipv4
vrouter running ipv4# accept-redirects true|false
accept-source-route
Accept packets with source route option. Must be activated at vrf or system level too to be activated.
vrouter running config# vrf <vrf> interface gre <gre> network-stack ipv4
vrouter running ipv4# accept-source-route true|false
arp-announce
Define different restriction levels for announcing the local source IP address from IP packets in ARP requests sent
on interface. Increasing the restriction level gives more chance for receiving answer from the resolved target while
decreasing the level announces more valid sender’s information.
vrouter running config# vrf <vrf> interface gre <gre> network-stack ipv4
vrouter running ipv4# arp-announce ARP-ANNOUNCE
Description
ARP-ANNOUNCE
val-
ues
any Use any local address, configured on any interface.
avoid- Try to avoid local addresses that are not in the target’s subnet for this interface. This mode is useful when
not- target hosts reachable via this interface require the source IP address in ARP requests to be part of their
in- logical network configured on the receiving interface. When we generate the request we will check all our
subnet subnets that include the target IP and will preserve the source address if it is from such subnet. If there is
no such subnet we select source address according to the rules for level 2, ‘best-local’.
best- Always use the best local address for this target. In this mode we ignore the source address in the IP packet
local and try to select local address that we prefer for talks with the target host. Such local address is selected
by looking for primary IP addresses on all our subnets on the outgoing interface that include the target
IP address. If no suitable local address is found we select the first local address we have on the outgoing
interface or on all other interfaces, with the hope we will receive reply for our request and even sometimes
no matter the source IP address we announce.
arp-filter
Allows to have multiple network interfaces on the same subnet, and have the ARPs for each interface be answered
based on whether or not the kernel would route a packet from the ARP’d IP out that interface (therefore you must
use source based routing for this to work). In other words it allows control of which cards (usually 1) will respond
to an arp request.
vrouter running config# vrf <vrf> interface gre <gre> network-stack ipv4
vrouter running ipv4# arp-filter true|false
arp-ignore
Define different modes for sending replies in response to received ARP requests that resolve local target IP addresses.
vrouter running config# vrf <vrf> interface gre <gre> network-stack ipv4
vrouter running ipv4# arp-ignore ARP-IGNORE
ARP-IGNORE Description
values
any Reply for any local target IP address, configured on any interface.
check- Reply only if the target IP address is local address configured on the incoming interface.
interface
check- Reply only if the target IP address is local address configured on the incoming interface and
interface- both with the sender’s IP address are part from same subnet on this interface.
and-subnet
ignore-scope Do not reply for local addresses configured with scope host, only resolutions for global and
link addresses are replied.
ignore-all Do not reply for all local addresses.
log-invalid-addresses
vrouter running config# vrf <vrf> interface gre <gre> network-stack ipv4
vrouter running ipv4# log-invalid-addresses true|false
ipv6
IPv6 parameters.
vrouter running config# vrf <vrf> interface gre <gre> network-stack ipv6
autoconfiguration
vrouter running config# vrf <vrf> interface gre <gre> network-stack ipv6
vrouter running ipv6# autoconfiguration true|false
accept-router-advert
vrouter running config# vrf <vrf> interface gre <gre> network-stack ipv6
vrouter running ipv6# accept-router-advert ACCEPT-ROUTER-ADVERT
accept-redirects
Accept redirect when acting as a host. It is always disabled when acting as a router.
vrouter running config# vrf <vrf> interface gre <gre> network-stack ipv6
vrouter running ipv6# accept-redirects true|false
accept-source-route
vrouter running config# vrf <vrf> interface gre <gre> network-stack ipv6
vrouter running ipv6# accept-source-route true|false
router-solicitations
vrouter running config# vrf <vrf> interface gre <gre> network-stack ipv6
vrouter running ipv6# router-solicitations <int16>
use-temporary-addresses
Preference for Privacy Extensions (RFC4941). Not applied to point-to- point and loopback devices (always 0).
vrouter running config# vrf <vrf> interface gre <gre> network-stack ipv6
vrouter running ipv6# use-temporary-addresses USE-TEMPORARY-ADDRESSES
USE-TEMPORARY-ADDRESSESDescription
values
never Disable Privacy Extensions, i.e. use the public address, subnet prefix/interface id,
where interface id is always the same.
prefer-public-addresses Enable Privacy Extensions, but prefer public addresses over temporary addresses.
always Enable Privacy Extensions and prefer temporary addresses over public addresses.
key
input
output
GRE key for outgoing packets (overrides the value specified in both).
both
qos
QoS configuration.
ingress
vrouter running config# vrf <vrf> interface gre <gre> qos ingress
rate-limit
vrouter running config# vrf <vrf> interface gre <gre> qos ingress rate-limit
vrouter running config# vrf <vrf> interface gre <gre> qos ingress rate-limit
vrouter running rate-limit# policer <leafref>
vrouter running config# vrf <vrf> interface gre <gre> qos ingress rate-limit
vrouter running rate-limit# shared-policer <leafref>
Traffic policer.
Maximum bandwidth of regular traffic, a.k.a. CIR (Committed Information Rate), in bps. 0 allows no regular traffic.
vrouter> show state vrf <vrf> interface gre <gre> qos ingress rate-limit policer␣
˓→bandwidth
Maximum burst size of shaped traffic, a.k.a. CBS (Committed Burst Size), in bytes. The default value is set to
bandwidth / 80 to handle a burst of 100 ms at the targeted bandwidth. If not set or set to 0, the default value is
applied.
vrouter> show state vrf <vrf> interface gre <gre> qos ingress rate-limit policer burst
Maximum bandwidth of excess traffic, a.k.a. EIR (Excess Information Rate), in bps. 0 allows no excess traffic.
vrouter> show state vrf <vrf> interface gre <gre> qos ingress rate-limit policer␣
˓→excess-bandwidth
Maximum burst size of excess traffic, a.k.a. EBS (Excess Burst Size), in bytes. The default value is set to excess-
bandwidth / 80 to handle a burst of 100 ms at the targeted bandwidth. If not set or set to 0, the default value is
applied.
vrouter> show state vrf <vrf> interface gre <gre> qos ingress rate-limit policer␣
˓→excess-burst
vrouter> show state vrf <vrf> interface gre <gre> qos ingress rate-limit policer␣
˓→shared-policer
Number of packets passed (regular traffic that conforms to (bandwidth, burst) specification.
vrouter> show state vrf <vrf> interface gre <gre> qos ingress rate-limit policer stats␣
˓→pass-packets
Number of bytes passed (regular traffic that conforms to (bandwidth, burst) specification.
vrouter> show state vrf <vrf> interface gre <gre> qos ingress rate-limit policer stats␣
˓→pass-bytes
Number of excess packets passed (excess traffic that conforms to (excess-bandwidth, excess-burst) specification.
vrouter> show state vrf <vrf> interface gre <gre> qos ingress rate-limit policer stats␣
˓→pass-excess-packets
Number of excess bytes passed (excess traffic that conforms to (excess-bandwidth, excess-burst) specification.
vrouter> show state vrf <vrf> interface gre <gre> qos ingress rate-limit policer stats␣
˓→pass-excess-bytes
Number of packets dropped (traffic that does not conform to bandwidth or excess-bandwidth).
vrouter> show state vrf <vrf> interface gre <gre> qos ingress rate-limit policer stats␣
˓→drop-packets
Number of bytes dropped (traffic that does not conform to bandwidth or excess-bandwidth).
vrouter> show state vrf <vrf> interface gre <gre> qos ingress rate-limit policer stats␣
˓→drop-bytes
egress
vrouter running config# vrf <vrf> interface gre <gre> qos egress
rate-limit
vrouter running config# vrf <vrf> interface gre <gre> qos egress rate-limit
vrouter running config# vrf <vrf> interface gre <gre> qos egress rate-limit
vrouter running rate-limit# policer <leafref>
vrouter running config# vrf <vrf> interface gre <gre> qos egress rate-limit
vrouter running rate-limit# shared-policer <leafref>
Traffic policer.
Maximum bandwidth of regular traffic, a.k.a. CIR (Committed Information Rate), in bps. 0 allows no regular traffic.
vrouter> show state vrf <vrf> interface gre <gre> qos egress rate-limit policer␣
˓→bandwidth
Maximum burst size of shaped traffic, a.k.a. CBS (Committed Burst Size), in bytes. The default value is set to
bandwidth / 80 to handle a burst of 100 ms at the targeted bandwidth. If not set or set to 0, the default value is
applied.
vrouter> show state vrf <vrf> interface gre <gre> qos egress rate-limit policer burst
Maximum bandwidth of excess traffic, a.k.a. EIR (Excess Information Rate), in bps. 0 allows no excess traffic.
vrouter> show state vrf <vrf> interface gre <gre> qos egress rate-limit policer excess-
˓→bandwidth
Maximum burst size of excess traffic, a.k.a. EBS (Excess Burst Size), in bytes. The default value is set to excess-
bandwidth / 80 to handle a burst of 100 ms at the targeted bandwidth. If not set or set to 0, the default value is
applied.
vrouter> show state vrf <vrf> interface gre <gre> qos egress rate-limit policer excess-
˓→burst
vrouter> show state vrf <vrf> interface gre <gre> qos egress rate-limit policer shared-
˓→policer
Number of packets passed (regular traffic that conforms to (bandwidth, burst) specification.
vrouter> show state vrf <vrf> interface gre <gre> qos egress rate-limit policer stats␣
˓→pass-packets
Number of bytes passed (regular traffic that conforms to (bandwidth, burst) specification.
vrouter> show state vrf <vrf> interface gre <gre> qos egress rate-limit policer stats␣
˓→pass-bytes
Number of excess packets passed (excess traffic that conforms to (excess-bandwidth, excess-burst) specification.
vrouter> show state vrf <vrf> interface gre <gre> qos egress rate-limit policer stats␣
˓→pass-excess-packets
Number of excess bytes passed (excess traffic that conforms to (excess-bandwidth, excess-burst) specification.
vrouter> show state vrf <vrf> interface gre <gre> qos egress rate-limit policer stats␣
˓→pass-excess-bytes
Number of packets dropped (traffic that does not conform to bandwidth or excess-bandwidth).
vrouter> show state vrf <vrf> interface gre <gre> qos egress rate-limit policer stats␣
˓→drop-packets
Number of bytes dropped (traffic that does not conform to bandwidth or excess-bandwidth).
vrouter> show state vrf <vrf> interface gre <gre> qos egress rate-limit policer stats␣
˓→drop-bytes
The total number of octets received on the interface, including framing characters. Discontinuities in the value of
this counter can occur at re-initialization of the management system, and at other times as indicated by the value of
‘last-clear’.
vrouter> show state vrf <vrf> interface gre <gre> counters in-octets
The number of packets, delivered by this sub-layer to a higher (sub-)layer, that were not addressed to a multicast or
broadcast address at this sub-layer. Discontinuities in the value of this counter can occur at re-initialization of the
management system, and at other times as indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface gre <gre> counters in-unicast-pkts
The number of inbound packets that were chosen to be discarded even though no errors had been detected to prevent
their being deliverable to a higher-layer protocol. One possible reason for discarding such a packet could be to free
up buffer space. Discontinuities in the value of this counter can occur at re-initialization of the management system,
and at other times as indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface gre <gre> counters in-discards
For packet-oriented interfaces, the number of inbound packets that contained errors preventing them from being
deliverable to a higher- layer protocol. For character- oriented or fixed-length interfaces, the number of inbound
transmission units that contained errors preventing them from being deliverable to a higher-layer protocol. Discon-
tinuities in the value of this counter can occur at re- initialization of the management system, and at other times as
indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface gre <gre> counters in-errors
The total number of octets transmitted out of the interface, including framing characters. Discontinuities in the
value of this counter can occur at re-initialization of the management system, and at other times as indicated by the
value of ‘last-clear’.
vrouter> show state vrf <vrf> interface gre <gre> counters out-octets
The total number of packets that higher-level protocols requested be transmitted, and that were not addressed to a
multicast or broadcast address at this sub-layer, including those that were discarded or not sent. Discontinuities in
the value of this counter can occur at re- initialization of the management system, and at other times as indicated by
the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface gre <gre> counters out-unicast-pkts
The number of outbound packets that were chosen to be discarded even though no errors had been detected to
prevent their being transmitted. One possible reason for discarding such a packet could be to free up buffer space.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other
times as indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface gre <gre> counters out-discards
For packet-oriented interfaces, the number of outbound packets that could not be transmitted because of errors. For
character-oriented or fixed-length interfaces, the number of outbound transmission units that could not be transmitted
because of errors. Discontinuities in the value of this counter can occur at re-initialization of the management system,
and at other times as indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface gre <gre> counters out-errors
ipip
mtu
promiscuous
description
enabled
Default value
true
local (mandatory)
remote (mandatory)
ttl
The time-to-live (or hop limit) that should be utilised for the IP packets used for the tunnel transport. If not set, the
ttl is inherited from the inner packet for IPv4 tunnels, and is 64 for IPv6 tunnels.
tos
link-interface
link-vrf
System assigned number for each interface. Corresponds to ifIndex object in SNMP Interface MIB.
The desired state of the interface. In RFC 7223 this leaf has the same read semantics as ifAdminStatus. Here, it
reflects the administrative state as set by enabling or disabling the interface.
The current operational state of the interface. This leaf has the same semantics as ifOperStatus.
This timestamp indicates the time of the last state change of the interface (e.g., up-to-down transition). This corre-
sponds to the ifLastChange object in the standard interface MIB. The value is the timestamp in nanoseconds relative
to the Unix Epoch (Jan 1, 1970 00:00:00 UTC).
ipv4
enabled
Controls whether IPv4 is enabled or disabled on this interface. When IPv4 is enabled, this interface is connected to
an IPv4 stack, and the interface can send and receive IPv4 packets.
Default value
true
address
peer
The IPv4 address of the remote endpoint for point to point interfaces.
peer PEER
The origin of this address, e.g., statically configured, assigned by DHCP, etc..
vrouter> show state vrf <vrf> interface ipip <ipip> ipv4 address <address> origin
ipv6
enabled
Controls whether IPv6 is enabled or disabled on this interface. When IPv6 is enabled, this interface is connected to
an IPv6 stack, and the interface can send and receive IPv6 packets.
Default value
true
address
peer
The IPv6 address of the remote endpoint for point to point interfaces.
peer PEER
vrouter> show state vrf <vrf> interface ipip <ipip> ipv6 address <address> origin
The status of an address. Most of the states correspond to states from the IPv6 Stateless Address Autoconfiguration
protocol.
vrouter> show state vrf <vrf> interface ipip <ipip> ipv6 address <address> status
network-stack
ipv4
IPv4 parameters.
vrouter running config# vrf <vrf> interface ipip <ipip> network-stack ipv4
send-redirects
vrouter running config# vrf <vrf> interface ipip <ipip> network-stack ipv4
vrouter running ipv4# send-redirects true|false
accept-redirects
Accept redirect when acting as a host. It is always disabled when acting as a router. Must be activated at vrf or
system level too to be activated.
vrouter running config# vrf <vrf> interface ipip <ipip> network-stack ipv4
vrouter running ipv4# accept-redirects true|false
accept-source-route
Accept packets with source route option. Must be activated at vrf or system level too to be activated.
vrouter running config# vrf <vrf> interface ipip <ipip> network-stack ipv4
vrouter running ipv4# accept-source-route true|false
arp-announce
Define different restriction levels for announcing the local source IP address from IP packets in ARP requests sent
on interface. Increasing the restriction level gives more chance for receiving answer from the resolved target while
decreasing the level announces more valid sender’s information.
vrouter running config# vrf <vrf> interface ipip <ipip> network-stack ipv4
vrouter running ipv4# arp-announce ARP-ANNOUNCE
Description
ARP-ANNOUNCE
val-
ues
any Use any local address, configured on any interface.
avoid- Try to avoid local addresses that are not in the target’s subnet for this interface. This mode is useful when
not- target hosts reachable via this interface require the source IP address in ARP requests to be part of their
in- logical network configured on the receiving interface. When we generate the request we will check all our
subnet subnets that include the target IP and will preserve the source address if it is from such subnet. If there is
no such subnet we select source address according to the rules for level 2, ‘best-local’.
best- Always use the best local address for this target. In this mode we ignore the source address in the IP packet
local and try to select local address that we prefer for talks with the target host. Such local address is selected
by looking for primary IP addresses on all our subnets on the outgoing interface that include the target
IP address. If no suitable local address is found we select the first local address we have on the outgoing
interface or on all other interfaces, with the hope we will receive reply for our request and even sometimes
no matter the source IP address we announce.
arp-filter
Allows to have multiple network interfaces on the same subnet, and have the ARPs for each interface be answered
based on whether or not the kernel would route a packet from the ARP’d IP out that interface (therefore you must
use source based routing for this to work). In other words it allows control of which cards (usually 1) will respond
to an arp request.
vrouter running config# vrf <vrf> interface ipip <ipip> network-stack ipv4
vrouter running ipv4# arp-filter true|false
arp-ignore
Define different modes for sending replies in response to received ARP requests that resolve local target IP addresses.
vrouter running config# vrf <vrf> interface ipip <ipip> network-stack ipv4
vrouter running ipv4# arp-ignore ARP-IGNORE
ARP-IGNORE Description
values
any Reply for any local target IP address, configured on any interface.
check- Reply only if the target IP address is local address configured on the incoming interface.
interface
check- Reply only if the target IP address is local address configured on the incoming interface and
interface- both with the sender’s IP address are part from same subnet on this interface.
and-subnet
ignore-scope Do not reply for local addresses configured with scope host, only resolutions for global and
link addresses are replied.
ignore-all Do not reply for all local addresses.
log-invalid-addresses
vrouter running config# vrf <vrf> interface ipip <ipip> network-stack ipv4
vrouter running ipv4# log-invalid-addresses true|false
ipv6
IPv6 parameters.
vrouter running config# vrf <vrf> interface ipip <ipip> network-stack ipv6
autoconfiguration
vrouter running config# vrf <vrf> interface ipip <ipip> network-stack ipv6
vrouter running ipv6# autoconfiguration true|false
accept-router-advert
vrouter running config# vrf <vrf> interface ipip <ipip> network-stack ipv6
vrouter running ipv6# accept-router-advert ACCEPT-ROUTER-ADVERT
accept-redirects
Accept redirect when acting as a host. It is always disabled when acting as a router.
vrouter running config# vrf <vrf> interface ipip <ipip> network-stack ipv6
vrouter running ipv6# accept-redirects true|false
accept-source-route
vrouter running config# vrf <vrf> interface ipip <ipip> network-stack ipv6
vrouter running ipv6# accept-source-route true|false
router-solicitations
vrouter running config# vrf <vrf> interface ipip <ipip> network-stack ipv6
vrouter running ipv6# router-solicitations <int16>
use-temporary-addresses
Preference for Privacy Extensions (RFC4941). Not applied to point-to- point and loopback devices (always 0).
vrouter running config# vrf <vrf> interface ipip <ipip> network-stack ipv6
vrouter running ipv6# use-temporary-addresses USE-TEMPORARY-ADDRESSES
USE-TEMPORARY-ADDRESSESDescription
values
never Disable Privacy Extensions, i.e. use the public address, subnet prefix/interface id,
where interface id is always the same.
prefer-public-addresses Enable Privacy Extensions, but prefer public addresses over temporary addresses.
always Enable Privacy Extensions and prefer temporary addresses over public addresses.
qos
QoS configuration.
ingress
vrouter running config# vrf <vrf> interface ipip <ipip> qos ingress
rate-limit
vrouter running config# vrf <vrf> interface ipip <ipip> qos ingress rate-limit
vrouter running config# vrf <vrf> interface ipip <ipip> qos ingress rate-limit
vrouter running rate-limit# policer <leafref>
vrouter running config# vrf <vrf> interface ipip <ipip> qos ingress rate-limit
vrouter running rate-limit# shared-policer <leafref>
Traffic policer.
Maximum bandwidth of regular traffic, a.k.a. CIR (Committed Information Rate), in bps. 0 allows no regular traffic.
vrouter> show state vrf <vrf> interface ipip <ipip> qos ingress rate-limit policer␣
˓→bandwidth
Maximum burst size of shaped traffic, a.k.a. CBS (Committed Burst Size), in bytes. The default value is set to
bandwidth / 80 to handle a burst of 100 ms at the targeted bandwidth. If not set or set to 0, the default value is
applied.
vrouter> show state vrf <vrf> interface ipip <ipip> qos ingress rate-limit policer␣
˓→burst
Maximum bandwidth of excess traffic, a.k.a. EIR (Excess Information Rate), in bps. 0 allows no excess traffic.
vrouter> show state vrf <vrf> interface ipip <ipip> qos ingress rate-limit policer␣
˓→excess-bandwidth
Maximum burst size of excess traffic, a.k.a. EBS (Excess Burst Size), in bytes. The default value is set to excess-
bandwidth / 80 to handle a burst of 100 ms at the targeted bandwidth. If not set or set to 0, the default value is
applied.
vrouter> show state vrf <vrf> interface ipip <ipip> qos ingress rate-limit policer␣
˓→excess-burst
vrouter> show state vrf <vrf> interface ipip <ipip> qos ingress rate-limit policer␣
˓→shared-policer
Number of packets passed (regular traffic that conforms to (bandwidth, burst) specification.
vrouter> show state vrf <vrf> interface ipip <ipip> qos ingress rate-limit policer␣
˓→stats pass-packets
Number of bytes passed (regular traffic that conforms to (bandwidth, burst) specification.
vrouter> show state vrf <vrf> interface ipip <ipip> qos ingress rate-limit policer␣
˓→stats pass-bytes
Number of excess packets passed (excess traffic that conforms to (excess-bandwidth, excess-burst) specification.
vrouter> show state vrf <vrf> interface ipip <ipip> qos ingress rate-limit policer␣
˓→stats pass-excess-packets
Number of excess bytes passed (excess traffic that conforms to (excess-bandwidth, excess-burst) specification.
vrouter> show state vrf <vrf> interface ipip <ipip> qos ingress rate-limit policer␣
˓→stats pass-excess-bytes
Number of packets dropped (traffic that does not conform to bandwidth or excess-bandwidth).
vrouter> show state vrf <vrf> interface ipip <ipip> qos ingress rate-limit policer␣
˓→stats drop-packets
Number of bytes dropped (traffic that does not conform to bandwidth or excess-bandwidth).
vrouter> show state vrf <vrf> interface ipip <ipip> qos ingress rate-limit policer␣
˓→stats drop-bytes
egress
vrouter running config# vrf <vrf> interface ipip <ipip> qos egress
rate-limit
vrouter running config# vrf <vrf> interface ipip <ipip> qos egress rate-limit
vrouter running config# vrf <vrf> interface ipip <ipip> qos egress rate-limit
vrouter running rate-limit# policer <leafref>
vrouter running config# vrf <vrf> interface ipip <ipip> qos egress rate-limit
vrouter running rate-limit# shared-policer <leafref>
Traffic policer.
Maximum bandwidth of regular traffic, a.k.a. CIR (Committed Information Rate), in bps. 0 allows no regular traffic.
vrouter> show state vrf <vrf> interface ipip <ipip> qos egress rate-limit policer␣
˓→bandwidth
Maximum burst size of shaped traffic, a.k.a. CBS (Committed Burst Size), in bytes. The default value is set to
bandwidth / 80 to handle a burst of 100 ms at the targeted bandwidth. If not set or set to 0, the default value is
applied.
vrouter> show state vrf <vrf> interface ipip <ipip> qos egress rate-limit policer burst
Maximum bandwidth of excess traffic, a.k.a. EIR (Excess Information Rate), in bps. 0 allows no excess traffic.
vrouter> show state vrf <vrf> interface ipip <ipip> qos egress rate-limit policer␣
˓→excess-bandwidth
Maximum burst size of excess traffic, a.k.a. EBS (Excess Burst Size), in bytes. The default value is set to excess-
bandwidth / 80 to handle a burst of 100 ms at the targeted bandwidth. If not set or set to 0, the default value is
applied.
vrouter> show state vrf <vrf> interface ipip <ipip> qos egress rate-limit policer␣
˓→excess-burst
vrouter> show state vrf <vrf> interface ipip <ipip> qos egress rate-limit policer␣
˓→shared-policer
Number of packets passed (regular traffic that conforms to (bandwidth, burst) specification.
vrouter> show state vrf <vrf> interface ipip <ipip> qos egress rate-limit policer␣
˓→stats pass-packets
Number of bytes passed (regular traffic that conforms to (bandwidth, burst) specification.
vrouter> show state vrf <vrf> interface ipip <ipip> qos egress rate-limit policer␣
˓→stats pass-bytes
Number of excess packets passed (excess traffic that conforms to (excess-bandwidth, excess-burst) specification.
vrouter> show state vrf <vrf> interface ipip <ipip> qos egress rate-limit policer␣
˓→stats pass-excess-packets
Number of excess bytes passed (excess traffic that conforms to (excess-bandwidth, excess-burst) specification.
vrouter> show state vrf <vrf> interface ipip <ipip> qos egress rate-limit policer␣
˓→stats pass-excess-bytes
Number of packets dropped (traffic that does not conform to bandwidth or excess-bandwidth).
vrouter> show state vrf <vrf> interface ipip <ipip> qos egress rate-limit policer␣
˓→stats drop-packets
Number of bytes dropped (traffic that does not conform to bandwidth or excess-bandwidth).
vrouter> show state vrf <vrf> interface ipip <ipip> qos egress rate-limit policer␣
˓→stats drop-bytes
The total number of octets received on the interface, including framing characters. Discontinuities in the value of
this counter can occur at re-initialization of the management system, and at other times as indicated by the value of
‘last-clear’.
vrouter> show state vrf <vrf> interface ipip <ipip> counters in-octets
The number of packets, delivered by this sub-layer to a higher (sub-)layer, that were not addressed to a multicast or
broadcast address at this sub-layer. Discontinuities in the value of this counter can occur at re-initialization of the
management system, and at other times as indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface ipip <ipip> counters in-unicast-pkts
The number of inbound packets that were chosen to be discarded even though no errors had been detected to prevent
their being deliverable to a higher-layer protocol. One possible reason for discarding such a packet could be to free
up buffer space. Discontinuities in the value of this counter can occur at re-initialization of the management system,
and at other times as indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface ipip <ipip> counters in-discards
For packet-oriented interfaces, the number of inbound packets that contained errors preventing them from being
deliverable to a higher- layer protocol. For character- oriented or fixed-length interfaces, the number of inbound
transmission units that contained errors preventing them from being deliverable to a higher-layer protocol. Discon-
tinuities in the value of this counter can occur at re- initialization of the management system, and at other times as
indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface ipip <ipip> counters in-errors
The total number of octets transmitted out of the interface, including framing characters. Discontinuities in the
value of this counter can occur at re-initialization of the management system, and at other times as indicated by the
value of ‘last-clear’.
vrouter> show state vrf <vrf> interface ipip <ipip> counters out-octets
The total number of packets that higher-level protocols requested be transmitted, and that were not addressed to a
multicast or broadcast address at this sub-layer, including those that were discarded or not sent. Discontinuities in
the value of this counter can occur at re- initialization of the management system, and at other times as indicated by
the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface ipip <ipip> counters out-unicast-pkts
The number of outbound packets that were chosen to be discarded even though no errors had been detected to
prevent their being transmitted. One possible reason for discarding such a packet could be to free up buffer space.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other
times as indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface ipip <ipip> counters out-discards
For packet-oriented interfaces, the number of outbound packets that could not be transmitted because of errors. For
character-oriented or fixed-length interfaces, the number of outbound transmission units that could not be transmitted
because of errors. Discontinuities in the value of this counter can occur at re-initialization of the management system,
and at other times as indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface ipip <ipip> counters out-errors
lag
mtu
promiscuous
description
enabled
Default value
true
mode (mandatory)
LAG mode.
xmit-hash-policy
LAG xmit hash policy to use for slave selection in xor or lacp modes.
lacp-rate
mii-link-monitoring
Default value
100
System assigned number for each interface. Corresponds to ifIndex object in SNMP Interface MIB.
The desired state of the interface. In RFC 7223 this leaf has the same read semantics as ifAdminStatus. Here, it
reflects the administrative state as set by enabling or disabling the interface.
The current operational state of the interface. This leaf has the same semantics as ifOperStatus.
This timestamp indicates the time of the last state change of the interface (e.g., up-to-down transition). This corre-
sponds to the ifLastChange object in the standard interface MIB. The value is the timestamp in nanoseconds relative
to the Unix Epoch (Jan 1, 1970 00:00:00 UTC).
ethernet
mac-address
Assigns a MAC address to the Ethernet interface. If not specified, the corresponding operational state leaf is expected
to show the system-assigned MAC address.
MAC- An IEEE 802 unicast MAC address i.e. the second digit is an even number. Moreover the mac
ADDRESS address must not be 00:00:00:00:00:00.
ipv4
enabled
Controls whether IPv4 is enabled or disabled on this interface. When IPv4 is enabled, this interface is connected to
an IPv4 stack, and the interface can send and receive IPv4 packets.
Default value
true
address
peer
The IPv4 address of the remote endpoint for point to point interfaces.
peer PEER
The origin of this address, e.g., statically configured, assigned by DHCP, etc..
vrouter> show state vrf <vrf> interface lag <lag> ipv4 address <address> origin
neighbor
A list of mappings from IPv4 addresses to link-layer addresses. Entries in this list are used as static entries in the
ARP Cache.
link-layer-address (mandatory)
link-layer-address LINK-LAYER-ADDRESS
vrouter> show state vrf <vrf> interface lag <lag> ipv4 neighbor <neighbor> state
dhcp
vrouter running config# vrf <vrf> interface lag <lag> ipv4 dhcp
enabled
vrouter running config# vrf <vrf> interface lag <lag> ipv4 dhcp
vrouter running dhcp# enabled true|false
Default value
true
timeout
Time before deciding that it’s not going to be able to contact a server.
vrouter running config# vrf <vrf> interface lag <lag> ipv4 dhcp
vrouter running dhcp# timeout <uint32>
Default value
60
retry
vrouter running config# vrf <vrf> interface lag <lag> ipv4 dhcp
vrouter running dhcp# retry <uint32>
Default value
300
select-timeout
Time at which the client stops waiting for other offers from servers.
vrouter running config# vrf <vrf> interface lag <lag> ipv4 dhcp
vrouter running dhcp# select-timeout <uint32>
Default value
0
reboot
Time after trying to reacquire its old address before trying to discover a new address.
vrouter running config# vrf <vrf> interface lag <lag> ipv4 dhcp
vrouter running dhcp# reboot <uint32>
Default value
10
initial-interval
Time between the first attempt to reach a server and the second attempt to reach a server.
vrouter running config# vrf <vrf> interface lag <lag> ipv4 dhcp
vrouter running dhcp# initial-interval <uint32>
Default value
10
dhcp-lease-time
vrouter running config# vrf <vrf> interface lag <lag> ipv4 dhcp
vrouter running dhcp# dhcp-lease-time <uint32>
Default value
7200
dhcp-client-identifier-ascii
vrouter running config# vrf <vrf> interface lag <lag> ipv4 dhcp
vrouter running dhcp# dhcp-client-identifier-ascii <string>
dhcp-client-identifier-hexa
vrouter running config# vrf <vrf> interface lag <lag> ipv4 dhcp
vrouter running dhcp# dhcp-client-identifier-hexa <string>
host-name
vrouter running config# vrf <vrf> interface lag <lag> ipv4 dhcp
vrouter running dhcp# host-name <string>
request
DHCP requests.
vrouter running config# vrf <vrf> interface lag <lag> ipv4 dhcp
vrouter running dhcp# request REQUEST
Default value
subnet-mask
broadcast-address
time-offset
routers
domain-name
domain-search
domain-name-servers
host-name
nis-domain
nis-servers
ntp-servers
interface-mtu
Current lease.
vrouter> show state vrf <vrf> interface lag <lag> ipv4 dhcp current-lease fixed-address
Time at which the client should begin trying to contact its server to renew its lease.
vrouter> show state vrf <vrf> interface lag <lag> ipv4 dhcp current-lease renew
Time at which the client should begin to try to contact any dhcp server to renew its lease.
vrouter> show state vrf <vrf> interface lag <lag> ipv4 dhcp current-lease rebind
Time at which the client must stop using a lease if it has not been able to renew it.
vrouter> show state vrf <vrf> interface lag <lag> ipv4 dhcp current-lease expire
ipv6
enabled
Controls whether IPv6 is enabled or disabled on this interface. When IPv6 is enabled, this interface is connected to
an IPv6 stack, and the interface can send and receive IPv6 packets.
Default value
true
address
peer
The IPv6 address of the remote endpoint for point to point interfaces.
peer PEER
vrouter> show state vrf <vrf> interface lag <lag> ipv6 address <address> origin
The status of an address. Most of the states correspond to states from the IPv6 Stateless Address Autoconfiguration
protocol.
vrouter> show state vrf <vrf> interface lag <lag> ipv6 address <address> status
neighbor
link-layer-address (mandatory)
link-layer-address LINK-LAYER-ADDRESS
vrouter> show state vrf <vrf> interface lag <lag> ipv6 neighbor <neighbor> router
vrouter> show state vrf <vrf> interface lag <lag> ipv6 neighbor <neighbor> state
network-stack
ipv4
IPv4 parameters.
vrouter running config# vrf <vrf> interface lag <lag> network-stack ipv4
send-redirects
vrouter running config# vrf <vrf> interface lag <lag> network-stack ipv4
vrouter running ipv4# send-redirects true|false
accept-redirects
Accept redirect when acting as a host. It is always disabled when acting as a router. Must be activated at vrf or
system level too to be activated.
vrouter running config# vrf <vrf> interface lag <lag> network-stack ipv4
vrouter running ipv4# accept-redirects true|false
accept-source-route
Accept packets with source route option. Must be activated at vrf or system level too to be activated.
vrouter running config# vrf <vrf> interface lag <lag> network-stack ipv4
vrouter running ipv4# accept-source-route true|false
arp-announce
Define different restriction levels for announcing the local source IP address from IP packets in ARP requests sent
on interface. Increasing the restriction level gives more chance for receiving answer from the resolved target while
decreasing the level announces more valid sender’s information.
vrouter running config# vrf <vrf> interface lag <lag> network-stack ipv4
vrouter running ipv4# arp-announce ARP-ANNOUNCE
Description
ARP-ANNOUNCE
val-
ues
any Use any local address, configured on any interface.
avoid- Try to avoid local addresses that are not in the target’s subnet for this interface. This mode is useful when
not- target hosts reachable via this interface require the source IP address in ARP requests to be part of their
in- logical network configured on the receiving interface. When we generate the request we will check all our
subnet subnets that include the target IP and will preserve the source address if it is from such subnet. If there is
no such subnet we select source address according to the rules for level 2, ‘best-local’.
best- Always use the best local address for this target. In this mode we ignore the source address in the IP packet
local and try to select local address that we prefer for talks with the target host. Such local address is selected
by looking for primary IP addresses on all our subnets on the outgoing interface that include the target
IP address. If no suitable local address is found we select the first local address we have on the outgoing
interface or on all other interfaces, with the hope we will receive reply for our request and even sometimes
no matter the source IP address we announce.
arp-filter
Allows to have multiple network interfaces on the same subnet, and have the ARPs for each interface be answered
based on whether or not the kernel would route a packet from the ARP’d IP out that interface (therefore you must
use source based routing for this to work). In other words it allows control of which cards (usually 1) will respond
to an arp request.
vrouter running config# vrf <vrf> interface lag <lag> network-stack ipv4
vrouter running ipv4# arp-filter true|false
arp-ignore
Define different modes for sending replies in response to received ARP requests that resolve local target IP addresses.
vrouter running config# vrf <vrf> interface lag <lag> network-stack ipv4
vrouter running ipv4# arp-ignore ARP-IGNORE
ARP-IGNORE Description
values
any Reply for any local target IP address, configured on any interface.
check- Reply only if the target IP address is local address configured on the incoming interface.
interface
check- Reply only if the target IP address is local address configured on the incoming interface and
interface- both with the sender’s IP address are part from same subnet on this interface.
and-subnet
ignore-scope Do not reply for local addresses configured with scope host, only resolutions for global and
link addresses are replied.
ignore-all Do not reply for all local addresses.
log-invalid-addresses
vrouter running config# vrf <vrf> interface lag <lag> network-stack ipv4
vrouter running ipv4# log-invalid-addresses true|false
ipv6
IPv6 parameters.
vrouter running config# vrf <vrf> interface lag <lag> network-stack ipv6
autoconfiguration
vrouter running config# vrf <vrf> interface lag <lag> network-stack ipv6
vrouter running ipv6# autoconfiguration true|false
accept-router-advert
vrouter running config# vrf <vrf> interface lag <lag> network-stack ipv6
vrouter running ipv6# accept-router-advert ACCEPT-ROUTER-ADVERT
accept-redirects
Accept redirect when acting as a host. It is always disabled when acting as a router.
vrouter running config# vrf <vrf> interface lag <lag> network-stack ipv6
vrouter running ipv6# accept-redirects true|false
accept-source-route
vrouter running config# vrf <vrf> interface lag <lag> network-stack ipv6
vrouter running ipv6# accept-source-route true|false
router-solicitations
vrouter running config# vrf <vrf> interface lag <lag> network-stack ipv6
vrouter running ipv6# router-solicitations <int16>
use-temporary-addresses
Preference for Privacy Extensions (RFC4941). Not applied to point-to- point and loopback devices (always 0).
vrouter running config# vrf <vrf> interface lag <lag> network-stack ipv6
vrouter running ipv6# use-temporary-addresses USE-TEMPORARY-ADDRESSES
USE-TEMPORARY-ADDRESSESDescription
values
never Disable Privacy Extensions, i.e. use the public address, subnet prefix/interface id,
where interface id is always the same.
prefer-public-addresses Enable Privacy Extensions, but prefer public addresses over temporary addresses.
always Enable Privacy Extensions and prefer temporary addresses over public addresses.
link-interface
Slave state.
vrouter> show state vrf <vrf> interface lag <lag> link-interface <link-interface> state
vrouter> show state vrf <vrf> interface lag <lag> link-interface <link-interface> link
vrouter> show state vrf <vrf> interface lag <lag> link-interface <link-interface>␣
˓→failure-count
primary
interface (mandatory)
Lag primary interface. After recovery, this interface become the active interface according to the reselect policy.
interface INTERFACE
reselect-policy
Specifies the reselection policy for the primary interface. This affects how the primary interface is chosen to become
active when failure of the current active interface or recovery of the primary interface occurs.
reselect-policy RESELECT-POLICY
RESELECT-POLICY Description
values
always The primary interface becomes active whenever it comes back up.
better The primary interface becomes active when it comes back up, if its speed and duplex is better
than the speed and duplex of the current active slave.
failure The primary interface becomes active only if it is up and the current active interface fails.
Default value
always
qos
QoS configuration.
ingress
vrouter running config# vrf <vrf> interface lag <lag> qos ingress
rate-limit
vrouter running config# vrf <vrf> interface lag <lag> qos ingress rate-limit
vrouter running config# vrf <vrf> interface lag <lag> qos ingress rate-limit
vrouter running rate-limit# policer <leafref>
vrouter running config# vrf <vrf> interface lag <lag> qos ingress rate-limit
vrouter running rate-limit# shared-policer <leafref>
Traffic policer.
Maximum bandwidth of regular traffic, a.k.a. CIR (Committed Information Rate), in bps. 0 allows no regular traffic.
vrouter> show state vrf <vrf> interface lag <lag> qos ingress rate-limit policer␣
˓→bandwidth
Maximum burst size of shaped traffic, a.k.a. CBS (Committed Burst Size), in bytes. The default value is set to
bandwidth / 80 to handle a burst of 100 ms at the targeted bandwidth. If not set or set to 0, the default value is
applied.
vrouter> show state vrf <vrf> interface lag <lag> qos ingress rate-limit policer burst
Maximum bandwidth of excess traffic, a.k.a. EIR (Excess Information Rate), in bps. 0 allows no excess traffic.
vrouter> show state vrf <vrf> interface lag <lag> qos ingress rate-limit policer␣
˓→excess-bandwidth
Maximum burst size of excess traffic, a.k.a. EBS (Excess Burst Size), in bytes. The default value is set to excess-
bandwidth / 80 to handle a burst of 100 ms at the targeted bandwidth. If not set or set to 0, the default value is
applied.
vrouter> show state vrf <vrf> interface lag <lag> qos ingress rate-limit policer␣
˓→excess-burst
vrouter> show state vrf <vrf> interface lag <lag> qos ingress rate-limit policer␣
˓→shared-policer
Number of packets passed (regular traffic that conforms to (bandwidth, burst) specification.
vrouter> show state vrf <vrf> interface lag <lag> qos ingress rate-limit policer stats␣
˓→pass-packets
Number of bytes passed (regular traffic that conforms to (bandwidth, burst) specification.
vrouter> show state vrf <vrf> interface lag <lag> qos ingress rate-limit policer stats␣
˓→pass-bytes
Number of excess packets passed (excess traffic that conforms to (excess-bandwidth, excess-burst) specification.
vrouter> show state vrf <vrf> interface lag <lag> qos ingress rate-limit policer stats␣
˓→pass-excess-packets
Number of excess bytes passed (excess traffic that conforms to (excess-bandwidth, excess-burst) specification.
vrouter> show state vrf <vrf> interface lag <lag> qos ingress rate-limit policer stats␣
˓→pass-excess-bytes
Number of packets dropped (traffic that does not conform to bandwidth or excess-bandwidth).
vrouter> show state vrf <vrf> interface lag <lag> qos ingress rate-limit policer stats␣
˓→drop-packets
Number of bytes dropped (traffic that does not conform to bandwidth or excess-bandwidth).
vrouter> show state vrf <vrf> interface lag <lag> qos ingress rate-limit policer stats␣
˓→drop-bytes
egress
vrouter running config# vrf <vrf> interface lag <lag> qos egress
rate-limit
vrouter running config# vrf <vrf> interface lag <lag> qos egress rate-limit
vrouter running config# vrf <vrf> interface lag <lag> qos egress rate-limit
vrouter running rate-limit# policer <leafref>
vrouter running config# vrf <vrf> interface lag <lag> qos egress rate-limit
vrouter running rate-limit# shared-policer <leafref>
Traffic policer.
Maximum bandwidth of regular traffic, a.k.a. CIR (Committed Information Rate), in bps. 0 allows no regular traffic.
vrouter> show state vrf <vrf> interface lag <lag> qos egress rate-limit policer␣
˓→bandwidth
Maximum burst size of shaped traffic, a.k.a. CBS (Committed Burst Size), in bytes. The default value is set to
bandwidth / 80 to handle a burst of 100 ms at the targeted bandwidth. If not set or set to 0, the default value is
applied.
vrouter> show state vrf <vrf> interface lag <lag> qos egress rate-limit policer burst
Maximum bandwidth of excess traffic, a.k.a. EIR (Excess Information Rate), in bps. 0 allows no excess traffic.
vrouter> show state vrf <vrf> interface lag <lag> qos egress rate-limit policer excess-
˓→bandwidth
Maximum burst size of excess traffic, a.k.a. EBS (Excess Burst Size), in bytes. The default value is set to excess-
bandwidth / 80 to handle a burst of 100 ms at the targeted bandwidth. If not set or set to 0, the default value is
applied.
vrouter> show state vrf <vrf> interface lag <lag> qos egress rate-limit policer excess-
˓→burst
vrouter> show state vrf <vrf> interface lag <lag> qos egress rate-limit policer shared-
˓→policer
Number of packets passed (regular traffic that conforms to (bandwidth, burst) specification.
vrouter> show state vrf <vrf> interface lag <lag> qos egress rate-limit policer stats␣
˓→pass-packets
Number of bytes passed (regular traffic that conforms to (bandwidth, burst) specification.
vrouter> show state vrf <vrf> interface lag <lag> qos egress rate-limit policer stats␣
˓→pass-bytes
Number of excess packets passed (excess traffic that conforms to (excess-bandwidth, excess-burst) specification.
vrouter> show state vrf <vrf> interface lag <lag> qos egress rate-limit policer stats␣
˓→pass-excess-packets
Number of excess bytes passed (excess traffic that conforms to (excess-bandwidth, excess-burst) specification.
vrouter> show state vrf <vrf> interface lag <lag> qos egress rate-limit policer stats␣
˓→pass-excess-bytes
Number of packets dropped (traffic that does not conform to bandwidth or excess-bandwidth).
vrouter> show state vrf <vrf> interface lag <lag> qos egress rate-limit policer stats␣
˓→drop-packets
Number of bytes dropped (traffic that does not conform to bandwidth or excess-bandwidth).
vrouter> show state vrf <vrf> interface lag <lag> qos egress rate-limit policer stats␣
˓→drop-bytes
The total number of octets received on the interface, including framing characters. Discontinuities in the value of
this counter can occur at re-initialization of the management system, and at other times as indicated by the value of
‘last-clear’.
vrouter> show state vrf <vrf> interface lag <lag> counters in-octets
The number of packets, delivered by this sub-layer to a higher (sub-)layer, that were not addressed to a multicast or
broadcast address at this sub-layer. Discontinuities in the value of this counter can occur at re-initialization of the
management system, and at other times as indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface lag <lag> counters in-unicast-pkts
The number of inbound packets that were chosen to be discarded even though no errors had been detected to prevent
their being deliverable to a higher-layer protocol. One possible reason for discarding such a packet could be to free
up buffer space. Discontinuities in the value of this counter can occur at re-initialization of the management system,
and at other times as indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface lag <lag> counters in-discards
For packet-oriented interfaces, the number of inbound packets that contained errors preventing them from being
deliverable to a higher- layer protocol. For character- oriented or fixed-length interfaces, the number of inbound
transmission units that contained errors preventing them from being deliverable to a higher-layer protocol. Discon-
tinuities in the value of this counter can occur at re- initialization of the management system, and at other times as
indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface lag <lag> counters in-errors
The total number of octets transmitted out of the interface, including framing characters. Discontinuities in the
value of this counter can occur at re-initialization of the management system, and at other times as indicated by the
value of ‘last-clear’.
vrouter> show state vrf <vrf> interface lag <lag> counters out-octets
The total number of packets that higher-level protocols requested be transmitted, and that were not addressed to a
multicast or broadcast address at this sub-layer, including those that were discarded or not sent. Discontinuities in
the value of this counter can occur at re- initialization of the management system, and at other times as indicated by
the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface lag <lag> counters out-unicast-pkts
The number of outbound packets that were chosen to be discarded even though no errors had been detected to
prevent their being transmitted. One possible reason for discarding such a packet could be to free up buffer space.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other
times as indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface lag <lag> counters out-discards
For packet-oriented interfaces, the number of outbound packets that could not be transmitted because of errors. For
character-oriented or fixed-length interfaces, the number of outbound transmission units that could not be transmitted
because of errors. Discontinuities in the value of this counter can occur at re-initialization of the management system,
and at other times as indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface lag <lag> counters out-errors
loopback
mtu
promiscuous
description
enabled
Default value
true
System assigned number for each interface. Corresponds to ifIndex object in SNMP Interface MIB.
The desired state of the interface. In RFC 7223 this leaf has the same read semantics as ifAdminStatus. Here, it
reflects the administrative state as set by enabling or disabling the interface.
The current operational state of the interface. This leaf has the same semantics as ifOperStatus.
This timestamp indicates the time of the last state change of the interface (e.g., up-to-down transition). This corre-
sponds to the ifLastChange object in the standard interface MIB. The value is the timestamp in nanoseconds relative
to the Unix Epoch (Jan 1, 1970 00:00:00 UTC).
ipv4
enabled
Controls whether IPv4 is enabled or disabled on this interface. When IPv4 is enabled, this interface is connected to
an IPv4 stack, and the interface can send and receive IPv4 packets.
Default value
true
address
peer
The IPv4 address of the remote endpoint for point to point interfaces.
peer PEER
The origin of this address, e.g., statically configured, assigned by DHCP, etc..
vrouter> show state vrf <vrf> interface loopback <loopback> ipv4 address <address>␣
˓→origin
neighbor
A list of mappings from IPv4 addresses to link-layer addresses. Entries in this list are used as static entries in the
ARP Cache.
link-layer-address (mandatory)
link-layer-address LINK-LAYER-ADDRESS
vrouter> show state vrf <vrf> interface loopback <loopback> ipv4 neighbor <neighbor>␣
˓→state
dhcp
vrouter running config# vrf <vrf> interface loopback <loopback> ipv4 dhcp
enabled
vrouter running config# vrf <vrf> interface loopback <loopback> ipv4 dhcp
vrouter running dhcp# enabled true|false
Default value
true
timeout
Time before deciding that it’s not going to be able to contact a server.
vrouter running config# vrf <vrf> interface loopback <loopback> ipv4 dhcp
vrouter running dhcp# timeout <uint32>
Default value
60
retry
vrouter running config# vrf <vrf> interface loopback <loopback> ipv4 dhcp
vrouter running dhcp# retry <uint32>
Default value
300
select-timeout
Time at which the client stops waiting for other offers from servers.
vrouter running config# vrf <vrf> interface loopback <loopback> ipv4 dhcp
vrouter running dhcp# select-timeout <uint32>
Default value
0
reboot
Time after trying to reacquire its old address before trying to discover a new address.
vrouter running config# vrf <vrf> interface loopback <loopback> ipv4 dhcp
vrouter running dhcp# reboot <uint32>
Default value
10
initial-interval
Time between the first attempt to reach a server and the second attempt to reach a server.
vrouter running config# vrf <vrf> interface loopback <loopback> ipv4 dhcp
vrouter running dhcp# initial-interval <uint32>
Default value
10
dhcp-lease-time
vrouter running config# vrf <vrf> interface loopback <loopback> ipv4 dhcp
vrouter running dhcp# dhcp-lease-time <uint32>
Default value
7200
dhcp-client-identifier-ascii
vrouter running config# vrf <vrf> interface loopback <loopback> ipv4 dhcp
vrouter running dhcp# dhcp-client-identifier-ascii <string>
dhcp-client-identifier-hexa
vrouter running config# vrf <vrf> interface loopback <loopback> ipv4 dhcp
vrouter running dhcp# dhcp-client-identifier-hexa <string>
host-name
vrouter running config# vrf <vrf> interface loopback <loopback> ipv4 dhcp
vrouter running dhcp# host-name <string>
request
DHCP requests.
vrouter running config# vrf <vrf> interface loopback <loopback> ipv4 dhcp
vrouter running dhcp# request REQUEST
Default value
subnet-mask
broadcast-address
time-offset
routers
domain-name
domain-search
domain-name-servers
host-name
nis-domain
nis-servers
ntp-servers
interface-mtu
Current lease.
vrouter> show state vrf <vrf> interface loopback <loopback> ipv4 dhcp current-lease␣
˓→fixed-address
Time at which the client should begin trying to contact its server to renew its lease.
vrouter> show state vrf <vrf> interface loopback <loopback> ipv4 dhcp current-lease␣
˓→renew
Time at which the client should begin to try to contact any dhcp server to renew its lease.
vrouter> show state vrf <vrf> interface loopback <loopback> ipv4 dhcp current-lease␣
˓→rebind
Time at which the client must stop using a lease if it has not been able to renew it.
vrouter> show state vrf <vrf> interface loopback <loopback> ipv4 dhcp current-lease␣
˓→expire
ipv6
enabled
Controls whether IPv6 is enabled or disabled on this interface. When IPv6 is enabled, this interface is connected to
an IPv6 stack, and the interface can send and receive IPv6 packets.
Default value
true
address
peer
The IPv6 address of the remote endpoint for point to point interfaces.
peer PEER
vrouter> show state vrf <vrf> interface loopback <loopback> ipv6 address <address>␣
˓→origin
The status of an address. Most of the states correspond to states from the IPv6 Stateless Address Autoconfiguration
protocol.
vrouter> show state vrf <vrf> interface loopback <loopback> ipv6 address <address>␣
˓→status
neighbor
link-layer-address (mandatory)
link-layer-address LINK-LAYER-ADDRESS
vrouter> show state vrf <vrf> interface loopback <loopback> ipv6 neighbor <neighbor>␣
˓→router
vrouter> show state vrf <vrf> interface loopback <loopback> ipv6 neighbor <neighbor>␣
˓→state
network-stack
ipv4
IPv4 parameters.
vrouter running config# vrf <vrf> interface loopback <loopback> network-stack ipv4
send-redirects
vrouter running config# vrf <vrf> interface loopback <loopback> network-stack ipv4
vrouter running ipv4# send-redirects true|false
accept-redirects
Accept redirect when acting as a host. It is always disabled when acting as a router. Must be activated at vrf or
system level too to be activated.
vrouter running config# vrf <vrf> interface loopback <loopback> network-stack ipv4
vrouter running ipv4# accept-redirects true|false
accept-source-route
Accept packets with source route option. Must be activated at vrf or system level too to be activated.
vrouter running config# vrf <vrf> interface loopback <loopback> network-stack ipv4
vrouter running ipv4# accept-source-route true|false
arp-announce
Define different restriction levels for announcing the local source IP address from IP packets in ARP requests sent
on interface. Increasing the restriction level gives more chance for receiving answer from the resolved target while
decreasing the level announces more valid sender’s information.
vrouter running config# vrf <vrf> interface loopback <loopback> network-stack ipv4
vrouter running ipv4# arp-announce ARP-ANNOUNCE
Description
ARP-ANNOUNCE
val-
ues
any Use any local address, configured on any interface.
avoid- Try to avoid local addresses that are not in the target’s subnet for this interface. This mode is useful when
not- target hosts reachable via this interface require the source IP address in ARP requests to be part of their
in- logical network configured on the receiving interface. When we generate the request we will check all our
subnet subnets that include the target IP and will preserve the source address if it is from such subnet. If there is
no such subnet we select source address according to the rules for level 2, ‘best-local’.
best- Always use the best local address for this target. In this mode we ignore the source address in the IP packet
local and try to select local address that we prefer for talks with the target host. Such local address is selected
by looking for primary IP addresses on all our subnets on the outgoing interface that include the target
IP address. If no suitable local address is found we select the first local address we have on the outgoing
interface or on all other interfaces, with the hope we will receive reply for our request and even sometimes
no matter the source IP address we announce.
arp-filter
Allows to have multiple network interfaces on the same subnet, and have the ARPs for each interface be answered
based on whether or not the kernel would route a packet from the ARP’d IP out that interface (therefore you must
use source based routing for this to work). In other words it allows control of which cards (usually 1) will respond
to an arp request.
vrouter running config# vrf <vrf> interface loopback <loopback> network-stack ipv4
vrouter running ipv4# arp-filter true|false
arp-ignore
Define different modes for sending replies in response to received ARP requests that resolve local target IP addresses.
vrouter running config# vrf <vrf> interface loopback <loopback> network-stack ipv4
vrouter running ipv4# arp-ignore ARP-IGNORE
ARP-IGNORE Description
values
any Reply for any local target IP address, configured on any interface.
check- Reply only if the target IP address is local address configured on the incoming interface.
interface
check- Reply only if the target IP address is local address configured on the incoming interface and
interface- both with the sender’s IP address are part from same subnet on this interface.
and-subnet
ignore-scope Do not reply for local addresses configured with scope host, only resolutions for global and
link addresses are replied.
ignore-all Do not reply for all local addresses.
log-invalid-addresses
vrouter running config# vrf <vrf> interface loopback <loopback> network-stack ipv4
vrouter running ipv4# log-invalid-addresses true|false
ipv6
IPv6 parameters.
vrouter running config# vrf <vrf> interface loopback <loopback> network-stack ipv6
autoconfiguration
vrouter running config# vrf <vrf> interface loopback <loopback> network-stack ipv6
vrouter running ipv6# autoconfiguration true|false
accept-router-advert
vrouter running config# vrf <vrf> interface loopback <loopback> network-stack ipv6
vrouter running ipv6# accept-router-advert ACCEPT-ROUTER-ADVERT
accept-redirects
Accept redirect when acting as a host. It is always disabled when acting as a router.
vrouter running config# vrf <vrf> interface loopback <loopback> network-stack ipv6
vrouter running ipv6# accept-redirects true|false
accept-source-route
vrouter running config# vrf <vrf> interface loopback <loopback> network-stack ipv6
vrouter running ipv6# accept-source-route true|false
router-solicitations
vrouter running config# vrf <vrf> interface loopback <loopback> network-stack ipv6
vrouter running ipv6# router-solicitations <int16>
use-temporary-addresses
Preference for Privacy Extensions (RFC4941). Not applied to point-to- point and loopback devices (always 0).
vrouter running config# vrf <vrf> interface loopback <loopback> network-stack ipv6
vrouter running ipv6# use-temporary-addresses USE-TEMPORARY-ADDRESSES
USE-TEMPORARY-ADDRESSESDescription
values
never Disable Privacy Extensions, i.e. use the public address, subnet prefix/interface id,
where interface id is always the same.
prefer-public-addresses Enable Privacy Extensions, but prefer public addresses over temporary addresses.
always Enable Privacy Extensions and prefer temporary addresses over public addresses.
ethernet
mac-address
Assigns a MAC address to the Ethernet interface. If not specified, the corresponding operational state leaf is expected
to show the system-assigned MAC address.
MAC- An IEEE 802 unicast MAC address i.e. the second digit is an even number. Moreover the mac
ADDRESS address must not be 00:00:00:00:00:00.
qos
QoS configuration.
ingress
vrouter running config# vrf <vrf> interface loopback <loopback> qos ingress
rate-limit
vrouter running config# vrf <vrf> interface loopback <loopback> qos ingress rate-limit
vrouter running config# vrf <vrf> interface loopback <loopback> qos ingress rate-limit
vrouter running rate-limit# policer <leafref>
vrouter running config# vrf <vrf> interface loopback <loopback> qos ingress rate-limit
vrouter running rate-limit# shared-policer <leafref>
Traffic policer.
Maximum bandwidth of regular traffic, a.k.a. CIR (Committed Information Rate), in bps. 0 allows no regular traffic.
vrouter> show state vrf <vrf> interface loopback <loopback> qos ingress rate-limit␣
˓→policer bandwidth
Maximum burst size of shaped traffic, a.k.a. CBS (Committed Burst Size), in bytes. The default value is set to
bandwidth / 80 to handle a burst of 100 ms at the targeted bandwidth. If not set or set to 0, the default value is
applied.
vrouter> show state vrf <vrf> interface loopback <loopback> qos ingress rate-limit␣
˓→policer burst
Maximum bandwidth of excess traffic, a.k.a. EIR (Excess Information Rate), in bps. 0 allows no excess traffic.
vrouter> show state vrf <vrf> interface loopback <loopback> qos ingress rate-limit␣
˓→policer excess-bandwidth
Maximum burst size of excess traffic, a.k.a. EBS (Excess Burst Size), in bytes. The default value is set to excess-
bandwidth / 80 to handle a burst of 100 ms at the targeted bandwidth. If not set or set to 0, the default value is
applied.
vrouter> show state vrf <vrf> interface loopback <loopback> qos ingress rate-limit␣
˓→policer excess-burst
vrouter> show state vrf <vrf> interface loopback <loopback> qos ingress rate-limit␣
˓→policer shared-policer
Number of packets passed (regular traffic that conforms to (bandwidth, burst) specification.
vrouter> show state vrf <vrf> interface loopback <loopback> qos ingress rate-limit␣
˓→policer stats pass-packets
Number of bytes passed (regular traffic that conforms to (bandwidth, burst) specification.
vrouter> show state vrf <vrf> interface loopback <loopback> qos ingress rate-limit␣
˓→policer stats pass-bytes
Number of excess packets passed (excess traffic that conforms to (excess-bandwidth, excess-burst) specification.
vrouter> show state vrf <vrf> interface loopback <loopback> qos ingress rate-limit␣
˓→policer stats pass-excess-packets
Number of excess bytes passed (excess traffic that conforms to (excess-bandwidth, excess-burst) specification.
vrouter> show state vrf <vrf> interface loopback <loopback> qos ingress rate-limit␣
˓→policer stats pass-excess-bytes
Number of packets dropped (traffic that does not conform to bandwidth or excess-bandwidth).
vrouter> show state vrf <vrf> interface loopback <loopback> qos ingress rate-limit␣
˓→policer stats drop-packets
Number of bytes dropped (traffic that does not conform to bandwidth or excess-bandwidth).
vrouter> show state vrf <vrf> interface loopback <loopback> qos ingress rate-limit␣
˓→policer stats drop-bytes
egress
vrouter running config# vrf <vrf> interface loopback <loopback> qos egress
rate-limit
vrouter running config# vrf <vrf> interface loopback <loopback> qos egress rate-limit
vrouter running config# vrf <vrf> interface loopback <loopback> qos egress rate-limit
vrouter running rate-limit# policer <leafref>
vrouter running config# vrf <vrf> interface loopback <loopback> qos egress rate-limit
vrouter running rate-limit# shared-policer <leafref>
Traffic policer.
Maximum bandwidth of regular traffic, a.k.a. CIR (Committed Information Rate), in bps. 0 allows no regular traffic.
vrouter> show state vrf <vrf> interface loopback <loopback> qos egress rate-limit␣
˓→policer bandwidth
Maximum burst size of shaped traffic, a.k.a. CBS (Committed Burst Size), in bytes. The default value is set to
bandwidth / 80 to handle a burst of 100 ms at the targeted bandwidth. If not set or set to 0, the default value is
applied.
vrouter> show state vrf <vrf> interface loopback <loopback> qos egress rate-limit␣
˓→policer burst
Maximum bandwidth of excess traffic, a.k.a. EIR (Excess Information Rate), in bps. 0 allows no excess traffic.
vrouter> show state vrf <vrf> interface loopback <loopback> qos egress rate-limit␣
˓→policer excess-bandwidth
Maximum burst size of excess traffic, a.k.a. EBS (Excess Burst Size), in bytes. The default value is set to excess-
bandwidth / 80 to handle a burst of 100 ms at the targeted bandwidth. If not set or set to 0, the default value is
applied.
vrouter> show state vrf <vrf> interface loopback <loopback> qos egress rate-limit␣
˓→policer excess-burst
vrouter> show state vrf <vrf> interface loopback <loopback> qos egress rate-limit␣
˓→policer shared-policer
Number of packets passed (regular traffic that conforms to (bandwidth, burst) specification.
vrouter> show state vrf <vrf> interface loopback <loopback> qos egress rate-limit␣
˓→policer stats pass-packets
Number of bytes passed (regular traffic that conforms to (bandwidth, burst) specification.
vrouter> show state vrf <vrf> interface loopback <loopback> qos egress rate-limit␣
˓→policer stats pass-bytes
Number of excess packets passed (excess traffic that conforms to (excess-bandwidth, excess-burst) specification.
vrouter> show state vrf <vrf> interface loopback <loopback> qos egress rate-limit␣
˓→policer stats pass-excess-packets
Number of excess bytes passed (excess traffic that conforms to (excess-bandwidth, excess-burst) specification.
vrouter> show state vrf <vrf> interface loopback <loopback> qos egress rate-limit␣
˓→policer stats pass-excess-bytes
Number of packets dropped (traffic that does not conform to bandwidth or excess-bandwidth).
vrouter> show state vrf <vrf> interface loopback <loopback> qos egress rate-limit␣
˓→policer stats drop-packets
Number of bytes dropped (traffic that does not conform to bandwidth or excess-bandwidth).
vrouter> show state vrf <vrf> interface loopback <loopback> qos egress rate-limit␣
˓→policer stats drop-bytes
The total number of octets received on the interface, including framing characters. Discontinuities in the value of
this counter can occur at re-initialization of the management system, and at other times as indicated by the value of
‘last-clear’.
vrouter> show state vrf <vrf> interface loopback <loopback> counters in-octets
The number of packets, delivered by this sub-layer to a higher (sub-)layer, that were not addressed to a multicast or
broadcast address at this sub-layer. Discontinuities in the value of this counter can occur at re-initialization of the
management system, and at other times as indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface loopback <loopback> counters in-unicast-pkts
The number of inbound packets that were chosen to be discarded even though no errors had been detected to prevent
their being deliverable to a higher-layer protocol. One possible reason for discarding such a packet could be to free
up buffer space. Discontinuities in the value of this counter can occur at re-initialization of the management system,
and at other times as indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface loopback <loopback> counters in-discards
For packet-oriented interfaces, the number of inbound packets that contained errors preventing them from being
deliverable to a higher- layer protocol. For character- oriented or fixed-length interfaces, the number of inbound
transmission units that contained errors preventing them from being deliverable to a higher-layer protocol. Discon-
tinuities in the value of this counter can occur at re- initialization of the management system, and at other times as
indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface loopback <loopback> counters in-errors
The total number of octets transmitted out of the interface, including framing characters. Discontinuities in the
value of this counter can occur at re-initialization of the management system, and at other times as indicated by the
value of ‘last-clear’.
vrouter> show state vrf <vrf> interface loopback <loopback> counters out-octets
The total number of packets that higher-level protocols requested be transmitted, and that were not addressed to a
multicast or broadcast address at this sub-layer, including those that were discarded or not sent. Discontinuities in
the value of this counter can occur at re- initialization of the management system, and at other times as indicated by
the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface loopback <loopback> counters out-unicast-pkts
The number of outbound packets that were chosen to be discarded even though no errors had been detected to
prevent their being transmitted. One possible reason for discarding such a packet could be to free up buffer space.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other
times as indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface loopback <loopback> counters out-discards
For packet-oriented interfaces, the number of outbound packets that could not be transmitted because of errors. For
character-oriented or fixed-length interfaces, the number of outbound transmission units that could not be transmitted
because of errors. Discontinuities in the value of this counter can occur at re-initialization of the management system,
and at other times as indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface loopback <loopback> counters out-errors
physical
port (mandatory)
mtu
promiscuous
description
enabled
Default value
true
rx-cp-protection
tx-cp-protection
System assigned number for each interface. Corresponds to ifIndex object in SNMP Interface MIB.
The desired state of the interface. In RFC 7223 this leaf has the same read semantics as ifAdminStatus. Here, it
reflects the administrative state as set by enabling or disabling the interface.
The current operational state of the interface. This leaf has the same semantics as ifOperStatus.
This timestamp indicates the time of the last state change of the interface (e.g., up-to-down transition). This corre-
sponds to the ifLastChange object in the standard interface MIB. The value is the timestamp in nanoseconds relative
to the Unix Epoch (Jan 1, 1970 00:00:00 UTC).
ipv4
enabled
Controls whether IPv4 is enabled or disabled on this interface. When IPv4 is enabled, this interface is connected to
an IPv4 stack, and the interface can send and receive IPv4 packets.
Default value
true
address
peer
The IPv4 address of the remote endpoint for point to point interfaces.
peer PEER
The origin of this address, e.g., statically configured, assigned by DHCP, etc..
vrouter> show state vrf <vrf> interface physical <physical> ipv4 address <address>␣
˓→origin
neighbor
A list of mappings from IPv4 addresses to link-layer addresses. Entries in this list are used as static entries in the
ARP Cache.
link-layer-address (mandatory)
link-layer-address LINK-LAYER-ADDRESS
vrouter> show state vrf <vrf> interface physical <physical> ipv4 neighbor <neighbor>␣
˓→state
dhcp
vrouter running config# vrf <vrf> interface physical <physical> ipv4 dhcp
enabled
vrouter running config# vrf <vrf> interface physical <physical> ipv4 dhcp
vrouter running dhcp# enabled true|false
Default value
true
timeout
Time before deciding that it’s not going to be able to contact a server.
vrouter running config# vrf <vrf> interface physical <physical> ipv4 dhcp
vrouter running dhcp# timeout <uint32>
Default value
60
retry
vrouter running config# vrf <vrf> interface physical <physical> ipv4 dhcp
vrouter running dhcp# retry <uint32>
Default value
300
select-timeout
Time at which the client stops waiting for other offers from servers.
vrouter running config# vrf <vrf> interface physical <physical> ipv4 dhcp
vrouter running dhcp# select-timeout <uint32>
Default value
0
reboot
Time after trying to reacquire its old address before trying to discover a new address.
vrouter running config# vrf <vrf> interface physical <physical> ipv4 dhcp
vrouter running dhcp# reboot <uint32>
Default value
10
initial-interval
Time between the first attempt to reach a server and the second attempt to reach a server.
vrouter running config# vrf <vrf> interface physical <physical> ipv4 dhcp
vrouter running dhcp# initial-interval <uint32>
Default value
10
dhcp-lease-time
vrouter running config# vrf <vrf> interface physical <physical> ipv4 dhcp
vrouter running dhcp# dhcp-lease-time <uint32>
Default value
7200
dhcp-client-identifier-ascii
vrouter running config# vrf <vrf> interface physical <physical> ipv4 dhcp
vrouter running dhcp# dhcp-client-identifier-ascii <string>
dhcp-client-identifier-hexa
vrouter running config# vrf <vrf> interface physical <physical> ipv4 dhcp
vrouter running dhcp# dhcp-client-identifier-hexa <string>
host-name
vrouter running config# vrf <vrf> interface physical <physical> ipv4 dhcp
vrouter running dhcp# host-name <string>
request
DHCP requests.
vrouter running config# vrf <vrf> interface physical <physical> ipv4 dhcp
vrouter running dhcp# request REQUEST
Default value
subnet-mask
broadcast-address
time-offset
routers
domain-name
domain-search
domain-name-servers
host-name
nis-domain
nis-servers
ntp-servers
interface-mtu
Current lease.
vrouter> show state vrf <vrf> interface physical <physical> ipv4 dhcp current-lease␣
˓→fixed-address
Time at which the client should begin trying to contact its server to renew its lease.
vrouter> show state vrf <vrf> interface physical <physical> ipv4 dhcp current-lease␣
˓→renew
Time at which the client should begin to try to contact any dhcp server to renew its lease.
vrouter> show state vrf <vrf> interface physical <physical> ipv4 dhcp current-lease␣
˓→rebind
Time at which the client must stop using a lease if it has not been able to renew it.
vrouter> show state vrf <vrf> interface physical <physical> ipv4 dhcp current-lease␣
˓→expire
ipv6
enabled
Controls whether IPv6 is enabled or disabled on this interface. When IPv6 is enabled, this interface is connected to
an IPv6 stack, and the interface can send and receive IPv6 packets.
Default value
true
address
peer
The IPv6 address of the remote endpoint for point to point interfaces.
peer PEER
vrouter> show state vrf <vrf> interface physical <physical> ipv6 address <address>␣
˓→origin
The status of an address. Most of the states correspond to states from the IPv6 Stateless Address Autoconfiguration
protocol.
vrouter> show state vrf <vrf> interface physical <physical> ipv6 address <address>␣
˓→status
neighbor
link-layer-address (mandatory)
link-layer-address LINK-LAYER-ADDRESS
vrouter> show state vrf <vrf> interface physical <physical> ipv6 neighbor <neighbor>␣
˓→router
vrouter> show state vrf <vrf> interface physical <physical> ipv6 neighbor <neighbor>␣
˓→state
network-stack
ipv4
IPv4 parameters.
vrouter running config# vrf <vrf> interface physical <physical> network-stack ipv4
send-redirects
vrouter running config# vrf <vrf> interface physical <physical> network-stack ipv4
vrouter running ipv4# send-redirects true|false
accept-redirects
Accept redirect when acting as a host. It is always disabled when acting as a router. Must be activated at vrf or
system level too to be activated.
vrouter running config# vrf <vrf> interface physical <physical> network-stack ipv4
vrouter running ipv4# accept-redirects true|false
accept-source-route
Accept packets with source route option. Must be activated at vrf or system level too to be activated.
vrouter running config# vrf <vrf> interface physical <physical> network-stack ipv4
vrouter running ipv4# accept-source-route true|false
arp-announce
Define different restriction levels for announcing the local source IP address from IP packets in ARP requests sent
on interface. Increasing the restriction level gives more chance for receiving answer from the resolved target while
decreasing the level announces more valid sender’s information.
vrouter running config# vrf <vrf> interface physical <physical> network-stack ipv4
vrouter running ipv4# arp-announce ARP-ANNOUNCE
Description
ARP-ANNOUNCE
val-
ues
any Use any local address, configured on any interface.
avoid- Try to avoid local addresses that are not in the target’s subnet for this interface. This mode is useful when
not- target hosts reachable via this interface require the source IP address in ARP requests to be part of their
in- logical network configured on the receiving interface. When we generate the request we will check all our
subnet subnets that include the target IP and will preserve the source address if it is from such subnet. If there is
no such subnet we select source address according to the rules for level 2, ‘best-local’.
best- Always use the best local address for this target. In this mode we ignore the source address in the IP packet
local and try to select local address that we prefer for talks with the target host. Such local address is selected
by looking for primary IP addresses on all our subnets on the outgoing interface that include the target
IP address. If no suitable local address is found we select the first local address we have on the outgoing
interface or on all other interfaces, with the hope we will receive reply for our request and even sometimes
no matter the source IP address we announce.
arp-filter
Allows to have multiple network interfaces on the same subnet, and have the ARPs for each interface be answered
based on whether or not the kernel would route a packet from the ARP’d IP out that interface (therefore you must
use source based routing for this to work). In other words it allows control of which cards (usually 1) will respond
to an arp request.
vrouter running config# vrf <vrf> interface physical <physical> network-stack ipv4
vrouter running ipv4# arp-filter true|false
arp-ignore
Define different modes for sending replies in response to received ARP requests that resolve local target IP addresses.
vrouter running config# vrf <vrf> interface physical <physical> network-stack ipv4
vrouter running ipv4# arp-ignore ARP-IGNORE
ARP-IGNORE Description
values
any Reply for any local target IP address, configured on any interface.
check- Reply only if the target IP address is local address configured on the incoming interface.
interface
check- Reply only if the target IP address is local address configured on the incoming interface and
interface- both with the sender’s IP address are part from same subnet on this interface.
and-subnet
ignore-scope Do not reply for local addresses configured with scope host, only resolutions for global and
link addresses are replied.
ignore-all Do not reply for all local addresses.
log-invalid-addresses
vrouter running config# vrf <vrf> interface physical <physical> network-stack ipv4
vrouter running ipv4# log-invalid-addresses true|false
ipv6
IPv6 parameters.
vrouter running config# vrf <vrf> interface physical <physical> network-stack ipv6
autoconfiguration
vrouter running config# vrf <vrf> interface physical <physical> network-stack ipv6
vrouter running ipv6# autoconfiguration true|false
accept-router-advert
vrouter running config# vrf <vrf> interface physical <physical> network-stack ipv6
vrouter running ipv6# accept-router-advert ACCEPT-ROUTER-ADVERT
accept-redirects
Accept redirect when acting as a host. It is always disabled when acting as a router.
vrouter running config# vrf <vrf> interface physical <physical> network-stack ipv6
vrouter running ipv6# accept-redirects true|false
accept-source-route
vrouter running config# vrf <vrf> interface physical <physical> network-stack ipv6
vrouter running ipv6# accept-source-route true|false
router-solicitations
vrouter running config# vrf <vrf> interface physical <physical> network-stack ipv6
vrouter running ipv6# router-solicitations <int16>
use-temporary-addresses
Preference for Privacy Extensions (RFC4941). Not applied to point-to- point and loopback devices (always 0).
vrouter running config# vrf <vrf> interface physical <physical> network-stack ipv6
vrouter running ipv6# use-temporary-addresses USE-TEMPORARY-ADDRESSES
USE-TEMPORARY-ADDRESSESDescription
values
never Disable Privacy Extensions, i.e. use the public address, subnet prefix/interface id,
where interface id is always the same.
prefer-public-addresses Enable Privacy Extensions, but prefer public addresses over temporary addresses.
always Enable Privacy Extensions and prefer temporary addresses over public addresses.
ethernet
mac-address
Assigns a MAC address to the Ethernet interface. If not specified, the corresponding operational state leaf is expected
to show the system-assigned MAC address.
MAC- An IEEE 802 unicast MAC address i.e. the second digit is an even number. Moreover the mac
ADDRESS address must not be 00:00:00:00:00:00.
auto-negotiate
Set to true to request the interface to auto-negotiate transmission parameters with its peer interface. When set to
false, the transmission parameters must be specified manually.
duplex-mode
Force the duplex mode. If unspecified and auto-negotiate is true, the interface should negotiate the duplex mode
directly (typically full- duplex). When auto-negotiate is false, duplex-mode must be specified.
port-speed
Force the port speed. If unspecified and auto-negotiate is true, the interface should negotiate the port speed directly.
When auto- negotiate is false, port-speed must be specified.
PORT-SPEED Description
values
10mb 10 Mbps Ethernet.
100mb 100 Mbps Ethernet.
1gb 1 Gbps Ethernet.
10gb 10 Gbps Ethernet.
25gb 25 Gbps Ethernet.
40gb 40 Gbps Ethernet.
50gb 50 Gbps Ethernet.
100gb 100 Gbps Ethernet.
unknown Interface speed is unknown. Systems may report unknown when an interface is down or un-
popuplated (e.g., pluggable not present).
flow-control-rx
Enable or disable ingress flow control for this interface. Ethernet flow control is a mechanism by which a receiver
may send PAUSE frames to a sender to stop transmission for a specified time. This setting should override auto-
negotiated flow control settings. If left unspecified, and auto-negotiate is true, flow control mode is negotiated with
the peer interface.
flow-control-tx
Enable or disable egress flow control for this interface. Ethernet flow control is a mechanism by which a receiver
may send PAUSE frames to a sender to stop transmission for a specified time. This setting should override auto-
negotiated flow control settings. If left unspecified, and auto-negotiate is true, flow control mode is negotiated with
the peer interface.
qos
QoS configuration.
ingress
vrouter running config# vrf <vrf> interface physical <physical> qos ingress
rate-limit
vrouter running config# vrf <vrf> interface physical <physical> qos ingress rate-limit
vrouter running config# vrf <vrf> interface physical <physical> qos ingress rate-limit
vrouter running rate-limit# policer <leafref>
vrouter running config# vrf <vrf> interface physical <physical> qos ingress rate-limit
vrouter running rate-limit# shared-policer <leafref>
Traffic policer.
Maximum bandwidth of regular traffic, a.k.a. CIR (Committed Information Rate), in bps. 0 allows no regular traffic.
vrouter> show state vrf <vrf> interface physical <physical> qos ingress rate-limit␣
˓→policer bandwidth
Maximum burst size of shaped traffic, a.k.a. CBS (Committed Burst Size), in bytes. The default value is set to
bandwidth / 80 to handle a burst of 100 ms at the targeted bandwidth. If not set or set to 0, the default value is
applied.
vrouter> show state vrf <vrf> interface physical <physical> qos ingress rate-limit␣
˓→policer burst
Maximum bandwidth of excess traffic, a.k.a. EIR (Excess Information Rate), in bps. 0 allows no excess traffic.
vrouter> show state vrf <vrf> interface physical <physical> qos ingress rate-limit␣
˓→policer excess-bandwidth
Maximum burst size of excess traffic, a.k.a. EBS (Excess Burst Size), in bytes. The default value is set to excess-
bandwidth / 80 to handle a burst of 100 ms at the targeted bandwidth. If not set or set to 0, the default value is
applied.
vrouter> show state vrf <vrf> interface physical <physical> qos ingress rate-limit␣
˓→policer excess-burst
vrouter> show state vrf <vrf> interface physical <physical> qos ingress rate-limit␣
˓→policer shared-policer
Number of packets passed (regular traffic that conforms to (bandwidth, burst) specification.
vrouter> show state vrf <vrf> interface physical <physical> qos ingress rate-limit␣
˓→policer stats pass-packets
Number of bytes passed (regular traffic that conforms to (bandwidth, burst) specification.
vrouter> show state vrf <vrf> interface physical <physical> qos ingress rate-limit␣
˓→policer stats pass-bytes
Number of excess packets passed (excess traffic that conforms to (excess-bandwidth, excess-burst) specification.
vrouter> show state vrf <vrf> interface physical <physical> qos ingress rate-limit␣
˓→policer stats pass-excess-packets
Number of excess bytes passed (excess traffic that conforms to (excess-bandwidth, excess-burst) specification.
vrouter> show state vrf <vrf> interface physical <physical> qos ingress rate-limit␣
˓→policer stats pass-excess-bytes
Number of packets dropped (traffic that does not conform to bandwidth or excess-bandwidth).
vrouter> show state vrf <vrf> interface physical <physical> qos ingress rate-limit␣
˓→policer stats drop-packets
Number of bytes dropped (traffic that does not conform to bandwidth or excess-bandwidth).
vrouter> show state vrf <vrf> interface physical <physical> qos ingress rate-limit␣
˓→policer stats drop-bytes
egress
vrouter running config# vrf <vrf> interface physical <physical> qos egress
vrouter running config# vrf <vrf> interface physical <physical> qos egress
vrouter running egress# scheduler <leafref>
rate-limit
vrouter running config# vrf <vrf> interface physical <physical> qos egress rate-limit
vrouter running config# vrf <vrf> interface physical <physical> qos egress rate-limit
vrouter running rate-limit# policer <leafref>
vrouter running config# vrf <vrf> interface physical <physical> qos egress rate-limit
vrouter running rate-limit# shared-policer <leafref>
vrouter running config# vrf <vrf> interface physical <physical> qos egress rate-limit
vrouter running rate-limit# shaper <leafref>
Traffic policer.
Maximum bandwidth of regular traffic, a.k.a. CIR (Committed Information Rate), in bps. 0 allows no regular traffic.
vrouter> show state vrf <vrf> interface physical <physical> qos egress rate-limit␣
˓→policer bandwidth
Maximum burst size of shaped traffic, a.k.a. CBS (Committed Burst Size), in bytes. The default value is set to
bandwidth / 80 to handle a burst of 100 ms at the targeted bandwidth. If not set or set to 0, the default value is
applied.
vrouter> show state vrf <vrf> interface physical <physical> qos egress rate-limit␣
˓→policer burst
Maximum bandwidth of excess traffic, a.k.a. EIR (Excess Information Rate), in bps. 0 allows no excess traffic.
vrouter> show state vrf <vrf> interface physical <physical> qos egress rate-limit␣
˓→policer excess-bandwidth
Maximum burst size of excess traffic, a.k.a. EBS (Excess Burst Size), in bytes. The default value is set to excess-
bandwidth / 80 to handle a burst of 100 ms at the targeted bandwidth. If not set or set to 0, the default value is
applied.
vrouter> show state vrf <vrf> interface physical <physical> qos egress rate-limit␣
˓→policer excess-burst
vrouter> show state vrf <vrf> interface physical <physical> qos egress rate-limit␣
˓→policer shared-policer
Number of packets passed (regular traffic that conforms to (bandwidth, burst) specification.
vrouter> show state vrf <vrf> interface physical <physical> qos egress rate-limit␣
˓→policer stats pass-packets
Number of bytes passed (regular traffic that conforms to (bandwidth, burst) specification.
vrouter> show state vrf <vrf> interface physical <physical> qos egress rate-limit␣
˓→policer stats pass-bytes
Number of excess packets passed (excess traffic that conforms to (excess-bandwidth, excess-burst) specification.
vrouter> show state vrf <vrf> interface physical <physical> qos egress rate-limit␣
˓→policer stats pass-excess-packets
Number of excess bytes passed (excess traffic that conforms to (excess-bandwidth, excess-burst) specification.
vrouter> show state vrf <vrf> interface physical <physical> qos egress rate-limit␣
˓→policer stats pass-excess-bytes
Number of packets dropped (traffic that does not conform to bandwidth or excess-bandwidth).
vrouter> show state vrf <vrf> interface physical <physical> qos egress rate-limit␣
˓→policer stats drop-packets
Number of bytes dropped (traffic that does not conform to bandwidth or excess-bandwidth).
vrouter> show state vrf <vrf> interface physical <physical> qos egress rate-limit␣
˓→policer stats drop-bytes
Traffic shaper.
vrouter> show state vrf <vrf> interface physical <physical> qos egress rate-limit␣
˓→shaper bandwidth
Maximum burst size of shaped traffic. The default value is set to bandwidth / 80 to handle a burst of 100 ms at the
targeted bandwidth. If not set or set to 0, the default value is applied.
vrouter> show state vrf <vrf> interface physical <physical> qos egress rate-limit␣
˓→shaper burst
vrouter> show state vrf <vrf> interface physical <physical> qos egress rate-limit␣
˓→shaper layer1-overhead
Number of packets that can be saved in the delay queue. If a scheduler is also configured on the interface, this value
is not used, the queues of the scheduler are used as delay queues. The value is rounded up to the nearest power of 2.
vrouter> show state vrf <vrf> interface physical <physical> qos egress rate-limit␣
˓→shaper queue-size
vrouter> show state vrf <vrf> interface physical <physical> qos egress rate-limit␣
˓→shaper stats pass-packets
vrouter> show state vrf <vrf> interface physical <physical> qos egress rate-limit␣
˓→shaper stats drop-packets
Scheduler state.
vrouter> show state vrf <vrf> interface physical <physical> qos egress scheduler core
pq (state only)
vrouter> show state vrf <vrf> interface physical <physical> qos egress scheduler pq nb-
˓→queue
Size of the queue in packets. The value is rounded up to the nearest power of 2.
vrouter> show state vrf <vrf> interface physical <physical> qos egress scheduler pq␣
˓→queue <uint32> size
Maximum bandwidth of regular traffic, a.k.a. CIR (Committed Information Rate), in bps. 0 allows no regular traffic.
vrouter> show state vrf <vrf> interface physical <physical> qos egress scheduler pq␣
˓→queue <uint32> policer bandwidth
Maximum burst size of shaped traffic, a.k.a. CBS (Committed Burst Size), in bytes. The default value is set to
bandwidth / 80 to handle a burst of 100 ms at the targeted bandwidth. If not set or set to 0, the default value is
applied.
vrouter> show state vrf <vrf> interface physical <physical> qos egress scheduler pq␣
˓→queue <uint32> policer burst
Maximum bandwidth of excess traffic, a.k.a. EIR (Excess Information Rate), in bps. 0 allows no excess traffic.
vrouter> show state vrf <vrf> interface physical <physical> qos egress scheduler pq␣
˓→queue <uint32> policer excess-bandwidth
Maximum burst size of excess traffic, a.k.a. EBS (Excess Burst Size), in bytes. The default value is set to excess-
bandwidth / 80 to handle a burst of 100 ms at the targeted bandwidth. If not set or set to 0, the default value is
applied.
vrouter> show state vrf <vrf> interface physical <physical> qos egress scheduler pq␣
˓→queue <uint32> policer excess-burst
Number of packets passed (regular traffic that conforms to (bandwidth, burst) specification.
vrouter> show state vrf <vrf> interface physical <physical> qos egress scheduler pq␣
˓→queue <uint32> policer stats pass-packets
Number of bytes passed (regular traffic that conforms to (bandwidth, burst) specification.
vrouter> show state vrf <vrf> interface physical <physical> qos egress scheduler pq␣
˓→queue <uint32> policer stats pass-bytes
Number of excess packets passed (excess traffic that conforms to (excess-bandwidth, excess-burst) specification.
vrouter> show state vrf <vrf> interface physical <physical> qos egress scheduler pq␣
˓→queue <uint32> policer stats pass-excess-packets
Number of excess bytes passed (excess traffic that conforms to (excess-bandwidth, excess-burst) specification.
vrouter> show state vrf <vrf> interface physical <physical> qos egress scheduler pq␣
˓→queue <uint32> policer stats pass-excess-bytes
Number of packets dropped (traffic that does not conform to bandwidth or excess-bandwidth).
vrouter> show state vrf <vrf> interface physical <physical> qos egress scheduler pq␣
˓→queue <uint32> policer stats drop-packets
Number of bytes dropped (traffic that does not conform to bandwidth or excess-bandwidth).
vrouter> show state vrf <vrf> interface physical <physical> qos egress scheduler pq␣
˓→queue <uint32> policer stats drop-bytes
vrouter> show state vrf <vrf> interface physical <physical> qos egress scheduler pq␣
˓→queue <uint32> shaper bandwidth
Maximum burst size of shaped traffic. The default value is set to bandwidth / 80 to handle a burst of 100 ms at the
targeted bandwidth. If not set or set to 0, the default value is applied.
vrouter> show state vrf <vrf> interface physical <physical> qos egress scheduler pq␣
˓→queue <uint32> shaper burst
vrouter> show state vrf <vrf> interface physical <physical> qos egress scheduler pq␣
˓→queue <uint32> shaper layer1-overhead
Number of packets that can be saved in the delay queue. If a scheduler is also configured on the interface, this value
is not used, the queues of the scheduler are used as delay queues. The value is rounded up to the nearest power of 2.
vrouter> show state vrf <vrf> interface physical <physical> qos egress scheduler pq␣
˓→queue <uint32> shaper queue-size
vrouter> show state vrf <vrf> interface physical <physical> qos egress scheduler pq␣
˓→queue <uint32> shaper stats pass-packets
vrouter> show state vrf <vrf> interface physical <physical> qos egress scheduler pq␣
˓→queue <uint32> shaper stats drop-packets
Class statistics.
vrouter> show state vrf <vrf> interface physical <physical> qos egress scheduler pq␣
˓→queue <uint32> class <string> stats match-packets
Queue statistics.
vrouter> show state vrf <vrf> interface physical <physical> qos egress scheduler pq␣
˓→queue <uint32> stats enqueue-packets
vrouter> show state vrf <vrf> interface physical <physical> qos egress scheduler pq␣
˓→queue <uint32> stats xmit-packets
vrouter> show state vrf <vrf> interface physical <physical> qos egress scheduler pq␣
˓→queue <uint32> stats drop-queue-full
vrouter> show state vrf <vrf> interface physical <physical> qos egress scheduler pb-
˓→dwrr nb-queue
Size of the queue in packets. The value is rounded up to the nearest power of 2.
vrouter> show state vrf <vrf> interface physical <physical> qos egress scheduler pb-
˓→dwrr queue <uint32> size
vrouter> show state vrf <vrf> interface physical <physical> qos egress scheduler pb-
˓→dwrr queue <uint32> quantum
vrouter> show state vrf <vrf> interface physical <physical> qos egress scheduler pb-
˓→dwrr queue <uint32> priority
Maximum bandwidth of regular traffic, a.k.a. CIR (Committed Information Rate), in bps. 0 allows no regular traffic.
vrouter> show state vrf <vrf> interface physical <physical> qos egress scheduler pb-
˓→dwrr queue <uint32> policer bandwidth
Maximum burst size of shaped traffic, a.k.a. CBS (Committed Burst Size), in bytes. The default value is set to
bandwidth / 80 to handle a burst of 100 ms at the targeted bandwidth. If not set or set to 0, the default value is
applied.
vrouter> show state vrf <vrf> interface physical <physical> qos egress scheduler pb-
˓→dwrr queue <uint32> policer burst
Maximum bandwidth of excess traffic, a.k.a. EIR (Excess Information Rate), in bps. 0 allows no excess traffic.
vrouter> show state vrf <vrf> interface physical <physical> qos egress scheduler pb-
˓→dwrr queue <uint32> policer excess-bandwidth
Maximum burst size of excess traffic, a.k.a. EBS (Excess Burst Size), in bytes. The default value is set to excess-
bandwidth / 80 to handle a burst of 100 ms at the targeted bandwidth. If not set or set to 0, the default value is
applied.
vrouter> show state vrf <vrf> interface physical <physical> qos egress scheduler pb-
˓→dwrr queue <uint32> policer excess-burst
Number of packets passed (regular traffic that conforms to (bandwidth, burst) specification.
vrouter> show state vrf <vrf> interface physical <physical> qos egress scheduler pb-
˓→dwrr queue <uint32> policer stats pass-packets
Number of bytes passed (regular traffic that conforms to (bandwidth, burst) specification.
vrouter> show state vrf <vrf> interface physical <physical> qos egress scheduler pb-
˓→dwrr queue <uint32> policer stats pass-bytes
Number of excess packets passed (excess traffic that conforms to (excess-bandwidth, excess-burst) specification.
vrouter> show state vrf <vrf> interface physical <physical> qos egress scheduler pb-
˓→dwrr queue <uint32> policer stats pass-excess-packets
Number of excess bytes passed (excess traffic that conforms to (excess-bandwidth, excess-burst) specification.
vrouter> show state vrf <vrf> interface physical <physical> qos egress scheduler pb-
˓→dwrr queue <uint32> policer stats pass-excess-bytes
Number of packets dropped (traffic that does not conform to bandwidth or excess-bandwidth).
vrouter> show state vrf <vrf> interface physical <physical> qos egress scheduler pb-
˓→dwrr queue <uint32> policer stats drop-packets
Number of bytes dropped (traffic that does not conform to bandwidth or excess-bandwidth).
vrouter> show state vrf <vrf> interface physical <physical> qos egress scheduler pb-
˓→dwrr queue <uint32> policer stats drop-bytes
vrouter> show state vrf <vrf> interface physical <physical> qos egress scheduler pb-
˓→dwrr queue <uint32> shaper bandwidth
Maximum burst size of shaped traffic. The default value is set to bandwidth / 80 to handle a burst of 100 ms at the
targeted bandwidth. If not set or set to 0, the default value is applied.
vrouter> show state vrf <vrf> interface physical <physical> qos egress scheduler pb-
˓→dwrr queue <uint32> shaper burst
vrouter> show state vrf <vrf> interface physical <physical> qos egress scheduler pb-
˓→dwrr queue <uint32> shaper layer1-overhead
Number of packets that can be saved in the delay queue. If a scheduler is also configured on the interface, this value
is not used, the queues of the scheduler are used as delay queues. The value is rounded up to the nearest power of 2.
vrouter> show state vrf <vrf> interface physical <physical> qos egress scheduler pb-
˓→dwrr queue <uint32> shaper queue-size
vrouter> show state vrf <vrf> interface physical <physical> qos egress scheduler pb-
˓→dwrr queue <uint32> shaper stats pass-packets
vrouter> show state vrf <vrf> interface physical <physical> qos egress scheduler pb-
˓→dwrr queue <uint32> shaper stats drop-packets
Class statistics.
vrouter> show state vrf <vrf> interface physical <physical> qos egress scheduler pb-
˓→dwrr queue <uint32> class <string> stats match-packets
Queue statistics.
vrouter> show state vrf <vrf> interface physical <physical> qos egress scheduler pb-
˓→dwrr queue <uint32> stats enqueue-packets
vrouter> show state vrf <vrf> interface physical <physical> qos egress scheduler pb-
˓→dwrr queue <uint32> stats xmit-packets
vrouter> show state vrf <vrf> interface physical <physical> qos egress scheduler pb-
˓→dwrr queue <uint32> stats drop-queue-full
The total number of octets received on the interface, including framing characters. Discontinuities in the value of
this counter can occur at re-initialization of the management system, and at other times as indicated by the value of
‘last-clear’.
vrouter> show state vrf <vrf> interface physical <physical> counters in-octets
The number of packets, delivered by this sub-layer to a higher (sub-)layer, that were not addressed to a multicast or
broadcast address at this sub-layer. Discontinuities in the value of this counter can occur at re-initialization of the
management system, and at other times as indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface physical <physical> counters in-unicast-pkts
The number of inbound packets that were chosen to be discarded even though no errors had been detected to prevent
their being deliverable to a higher-layer protocol. One possible reason for discarding such a packet could be to free
up buffer space. Discontinuities in the value of this counter can occur at re-initialization of the management system,
and at other times as indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface physical <physical> counters in-discards
For packet-oriented interfaces, the number of inbound packets that contained errors preventing them from being
deliverable to a higher- layer protocol. For character- oriented or fixed-length interfaces, the number of inbound
transmission units that contained errors preventing them from being deliverable to a higher-layer protocol. Discon-
tinuities in the value of this counter can occur at re- initialization of the management system, and at other times as
indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface physical <physical> counters in-errors
The total number of octets transmitted out of the interface, including framing characters. Discontinuities in the
value of this counter can occur at re-initialization of the management system, and at other times as indicated by the
value of ‘last-clear’.
vrouter> show state vrf <vrf> interface physical <physical> counters out-octets
The total number of packets that higher-level protocols requested be transmitted, and that were not addressed to a
multicast or broadcast address at this sub-layer, including those that were discarded or not sent. Discontinuities in
the value of this counter can occur at re- initialization of the management system, and at other times as indicated by
the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface physical <physical> counters out-unicast-pkts
The number of outbound packets that were chosen to be discarded even though no errors had been detected to
prevent their being transmitted. One possible reason for discarding such a packet could be to free up buffer space.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other
times as indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface physical <physical> counters out-discards
For packet-oriented interfaces, the number of outbound packets that could not be transmitted because of errors. For
character-oriented or fixed-length interfaces, the number of outbound transmission units that could not be transmitted
because of errors. Discontinuities in the value of this counter can occur at re-initialization of the management system,
and at other times as indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface physical <physical> counters out-errors
svti
mtu
promiscuous
description
enabled
Default value
true
svti-id (mandatory)
SVTI ID for association with IPsec policies/SA. Must be unique per link-vrf.
link-vrf
System assigned number for each interface. Corresponds to ifIndex object in SNMP Interface MIB.
The desired state of the interface. In RFC 7223 this leaf has the same read semantics as ifAdminStatus. Here, it
reflects the administrative state as set by enabling or disabling the interface.
The current operational state of the interface. This leaf has the same semantics as ifOperStatus.
This timestamp indicates the time of the last state change of the interface (e.g., up-to-down transition). This corre-
sponds to the ifLastChange object in the standard interface MIB. The value is the timestamp in nanoseconds relative
to the Unix Epoch (Jan 1, 1970 00:00:00 UTC).
Link interface.
ethernet
mac-address
Assigns a MAC address to the Ethernet interface. If not specified, the corresponding operational state leaf is expected
to show the system-assigned MAC address.
MAC- An IEEE 802 unicast MAC address i.e. the second digit is an even number. Moreover the mac
ADDRESS address must not be 00:00:00:00:00:00.
ipv4
enabled
Controls whether IPv4 is enabled or disabled on this interface. When IPv4 is enabled, this interface is connected to
an IPv4 stack, and the interface can send and receive IPv4 packets.
Default value
true
address
peer
The IPv4 address of the remote endpoint for point to point interfaces.
peer PEER
The origin of this address, e.g., statically configured, assigned by DHCP, etc..
vrouter> show state vrf <vrf> interface svti <svti> ipv4 address <address> origin
neighbor
A list of mappings from IPv4 addresses to link-layer addresses. Entries in this list are used as static entries in the
ARP Cache.
link-layer-address (mandatory)
link-layer-address LINK-LAYER-ADDRESS
vrouter> show state vrf <vrf> interface svti <svti> ipv4 neighbor <neighbor> state
dhcp
vrouter running config# vrf <vrf> interface svti <svti> ipv4 dhcp
enabled
vrouter running config# vrf <vrf> interface svti <svti> ipv4 dhcp
vrouter running dhcp# enabled true|false
Default value
true
timeout
Time before deciding that it’s not going to be able to contact a server.
vrouter running config# vrf <vrf> interface svti <svti> ipv4 dhcp
vrouter running dhcp# timeout <uint32>
Default value
60
retry
vrouter running config# vrf <vrf> interface svti <svti> ipv4 dhcp
vrouter running dhcp# retry <uint32>
Default value
300
select-timeout
Time at which the client stops waiting for other offers from servers.
vrouter running config# vrf <vrf> interface svti <svti> ipv4 dhcp
vrouter running dhcp# select-timeout <uint32>
Default value
0
reboot
Time after trying to reacquire its old address before trying to discover a new address.
vrouter running config# vrf <vrf> interface svti <svti> ipv4 dhcp
vrouter running dhcp# reboot <uint32>
Default value
10
initial-interval
Time between the first attempt to reach a server and the second attempt to reach a server.
vrouter running config# vrf <vrf> interface svti <svti> ipv4 dhcp
vrouter running dhcp# initial-interval <uint32>
Default value
10
dhcp-lease-time
vrouter running config# vrf <vrf> interface svti <svti> ipv4 dhcp
vrouter running dhcp# dhcp-lease-time <uint32>
Default value
7200
dhcp-client-identifier-ascii
vrouter running config# vrf <vrf> interface svti <svti> ipv4 dhcp
vrouter running dhcp# dhcp-client-identifier-ascii <string>
dhcp-client-identifier-hexa
vrouter running config# vrf <vrf> interface svti <svti> ipv4 dhcp
vrouter running dhcp# dhcp-client-identifier-hexa <string>
host-name
vrouter running config# vrf <vrf> interface svti <svti> ipv4 dhcp
vrouter running dhcp# host-name <string>
request
DHCP requests.
vrouter running config# vrf <vrf> interface svti <svti> ipv4 dhcp
vrouter running dhcp# request REQUEST
Default value
subnet-mask
broadcast-address
time-offset
routers
domain-name
domain-search
domain-name-servers
host-name
nis-domain
nis-servers
ntp-servers
interface-mtu
Current lease.
vrouter> show state vrf <vrf> interface svti <svti> ipv4 dhcp current-lease fixed-
˓→address
Time at which the client should begin trying to contact its server to renew its lease.
vrouter> show state vrf <vrf> interface svti <svti> ipv4 dhcp current-lease renew
Time at which the client should begin to try to contact any dhcp server to renew its lease.
vrouter> show state vrf <vrf> interface svti <svti> ipv4 dhcp current-lease rebind
Time at which the client must stop using a lease if it has not been able to renew it.
vrouter> show state vrf <vrf> interface svti <svti> ipv4 dhcp current-lease expire
ipv6
enabled
Controls whether IPv6 is enabled or disabled on this interface. When IPv6 is enabled, this interface is connected to
an IPv6 stack, and the interface can send and receive IPv6 packets.
Default value
true
address
peer
The IPv6 address of the remote endpoint for point to point interfaces.
peer PEER
vrouter> show state vrf <vrf> interface svti <svti> ipv6 address <address> origin
The status of an address. Most of the states correspond to states from the IPv6 Stateless Address Autoconfiguration
protocol.
vrouter> show state vrf <vrf> interface svti <svti> ipv6 address <address> status
neighbor
link-layer-address (mandatory)
link-layer-address LINK-LAYER-ADDRESS
vrouter> show state vrf <vrf> interface svti <svti> ipv6 neighbor <neighbor> router
vrouter> show state vrf <vrf> interface svti <svti> ipv6 neighbor <neighbor> state
network-stack
ipv4
IPv4 parameters.
vrouter running config# vrf <vrf> interface svti <svti> network-stack ipv4
send-redirects
vrouter running config# vrf <vrf> interface svti <svti> network-stack ipv4
vrouter running ipv4# send-redirects true|false
accept-redirects
Accept redirect when acting as a host. It is always disabled when acting as a router. Must be activated at vrf or
system level too to be activated.
vrouter running config# vrf <vrf> interface svti <svti> network-stack ipv4
vrouter running ipv4# accept-redirects true|false
accept-source-route
Accept packets with source route option. Must be activated at vrf or system level too to be activated.
vrouter running config# vrf <vrf> interface svti <svti> network-stack ipv4
vrouter running ipv4# accept-source-route true|false
arp-announce
Define different restriction levels for announcing the local source IP address from IP packets in ARP requests sent
on interface. Increasing the restriction level gives more chance for receiving answer from the resolved target while
decreasing the level announces more valid sender’s information.
vrouter running config# vrf <vrf> interface svti <svti> network-stack ipv4
vrouter running ipv4# arp-announce ARP-ANNOUNCE
Description
ARP-ANNOUNCE
val-
ues
any Use any local address, configured on any interface.
avoid- Try to avoid local addresses that are not in the target’s subnet for this interface. This mode is useful when
not- target hosts reachable via this interface require the source IP address in ARP requests to be part of their
in- logical network configured on the receiving interface. When we generate the request we will check all our
subnet subnets that include the target IP and will preserve the source address if it is from such subnet. If there is
no such subnet we select source address according to the rules for level 2, ‘best-local’.
best- Always use the best local address for this target. In this mode we ignore the source address in the IP packet
local and try to select local address that we prefer for talks with the target host. Such local address is selected
by looking for primary IP addresses on all our subnets on the outgoing interface that include the target
IP address. If no suitable local address is found we select the first local address we have on the outgoing
interface or on all other interfaces, with the hope we will receive reply for our request and even sometimes
no matter the source IP address we announce.
arp-filter
Allows to have multiple network interfaces on the same subnet, and have the ARPs for each interface be answered
based on whether or not the kernel would route a packet from the ARP’d IP out that interface (therefore you must
use source based routing for this to work). In other words it allows control of which cards (usually 1) will respond
to an arp request.
vrouter running config# vrf <vrf> interface svti <svti> network-stack ipv4
vrouter running ipv4# arp-filter true|false
arp-ignore
Define different modes for sending replies in response to received ARP requests that resolve local target IP addresses.
vrouter running config# vrf <vrf> interface svti <svti> network-stack ipv4
vrouter running ipv4# arp-ignore ARP-IGNORE
ARP-IGNORE Description
values
any Reply for any local target IP address, configured on any interface.
check- Reply only if the target IP address is local address configured on the incoming interface.
interface
check- Reply only if the target IP address is local address configured on the incoming interface and
interface- both with the sender’s IP address are part from same subnet on this interface.
and-subnet
ignore-scope Do not reply for local addresses configured with scope host, only resolutions for global and
link addresses are replied.
ignore-all Do not reply for all local addresses.
log-invalid-addresses
vrouter running config# vrf <vrf> interface svti <svti> network-stack ipv4
vrouter running ipv4# log-invalid-addresses true|false
ipv6
IPv6 parameters.
vrouter running config# vrf <vrf> interface svti <svti> network-stack ipv6
autoconfiguration
vrouter running config# vrf <vrf> interface svti <svti> network-stack ipv6
vrouter running ipv6# autoconfiguration true|false
accept-router-advert
vrouter running config# vrf <vrf> interface svti <svti> network-stack ipv6
vrouter running ipv6# accept-router-advert ACCEPT-ROUTER-ADVERT
accept-redirects
Accept redirect when acting as a host. It is always disabled when acting as a router.
vrouter running config# vrf <vrf> interface svti <svti> network-stack ipv6
vrouter running ipv6# accept-redirects true|false
accept-source-route
vrouter running config# vrf <vrf> interface svti <svti> network-stack ipv6
vrouter running ipv6# accept-source-route true|false
router-solicitations
vrouter running config# vrf <vrf> interface svti <svti> network-stack ipv6
vrouter running ipv6# router-solicitations <int16>
use-temporary-addresses
Preference for Privacy Extensions (RFC4941). Not applied to point-to- point and loopback devices (always 0).
vrouter running config# vrf <vrf> interface svti <svti> network-stack ipv6
vrouter running ipv6# use-temporary-addresses USE-TEMPORARY-ADDRESSES
USE-TEMPORARY-ADDRESSESDescription
values
never Disable Privacy Extensions, i.e. use the public address, subnet prefix/interface id,
where interface id is always the same.
prefer-public-addresses Enable Privacy Extensions, but prefer public addresses over temporary addresses.
always Enable Privacy Extensions and prefer temporary addresses over public addresses.
qos
QoS configuration.
ingress
vrouter running config# vrf <vrf> interface svti <svti> qos ingress
rate-limit
vrouter running config# vrf <vrf> interface svti <svti> qos ingress rate-limit
vrouter running config# vrf <vrf> interface svti <svti> qos ingress rate-limit
vrouter running rate-limit# policer <leafref>
vrouter running config# vrf <vrf> interface svti <svti> qos ingress rate-limit
vrouter running rate-limit# shared-policer <leafref>
Traffic policer.
Maximum bandwidth of regular traffic, a.k.a. CIR (Committed Information Rate), in bps. 0 allows no regular traffic.
vrouter> show state vrf <vrf> interface svti <svti> qos ingress rate-limit policer␣
˓→bandwidth
Maximum burst size of shaped traffic, a.k.a. CBS (Committed Burst Size), in bytes. The default value is set to
bandwidth / 80 to handle a burst of 100 ms at the targeted bandwidth. If not set or set to 0, the default value is
applied.
vrouter> show state vrf <vrf> interface svti <svti> qos ingress rate-limit policer␣
˓→burst
Maximum bandwidth of excess traffic, a.k.a. EIR (Excess Information Rate), in bps. 0 allows no excess traffic.
vrouter> show state vrf <vrf> interface svti <svti> qos ingress rate-limit policer␣
˓→excess-bandwidth
Maximum burst size of excess traffic, a.k.a. EBS (Excess Burst Size), in bytes. The default value is set to excess-
bandwidth / 80 to handle a burst of 100 ms at the targeted bandwidth. If not set or set to 0, the default value is
applied.
vrouter> show state vrf <vrf> interface svti <svti> qos ingress rate-limit policer␣
˓→excess-burst
vrouter> show state vrf <vrf> interface svti <svti> qos ingress rate-limit policer␣
˓→shared-policer
Number of packets passed (regular traffic that conforms to (bandwidth, burst) specification.
vrouter> show state vrf <vrf> interface svti <svti> qos ingress rate-limit policer␣
˓→stats pass-packets
Number of bytes passed (regular traffic that conforms to (bandwidth, burst) specification.
vrouter> show state vrf <vrf> interface svti <svti> qos ingress rate-limit policer␣
˓→stats pass-bytes
Number of excess packets passed (excess traffic that conforms to (excess-bandwidth, excess-burst) specification.
vrouter> show state vrf <vrf> interface svti <svti> qos ingress rate-limit policer␣
˓→stats pass-excess-packets
Number of excess bytes passed (excess traffic that conforms to (excess-bandwidth, excess-burst) specification.
vrouter> show state vrf <vrf> interface svti <svti> qos ingress rate-limit policer␣
˓→stats pass-excess-bytes
Number of packets dropped (traffic that does not conform to bandwidth or excess-bandwidth).
vrouter> show state vrf <vrf> interface svti <svti> qos ingress rate-limit policer␣
˓→stats drop-packets
Number of bytes dropped (traffic that does not conform to bandwidth or excess-bandwidth).
vrouter> show state vrf <vrf> interface svti <svti> qos ingress rate-limit policer␣
˓→stats drop-bytes
egress
vrouter running config# vrf <vrf> interface svti <svti> qos egress
rate-limit
vrouter running config# vrf <vrf> interface svti <svti> qos egress rate-limit
vrouter running config# vrf <vrf> interface svti <svti> qos egress rate-limit
vrouter running rate-limit# policer <leafref>
vrouter running config# vrf <vrf> interface svti <svti> qos egress rate-limit
vrouter running rate-limit# shared-policer <leafref>
Traffic policer.
Maximum bandwidth of regular traffic, a.k.a. CIR (Committed Information Rate), in bps. 0 allows no regular traffic.
vrouter> show state vrf <vrf> interface svti <svti> qos egress rate-limit policer␣
˓→bandwidth
Maximum burst size of shaped traffic, a.k.a. CBS (Committed Burst Size), in bytes. The default value is set to
bandwidth / 80 to handle a burst of 100 ms at the targeted bandwidth. If not set or set to 0, the default value is
applied.
vrouter> show state vrf <vrf> interface svti <svti> qos egress rate-limit policer burst
Maximum bandwidth of excess traffic, a.k.a. EIR (Excess Information Rate), in bps. 0 allows no excess traffic.
vrouter> show state vrf <vrf> interface svti <svti> qos egress rate-limit policer␣
˓→excess-bandwidth
Maximum burst size of excess traffic, a.k.a. EBS (Excess Burst Size), in bytes. The default value is set to excess-
bandwidth / 80 to handle a burst of 100 ms at the targeted bandwidth. If not set or set to 0, the default value is
applied.
vrouter> show state vrf <vrf> interface svti <svti> qos egress rate-limit policer␣
˓→excess-burst
vrouter> show state vrf <vrf> interface svti <svti> qos egress rate-limit policer␣
˓→shared-policer
Number of packets passed (regular traffic that conforms to (bandwidth, burst) specification.
vrouter> show state vrf <vrf> interface svti <svti> qos egress rate-limit policer␣
˓→stats pass-packets
Number of bytes passed (regular traffic that conforms to (bandwidth, burst) specification.
vrouter> show state vrf <vrf> interface svti <svti> qos egress rate-limit policer␣
˓→stats pass-bytes
Number of excess packets passed (excess traffic that conforms to (excess-bandwidth, excess-burst) specification.
vrouter> show state vrf <vrf> interface svti <svti> qos egress rate-limit policer␣
˓→stats pass-excess-packets
Number of excess bytes passed (excess traffic that conforms to (excess-bandwidth, excess-burst) specification.
vrouter> show state vrf <vrf> interface svti <svti> qos egress rate-limit policer␣
˓→stats pass-excess-bytes
Number of packets dropped (traffic that does not conform to bandwidth or excess-bandwidth).
vrouter> show state vrf <vrf> interface svti <svti> qos egress rate-limit policer␣
˓→stats drop-packets
Number of bytes dropped (traffic that does not conform to bandwidth or excess-bandwidth).
vrouter> show state vrf <vrf> interface svti <svti> qos egress rate-limit policer␣
˓→stats drop-bytes
The total number of octets received on the interface, including framing characters. Discontinuities in the value of
this counter can occur at re-initialization of the management system, and at other times as indicated by the value of
‘last-clear’.
vrouter> show state vrf <vrf> interface svti <svti> counters in-octets
The number of packets, delivered by this sub-layer to a higher (sub-)layer, that were not addressed to a multicast or
broadcast address at this sub-layer. Discontinuities in the value of this counter can occur at re-initialization of the
management system, and at other times as indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface svti <svti> counters in-unicast-pkts
The number of inbound packets that were chosen to be discarded even though no errors had been detected to prevent
their being deliverable to a higher-layer protocol. One possible reason for discarding such a packet could be to free
up buffer space. Discontinuities in the value of this counter can occur at re-initialization of the management system,
and at other times as indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface svti <svti> counters in-discards
For packet-oriented interfaces, the number of inbound packets that contained errors preventing them from being
deliverable to a higher- layer protocol. For character- oriented or fixed-length interfaces, the number of inbound
transmission units that contained errors preventing them from being deliverable to a higher-layer protocol. Discon-
tinuities in the value of this counter can occur at re- initialization of the management system, and at other times as
indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface svti <svti> counters in-errors
The total number of octets transmitted out of the interface, including framing characters. Discontinuities in the
value of this counter can occur at re-initialization of the management system, and at other times as indicated by the
value of ‘last-clear’.
vrouter> show state vrf <vrf> interface svti <svti> counters out-octets
The total number of packets that higher-level protocols requested be transmitted, and that were not addressed to a
multicast or broadcast address at this sub-layer, including those that were discarded or not sent. Discontinuities in
the value of this counter can occur at re- initialization of the management system, and at other times as indicated by
the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface svti <svti> counters out-unicast-pkts
The number of outbound packets that were chosen to be discarded even though no errors had been detected to
prevent their being transmitted. One possible reason for discarding such a packet could be to free up buffer space.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other
times as indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface svti <svti> counters out-discards
For packet-oriented interfaces, the number of outbound packets that could not be transmitted because of errors. For
character-oriented or fixed-length interfaces, the number of outbound transmission units that could not be transmitted
because of errors. Discontinuities in the value of this counter can occur at re-initialization of the management system,
and at other times as indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface svti <svti> counters out-errors
Default value
vip-or-remote-ts
System assigned number for each interface. Corresponds to ifIndex object in SNMP Interface MIB.
The desired state of the interface. In RFC 7223 this leaf has the same read semantics as ifAdminStatus. Here, it
reflects the administrative state as set by enabling or disabling the interface.
The current operational state of the interface. This leaf has the same semantics as ifOperStatus.
This timestamp indicates the time of the last state change of the interface (e.g., up-to-down transition). This corre-
sponds to the ifLastChange object in the standard interface MIB. The value is the timestamp in nanoseconds relative
to the Unix Epoch (Jan 1, 1970 00:00:00 UTC).
Controls whether IPv4 is enabled or disabled on this interface. When IPv4 is enabled, this interface is connected to
an IPv4 stack, and the interface can send and receive IPv4 packets.
vrouter> show state vrf <vrf> interface system-loopback <system-loopback> ipv4 enabled
The IPv4 address of the remote endpoint for point to point interfaces.
vrouter> show state vrf <vrf> interface system-loopback <system-loopback> ipv4 address
˓→<address> peer
The origin of this address, e.g., statically configured, assigned by DHCP, etc..
vrouter> show state vrf <vrf> interface system-loopback <system-loopback> ipv4 address
˓→<address> origin
A list of mappings from IPv4 addresses to link-layer addresses. Entries in this list are used as static entries in the
ARP Cache.
vrouter> show state vrf <vrf> interface system-loopback <system-loopback> ipv4 dhcp␣
˓→enabled
Time before deciding that it’s not going to be able to contact a server.
vrouter> show state vrf <vrf> interface system-loopback <system-loopback> ipv4 dhcp␣
˓→timeout
vrouter> show state vrf <vrf> interface system-loopback <system-loopback> ipv4 dhcp␣
˓→retry
Time at which the client stops waiting for other offers from servers.
vrouter> show state vrf <vrf> interface system-loopback <system-loopback> ipv4 dhcp␣
˓→select-timeout
Time after trying to reacquire its old address before trying to discover a new address.
vrouter> show state vrf <vrf> interface system-loopback <system-loopback> ipv4 dhcp␣
˓→reboot
Time between the first attempt to reach a server and the second attempt to reach a server.
vrouter> show state vrf <vrf> interface system-loopback <system-loopback> ipv4 dhcp␣
˓→initial-interval
vrouter> show state vrf <vrf> interface system-loopback <system-loopback> ipv4 dhcp␣
˓→dhcp-lease-time
vrouter> show state vrf <vrf> interface system-loopback <system-loopback> ipv4 dhcp␣
˓→dhcp-client-identifier-ascii
vrouter> show state vrf <vrf> interface system-loopback <system-loopback> ipv4 dhcp␣
˓→dhcp-client-identifier-hexa
vrouter> show state vrf <vrf> interface system-loopback <system-loopback> ipv4 dhcp␣
˓→host-name
DHCP requests.
vrouter> show state vrf <vrf> interface system-loopback <system-loopback> ipv4 dhcp␣
˓→request
Current lease.
vrouter> show state vrf <vrf> interface system-loopback <system-loopback> ipv4 dhcp␣
˓→current-lease fixed-address
Time at which the client should begin trying to contact its server to renew its lease.
vrouter> show state vrf <vrf> interface system-loopback <system-loopback> ipv4 dhcp␣
˓→current-lease renew
Time at which the client should begin to try to contact any dhcp server to renew its lease.
vrouter> show state vrf <vrf> interface system-loopback <system-loopback> ipv4 dhcp␣
˓→current-lease rebind
Time at which the client must stop using a lease if it has not been able to renew it.
vrouter> show state vrf <vrf> interface system-loopback <system-loopback> ipv4 dhcp␣
˓→current-lease expire
Controls whether IPv6 is enabled or disabled on this interface. When IPv6 is enabled, this interface is connected to
an IPv6 stack, and the interface can send and receive IPv6 packets.
vrouter> show state vrf <vrf> interface system-loopback <system-loopback> ipv6 enabled
The IPv6 address of the remote endpoint for point to point interfaces.
vrouter> show state vrf <vrf> interface system-loopback <system-loopback> ipv6 address
˓→<address> peer
vrouter> show state vrf <vrf> interface system-loopback <system-loopback> ipv6 address
˓→<address> origin
The status of an address. Most of the states correspond to states from the IPv6 Stateless Address Autoconfiguration
protocol.
vrouter> show state vrf <vrf> interface system-loopback <system-loopback> ipv6 address
˓→<address> status
The total number of octets received on the interface, including framing characters. Discontinuities in the value of
this counter can occur at re-initialization of the management system, and at other times as indicated by the value of
‘last-clear’.
vrouter> show state vrf <vrf> interface system-loopback <system-loopback> counters in-
˓→octets
The number of packets, delivered by this sub-layer to a higher (sub-)layer, that were not addressed to a multicast or
broadcast address at this sub-layer. Discontinuities in the value of this counter can occur at re-initialization of the
management system, and at other times as indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface system-loopback <system-loopback> counters in-
˓→unicast-pkts
The number of inbound packets that were chosen to be discarded even though no errors had been detected to prevent
their being deliverable to a higher-layer protocol. One possible reason for discarding such a packet could be to free
up buffer space. Discontinuities in the value of this counter can occur at re-initialization of the management system,
and at other times as indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface system-loopback <system-loopback> counters in-
˓→discards
For packet-oriented interfaces, the number of inbound packets that contained errors preventing them from being
deliverable to a higher- layer protocol. For character- oriented or fixed-length interfaces, the number of inbound
transmission units that contained errors preventing them from being deliverable to a higher-layer protocol. Discon-
tinuities in the value of this counter can occur at re- initialization of the management system, and at other times as
indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface system-loopback <system-loopback> counters in-
˓→errors
The total number of octets transmitted out of the interface, including framing characters. Discontinuities in the
value of this counter can occur at re-initialization of the management system, and at other times as indicated by the
value of ‘last-clear’.
vrouter> show state vrf <vrf> interface system-loopback <system-loopback> counters out-
˓→octets
The total number of packets that higher-level protocols requested be transmitted, and that were not addressed to a
multicast or broadcast address at this sub-layer, including those that were discarded or not sent. Discontinuities in
the value of this counter can occur at re- initialization of the management system, and at other times as indicated by
the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface system-loopback <system-loopback> counters out-
˓→unicast-pkts
The number of outbound packets that were chosen to be discarded even though no errors had been detected to
prevent their being transmitted. One possible reason for discarding such a packet could be to free up buffer space.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other
times as indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface system-loopback <system-loopback> counters out-
˓→discards
For packet-oriented interfaces, the number of outbound packets that could not be transmitted because of errors. For
character-oriented or fixed-length interfaces, the number of outbound transmission units that could not be transmitted
because of errors. Discontinuities in the value of this counter can occur at re-initialization of the management system,
and at other times as indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface system-loopback <system-loopback> counters out-
˓→errors
veth
mtu
promiscuous
description
enabled
Default value
true
link-interface (mandatory)
link-vrf (mandatory)
System assigned number for each interface. Corresponds to ifIndex object in SNMP Interface MIB.
The desired state of the interface. In RFC 7223 this leaf has the same read semantics as ifAdminStatus. Here, it
reflects the administrative state as set by enabling or disabling the interface.
The current operational state of the interface. This leaf has the same semantics as ifOperStatus.
This timestamp indicates the time of the last state change of the interface (e.g., up-to-down transition). This corre-
sponds to the ifLastChange object in the standard interface MIB. The value is the timestamp in nanoseconds relative
to the Unix Epoch (Jan 1, 1970 00:00:00 UTC).
ipv4
enabled
Controls whether IPv4 is enabled or disabled on this interface. When IPv4 is enabled, this interface is connected to
an IPv4 stack, and the interface can send and receive IPv4 packets.
Default value
true
address
peer
The IPv4 address of the remote endpoint for point to point interfaces.
peer PEER
The origin of this address, e.g., statically configured, assigned by DHCP, etc..
vrouter> show state vrf <vrf> interface veth <veth> ipv4 address <address> origin
neighbor
A list of mappings from IPv4 addresses to link-layer addresses. Entries in this list are used as static entries in the
ARP Cache.
link-layer-address (mandatory)
link-layer-address LINK-LAYER-ADDRESS
vrouter> show state vrf <vrf> interface veth <veth> ipv4 neighbor <neighbor> state
dhcp
vrouter running config# vrf <vrf> interface veth <veth> ipv4 dhcp
enabled
vrouter running config# vrf <vrf> interface veth <veth> ipv4 dhcp
vrouter running dhcp# enabled true|false
Default value
true
timeout
Time before deciding that it’s not going to be able to contact a server.
vrouter running config# vrf <vrf> interface veth <veth> ipv4 dhcp
vrouter running dhcp# timeout <uint32>
Default value
60
retry
vrouter running config# vrf <vrf> interface veth <veth> ipv4 dhcp
vrouter running dhcp# retry <uint32>
Default value
300
select-timeout
Time at which the client stops waiting for other offers from servers.
vrouter running config# vrf <vrf> interface veth <veth> ipv4 dhcp
vrouter running dhcp# select-timeout <uint32>
Default value
0
reboot
Time after trying to reacquire its old address before trying to discover a new address.
vrouter running config# vrf <vrf> interface veth <veth> ipv4 dhcp
vrouter running dhcp# reboot <uint32>
Default value
10
initial-interval
Time between the first attempt to reach a server and the second attempt to reach a server.
vrouter running config# vrf <vrf> interface veth <veth> ipv4 dhcp
vrouter running dhcp# initial-interval <uint32>
Default value
10
dhcp-lease-time
vrouter running config# vrf <vrf> interface veth <veth> ipv4 dhcp
vrouter running dhcp# dhcp-lease-time <uint32>
Default value
7200
dhcp-client-identifier-ascii
vrouter running config# vrf <vrf> interface veth <veth> ipv4 dhcp
vrouter running dhcp# dhcp-client-identifier-ascii <string>
dhcp-client-identifier-hexa
vrouter running config# vrf <vrf> interface veth <veth> ipv4 dhcp
vrouter running dhcp# dhcp-client-identifier-hexa <string>
host-name
vrouter running config# vrf <vrf> interface veth <veth> ipv4 dhcp
vrouter running dhcp# host-name <string>
request
DHCP requests.
vrouter running config# vrf <vrf> interface veth <veth> ipv4 dhcp
vrouter running dhcp# request REQUEST
Default value
subnet-mask
broadcast-address
time-offset
routers
domain-name
domain-search
domain-name-servers
host-name
nis-domain
nis-servers
ntp-servers
interface-mtu
Current lease.
vrouter> show state vrf <vrf> interface veth <veth> ipv4 dhcp current-lease fixed-
˓→address
Time at which the client should begin trying to contact its server to renew its lease.
vrouter> show state vrf <vrf> interface veth <veth> ipv4 dhcp current-lease renew
Time at which the client should begin to try to contact any dhcp server to renew its lease.
vrouter> show state vrf <vrf> interface veth <veth> ipv4 dhcp current-lease rebind
Time at which the client must stop using a lease if it has not been able to renew it.
vrouter> show state vrf <vrf> interface veth <veth> ipv4 dhcp current-lease expire
ipv6
enabled
Controls whether IPv6 is enabled or disabled on this interface. When IPv6 is enabled, this interface is connected to
an IPv6 stack, and the interface can send and receive IPv6 packets.
Default value
true
address
peer
The IPv6 address of the remote endpoint for point to point interfaces.
peer PEER
vrouter> show state vrf <vrf> interface veth <veth> ipv6 address <address> origin
The status of an address. Most of the states correspond to states from the IPv6 Stateless Address Autoconfiguration
protocol.
vrouter> show state vrf <vrf> interface veth <veth> ipv6 address <address> status
neighbor
link-layer-address (mandatory)
link-layer-address LINK-LAYER-ADDRESS
vrouter> show state vrf <vrf> interface veth <veth> ipv6 neighbor <neighbor> router
vrouter> show state vrf <vrf> interface veth <veth> ipv6 neighbor <neighbor> state
network-stack
ipv4
IPv4 parameters.
vrouter running config# vrf <vrf> interface veth <veth> network-stack ipv4
send-redirects
vrouter running config# vrf <vrf> interface veth <veth> network-stack ipv4
vrouter running ipv4# send-redirects true|false
accept-redirects
Accept redirect when acting as a host. It is always disabled when acting as a router. Must be activated at vrf or
system level too to be activated.
vrouter running config# vrf <vrf> interface veth <veth> network-stack ipv4
vrouter running ipv4# accept-redirects true|false
accept-source-route
Accept packets with source route option. Must be activated at vrf or system level too to be activated.
vrouter running config# vrf <vrf> interface veth <veth> network-stack ipv4
vrouter running ipv4# accept-source-route true|false
arp-announce
Define different restriction levels for announcing the local source IP address from IP packets in ARP requests sent
on interface. Increasing the restriction level gives more chance for receiving answer from the resolved target while
decreasing the level announces more valid sender’s information.
vrouter running config# vrf <vrf> interface veth <veth> network-stack ipv4
vrouter running ipv4# arp-announce ARP-ANNOUNCE
Description
ARP-ANNOUNCE
val-
ues
any Use any local address, configured on any interface.
avoid- Try to avoid local addresses that are not in the target’s subnet for this interface. This mode is useful when
not- target hosts reachable via this interface require the source IP address in ARP requests to be part of their
in- logical network configured on the receiving interface. When we generate the request we will check all our
subnet subnets that include the target IP and will preserve the source address if it is from such subnet. If there is
no such subnet we select source address according to the rules for level 2, ‘best-local’.
best- Always use the best local address for this target. In this mode we ignore the source address in the IP packet
local and try to select local address that we prefer for talks with the target host. Such local address is selected
by looking for primary IP addresses on all our subnets on the outgoing interface that include the target
IP address. If no suitable local address is found we select the first local address we have on the outgoing
interface or on all other interfaces, with the hope we will receive reply for our request and even sometimes
no matter the source IP address we announce.
arp-filter
Allows to have multiple network interfaces on the same subnet, and have the ARPs for each interface be answered
based on whether or not the kernel would route a packet from the ARP’d IP out that interface (therefore you must
use source based routing for this to work). In other words it allows control of which cards (usually 1) will respond
to an arp request.
vrouter running config# vrf <vrf> interface veth <veth> network-stack ipv4
vrouter running ipv4# arp-filter true|false
arp-ignore
Define different modes for sending replies in response to received ARP requests that resolve local target IP addresses.
vrouter running config# vrf <vrf> interface veth <veth> network-stack ipv4
vrouter running ipv4# arp-ignore ARP-IGNORE
ARP-IGNORE Description
values
any Reply for any local target IP address, configured on any interface.
check- Reply only if the target IP address is local address configured on the incoming interface.
interface
check- Reply only if the target IP address is local address configured on the incoming interface and
interface- both with the sender’s IP address are part from same subnet on this interface.
and-subnet
ignore-scope Do not reply for local addresses configured with scope host, only resolutions for global and
link addresses are replied.
ignore-all Do not reply for all local addresses.
log-invalid-addresses
vrouter running config# vrf <vrf> interface veth <veth> network-stack ipv4
vrouter running ipv4# log-invalid-addresses true|false
ipv6
IPv6 parameters.
vrouter running config# vrf <vrf> interface veth <veth> network-stack ipv6
autoconfiguration
vrouter running config# vrf <vrf> interface veth <veth> network-stack ipv6
vrouter running ipv6# autoconfiguration true|false
accept-router-advert
vrouter running config# vrf <vrf> interface veth <veth> network-stack ipv6
vrouter running ipv6# accept-router-advert ACCEPT-ROUTER-ADVERT
accept-redirects
Accept redirect when acting as a host. It is always disabled when acting as a router.
vrouter running config# vrf <vrf> interface veth <veth> network-stack ipv6
vrouter running ipv6# accept-redirects true|false
accept-source-route
vrouter running config# vrf <vrf> interface veth <veth> network-stack ipv6
vrouter running ipv6# accept-source-route true|false
router-solicitations
vrouter running config# vrf <vrf> interface veth <veth> network-stack ipv6
vrouter running ipv6# router-solicitations <int16>
use-temporary-addresses
Preference for Privacy Extensions (RFC4941). Not applied to point-to- point and loopback devices (always 0).
vrouter running config# vrf <vrf> interface veth <veth> network-stack ipv6
vrouter running ipv6# use-temporary-addresses USE-TEMPORARY-ADDRESSES
USE-TEMPORARY-ADDRESSESDescription
values
never Disable Privacy Extensions, i.e. use the public address, subnet prefix/interface id,
where interface id is always the same.
prefer-public-addresses Enable Privacy Extensions, but prefer public addresses over temporary addresses.
always Enable Privacy Extensions and prefer temporary addresses over public addresses.
ethernet
mac-address
Assigns a MAC address to the Ethernet interface. If not specified, the corresponding operational state leaf is expected
to show the system-assigned MAC address.
MAC- An IEEE 802 unicast MAC address i.e. the second digit is an even number. Moreover the mac
ADDRESS address must not be 00:00:00:00:00:00.
qos
QoS configuration.
ingress
vrouter running config# vrf <vrf> interface veth <veth> qos ingress
rate-limit
vrouter running config# vrf <vrf> interface veth <veth> qos ingress rate-limit
vrouter running config# vrf <vrf> interface veth <veth> qos ingress rate-limit
vrouter running rate-limit# policer <leafref>
vrouter running config# vrf <vrf> interface veth <veth> qos ingress rate-limit
vrouter running rate-limit# shared-policer <leafref>
Traffic policer.
Maximum bandwidth of regular traffic, a.k.a. CIR (Committed Information Rate), in bps. 0 allows no regular traffic.
vrouter> show state vrf <vrf> interface veth <veth> qos ingress rate-limit policer␣
˓→bandwidth
Maximum burst size of shaped traffic, a.k.a. CBS (Committed Burst Size), in bytes. The default value is set to
bandwidth / 80 to handle a burst of 100 ms at the targeted bandwidth. If not set or set to 0, the default value is
applied.
vrouter> show state vrf <vrf> interface veth <veth> qos ingress rate-limit policer␣
˓→burst
Maximum bandwidth of excess traffic, a.k.a. EIR (Excess Information Rate), in bps. 0 allows no excess traffic.
vrouter> show state vrf <vrf> interface veth <veth> qos ingress rate-limit policer␣
˓→excess-bandwidth
Maximum burst size of excess traffic, a.k.a. EBS (Excess Burst Size), in bytes. The default value is set to excess-
bandwidth / 80 to handle a burst of 100 ms at the targeted bandwidth. If not set or set to 0, the default value is
applied.
vrouter> show state vrf <vrf> interface veth <veth> qos ingress rate-limit policer␣
˓→excess-burst
vrouter> show state vrf <vrf> interface veth <veth> qos ingress rate-limit policer␣
˓→shared-policer
Number of packets passed (regular traffic that conforms to (bandwidth, burst) specification.
vrouter> show state vrf <vrf> interface veth <veth> qos ingress rate-limit policer␣
˓→stats pass-packets
Number of bytes passed (regular traffic that conforms to (bandwidth, burst) specification.
vrouter> show state vrf <vrf> interface veth <veth> qos ingress rate-limit policer␣
˓→stats pass-bytes
Number of excess packets passed (excess traffic that conforms to (excess-bandwidth, excess-burst) specification.
vrouter> show state vrf <vrf> interface veth <veth> qos ingress rate-limit policer␣
˓→stats pass-excess-packets
Number of excess bytes passed (excess traffic that conforms to (excess-bandwidth, excess-burst) specification.
vrouter> show state vrf <vrf> interface veth <veth> qos ingress rate-limit policer␣
˓→stats pass-excess-bytes
Number of packets dropped (traffic that does not conform to bandwidth or excess-bandwidth).
vrouter> show state vrf <vrf> interface veth <veth> qos ingress rate-limit policer␣
˓→stats drop-packets
Number of bytes dropped (traffic that does not conform to bandwidth or excess-bandwidth).
vrouter> show state vrf <vrf> interface veth <veth> qos ingress rate-limit policer␣
˓→stats drop-bytes
egress
vrouter running config# vrf <vrf> interface veth <veth> qos egress
rate-limit
vrouter running config# vrf <vrf> interface veth <veth> qos egress rate-limit
vrouter running config# vrf <vrf> interface veth <veth> qos egress rate-limit
vrouter running rate-limit# policer <leafref>
vrouter running config# vrf <vrf> interface veth <veth> qos egress rate-limit
vrouter running rate-limit# shared-policer <leafref>
Traffic policer.
Maximum bandwidth of regular traffic, a.k.a. CIR (Committed Information Rate), in bps. 0 allows no regular traffic.
vrouter> show state vrf <vrf> interface veth <veth> qos egress rate-limit policer␣
˓→bandwidth
Maximum burst size of shaped traffic, a.k.a. CBS (Committed Burst Size), in bytes. The default value is set to
bandwidth / 80 to handle a burst of 100 ms at the targeted bandwidth. If not set or set to 0, the default value is
applied.
vrouter> show state vrf <vrf> interface veth <veth> qos egress rate-limit policer burst
Maximum bandwidth of excess traffic, a.k.a. EIR (Excess Information Rate), in bps. 0 allows no excess traffic.
vrouter> show state vrf <vrf> interface veth <veth> qos egress rate-limit policer␣
˓→excess-bandwidth
Maximum burst size of excess traffic, a.k.a. EBS (Excess Burst Size), in bytes. The default value is set to excess-
bandwidth / 80 to handle a burst of 100 ms at the targeted bandwidth. If not set or set to 0, the default value is
applied.
vrouter> show state vrf <vrf> interface veth <veth> qos egress rate-limit policer␣
˓→excess-burst
vrouter> show state vrf <vrf> interface veth <veth> qos egress rate-limit policer␣
˓→shared-policer
Number of packets passed (regular traffic that conforms to (bandwidth, burst) specification.
vrouter> show state vrf <vrf> interface veth <veth> qos egress rate-limit policer␣
˓→stats pass-packets
Number of bytes passed (regular traffic that conforms to (bandwidth, burst) specification.
vrouter> show state vrf <vrf> interface veth <veth> qos egress rate-limit policer␣
˓→stats pass-bytes
Number of excess packets passed (excess traffic that conforms to (excess-bandwidth, excess-burst) specification.
vrouter> show state vrf <vrf> interface veth <veth> qos egress rate-limit policer␣
˓→stats pass-excess-packets
Number of excess bytes passed (excess traffic that conforms to (excess-bandwidth, excess-burst) specification.
vrouter> show state vrf <vrf> interface veth <veth> qos egress rate-limit policer␣
˓→stats pass-excess-bytes
Number of packets dropped (traffic that does not conform to bandwidth or excess-bandwidth).
vrouter> show state vrf <vrf> interface veth <veth> qos egress rate-limit policer␣
˓→stats drop-packets
Number of bytes dropped (traffic that does not conform to bandwidth or excess-bandwidth).
vrouter> show state vrf <vrf> interface veth <veth> qos egress rate-limit policer␣
˓→stats drop-bytes
The total number of octets received on the interface, including framing characters. Discontinuities in the value of
this counter can occur at re-initialization of the management system, and at other times as indicated by the value of
‘last-clear’.
vrouter> show state vrf <vrf> interface veth <veth> counters in-octets
The number of packets, delivered by this sub-layer to a higher (sub-)layer, that were not addressed to a multicast or
broadcast address at this sub-layer. Discontinuities in the value of this counter can occur at re-initialization of the
management system, and at other times as indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface veth <veth> counters in-unicast-pkts
The number of inbound packets that were chosen to be discarded even though no errors had been detected to prevent
their being deliverable to a higher-layer protocol. One possible reason for discarding such a packet could be to free
up buffer space. Discontinuities in the value of this counter can occur at re-initialization of the management system,
and at other times as indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface veth <veth> counters in-discards
For packet-oriented interfaces, the number of inbound packets that contained errors preventing them from being
deliverable to a higher- layer protocol. For character- oriented or fixed-length interfaces, the number of inbound
transmission units that contained errors preventing them from being deliverable to a higher-layer protocol. Discon-
tinuities in the value of this counter can occur at re- initialization of the management system, and at other times as
indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface veth <veth> counters in-errors
The total number of octets transmitted out of the interface, including framing characters. Discontinuities in the
value of this counter can occur at re-initialization of the management system, and at other times as indicated by the
value of ‘last-clear’.
vrouter> show state vrf <vrf> interface veth <veth> counters out-octets
The total number of packets that higher-level protocols requested be transmitted, and that were not addressed to a
multicast or broadcast address at this sub-layer, including those that were discarded or not sent. Discontinuities in
the value of this counter can occur at re- initialization of the management system, and at other times as indicated by
the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface veth <veth> counters out-unicast-pkts
The number of outbound packets that were chosen to be discarded even though no errors had been detected to
prevent their being transmitted. One possible reason for discarding such a packet could be to free up buffer space.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other
times as indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface veth <veth> counters out-discards
For packet-oriented interfaces, the number of outbound packets that could not be transmitted because of errors. For
character-oriented or fixed-length interfaces, the number of outbound transmission units that could not be transmitted
because of errors. Discontinuities in the value of this counter can occur at re-initialization of the management system,
and at other times as indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface veth <veth> counters out-errors
vlan
mtu
promiscuous
description
enabled
Default value
true
vlan-id (mandatory)
link-interface (mandatory)
protocol
Default value
802.1q
link-vrf
System assigned number for each interface. Corresponds to ifIndex object in SNMP Interface MIB.
The desired state of the interface. In RFC 7223 this leaf has the same read semantics as ifAdminStatus. Here, it
reflects the administrative state as set by enabling or disabling the interface.
The current operational state of the interface. This leaf has the same semantics as ifOperStatus.
This timestamp indicates the time of the last state change of the interface (e.g., up-to-down transition). This corre-
sponds to the ifLastChange object in the standard interface MIB. The value is the timestamp in nanoseconds relative
to the Unix Epoch (Jan 1, 1970 00:00:00 UTC).
ethernet
mac-address
Assigns a MAC address to the Ethernet interface. If not specified, the corresponding operational state leaf is expected
to show the system-assigned MAC address.
MAC- An IEEE 802 unicast MAC address i.e. the second digit is an even number. Moreover the mac
ADDRESS address must not be 00:00:00:00:00:00.
ipv4
enabled
Controls whether IPv4 is enabled or disabled on this interface. When IPv4 is enabled, this interface is connected to
an IPv4 stack, and the interface can send and receive IPv4 packets.
Default value
true
address
peer
The IPv4 address of the remote endpoint for point to point interfaces.
peer PEER
The origin of this address, e.g., statically configured, assigned by DHCP, etc..
vrouter> show state vrf <vrf> interface vlan <vlan> ipv4 address <address> origin
neighbor
A list of mappings from IPv4 addresses to link-layer addresses. Entries in this list are used as static entries in the
ARP Cache.
link-layer-address (mandatory)
link-layer-address LINK-LAYER-ADDRESS
vrouter> show state vrf <vrf> interface vlan <vlan> ipv4 neighbor <neighbor> state
dhcp
vrouter running config# vrf <vrf> interface vlan <vlan> ipv4 dhcp
enabled
vrouter running config# vrf <vrf> interface vlan <vlan> ipv4 dhcp
vrouter running dhcp# enabled true|false
Default value
true
timeout
Time before deciding that it’s not going to be able to contact a server.
vrouter running config# vrf <vrf> interface vlan <vlan> ipv4 dhcp
vrouter running dhcp# timeout <uint32>
Default value
60
retry
vrouter running config# vrf <vrf> interface vlan <vlan> ipv4 dhcp
vrouter running dhcp# retry <uint32>
Default value
300
select-timeout
Time at which the client stops waiting for other offers from servers.
vrouter running config# vrf <vrf> interface vlan <vlan> ipv4 dhcp
vrouter running dhcp# select-timeout <uint32>
Default value
0
reboot
Time after trying to reacquire its old address before trying to discover a new address.
vrouter running config# vrf <vrf> interface vlan <vlan> ipv4 dhcp
vrouter running dhcp# reboot <uint32>
Default value
10
initial-interval
Time between the first attempt to reach a server and the second attempt to reach a server.
vrouter running config# vrf <vrf> interface vlan <vlan> ipv4 dhcp
vrouter running dhcp# initial-interval <uint32>
Default value
10
dhcp-lease-time
vrouter running config# vrf <vrf> interface vlan <vlan> ipv4 dhcp
vrouter running dhcp# dhcp-lease-time <uint32>
Default value
7200
dhcp-client-identifier-ascii
vrouter running config# vrf <vrf> interface vlan <vlan> ipv4 dhcp
vrouter running dhcp# dhcp-client-identifier-ascii <string>
dhcp-client-identifier-hexa
vrouter running config# vrf <vrf> interface vlan <vlan> ipv4 dhcp
vrouter running dhcp# dhcp-client-identifier-hexa <string>
host-name
vrouter running config# vrf <vrf> interface vlan <vlan> ipv4 dhcp
vrouter running dhcp# host-name <string>
request
DHCP requests.
vrouter running config# vrf <vrf> interface vlan <vlan> ipv4 dhcp
vrouter running dhcp# request REQUEST
Default value
subnet-mask
broadcast-address
time-offset
routers
domain-name
domain-search
domain-name-servers
host-name
nis-domain
nis-servers
ntp-servers
interface-mtu
Current lease.
vrouter> show state vrf <vrf> interface vlan <vlan> ipv4 dhcp current-lease fixed-
˓→address
Time at which the client should begin trying to contact its server to renew its lease.
vrouter> show state vrf <vrf> interface vlan <vlan> ipv4 dhcp current-lease renew
Time at which the client should begin to try to contact any dhcp server to renew its lease.
vrouter> show state vrf <vrf> interface vlan <vlan> ipv4 dhcp current-lease rebind
Time at which the client must stop using a lease if it has not been able to renew it.
vrouter> show state vrf <vrf> interface vlan <vlan> ipv4 dhcp current-lease expire
ipv6
enabled
Controls whether IPv6 is enabled or disabled on this interface. When IPv6 is enabled, this interface is connected to
an IPv6 stack, and the interface can send and receive IPv6 packets.
Default value
true
address
peer
The IPv6 address of the remote endpoint for point to point interfaces.
peer PEER
vrouter> show state vrf <vrf> interface vlan <vlan> ipv6 address <address> origin
The status of an address. Most of the states correspond to states from the IPv6 Stateless Address Autoconfiguration
protocol.
vrouter> show state vrf <vrf> interface vlan <vlan> ipv6 address <address> status
neighbor
link-layer-address (mandatory)
link-layer-address LINK-LAYER-ADDRESS
vrouter> show state vrf <vrf> interface vlan <vlan> ipv6 neighbor <neighbor> router
vrouter> show state vrf <vrf> interface vlan <vlan> ipv6 neighbor <neighbor> state
network-stack
ipv4
IPv4 parameters.
vrouter running config# vrf <vrf> interface vlan <vlan> network-stack ipv4
send-redirects
vrouter running config# vrf <vrf> interface vlan <vlan> network-stack ipv4
vrouter running ipv4# send-redirects true|false
accept-redirects
Accept redirect when acting as a host. It is always disabled when acting as a router. Must be activated at vrf or
system level too to be activated.
vrouter running config# vrf <vrf> interface vlan <vlan> network-stack ipv4
vrouter running ipv4# accept-redirects true|false
accept-source-route
Accept packets with source route option. Must be activated at vrf or system level too to be activated.
vrouter running config# vrf <vrf> interface vlan <vlan> network-stack ipv4
vrouter running ipv4# accept-source-route true|false
arp-announce
Define different restriction levels for announcing the local source IP address from IP packets in ARP requests sent
on interface. Increasing the restriction level gives more chance for receiving answer from the resolved target while
decreasing the level announces more valid sender’s information.
vrouter running config# vrf <vrf> interface vlan <vlan> network-stack ipv4
vrouter running ipv4# arp-announce ARP-ANNOUNCE
Description
ARP-ANNOUNCE
val-
ues
any Use any local address, configured on any interface.
avoid- Try to avoid local addresses that are not in the target’s subnet for this interface. This mode is useful when
not- target hosts reachable via this interface require the source IP address in ARP requests to be part of their
in- logical network configured on the receiving interface. When we generate the request we will check all our
subnet subnets that include the target IP and will preserve the source address if it is from such subnet. If there is
no such subnet we select source address according to the rules for level 2, ‘best-local’.
best- Always use the best local address for this target. In this mode we ignore the source address in the IP packet
local and try to select local address that we prefer for talks with the target host. Such local address is selected
by looking for primary IP addresses on all our subnets on the outgoing interface that include the target
IP address. If no suitable local address is found we select the first local address we have on the outgoing
interface or on all other interfaces, with the hope we will receive reply for our request and even sometimes
no matter the source IP address we announce.
arp-filter
Allows to have multiple network interfaces on the same subnet, and have the ARPs for each interface be answered
based on whether or not the kernel would route a packet from the ARP’d IP out that interface (therefore you must
use source based routing for this to work). In other words it allows control of which cards (usually 1) will respond
to an arp request.
vrouter running config# vrf <vrf> interface vlan <vlan> network-stack ipv4
vrouter running ipv4# arp-filter true|false
arp-ignore
Define different modes for sending replies in response to received ARP requests that resolve local target IP addresses.
vrouter running config# vrf <vrf> interface vlan <vlan> network-stack ipv4
vrouter running ipv4# arp-ignore ARP-IGNORE
ARP-IGNORE Description
values
any Reply for any local target IP address, configured on any interface.
check- Reply only if the target IP address is local address configured on the incoming interface.
interface
check- Reply only if the target IP address is local address configured on the incoming interface and
interface- both with the sender’s IP address are part from same subnet on this interface.
and-subnet
ignore-scope Do not reply for local addresses configured with scope host, only resolutions for global and
link addresses are replied.
ignore-all Do not reply for all local addresses.
log-invalid-addresses
vrouter running config# vrf <vrf> interface vlan <vlan> network-stack ipv4
vrouter running ipv4# log-invalid-addresses true|false
ipv6
IPv6 parameters.
vrouter running config# vrf <vrf> interface vlan <vlan> network-stack ipv6
autoconfiguration
vrouter running config# vrf <vrf> interface vlan <vlan> network-stack ipv6
vrouter running ipv6# autoconfiguration true|false
accept-router-advert
vrouter running config# vrf <vrf> interface vlan <vlan> network-stack ipv6
vrouter running ipv6# accept-router-advert ACCEPT-ROUTER-ADVERT
accept-redirects
Accept redirect when acting as a host. It is always disabled when acting as a router.
vrouter running config# vrf <vrf> interface vlan <vlan> network-stack ipv6
vrouter running ipv6# accept-redirects true|false
accept-source-route
vrouter running config# vrf <vrf> interface vlan <vlan> network-stack ipv6
vrouter running ipv6# accept-source-route true|false
router-solicitations
vrouter running config# vrf <vrf> interface vlan <vlan> network-stack ipv6
vrouter running ipv6# router-solicitations <int16>
use-temporary-addresses
Preference for Privacy Extensions (RFC4941). Not applied to point-to- point and loopback devices (always 0).
vrouter running config# vrf <vrf> interface vlan <vlan> network-stack ipv6
vrouter running ipv6# use-temporary-addresses USE-TEMPORARY-ADDRESSES
USE-TEMPORARY-ADDRESSESDescription
values
never Disable Privacy Extensions, i.e. use the public address, subnet prefix/interface id,
where interface id is always the same.
prefer-public-addresses Enable Privacy Extensions, but prefer public addresses over temporary addresses.
always Enable Privacy Extensions and prefer temporary addresses over public addresses.
qos
QoS configuration.
ingress
vrouter running config# vrf <vrf> interface vlan <vlan> qos ingress
rate-limit
vrouter running config# vrf <vrf> interface vlan <vlan> qos ingress rate-limit
vrouter running config# vrf <vrf> interface vlan <vlan> qos ingress rate-limit
vrouter running rate-limit# policer <leafref>
vrouter running config# vrf <vrf> interface vlan <vlan> qos ingress rate-limit
vrouter running rate-limit# shared-policer <leafref>
Traffic policer.
Maximum bandwidth of regular traffic, a.k.a. CIR (Committed Information Rate), in bps. 0 allows no regular traffic.
vrouter> show state vrf <vrf> interface vlan <vlan> qos ingress rate-limit policer␣
˓→bandwidth
Maximum burst size of shaped traffic, a.k.a. CBS (Committed Burst Size), in bytes. The default value is set to
bandwidth / 80 to handle a burst of 100 ms at the targeted bandwidth. If not set or set to 0, the default value is
applied.
vrouter> show state vrf <vrf> interface vlan <vlan> qos ingress rate-limit policer␣
˓→burst
Maximum bandwidth of excess traffic, a.k.a. EIR (Excess Information Rate), in bps. 0 allows no excess traffic.
vrouter> show state vrf <vrf> interface vlan <vlan> qos ingress rate-limit policer␣
˓→excess-bandwidth
Maximum burst size of excess traffic, a.k.a. EBS (Excess Burst Size), in bytes. The default value is set to excess-
bandwidth / 80 to handle a burst of 100 ms at the targeted bandwidth. If not set or set to 0, the default value is
applied.
vrouter> show state vrf <vrf> interface vlan <vlan> qos ingress rate-limit policer␣
˓→excess-burst
vrouter> show state vrf <vrf> interface vlan <vlan> qos ingress rate-limit policer␣
˓→shared-policer
Number of packets passed (regular traffic that conforms to (bandwidth, burst) specification.
vrouter> show state vrf <vrf> interface vlan <vlan> qos ingress rate-limit policer␣
˓→stats pass-packets
Number of bytes passed (regular traffic that conforms to (bandwidth, burst) specification.
vrouter> show state vrf <vrf> interface vlan <vlan> qos ingress rate-limit policer␣
˓→stats pass-bytes
Number of excess packets passed (excess traffic that conforms to (excess-bandwidth, excess-burst) specification.
vrouter> show state vrf <vrf> interface vlan <vlan> qos ingress rate-limit policer␣
˓→stats pass-excess-packets
Number of excess bytes passed (excess traffic that conforms to (excess-bandwidth, excess-burst) specification.
vrouter> show state vrf <vrf> interface vlan <vlan> qos ingress rate-limit policer␣
˓→stats pass-excess-bytes
Number of packets dropped (traffic that does not conform to bandwidth or excess-bandwidth).
vrouter> show state vrf <vrf> interface vlan <vlan> qos ingress rate-limit policer␣
˓→stats drop-packets
Number of bytes dropped (traffic that does not conform to bandwidth or excess-bandwidth).
vrouter> show state vrf <vrf> interface vlan <vlan> qos ingress rate-limit policer␣
˓→stats drop-bytes
egress
vrouter running config# vrf <vrf> interface vlan <vlan> qos egress
rate-limit
vrouter running config# vrf <vrf> interface vlan <vlan> qos egress rate-limit
vrouter running config# vrf <vrf> interface vlan <vlan> qos egress rate-limit
vrouter running rate-limit# policer <leafref>
vrouter running config# vrf <vrf> interface vlan <vlan> qos egress rate-limit
vrouter running rate-limit# shared-policer <leafref>
Traffic policer.
Maximum bandwidth of regular traffic, a.k.a. CIR (Committed Information Rate), in bps. 0 allows no regular traffic.
vrouter> show state vrf <vrf> interface vlan <vlan> qos egress rate-limit policer␣
˓→bandwidth
Maximum burst size of shaped traffic, a.k.a. CBS (Committed Burst Size), in bytes. The default value is set to
bandwidth / 80 to handle a burst of 100 ms at the targeted bandwidth. If not set or set to 0, the default value is
applied.
vrouter> show state vrf <vrf> interface vlan <vlan> qos egress rate-limit policer burst
Maximum bandwidth of excess traffic, a.k.a. EIR (Excess Information Rate), in bps. 0 allows no excess traffic.
vrouter> show state vrf <vrf> interface vlan <vlan> qos egress rate-limit policer␣
˓→excess-bandwidth
Maximum burst size of excess traffic, a.k.a. EBS (Excess Burst Size), in bytes. The default value is set to excess-
bandwidth / 80 to handle a burst of 100 ms at the targeted bandwidth. If not set or set to 0, the default value is
applied.
vrouter> show state vrf <vrf> interface vlan <vlan> qos egress rate-limit policer␣
˓→excess-burst
vrouter> show state vrf <vrf> interface vlan <vlan> qos egress rate-limit policer␣
˓→shared-policer
Number of packets passed (regular traffic that conforms to (bandwidth, burst) specification.
vrouter> show state vrf <vrf> interface vlan <vlan> qos egress rate-limit policer␣
˓→stats pass-packets
Number of bytes passed (regular traffic that conforms to (bandwidth, burst) specification.
vrouter> show state vrf <vrf> interface vlan <vlan> qos egress rate-limit policer␣
˓→stats pass-bytes
Number of excess packets passed (excess traffic that conforms to (excess-bandwidth, excess-burst) specification.
vrouter> show state vrf <vrf> interface vlan <vlan> qos egress rate-limit policer␣
˓→stats pass-excess-packets
Number of excess bytes passed (excess traffic that conforms to (excess-bandwidth, excess-burst) specification.
vrouter> show state vrf <vrf> interface vlan <vlan> qos egress rate-limit policer␣
˓→stats pass-excess-bytes
Number of packets dropped (traffic that does not conform to bandwidth or excess-bandwidth).
vrouter> show state vrf <vrf> interface vlan <vlan> qos egress rate-limit policer␣
˓→stats drop-packets
Number of bytes dropped (traffic that does not conform to bandwidth or excess-bandwidth).
vrouter> show state vrf <vrf> interface vlan <vlan> qos egress rate-limit policer␣
˓→stats drop-bytes
The total number of octets received on the interface, including framing characters. Discontinuities in the value of
this counter can occur at re-initialization of the management system, and at other times as indicated by the value of
‘last-clear’.
vrouter> show state vrf <vrf> interface vlan <vlan> counters in-octets
The number of packets, delivered by this sub-layer to a higher (sub-)layer, that were not addressed to a multicast or
broadcast address at this sub-layer. Discontinuities in the value of this counter can occur at re-initialization of the
management system, and at other times as indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface vlan <vlan> counters in-unicast-pkts
The number of inbound packets that were chosen to be discarded even though no errors had been detected to prevent
their being deliverable to a higher-layer protocol. One possible reason for discarding such a packet could be to free
up buffer space. Discontinuities in the value of this counter can occur at re-initialization of the management system,
and at other times as indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface vlan <vlan> counters in-discards
For packet-oriented interfaces, the number of inbound packets that contained errors preventing them from being
deliverable to a higher- layer protocol. For character- oriented or fixed-length interfaces, the number of inbound
transmission units that contained errors preventing them from being deliverable to a higher-layer protocol. Discon-
tinuities in the value of this counter can occur at re- initialization of the management system, and at other times as
indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface vlan <vlan> counters in-errors
The total number of octets transmitted out of the interface, including framing characters. Discontinuities in the
value of this counter can occur at re-initialization of the management system, and at other times as indicated by the
value of ‘last-clear’.
vrouter> show state vrf <vrf> interface vlan <vlan> counters out-octets
The total number of packets that higher-level protocols requested be transmitted, and that were not addressed to a
multicast or broadcast address at this sub-layer, including those that were discarded or not sent. Discontinuities in
the value of this counter can occur at re- initialization of the management system, and at other times as indicated by
the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface vlan <vlan> counters out-unicast-pkts
The number of outbound packets that were chosen to be discarded even though no errors had been detected to
prevent their being transmitted. One possible reason for discarding such a packet could be to free up buffer space.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other
times as indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface vlan <vlan> counters out-discards
For packet-oriented interfaces, the number of outbound packets that could not be transmitted because of errors. For
character-oriented or fixed-length interfaces, the number of outbound transmission units that could not be transmitted
because of errors. Discontinuities in the value of this counter can occur at re-initialization of the management system,
and at other times as indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface vlan <vlan> counters out-errors
vxlan
mtu
promiscuous
description
enabled
Default value
true
vni (mandatory)
VNI Type definition representing VXLAN Segment ID / VXLAN Network Identifier value.
group
remote
local
The source address that should be used for the Vxlan tunnel. If none is specified an address of the link interface
will be used.
ttl
The time-to-live (or hop limit) that should be utilised for the IP packets used for the tunnel transport. If not set, the
ttl is inherited from the inner packet for IPv4 tunnels, and is 64 for IPv6 tunnels.
tos
link-interface
link-vrf
learning
Enable the registration of unknown source link layer addresses and IP addresses into the VxLAN forwarding
database.
Default value
true
gbp
Default value
false
dst
Default value
4789
System assigned number for each interface. Corresponds to ifIndex object in SNMP Interface MIB.
The desired state of the interface. In RFC 7223 this leaf has the same read semantics as ifAdminStatus. Here, it
reflects the administrative state as set by enabling or disabling the interface.
The current operational state of the interface. This leaf has the same semantics as ifOperStatus.
This timestamp indicates the time of the last state change of the interface (e.g., up-to-down transition). This corre-
sponds to the ifLastChange object in the standard interface MIB. The value is the timestamp in nanoseconds relative
to the Unix Epoch (Jan 1, 1970 00:00:00 UTC).
ethernet
mac-address
Assigns a MAC address to the Ethernet interface. If not specified, the corresponding operational state leaf is expected
to show the system-assigned MAC address.
MAC- An IEEE 802 unicast MAC address i.e. the second digit is an even number. Moreover the mac
ADDRESS address must not be 00:00:00:00:00:00.
ipv4
enabled
Controls whether IPv4 is enabled or disabled on this interface. When IPv4 is enabled, this interface is connected to
an IPv4 stack, and the interface can send and receive IPv4 packets.
Default value
true
address
peer
The IPv4 address of the remote endpoint for point to point interfaces.
peer PEER
The origin of this address, e.g., statically configured, assigned by DHCP, etc..
vrouter> show state vrf <vrf> interface vxlan <vxlan> ipv4 address <address> origin
neighbor
A list of mappings from IPv4 addresses to link-layer addresses. Entries in this list are used as static entries in the
ARP Cache.
link-layer-address (mandatory)
link-layer-address LINK-LAYER-ADDRESS
vrouter> show state vrf <vrf> interface vxlan <vxlan> ipv4 neighbor <neighbor> state
dhcp
vrouter running config# vrf <vrf> interface vxlan <vxlan> ipv4 dhcp
enabled
vrouter running config# vrf <vrf> interface vxlan <vxlan> ipv4 dhcp
vrouter running dhcp# enabled true|false
Default value
true
timeout
Time before deciding that it’s not going to be able to contact a server.
vrouter running config# vrf <vrf> interface vxlan <vxlan> ipv4 dhcp
vrouter running dhcp# timeout <uint32>
Default value
60
retry
vrouter running config# vrf <vrf> interface vxlan <vxlan> ipv4 dhcp
vrouter running dhcp# retry <uint32>
Default value
300
select-timeout
Time at which the client stops waiting for other offers from servers.
vrouter running config# vrf <vrf> interface vxlan <vxlan> ipv4 dhcp
vrouter running dhcp# select-timeout <uint32>
Default value
0
reboot
Time after trying to reacquire its old address before trying to discover a new address.
vrouter running config# vrf <vrf> interface vxlan <vxlan> ipv4 dhcp
vrouter running dhcp# reboot <uint32>
Default value
10
initial-interval
Time between the first attempt to reach a server and the second attempt to reach a server.
vrouter running config# vrf <vrf> interface vxlan <vxlan> ipv4 dhcp
vrouter running dhcp# initial-interval <uint32>
Default value
10
dhcp-lease-time
vrouter running config# vrf <vrf> interface vxlan <vxlan> ipv4 dhcp
vrouter running dhcp# dhcp-lease-time <uint32>
Default value
7200
dhcp-client-identifier-ascii
vrouter running config# vrf <vrf> interface vxlan <vxlan> ipv4 dhcp
vrouter running dhcp# dhcp-client-identifier-ascii <string>
dhcp-client-identifier-hexa
vrouter running config# vrf <vrf> interface vxlan <vxlan> ipv4 dhcp
vrouter running dhcp# dhcp-client-identifier-hexa <string>
host-name
vrouter running config# vrf <vrf> interface vxlan <vxlan> ipv4 dhcp
vrouter running dhcp# host-name <string>
request
DHCP requests.
vrouter running config# vrf <vrf> interface vxlan <vxlan> ipv4 dhcp
vrouter running dhcp# request REQUEST
Default value
subnet-mask
broadcast-address
time-offset
routers
domain-name
domain-search
domain-name-servers
host-name
nis-domain
nis-servers
ntp-servers
interface-mtu
Current lease.
vrouter> show state vrf <vrf> interface vxlan <vxlan> ipv4 dhcp current-lease fixed-
˓→address
Time at which the client should begin trying to contact its server to renew its lease.
vrouter> show state vrf <vrf> interface vxlan <vxlan> ipv4 dhcp current-lease renew
Time at which the client should begin to try to contact any dhcp server to renew its lease.
vrouter> show state vrf <vrf> interface vxlan <vxlan> ipv4 dhcp current-lease rebind
Time at which the client must stop using a lease if it has not been able to renew it.
vrouter> show state vrf <vrf> interface vxlan <vxlan> ipv4 dhcp current-lease expire
fdb
link-interface
The outgoing interface for the VXLAN device driver to reach the remote VXLAN tunnel endpoint.
link-interface LINK-INTERFACE
port
The UDP destination PORT number to use to connect to the remote VXLAN tunnel endpoint (default: the VXLAN
dst).
port PORT
PORT A 16-bit port number used by a transport protocol such as TCP or UDP.
vni
The VXLAN VNI Network Identifier (or VXLAN Segment ID) to use to connect to the remote VXLAN tunnel
endpoint (default: the VXLAN vni).
vni VNI
VNI Type definition representing VXLAN Segment ID / VXLAN Network Identifier value.
vrouter> show state vrf <vrf> interface vxlan <vxlan> ipv4 fdb link-layer-address
˓→<link-layer-address> ip <ip> state
ipv6
enabled
Controls whether IPv6 is enabled or disabled on this interface. When IPv6 is enabled, this interface is connected to
an IPv6 stack, and the interface can send and receive IPv6 packets.
Default value
true
address
peer
The IPv6 address of the remote endpoint for point to point interfaces.
peer PEER
vrouter> show state vrf <vrf> interface vxlan <vxlan> ipv6 address <address> origin
The status of an address. Most of the states correspond to states from the IPv6 Stateless Address Autoconfiguration
protocol.
vrouter> show state vrf <vrf> interface vxlan <vxlan> ipv6 address <address> status
neighbor
link-layer-address (mandatory)
link-layer-address LINK-LAYER-ADDRESS
vrouter> show state vrf <vrf> interface vxlan <vxlan> ipv6 neighbor <neighbor> router
vrouter> show state vrf <vrf> interface vxlan <vxlan> ipv6 neighbor <neighbor> state
fdb
link-interface
The outgoing interface for the VXLAN device driver to reach the remote VXLAN tunnel endpoint.
link-interface LINK-INTERFACE
port
The UDP destination PORT number to use to connect to the remote VXLAN tunnel endpoint (default: the VXLAN
dst).
port PORT
PORT A 16-bit port number used by a transport protocol such as TCP or UDP.
vni
The VXLAN VNI Network Identifier (or VXLAN Segment ID) to use to connect to the remote VXLAN tunnel
endpoint (default: the VXLAN vni).
vni VNI
VNI Type definition representing VXLAN Segment ID / VXLAN Network Identifier value.
vrouter> show state vrf <vrf> interface vxlan <vxlan> ipv6 fdb link-layer-address
˓→<link-layer-address> ip <ip> state
network-stack
ipv4
IPv4 parameters.
vrouter running config# vrf <vrf> interface vxlan <vxlan> network-stack ipv4
send-redirects
vrouter running config# vrf <vrf> interface vxlan <vxlan> network-stack ipv4
vrouter running ipv4# send-redirects true|false
accept-redirects
Accept redirect when acting as a host. It is always disabled when acting as a router. Must be activated at vrf or
system level too to be activated.
vrouter running config# vrf <vrf> interface vxlan <vxlan> network-stack ipv4
vrouter running ipv4# accept-redirects true|false
accept-source-route
Accept packets with source route option. Must be activated at vrf or system level too to be activated.
vrouter running config# vrf <vrf> interface vxlan <vxlan> network-stack ipv4
vrouter running ipv4# accept-source-route true|false
arp-announce
Define different restriction levels for announcing the local source IP address from IP packets in ARP requests sent
on interface. Increasing the restriction level gives more chance for receiving answer from the resolved target while
decreasing the level announces more valid sender’s information.
vrouter running config# vrf <vrf> interface vxlan <vxlan> network-stack ipv4
vrouter running ipv4# arp-announce ARP-ANNOUNCE
Description
ARP-ANNOUNCE
val-
ues
any Use any local address, configured on any interface.
avoid- Try to avoid local addresses that are not in the target’s subnet for this interface. This mode is useful when
not- target hosts reachable via this interface require the source IP address in ARP requests to be part of their
in- logical network configured on the receiving interface. When we generate the request we will check all our
subnet subnets that include the target IP and will preserve the source address if it is from such subnet. If there is
no such subnet we select source address according to the rules for level 2, ‘best-local’.
best- Always use the best local address for this target. In this mode we ignore the source address in the IP packet
local and try to select local address that we prefer for talks with the target host. Such local address is selected
by looking for primary IP addresses on all our subnets on the outgoing interface that include the target
IP address. If no suitable local address is found we select the first local address we have on the outgoing
interface or on all other interfaces, with the hope we will receive reply for our request and even sometimes
no matter the source IP address we announce.
arp-filter
Allows to have multiple network interfaces on the same subnet, and have the ARPs for each interface be answered
based on whether or not the kernel would route a packet from the ARP’d IP out that interface (therefore you must
use source based routing for this to work). In other words it allows control of which cards (usually 1) will respond
to an arp request.
vrouter running config# vrf <vrf> interface vxlan <vxlan> network-stack ipv4
vrouter running ipv4# arp-filter true|false
arp-ignore
Define different modes for sending replies in response to received ARP requests that resolve local target IP addresses.
vrouter running config# vrf <vrf> interface vxlan <vxlan> network-stack ipv4
vrouter running ipv4# arp-ignore ARP-IGNORE
ARP-IGNORE Description
values
any Reply for any local target IP address, configured on any interface.
check- Reply only if the target IP address is local address configured on the incoming interface.
interface
check- Reply only if the target IP address is local address configured on the incoming interface and
interface- both with the sender’s IP address are part from same subnet on this interface.
and-subnet
ignore-scope Do not reply for local addresses configured with scope host, only resolutions for global and
link addresses are replied.
ignore-all Do not reply for all local addresses.
log-invalid-addresses
vrouter running config# vrf <vrf> interface vxlan <vxlan> network-stack ipv4
vrouter running ipv4# log-invalid-addresses true|false
ipv6
IPv6 parameters.
vrouter running config# vrf <vrf> interface vxlan <vxlan> network-stack ipv6
autoconfiguration
vrouter running config# vrf <vrf> interface vxlan <vxlan> network-stack ipv6
vrouter running ipv6# autoconfiguration true|false
accept-router-advert
vrouter running config# vrf <vrf> interface vxlan <vxlan> network-stack ipv6
vrouter running ipv6# accept-router-advert ACCEPT-ROUTER-ADVERT
accept-redirects
Accept redirect when acting as a host. It is always disabled when acting as a router.
vrouter running config# vrf <vrf> interface vxlan <vxlan> network-stack ipv6
vrouter running ipv6# accept-redirects true|false
accept-source-route
vrouter running config# vrf <vrf> interface vxlan <vxlan> network-stack ipv6
vrouter running ipv6# accept-source-route true|false
router-solicitations
vrouter running config# vrf <vrf> interface vxlan <vxlan> network-stack ipv6
vrouter running ipv6# router-solicitations <int16>
use-temporary-addresses
Preference for Privacy Extensions (RFC4941). Not applied to point-to- point and loopback devices (always 0).
vrouter running config# vrf <vrf> interface vxlan <vxlan> network-stack ipv6
vrouter running ipv6# use-temporary-addresses USE-TEMPORARY-ADDRESSES
USE-TEMPORARY-ADDRESSESDescription
values
never Disable Privacy Extensions, i.e. use the public address, subnet prefix/interface id,
where interface id is always the same.
prefer-public-addresses Enable Privacy Extensions, but prefer public addresses over temporary addresses.
always Enable Privacy Extensions and prefer temporary addresses over public addresses.
src-range
<uint16>
Default value
49152
<uint16>
Default value
65535
qos
QoS configuration.
ingress
vrouter running config# vrf <vrf> interface vxlan <vxlan> qos ingress
rate-limit
vrouter running config# vrf <vrf> interface vxlan <vxlan> qos ingress rate-limit
vrouter running config# vrf <vrf> interface vxlan <vxlan> qos ingress rate-limit
vrouter running rate-limit# policer <leafref>
vrouter running config# vrf <vrf> interface vxlan <vxlan> qos ingress rate-limit
vrouter running rate-limit# shared-policer <leafref>
Traffic policer.
Maximum bandwidth of regular traffic, a.k.a. CIR (Committed Information Rate), in bps. 0 allows no regular traffic.
vrouter> show state vrf <vrf> interface vxlan <vxlan> qos ingress rate-limit policer␣
˓→bandwidth
Maximum burst size of shaped traffic, a.k.a. CBS (Committed Burst Size), in bytes. The default value is set to
bandwidth / 80 to handle a burst of 100 ms at the targeted bandwidth. If not set or set to 0, the default value is
applied.
vrouter> show state vrf <vrf> interface vxlan <vxlan> qos ingress rate-limit policer␣
˓→burst
Maximum bandwidth of excess traffic, a.k.a. EIR (Excess Information Rate), in bps. 0 allows no excess traffic.
vrouter> show state vrf <vrf> interface vxlan <vxlan> qos ingress rate-limit policer␣
˓→excess-bandwidth
Maximum burst size of excess traffic, a.k.a. EBS (Excess Burst Size), in bytes. The default value is set to excess-
bandwidth / 80 to handle a burst of 100 ms at the targeted bandwidth. If not set or set to 0, the default value is
applied.
vrouter> show state vrf <vrf> interface vxlan <vxlan> qos ingress rate-limit policer␣
˓→excess-burst
vrouter> show state vrf <vrf> interface vxlan <vxlan> qos ingress rate-limit policer␣
˓→shared-policer
Number of packets passed (regular traffic that conforms to (bandwidth, burst) specification.
vrouter> show state vrf <vrf> interface vxlan <vxlan> qos ingress rate-limit policer␣
˓→stats pass-packets
Number of bytes passed (regular traffic that conforms to (bandwidth, burst) specification.
vrouter> show state vrf <vrf> interface vxlan <vxlan> qos ingress rate-limit policer␣
˓→stats pass-bytes
Number of excess packets passed (excess traffic that conforms to (excess-bandwidth, excess-burst) specification.
vrouter> show state vrf <vrf> interface vxlan <vxlan> qos ingress rate-limit policer␣
˓→stats pass-excess-packets
Number of excess bytes passed (excess traffic that conforms to (excess-bandwidth, excess-burst) specification.
vrouter> show state vrf <vrf> interface vxlan <vxlan> qos ingress rate-limit policer␣
˓→stats pass-excess-bytes
Number of packets dropped (traffic that does not conform to bandwidth or excess-bandwidth).
vrouter> show state vrf <vrf> interface vxlan <vxlan> qos ingress rate-limit policer␣
˓→stats drop-packets
Number of bytes dropped (traffic that does not conform to bandwidth or excess-bandwidth).
vrouter> show state vrf <vrf> interface vxlan <vxlan> qos ingress rate-limit policer␣
˓→stats drop-bytes
egress
vrouter running config# vrf <vrf> interface vxlan <vxlan> qos egress
rate-limit
vrouter running config# vrf <vrf> interface vxlan <vxlan> qos egress rate-limit
vrouter running config# vrf <vrf> interface vxlan <vxlan> qos egress rate-limit
vrouter running rate-limit# policer <leafref>
vrouter running config# vrf <vrf> interface vxlan <vxlan> qos egress rate-limit
vrouter running rate-limit# shared-policer <leafref>
Traffic policer.
Maximum bandwidth of regular traffic, a.k.a. CIR (Committed Information Rate), in bps. 0 allows no regular traffic.
vrouter> show state vrf <vrf> interface vxlan <vxlan> qos egress rate-limit policer␣
˓→bandwidth
Maximum burst size of shaped traffic, a.k.a. CBS (Committed Burst Size), in bytes. The default value is set to
bandwidth / 80 to handle a burst of 100 ms at the targeted bandwidth. If not set or set to 0, the default value is
applied.
vrouter> show state vrf <vrf> interface vxlan <vxlan> qos egress rate-limit policer␣
˓→burst
Maximum bandwidth of excess traffic, a.k.a. EIR (Excess Information Rate), in bps. 0 allows no excess traffic.
vrouter> show state vrf <vrf> interface vxlan <vxlan> qos egress rate-limit policer␣
˓→excess-bandwidth
Maximum burst size of excess traffic, a.k.a. EBS (Excess Burst Size), in bytes. The default value is set to excess-
bandwidth / 80 to handle a burst of 100 ms at the targeted bandwidth. If not set or set to 0, the default value is
applied.
vrouter> show state vrf <vrf> interface vxlan <vxlan> qos egress rate-limit policer␣
˓→excess-burst
vrouter> show state vrf <vrf> interface vxlan <vxlan> qos egress rate-limit policer␣
˓→shared-policer
Number of packets passed (regular traffic that conforms to (bandwidth, burst) specification.
vrouter> show state vrf <vrf> interface vxlan <vxlan> qos egress rate-limit policer␣
˓→stats pass-packets
Number of bytes passed (regular traffic that conforms to (bandwidth, burst) specification.
vrouter> show state vrf <vrf> interface vxlan <vxlan> qos egress rate-limit policer␣
˓→stats pass-bytes
Number of excess packets passed (excess traffic that conforms to (excess-bandwidth, excess-burst) specification.
vrouter> show state vrf <vrf> interface vxlan <vxlan> qos egress rate-limit policer␣
˓→stats pass-excess-packets
Number of excess bytes passed (excess traffic that conforms to (excess-bandwidth, excess-burst) specification.
vrouter> show state vrf <vrf> interface vxlan <vxlan> qos egress rate-limit policer␣
˓→stats pass-excess-bytes
Number of packets dropped (traffic that does not conform to bandwidth or excess-bandwidth).
vrouter> show state vrf <vrf> interface vxlan <vxlan> qos egress rate-limit policer␣
˓→stats drop-packets
Number of bytes dropped (traffic that does not conform to bandwidth or excess-bandwidth).
vrouter> show state vrf <vrf> interface vxlan <vxlan> qos egress rate-limit policer␣
˓→stats drop-bytes
The total number of octets received on the interface, including framing characters. Discontinuities in the value of
this counter can occur at re-initialization of the management system, and at other times as indicated by the value of
‘last-clear’.
vrouter> show state vrf <vrf> interface vxlan <vxlan> counters in-octets
The number of packets, delivered by this sub-layer to a higher (sub-)layer, that were not addressed to a multicast or
broadcast address at this sub-layer. Discontinuities in the value of this counter can occur at re-initialization of the
management system, and at other times as indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface vxlan <vxlan> counters in-unicast-pkts
The number of inbound packets that were chosen to be discarded even though no errors had been detected to prevent
their being deliverable to a higher-layer protocol. One possible reason for discarding such a packet could be to free
up buffer space. Discontinuities in the value of this counter can occur at re-initialization of the management system,
and at other times as indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface vxlan <vxlan> counters in-discards
For packet-oriented interfaces, the number of inbound packets that contained errors preventing them from being
deliverable to a higher- layer protocol. For character- oriented or fixed-length interfaces, the number of inbound
transmission units that contained errors preventing them from being deliverable to a higher-layer protocol. Discon-
tinuities in the value of this counter can occur at re- initialization of the management system, and at other times as
indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface vxlan <vxlan> counters in-errors
The total number of octets transmitted out of the interface, including framing characters. Discontinuities in the
value of this counter can occur at re-initialization of the management system, and at other times as indicated by the
value of ‘last-clear’.
vrouter> show state vrf <vrf> interface vxlan <vxlan> counters out-octets
The total number of packets that higher-level protocols requested be transmitted, and that were not addressed to a
multicast or broadcast address at this sub-layer, including those that were discarded or not sent. Discontinuities in
the value of this counter can occur at re- initialization of the management system, and at other times as indicated by
the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface vxlan <vxlan> counters out-unicast-pkts
The number of outbound packets that were chosen to be discarded even though no errors had been detected to
prevent their being transmitted. One possible reason for discarding such a packet could be to free up buffer space.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other
times as indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface vxlan <vxlan> counters out-discards
For packet-oriented interfaces, the number of outbound packets that could not be transmitted because of errors. For
character-oriented or fixed-length interfaces, the number of outbound transmission units that could not be transmitted
because of errors. Discontinuities in the value of this counter can occur at re-initialization of the management system,
and at other times as indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface vxlan <vxlan> counters out-errors
xvrf
mtu
promiscuous
description
enabled
Default value
true
link-interface (mandatory)
link-vrf (mandatory)
System assigned number for each interface. Corresponds to ifIndex object in SNMP Interface MIB.
The desired state of the interface. In RFC 7223 this leaf has the same read semantics as ifAdminStatus. Here, it
reflects the administrative state as set by enabling or disabling the interface.
The current operational state of the interface. This leaf has the same semantics as ifOperStatus.
This timestamp indicates the time of the last state change of the interface (e.g., up-to-down transition). This corre-
sponds to the ifLastChange object in the standard interface MIB. The value is the timestamp in nanoseconds relative
to the Unix Epoch (Jan 1, 1970 00:00:00 UTC).
qos
QoS configuration.
ingress
vrouter running config# vrf <vrf> interface xvrf <xvrf> qos ingress
rate-limit
vrouter running config# vrf <vrf> interface xvrf <xvrf> qos ingress rate-limit
vrouter running config# vrf <vrf> interface xvrf <xvrf> qos ingress rate-limit
vrouter running rate-limit# policer <leafref>
vrouter running config# vrf <vrf> interface xvrf <xvrf> qos ingress rate-limit
vrouter running rate-limit# shared-policer <leafref>
Traffic policer.
Maximum bandwidth of regular traffic, a.k.a. CIR (Committed Information Rate), in bps. 0 allows no regular traffic.
vrouter> show state vrf <vrf> interface xvrf <xvrf> qos ingress rate-limit policer␣
˓→bandwidth
Maximum burst size of shaped traffic, a.k.a. CBS (Committed Burst Size), in bytes. The default value is set to
bandwidth / 80 to handle a burst of 100 ms at the targeted bandwidth. If not set or set to 0, the default value is
applied.
vrouter> show state vrf <vrf> interface xvrf <xvrf> qos ingress rate-limit policer␣
˓→burst
Maximum bandwidth of excess traffic, a.k.a. EIR (Excess Information Rate), in bps. 0 allows no excess traffic.
vrouter> show state vrf <vrf> interface xvrf <xvrf> qos ingress rate-limit policer␣
˓→excess-bandwidth
Maximum burst size of excess traffic, a.k.a. EBS (Excess Burst Size), in bytes. The default value is set to excess-
bandwidth / 80 to handle a burst of 100 ms at the targeted bandwidth. If not set or set to 0, the default value is
applied.
vrouter> show state vrf <vrf> interface xvrf <xvrf> qos ingress rate-limit policer␣
˓→excess-burst
vrouter> show state vrf <vrf> interface xvrf <xvrf> qos ingress rate-limit policer␣
˓→shared-policer
Number of packets passed (regular traffic that conforms to (bandwidth, burst) specification.
vrouter> show state vrf <vrf> interface xvrf <xvrf> qos ingress rate-limit policer␣
˓→stats pass-packets
Number of bytes passed (regular traffic that conforms to (bandwidth, burst) specification.
vrouter> show state vrf <vrf> interface xvrf <xvrf> qos ingress rate-limit policer␣
˓→stats pass-bytes
Number of excess packets passed (excess traffic that conforms to (excess-bandwidth, excess-burst) specification.
vrouter> show state vrf <vrf> interface xvrf <xvrf> qos ingress rate-limit policer␣
˓→stats pass-excess-packets
Number of excess bytes passed (excess traffic that conforms to (excess-bandwidth, excess-burst) specification.
vrouter> show state vrf <vrf> interface xvrf <xvrf> qos ingress rate-limit policer␣
˓→stats pass-excess-bytes
Number of packets dropped (traffic that does not conform to bandwidth or excess-bandwidth).
vrouter> show state vrf <vrf> interface xvrf <xvrf> qos ingress rate-limit policer␣
˓→stats drop-packets
Number of bytes dropped (traffic that does not conform to bandwidth or excess-bandwidth).
vrouter> show state vrf <vrf> interface xvrf <xvrf> qos ingress rate-limit policer␣
˓→stats drop-bytes
egress
vrouter running config# vrf <vrf> interface xvrf <xvrf> qos egress
rate-limit
vrouter running config# vrf <vrf> interface xvrf <xvrf> qos egress rate-limit
vrouter running config# vrf <vrf> interface xvrf <xvrf> qos egress rate-limit
vrouter running rate-limit# policer <leafref>
vrouter running config# vrf <vrf> interface xvrf <xvrf> qos egress rate-limit
vrouter running rate-limit# shared-policer <leafref>
Traffic policer.
Maximum bandwidth of regular traffic, a.k.a. CIR (Committed Information Rate), in bps. 0 allows no regular traffic.
vrouter> show state vrf <vrf> interface xvrf <xvrf> qos egress rate-limit policer␣
˓→bandwidth
Maximum burst size of shaped traffic, a.k.a. CBS (Committed Burst Size), in bytes. The default value is set to
bandwidth / 80 to handle a burst of 100 ms at the targeted bandwidth. If not set or set to 0, the default value is
applied.
vrouter> show state vrf <vrf> interface xvrf <xvrf> qos egress rate-limit policer burst
Maximum bandwidth of excess traffic, a.k.a. EIR (Excess Information Rate), in bps. 0 allows no excess traffic.
vrouter> show state vrf <vrf> interface xvrf <xvrf> qos egress rate-limit policer␣
˓→excess-bandwidth
Maximum burst size of excess traffic, a.k.a. EBS (Excess Burst Size), in bytes. The default value is set to excess-
bandwidth / 80 to handle a burst of 100 ms at the targeted bandwidth. If not set or set to 0, the default value is
applied.
vrouter> show state vrf <vrf> interface xvrf <xvrf> qos egress rate-limit policer␣
˓→excess-burst
vrouter> show state vrf <vrf> interface xvrf <xvrf> qos egress rate-limit policer␣
˓→shared-policer
Number of packets passed (regular traffic that conforms to (bandwidth, burst) specification.
vrouter> show state vrf <vrf> interface xvrf <xvrf> qos egress rate-limit policer␣
˓→stats pass-packets
Number of bytes passed (regular traffic that conforms to (bandwidth, burst) specification.
vrouter> show state vrf <vrf> interface xvrf <xvrf> qos egress rate-limit policer␣
˓→stats pass-bytes
Number of excess packets passed (excess traffic that conforms to (excess-bandwidth, excess-burst) specification.
vrouter> show state vrf <vrf> interface xvrf <xvrf> qos egress rate-limit policer␣
˓→stats pass-excess-packets
Number of excess bytes passed (excess traffic that conforms to (excess-bandwidth, excess-burst) specification.
vrouter> show state vrf <vrf> interface xvrf <xvrf> qos egress rate-limit policer␣
˓→stats pass-excess-bytes
Number of packets dropped (traffic that does not conform to bandwidth or excess-bandwidth).
vrouter> show state vrf <vrf> interface xvrf <xvrf> qos egress rate-limit policer␣
˓→stats drop-packets
Number of bytes dropped (traffic that does not conform to bandwidth or excess-bandwidth).
vrouter> show state vrf <vrf> interface xvrf <xvrf> qos egress rate-limit policer␣
˓→stats drop-bytes
The total number of octets received on the interface, including framing characters. Discontinuities in the value of
this counter can occur at re-initialization of the management system, and at other times as indicated by the value of
‘last-clear’.
vrouter> show state vrf <vrf> interface xvrf <xvrf> counters in-octets
The number of packets, delivered by this sub-layer to a higher (sub-)layer, that were not addressed to a multicast or
broadcast address at this sub-layer. Discontinuities in the value of this counter can occur at re-initialization of the
management system, and at other times as indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface xvrf <xvrf> counters in-unicast-pkts
The number of inbound packets that were chosen to be discarded even though no errors had been detected to prevent
their being deliverable to a higher-layer protocol. One possible reason for discarding such a packet could be to free
up buffer space. Discontinuities in the value of this counter can occur at re-initialization of the management system,
and at other times as indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface xvrf <xvrf> counters in-discards
For packet-oriented interfaces, the number of inbound packets that contained errors preventing them from being
deliverable to a higher- layer protocol. For character- oriented or fixed-length interfaces, the number of inbound
transmission units that contained errors preventing them from being deliverable to a higher-layer protocol. Discon-
tinuities in the value of this counter can occur at re- initialization of the management system, and at other times as
indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface xvrf <xvrf> counters in-errors
The total number of octets transmitted out of the interface, including framing characters. Discontinuities in the
value of this counter can occur at re-initialization of the management system, and at other times as indicated by the
value of ‘last-clear’.
vrouter> show state vrf <vrf> interface xvrf <xvrf> counters out-octets
The total number of packets that higher-level protocols requested be transmitted, and that were not addressed to a
multicast or broadcast address at this sub-layer, including those that were discarded or not sent. Discontinuities in
the value of this counter can occur at re- initialization of the management system, and at other times as indicated by
the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface xvrf <xvrf> counters out-unicast-pkts
The number of outbound packets that were chosen to be discarded even though no errors had been detected to
prevent their being transmitted. One possible reason for discarding such a packet could be to free up buffer space.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other
times as indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface xvrf <xvrf> counters out-discards
For packet-oriented interfaces, the number of outbound packets that could not be transmitted because of errors. For
character-oriented or fixed-length interfaces, the number of outbound transmission units that could not be transmitted
because of errors. Discontinuities in the value of this counter can occur at re-initialization of the management system,
and at other times as indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface xvrf <xvrf> counters out-errors
3.2.24 qos
QoS configuration.
Default value
0xFFFFFFFF
Maximum bandwidth of regular traffic, a.k.a. CIR (Committed Information Rate), in bps. 0 allows no regular traffic.
BAND- Rate in bits per second. K/M/G/T multipliers are supported. Example: 1G stands for
WIDTH 1000000000 bps.
Maximum burst size of shaped traffic, a.k.a. CBS (Committed Burst Size), in bytes. The default value is set to
bandwidth / 80 to handle a burst of 100 ms at the targeted bandwidth. If not set or set to 0, the default value is
applied.
BURST Burst size in bytes. K/M/G/T multipliers are supported. Example: 2K stands for 2000 bytes.
Maximum bandwidth of excess traffic, a.k.a. EIR (Excess Information Rate), in bps. 0 allows no excess traffic.
EXCESS- Rate in bits per second. K/M/G/T multipliers are supported. Example: 1G stands for
BANDWIDTH 1000000000 bps.
Default value
0
Maximum burst size of excess traffic, a.k.a. EBS (Excess Burst Size), in bytes. The default value is set to excess-
bandwidth / 80 to handle a burst of 100 ms at the targeted bandwidth. If not set or set to 0, the default value is
applied.
EXCESS- Burst size in bytes. K/M/G/T multipliers are supported. Example: 2K stands for 2000 bytes.
BURST
shared-policer
Maximum bandwidth of regular traffic, a.k.a. CIR (Committed Information Rate), in bps. 0 allows no regular traffic.
Maximum burst size of shaped traffic, a.k.a. CBS (Committed Burst Size), in bytes. The default value is set to
bandwidth / 80 to handle a burst of 100 ms at the targeted bandwidth. If not set or set to 0, the default value is
applied.
Maximum bandwidth of excess traffic, a.k.a. EIR (Excess Information Rate), in bps. 0 allows no excess traffic.
Maximum burst size of excess traffic, a.k.a. EBS (Excess Burst Size), in bytes. The default value is set to excess-
bandwidth / 80 to handle a burst of 100 ms at the targeted bandwidth. If not set or set to 0, the default value is
applied.
Number of packets passed (regular traffic that conforms to (bandwidth, burst) specification.
Number of bytes passed (regular traffic that conforms to (bandwidth, burst) specification.
Number of excess packets passed (excess traffic that conforms to (excess-bandwidth, excess-burst) specification.
Number of excess bytes passed (excess traffic that conforms to (excess-bandwidth, excess-burst) specification.
Number of packets dropped (traffic that does not conform to bandwidth or excess-bandwidth).
Number of bytes dropped (traffic that does not conform to bandwidth or excess-bandwidth).
List of shapers.
BAND- Rate in bits per second. K/M/G/T multipliers are supported. Example: 1G stands for
WIDTH 1000000000 bps.
Maximum burst size of shaped traffic. The default value is set to bandwidth / 80 to handle a burst of 100 ms at the
targeted bandwidth. If not set or set to 0, the default value is applied.
BURST Burst size in bytes. K/M/G/T multipliers are supported. Example: 2K stands for 2000 bytes.
Default value
0
Number of packets that can be saved in the delay queue. If a scheduler is also configured on the interface, this value
is not used, the queues of the scheduler are used as delay queues. The value is rounded up to the nearest power of 2.
Default value
256
List of schedulers.
pq (config only)
Default value
256
Default value
256
Default value
1500
Default value
low
cp (config only)
Whether this class relates to critical control plane traffic. If unset, match any traffic. If true, only match critical
control plane traffic. If false, do not match critical control plane traffic.
3.2.25 vrrp
global
enabled
Default value
true
router-id
Default value
router
traps-enabled
Default value
false
vrrp-startup-delay
Delay in seconds before vrrp instances start up after keepalived starts. Recommended value is 30 when at least one
of the vrrp instance runs on top of lag interfaces.
Default value
0
group
instance
List of VRRP instances in this group. All instances of a same group share their state.
notify-ha-group
track-group
Track a group in another vrf and reduce our priority when the tracked group is in fault state.
priority-penalty
The value that will be deduced from our priority when this group is in fault state. Choose this value so that (master
priority - value) < backup priority.
priority-penalty <uint8>
Default value
253
interface
mtu
promiscuous
description
enabled
Default value
true
version
Default value
2
link-interface (mandatory)
garp-delay
Delay for the second set of gratuitous ARP after transition to master state.
Default value
5
use-vmac
If true, create and associate the virtual address to a vmac interface for this VRRP instance with a VRRP standard
MAC address.
Default value
true
vmac-xmit-base
If true, send and receive VRRP messages from bound interface instead of VMAC interface. It requires use-vmac to
be set to true.
Default value
false
vrid (mandatory)
Virtual router identifier, used to differentiate multiple VRRP instances bound to the same interface.
priority
Specifies the sending VRRP interface’s priority for the virtual router. The higher value among interfaces with the
same router id will be elected as master.
Default value
100
init-state
Default value
backup
preempt
If true, the VRRP instance becomes master when lower priority advertisements are received from the other router.
For this to work, the initial state of this entry must be backup.
Default value
true
preempt-delay
Additional delay the router waits before preempting the master state after receiving a lower priority advertisements
from another node. A value of 0 does not mean immediate switchover, as it is still delayed by Master_Down_Interval.
Default value
0
advertisement-interval
Default value
1000
track-link-interface
If false, the VRRP instance (and its group if any) does not go to fault state if the link-interface state goes down. Set
to false to prevent a broken ha link from causing a fault state on both nodes.
Default value
true
track-interface
List of tracked interfaces. The VRRP instance (and its group if any) goes to fault state if one of the tracked interfaces
goes down.
track
A tracker name. The VRRP instance (and its group if any) goes to fault state if the tracker is down.
track-fast-path
If true, the VRRP instance (and its group if any) goes to fault state if fast path state does not match the configuration.
Default value
false
notify-ha-group
System assigned number for each interface. Corresponds to ifIndex object in SNMP Interface MIB.
The desired state of the interface. In RFC 7223 this leaf has the same read semantics as ifAdminStatus. Here, it
reflects the administrative state as set by enabling or disabling the interface.
The current operational state of the interface. This leaf has the same semantics as ifOperStatus.
This timestamp indicates the time of the last state change of the interface (e.g., up-to-down transition). This corre-
sponds to the ifLastChange object in the standard interface MIB. The value is the timestamp in nanoseconds relative
to the Unix Epoch (Jan 1, 1970 00:00:00 UTC).
network-stack
ipv4
IPv4 parameters.
vrouter running config# vrf <vrf> interface vrrp <vrrp> network-stack ipv4
send-redirects
vrouter running config# vrf <vrf> interface vrrp <vrrp> network-stack ipv4
vrouter running ipv4# send-redirects true|false
accept-redirects
Accept redirect when acting as a host. It is always disabled when acting as a router. Must be activated at vrf or
system level too to be activated.
vrouter running config# vrf <vrf> interface vrrp <vrrp> network-stack ipv4
vrouter running ipv4# accept-redirects true|false
accept-source-route
Accept packets with source route option. Must be activated at vrf or system level too to be activated.
vrouter running config# vrf <vrf> interface vrrp <vrrp> network-stack ipv4
vrouter running ipv4# accept-source-route true|false
arp-announce
Define different restriction levels for announcing the local source IP address from IP packets in ARP requests sent
on interface. Increasing the restriction level gives more chance for receiving answer from the resolved target while
decreasing the level announces more valid sender’s information.
vrouter running config# vrf <vrf> interface vrrp <vrrp> network-stack ipv4
vrouter running ipv4# arp-announce ARP-ANNOUNCE
Description
ARP-ANNOUNCE
val-
ues
any Use any local address, configured on any interface.
avoid- Try to avoid local addresses that are not in the target’s subnet for this interface. This mode is useful when
not- target hosts reachable via this interface require the source IP address in ARP requests to be part of their
in- logical network configured on the receiving interface. When we generate the request we will check all our
subnet subnets that include the target IP and will preserve the source address if it is from such subnet. If there is
no such subnet we select source address according to the rules for level 2, ‘best-local’.
best- Always use the best local address for this target. In this mode we ignore the source address in the IP packet
local and try to select local address that we prefer for talks with the target host. Such local address is selected
by looking for primary IP addresses on all our subnets on the outgoing interface that include the target
IP address. If no suitable local address is found we select the first local address we have on the outgoing
interface or on all other interfaces, with the hope we will receive reply for our request and even sometimes
no matter the source IP address we announce.
arp-filter
Allows to have multiple network interfaces on the same subnet, and have the ARPs for each interface be answered
based on whether or not the kernel would route a packet from the ARP’d IP out that interface (therefore you must
use source based routing for this to work). In other words it allows control of which cards (usually 1) will respond
to an arp request.
vrouter running config# vrf <vrf> interface vrrp <vrrp> network-stack ipv4
vrouter running ipv4# arp-filter true|false
arp-ignore
Define different modes for sending replies in response to received ARP requests that resolve local target IP addresses.
vrouter running config# vrf <vrf> interface vrrp <vrrp> network-stack ipv4
vrouter running ipv4# arp-ignore ARP-IGNORE
ARP-IGNORE Description
values
any Reply for any local target IP address, configured on any interface.
check- Reply only if the target IP address is local address configured on the incoming interface.
interface
check- Reply only if the target IP address is local address configured on the incoming interface and
interface- both with the sender’s IP address are part from same subnet on this interface.
and-subnet
ignore-scope Do not reply for local addresses configured with scope host, only resolutions for global and
link addresses are replied.
ignore-all Do not reply for all local addresses.
log-invalid-addresses
vrouter running config# vrf <vrf> interface vrrp <vrrp> network-stack ipv4
vrouter running ipv4# log-invalid-addresses true|false
ipv6
IPv6 parameters.
vrouter running config# vrf <vrf> interface vrrp <vrrp> network-stack ipv6
autoconfiguration
vrouter running config# vrf <vrf> interface vrrp <vrrp> network-stack ipv6
vrouter running ipv6# autoconfiguration true|false
accept-router-advert
vrouter running config# vrf <vrf> interface vrrp <vrrp> network-stack ipv6
vrouter running ipv6# accept-router-advert ACCEPT-ROUTER-ADVERT
accept-redirects
Accept redirect when acting as a host. It is always disabled when acting as a router.
vrouter running config# vrf <vrf> interface vrrp <vrrp> network-stack ipv6
vrouter running ipv6# accept-redirects true|false
accept-source-route
vrouter running config# vrf <vrf> interface vrrp <vrrp> network-stack ipv6
vrouter running ipv6# accept-source-route true|false
router-solicitations
vrouter running config# vrf <vrf> interface vrrp <vrrp> network-stack ipv6
vrouter running ipv6# router-solicitations <int16>
use-temporary-addresses
Preference for Privacy Extensions (RFC4941). Not applied to point-to- point and loopback devices (always 0).
vrouter running config# vrf <vrf> interface vrrp <vrrp> network-stack ipv6
vrouter running ipv6# use-temporary-addresses USE-TEMPORARY-ADDRESSES
USE-TEMPORARY-ADDRESSESDescription
values
never Disable Privacy Extensions, i.e. use the public address, subnet prefix/interface id,
where interface id is always the same.
prefer-public-addresses Enable Privacy Extensions, but prefer public addresses over temporary addresses.
always Enable Privacy Extensions and prefer temporary addresses over public addresses.
authentication
Authentication parameters.
auth-type
auth-pass
unicast-peer
IP addresses of unicast peers. If the list is not empty, do not send VRRP advertisements over a VRRP multicast
group but to this list of peers.
virtual-address
virtual-route
interface
Out device.
interface <string>
gw
Gateway IP.
gw GW
GW values Description
<A.B.C.D> An IPv4 address.
<X:X::X:X> An IPv6 address.
The total number of octets received on the interface, including framing characters. Discontinuities in the value of
this counter can occur at re-initialization of the management system, and at other times as indicated by the value of
‘last-clear’.
vrouter> show state vrf <vrf> interface vrrp <vrrp> counters in-octets
The number of packets, delivered by this sub-layer to a higher (sub-)layer, that were not addressed to a multicast or
broadcast address at this sub-layer. Discontinuities in the value of this counter can occur at re-initialization of the
management system, and at other times as indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface vrrp <vrrp> counters in-unicast-pkts
The number of inbound packets that were chosen to be discarded even though no errors had been detected to prevent
their being deliverable to a higher-layer protocol. One possible reason for discarding such a packet could be to free
up buffer space. Discontinuities in the value of this counter can occur at re-initialization of the management system,
and at other times as indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface vrrp <vrrp> counters in-discards
For packet-oriented interfaces, the number of inbound packets that contained errors preventing them from being
deliverable to a higher- layer protocol. For character- oriented or fixed-length interfaces, the number of inbound
transmission units that contained errors preventing them from being deliverable to a higher-layer protocol. Discon-
tinuities in the value of this counter can occur at re- initialization of the management system, and at other times as
indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface vrrp <vrrp> counters in-errors
The total number of octets transmitted out of the interface, including framing characters. Discontinuities in the
value of this counter can occur at re-initialization of the management system, and at other times as indicated by the
value of ‘last-clear’.
vrouter> show state vrf <vrf> interface vrrp <vrrp> counters out-octets
The total number of packets that higher-level protocols requested be transmitted, and that were not addressed to a
multicast or broadcast address at this sub-layer, including those that were discarded or not sent. Discontinuities in
the value of this counter can occur at re- initialization of the management system, and at other times as indicated by
the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface vrrp <vrrp> counters out-unicast-pkts
The number of outbound packets that were chosen to be discarded even though no errors had been detected to
prevent their being transmitted. One possible reason for discarding such a packet could be to free up buffer space.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other
times as indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface vrrp <vrrp> counters out-discards
For packet-oriented interfaces, the number of outbound packets that could not be transmitted because of errors. For
character-oriented or fixed-length interfaces, the number of outbound transmission units that could not be transmitted
because of errors. Discontinuities in the value of this counter can occur at re-initialization of the management system,
and at other times as indicated by the value of ‘last-clear’.
vrouter> show state vrf <vrf> interface vrrp <vrrp> counters out-errors
Controls whether IPv4 is enabled or disabled on this interface. When IPv4 is enabled, this interface is connected to
an IPv4 stack, and the interface can send and receive IPv4 packets.
vrouter> show state vrf <vrf> interface vrrp <vrrp> ipv4 enabled
The IPv4 address of the remote endpoint for point to point interfaces.
vrouter> show state vrf <vrf> interface vrrp <vrrp> ipv4 address <address> peer
The origin of this address, e.g., statically configured, assigned by DHCP, etc..
vrouter> show state vrf <vrf> interface vrrp <vrrp> ipv4 address <address> origin
A list of mappings from IPv4 addresses to link-layer addresses. Entries in this list are used as static entries in the
ARP Cache.
vrouter> show state vrf <vrf> interface vrrp <vrrp> ipv4 neighbor <neighbor> link-
˓→layer-address
vrouter> show state vrf <vrf> interface vrrp <vrrp> ipv4 neighbor <neighbor> state
vrouter> show state vrf <vrf> interface vrrp <vrrp> ipv4 dhcp enabled
Time before deciding that it’s not going to be able to contact a server.
vrouter> show state vrf <vrf> interface vrrp <vrrp> ipv4 dhcp timeout
vrouter> show state vrf <vrf> interface vrrp <vrrp> ipv4 dhcp retry
Time at which the client stops waiting for other offers from servers.
vrouter> show state vrf <vrf> interface vrrp <vrrp> ipv4 dhcp select-timeout
Time after trying to reacquire its old address before trying to discover a new address.
vrouter> show state vrf <vrf> interface vrrp <vrrp> ipv4 dhcp reboot
Time between the first attempt to reach a server and the second attempt to reach a server.
vrouter> show state vrf <vrf> interface vrrp <vrrp> ipv4 dhcp initial-interval
vrouter> show state vrf <vrf> interface vrrp <vrrp> ipv4 dhcp dhcp-lease-time
vrouter> show state vrf <vrf> interface vrrp <vrrp> ipv4 dhcp dhcp-client-identifier-
˓→ascii
vrouter> show state vrf <vrf> interface vrrp <vrrp> ipv4 dhcp dhcp-client-identifier-
˓→hexa
vrouter> show state vrf <vrf> interface vrrp <vrrp> ipv4 dhcp host-name
DHCP requests.
vrouter> show state vrf <vrf> interface vrrp <vrrp> ipv4 dhcp request
Current lease.
vrouter> show state vrf <vrf> interface vrrp <vrrp> ipv4 dhcp current-lease fixed-
˓→address
Time at which the client should begin trying to contact its server to renew its lease.
vrouter> show state vrf <vrf> interface vrrp <vrrp> ipv4 dhcp current-lease renew
Time at which the client should begin to try to contact any dhcp server to renew its lease.
vrouter> show state vrf <vrf> interface vrrp <vrrp> ipv4 dhcp current-lease rebind
Time at which the client must stop using a lease if it has not been able to renew it.
vrouter> show state vrf <vrf> interface vrrp <vrrp> ipv4 dhcp current-lease expire
Controls whether IPv6 is enabled or disabled on this interface. When IPv6 is enabled, this interface is connected to
an IPv6 stack, and the interface can send and receive IPv6 packets.
vrouter> show state vrf <vrf> interface vrrp <vrrp> ipv6 enabled
The IPv6 address of the remote endpoint for point to point interfaces.
vrouter> show state vrf <vrf> interface vrrp <vrrp> ipv6 address <address> peer
vrouter> show state vrf <vrf> interface vrrp <vrrp> ipv6 address <address> origin
The status of an address. Most of the states correspond to states from the IPv6 Stateless Address Autoconfiguration
protocol.
vrouter> show state vrf <vrf> interface vrrp <vrrp> ipv6 address <address> status
vrouter> show state vrf <vrf> interface vrrp <vrrp> ipv6 neighbor <neighbor> link-
˓→layer-address
vrouter> show state vrf <vrf> interface vrrp <vrrp> ipv6 neighbor <neighbor> router
vrouter> show state vrf <vrf> interface vrrp <vrrp> ipv6 neighbor <neighbor> state
vrouter> show state vrf <vrf> interface vrrp <vrrp> ethernet mac-address
3.2.26 ike
IKE configuration.
enabled
Enable or disable the IKE protocol and indicate whether the system should negotiate Security Associations for the
IPsec protocol.
Default value
true
pool
address (mandatory)
dns
nbns
dhcp
subnet
SUBNETDescription
val-
ues
<subnet-
The ipv4-prefix type represents an IPv4 address prefix. The prefix length is given by the number following
ip- the slash character and must be less than or equal to 32. A prefix length value of n corresponds to an IP
address>
address mask that has n contiguous 1-bits from the most significant bit (MSB) and all other bits set to 0.
The canonical format of an IPv4 prefix has all bits of the IPv4 address set to zero that are not part of the
IPv4 prefix.
<subnet-
The ipv6-prefix type represents an IPv6 address prefix. The prefix length is given by the number following
ip- the slash character and must be less than or equal to 128. A prefix length value of n corresponds to an IP
address>
address mask that has n contiguous 1-bits from the most significant bit (MSB) and all other bits set to 0.
The IPv6 address should have all bits that do not belong to the prefix set to zero. The canonical format of
an IPv6 prefix has all bits of the IPv6 address set to zero that are not part of the IPv6 prefix. Furthermore,
the IPv6 address is represented as defined in Section 4 of RFC 5952.
certificate
certificate (mandatory)
private-key (mandatory)
certificate-authority
certificate (mandatory)
crl
crl-uri
pre-shared-key
id
ID Description
val-
ues
<ike- An IPv4 address.
id>
<ike- An IPv6 address.
id>
<ike- The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
id> this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<ike- IKE ID (IP address, fqdn, e-mail address or distinguished name).
id>
<ike- IKE ID (IP address, fqdn, e-mail address or distinguished name).
id>
secret (mandatory)
eap-key
id
ID EAP ID.
secret (mandatory)
eap-radius
nas-identifier
Default value
6WINDvRouter
auth-port
Default value
1812
sockets
Default value
1
retransmit-tries
Default value
4
retransmit-timeout
Default value
2.0
retransmit-base
Default value
1.4
server
address (mandatory)
vrf
secret (mandatory)
nas-identifier
auth-port
sockets
retransmit-tries
retransmit-timeout
retransmit-base
logging
Logs configuration.
daemon
default
Default value
0
asn1
config
child
CHILD_SA/IPsec SA processing.
daemon
encoding
ipsec
ike
IKE_SA/ISAKMP SA processing.
job
kernel
library
manager
network
authpriv
default
Default value
disable
asn1
config
child
CHILD_SA/IPsec SA processing.
daemon
encoding
ipsec
ike
IKE_SA/ISAKMP SA processing.
job
kernel
library
manager
network
global-options
threads
Default value
16
acquire-timeout
Lifetime of SA acquire messages created when traffic matches a trap policy (seconds).
Default value
30
sa-table-size
Default value
1
sa-table-segments
Default value
1
install-routes
If true, install routes into a separate routing table for established IPsec tunnels.
Default value
false
routing-table
Default value
220
routing-table-prio
Default value
220
retransmit-tries
Default value
5
retransmit-timeout
Default value
4.0
retransmit-base
Default value
1.8
delete-rekeyed
Whether to immediately delete the old child SAs after an IKEv1 rekey. If false, old child SAs will be deleted after
their hard lifetime, or on reception of a delete notification from the IKE peer.
Default value
false
delete-rekeyed-delay
Delay in seconds before deleting the old inbound child SAs after an IKEv2 rekey as initiator.
Default value
5
make-before-break
During reauthentication, whether to recreate all new SAs before deleting the old ones. This implies to use overlap-
ping IKE and child SAs, which must be supported by the IKE peer.
Default value
false
interface-use
List of network interfaces that should be used. All other interfaces are ignored.
interface-ignore
List of network interfaces that should be ignored, if interfaces-use is specified this option has no effect.
snmp
Default value
false
mobike-prefer-best-path
Dynamically update SAs with MOBIKE on routing changes using the cheapest path.
Default value
false
install-vip
Default value
true
install-vip-on
The name of the interface on which virtual IP addresses should be installed. If not specified the addresses will be
installed on the outbound interface.
retry-initiate-interval
Interval in seconds to use when retrying to initiate an IKE_SA (e.g. if DNS resolution failed), 0 to disable retries.
Default value
0
dos-protection
cookie-threshold
Number of half-open IKE SAs that activate the cookie mechanism. 0 disables cookies.
Default value
10
block-threshold
Maximum number of half-open IKE SAs for a single peer IP. 0 disables this limit.
Default value
5
init-limit-half-open
Refuse new connections if the current number of half open IKE SAs reaches this limit. 0 disables the limit.
Default value
0
sp-hash-ipv4
local
local <uint8>
Default value
32
remote
remote <uint8>
Default value
32
sp-hash-ipv6
local
local <uint8>
Default value
128
remote
remote <uint8>
Default value
128
ha
enabled
Default value
true
listen-ha-group (mandatory)
The HA group to be monitored. If the state of this group changes, it will trigger a failover of the IKE service to/from
another IKE HA node.
node-id (mandatory)
interface (mandatory)
local-address (mandatory)
remote-address (mandatory)
seqnum-sync
oseq-shift
Default value
65536
sync-period-time
Default value
10s
sync-period-packets
Default value
2
pool
address (mandatory)
LOCAL-AUTH-METHOD Description
values
pre-shared-key Pre-shared key.
certificate Public key signature with X509 Certificates.
eap-md5 Extensible Authentication Protocol - MD5-Challenge.
eap-mschapv2 Extensible Authentication Protocol - Microsoft Challenge-Handshake Authentica-
tion Protocol v2.
Default value
pre-shared-key
REMOTE-AUTH-METHOD Description
values
pre-shared-key Pre-shared key.
certificate Public key signature with X509 Certificates.
eap-md5 Extensible Authentication Protocol - MD5-Challenge.
eap-mschapv2 Extensible Authentication Protocol - Microsoft Challenge-Handshake Authentica-
tion Protocol v2.
eap-radius Extensible Authentication Protocol delegated to a RADIUS server.
Default value
pre-shared-key
Number of times we should try to initiate an IKE connection if the responder does not answer (after a full sequence
of retransmissions). A value of 0 initiates a new sequence forever, until the connection establishes or fails with a
permanent error.
Default value
1
Connection uniqueness policy to enforce, to avoid multiple connections from the same user ID.
UNIQUE-SA Description
values
no Do not enforce IKE SA uniqueness, except if a peer included INITIAL_CONTACT notify.
never Never enforce IKE SA uniqueness, even if a peer included INITIAL_CONTACT notify. Never
send INITIAL_CONTACT as initiator.
keep Reject new connection attempts from same user.
replace Delete any existing connection if a new one for the same user gets established.
Default value
no
Default value
0s
Default value
4h
Default value
0s
Default value
false
Default value
false
Default value
false
START-ACTION Description
values
none Load the connection only, can be used as a responder configuration.
trap Install a trap policy, which triggers the tunnel as soon as matching traffic has been
detected.
start Initiate the connection actively.
Default value
trap
Default value
trap
Default value
restart
Default value
32
Default value
1h
Timeout before closing CHILD_SA after inactivity. If no traffic has been processed in either direction for the
configured timeout, the CHILD_SA gets closed due to inactivity (default value of 0 disables inactivity checks).
Default value
0
Time range from which to choose a random value to subtract from rekey_time (default life_time - rekey_time).
Default value
0
Maximum bytes processed before CHILD_SA gets closed (default rekey- bytes + 10%).
Byte range from which to choose a random value to subtract from rekey_bytes (default life_bytes - rekey_bytes).
Default value
0
Maximum packets processed before CHILD_SA gets closed (default rekey- bytes + 10%).
Packet range from which to choose a random value to subtract from rekey_packets (default life_bytes - rekey_bytes).
Default value
true
Default value
false
Whether to copy the Don’t Fragment bit from outer to inner IP header at IPsec encapsulation.
Default value
true
List of AH proposals.
vpn
description
version
IKE version. 0 accepts both IKEv1 and IKEv2 as responder, and initiates the connection actively with IKEv2.
Default value
2
local-address
Description
LOCAL-ADDRESS
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<ipv4-An IPv4 address.
address>
<ipv6-An IPv6 address.
address>
<ipv4-An IPv4 prefix: address and CIDR mask.
prefix>
<ipv6-An IPv6 prefix: address and CIDR mask.
prefix>
<ipv4-An IPv4 address range, in the form addr4-addr4.
range>
<ipv6-An IPv6 address range, in the form addr6-addr6.
range>
remote-address
Description
REMOTE-ADDRESS
val-
ues
<domain-
The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<ipv4-An IPv4 address.
address>
<ipv6-An IPv6 address.
address>
<ipv4-An IPv4 prefix: address and CIDR mask.
prefix>
<ipv6-An IPv6 prefix: address and CIDR mask.
prefix>
<ipv4-An IPv4 address range, in the form addr4-addr4.
range>
<ipv6-An IPv6 address range, in the form addr6-addr6.
range>
local-id
Local IKE identifier (IP address, fqdn, user-fqdn, ASN.1 Distinguished Name) (Default psk: IP address, certificates:
SubjectName).
Description
LOCAL-ID
val-
ues
<ike- An IPv4 address.
id>
<ike- An IPv6 address.
id>
<ike- The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
id> this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<ike- IKE ID (IP address, fqdn, e-mail address or distinguished name).
id>
<ike- IKE ID (IP address, fqdn, e-mail address or distinguished name).
id>
remote-id
Remote IKE identifier (IP address, fqdn, user-fqdn, ASN.1 Distinguished Name) (Default psk: IP address, certifi-
cates: SubjectName).
Description
REMOTE-ID
val-
ues
<ike- An IPv4 address.
id>
<ike- An IPv6 address.
id>
<ike- The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
id> this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<ike- IKE ID (IP address, fqdn, e-mail address or distinguished name).
id>
<ike- IKE ID (IP address, fqdn, e-mail address or distinguished name).
id>
local-eap-id
remote-eap-id
certificate
remote-ca-certificate
List of certificate authority certificates to accept for authentication of the remote peer.
vip-request
List of virtual IP addresses to request (0.0.0.0 for any IPv4 address, :: for any IPv6 address).
vip-pool
ike-policy
local-auth-method
LOCAL-AUTH-METHOD Description
values
pre-shared-key Pre-shared key.
certificate Public key signature with X509 Certificates.
eap-md5 Extensible Authentication Protocol - MD5-Challenge.
eap-mschapv2 Extensible Authentication Protocol - Microsoft Challenge-Handshake Authentica-
tion Protocol v2.
remote-auth-method
REMOTE-AUTH-METHOD Description
values
pre-shared-key Pre-shared key.
certificate Public key signature with X509 Certificates.
eap-md5 Extensible Authentication Protocol - MD5-Challenge.
eap-mschapv2 Extensible Authentication Protocol - Microsoft Challenge-Handshake Authentica-
tion Protocol v2.
eap-radius Extensible Authentication Protocol delegated to a RADIUS server.
keying-tries
Number of times we should try to initiate an IKE connection if the responder does not answer (after a full sequence
of retransmissions). A value of 0 initiates a new sequence forever, until the connection establishes or fails with a
permanent error.
unique-sa
Connection uniqueness policy to enforce, to avoid multiple connections from the same user ID.
UNIQUE-SA Description
values
no Do not enforce IKE SA uniqueness, except if a peer included INITIAL_CONTACT notify.
never Never enforce IKE SA uniqueness, even if a peer included INITIAL_CONTACT notify. Never
send INITIAL_CONTACT as initiator.
keep Reject new connection attempts from same user.
replace Delete any existing connection if a new one for the same user gets established.
reauth-time
rekey-time
dpd-delay
aggressive
udp-encap
mobike
ike-proposal
vrouter running config# vrf <vrf> ike vpn <vpn> ike-policy ike-proposal <uint8>
enc-alg
vrouter running config# vrf <vrf> ike vpn <vpn> ike-policy ike-proposal <uint8>
vrouter running ike-proposal <uint8># enc-alg ENC-ALG
auth-alg
vrouter running config# vrf <vrf> ike vpn <vpn> ike-policy ike-proposal <uint8>
vrouter running ike-proposal <uint8># auth-alg AUTH-ALG
aead-alg
vrouter running config# vrf <vrf> ike vpn <vpn> ike-policy ike-proposal <uint8>
vrouter running ike-proposal <uint8># aead-alg AEAD-ALG
prf-alg
vrouter running config# vrf <vrf> ike vpn <vpn> ike-policy ike-proposal <uint8>
vrouter running ike-proposal <uint8># prf-alg PRF-ALG
dh-group
vrouter running config# vrf <vrf> ike vpn <vpn> ike-policy ike-proposal <uint8>
vrouter running ike-proposal <uint8># dh-group DH-GROUP
ipsec-policy
start-action
START-ACTION Description
values
none Load the connection only, can be used as a responder configuration.
trap Install a trap policy, which triggers the tunnel as soon as matching traffic has been
detected.
start Initiate the connection actively.
close-action
dpd-action
replay-window
rekey-time
inactivity
Timeout before closing CHILD_SA after inactivity. If no traffic has been processed in either direction for the
configured timeout, the CHILD_SA gets closed due to inactivity (default value of 0 disables inactivity checks).
life-time
rand-time
Time range from which to choose a random value to subtract from rekey_time (default life_time - rekey_time).
rekey-bytes
life-bytes
Maximum bytes processed before CHILD_SA gets closed (default rekey- bytes + 10%).
rand-bytes
Byte range from which to choose a random value to subtract from rekey_bytes (default life_bytes - rekey_bytes).
rekey-packets
life-packets
Maximum packets processed before CHILD_SA gets closed (default rekey- bytes + 10%).
rand-packets
Packet range from which to choose a random value to subtract from rekey_packets (default life_bytes - rekey_bytes).
encap-copy-dscp
decap-copy-dscp
encap-copy-df
Whether to copy the Don’t Fragment bit from outer to inner IP header at IPsec encapsulation.
esp-proposal
vrouter running config# vrf <vrf> ike vpn <vpn> ipsec-policy esp-proposal <uint8>
enc-alg
vrouter running config# vrf <vrf> ike vpn <vpn> ipsec-policy esp-proposal <uint8>
vrouter running esp-proposal <uint8># enc-alg ENC-ALG
auth-alg
vrouter running config# vrf <vrf> ike vpn <vpn> ipsec-policy esp-proposal <uint8>
vrouter running esp-proposal <uint8># auth-alg AUTH-ALG
aead-alg
vrouter running config# vrf <vrf> ike vpn <vpn> ipsec-policy esp-proposal <uint8>
vrouter running esp-proposal <uint8># aead-alg AEAD-ALG
dh-group
vrouter running config# vrf <vrf> ike vpn <vpn> ipsec-policy esp-proposal <uint8>
vrouter running esp-proposal <uint8># dh-group DH-GROUP
esn
vrouter running config# vrf <vrf> ike vpn <vpn> ipsec-policy esp-proposal <uint8>
vrouter running esp-proposal <uint8># esn true|false
ah-proposal
List of AH proposals.
vrouter running config# vrf <vrf> ike vpn <vpn> ipsec-policy ah-proposal <uint8>
auth-alg
vrouter running config# vrf <vrf> ike vpn <vpn> ipsec-policy ah-proposal <uint8>
vrouter running ah-proposal <uint8># auth-alg AUTH-ALG
dh-group
vrouter running config# vrf <vrf> ike vpn <vpn> ipsec-policy ah-proposal <uint8>
vrouter running ah-proposal <uint8># dh-group DH-GROUP
esn
vrouter running config# vrf <vrf> ike vpn <vpn> ipsec-policy ah-proposal <uint8>
vrouter running ah-proposal <uint8># esn true|false
security-policy
vrouter running config# vrf <vrf> ike vpn <vpn> security-policy <security-policy>
svti-id-in
vrouter running config# vrf <vrf> ike vpn <vpn> security-policy <security-policy>
vrouter running security-policy <security-policy># svti-id-in <uint32>
svti-id-out
vrouter running config# vrf <vrf> ike vpn <vpn> security-policy <security-policy>
vrouter running security-policy <security-policy># svti-id-out <uint32>
action
IPsec action.
vrouter running config# vrf <vrf> ike vpn <vpn> security-policy <security-policy>
vrouter running security-policy <security-policy># action ACTION
Default value
esp
mode
vrouter running config# vrf <vrf> ike vpn <vpn> security-policy <security-policy>
vrouter running security-policy <security-policy># mode MODE
Default value
tunnel
priority
vrouter running config# vrf <vrf> ike vpn <vpn> security-policy <security-policy>
vrouter running security-policy <security-policy># priority <uint32>
Default value
0
local-ts
Local traffic selector (default the tunnel outer address or the virtual IP, if negotiated).
vrouter running config# vrf <vrf> ike vpn <vpn> security-policy <security-policy>
vrouter running security-policy <security-policy># local-ts subnet SUBNET \
... protocol <uint8> port <uint16>
subnet
Private subnet or address (default: the tunnel outer address or virtual IP, if negotiated).
subnet SUBNET
protocol
protocol <uint8>
port
port <uint16>
remote-ts
Remote traffic selector (default the tunnel outer address or the virtual IP, if negotiated).
vrouter running config# vrf <vrf> ike vpn <vpn> security-policy <security-policy>
vrouter running security-policy <security-policy># remote-ts subnet SUBNET \
... protocol <uint8> port <uint16>
subnet
Private subnet or address (default: the tunnel outer address or virtual IP, if negotiated).
subnet SUBNET
protocol
protocol <uint8>
port
port <uint16>
vrouter> show state vrf <vrf> ike vpn-counters name <vpn-counters> ike-rekey-init
vrouter> show state vrf <vrf> ike vpn-counters name <vpn-counters> ike-rekey-resp
vrouter> show state vrf <vrf> ike vpn-counters name <vpn-counters> child-rekey
vrouter> show state vrf <vrf> ike vpn-counters name <vpn-counters> invalid
vrouter> show state vrf <vrf> ike vpn-counters name <vpn-counters> invalid-spi
vrouter> show state vrf <vrf> ike vpn-counters name <vpn-counters> ike-init-in-req
vrouter> show state vrf <vrf> ike vpn-counters name <vpn-counters> ike-init-in-resp
vrouter> show state vrf <vrf> ike vpn-counters name <vpn-counters> ike-init-out-req
vrouter> show state vrf <vrf> ike vpn-counters name <vpn-counters> ike-init-out-resp
vrouter> show state vrf <vrf> ike vpn-counters name <vpn-counters> ike-auth-in-req
vrouter> show state vrf <vrf> ike vpn-counters name <vpn-counters> ike-auth-in-resp
vrouter> show state vrf <vrf> ike vpn-counters name <vpn-counters> ike-auth-out-req
vrouter> show state vrf <vrf> ike vpn-counters name <vpn-counters> ike-auth-out-resp
vrouter> show state vrf <vrf> ike vpn-counters name <vpn-counters> create-child-in-req
vrouter> show state vrf <vrf> ike vpn-counters name <vpn-counters> create-child-in-resp
vrouter> show state vrf <vrf> ike vpn-counters name <vpn-counters> create-child-out-req
vrouter> show state vrf <vrf> ike vpn-counters name <vpn-counters> create-child-out-
˓→resp
vrouter> show state vrf <vrf> ike vpn-counters name <vpn-counters> info-in-req
vrouter> show state vrf <vrf> ike vpn-counters name <vpn-counters> info-in-resp
vrouter> show state vrf <vrf> ike vpn-counters name <vpn-counters> info-out-req
vrouter> show state vrf <vrf> ike vpn-counters name <vpn-counters> info-out-resp
vrouter> show state vrf <vrf> ike ike-sa unique-id <uint32> name
IKE version.
vrouter> show state vrf <vrf> ike ike-sa unique-id <uint32> version
IKE SA state.
vrouter> show state vrf <vrf> ike ike-sa unique-id <uint32> state
vrouter> show state vrf <vrf> ike ike-sa unique-id <uint32> local-address
vrouter> show state vrf <vrf> ike ike-sa unique-id <uint32> remote-address
vrouter> show state vrf <vrf> ike ike-sa unique-id <uint32> local-port
vrouter> show state vrf <vrf> ike ike-sa unique-id <uint32> remote-port
vrouter> show state vrf <vrf> ike ike-sa unique-id <uint32> local-id
vrouter> show state vrf <vrf> ike ike-sa unique-id <uint32> remote-id
vrouter> show state vrf <vrf> ike ike-sa unique-id <uint32> remote-eap-id
vrouter> show state vrf <vrf> ike ike-sa unique-id <uint32> initiator-spi
vrouter> show state vrf <vrf> ike ike-sa unique-id <uint32> responder-spi
vrouter> show state vrf <vrf> ike ike-sa unique-id <uint32> enc-alg
vrouter> show state vrf <vrf> ike ike-sa unique-id <uint32> auth-alg
vrouter> show state vrf <vrf> ike ike-sa unique-id <uint32> aead-alg
vrouter> show state vrf <vrf> ike ike-sa unique-id <uint32> prf-alg
vrouter> show state vrf <vrf> ike ike-sa unique-id <uint32> dh-group
vrouter> show state vrf <vrf> ike ike-sa unique-id <uint32> established-time
vrouter> show state vrf <vrf> ike ike-sa unique-id <uint32> rekey-time
vrouter> show state vrf <vrf> ike ike-sa unique-id <uint32> reauth-time
vrouter> show state vrf <vrf> ike ike-sa unique-id <uint32> udp-encap
vrouter> show state vrf <vrf> ike ike-sa unique-id <uint32> mobike
vrouter> show state vrf <vrf> ike ike-sa unique-id <uint32> local-vip
vrouter> show state vrf <vrf> ike ike-sa unique-id <uint32> remote-vip
vrouter> show state vrf <vrf> ike ike-sa unique-id <uint32> child-sa unique-id <uint32>
˓→ name
Child SA state.
vrouter> show state vrf <vrf> ike ike-sa unique-id <uint32> child-sa unique-id <uint32>
˓→ state
vrouter> show state vrf <vrf> ike ike-sa unique-id <uint32> child-sa unique-id <uint32>
˓→ reqid
IPsec protocol.
vrouter> show state vrf <vrf> ike ike-sa unique-id <uint32> child-sa unique-id <uint32>
˓→ protocol
vrouter> show state vrf <vrf> ike ike-sa unique-id <uint32> child-sa unique-id <uint32>
˓→ udp-encap
vrouter> show state vrf <vrf> ike ike-sa unique-id <uint32> child-sa unique-id <uint32>
˓→ mobike
vrouter> show state vrf <vrf> ike ike-sa unique-id <uint32> child-sa unique-id <uint32>
˓→ spi-in
vrouter> show state vrf <vrf> ike ike-sa unique-id <uint32> child-sa unique-id <uint32>
˓→ spi-out
vrouter> show state vrf <vrf> ike ike-sa unique-id <uint32> child-sa unique-id <uint32>
˓→ svti-id-in
vrouter> show state vrf <vrf> ike ike-sa unique-id <uint32> child-sa unique-id <uint32>
˓→ svti-id-out
vrouter> show state vrf <vrf> ike ike-sa unique-id <uint32> child-sa unique-id <uint32>
˓→ enc-alg
vrouter> show state vrf <vrf> ike ike-sa unique-id <uint32> child-sa unique-id <uint32>
˓→ auth-alg
vrouter> show state vrf <vrf> ike ike-sa unique-id <uint32> child-sa unique-id <uint32>
˓→ aead-alg
vrouter> show state vrf <vrf> ike ike-sa unique-id <uint32> child-sa unique-id <uint32>
˓→ dh-group
vrouter> show state vrf <vrf> ike ike-sa unique-id <uint32> child-sa unique-id <uint32>
˓→ esn
vrouter> show state vrf <vrf> ike ike-sa unique-id <uint32> child-sa unique-id <uint32>
˓→ bytes-in
vrouter> show state vrf <vrf> ike ike-sa unique-id <uint32> child-sa unique-id <uint32>
˓→ packets-in
vrouter> show state vrf <vrf> ike ike-sa unique-id <uint32> child-sa unique-id <uint32>
˓→ bytes-out
vrouter> show state vrf <vrf> ike ike-sa unique-id <uint32> child-sa unique-id <uint32>
˓→ packets-out
vrouter> show state vrf <vrf> ike ike-sa unique-id <uint32> child-sa unique-id <uint32>
˓→ installed-time
vrouter> show state vrf <vrf> ike ike-sa unique-id <uint32> child-sa unique-id <uint32>
˓→ rekey-time
vrouter> show state vrf <vrf> ike ike-sa unique-id <uint32> child-sa unique-id <uint32>
˓→ life-time
IPsec mode.
vrouter> show state vrf <vrf> ike ike-sa unique-id <uint32> child-sa unique-id <uint32>
˓→ mode
Private subnet or address (default: the tunnel outer address or virtual IP, if negotiated).
vrouter> show state vrf <vrf> ike ike-sa unique-id <uint32> child-sa unique-id <uint32>
˓→ local-ts subnet
vrouter> show state vrf <vrf> ike ike-sa unique-id <uint32> child-sa unique-id <uint32>
˓→ local-ts protocol
vrouter> show state vrf <vrf> ike ike-sa unique-id <uint32> child-sa unique-id <uint32>
˓→ local-ts port
The type of traffic selector proposed by the remote peer is not supported. The configuration may not work as
expected.
vrouter> show state vrf <vrf> ike ike-sa unique-id <uint32> child-sa unique-id <uint32>
˓→ local-ts unsupported
Private subnet or address (default: the tunnel outer address or virtual IP, if negotiated).
vrouter> show state vrf <vrf> ike ike-sa unique-id <uint32> child-sa unique-id <uint32>
˓→ remote-ts subnet
vrouter> show state vrf <vrf> ike ike-sa unique-id <uint32> child-sa unique-id <uint32>
˓→ remote-ts protocol
vrouter> show state vrf <vrf> ike ike-sa unique-id <uint32> child-sa unique-id <uint32>
˓→ remote-ts port
The type of traffic selector proposed by the remote peer is not supported. The configuration may not work as
expected.
vrouter> show state vrf <vrf> ike ike-sa unique-id <uint32> child-sa unique-id <uint32>
˓→ remote-ts unsupported
vrouter> show state vrf <vrf> ike pool-lease name <pool-lease> address
vrouter> show state vrf <vrf> ike pool-lease name <pool-lease> size
vrouter> show state vrf <vrf> ike pool-lease name <pool-lease> online
vrouter> show state vrf <vrf> ike pool-lease name <pool-lease> offline
3.2.27 sflow
SFlow configuration.
enabled
Default value
true
agent-interface
polling
Polling type (disabled or interval in seconds). Every interval, an sFlow frame containing interface statistics is sent
to the collector.
Default value
disabled
sflow-port
SFLOW-PORT A 16-bit port number used by a transport protocol such as TCP or UDP.
Default value
36343
if-error
if-unknown
Force the output ifindex value used for packets where the output is not known.
sflow-collector
Description
<sflow-collector>
val-
ues
<A.B.C.D>
An IPv4 address.
<X:X::X:X>
An IPv6 address.
<host- The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
port
port PORT
PORT A 16-bit port number used by a transport protocol such as TCP or UDP.
Default value
6343
sflow-interface
sflow-sampling
rate
Sampling rate in number of packets. For better performance, it should be set to a power of two.
rate RATE
Default value
auto
3.2.28 snmp
SNMP configuration.
enabled
Default value
true
listen
protocols
Default value
udp
port
PORT A 16-bit port number used by a transport protocol such as TCP or UDP.
Default value
161
static-info
Most of the information reported by the SNMP agent is retrieved from the underlying system. However, certain
MIB objects can be configured with a static value.
location
contact
name
services
Value of the sysServices.0 object. For a host system, a good value is 72 (application + end-to-end layers).
description
object-id
view
subtree
included
included true|false
Default value
true
community
authorization (mandatory)
source
SOURCE Description
val-
ues
<A.B.C.D>
An IPv4 address.
<X:X::X:X>
An IPv6 address.
<host- The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<A.B.C.D/M>
An IPv4 prefix: address and CIDR mask.
<X:X::X:X/M>
An IPv6 prefix: address and CIDR mask.
view
Restricts access for that community to the subtree rooted at the given view name. If not specified, the community
has access to the whole OID tree.
monitored-vrf
Monitored VRF.
identifier
Identifier to access the monitored VRF, acts as a community for SNMPv1 or SNMPv2c and as a context for SNMPv3.
vrouter running config# vrf <vrf> snmp monitored-vrf <string> identifier <string>
<string> The monitored VRF identifier (community for SNMPv1 or SNMPv2c and context for SNMPv3).
authorization (mandatory)
vrouter running config# vrf <vrf> snmp monitored-vrf <string> identifier <string>
vrouter running identifier <string># authorization AUTHORIZATION
source
Restrict access to requests from the specified address or prefix list for SNMPv1 or SNMPv2.
vrouter running config# vrf <vrf> snmp monitored-vrf <string> identifier <string>
vrouter running identifier <string># source SOURCE
SOURCE Description
val-
ues
<A.B.C.D>
An IPv4 address.
<X:X::X:X>
An IPv6 address.
<host- The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
<A.B.C.D/M>
An IPv4 prefix: address and CIDR mask.
<X:X::X:X/M>
An IPv6 prefix: address and CIDR mask.
view
Restricts access to the subtree rooted at the given view name. If not specified, the identifier has access to the whole
OID tree.
vrouter running config# vrf <vrf> snmp monitored-vrf <string> identifier <string>
vrouter running identifier <string># view <leafref>
traps
destination
vrouter running config# vrf <vrf> snmp monitored-vrf <string> traps destination
˓→<leafref>
community (mandatory)
vrouter running config# vrf <vrf> snmp monitored-vrf <string> traps destination
˓→<leafref>
access-control
user
An SNMPv3 user.
auth-password (mandatory)
auth-method
Default value
sha
priv-password
The privacy (encryption) password. If not specified, it is assumed to be the same as the authentication password.
priv-protocol
Default value
aes
group
An SNMPv3 group.
user
security-level (mandatory)
view
Restricts access for that group to the subtree rooted at the given view name. If not specified, the group has access
to the whole OID tree.
authorization
Default value
read-only
traps
destination
Notification receiver that should be sent SNMPv1 TRAPs, SNMPv2c TRAP2s, or SNMPv2 INFORM notifications.
Description
<destination>
val-
ues
<A.B.C.D>
An IPv4 address.
<X:X::X:X>
An IPv6 address.
<host- The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
port
port PORT
PORT A 16-bit port number used by a transport protocol such as TCP or UDP.
Default value
162
protocol
protocol PROTOCOL
Default value
udp
notification-type (mandatory)
notification-type NOTIFICATION-TYPE
community (mandatory)
community <leafref>
authfail-check
enabled
enabled true|false
Default value
true
link-status-check
Monitor network interfaces being taken up or down, triggering a linkUp or linkDown notification as appropriate.
frequency
Check for network interfaces being taken up or down every <frequency> period.
frequency FREQUENCY
FRE- Value in seconds or optionnally suffixed by one of s (for seconds), m (for minutes), h (for hours),
QUENCY d (for days) or w (for weeks).
Default value
60s
enabled
enabled true|false
Default value
true
process-check
Monitor the important processes of the system, triggering a notification when one of them is not alive.
frequency
Check for network interfaces being taken up or down every <frequency> period.
frequency FREQUENCY
FRE- Value in seconds or optionnally suffixed by one of s (for seconds), m (for minutes), h (for hours),
QUENCY d (for days) or w (for weeks).
Default value
2s
enabled
enabled true|false
Default value
true
disk-space-check
Enables monitoring of all disks found on the system, using the specified (percentage) threshold.
threshold (mandatory)
threshold <uint8>
frequency
frequency FREQUENCY
FRE- Value in seconds or optionnally suffixed by one of s (for seconds), m (for minutes), h (for hours),
QUENCY d (for days) or w (for weeks).
Default value
5m
enabled
enabled true|false
Default value
true
load-check
Enables monitoring of the load average and trigger notifications if it goes above the specified thresholds.
threshold (mandatory)
threshold <uint16>
enabled
enabled true|false
Default value
true
3.2.29 routing
global
ipv4-access-list
remark
seq
permit
exact-match
exact-match true|false
deny
exact-match
exact-match true|false
ipv6-access-list
remark
seq
permit
exact-match
exact-match true|false
deny
exact-match
exact-match true|false
logging
Logs configuration.
enabled
Default value
true
level
Default value
error
mpls
ldp
enabled
Default value
true
discovery-hello
errors
Log errors.
Default value
true
events
Default value
false
labels
Default value
false
zebra
Default value
false
message
direction
Default value
both
detail
Default value
false
bgp
enabled
Default value
true
allow-martians
Default value
false
as-4bytes
Default value
false
as-4bytes-segment
Default value
false
bestpath
nexthop-tracking
Default value
false
flowspec
Default value
false
keepalives
neighbor-events
update-groups
Default value
false
zebra
rpki
Default value
false
pbr
detail
Default value
false
updates
enabled
Default value
true
in
IN values Description
<A.B.C.D> An IPv4 address.
<X:X::X:X> An IPv6 address.
all Log inbound update messages from all neighbors.
Default value
all
out
Default value
all
prefix
vpn
label
Default value
false
leak-vrf
Log leaks.
route-map-event
Default value
false
rip
enabled
Default value
true
events
Default value
false
packet
Default value
both
zebra
Default value
false
ripng
enabled
Default value
true
events
Default value
false
packet
Default value
both
zebra
Default value
false
ospf
enabled
Default value
true
events
Default value
false
ism
lsa
nsm
nssa
Default value
false
zebra
message
direction
Default value
both
detail
Default value
false
ospf6
enabled
Default value
true
abr
Default value
false
asbr
Default value
false
events
Log events.
Default value
false
flooding
Default value
false
interface
Default value
false
neighbor
route
spf
zebra
border-routers
summary
Default value
false
area-id
router-id
lsa
level
level LEVEL
Default value
all
message
direction
direction DIRECTION
Default value
both
ipv4-prefix-list
seq
address
address ADDRESS
policy (mandatory)
policy POLICY
ge
ge <uint8>
le
le <uint8>
ipv6-prefix-list
seq
address
address ADDRESS
policy (mandatory)
policy POLICY
ge
ge <uint8>
le
le <uint8>
route-map
seq
policy (mandatory)
Matching policy.
description
Route-map description.
call
on-match
match
as-path
interface
local-preference
mac-address
metric
origin
peer
probability
source-instance
source-protocol
tag
extcommunity
rpki
evpn
vrouter running config# routing route-map <string> seq <uint16> match evpn
default-route
vrouter running config# routing route-map <string> seq <uint16> match evpn
vrouter running evpn# default-route true|false
route-type
vrouter running config# routing route-map <string> seq <uint16> match evpn
vrouter running evpn# route-type ROUTE-TYPE
vni
VNI ID.
vrouter running config# routing route-map <string> seq <uint16> match evpn
vrouter running evpn# vni <uint32>
route-distinguisher
Route distinguisher.
vrouter running config# routing route-map <string> seq <uint16> match evpn
vrouter running evpn# route-distinguisher ROUTE-DISTINGUISHER
Description
ROUTE-DISTINGUISHER
values
<string> Type definition for extended community attributes. In the case that common communities are
utilised, they are represented as a string of the form: - <2b AS>:<4b value> per RFC4360 section
3.1 - <4b IPv4>:<2b value> per RFC4360 section 3.2.
<string> Type definition for extended community attributes. In the case that common communities are
utilised, they are represented as a string of the form: - <2b AS>:<4b value> per RFC4360 section
3.1 - <4b IPv4>:<2b value> per RFC4360 section 3.2.
ip
IP information.
address
vrouter running config# routing route-map <string> seq <uint16> match ip address
access-list
vrouter running config# routing route-map <string> seq <uint16> match ip address
vrouter running address# access-list ACCESS-LIST
prefix-list
vrouter running config# routing route-map <string> seq <uint16> match ip address
vrouter running address# prefix-list <string>
prefix-len
vrouter running config# routing route-map <string> seq <uint16> match ip address
vrouter running address# prefix-len <uint8>
next-hop
vrouter running config# routing route-map <string> seq <uint16> match ip next-hop
access-list
vrouter running config# routing route-map <string> seq <uint16> match ip next-hop
vrouter running next-hop# access-list ACCESS-LIST
prefix-list
vrouter running config# routing route-map <string> seq <uint16> match ip next-hop
vrouter running next-hop# prefix-list <string>
prefix-len
vrouter running config# routing route-map <string> seq <uint16> match ip next-hop
vrouter running next-hop# prefix-len <uint8>
route-source
vrouter running config# routing route-map <string> seq <uint16> match ip route-source
access-list
vrouter running config# routing route-map <string> seq <uint16> match ip route-source
vrouter running route-source# access-list ACCESS-LIST
prefix-list
vrouter running config# routing route-map <string> seq <uint16> match ip route-source
vrouter running route-source# prefix-list <string>
ipv6
IPv6 information.
vrouter running config# routing route-map <string> seq <uint16> match ipv6
address
vrouter running config# routing route-map <string> seq <uint16> match ipv6 address
access-list
vrouter running config# routing route-map <string> seq <uint16> match ipv6 address
vrouter running address# access-list <string>
prefix-list
vrouter running config# routing route-map <string> seq <uint16> match ipv6 address
vrouter running address# prefix-list <string>
prefix-len
vrouter running config# routing route-map <string> seq <uint16> match ipv6 address
vrouter running address# prefix-len <uint8>
next-hop
vrouter running config# routing route-map <string> seq <uint16> match ipv6 next-hop
address
vrouter running config# routing route-map <string> seq <uint16> match ipv6 next-hop
vrouter running next-hop# address ADDRESS
community
id (mandatory)
id <leafref>
exact-match
exact-match true|false
set
table
atomic-aggregate
label-index
local-preference
metric
metric-type
Type of metric.
origin
originator-id
src
tag
weight
comm-list-delete
aggregator
as (mandatory)
as <uint32>
address (mandatory)
IP address of aggregator.
address ADDRESS
as-path
vrouter running config# routing route-map <string> seq <uint16> set as-path
exclude
vrouter running config# routing route-map <string> seq <uint16> set as-path
vrouter running as-path# exclude <uint32>
prepend
vrouter running config# routing route-map <string> seq <uint16> set as-path prepend
last-as
vrouter running config# routing route-map <string> seq <uint16> set as-path prepend
vrouter running prepend# last-as <uint8>
asn
vrouter running config# routing route-map <string> seq <uint16> set as-path prepend␣
˓→asn <uint8>
<uint32> (mandatory)
AS number.
vrouter running config# routing route-map <string> seq <uint16> set as-path prepend␣
˓→asn <uint8>
ip
IP information.
next-hop
ipv4
IPv4 information.
vrouter running config# routing route-map <string> seq <uint16> set ipv4
vpn
VPN information.
vrouter running config# routing route-map <string> seq <uint16> set ipv4 vpn
next-hop
vrouter running config# routing route-map <string> seq <uint16> set ipv4 vpn
vrouter running vpn# next-hop NEXT-HOP
ipv6
IPv6 information.
vrouter running config# routing route-map <string> seq <uint16> set ipv6
next-hop
vrouter running config# routing route-map <string> seq <uint16> set ipv6 next-hop
global
vrouter running config# routing route-map <string> seq <uint16> set ipv6 next-hop
vrouter running next-hop# global GLOBAL
local
vrouter running config# routing route-map <string> seq <uint16> set ipv6 next-hop
vrouter running next-hop# local LOCAL
peer-address
vrouter running config# routing route-map <string> seq <uint16> set ipv6 next-hop
vrouter running next-hop# peer-address true|false
prefer-global
vrouter running config# routing route-map <string> seq <uint16> set ipv6 next-hop
vrouter running next-hop# prefer-global true|false
vpn
VPN information.
vrouter running config# routing route-map <string> seq <uint16> set ipv6 vpn
next-hop
vrouter running config# routing route-map <string> seq <uint16> set ipv6 vpn
vrouter running vpn# next-hop NEXT-HOP
community
vrouter running config# routing route-map <string> seq <uint16> set community
none
vrouter running config# routing route-map <string> seq <uint16> set community
vrouter running community# none
attribute
vrouter running config# routing route-map <string> seq <uint16> set community
vrouter running community# attribute ATTRIBUTE
extcommunity
vrouter running config# routing route-map <string> seq <uint16> set extcommunity
rt
vrouter running config# routing route-map <string> seq <uint16> set extcommunity
vrouter running extcommunity# rt RT
RT values Description
<string> Extended communities or route-target attribute.
<string> Extended communities or route-target attribute.
<string> Extended communities or route-target attribute.
soo
vrouter running config# routing route-map <string> seq <uint16> set extcommunity
vrouter running extcommunity# soo SOO
bgp
route-map-delay
Default value
5
community-list
policy
<uint16> Priority of the policy. Lesser is the value, greater is the priority.
POLICY (mandatory)
POLICY
COMMUNITY
COMMUNITY
community-list-expanded
policy
<uint16> Priority of the policy. Lesser is the value, greater is the priority.
POLICY (mandatory)
POLICY
COMMUNITY
COMMUNITY
extcommunity-list
policy
<uint16> Priority of the policy. Lesser is the value, greater is the priority.
POLICY (mandatory)
POLICY
rt
rt RT
RT values Description
<string> Extended communities or route-target attribute.
<string> Extended communities or route-target attribute.
<string> Extended communities or route-target attribute.
soo
soo SOO
extcommunity-list-expanded
policy
<uint16> Priority of the policy. Lesser is the value, greater is the priority.
POLICY (mandatory)
POLICY
<string>
<string>
as-path-access-list
policy
<uint16> Priority of the policy. Lesser is the value, greater is the priority.
POLICY (mandatory)
POLICY
<string>
Regular expression to match the BGP AS paths on which the policy should be applied.
<string>
static
Static routes.
ipv4-route
next-hop
Route next-hops.
dhcp-port
dhcp-port DHCP-PORT
distance
distance <uint8>
label
Specify label(s) for this route. One or more labels in the range (16-1048575) separated by ‘/’.
label <string>
nexthop-vrf
Nexthop vrf.
nexthop-vrf NEXTHOP-VRF
tag
Route tag.
tag <uint32>
track
A tracker name. If the tracked address is reachable, the next-hop is considered as valid, else it is disabled.
track TRACK
ipv6-route
next-hop
Route next-hops.
distance
distance <uint8>
label
Specify label(s) for this route. One or more labels in the range (16-1048575) separated by ‘/’.
label <string>
nexthop-vrf
Nexthop vrf.
nexthop-vrf NEXTHOP-VRF
tag
Route tag.
tag <uint32>
track
A tracker name. If the tracked address is reachable, the next-hop is considered as valid, else it is disabled.
track TRACK
table
ipv4-route
vrouter running config# vrf <vrf> routing static table <uint32> ipv4-route <ipv4-route>
next-hop
Route next-hops.
vrouter running config# vrf <vrf> routing static table <uint32> ipv4-route <ipv4-route>
vrouter running ipv4-route <ipv4-route># next-hop <next-hop> dhcp-port DHCP-PORT \
... distance <uint8> label <string> nexthop-vrf NEXTHOP-VRF tag <uint32> track TRACK
dhcp-port
dhcp-port DHCP-PORT
distance
distance <uint8>
label
Specify label(s) for this route. One or more labels in the range (16-1048575) separated by ‘/’.
label <string>
nexthop-vrf
Nexthop vrf.
nexthop-vrf NEXTHOP-VRF
tag
Route tag.
tag <uint32>
track
A tracker name. If the tracked address is reachable, the next-hop is considered as valid, else it is disabled.
track TRACK
ipv6-route
vrouter running config# vrf <vrf> routing static table <uint32> ipv6-route <ipv6-route>
next-hop
Route next-hops.
vrouter running config# vrf <vrf> routing static table <uint32> ipv6-route <ipv6-route>
vrouter running ipv6-route <ipv6-route># next-hop <next-hop> distance <uint8> \
... label <string> nexthop-vrf NEXTHOP-VRF tag <uint32> track TRACK
distance
distance <uint8>
label
Specify label(s) for this route. One or more labels in the range (16-1048575) separated by ‘/’.
label <string>
nexthop-vrf
Nexthop vrf.
nexthop-vrf NEXTHOP-VRF
tag
Route tag.
tag <uint32>
track
A tracker name. If the tracked address is reachable, the next-hop is considered as valid, else it is disabled.
track TRACK
interface
ip nhrp
enabled
Default value
true
registration-no-unique
Default value
false
shortcut
Default value
false
redirect
Default value
false
shortcut-keep-sa
Default value
false
network-id
holdtime
Default value
7200
ip-nhrp-mtu
MTU configuration.
Default value
default
nhrp-map
vrouter running config# vrf <vrf> routing interface <interface> ip nhrp nhrp-map <nhrp-
˓→map>
nbma
vrouter running config# vrf <vrf> routing interface <interface> ip nhrp nhrp-map <nhrp-
˓→map>
nhrp-nhs
vrouter running config# vrf <vrf> routing interface <interface> ip nhrp nhrp-nhs <nhrp-
˓→nhs>
nbma (mandatory)
vrouter running config# vrf <vrf> routing interface <interface> ip nhrp nhrp-nhs <nhrp-
˓→nhs>
ipv6 nhrp
vrouter running config# vrf <vrf> routing interface <interface> ipv6 nhrp
enabled
vrouter running config# vrf <vrf> routing interface <interface> ipv6 nhrp
vrouter running nhrp# enabled true|false
Default value
true
registration-no-unique
vrouter running config# vrf <vrf> routing interface <interface> ipv6 nhrp
vrouter running nhrp# registration-no-unique true|false
Default value
false
shortcut
vrouter running config# vrf <vrf> routing interface <interface> ipv6 nhrp
vrouter running nhrp# shortcut true|false
Default value
false
redirect
vrouter running config# vrf <vrf> routing interface <interface> ipv6 nhrp
vrouter running nhrp# redirect true|false
Default value
false
shortcut-keep-sa
vrouter running config# vrf <vrf> routing interface <interface> ipv6 nhrp
vrouter running nhrp# shortcut-keep-sa true|false
Default value
false
network-id
vrouter running config# vrf <vrf> routing interface <interface> ipv6 nhrp
vrouter running nhrp# network-id <uint32>
holdtime
vrouter running config# vrf <vrf> routing interface <interface> ipv6 nhrp
vrouter running nhrp# holdtime <uint16>
Default value
7200
nhrp-map
vrouter running config# vrf <vrf> routing interface <interface> ipv6 nhrp nhrp-map
˓→<nhrp-map>
nbma (mandatory)
vrouter running config# vrf <vrf> routing interface <interface> ipv6 nhrp nhrp-map
˓→<nhrp-map>
nhrp-nhs
vrouter running config# vrf <vrf> routing interface <interface> ipv6 nhrp nhrp-nhs
˓→<nhrp-nhs>
nbma (mandatory)
vrouter running config# vrf <vrf> routing interface <interface> ipv6 nhrp nhrp-nhs
˓→<nhrp-nhs>
ip ospf
OSPF configuration.
area
authentication
authentication-key
Authentication key.
cost
Interface cost.
hello-interval
mtu-ignore
priority
Router priority.
retransmit-interval
transmit-delay
network
Network type.
Default value
broadcast
message-digest-key
md5 (mandatory)
md5 <string>
dead-interval
seconds
Seconds.
seconds <uint16>
minimal
hello-multiplier (mandatory)
hello-multiplier <uint8>
address
vrouter running config# vrf <vrf> routing interface <interface> ip ospf address
˓→<address>
area
vrouter running config# vrf <vrf> routing interface <interface> ip ospf address
˓→<address>
authentication
vrouter running config# vrf <vrf> routing interface <interface> ip ospf address
˓→<address>
authentication-key
Authentication key.
vrouter running config# vrf <vrf> routing interface <interface> ip ospf address
˓→<address>
cost
Interface cost.
vrouter running config# vrf <vrf> routing interface <interface> ip ospf address
˓→<address>
hello-interval
vrouter running config# vrf <vrf> routing interface <interface> ip ospf address
˓→<address>
mtu-ignore
vrouter running config# vrf <vrf> routing interface <interface> ip ospf address
˓→<address>
priority
Router priority.
vrouter running config# vrf <vrf> routing interface <interface> ip ospf address
˓→<address>
retransmit-interval
vrouter running config# vrf <vrf> routing interface <interface> ip ospf address
˓→<address>
transmit-delay
vrouter running config# vrf <vrf> routing interface <interface> ip ospf address
˓→<address>
message-digest-key
vrouter running config# vrf <vrf> routing interface <interface> ip ospf address
˓→<address>
md5 (mandatory)
md5 <string>
dead-interval
vrouter running config# vrf <vrf> routing interface <interface> ip ospf address
˓→<address>
seconds
Seconds.
seconds <uint16>
minimal
hello-multiplier (mandatory)
hello-multiplier <uint8>
ipv6 ospf6
vrouter running config# vrf <vrf> routing interface <interface> ipv6 ospf6
cost
vrouter running config# vrf <vrf> routing interface <interface> ipv6 ospf6
vrouter running ospf6# cost <uint16>
dead-interval
vrouter running config# vrf <vrf> routing interface <interface> ipv6 ospf6
vrouter running ospf6# dead-interval <uint16>
hello-interval
vrouter running config# vrf <vrf> routing interface <interface> ipv6 ospf6
vrouter running ospf6# hello-interval <uint16>
ifmtu
vrouter running config# vrf <vrf> routing interface <interface> ipv6 ospf6
vrouter running ospf6# ifmtu <uint16>
instance-id
vrouter running config# vrf <vrf> routing interface <interface> ipv6 ospf6
vrouter running ospf6# instance-id <uint8>
mtu-ignore
vrouter running config# vrf <vrf> routing interface <interface> ipv6 ospf6
vrouter running ospf6# mtu-ignore true|false
network
Network type.
vrouter running config# vrf <vrf> routing interface <interface> ipv6 ospf6
vrouter running ospf6# network NETWORK
Default value
broadcast
passive
vrouter running config# vrf <vrf> routing interface <interface> ipv6 ospf6
vrouter running ospf6# passive true|false
priority
Router priority.
vrouter running config# vrf <vrf> routing interface <interface> ipv6 ospf6
vrouter running ospf6# priority <uint8>
retransmit-interval
vrouter running config# vrf <vrf> routing interface <interface> ipv6 ospf6
vrouter running ospf6# retransmit-interval <uint16>
transmit-delay
vrouter running config# vrf <vrf> routing interface <interface> ipv6 ospf6
vrouter running ospf6# transmit-delay <uint16>
advertise
Advertising options.
vrouter running config# vrf <vrf> routing interface <interface> ipv6 ospf6
vrouter running ospf6# advertise prefix-list <string>
prefix-list (mandatory)
prefix-list <string>
ip rip
RIP configuration.
v2-broadcast
Default value
false
split-horizon
Default value
simple
version
vrouter running config# vrf <vrf> routing interface <interface> ip rip version
receive
vrouter running config# vrf <vrf> routing interface <interface> ip rip version
vrouter running version# receive RECEIVE
Default value
inherit
send
vrouter running config# vrf <vrf> routing interface <interface> ip rip version
vrouter running version# send SEND
Default value
inherit
authentication
vrouter running config# vrf <vrf> routing interface <interface> ip rip authentication
mode
vrouter running config# vrf <vrf> routing interface <interface> ip rip authentication
vrouter running authentication# mode MODE
Default value
none
md5-auth-length
vrouter running config# vrf <vrf> routing interface <interface> ip rip authentication
vrouter running authentication# md5-auth-length MD5-AUTH-LENGTH
Default value
old-ripd
password
Authentication string.
vrouter running config# vrf <vrf> routing interface <interface> ip rip authentication
vrouter running authentication# password <string>
key-chain
Key-chain name.
vrouter running config# vrf <vrf> routing interface <interface> ip rip authentication
vrouter running authentication# key-chain <string>
ipv6 ripng
RIPng configuration.
vrouter running config# vrf <vrf> routing interface <interface> ipv6 ripng
split-horizon
vrouter running config# vrf <vrf> routing interface <interface> ipv6 ripng
vrouter running ripng# split-horizon SPLIT-HORIZON
Default value
simple
vrouter> show state vrf <vrf> routing evpn vni <vni> type
VXLAN name.
vrouter> show state vrf <vrf> routing evpn vni <vni> vxlan
vrouter> show state vrf <vrf> routing evpn vni <vni> num-mac
vrouter> show state vrf <vrf> routing evpn vni <vni> num-arp-nd
vrouter> show state vrf <vrf> routing evpn vni <vni> local-vtep-ip
vrouter> show state vrf <vrf> routing evpn vni <vni> advertise-gateway-mac-ip
VNI state.
vrouter> show state vrf <vrf> routing evpn vni <vni> state
vrouter> show state vrf <vrf> routing evpn vni <vni> router-mac
vrouter> show state vrf <vrf> routing evpn vni <vni> l2-vni
vrouter> show state vrf <vrf> routing evpn vni <vni> arp-neighbor-discovery <arp-
˓→neighbor-discovery> state
Default gateway.
vrouter> show state vrf <vrf> routing evpn vni <vni> arp-neighbor-discovery <arp-
˓→neighbor-discovery> default-gateway
vrouter> show state vrf <vrf> routing evpn vni <vni> arp-neighbor-discovery <arp-
˓→neighbor-discovery> mac
vrouter> show state vrf <vrf> routing evpn vni <vni> arp-neighbor-discovery <arp-
˓→neighbor-discovery> type
vrouter> show state vrf <vrf> routing evpn vni <vni> arp-neighbor-discovery <arp-
˓→neighbor-discovery> remote-vtep-ip
VLAN identifier.
vrouter> show state vrf <vrf> routing evpn vni <vni> mac <mac> vlan-id
vrouter> show state vrf <vrf> routing evpn vni <vni> mac <mac> type
vrouter> show state vrf <vrf> routing evpn vni <vni> mac <mac> remote-vtep-ip
bgp
enabled
Default value
true
as (mandatory)
BGP AS number.
AS A numeric identifier for an autonomous system (AS). An AS is a single domain, under common administra-
tive control, which forms a unit of routing policy. Autonomous systems can be assigned a 2-byte identifier,
or a 4-byte identifier which may have public or private scope. Private ASNs are assigned from dedicated
ranges. Public ASNs are assigned from ranges allocated by IANA to the regional internet registries (RIRs).
always-compare-med
Default value
false
cluster-id
coalesce-time
deterministic-med
If true, Pick the best-MED path among paths advertised from the neighboring AS.
Default value
false
ebgp-connected-route-check
Default value
true
fast-external-failover
If true, immediately reset session if a link to a directly connected external peer goes down.
Default value
true
graceful-shutdown
Enable or disable graceful shutdown. When enabled, EBGP route attributes are sent with the GRACE-
FUL_SHUTDOWN (see RFC8326) community and preference set to 0.
Default value
false
log-neighbor-changes
Default value
false
network-import-check
Default value
false
route-reflector-allow-outbound-policy
Default value
false
reject-as-sets
Some BGP routers may perform route aggregation, and because of that, those routers may use AS_SET and
AS_CONFED_SETS attributes that contain an unordered list of ASes that contributing prefixes in the aggregate
have traversed. Using those attributes may cause operational issues, because they blur the semantic of origin AS.
Default value
false
router-id
ebgp-requires-policy
Default value
false
bestpath
compare-routerid
Default value
false
med
MED attribute.
as-path
AS-path attribute.
confederation
If true, compare path lengths including confederation sets and sequences in selecting a route.
Default value
false
ignore
Default value
false
multipath-relax
Allow load sharing across routes that have different AS paths (but same length).
client-to-client
reflection
Default value
true
confederation
Parameters indicating whether the local system acts as part of a BGP confederation.
identifier
Confederation AS number. Setting the AS indicates that the local-AS is part of a BGP confederation.
peers
dampening
half-life
reuse
suppress
max-suppress-time
graceful-restart
preserve-fw-state
If true, sets F-bit indication that fib is preserved while doing Graceful Restart.
Default value
false
restart-time
Set the time to wait to delete stale routes before a BGP open message is received.
Default value
120
stalepath-time
Set the max time to hold onto restarting peer’s stale paths.
Default value
360
listen
limit
Default value
100
neighbor-range
neighbor-group (mandatory)
neighbor-group <neighbor-group>
max-med
administrative
on-startup
Effective on a startup.
period (mandatory)
max-med
Default value
4294967295
packet-rw-quantum
read
Default value
10
write
Default value
64
tcp-keepalive
idle
Default value
10
keepalive
Default value
10
probes
Default value
3
update-delay
delay
Default value
0
established-wait
address-family
ipv4-unicast
table-map
enabled
Default value
true
dampening
vrouter> show state vrf <vrf> routing bgp address-family ipv4-unicast rib-count
vrouter> show state vrf <vrf> routing bgp address-family ipv4-unicast neighbor-count
vrouter> show state vrf <vrf> routing bgp address-family ipv4-unicast dynamic-neighbor-
˓→count
network
vrouter running config# vrf <vrf> routing bgp address-family ipv4-unicast network
˓→<network>
route-map
Route-map name.
vrouter running config# vrf <vrf> routing bgp address-family ipv4-unicast network
˓→<network>
backdoor
vrouter running config# vrf <vrf> routing bgp address-family ipv4-unicast network
˓→<network>
Default value
false
label-index
vrouter running config# vrf <vrf> routing bgp address-family ipv4-unicast network
˓→<network>
Route state.
vrouter> show state vrf <vrf> routing bgp address-family ipv4-unicast network <network>
˓→ route <string> status
vrouter> show state vrf <vrf> routing bgp address-family ipv4-unicast network <network>
˓→ route <string> stale
vrouter> show state vrf <vrf> routing bgp address-family ipv4-unicast network <network>
˓→ route <string> suppressed
vrouter> show state vrf <vrf> routing bgp address-family ipv4-unicast network <network>
˓→ route <string> history
vrouter> show state vrf <vrf> routing bgp address-family ipv4-unicast network <network>
˓→ route <string> damped
Selected route considered as the preferred one in the local routing context.
vrouter> show state vrf <vrf> routing bgp address-family ipv4-unicast network <network>
˓→ route <string> bestpath
vrouter> show state vrf <vrf> routing bgp address-family ipv4-unicast network <network>
˓→ route <string> multipath
Route validity.
vrouter> show state vrf <vrf> routing bgp address-family ipv4-unicast network <network>
˓→ route <string> validity
vrouter> show state vrf <vrf> routing bgp address-family ipv4-unicast network <network>
˓→ route <string> route-type
Route prefix.
vrouter> show state vrf <vrf> routing bgp address-family ipv4-unicast network <network>
˓→ route <string> prefix
vrouter> show state vrf <vrf> routing bgp address-family ipv4-unicast network <network>
˓→ route <string> prefix-length
Route metric.
vrouter> show state vrf <vrf> routing bgp address-family ipv4-unicast network <network>
˓→ route <string> metric
Route origin.
vrouter> show state vrf <vrf> routing bgp address-family ipv4-unicast network <network>
˓→ route <string> origin
Path network.
vrouter> show state vrf <vrf> routing bgp address-family ipv4-unicast network <network>
˓→ route <string> network
Local preference.
vrouter> show state vrf <vrf> routing bgp address-family ipv4-unicast network <network>
˓→ route <string> local-preference
Weight.
vrouter> show state vrf <vrf> routing bgp address-family ipv4-unicast network <network>
˓→ route <string> weight
Packet length.
vrouter> show state vrf <vrf> routing bgp address-family ipv4-unicast network <network>
˓→ route <string> packet-length
AS path.
vrouter> show state vrf <vrf> routing bgp address-family ipv4-unicast network <network>
˓→ route <string> path
Route nexthop.
vrouter> show state vrf <vrf> routing bgp address-family ipv4-unicast network <network>
˓→ route <string> nexthop <nexthop> address-family
Nexthop used.
vrouter> show state vrf <vrf> routing bgp address-family ipv4-unicast network <network>
˓→ route <string> nexthop <nexthop> used
redistribute
id
id <uint32>
metric
metric <uint32>
route-map
Route-map name.
route-map ROUTE-MAP
route-target
vrouter running config# vrf <vrf> routing bgp address-family ipv4-unicast route-target
redirect-import
Flow-spec redirect type route target, Import routes to this address- family.
vrouter running config# vrf <vrf> routing bgp address-family ipv4-unicast route-target
vrouter running route-target# redirect-import REDIRECT-IMPORT
l3vpn
Specify route-target and route-distinguisher between this address family and VPN.
vrouter running config# vrf <vrf> routing bgp address-family ipv4-unicast l3vpn
export
vrouter running config# vrf <vrf> routing bgp address-family ipv4-unicast l3vpn export
vpn
vrouter running config# vrf <vrf> routing bgp address-family ipv4-unicast l3vpn export
vrouter running export# vpn true|false
Default value
false
label
vrouter running config# vrf <vrf> routing bgp address-family ipv4-unicast l3vpn export
vrouter running export# label LABEL
route-target
vrouter running config# vrf <vrf> routing bgp address-family ipv4-unicast l3vpn export
vrouter running export# route-target ROUTE-TARGET
route-distinguisher
vrouter running config# vrf <vrf> routing bgp address-family ipv4-unicast l3vpn export
vrouter running export# route-distinguisher ROUTE-DISTINGUISHER
Description
ROUTE-DISTINGUISHER
values
<string> Type definition for extended community attributes. In the case that common communities are
utilised, they are represented as a string of the form: - <2b AS>:<4b value> per RFC4360 section
3.1 - <4b IPv4>:<2b value> per RFC4360 section 3.2.
<string> Type definition for extended community attributes. In the case that common communities are
utilised, they are represented as a string of the form: - <2b AS>:<4b value> per RFC4360 section
3.1 - <4b IPv4>:<2b value> per RFC4360 section 3.2.
nexthop
Specify next hop to use for VRF advertised prefixes between the current address-family and VPN.
vrouter running config# vrf <vrf> routing bgp address-family ipv4-unicast l3vpn export
vrouter running export# nexthop NEXTHOP
route-map
vrouter running config# vrf <vrf> routing bgp address-family ipv4-unicast l3vpn export
vrouter running export# route-map ROUTE-MAP
import
vrouter running config# vrf <vrf> routing bgp address-family ipv4-unicast l3vpn import
vpn
vrouter running config# vrf <vrf> routing bgp address-family ipv4-unicast l3vpn import
vrouter running import# vpn true|false
Default value
false
route-target
vrouter running config# vrf <vrf> routing bgp address-family ipv4-unicast l3vpn import
vrouter running import# route-target ROUTE-TARGET
route-map
vrouter running config# vrf <vrf> routing bgp address-family ipv4-unicast l3vpn import
vrouter running import# route-map ROUTE-MAP
maximum-path
vrouter running config# vrf <vrf> routing bgp address-family ipv4-unicast maximum-path
ebgp
vrouter running config# vrf <vrf> routing bgp address-family ipv4-unicast maximum-path
vrouter running maximum-path# ebgp <uint8>
Default value
16
ibgp
vrouter running config# vrf <vrf> routing bgp address-family ipv4-unicast maximum-path
vrouter running maximum-path# ibgp <uint8>
Default value
16
equal-cluster-length
vrouter running config# vrf <vrf> routing bgp address-family ipv4-unicast maximum-path
vrouter running maximum-path# equal-cluster-length true|false
Default value
false
aggregate-address
as-set
as-set true|false
Default value
false
summary-only
summary-only true|false
Default value
false
route-map
route-map ROUTE-MAP
administrative-distance
distance (mandatory)
Administrative distance.
distance <uint8>
access-list
access-list ACCESS-LIST
bgp-distance
vrouter running config# vrf <vrf> routing bgp address-family ipv4-unicast bgp-distance
external-routes
vrouter running config# vrf <vrf> routing bgp address-family ipv4-unicast bgp-distance
vrouter running bgp-distance# external-routes <uint8>
Default value
20
internal-routes
vrouter running config# vrf <vrf> routing bgp address-family ipv4-unicast bgp-distance
vrouter running bgp-distance# internal-routes <uint8>
Default value
200
local-routes
vrouter running config# vrf <vrf> routing bgp address-family ipv4-unicast bgp-distance
vrouter running bgp-distance# local-routes <uint8>
Default value
200
route-flap-dampening
vrouter running config# vrf <vrf> routing bgp address-family ipv4-unicast route-flap-
˓→dampening
enabled
vrouter running config# vrf <vrf> routing bgp address-family ipv4-unicast route-flap-
˓→dampening
Default value
false
reach-decay
This value specifies the time desired for the instability metric value to reach one-half of its current value when the
route is reachable. This half-life value determines the rate at which the metric value is decayed. A smaller half-life
value makes a suppressed route reusable sooner than a larger value. The accumulated penalty will be reduced to
half after this duration.
vrouter running config# vrf <vrf> routing bgp address-family ipv4-unicast route-flap-
˓→dampening
Default value
15
reuse-above
This is the value of the instability metric at which a suppressed route becomes unsuppressed if it is reachable but
currently suppressed. The value assigned to reuse-below must be less than suppress-above.
vrouter running config# vrf <vrf> routing bgp address-family ipv4-unicast route-flap-
˓→dampening
Default value
750
suppress-above
This is the value of the instability metric at which route suppression takes place. A route is not installed in the
forwarding information base (FIB), or announced even if it is reachable during the period that it is suppressed.
vrouter running config# vrf <vrf> routing bgp address-family ipv4-unicast route-flap-
˓→dampening
Default value
2000
unreach-decay
This value acts the same as reach-decay except that it specifies the rate at which the instability metric is decayed
when a route is unreachable. It should have a value greater than or equal to reach- decay.
vrouter running config# vrf <vrf> routing bgp address-family ipv4-unicast route-flap-
˓→dampening
Default value
60
ipv4-multicast
table-map
enabled
Default value
true
dampening
vrouter> show state vrf <vrf> routing bgp address-family ipv4-multicast rib-count
vrouter> show state vrf <vrf> routing bgp address-family ipv4-multicast neighbor-count
vrouter> show state vrf <vrf> routing bgp address-family ipv4-multicast dynamic-
˓→neighbor-count
network
vrouter running config# vrf <vrf> routing bgp address-family ipv4-multicast network
˓→<network>
route-map
Route-map name.
vrouter running config# vrf <vrf> routing bgp address-family ipv4-multicast network
˓→<network>
backdoor
vrouter running config# vrf <vrf> routing bgp address-family ipv4-multicast network
˓→<network>
Default value
false
label-index
vrouter running config# vrf <vrf> routing bgp address-family ipv4-multicast network
˓→<network>
Route state.
vrouter> show state vrf <vrf> routing bgp address-family ipv4-multicast network
˓→<network> route <string> status
vrouter> show state vrf <vrf> routing bgp address-family ipv4-multicast network
˓→<network> route <string> stale
vrouter> show state vrf <vrf> routing bgp address-family ipv4-multicast network
˓→<network> route <string> suppressed
vrouter> show state vrf <vrf> routing bgp address-family ipv4-multicast network
˓→<network> route <string> history
vrouter> show state vrf <vrf> routing bgp address-family ipv4-multicast network
˓→<network> route <string> damped
Selected route considered as the preferred one in the local routing context.
vrouter> show state vrf <vrf> routing bgp address-family ipv4-multicast network
˓→<network> route <string> bestpath
vrouter> show state vrf <vrf> routing bgp address-family ipv4-multicast network
˓→<network> route <string> multipath
Route validity.
vrouter> show state vrf <vrf> routing bgp address-family ipv4-multicast network
˓→<network> route <string> validity
vrouter> show state vrf <vrf> routing bgp address-family ipv4-multicast network
˓→<network> route <string> route-type
Route prefix.
vrouter> show state vrf <vrf> routing bgp address-family ipv4-multicast network
˓→<network> route <string> prefix
vrouter> show state vrf <vrf> routing bgp address-family ipv4-multicast network
˓→<network> route <string> prefix-length
Route metric.
vrouter> show state vrf <vrf> routing bgp address-family ipv4-multicast network
˓→<network> route <string> metric
Route origin.
vrouter> show state vrf <vrf> routing bgp address-family ipv4-multicast network
˓→<network> route <string> origin
Path network.
vrouter> show state vrf <vrf> routing bgp address-family ipv4-multicast network
˓→<network> route <string> network
Local preference.
vrouter> show state vrf <vrf> routing bgp address-family ipv4-multicast network
˓→<network> route <string> local-preference
Weight.
vrouter> show state vrf <vrf> routing bgp address-family ipv4-multicast network
˓→<network> route <string> weight
Packet length.
vrouter> show state vrf <vrf> routing bgp address-family ipv4-multicast network
˓→<network> route <string> packet-length
AS path.
vrouter> show state vrf <vrf> routing bgp address-family ipv4-multicast network
˓→<network> route <string> path
Route nexthop.
vrouter> show state vrf <vrf> routing bgp address-family ipv4-multicast network
˓→<network> route <string> nexthop <nexthop> address-family
Nexthop used.
vrouter> show state vrf <vrf> routing bgp address-family ipv4-multicast network
˓→<network> route <string> nexthop <nexthop> used
aggregate-address
as-set
as-set true|false
Default value
false
summary-only
summary-only true|false
Default value
false
route-map
route-map ROUTE-MAP
administrative-distance
distance (mandatory)
Administrative distance.
distance <uint8>
access-list
access-list ACCESS-LIST
bgp-distance
vrouter running config# vrf <vrf> routing bgp address-family ipv4-multicast bgp-
˓→distance
external-routes
vrouter running config# vrf <vrf> routing bgp address-family ipv4-multicast bgp-
˓→distance
Default value
20
internal-routes
vrouter running config# vrf <vrf> routing bgp address-family ipv4-multicast bgp-
˓→distance
Default value
200
local-routes
vrouter running config# vrf <vrf> routing bgp address-family ipv4-multicast bgp-
˓→distance
Default value
200
route-flap-dampening
vrouter running config# vrf <vrf> routing bgp address-family ipv4-multicast route-flap-
˓→dampening
enabled
vrouter running config# vrf <vrf> routing bgp address-family ipv4-multicast route-flap-
˓→dampening
Default value
false
reach-decay
This value specifies the time desired for the instability metric value to reach one-half of its current value when the
route is reachable. This half-life value determines the rate at which the metric value is decayed. A smaller half-life
value makes a suppressed route reusable sooner than a larger value. The accumulated penalty will be reduced to
half after this duration.
vrouter running config# vrf <vrf> routing bgp address-family ipv4-multicast route-flap-
˓→dampening
Default value
15
reuse-above
This is the value of the instability metric at which a suppressed route becomes unsuppressed if it is reachable but
currently suppressed. The value assigned to reuse-below must be less than suppress-above.
vrouter running config# vrf <vrf> routing bgp address-family ipv4-multicast route-flap-
˓→dampening
Default value
750
suppress-above
This is the value of the instability metric at which route suppression takes place. A route is not installed in the
forwarding information base (FIB), or announced even if it is reachable during the period that it is suppressed.
vrouter running config# vrf <vrf> routing bgp address-family ipv4-multicast route-flap-
˓→dampening
Default value
2000
unreach-decay
This value acts the same as reach-decay except that it specifies the rate at which the instability metric is decayed
when a route is unreachable. It should have a value greater than or equal to reach- decay.
vrouter running config# vrf <vrf> routing bgp address-family ipv4-multicast route-flap-
˓→dampening
Default value
60
ipv4-flowspec
enabled
Default value
true
local-install
Interface name.
vrouter> show state vrf <vrf> routing bgp address-family ipv4-flowspec rib-count
vrouter> show state vrf <vrf> routing bgp address-family ipv4-flowspec neighbor-count
vrouter> show state vrf <vrf> routing bgp address-family ipv4-flowspec dynamic-
˓→neighbor-count
to (state only)
vrouter> show state vrf <vrf> routing bgp address-family ipv4-flowspec route <uint32>␣
˓→to
vrouter> show state vrf <vrf> routing bgp address-family ipv4-flowspec route <uint32>␣
˓→from
vrouter> show state vrf <vrf> routing bgp address-family ipv4-flowspec route <uint32>␣
˓→peer-id
Route state.
vrouter> show state vrf <vrf> routing bgp address-family ipv4-flowspec route <uint32>␣
˓→status
vrouter> show state vrf <vrf> routing bgp address-family ipv4-flowspec route <uint32>␣
˓→stale
vrouter> show state vrf <vrf> routing bgp address-family ipv4-flowspec route <uint32>␣
˓→suppressed
vrouter> show state vrf <vrf> routing bgp address-family ipv4-flowspec route <uint32>␣
˓→history
vrouter> show state vrf <vrf> routing bgp address-family ipv4-flowspec route <uint32>␣
˓→damped
Selected route considered as the preferred one in the local routing context.
vrouter> show state vrf <vrf> routing bgp address-family ipv4-flowspec route <uint32>␣
˓→bestpath
vrouter> show state vrf <vrf> routing bgp address-family ipv4-flowspec route <uint32>␣
˓→multipath
Route validity.
vrouter> show state vrf <vrf> routing bgp address-family ipv4-flowspec route <uint32>␣
˓→validity
vrouter> show state vrf <vrf> routing bgp address-family ipv4-flowspec route <uint32>␣
˓→route-type
Route prefix.
vrouter> show state vrf <vrf> routing bgp address-family ipv4-flowspec route <uint32>␣
˓→prefix
vrouter> show state vrf <vrf> routing bgp address-family ipv4-flowspec route <uint32>␣
˓→prefix-length
Route metric.
vrouter> show state vrf <vrf> routing bgp address-family ipv4-flowspec route <uint32>␣
˓→metric
Route origin.
vrouter> show state vrf <vrf> routing bgp address-family ipv4-flowspec route <uint32>␣
˓→origin
Path network.
vrouter> show state vrf <vrf> routing bgp address-family ipv4-flowspec route <uint32>␣
˓→network
Local preference.
vrouter> show state vrf <vrf> routing bgp address-family ipv4-flowspec route <uint32>␣
˓→local-preference
Weight.
vrouter> show state vrf <vrf> routing bgp address-family ipv4-flowspec route <uint32>␣
˓→weight
Packet length.
vrouter> show state vrf <vrf> routing bgp address-family ipv4-flowspec route <uint32>␣
˓→packet-length
AS path.
vrouter> show state vrf <vrf> routing bgp address-family ipv4-flowspec route <uint32>␣
˓→path
Route nexthop.
vrouter> show state vrf <vrf> routing bgp address-family ipv4-flowspec route <uint32>␣
˓→nexthop <nexthop> address-family
Nexthop used.
vrouter> show state vrf <vrf> routing bgp address-family ipv4-flowspec route <uint32>␣
˓→nexthop <nexthop> used
ipv4-labeled-unicast
enabled
Default value
true
vrouter> show state vrf <vrf> routing bgp address-family ipv4-labeled-unicast rib-count
vrouter> show state vrf <vrf> routing bgp address-family ipv4-labeled-unicast neighbor-
˓→count
vrouter> show state vrf <vrf> routing bgp address-family ipv4-labeled-unicast dynamic-
˓→neighbor-count
route-flap-dampening
enabled
Default value
false
reach-decay
This value specifies the time desired for the instability metric value to reach one-half of its current value when the
route is reachable. This half-life value determines the rate at which the metric value is decayed. A smaller half-life
value makes a suppressed route reusable sooner than a larger value. The accumulated penalty will be reduced to
half after this duration.
Default value
15
reuse-above
This is the value of the instability metric at which a suppressed route becomes unsuppressed if it is reachable but
currently suppressed. The value assigned to reuse-below must be less than suppress-above.
Default value
750
suppress-above
This is the value of the instability metric at which route suppression takes place. A route is not installed in the
forwarding information base (FIB), or announced even if it is reachable during the period that it is suppressed.
Default value
2000
unreach-decay
This value acts the same as reach-decay except that it specifies the rate at which the instability metric is decayed
when a route is unreachable. It should have a value greater than or equal to reach- decay.
Default value
60
ipv4-vpn
enabled
Default value
true
vrouter> show state vrf <vrf> routing bgp address-family ipv4-vpn rib-count
vrouter> show state vrf <vrf> routing bgp address-family ipv4-vpn neighbor-count
vrouter> show state vrf <vrf> routing bgp address-family ipv4-vpn dynamic-neighbor-
˓→count
route-distinguisher
vrouter running config# vrf <vrf> routing bgp address-family ipv4-vpn route-
˓→distinguisher <rd> <ip-prefix>
<rd> Description
val-
ues
<string>Type definition for extended community attributes. In the case that common communities are utilised,
they are represented as a string of the form: - <2b AS>:<4b value> per RFC4360 section 3.1 - <4b
IPv4>:<2b value> per RFC4360 section 3.2.
<string>Type definition for extended community attributes. In the case that common communities are utilised,
they are represented as a string of the form: - <2b AS>:<4b value> per RFC4360 section 3.1 - <4b
IPv4>:<2b value> per RFC4360 section 3.2.
label
vrouter running config# vrf <vrf> routing bgp address-family ipv4-vpn route-
˓→distinguisher <rd> <ip-prefix>
route-map
vrouter running config# vrf <vrf> routing bgp address-family ipv4-vpn route-
˓→distinguisher <rd> <ip-prefix>
Route state.
vrouter> show state vrf <vrf> routing bgp address-family ipv4-vpn route-distinguisher
˓→<rd> <ip-prefix> route <string> status
vrouter> show state vrf <vrf> routing bgp address-family ipv4-vpn route-distinguisher
˓→<rd> <ip-prefix> route <string> stale
vrouter> show state vrf <vrf> routing bgp address-family ipv4-vpn route-distinguisher
˓→<rd> <ip-prefix> route <string> suppressed
vrouter> show state vrf <vrf> routing bgp address-family ipv4-vpn route-distinguisher
˓→<rd> <ip-prefix> route <string> history
vrouter> show state vrf <vrf> routing bgp address-family ipv4-vpn route-distinguisher
˓→<rd> <ip-prefix> route <string> damped
Selected route considered as the preferred one in the local routing context.
vrouter> show state vrf <vrf> routing bgp address-family ipv4-vpn route-distinguisher
˓→<rd> <ip-prefix> route <string> bestpath
vrouter> show state vrf <vrf> routing bgp address-family ipv4-vpn route-distinguisher
˓→<rd> <ip-prefix> route <string> multipath
Route validity.
vrouter> show state vrf <vrf> routing bgp address-family ipv4-vpn route-distinguisher
˓→<rd> <ip-prefix> route <string> validity
vrouter> show state vrf <vrf> routing bgp address-family ipv4-vpn route-distinguisher
˓→<rd> <ip-prefix> route <string> route-type
Route prefix.
vrouter> show state vrf <vrf> routing bgp address-family ipv4-vpn route-distinguisher
˓→<rd> <ip-prefix> route <string> prefix
vrouter> show state vrf <vrf> routing bgp address-family ipv4-vpn route-distinguisher
˓→<rd> <ip-prefix> route <string> prefix-length
Route metric.
vrouter> show state vrf <vrf> routing bgp address-family ipv4-vpn route-distinguisher
˓→<rd> <ip-prefix> route <string> metric
Route origin.
vrouter> show state vrf <vrf> routing bgp address-family ipv4-vpn route-distinguisher
˓→<rd> <ip-prefix> route <string> origin
Path network.
vrouter> show state vrf <vrf> routing bgp address-family ipv4-vpn route-distinguisher
˓→<rd> <ip-prefix> route <string> network
Local preference.
vrouter> show state vrf <vrf> routing bgp address-family ipv4-vpn route-distinguisher
˓→<rd> <ip-prefix> route <string> local-preference
Weight.
vrouter> show state vrf <vrf> routing bgp address-family ipv4-vpn route-distinguisher
˓→<rd> <ip-prefix> route <string> weight
Packet length.
vrouter> show state vrf <vrf> routing bgp address-family ipv4-vpn route-distinguisher
˓→<rd> <ip-prefix> route <string> packet-length
AS path.
vrouter> show state vrf <vrf> routing bgp address-family ipv4-vpn route-distinguisher
˓→<rd> <ip-prefix> route <string> path
Route nexthop.
vrouter> show state vrf <vrf> routing bgp address-family ipv4-vpn route-distinguisher
˓→<rd> <ip-prefix> route <string> nexthop <nexthop> address-family
Nexthop used.
vrouter> show state vrf <vrf> routing bgp address-family ipv4-vpn route-distinguisher
˓→<rd> <ip-prefix> route <string> nexthop <nexthop> used
ipv6-unicast
table-map
enabled
Default value
true
vrouter> show state vrf <vrf> routing bgp address-family ipv6-unicast rib-count
vrouter> show state vrf <vrf> routing bgp address-family ipv6-unicast neighbor-count
vrouter> show state vrf <vrf> routing bgp address-family ipv6-unicast dynamic-neighbor-
˓→count
network
vrouter running config# vrf <vrf> routing bgp address-family ipv6-unicast network
˓→<network>
route-map
Route-map name.
vrouter running config# vrf <vrf> routing bgp address-family ipv6-unicast network
˓→<network>
label-index
vrouter running config# vrf <vrf> routing bgp address-family ipv6-unicast network
˓→<network>
Route state.
vrouter> show state vrf <vrf> routing bgp address-family ipv6-unicast network <network>
˓→ route <string> status
vrouter> show state vrf <vrf> routing bgp address-family ipv6-unicast network <network>
˓→ route <string> stale
vrouter> show state vrf <vrf> routing bgp address-family ipv6-unicast network <network>
˓→ route <string> suppressed
vrouter> show state vrf <vrf> routing bgp address-family ipv6-unicast network <network>
˓→ route <string> history
vrouter> show state vrf <vrf> routing bgp address-family ipv6-unicast network <network>
˓→ route <string> damped
Selected route considered as the preferred one in the local routing context.
vrouter> show state vrf <vrf> routing bgp address-family ipv6-unicast network <network>
˓→ route <string> bestpath
vrouter> show state vrf <vrf> routing bgp address-family ipv6-unicast network <network>
˓→ route <string> multipath
Route validity.
vrouter> show state vrf <vrf> routing bgp address-family ipv6-unicast network <network>
˓→ route <string> validity
vrouter> show state vrf <vrf> routing bgp address-family ipv6-unicast network <network>
˓→ route <string> route-type
Route prefix.
vrouter> show state vrf <vrf> routing bgp address-family ipv6-unicast network <network>
˓→ route <string> prefix
vrouter> show state vrf <vrf> routing bgp address-family ipv6-unicast network <network>
˓→ route <string> prefix-length
Route metric.
vrouter> show state vrf <vrf> routing bgp address-family ipv6-unicast network <network>
˓→ route <string> metric
Route origin.
vrouter> show state vrf <vrf> routing bgp address-family ipv6-unicast network <network>
˓→ route <string> origin
Path network.
vrouter> show state vrf <vrf> routing bgp address-family ipv6-unicast network <network>
˓→ route <string> network
Local preference.
vrouter> show state vrf <vrf> routing bgp address-family ipv6-unicast network <network>
˓→ route <string> local-preference
Weight.
vrouter> show state vrf <vrf> routing bgp address-family ipv6-unicast network <network>
˓→ route <string> weight
Packet length.
vrouter> show state vrf <vrf> routing bgp address-family ipv6-unicast network <network>
˓→ route <string> packet-length
AS path.
vrouter> show state vrf <vrf> routing bgp address-family ipv6-unicast network <network>
˓→ route <string> path
Route nexthop.
vrouter> show state vrf <vrf> routing bgp address-family ipv6-unicast network <network>
˓→ route <string> nexthop <nexthop> address-family
Nexthop used.
vrouter> show state vrf <vrf> routing bgp address-family ipv6-unicast network <network>
˓→ route <string> nexthop <nexthop> used
aggregate-address
as-set
as-set true|false
Default value
false
summary-only
summary-only true|false
Default value
false
route-map
route-map ROUTE-MAP
redistribute
metric
metric <uint32>
route-map
Route-map name.
route-map ROUTE-MAP
ipv6-route-target
vrouter running config# vrf <vrf> routing bgp address-family ipv6-unicast ipv6-route-
˓→target
redirect-import
Flow-spec redirect ipv6 type route target, Import routes to this address-family.
vrouter running config# vrf <vrf> routing bgp address-family ipv6-unicast ipv6-route-
˓→target
REDIRECT-
An IPv6 route target is a 20-octet BGP IPv6 address specific extended community serving the same
IMPORT function as a standard 8-octet route target only allowing for an IPv6 address as the global administra-
tor. The format is <ipv6-address:2-octet-number>. Some valid examples are: 2001:DB8::1:6544 and
2001:DB8::5eb1:791:6b37:17958.
administrative-distance
distance (mandatory)
Administrative distance.
distance <uint8>
access-list
access-list ACCESS-LIST
l3vpn
Specify route-target and route-distinguisher between this address family and VPN.
vrouter running config# vrf <vrf> routing bgp address-family ipv6-unicast l3vpn
export
vrouter running config# vrf <vrf> routing bgp address-family ipv6-unicast l3vpn export
vpn
vrouter running config# vrf <vrf> routing bgp address-family ipv6-unicast l3vpn export
vrouter running export# vpn true|false
Default value
false
label
vrouter running config# vrf <vrf> routing bgp address-family ipv6-unicast l3vpn export
vrouter running export# label LABEL
route-target
vrouter running config# vrf <vrf> routing bgp address-family ipv6-unicast l3vpn export
vrouter running export# route-target ROUTE-TARGET
route-distinguisher
vrouter running config# vrf <vrf> routing bgp address-family ipv6-unicast l3vpn export
vrouter running export# route-distinguisher ROUTE-DISTINGUISHER
Description
ROUTE-DISTINGUISHER
values
<string> Type definition for extended community attributes. In the case that common communities are
utilised, they are represented as a string of the form: - <2b AS>:<4b value> per RFC4360 section
3.1 - <4b IPv4>:<2b value> per RFC4360 section 3.2.
<string> Type definition for extended community attributes. In the case that common communities are
utilised, they are represented as a string of the form: - <2b AS>:<4b value> per RFC4360 section
3.1 - <4b IPv4>:<2b value> per RFC4360 section 3.2.
nexthop
Specify next hop to use for VRF advertised prefixes between the current address-family and VPN.
vrouter running config# vrf <vrf> routing bgp address-family ipv6-unicast l3vpn export
vrouter running export# nexthop NEXTHOP
route-map
vrouter running config# vrf <vrf> routing bgp address-family ipv6-unicast l3vpn export
vrouter running export# route-map ROUTE-MAP
import
vrouter running config# vrf <vrf> routing bgp address-family ipv6-unicast l3vpn import
vpn
vrouter running config# vrf <vrf> routing bgp address-family ipv6-unicast l3vpn import
vrouter running import# vpn true|false
Default value
false
route-target
vrouter running config# vrf <vrf> routing bgp address-family ipv6-unicast l3vpn import
vrouter running import# route-target ROUTE-TARGET
route-map
vrouter running config# vrf <vrf> routing bgp address-family ipv6-unicast l3vpn import
vrouter running import# route-map ROUTE-MAP
maximum-path
vrouter running config# vrf <vrf> routing bgp address-family ipv6-unicast maximum-path
ebgp
vrouter running config# vrf <vrf> routing bgp address-family ipv6-unicast maximum-path
vrouter running maximum-path# ebgp <uint8>
Default value
16
ibgp
vrouter running config# vrf <vrf> routing bgp address-family ipv6-unicast maximum-path
vrouter running maximum-path# ibgp <uint8>
Default value
16
equal-cluster-length
vrouter running config# vrf <vrf> routing bgp address-family ipv6-unicast maximum-path
vrouter running maximum-path# equal-cluster-length true|false
Default value
false
bgp-distance
vrouter running config# vrf <vrf> routing bgp address-family ipv6-unicast bgp-distance
external-routes
vrouter running config# vrf <vrf> routing bgp address-family ipv6-unicast bgp-distance
vrouter running bgp-distance# external-routes <uint8>
Default value
20
internal-routes
vrouter running config# vrf <vrf> routing bgp address-family ipv6-unicast bgp-distance
vrouter running bgp-distance# internal-routes <uint8>
Default value
200
local-routes
vrouter running config# vrf <vrf> routing bgp address-family ipv6-unicast bgp-distance
vrouter running bgp-distance# local-routes <uint8>
Default value
200
route-flap-dampening
vrouter running config# vrf <vrf> routing bgp address-family ipv6-unicast route-flap-
˓→dampening
enabled
vrouter running config# vrf <vrf> routing bgp address-family ipv6-unicast route-flap-
˓→dampening
Default value
false
reach-decay
This value specifies the time desired for the instability metric value to reach one-half of its current value when the
route is reachable. This half-life value determines the rate at which the metric value is decayed. A smaller half-life
value makes a suppressed route reusable sooner than a larger value. The accumulated penalty will be reduced to
half after this duration.
vrouter running config# vrf <vrf> routing bgp address-family ipv6-unicast route-flap-
˓→dampening
Default value
15
reuse-above
This is the value of the instability metric at which a suppressed route becomes unsuppressed if it is reachable but
currently suppressed. The value assigned to reuse-below must be less than suppress-above.
vrouter running config# vrf <vrf> routing bgp address-family ipv6-unicast route-flap-
˓→dampening
Default value
750
suppress-above
This is the value of the instability metric at which route suppression takes place. A route is not installed in the
forwarding information base (FIB), or announced even if it is reachable during the period that it is suppressed.
vrouter running config# vrf <vrf> routing bgp address-family ipv6-unicast route-flap-
˓→dampening
Default value
2000
unreach-decay
This value acts the same as reach-decay except that it specifies the rate at which the instability metric is decayed
when a route is unreachable. It should have a value greater than or equal to reach- decay.
vrouter running config# vrf <vrf> routing bgp address-family ipv6-unicast route-flap-
˓→dampening
Default value
60
ipv6-flowspec
enabled
Default value
true
local-install
Interface name.
vrouter> show state vrf <vrf> routing bgp address-family ipv6-flowspec rib-count
vrouter> show state vrf <vrf> routing bgp address-family ipv6-flowspec neighbor-count
vrouter> show state vrf <vrf> routing bgp address-family ipv6-flowspec dynamic-
˓→neighbor-count
to (state only)
vrouter> show state vrf <vrf> routing bgp address-family ipv6-flowspec route <uint32>␣
˓→to
vrouter> show state vrf <vrf> routing bgp address-family ipv6-flowspec route <uint32>␣
˓→from
vrouter> show state vrf <vrf> routing bgp address-family ipv6-flowspec route <uint32>␣
˓→peer-id
Route state.
vrouter> show state vrf <vrf> routing bgp address-family ipv6-flowspec route <uint32>␣
˓→status
vrouter> show state vrf <vrf> routing bgp address-family ipv6-flowspec route <uint32>␣
˓→stale
vrouter> show state vrf <vrf> routing bgp address-family ipv6-flowspec route <uint32>␣
˓→suppressed
vrouter> show state vrf <vrf> routing bgp address-family ipv6-flowspec route <uint32>␣
˓→history
vrouter> show state vrf <vrf> routing bgp address-family ipv6-flowspec route <uint32>␣
˓→damped
Selected route considered as the preferred one in the local routing context.
vrouter> show state vrf <vrf> routing bgp address-family ipv6-flowspec route <uint32>␣
˓→bestpath
vrouter> show state vrf <vrf> routing bgp address-family ipv6-flowspec route <uint32>␣
˓→multipath
Route validity.
vrouter> show state vrf <vrf> routing bgp address-family ipv6-flowspec route <uint32>␣
˓→validity
vrouter> show state vrf <vrf> routing bgp address-family ipv6-flowspec route <uint32>␣
˓→route-type
Route prefix.
vrouter> show state vrf <vrf> routing bgp address-family ipv6-flowspec route <uint32>␣
˓→prefix
vrouter> show state vrf <vrf> routing bgp address-family ipv6-flowspec route <uint32>␣
˓→prefix-length
Route metric.
vrouter> show state vrf <vrf> routing bgp address-family ipv6-flowspec route <uint32>␣
˓→metric
Route origin.
vrouter> show state vrf <vrf> routing bgp address-family ipv6-flowspec route <uint32>␣
˓→origin
Path network.
vrouter> show state vrf <vrf> routing bgp address-family ipv6-flowspec route <uint32>␣
˓→network
Local preference.
vrouter> show state vrf <vrf> routing bgp address-family ipv6-flowspec route <uint32>␣
˓→local-preference
Weight.
vrouter> show state vrf <vrf> routing bgp address-family ipv6-flowspec route <uint32>␣
˓→weight
Packet length.
vrouter> show state vrf <vrf> routing bgp address-family ipv6-flowspec route <uint32>␣
˓→packet-length
AS path.
vrouter> show state vrf <vrf> routing bgp address-family ipv6-flowspec route <uint32>␣
˓→path
Route nexthop.
vrouter> show state vrf <vrf> routing bgp address-family ipv6-flowspec route <uint32>␣
˓→nexthop <nexthop> address-family
Nexthop used.
vrouter> show state vrf <vrf> routing bgp address-family ipv6-flowspec route <uint32>␣
˓→nexthop <nexthop> used
ipv6-multicast
enabled
Default value
true
vrouter> show state vrf <vrf> routing bgp address-family ipv6-multicast rib-count
vrouter> show state vrf <vrf> routing bgp address-family ipv6-multicast neighbor-count
vrouter> show state vrf <vrf> routing bgp address-family ipv6-multicast dynamic-
˓→neighbor-count
network
vrouter running config# vrf <vrf> routing bgp address-family ipv6-multicast network
˓→<network>
route-map
Route-map name.
vrouter running config# vrf <vrf> routing bgp address-family ipv6-multicast network
˓→<network>
label-index
vrouter running config# vrf <vrf> routing bgp address-family ipv6-multicast network
˓→<network>
Route state.
vrouter> show state vrf <vrf> routing bgp address-family ipv6-multicast network
˓→<network> route <string> status
vrouter> show state vrf <vrf> routing bgp address-family ipv6-multicast network
˓→<network> route <string> stale
vrouter> show state vrf <vrf> routing bgp address-family ipv6-multicast network
˓→<network> route <string> suppressed
vrouter> show state vrf <vrf> routing bgp address-family ipv6-multicast network
˓→<network> route <string> history
vrouter> show state vrf <vrf> routing bgp address-family ipv6-multicast network
˓→<network> route <string> damped
Selected route considered as the preferred one in the local routing context.
vrouter> show state vrf <vrf> routing bgp address-family ipv6-multicast network
˓→<network> route <string> bestpath
vrouter> show state vrf <vrf> routing bgp address-family ipv6-multicast network
˓→<network> route <string> multipath
Route validity.
vrouter> show state vrf <vrf> routing bgp address-family ipv6-multicast network
˓→<network> route <string> validity
vrouter> show state vrf <vrf> routing bgp address-family ipv6-multicast network
˓→<network> route <string> route-type
Route prefix.
vrouter> show state vrf <vrf> routing bgp address-family ipv6-multicast network
˓→<network> route <string> prefix
vrouter> show state vrf <vrf> routing bgp address-family ipv6-multicast network
˓→<network> route <string> prefix-length
Route metric.
vrouter> show state vrf <vrf> routing bgp address-family ipv6-multicast network
˓→<network> route <string> metric
Route origin.
vrouter> show state vrf <vrf> routing bgp address-family ipv6-multicast network
˓→<network> route <string> origin
Path network.
vrouter> show state vrf <vrf> routing bgp address-family ipv6-multicast network
˓→<network> route <string> network
Local preference.
vrouter> show state vrf <vrf> routing bgp address-family ipv6-multicast network
˓→<network> route <string> local-preference
Weight.
vrouter> show state vrf <vrf> routing bgp address-family ipv6-multicast network
˓→<network> route <string> weight
Packet length.
vrouter> show state vrf <vrf> routing bgp address-family ipv6-multicast network
˓→<network> route <string> packet-length
AS path.
vrouter> show state vrf <vrf> routing bgp address-family ipv6-multicast network
˓→<network> route <string> path
Route nexthop.
vrouter> show state vrf <vrf> routing bgp address-family ipv6-multicast network
˓→<network> route <string> nexthop <nexthop> address-family
Nexthop used.
vrouter> show state vrf <vrf> routing bgp address-family ipv6-multicast network
˓→<network> route <string> nexthop <nexthop> used
administrative-distance
distance (mandatory)
Administrative distance.
distance <uint8>
access-list
access-list ACCESS-LIST
bgp-distance
vrouter running config# vrf <vrf> routing bgp address-family ipv6-multicast bgp-
˓→distance
external-routes
vrouter running config# vrf <vrf> routing bgp address-family ipv6-multicast bgp-
˓→distance
Default value
20
internal-routes
vrouter running config# vrf <vrf> routing bgp address-family ipv6-multicast bgp-
˓→distance
Default value
200
local-routes
vrouter running config# vrf <vrf> routing bgp address-family ipv6-multicast bgp-
˓→distance
Default value
200
route-flap-dampening
vrouter running config# vrf <vrf> routing bgp address-family ipv6-multicast route-flap-
˓→dampening
enabled
vrouter running config# vrf <vrf> routing bgp address-family ipv6-multicast route-flap-
˓→dampening
Default value
false
reach-decay
This value specifies the time desired for the instability metric value to reach one-half of its current value when the
route is reachable. This half-life value determines the rate at which the metric value is decayed. A smaller half-life
value makes a suppressed route reusable sooner than a larger value. The accumulated penalty will be reduced to
half after this duration.
vrouter running config# vrf <vrf> routing bgp address-family ipv6-multicast route-flap-
˓→dampening
Default value
15
reuse-above
This is the value of the instability metric at which a suppressed route becomes unsuppressed if it is reachable but
currently suppressed. The value assigned to reuse-below must be less than suppress-above.
vrouter running config# vrf <vrf> routing bgp address-family ipv6-multicast route-flap-
˓→dampening
Default value
750
suppress-above
This is the value of the instability metric at which route suppression takes place. A route is not installed in the
forwarding information base (FIB), or announced even if it is reachable during the period that it is suppressed.
vrouter running config# vrf <vrf> routing bgp address-family ipv6-multicast route-flap-
˓→dampening
Default value
2000
unreach-decay
This value acts the same as reach-decay except that it specifies the rate at which the instability metric is decayed
when a route is unreachable. It should have a value greater than or equal to reach- decay.
vrouter running config# vrf <vrf> routing bgp address-family ipv6-multicast route-flap-
˓→dampening
Default value
60
ipv6-labeled-unicast
enabled
Default value
true
vrouter> show state vrf <vrf> routing bgp address-family ipv6-labeled-unicast rib-count
vrouter> show state vrf <vrf> routing bgp address-family ipv6-labeled-unicast neighbor-
˓→count
vrouter> show state vrf <vrf> routing bgp address-family ipv6-labeled-unicast dynamic-
˓→neighbor-count
maximum-path
ebgp
Default value
16
ibgp
Default value
16
equal-cluster-length
Default value
false
route-flap-dampening
enabled
Default value
false
reach-decay
This value specifies the time desired for the instability metric value to reach one-half of its current value when the
route is reachable. This half-life value determines the rate at which the metric value is decayed. A smaller half-life
value makes a suppressed route reusable sooner than a larger value. The accumulated penalty will be reduced to
half after this duration.
Default value
15
reuse-above
This is the value of the instability metric at which a suppressed route becomes unsuppressed if it is reachable but
currently suppressed. The value assigned to reuse-below must be less than suppress-above.
Default value
750
suppress-above
This is the value of the instability metric at which route suppression takes place. A route is not installed in the
forwarding information base (FIB), or announced even if it is reachable during the period that it is suppressed.
Default value
2000
unreach-decay
This value acts the same as reach-decay except that it specifies the rate at which the instability metric is decayed
when a route is unreachable. It should have a value greater than or equal to reach- decay.
Default value
60
ipv6-vpn
enabled
Default value
true
vrouter> show state vrf <vrf> routing bgp address-family ipv6-vpn rib-count
vrouter> show state vrf <vrf> routing bgp address-family ipv6-vpn neighbor-count
vrouter> show state vrf <vrf> routing bgp address-family ipv6-vpn dynamic-neighbor-
˓→count
route-distinguisher
vrouter running config# vrf <vrf> routing bgp address-family ipv6-vpn route-
˓→distinguisher <rd> <ip-prefix>
<rd> Description
val-
ues
<string>Type definition for extended community attributes. In the case that common communities are utilised,
they are represented as a string of the form: - <2b AS>:<4b value> per RFC4360 section 3.1 - <4b
IPv4>:<2b value> per RFC4360 section 3.2.
<string>Type definition for extended community attributes. In the case that common communities are utilised,
they are represented as a string of the form: - <2b AS>:<4b value> per RFC4360 section 3.1 - <4b
IPv4>:<2b value> per RFC4360 section 3.2.
label
vrouter running config# vrf <vrf> routing bgp address-family ipv6-vpn route-
˓→distinguisher <rd> <ip-prefix>
route-map
vrouter running config# vrf <vrf> routing bgp address-family ipv6-vpn route-
˓→distinguisher <rd> <ip-prefix>
Route state.
vrouter> show state vrf <vrf> routing bgp address-family ipv6-vpn route-distinguisher
˓→<rd> <ip-prefix> route <string> status
vrouter> show state vrf <vrf> routing bgp address-family ipv6-vpn route-distinguisher
˓→<rd> <ip-prefix> route <string> stale
vrouter> show state vrf <vrf> routing bgp address-family ipv6-vpn route-distinguisher
˓→<rd> <ip-prefix> route <string> suppressed
vrouter> show state vrf <vrf> routing bgp address-family ipv6-vpn route-distinguisher
˓→<rd> <ip-prefix> route <string> history
vrouter> show state vrf <vrf> routing bgp address-family ipv6-vpn route-distinguisher
˓→<rd> <ip-prefix> route <string> damped
Selected route considered as the preferred one in the local routing context.
vrouter> show state vrf <vrf> routing bgp address-family ipv6-vpn route-distinguisher
˓→<rd> <ip-prefix> route <string> bestpath
vrouter> show state vrf <vrf> routing bgp address-family ipv6-vpn route-distinguisher
˓→<rd> <ip-prefix> route <string> multipath
Route validity.
vrouter> show state vrf <vrf> routing bgp address-family ipv6-vpn route-distinguisher
˓→<rd> <ip-prefix> route <string> validity
vrouter> show state vrf <vrf> routing bgp address-family ipv6-vpn route-distinguisher
˓→<rd> <ip-prefix> route <string> route-type
Route prefix.
vrouter> show state vrf <vrf> routing bgp address-family ipv6-vpn route-distinguisher
˓→<rd> <ip-prefix> route <string> prefix
vrouter> show state vrf <vrf> routing bgp address-family ipv6-vpn route-distinguisher
˓→<rd> <ip-prefix> route <string> prefix-length
Route metric.
vrouter> show state vrf <vrf> routing bgp address-family ipv6-vpn route-distinguisher
˓→<rd> <ip-prefix> route <string> metric
Route origin.
vrouter> show state vrf <vrf> routing bgp address-family ipv6-vpn route-distinguisher
˓→<rd> <ip-prefix> route <string> origin
Path network.
vrouter> show state vrf <vrf> routing bgp address-family ipv6-vpn route-distinguisher
˓→<rd> <ip-prefix> route <string> network
Local preference.
vrouter> show state vrf <vrf> routing bgp address-family ipv6-vpn route-distinguisher
˓→<rd> <ip-prefix> route <string> local-preference
Weight.
vrouter> show state vrf <vrf> routing bgp address-family ipv6-vpn route-distinguisher
˓→<rd> <ip-prefix> route <string> weight
Packet length.
vrouter> show state vrf <vrf> routing bgp address-family ipv6-vpn route-distinguisher
˓→<rd> <ip-prefix> route <string> packet-length
AS path.
vrouter> show state vrf <vrf> routing bgp address-family ipv6-vpn route-distinguisher
˓→<rd> <ip-prefix> route <string> path
Route nexthop.
vrouter> show state vrf <vrf> routing bgp address-family ipv6-vpn route-distinguisher
˓→<rd> <ip-prefix> route <string> nexthop <nexthop> address-family
Nexthop used.
vrouter> show state vrf <vrf> routing bgp address-family ipv6-vpn route-distinguisher
˓→<rd> <ip-prefix> route <string> nexthop <nexthop> used
l2vpn-evpn
enabled
Default value
true
advertise
Configure advertisement.
advertise-all-vni
Default value
false
auto-route-target
Default value
disabled
default-originate
flooding
Default value
head-end-replication
vrouter> show state vrf <vrf> routing bgp address-family l2vpn-evpn rib-count
vrouter> show state vrf <vrf> routing bgp address-family l2vpn-evpn neighbor-count
vrouter> show state vrf <vrf> routing bgp address-family l2vpn-evpn dynamic-neighbor-
˓→count
vni
vrouter running config# vrf <vrf> routing bgp address-family l2vpn-evpn vni <vni>
<vni> Type definition representing VXLAN Segment ID / VXLAN Network Identifier value.
enabled
vrouter running config# vrf <vrf> routing bgp address-family l2vpn-evpn vni <vni>
vrouter running vni <vni># enabled true|false
Default value
true
advertise-default-gw
vrouter running config# vrf <vrf> routing bgp address-family l2vpn-evpn vni <vni>
vrouter running vni <vni># advertise-default-gw true|false
Default value
false
export
vrouter running config# vrf <vrf> routing bgp address-family l2vpn-evpn vni <vni>␣
˓→export
route-target
vrouter running config# vrf <vrf> routing bgp address-family l2vpn-evpn vni <vni>␣
˓→export
route-distinguisher
vrouter running config# vrf <vrf> routing bgp address-family l2vpn-evpn vni <vni>␣
˓→export
Description
ROUTE-DISTINGUISHER
values
<string> Type definition for extended community attributes. In the case that common communities are
utilised, they are represented as a string of the form: - <2b AS>:<4b value> per RFC4360 section
3.1 - <4b IPv4>:<2b value> per RFC4360 section 3.2.
<string> Type definition for extended community attributes. In the case that common communities are
utilised, they are represented as a string of the form: - <2b AS>:<4b value> per RFC4360 section
3.1 - <4b IPv4>:<2b value> per RFC4360 section 3.2.
import
vrouter running config# vrf <vrf> routing bgp address-family l2vpn-evpn vni <vni>␣
˓→import
route-target
vrouter running config# vrf <vrf> routing bgp address-family l2vpn-evpn vni <vni>␣
˓→import
export
vrouter running config# vrf <vrf> routing bgp address-family l2vpn-evpn export
route-target
vrouter running config# vrf <vrf> routing bgp address-family l2vpn-evpn export
vrouter running export# route-target ROUTE-TARGET
route-distinguisher
vrouter running config# vrf <vrf> routing bgp address-family l2vpn-evpn export
vrouter running export# route-distinguisher ROUTE-DISTINGUISHER
Description
ROUTE-DISTINGUISHER
values
<string> Type definition for extended community attributes. In the case that common communities are
utilised, they are represented as a string of the form: - <2b AS>:<4b value> per RFC4360 section
3.1 - <4b IPv4>:<2b value> per RFC4360 section 3.2.
<string> Type definition for extended community attributes. In the case that common communities are
utilised, they are represented as a string of the form: - <2b AS>:<4b value> per RFC4360 section
3.1 - <4b IPv4>:<2b value> per RFC4360 section 3.2.
import
vrouter running config# vrf <vrf> routing bgp address-family l2vpn-evpn import
route-target
vrouter running config# vrf <vrf> routing bgp address-family l2vpn-evpn import
vrouter running import# route-target ROUTE-TARGET
vrouter> show state vrf <vrf> routing bgp address-family l2vpn-evpn route-
˓→distinguisher <route-distinguisher> prefix <string> prefix-length
Path list.
vrouter> show state vrf <vrf> routing bgp address-family l2vpn-evpn route-
˓→distinguisher <route-distinguisher> prefix <string> path <uint32> peer-id
Route state.
vrouter> show state vrf <vrf> routing bgp address-family l2vpn-evpn route-
˓→distinguisher <route-distinguisher> prefix <string> path <uint32> status
vrouter> show state vrf <vrf> routing bgp address-family l2vpn-evpn route-
˓→distinguisher <route-distinguisher> prefix <string> path <uint32> stale
vrouter> show state vrf <vrf> routing bgp address-family l2vpn-evpn route-
˓→distinguisher <route-distinguisher> prefix <string> path <uint32> suppressed
vrouter> show state vrf <vrf> routing bgp address-family l2vpn-evpn route-
˓→distinguisher <route-distinguisher> prefix <string> path <uint32> history
vrouter> show state vrf <vrf> routing bgp address-family l2vpn-evpn route-
˓→distinguisher <route-distinguisher> prefix <string> path <uint32> damped
Selected route considered as the preferred one in the local routing context.
vrouter> show state vrf <vrf> routing bgp address-family l2vpn-evpn route-
˓→distinguisher <route-distinguisher> prefix <string> path <uint32> bestpath
vrouter> show state vrf <vrf> routing bgp address-family l2vpn-evpn route-
˓→distinguisher <route-distinguisher> prefix <string> path <uint32> multipath
Route validity.
vrouter> show state vrf <vrf> routing bgp address-family l2vpn-evpn route-
˓→distinguisher <route-distinguisher> prefix <string> path <uint32> validity
vrouter> show state vrf <vrf> routing bgp address-family l2vpn-evpn route-
˓→distinguisher <route-distinguisher> prefix <string> path <uint32> route-type
Route prefix.
vrouter> show state vrf <vrf> routing bgp address-family l2vpn-evpn route-
˓→distinguisher <route-distinguisher> prefix <string> path <uint32> prefix
vrouter> show state vrf <vrf> routing bgp address-family l2vpn-evpn route-
˓→distinguisher <route-distinguisher> prefix <string> path <uint32> prefix-length
Route metric.
vrouter> show state vrf <vrf> routing bgp address-family l2vpn-evpn route-
˓→distinguisher <route-distinguisher> prefix <string> path <uint32> metric
Route origin.
vrouter> show state vrf <vrf> routing bgp address-family l2vpn-evpn route-
˓→distinguisher <route-distinguisher> prefix <string> path <uint32> origin
Path network.
vrouter> show state vrf <vrf> routing bgp address-family l2vpn-evpn route-
˓→distinguisher <route-distinguisher> prefix <string> path <uint32> network
Local preference.
vrouter> show state vrf <vrf> routing bgp address-family l2vpn-evpn route-
˓→distinguisher <route-distinguisher> prefix <string> path <uint32> local-preference
Weight.
vrouter> show state vrf <vrf> routing bgp address-family l2vpn-evpn route-
˓→distinguisher <route-distinguisher> prefix <string> path <uint32> weight
Packet length.
vrouter> show state vrf <vrf> routing bgp address-family l2vpn-evpn route-
˓→distinguisher <route-distinguisher> prefix <string> path <uint32> packet-length
AS path.
vrouter> show state vrf <vrf> routing bgp address-family l2vpn-evpn route-
˓→distinguisher <route-distinguisher> prefix <string> path <uint32> path
Route nexthop.
vrouter> show state vrf <vrf> routing bgp address-family l2vpn-evpn route-
˓→distinguisher <route-distinguisher> prefix <string> path <uint32> nexthop <nexthop>␣
˓→address-family
Nexthop used.
vrouter> show state vrf <vrf> routing bgp address-family l2vpn-evpn route-
˓→distinguisher <route-distinguisher> prefix <string> path <uint32> nexthop <nexthop>␣
˓→used
neighbor-group
List of BGP peer-groups configured on the local system - uniquely identified by peer-group name.
<string> Reference to the name of the BGP neighbor-group used as a key in the neighbor-group list.
remote-as
Remote AS number.
capability
capability-negotiate
Default value
true
ebgp-multihop
enforce-first-as
Default value
false
enforce-multihop
Default value
false
neighbor-description
override-capability
Default value
false
passive
Default value
false
password
Set a password.
solo
Default value
false
strict-capability-match
Default value
false
track
A tracker name defined in the tracker context, or the BGP internal BFD tracker (bfd keyword). If a tracker name is
used, when the tracked address is reachable, the neighbor or neighbor group is considered as valid, else it is disabled.
If the BGP internal BFD tracker is used, it works the same way, but this neighbor address is automatically tracked.
The check-control-plane-failure option is available only when the BGP internal BFD tracker is used.
check-control-plane-failure
Link data-plane status with BGP control-plane. This option is available only if the BGP internal BFD tracker is
selected, i.e the ‘track bfd’ option is set.
ttl-security-hops
update-source
sender-as-path-loop-detection
Detect the sender side AS path loops and filter the bad routes before they are sent.
Default value
false
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> remote-neighbor-group
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> remote-router-id
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> state
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> min-time-btwn-
˓→advertisement
Last reset.
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> last-reset
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> bgp-connection
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> connect-retry-timer
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> estimated-rount-trip-
˓→time
local-as
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> local-as
as-number (mandatory)
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> local-as
vrouter running local-as# as-number <uint32>
no-prepend
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> local-as
vrouter running local-as# no-prepend true|false
Default value
false
replace-as
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> local-as
vrouter running local-as# replace-as true|false
Default value
false
shutdown
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> shutdown
message
Shutdown message.
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> shutdown
vrouter running shutdown# message <string>
timers
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> timers
advertisement-interval
Minimum time which must elapse between subsequent UPDATE messages relating to a common set of NLRI being
transmitted to a peer. This timer is referred to as MinRouteAdvertisementIntervalTimer by RFC 4721 and serves to
reduce the number of UPDATE messages transmitted when a particular set of NLRI exhibit instability. A change
of this value will be taken into account for new sessions.
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> timers
vrouter running timers# advertisement-interval <uint16>
connect-retry
Time interval in seconds between attempts to establish a session with the peer.
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> timers
vrouter running timers# connect-retry <uint16>
keepalive-interval
Time interval in seconds between transmission of keepalive messages to the neighbor. Typically set to 1/3 the
hold-time. A change of this value will be taken into account for new sessions.
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> timers
vrouter running timers# keepalive-interval <uint16>
hold-time
Time interval in seconds that a BGP session will be considered active in the absence of keepalive or other messages
from the peer. The hold- time is typically set to 3x the keepalive-interval.
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> timers
vrouter running timers# hold-time <uint16>
address-family
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family
ipv4-unicast
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-unicast
enabled
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-unicast
Default value
true
as-override
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-unicast
Default value
false
maximum-prefix-out
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-unicast
send-community
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-unicast
Default value
all
weight
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-unicast
allowas-in
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-unicast
attribute-unchanged
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-unicast
route-reflector-client
If true, configure a neighbor as Route Reflector client. This only applies to internal neighbors (IGP).
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-unicast
Default value
false
route-server-client
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-unicast
Default value
false
soft-reconfiguration-inbound
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-unicast
Default value
false
capability-orf-prefix-list
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-unicast
unsuppress-map
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-unicast
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv4-
˓→unicast update-group-id
Sub-group identifier.
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv4-
˓→unicast sub-group-id
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv4-
˓→unicast packet-queue-length
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv4-
˓→unicast accepted-prefix
The presence of this comment informs the user that incoming BGP updates are discarded, as per RFC8212 behaviour.
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv4-
˓→unicast inbound-ebgp-requires-policy
The presence of this comment informs the user that outgoing BGP updates are discarded, as per RFC8212 behaviour.
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv4-
˓→unicast outbound-ebgp-requires-policy
addpath
Configure addpath.
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-unicast addpath
tx-all-paths
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-unicast addpath
Default value
false
tx-best-path-per-AS
If true, use addpath to advertise the bestpath per each neighboring AS.
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-unicast addpath
Default value
false
distribute-list
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-unicast
access-list (mandatory)
access-list ACCESS-LIST
maximum-prefix
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-unicast maximum-prefix
maximum (mandatory)
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-unicast maximum-prefix
threshold
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-unicast maximum-prefix
Default value
75
restart
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-unicast maximum-prefix
warning-only
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-unicast maximum-prefix
Default value
false
nexthop-self
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-unicast nexthop-self
force
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-unicast nexthop-self
Default value
false
as-outbound-update
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-unicast as-outbound-update
action
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-unicast as-outbound-update
Default value
remove
as-type
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-unicast as-outbound-update
Default value
private
filter-list
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-unicast
access-list (mandatory)
access-list <as-path-access-list>
prefix-list
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-unicast
prefix-list-name (mandatory)
prefix-list-name PREFIX-LIST-NAME
route-map
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-unicast
route-map-name (mandatory)
Route-map name.
route-map-name ROUTE-MAP-NAME
default-originate
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-unicast default-originate
route-map
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-unicast default-originate
ipv4-multicast
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-multicast
enabled
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-multicast
Default value
true
as-override
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-multicast
Default value
false
maximum-prefix-out
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-multicast
send-community
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-multicast
Default value
all
weight
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-multicast
allowas-in
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-multicast
attribute-unchanged
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-multicast
route-reflector-client
If true, configure a neighbor as Route Reflector client. This only applies to internal neighbors (IGP).
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-multicast
Default value
false
route-server-client
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-multicast
Default value
false
soft-reconfiguration-inbound
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-multicast
Default value
false
capability-orf-prefix-list
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-multicast
unsuppress-map
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-multicast
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv4-
˓→multicast update-group-id
Sub-group identifier.
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv4-
˓→multicast sub-group-id
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv4-
˓→multicast packet-queue-length
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv4-
˓→multicast accepted-prefix
The presence of this comment informs the user that incoming BGP updates are discarded, as per RFC8212 behaviour.
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv4-
˓→multicast inbound-ebgp-requires-policy
The presence of this comment informs the user that outgoing BGP updates are discarded, as per RFC8212 behaviour.
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv4-
˓→multicast outbound-ebgp-requires-policy
addpath
Configure addpath.
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-multicast addpath
tx-all-paths
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-multicast addpath
Default value
false
tx-best-path-per-AS
If true, use addpath to advertise the bestpath per each neighboring AS.
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-multicast addpath
Default value
false
distribute-list
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-multicast
access-list (mandatory)
access-list ACCESS-LIST
maximum-prefix
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-multicast maximum-prefix
maximum (mandatory)
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-multicast maximum-prefix
threshold
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-multicast maximum-prefix
Default value
75
restart
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-multicast maximum-prefix
warning-only
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-multicast maximum-prefix
Default value
false
nexthop-self
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-multicast nexthop-self
force
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-multicast nexthop-self
Default value
false
as-outbound-update
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-multicast as-outbound-update
action
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-multicast as-outbound-update
Default value
remove
as-type
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-multicast as-outbound-update
Default value
private
filter-list
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-multicast
access-list (mandatory)
access-list <as-path-access-list>
prefix-list
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-multicast
prefix-list-name (mandatory)
prefix-list-name PREFIX-LIST-NAME
route-map
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-multicast
route-map-name (mandatory)
Route-map name.
route-map-name ROUTE-MAP-NAME
default-originate
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-multicast default-originate
route-map
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-multicast default-originate
ipv4-labeled-unicast
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-labeled-unicast
enabled
Enable or disable IPv4 labeled unicast Address Family for this neighbor.
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-labeled-unicast
Default value
true
as-override
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-labeled-unicast
Default value
false
maximum-prefix-out
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-labeled-unicast
send-community
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-labeled-unicast
Default value
all
weight
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-labeled-unicast
allowas-in
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-labeled-unicast
attribute-unchanged
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-labeled-unicast
route-reflector-client
If true, configure a neighbor as Route Reflector client. This only applies to internal neighbors (IGP).
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-labeled-unicast
Default value
false
route-server-client
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-labeled-unicast
Default value
false
soft-reconfiguration-inbound
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-labeled-unicast
Default value
false
capability-orf-prefix-list
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-labeled-unicast
unsuppress-map
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-labeled-unicast
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv4-
˓→labeled-unicast update-group-id
Sub-group identifier.
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv4-
˓→labeled-unicast sub-group-id
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv4-
˓→labeled-unicast packet-queue-length
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv4-
˓→labeled-unicast accepted-prefix
The presence of this comment informs the user that incoming BGP updates are discarded, as per RFC8212 behaviour.
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv4-
˓→labeled-unicast inbound-ebgp-requires-policy
The presence of this comment informs the user that outgoing BGP updates are discarded, as per RFC8212 behaviour.
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv4-
˓→labeled-unicast outbound-ebgp-requires-policy
addpath
Configure addpath.
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-labeled-unicast addpath
tx-all-paths
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-labeled-unicast addpath
Default value
false
tx-best-path-per-AS
If true, use addpath to advertise the bestpath per each neighboring AS.
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-labeled-unicast addpath
Default value
false
distribute-list
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-labeled-unicast
access-list (mandatory)
access-list ACCESS-LIST
maximum-prefix
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-labeled-unicast maximum-prefix
maximum (mandatory)
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-labeled-unicast maximum-prefix
threshold
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-labeled-unicast maximum-prefix
Default value
75
restart
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-labeled-unicast maximum-prefix
warning-only
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-labeled-unicast maximum-prefix
Default value
false
nexthop-self
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-labeled-unicast nexthop-self
force
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-labeled-unicast nexthop-self
Default value
false
as-outbound-update
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-labeled-unicast as-outbound-update
action
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-labeled-unicast as-outbound-update
Default value
remove
as-type
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-labeled-unicast as-outbound-update
Default value
private
filter-list
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-labeled-unicast
access-list (mandatory)
access-list <as-path-access-list>
prefix-list
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-labeled-unicast
prefix-list-name (mandatory)
prefix-list-name PREFIX-LIST-NAME
route-map
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-labeled-unicast
route-map-name (mandatory)
Route-map name.
route-map-name ROUTE-MAP-NAME
default-originate
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-labeled-unicast default-originate
route-map
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-labeled-unicast default-originate
ipv4-flowspec
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-flowspec
enabled
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-flowspec
Default value
true
route-reflector-client
If true, configure a neighbor as Route Reflector client. This only applies to internal neighbors (IGP).
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-flowspec
Default value
false
route-server-client
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-flowspec
Default value
false
soft-reconfiguration-inbound
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-flowspec
Default value
false
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv4-
˓→flowspec update-group-id
Sub-group identifier.
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv4-
˓→flowspec sub-group-id
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv4-
˓→flowspec packet-queue-length
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv4-
˓→flowspec accepted-prefix
The presence of this comment informs the user that incoming BGP updates are discarded, as per RFC8212 behaviour.
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv4-
˓→flowspec inbound-ebgp-requires-policy
The presence of this comment informs the user that outgoing BGP updates are discarded, as per RFC8212 behaviour.
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv4-
˓→flowspec outbound-ebgp-requires-policy
filter-list
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-flowspec
access-list (mandatory)
access-list <as-path-access-list>
prefix-list
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-flowspec
prefix-list-name (mandatory)
prefix-list-name PREFIX-LIST-NAME
route-map
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-flowspec
route-map-name (mandatory)
Route-map name.
route-map-name ROUTE-MAP-NAME
ipv4-vpn
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-vpn
enabled
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-vpn
Default value
true
unsuppress-map
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-vpn
as-override
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-vpn
Default value
false
maximum-prefix-out
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-vpn
send-community
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-vpn
Default value
all
weight
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-vpn
allowas-in
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-vpn
attribute-unchanged
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-vpn
route-reflector-client
If true, configure a neighbor as Route Reflector client. This only applies to internal neighbors (IGP).
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-vpn
Default value
false
route-server-client
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-vpn
Default value
false
soft-reconfiguration-inbound
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-vpn
Default value
false
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv4-
˓→vpn update-group-id
Sub-group identifier.
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv4-
˓→vpn sub-group-id
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv4-
˓→vpn packet-queue-length
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv4-
˓→vpn accepted-prefix
The presence of this comment informs the user that incoming BGP updates are discarded, as per RFC8212 behaviour.
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv4-
˓→vpn inbound-ebgp-requires-policy
The presence of this comment informs the user that outgoing BGP updates are discarded, as per RFC8212 behaviour.
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv4-
˓→vpn outbound-ebgp-requires-policy
addpath
Configure addpath.
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-vpn addpath
tx-all-paths
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-vpn addpath
Default value
false
tx-best-path-per-AS
If true, use addpath to advertise the bestpath per each neighboring AS.
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-vpn addpath
Default value
false
distribute-list
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-vpn
access-list (mandatory)
access-list ACCESS-LIST
maximum-prefix
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-vpn maximum-prefix
maximum (mandatory)
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-vpn maximum-prefix
threshold
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-vpn maximum-prefix
Default value
75
restart
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-vpn maximum-prefix
warning-only
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-vpn maximum-prefix
Default value
false
nexthop-self
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-vpn nexthop-self
force
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-vpn nexthop-self
Default value
false
as-outbound-update
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-vpn as-outbound-update
action
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-vpn as-outbound-update
Default value
remove
as-type
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-vpn as-outbound-update
Default value
private
filter-list
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-vpn
access-list (mandatory)
access-list <as-path-access-list>
prefix-list
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-vpn
prefix-list-name (mandatory)
prefix-list-name PREFIX-LIST-NAME
route-map
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv4-vpn
route-map-name (mandatory)
Route-map name.
route-map-name ROUTE-MAP-NAME
ipv6-unicast
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-unicast
enabled
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-unicast
Default value
true
nexthop-local-unchanged
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-unicast
Default value
false
as-override
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-unicast
Default value
false
maximum-prefix-out
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-unicast
send-community
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-unicast
Default value
all
weight
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-unicast
allowas-in
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-unicast
attribute-unchanged
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-unicast
route-reflector-client
If true, configure a neighbor as Route Reflector client. This only applies to internal neighbors (IGP).
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-unicast
Default value
false
route-server-client
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-unicast
Default value
false
soft-reconfiguration-inbound
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-unicast
Default value
false
capability-orf-prefix-list
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-unicast
unsuppress-map
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-unicast
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv6-
˓→unicast update-group-id
Sub-group identifier.
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv6-
˓→unicast sub-group-id
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv6-
˓→unicast packet-queue-length
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv6-
˓→unicast accepted-prefix
The presence of this comment informs the user that incoming BGP updates are discarded, as per RFC8212 behaviour.
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv6-
˓→unicast inbound-ebgp-requires-policy
The presence of this comment informs the user that outgoing BGP updates are discarded, as per RFC8212 behaviour.
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv6-
˓→unicast outbound-ebgp-requires-policy
addpath
Configure addpath.
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-unicast addpath
tx-all-paths
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-unicast addpath
Default value
false
tx-best-path-per-AS
If true, use addpath to advertise the bestpath per each neighboring AS.
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-unicast addpath
Default value
false
distribute-list
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-unicast
access-list (mandatory)
access-list ACCESS-LIST
maximum-prefix
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-unicast maximum-prefix
maximum (mandatory)
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-unicast maximum-prefix
threshold
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-unicast maximum-prefix
Default value
75
restart
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-unicast maximum-prefix
warning-only
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-unicast maximum-prefix
Default value
false
nexthop-self
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-unicast nexthop-self
force
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-unicast nexthop-self
Default value
false
as-outbound-update
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-unicast as-outbound-update
action
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-unicast as-outbound-update
Default value
remove
as-type
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-unicast as-outbound-update
Default value
private
filter-list
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-unicast
access-list (mandatory)
access-list <as-path-access-list>
prefix-list
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-unicast
prefix-list-name (mandatory)
prefix-list-name PREFIX-LIST-NAME
route-map
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-unicast
route-map-name (mandatory)
Route-map name.
route-map-name ROUTE-MAP-NAME
default-originate
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-unicast default-originate
route-map
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-unicast default-originate
ipv6-multicast
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-multicast
enabled
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-multicast
Default value
true
as-override
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-multicast
Default value
false
maximum-prefix-out
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-multicast
send-community
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-multicast
Default value
all
weight
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-multicast
allowas-in
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-multicast
attribute-unchanged
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-multicast
route-reflector-client
If true, configure a neighbor as Route Reflector client. This only applies to internal neighbors (IGP).
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-multicast
Default value
false
route-server-client
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-multicast
Default value
false
soft-reconfiguration-inbound
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-multicast
Default value
false
capability-orf-prefix-list
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-multicast
unsuppress-map
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-multicast
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv6-
˓→multicast update-group-id
Sub-group identifier.
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv6-
˓→multicast sub-group-id
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv6-
˓→multicast packet-queue-length
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv6-
˓→multicast accepted-prefix
The presence of this comment informs the user that incoming BGP updates are discarded, as per RFC8212 behaviour.
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv6-
˓→multicast inbound-ebgp-requires-policy
The presence of this comment informs the user that outgoing BGP updates are discarded, as per RFC8212 behaviour.
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv6-
˓→multicast outbound-ebgp-requires-policy
addpath
Configure addpath.
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-multicast addpath
tx-all-paths
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-multicast addpath
Default value
false
tx-best-path-per-AS
If true, use addpath to advertise the bestpath per each neighboring AS.
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-multicast addpath
Default value
false
distribute-list
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-multicast
access-list (mandatory)
access-list ACCESS-LIST
maximum-prefix
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-multicast maximum-prefix
maximum (mandatory)
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-multicast maximum-prefix
threshold
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-multicast maximum-prefix
Default value
75
restart
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-multicast maximum-prefix
warning-only
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-multicast maximum-prefix
Default value
false
nexthop-self
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-multicast nexthop-self
force
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-multicast nexthop-self
Default value
false
as-outbound-update
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-multicast as-outbound-update
action
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-multicast as-outbound-update
Default value
remove
as-type
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-multicast as-outbound-update
Default value
private
filter-list
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-multicast
access-list (mandatory)
access-list <as-path-access-list>
prefix-list
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-multicast
prefix-list-name (mandatory)
prefix-list-name PREFIX-LIST-NAME
route-map
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-multicast
route-map-name (mandatory)
Route-map name.
route-map-name ROUTE-MAP-NAME
default-originate
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-multicast default-originate
route-map
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-multicast default-originate
ipv6-labeled-unicast
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-labeled-unicast
enabled
Enable or disable IPv6 labeled unicast Address Family for this neighbor.
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-labeled-unicast
Default value
true
as-override
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-labeled-unicast
Default value
false
maximum-prefix-out
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-labeled-unicast
send-community
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-labeled-unicast
Default value
all
weight
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-labeled-unicast
allowas-in
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-labeled-unicast
attribute-unchanged
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-labeled-unicast
route-reflector-client
If true, configure a neighbor as Route Reflector client. This only applies to internal neighbors (IGP).
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-labeled-unicast
Default value
false
route-server-client
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-labeled-unicast
Default value
false
soft-reconfiguration-inbound
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-labeled-unicast
Default value
false
capability-orf-prefix-list
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-labeled-unicast
unsuppress-map
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-labeled-unicast
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv6-
˓→labeled-unicast update-group-id
Sub-group identifier.
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv6-
˓→labeled-unicast sub-group-id
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv6-
˓→labeled-unicast packet-queue-length
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv6-
˓→labeled-unicast accepted-prefix
The presence of this comment informs the user that incoming BGP updates are discarded, as per RFC8212 behaviour.
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv6-
˓→labeled-unicast inbound-ebgp-requires-policy
The presence of this comment informs the user that outgoing BGP updates are discarded, as per RFC8212 behaviour.
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv6-
˓→labeled-unicast outbound-ebgp-requires-policy
addpath
Configure addpath.
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-labeled-unicast addpath
tx-all-paths
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-labeled-unicast addpath
Default value
false
tx-best-path-per-AS
If true, use addpath to advertise the bestpath per each neighboring AS.
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-labeled-unicast addpath
Default value
false
distribute-list
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-labeled-unicast
access-list (mandatory)
access-list ACCESS-LIST
maximum-prefix
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-labeled-unicast maximum-prefix
maximum (mandatory)
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-labeled-unicast maximum-prefix
threshold
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-labeled-unicast maximum-prefix
Default value
75
restart
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-labeled-unicast maximum-prefix
warning-only
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-labeled-unicast maximum-prefix
Default value
false
nexthop-self
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-labeled-unicast nexthop-self
force
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-labeled-unicast nexthop-self
Default value
false
as-outbound-update
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-labeled-unicast as-outbound-update
action
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-labeled-unicast as-outbound-update
Default value
remove
as-type
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-labeled-unicast as-outbound-update
Default value
private
filter-list
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-labeled-unicast
access-list (mandatory)
access-list <as-path-access-list>
prefix-list
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-labeled-unicast
prefix-list-name (mandatory)
prefix-list-name PREFIX-LIST-NAME
route-map
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-labeled-unicast
route-map-name (mandatory)
Route-map name.
route-map-name ROUTE-MAP-NAME
default-originate
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-labeled-unicast default-originate
route-map
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-labeled-unicast default-originate
ipv6-flowspec
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-flowspec
enabled
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-flowspec
Default value
true
route-reflector-client
If true, configure a neighbor as Route Reflector client. This only applies to internal neighbors (IGP).
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-flowspec
Default value
false
route-server-client
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-flowspec
Default value
false
soft-reconfiguration-inbound
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-flowspec
Default value
false
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv6-
˓→flowspec update-group-id
Sub-group identifier.
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv6-
˓→flowspec sub-group-id
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv6-
˓→flowspec packet-queue-length
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv6-
˓→flowspec accepted-prefix
The presence of this comment informs the user that incoming BGP updates are discarded, as per RFC8212 behaviour.
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv6-
˓→flowspec inbound-ebgp-requires-policy
The presence of this comment informs the user that outgoing BGP updates are discarded, as per RFC8212 behaviour.
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv6-
˓→flowspec outbound-ebgp-requires-policy
filter-list
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-flowspec
access-list (mandatory)
access-list <as-path-access-list>
prefix-list
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-flowspec
prefix-list-name (mandatory)
prefix-list-name PREFIX-LIST-NAME
route-map
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-flowspec
route-map-name (mandatory)
Route-map name.
route-map-name ROUTE-MAP-NAME
ipv6-vpn
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-vpn
enabled
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-vpn
Default value
true
unsuppress-map
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-vpn
as-override
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-vpn
Default value
false
maximum-prefix-out
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-vpn
send-community
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-vpn
Default value
all
weight
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-vpn
allowas-in
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-vpn
attribute-unchanged
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-vpn
route-reflector-client
If true, configure a neighbor as Route Reflector client. This only applies to internal neighbors (IGP).
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-vpn
Default value
false
route-server-client
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-vpn
Default value
false
soft-reconfiguration-inbound
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-vpn
Default value
false
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv6-
˓→vpn update-group-id
Sub-group identifier.
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv6-
˓→vpn sub-group-id
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv6-
˓→vpn packet-queue-length
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv6-
˓→vpn accepted-prefix
The presence of this comment informs the user that incoming BGP updates are discarded, as per RFC8212 behaviour.
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv6-
˓→vpn inbound-ebgp-requires-policy
The presence of this comment informs the user that outgoing BGP updates are discarded, as per RFC8212 behaviour.
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family ipv6-
˓→vpn outbound-ebgp-requires-policy
addpath
Configure addpath.
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-vpn addpath
tx-all-paths
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-vpn addpath
Default value
false
tx-best-path-per-AS
If true, use addpath to advertise the bestpath per each neighboring AS.
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-vpn addpath
Default value
false
distribute-list
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-vpn
access-list (mandatory)
access-list ACCESS-LIST
maximum-prefix
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-vpn maximum-prefix
maximum (mandatory)
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-vpn maximum-prefix
threshold
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-vpn maximum-prefix
Default value
75
restart
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-vpn maximum-prefix
warning-only
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-vpn maximum-prefix
Default value
false
nexthop-self
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-vpn nexthop-self
force
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-vpn nexthop-self
Default value
false
as-outbound-update
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-vpn as-outbound-update
action
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-vpn as-outbound-update
Default value
remove
as-type
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-vpn as-outbound-update
Default value
private
filter-list
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-vpn
access-list (mandatory)
access-list <as-path-access-list>
prefix-list
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-vpn
prefix-list-name (mandatory)
prefix-list-name PREFIX-LIST-NAME
route-map
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→ipv6-vpn
route-map-name (mandatory)
Route-map name.
route-map-name ROUTE-MAP-NAME
l2vpn-evpn
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→l2vpn-evpn
enabled
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→l2vpn-evpn
Default value
true
nexthop-self
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→l2vpn-evpn
Default value
false
route-reflector-client
If true, configure a neighbor as Route Reflector client. This only applies to internal neighbors (IGP).
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→l2vpn-evpn
Default value
false
route-server-client
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→l2vpn-evpn
Default value
false
soft-reconfiguration-inbound
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→l2vpn-evpn
Default value
false
allowas-in
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→l2vpn-evpn
attribute-unchanged
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→l2vpn-evpn
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family l2vpn-
˓→evpn update-group-id
Sub-group identifier.
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family l2vpn-
˓→evpn sub-group-id
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family l2vpn-
˓→evpn packet-queue-length
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family l2vpn-
˓→evpn accepted-prefix
The presence of this comment informs the user that incoming BGP updates are discarded, as per RFC8212 behaviour.
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family l2vpn-
˓→evpn inbound-ebgp-requires-policy
The presence of this comment informs the user that outgoing BGP updates are discarded, as per RFC8212 behaviour.
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> address-family l2vpn-
˓→evpn outbound-ebgp-requires-policy
route-map
vrouter running config# vrf <vrf> routing bgp neighbor-group <string> address-family␣
˓→l2vpn-evpn
route-map-name (mandatory)
Route-map name.
route-map-name ROUTE-MAP-NAME
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> connections␣
˓→established
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> connections dropped
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> local-host name
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> local-host port
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> remote-host name
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> remote-host port
Nexthop data.
Nexthop IP address.
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> nexthop address
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> nexthop global-
˓→address
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> nexthop local-address
Read/Write thread.
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> thread read-enabled
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> thread write-enabled
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> message-statistics␣
˓→packet-wait-process
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> message-statistics␣
˓→packet-wait-written
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> message-statistics␣
˓→open-sent
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> message-statistics␣
˓→opens-received
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> message-statistics␣
˓→notifications-sent
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> message-statistics␣
˓→notifications-received
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> message-statistics␣
˓→updates-sent
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> message-statistics␣
˓→updates-received
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> message-statistics␣
˓→keepalives-sent
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> message-statistics␣
˓→keepalives-received
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> message-statistics␣
˓→route-refresh-sent
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> message-statistics␣
˓→route-refresh-received
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> message-statistics␣
˓→capability-sent
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> message-statistics␣
˓→capability-received
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> message-statistics␣
˓→total-sent
vrouter> show state vrf <vrf> routing bgp neighbor-group <string> message-statistics␣
˓→total-received
neighbor
List of BGP neighbors configured on the local system, uniquely identified by peer IPv[46] address.
neighbor-group
interface
port
PORT A 16-bit port number used by a transport protocol such as TCP or UDP.
remote-as
Remote AS number.
capability
capability-negotiate
Default value
true
ebgp-multihop
enforce-first-as
Default value
false
enforce-multihop
Default value
false
neighbor-description
override-capability
Default value
false
passive
Default value
false
password
Set a password.
solo
Default value
false
strict-capability-match
Default value
false
track
A tracker name defined in the tracker context, or the BGP internal BFD tracker (bfd keyword). If a tracker name is
used, when the tracked address is reachable, the neighbor or neighbor group is considered as valid, else it is disabled.
If the BGP internal BFD tracker is used, it works the same way, but this neighbor address is automatically tracked.
The check-control-plane-failure option is available only when the BGP internal BFD tracker is used.
check-control-plane-failure
Link data-plane status with BGP control-plane. This option is available only if the BGP internal BFD tracker is
selected, i.e the ‘track bfd’ option is set.
ttl-security-hops
update-source
sender-as-path-loop-detection
Detect the sender side AS path loops and filter the bad routes before they are sent.
Default value
false
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> remote-neighbor-group
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> remote-router-id
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> state
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> min-time-btwn-
˓→advertisement
Last reset.
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> last-reset
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> bgp-connection
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> connect-retry-timer
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> estimated-rount-trip-time
local-as
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> local-as
as-number (mandatory)
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> local-as
vrouter running local-as# as-number <uint32>
no-prepend
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> local-as
vrouter running local-as# no-prepend true|false
Default value
false
replace-as
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> local-as
vrouter running local-as# replace-as true|false
Default value
false
shutdown
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> shutdown
message
Shutdown message.
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> shutdown
vrouter running shutdown# message <string>
timers
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> timers
advertisement-interval
Minimum time which must elapse between subsequent UPDATE messages relating to a common set of NLRI being
transmitted to a peer. This timer is referred to as MinRouteAdvertisementIntervalTimer by RFC 4721 and serves to
reduce the number of UPDATE messages transmitted when a particular set of NLRI exhibit instability. A change
of this value will be taken into account for new sessions.
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> timers
vrouter running timers# advertisement-interval <uint16>
connect-retry
Time interval in seconds between attempts to establish a session with the peer.
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> timers
vrouter running timers# connect-retry <uint16>
keepalive-interval
Time interval in seconds between transmission of keepalive messages to the neighbor. Typically set to 1/3 the
hold-time. A change of this value will be taken into account for new sessions.
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> timers
vrouter running timers# keepalive-interval <uint16>
hold-time
Time interval in seconds that a BGP session will be considered active in the absence of keepalive or other messages
from the peer. The hold- time is typically set to 3x the keepalive-interval.
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> timers
vrouter running timers# hold-time <uint16>
address-family
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family
ipv4-unicast
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→unicast
enabled
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→unicast
Default value
true
as-override
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→unicast
Default value
false
maximum-prefix-out
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→unicast
send-community
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→unicast
Default value
all
weight
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→unicast
allowas-in
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→unicast
attribute-unchanged
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→unicast
route-reflector-client
If true, configure a neighbor as Route Reflector client. This only applies to internal neighbors (IGP).
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→unicast
Default value
false
route-server-client
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→unicast
Default value
false
soft-reconfiguration-inbound
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→unicast
Default value
false
capability-orf-prefix-list
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→unicast
unsuppress-map
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→unicast
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→unicast update-group-id
Sub-group identifier.
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→unicast sub-group-id
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→unicast packet-queue-length
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→unicast accepted-prefix
The presence of this comment informs the user that incoming BGP updates are discarded, as per RFC8212 behaviour.
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→unicast inbound-ebgp-requires-policy
The presence of this comment informs the user that outgoing BGP updates are discarded, as per RFC8212 behaviour.
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→unicast outbound-ebgp-requires-policy
addpath
Configure addpath.
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→unicast addpath
tx-all-paths
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→unicast addpath
Default value
false
tx-best-path-per-AS
If true, use addpath to advertise the bestpath per each neighboring AS.
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→unicast addpath
Default value
false
distribute-list
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→unicast
access-list (mandatory)
access-list ACCESS-LIST
maximum-prefix
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→unicast maximum-prefix
maximum (mandatory)
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→unicast maximum-prefix
threshold
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→unicast maximum-prefix
Default value
75
restart
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→unicast maximum-prefix
warning-only
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→unicast maximum-prefix
Default value
false
nexthop-self
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→unicast nexthop-self
force
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→unicast nexthop-self
Default value
false
as-outbound-update
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→unicast as-outbound-update
action
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→unicast as-outbound-update
Default value
remove
as-type
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→unicast as-outbound-update
Default value
private
filter-list
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→unicast
access-list (mandatory)
access-list <as-path-access-list>
prefix-list
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→unicast
prefix-list-name (mandatory)
prefix-list-name PREFIX-LIST-NAME
route-map
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→unicast
route-map-name (mandatory)
Route-map name.
route-map-name ROUTE-MAP-NAME
default-originate
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→unicast default-originate
route-map
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→unicast default-originate
ipv4-multicast
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→multicast
enabled
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→multicast
Default value
true
as-override
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→multicast
Default value
false
maximum-prefix-out
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→multicast
send-community
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→multicast
Default value
all
weight
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→multicast
allowas-in
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→multicast
attribute-unchanged
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→multicast
route-reflector-client
If true, configure a neighbor as Route Reflector client. This only applies to internal neighbors (IGP).
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→multicast
Default value
false
route-server-client
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→multicast
Default value
false
soft-reconfiguration-inbound
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→multicast
Default value
false
capability-orf-prefix-list
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→multicast
unsuppress-map
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→multicast
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→multicast update-group-id
Sub-group identifier.
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→multicast sub-group-id
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→multicast packet-queue-length
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→multicast accepted-prefix
The presence of this comment informs the user that incoming BGP updates are discarded, as per RFC8212 behaviour.
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→multicast inbound-ebgp-requires-policy
The presence of this comment informs the user that outgoing BGP updates are discarded, as per RFC8212 behaviour.
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→multicast outbound-ebgp-requires-policy
addpath
Configure addpath.
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→multicast addpath
tx-all-paths
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→multicast addpath
Default value
false
tx-best-path-per-AS
If true, use addpath to advertise the bestpath per each neighboring AS.
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→multicast addpath
Default value
false
distribute-list
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→multicast
access-list (mandatory)
access-list ACCESS-LIST
maximum-prefix
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→multicast maximum-prefix
maximum (mandatory)
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→multicast maximum-prefix
threshold
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→multicast maximum-prefix
Default value
75
restart
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→multicast maximum-prefix
warning-only
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→multicast maximum-prefix
Default value
false
nexthop-self
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→multicast nexthop-self
force
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→multicast nexthop-self
Default value
false
as-outbound-update
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→multicast as-outbound-update
action
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→multicast as-outbound-update
Default value
remove
as-type
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→multicast as-outbound-update
Default value
private
filter-list
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→multicast
access-list (mandatory)
access-list <as-path-access-list>
prefix-list
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→multicast
prefix-list-name (mandatory)
prefix-list-name PREFIX-LIST-NAME
route-map
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→multicast
route-map-name (mandatory)
Route-map name.
route-map-name ROUTE-MAP-NAME
default-originate
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→multicast default-originate
route-map
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→multicast default-originate
ipv4-labeled-unicast
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→labeled-unicast
enabled
Enable or disable IPv4 labeled unicast Address Family for this neighbor.
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→labeled-unicast
Default value
true
as-override
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→labeled-unicast
Default value
false
maximum-prefix-out
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→labeled-unicast
send-community
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→labeled-unicast
Default value
all
weight
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→labeled-unicast
allowas-in
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→labeled-unicast
attribute-unchanged
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→labeled-unicast
route-reflector-client
If true, configure a neighbor as Route Reflector client. This only applies to internal neighbors (IGP).
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→labeled-unicast
Default value
false
route-server-client
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→labeled-unicast
Default value
false
soft-reconfiguration-inbound
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→labeled-unicast
Default value
false
capability-orf-prefix-list
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→labeled-unicast
unsuppress-map
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→labeled-unicast
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→labeled-unicast update-group-id
Sub-group identifier.
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→labeled-unicast sub-group-id
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→labeled-unicast packet-queue-length
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→labeled-unicast accepted-prefix
The presence of this comment informs the user that incoming BGP updates are discarded, as per RFC8212 behaviour.
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→labeled-unicast inbound-ebgp-requires-policy
The presence of this comment informs the user that outgoing BGP updates are discarded, as per RFC8212 behaviour.
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→labeled-unicast outbound-ebgp-requires-policy
addpath
Configure addpath.
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→labeled-unicast addpath
tx-all-paths
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→labeled-unicast addpath
Default value
false
tx-best-path-per-AS
If true, use addpath to advertise the bestpath per each neighboring AS.
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→labeled-unicast addpath
Default value
false
distribute-list
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→labeled-unicast
access-list (mandatory)
access-list ACCESS-LIST
maximum-prefix
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→labeled-unicast maximum-prefix
maximum (mandatory)
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→labeled-unicast maximum-prefix
threshold
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→labeled-unicast maximum-prefix
Default value
75
restart
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→labeled-unicast maximum-prefix
warning-only
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→labeled-unicast maximum-prefix
Default value
false
nexthop-self
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→labeled-unicast nexthop-self
force
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→labeled-unicast nexthop-self
Default value
false
as-outbound-update
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→labeled-unicast as-outbound-update
action
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→labeled-unicast as-outbound-update
Default value
remove
as-type
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→labeled-unicast as-outbound-update
Default value
private
filter-list
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→labeled-unicast
access-list (mandatory)
access-list <as-path-access-list>
prefix-list
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→labeled-unicast
prefix-list-name (mandatory)
prefix-list-name PREFIX-LIST-NAME
route-map
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→labeled-unicast
route-map-name (mandatory)
Route-map name.
route-map-name ROUTE-MAP-NAME
default-originate
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→labeled-unicast default-originate
route-map
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→labeled-unicast default-originate
ipv4-flowspec
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→flowspec
enabled
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→flowspec
Default value
true
route-reflector-client
If true, configure a neighbor as Route Reflector client. This only applies to internal neighbors (IGP).
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→flowspec
Default value
false
route-server-client
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→flowspec
Default value
false
soft-reconfiguration-inbound
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→flowspec
Default value
false
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→flowspec update-group-id
Sub-group identifier.
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→flowspec sub-group-id
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→flowspec packet-queue-length
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→flowspec accepted-prefix
The presence of this comment informs the user that incoming BGP updates are discarded, as per RFC8212 behaviour.
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→flowspec inbound-ebgp-requires-policy
The presence of this comment informs the user that outgoing BGP updates are discarded, as per RFC8212 behaviour.
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→flowspec outbound-ebgp-requires-policy
filter-list
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→flowspec
access-list (mandatory)
access-list <as-path-access-list>
prefix-list
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→flowspec
prefix-list-name (mandatory)
prefix-list-name PREFIX-LIST-NAME
route-map
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→flowspec
route-map-name (mandatory)
Route-map name.
route-map-name ROUTE-MAP-NAME
ipv4-vpn
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→vpn
enabled
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→vpn
Default value
true
unsuppress-map
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→vpn
as-override
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→vpn
Default value
false
maximum-prefix-out
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→vpn
send-community
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→vpn
Default value
all
weight
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→vpn
allowas-in
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→vpn
attribute-unchanged
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→vpn
route-reflector-client
If true, configure a neighbor as Route Reflector client. This only applies to internal neighbors (IGP).
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→vpn
Default value
false
route-server-client
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→vpn
Default value
false
soft-reconfiguration-inbound
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→vpn
Default value
false
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-vpn␣
˓→update-group-id
Sub-group identifier.
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-vpn␣
˓→sub-group-id
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-vpn␣
˓→packet-queue-length
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-vpn␣
˓→accepted-prefix
The presence of this comment informs the user that incoming BGP updates are discarded, as per RFC8212 behaviour.
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-vpn␣
˓→inbound-ebgp-requires-policy
The presence of this comment informs the user that outgoing BGP updates are discarded, as per RFC8212 behaviour.
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-vpn␣
˓→outbound-ebgp-requires-policy
addpath
Configure addpath.
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→vpn addpath
tx-all-paths
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→vpn addpath
Default value
false
tx-best-path-per-AS
If true, use addpath to advertise the bestpath per each neighboring AS.
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→vpn addpath
Default value
false
distribute-list
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→vpn
access-list (mandatory)
access-list ACCESS-LIST
maximum-prefix
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→vpn maximum-prefix
maximum (mandatory)
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→vpn maximum-prefix
threshold
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→vpn maximum-prefix
Default value
75
restart
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→vpn maximum-prefix
warning-only
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→vpn maximum-prefix
Default value
false
nexthop-self
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→vpn nexthop-self
force
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→vpn nexthop-self
Default value
false
as-outbound-update
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→vpn as-outbound-update
action
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→vpn as-outbound-update
Default value
remove
as-type
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→vpn as-outbound-update
Default value
private
filter-list
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→vpn
access-list (mandatory)
access-list <as-path-access-list>
prefix-list
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→vpn
prefix-list-name (mandatory)
prefix-list-name PREFIX-LIST-NAME
route-map
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv4-
˓→vpn
route-map-name (mandatory)
Route-map name.
route-map-name ROUTE-MAP-NAME
ipv6-unicast
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→unicast
enabled
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→unicast
Default value
true
nexthop-local-unchanged
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→unicast
Default value
false
as-override
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→unicast
Default value
false
maximum-prefix-out
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→unicast
send-community
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→unicast
Default value
all
weight
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→unicast
allowas-in
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→unicast
attribute-unchanged
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→unicast
route-reflector-client
If true, configure a neighbor as Route Reflector client. This only applies to internal neighbors (IGP).
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→unicast
Default value
false
route-server-client
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→unicast
Default value
false
soft-reconfiguration-inbound
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→unicast
Default value
false
capability-orf-prefix-list
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→unicast
unsuppress-map
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→unicast
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→unicast update-group-id
Sub-group identifier.
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→unicast sub-group-id
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→unicast packet-queue-length
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→unicast accepted-prefix
The presence of this comment informs the user that incoming BGP updates are discarded, as per RFC8212 behaviour.
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→unicast inbound-ebgp-requires-policy
The presence of this comment informs the user that outgoing BGP updates are discarded, as per RFC8212 behaviour.
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→unicast outbound-ebgp-requires-policy
addpath
Configure addpath.
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→unicast addpath
tx-all-paths
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→unicast addpath
Default value
false
tx-best-path-per-AS
If true, use addpath to advertise the bestpath per each neighboring AS.
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→unicast addpath
Default value
false
distribute-list
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→unicast
access-list (mandatory)
access-list ACCESS-LIST
maximum-prefix
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→unicast maximum-prefix
maximum (mandatory)
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→unicast maximum-prefix
threshold
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→unicast maximum-prefix
Default value
75
restart
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→unicast maximum-prefix
warning-only
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→unicast maximum-prefix
Default value
false
nexthop-self
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→unicast nexthop-self
force
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→unicast nexthop-self
Default value
false
as-outbound-update
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→unicast as-outbound-update
action
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→unicast as-outbound-update
Default value
remove
as-type
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→unicast as-outbound-update
Default value
private
filter-list
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→unicast
access-list (mandatory)
access-list <as-path-access-list>
prefix-list
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→unicast
prefix-list-name (mandatory)
prefix-list-name PREFIX-LIST-NAME
route-map
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→unicast
route-map-name (mandatory)
Route-map name.
route-map-name ROUTE-MAP-NAME
default-originate
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→unicast default-originate
route-map
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→unicast default-originate
ipv6-multicast
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→multicast
enabled
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→multicast
Default value
true
as-override
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→multicast
Default value
false
maximum-prefix-out
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→multicast
send-community
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→multicast
Default value
all
weight
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→multicast
allowas-in
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→multicast
attribute-unchanged
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→multicast
route-reflector-client
If true, configure a neighbor as Route Reflector client. This only applies to internal neighbors (IGP).
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→multicast
Default value
false
route-server-client
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→multicast
Default value
false
soft-reconfiguration-inbound
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→multicast
Default value
false
capability-orf-prefix-list
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→multicast
unsuppress-map
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→multicast
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→multicast update-group-id
Sub-group identifier.
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→multicast sub-group-id
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→multicast packet-queue-length
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→multicast accepted-prefix
The presence of this comment informs the user that incoming BGP updates are discarded, as per RFC8212 behaviour.
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→multicast inbound-ebgp-requires-policy
The presence of this comment informs the user that outgoing BGP updates are discarded, as per RFC8212 behaviour.
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→multicast outbound-ebgp-requires-policy
addpath
Configure addpath.
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→multicast addpath
tx-all-paths
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→multicast addpath
Default value
false
tx-best-path-per-AS
If true, use addpath to advertise the bestpath per each neighboring AS.
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→multicast addpath
Default value
false
distribute-list
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→multicast
access-list (mandatory)
access-list ACCESS-LIST
maximum-prefix
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→multicast maximum-prefix
maximum (mandatory)
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→multicast maximum-prefix
threshold
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→multicast maximum-prefix
Default value
75
restart
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→multicast maximum-prefix
warning-only
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→multicast maximum-prefix
Default value
false
nexthop-self
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→multicast nexthop-self
force
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→multicast nexthop-self
Default value
false
as-outbound-update
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→multicast as-outbound-update
action
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→multicast as-outbound-update
Default value
remove
as-type
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→multicast as-outbound-update
Default value
private
filter-list
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→multicast
access-list (mandatory)
access-list <as-path-access-list>
prefix-list
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→multicast
prefix-list-name (mandatory)
prefix-list-name PREFIX-LIST-NAME
route-map
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→multicast
route-map-name (mandatory)
Route-map name.
route-map-name ROUTE-MAP-NAME
default-originate
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→multicast default-originate
route-map
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→multicast default-originate
ipv6-labeled-unicast
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→labeled-unicast
enabled
Enable or disable IPv6 labeled unicast Address Family for this neighbor.
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→labeled-unicast
Default value
true
as-override
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→labeled-unicast
Default value
false
maximum-prefix-out
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→labeled-unicast
send-community
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→labeled-unicast
Default value
all
weight
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→labeled-unicast
allowas-in
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→labeled-unicast
attribute-unchanged
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→labeled-unicast
route-reflector-client
If true, configure a neighbor as Route Reflector client. This only applies to internal neighbors (IGP).
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→labeled-unicast
Default value
false
route-server-client
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→labeled-unicast
Default value
false
soft-reconfiguration-inbound
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→labeled-unicast
Default value
false
capability-orf-prefix-list
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→labeled-unicast
unsuppress-map
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→labeled-unicast
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→labeled-unicast update-group-id
Sub-group identifier.
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→labeled-unicast sub-group-id
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→labeled-unicast packet-queue-length
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→labeled-unicast accepted-prefix
The presence of this comment informs the user that incoming BGP updates are discarded, as per RFC8212 behaviour.
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→labeled-unicast inbound-ebgp-requires-policy
The presence of this comment informs the user that outgoing BGP updates are discarded, as per RFC8212 behaviour.
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→labeled-unicast outbound-ebgp-requires-policy
addpath
Configure addpath.
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→labeled-unicast addpath
tx-all-paths
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→labeled-unicast addpath
Default value
false
tx-best-path-per-AS
If true, use addpath to advertise the bestpath per each neighboring AS.
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→labeled-unicast addpath
Default value
false
distribute-list
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→labeled-unicast
access-list (mandatory)
access-list ACCESS-LIST
maximum-prefix
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→labeled-unicast maximum-prefix
maximum (mandatory)
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→labeled-unicast maximum-prefix
threshold
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→labeled-unicast maximum-prefix
Default value
75
restart
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→labeled-unicast maximum-prefix
warning-only
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→labeled-unicast maximum-prefix
Default value
false
nexthop-self
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→labeled-unicast nexthop-self
force
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→labeled-unicast nexthop-self
Default value
false
as-outbound-update
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→labeled-unicast as-outbound-update
action
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→labeled-unicast as-outbound-update
Default value
remove
as-type
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→labeled-unicast as-outbound-update
Default value
private
filter-list
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→labeled-unicast
access-list (mandatory)
access-list <as-path-access-list>
prefix-list
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→labeled-unicast
prefix-list-name (mandatory)
prefix-list-name PREFIX-LIST-NAME
route-map
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→labeled-unicast
route-map-name (mandatory)
Route-map name.
route-map-name ROUTE-MAP-NAME
default-originate
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→labeled-unicast default-originate
route-map
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→labeled-unicast default-originate
ipv6-flowspec
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→flowspec
enabled
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→flowspec
Default value
true
route-reflector-client
If true, configure a neighbor as Route Reflector client. This only applies to internal neighbors (IGP).
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→flowspec
Default value
false
route-server-client
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→flowspec
Default value
false
soft-reconfiguration-inbound
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→flowspec
Default value
false
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→flowspec update-group-id
Sub-group identifier.
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→flowspec sub-group-id
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→flowspec packet-queue-length
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→flowspec accepted-prefix
The presence of this comment informs the user that incoming BGP updates are discarded, as per RFC8212 behaviour.
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→flowspec inbound-ebgp-requires-policy
The presence of this comment informs the user that outgoing BGP updates are discarded, as per RFC8212 behaviour.
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→flowspec outbound-ebgp-requires-policy
filter-list
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→flowspec
access-list (mandatory)
access-list <as-path-access-list>
prefix-list
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→flowspec
prefix-list-name (mandatory)
prefix-list-name PREFIX-LIST-NAME
route-map
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→flowspec
route-map-name (mandatory)
Route-map name.
route-map-name ROUTE-MAP-NAME
ipv6-vpn
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→vpn
enabled
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→vpn
Default value
true
unsuppress-map
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→vpn
as-override
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→vpn
Default value
false
maximum-prefix-out
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→vpn
send-community
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→vpn
Default value
all
weight
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→vpn
allowas-in
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→vpn
attribute-unchanged
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→vpn
route-reflector-client
If true, configure a neighbor as Route Reflector client. This only applies to internal neighbors (IGP).
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→vpn
Default value
false
route-server-client
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→vpn
Default value
false
soft-reconfiguration-inbound
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→vpn
Default value
false
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-vpn␣
˓→update-group-id
Sub-group identifier.
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-vpn␣
˓→sub-group-id
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-vpn␣
˓→packet-queue-length
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-vpn␣
˓→accepted-prefix
The presence of this comment informs the user that incoming BGP updates are discarded, as per RFC8212 behaviour.
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-vpn␣
˓→inbound-ebgp-requires-policy
The presence of this comment informs the user that outgoing BGP updates are discarded, as per RFC8212 behaviour.
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-vpn␣
˓→outbound-ebgp-requires-policy
addpath
Configure addpath.
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→vpn addpath
tx-all-paths
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→vpn addpath
Default value
false
tx-best-path-per-AS
If true, use addpath to advertise the bestpath per each neighboring AS.
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→vpn addpath
Default value
false
distribute-list
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→vpn
access-list (mandatory)
access-list ACCESS-LIST
maximum-prefix
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→vpn maximum-prefix
maximum (mandatory)
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→vpn maximum-prefix
threshold
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→vpn maximum-prefix
Default value
75
restart
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→vpn maximum-prefix
warning-only
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→vpn maximum-prefix
Default value
false
nexthop-self
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→vpn nexthop-self
force
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→vpn nexthop-self
Default value
false
as-outbound-update
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→vpn as-outbound-update
action
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→vpn as-outbound-update
Default value
remove
as-type
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→vpn as-outbound-update
Default value
private
filter-list
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→vpn
access-list (mandatory)
access-list <as-path-access-list>
prefix-list
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→vpn
prefix-list-name (mandatory)
prefix-list-name PREFIX-LIST-NAME
route-map
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family ipv6-
˓→vpn
route-map-name (mandatory)
Route-map name.
route-map-name ROUTE-MAP-NAME
l2vpn-evpn
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family l2vpn-
˓→evpn
enabled
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family l2vpn-
˓→evpn
Default value
true
nexthop-self
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family l2vpn-
˓→evpn
Default value
false
route-reflector-client
If true, configure a neighbor as Route Reflector client. This only applies to internal neighbors (IGP).
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family l2vpn-
˓→evpn
Default value
false
route-server-client
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family l2vpn-
˓→evpn
Default value
false
soft-reconfiguration-inbound
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family l2vpn-
˓→evpn
Default value
false
allowas-in
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family l2vpn-
˓→evpn
attribute-unchanged
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family l2vpn-
˓→evpn
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family l2vpn-
˓→evpn update-group-id
Sub-group identifier.
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family l2vpn-
˓→evpn sub-group-id
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family l2vpn-
˓→evpn packet-queue-length
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family l2vpn-
˓→evpn accepted-prefix
The presence of this comment informs the user that incoming BGP updates are discarded, as per RFC8212 behaviour.
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family l2vpn-
˓→evpn inbound-ebgp-requires-policy
The presence of this comment informs the user that outgoing BGP updates are discarded, as per RFC8212 behaviour.
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> address-family l2vpn-
˓→evpn outbound-ebgp-requires-policy
route-map
vrouter running config# vrf <vrf> routing bgp neighbor <neighbor> address-family l2vpn-
˓→evpn
route-map-name (mandatory)
Route-map name.
route-map-name ROUTE-MAP-NAME
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> connections established
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> connections dropped
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> local-host name
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> local-host port
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> remote-host name
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> remote-host port
Nexthop data.
Nexthop IP address.
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> nexthop address
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> nexthop global-address
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> nexthop local-address
Read/Write thread.
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> thread read-enabled
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> thread write-enabled
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> message-statistics␣
˓→packet-wait-process
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> message-statistics␣
˓→packet-wait-written
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> message-statistics open-
˓→sent
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> message-statistics opens-
˓→received
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> message-statistics␣
˓→notifications-sent
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> message-statistics␣
˓→notifications-received
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> message-statistics␣
˓→updates-sent
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> message-statistics␣
˓→updates-received
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> message-statistics␣
˓→keepalives-sent
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> message-statistics␣
˓→keepalives-received
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> message-statistics route-
˓→refresh-sent
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> message-statistics route-
˓→refresh-received
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> message-statistics␣
˓→capability-sent
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> message-statistics␣
˓→capability-received
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> message-statistics total-
˓→sent
vrouter> show state vrf <vrf> routing bgp neighbor <neighbor> message-statistics total-
˓→received
unnumbered-neighbor
List of unnumbered neighbors that locally use ipv6 link local addresses,and discover remote ipv6 link local by using
the router advertisement daemon.
neighbor-group
ipv6-only
Default value
true
rpki
enabled
Default value
true
expire-interval
Default value
7200
polling-period
Default value
3600
retry-interval
Default value
600
cache-server
address (mandatory)
address ADDRESS
Description
ADDRESS
val-
ues
<A.B.C.D>
An IPv4 address.
<fqdn>The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
vrouter> show state vrf <vrf> routing bgp rpki cache-server <uint8> status
ssh
port (mandatory)
Port number.
port <uint16>
user-name (mandatory)
user-name <string>
key (mandatory)
key <string>
tcp
port (mandatory)
Port number.
port <uint16>
ldp
LDP configuration.
enabled
Default value
true
router-id
discovery
Discovery parameters.
hello
vrouter running config# vrf <vrf> routing mpls ldp discovery hello
holdtime
vrouter running config# vrf <vrf> routing mpls ldp discovery hello
vrouter running hello# holdtime <uint16>
Default value
15
interval
vrouter running config# vrf <vrf> routing mpls ldp discovery hello
vrouter running hello# interval <uint16>
Default value
5
dual-stack
cisco-interop
Use Cisco non-compliant format to send and interpret the Dual-Stack capability TLV.
Default value
false
transport-preference
Configure preferred address family for TCP transport connection with neighbor.
Default value
ipv6
neighbor
vrouter running config# vrf <vrf> routing mpls ldp neighbor <neighbor>
password
The password.
vrouter running config# vrf <vrf> routing mpls ldp neighbor <neighbor>
vrouter running neighbor <neighbor># password <string>
ttl-security
vrouter running config# vrf <vrf> routing mpls ldp neighbor <neighbor> ttl-security
hops
vrouter running config# vrf <vrf> routing mpls ldp neighbor <neighbor> ttl-security
vrouter running ttl-security# hops <uint8>
disable
vrouter running config# vrf <vrf> routing mpls ldp neighbor <neighbor> ttl-security
vrouter running ttl-security# disable true|false
Default value
false
address-family
ipv4
IPv4.
vrouter running config# vrf <vrf> routing mpls ldp address-family ipv4
session-holdtime
vrouter running config# vrf <vrf> routing mpls ldp address-family ipv4
vrouter running ipv4# session-holdtime <uint16>
Default value
180
discovery
Discovery parameters.
vrouter running config# vrf <vrf> routing mpls ldp address-family ipv4 discovery
transport-address (mandatory)
vrouter running config# vrf <vrf> routing mpls ldp address-family ipv4 discovery
vrouter running discovery# transport-address TRANSPORT-ADDRESS
hello
vrouter running config# vrf <vrf> routing mpls ldp address-family ipv4 discovery hello
holdtime
vrouter running config# vrf <vrf> routing mpls ldp address-family ipv4 discovery hello
vrouter running hello# holdtime <uint16>
Default value
15
interval
vrouter running config# vrf <vrf> routing mpls ldp address-family ipv4 discovery hello
vrouter running hello# interval <uint16>
Default value
5
interface
vrouter running config# vrf <vrf> routing mpls ldp address-family ipv4 interface
˓→<interface>
label
vrouter running config# vrf <vrf> routing mpls ldp address-family ipv4 label
local
vrouter running config# vrf <vrf> routing mpls ldp address-family ipv4 label local
advertise
vrouter running config# vrf <vrf> routing mpls ldp address-family ipv4 label local␣
˓→advertise
for
vrouter running config# vrf <vrf> routing mpls ldp address-family ipv4 label local␣
˓→advertise
to
vrouter running config# vrf <vrf> routing mpls ldp address-family ipv4 label local␣
˓→advertise
explicit-null
vrouter running config# vrf <vrf> routing mpls ldp address-family ipv4 label local␣
˓→advertise explicit-null
for
vrouter running config# vrf <vrf> routing mpls ldp address-family ipv4 label local␣
˓→advertise explicit-null
allocate
vrouter running config# vrf <vrf> routing mpls ldp address-family ipv4 label local␣
˓→allocate
for
IP access-list.
vrouter running config# vrf <vrf> routing mpls ldp address-family ipv4 label local␣
˓→allocate
host-routes
vrouter running config# vrf <vrf> routing mpls ldp address-family ipv4 label local␣
˓→allocate
remote
vrouter running config# vrf <vrf> routing mpls ldp address-family ipv4 label remote
accept
vrouter running config# vrf <vrf> routing mpls ldp address-family ipv4 label remote␣
˓→accept
for
vrouter running config# vrf <vrf> routing mpls ldp address-family ipv4 label remote␣
˓→accept
from
vrouter running config# vrf <vrf> routing mpls ldp address-family ipv4 label remote␣
˓→accept
ipv6
IPv6.
vrouter running config# vrf <vrf> routing mpls ldp address-family ipv6
session-holdtime
vrouter running config# vrf <vrf> routing mpls ldp address-family ipv6
vrouter running ipv6# session-holdtime <uint16>
Default value
180
discovery
Discovery parameters.
vrouter running config# vrf <vrf> routing mpls ldp address-family ipv6 discovery
transport-address (mandatory)
vrouter running config# vrf <vrf> routing mpls ldp address-family ipv6 discovery
vrouter running discovery# transport-address TRANSPORT-ADDRESS
hello
vrouter running config# vrf <vrf> routing mpls ldp address-family ipv6 discovery hello
holdtime
vrouter running config# vrf <vrf> routing mpls ldp address-family ipv6 discovery hello
vrouter running hello# holdtime <uint16>
Default value
15
interval
vrouter running config# vrf <vrf> routing mpls ldp address-family ipv6 discovery hello
vrouter running hello# interval <uint16>
Default value
5
interface
vrouter running config# vrf <vrf> routing mpls ldp address-family ipv6 interface
˓→<interface>
label
vrouter running config# vrf <vrf> routing mpls ldp address-family ipv6 label
local
vrouter running config# vrf <vrf> routing mpls ldp address-family ipv6 label local
advertise
vrouter running config# vrf <vrf> routing mpls ldp address-family ipv6 label local␣
˓→advertise
for
vrouter running config# vrf <vrf> routing mpls ldp address-family ipv6 label local␣
˓→advertise
to
vrouter running config# vrf <vrf> routing mpls ldp address-family ipv6 label local␣
˓→advertise
explicit-null
vrouter running config# vrf <vrf> routing mpls ldp address-family ipv6 label local␣
˓→advertise explicit-null
for
vrouter running config# vrf <vrf> routing mpls ldp address-family ipv6 label local␣
˓→advertise explicit-null
allocate
vrouter running config# vrf <vrf> routing mpls ldp address-family ipv6 label local␣
˓→allocate
for
IP access-list.
vrouter running config# vrf <vrf> routing mpls ldp address-family ipv6 label local␣
˓→allocate
host-routes
vrouter running config# vrf <vrf> routing mpls ldp address-family ipv6 label local␣
˓→allocate
remote
vrouter running config# vrf <vrf> routing mpls ldp address-family ipv6 label remote
accept
vrouter running config# vrf <vrf> routing mpls ldp address-family ipv6 label remote␣
˓→accept
for
vrouter running config# vrf <vrf> routing mpls ldp address-family ipv6 label remote␣
˓→accept
from
vrouter running config# vrf <vrf> routing mpls ldp address-family ipv6 label remote␣
˓→accept
nhrp
NHRP configuration.
enabled
Default value
true
hub-mode
Default value
false
vrouter> show state vrf <vrf> routing nhrp nhrp4-cache <string> <protocol> type
NBMA IP address.
vrouter> show state vrf <vrf> routing nhrp nhrp4-cache <string> <protocol> nbma
vrouter> show state vrf <vrf> routing nhrp nhrp4-cache <string> <protocol> timeout
vrouter> show state vrf <vrf> routing nhrp nhrp4-cache <string> <protocol> auth
vrouter> show state vrf <vrf> routing nhrp nhrp4-cache <string> <protocol> used
vrouter> show state vrf <vrf> routing nhrp nhrp4-cache <string> <protocol> identity
vrouter> show state vrf <vrf> routing nhrp nhrp6-cache <string> <protocol> type
NBMA IP address.
vrouter> show state vrf <vrf> routing nhrp nhrp6-cache <string> <protocol> nbma
vrouter> show state vrf <vrf> routing nhrp nhrp6-cache <string> <protocol> timeout
vrouter> show state vrf <vrf> routing nhrp nhrp6-cache <string> <protocol> auth
vrouter> show state vrf <vrf> routing nhrp nhrp6-cache <string> <protocol> used
vrouter> show state vrf <vrf> routing nhrp nhrp6-cache <string> <protocol> identity
vrouter> show state vrf <vrf> routing nhrp nhrp4-nhs <string> <nbma> fqdn
vrouter> show state vrf <vrf> routing nhrp nhrp4-nhs <string> <nbma> protocol
vrouter> show state vrf <vrf> routing nhrp nhrp6-nhs <string> <nbma> fqdn
vrouter> show state vrf <vrf> routing nhrp nhrp6-nhs <string> <nbma> protocol
NHRP Connection.
vrouter> show state vrf <vrf> routing nhrp connection <string> <string> notifier-active
vrouter> show state vrf <vrf> routing nhrp connection <string> <string> sa-count
vrouter> show state vrf <vrf> routing nhrp connection <string> <string> identity
ospf
OSPF configuration.
enabled
Default value
true
router-id
abr-type
Default value
cisco
write-multiplier
Default value
20
auto-cost
Calculate OSPF interface cost according to reference bandwidth (Mbits per second).
Default value
100000
opaque-lsa
compatible-rfc1583
default-metric
log-adjacency-changes
refresh-timer
Default value
10
area
default-cost
export-list
Set the filter for networks announced to other areas (access-list name).
import-list
Set the filter for networks from other areas announced to the specified one (access-list name).
shortcut
nssa
summary
summary true|false
Default value
true
translate
NSSA-ABR translate.
translate TRANSLATE
Default value
candidate
stub
summary
summary true|false
Default value
true
virtual-link
Virtual links.
vrouter running config# vrf <vrf> routing ospf area <area> virtual-link <virtual-link>
authentication
Enable authentication.
vrouter running config# vrf <vrf> routing ospf area <area> authentication
message-digest
vrouter running config# vrf <vrf> routing ospf area <area> authentication
vrouter running authentication# message-digest true|false
filter-list
vrouter running config# vrf <vrf> routing ospf area <area> filter-list
input
vrouter running config# vrf <vrf> routing ospf area <area> filter-list
vrouter running filter-list# input <string>
output
vrouter running config# vrf <vrf> routing ospf area <area> filter-list
vrouter running filter-list# output <string>
range
action
action ACTION
Default value
advertise
cost
cost <uint32>
default-information
always
metric
metric-type
Default value
2
route-map
distance
all
external
inter-area
intra-area
max-metric
administrative
on-shutdown
on-startup
neighbor
Neighbor router.
poll-interval
poll-interval <uint16>
priority
Neighbor priority.
priority <uint8>
network
area (mandatory)
area AREA
passive-interface
address
IPv4 address.
address ADDRESS
timers
lsa
min-arrival
throttle
lsa
spf
vrouter running config# vrf <vrf> routing ospf timers throttle spf
delay (mandatory)
vrouter running config# vrf <vrf> routing ospf timers throttle spf
vrouter running spf# delay <uint32>
init-hold-time (mandatory)
vrouter running config# vrf <vrf> routing ospf timers throttle spf
vrouter running spf# init-hold-time <uint32>
max-hold-time (mandatory)
vrouter running config# vrf <vrf> routing ospf timers throttle spf
vrouter running spf# max-hold-time <uint32>
distribute-list
vrouter running config# vrf <vrf> routing ospf distribute-list out <distribute-list>
access-list (mandatory)
vrouter running config# vrf <vrf> routing ospf distribute-list out <distribute-list>
vrouter running distribute-list out <distribute-list># access-list <string>
redistribute
metric
metric <uint32>
metric-type
metric-type <uint8>
route-map
route-map <string>
id
Table ID.
id <uint16>
rip
neighbor
Specifies the RIP neighbors. Useful for a non-broadcast multiple access (NBMA) network.
static-route
enabled
Default value
true
allow-ecmp
Default value
false
default-information-originate
Default value
false
default-metric
Default value
1
network
interface
passive-interface
administrative-distance
Administrative distance.
default
source
distance (mandatory)
Administrative distance.
distance <uint8>
access-list
Access-list name.
access-list ACCESS-LIST
redistribute
metric
Metric used for the redistributed route. If a metric is not specified, the metric configured with the default-metric
attribute in RIP router configuration is used. If the default-metric attribute has not been configured, the default
metric for redistributed routes is 0.
metric <uint8>
route-map
Applies the conditions of the specified route-map to routes that are redistributed into the RIP routing instance.
route-map ROUTE-MAP
route-map
route-map-name (mandatory)
Route-map name.
route-map-name ROUTE-MAP-NAME
timers
flush-interval
Default value
120
holddown-interval
Default value
180
update-interval
Default value
30
version
receive
Default value
1-2
send
Default value
2
distribute-list
access-list
Access-list name.
access-list ACCESS-LIST
prefix-list
Prefix-list name.
prefix-list PREFIX-LIST
offset-list
metric (mandatory)
Route metric.
metric <uint8>
access-list (mandatory)
Access-list name.
access-list ACCESS-LIST
Route protocol.
vrouter> show state vrf <vrf> routing rip state route <route> protocol
Route type.
vrouter> show state vrf <vrf> routing rip state route <route> route-type
vrouter> show state vrf <vrf> routing rip state route <route> nexthop
vrouter> show state vrf <vrf> routing rip state route <route> interface
Route metric.
vrouter> show state vrf <vrf> routing rip state route <route> metric
The time when the most recent RIP update was received from this neighbor.
vrouter> show state vrf <vrf> routing rip state neighbor <neighbor> last-update
The number of RIP invalid packets received from this neighbor which were subsequently discarded for any reason
(e.g. a version 0 packet, or an unknown command type).
vrouter> show state vrf <vrf> routing rip state neighbor <neighbor> bad-packets-
˓→received
The number of routes received from this neighbor, in valid RIP packets, which were ignored for any reason (e.g.
unknown address family, or invalid metric).
vrouter> show state vrf <vrf> routing rip state neighbor <neighbor> bad-routes-received
ospf6
OSPFv3 configuration.
enabled
Default value
true
router-id
auto-cost
Calculate OSPF interface cost according to reference bandwidth (Mbits per second).
Default value
100000
log-adjacency-changes
area
export-list
Set the filter for networks announced to other areas (access-list name).
import-list
Set the filter for networks from other areas announced to the specified one (access-list name).
stub
vrouter running config# vrf <vrf> routing ospf6 area <area> stub
summary
vrouter running config# vrf <vrf> routing ospf6 area <area> stub
vrouter running stub# summary true|false
Default value
true
filter-list
vrouter running config# vrf <vrf> routing ospf6 area <area> filter-list
input
vrouter running config# vrf <vrf> routing ospf6 area <area> filter-list
vrouter running filter-list# input <string>
output
vrouter running config# vrf <vrf> routing ospf6 area <area> filter-list
vrouter running filter-list# output <string>
range
advertise
advertise true|false
Default value
true
cost
cost <uint32>
distance
all
external
inter-area
intra-area
interface
area (mandatory)
area AREA
redistribute
route-map
route-map <string>
timers
lsa
min-arrival
throttle
lsa
spf
vrouter running config# vrf <vrf> routing ospf6 timers throttle spf
delay (mandatory)
vrouter running config# vrf <vrf> routing ospf6 timers throttle spf
vrouter running spf# delay <uint32>
init-hold-time (mandatory)
vrouter running config# vrf <vrf> routing ospf6 timers throttle spf
vrouter running spf# init-hold-time <uint32>
max-hold-time (mandatory)
vrouter running config# vrf <vrf> routing ospf6 timers throttle spf
vrouter running spf# max-hold-time <uint32>
ripng
aggregate
static-route
enabled
Default value
true
allow-ecmp
Default value
false
default-information-originate
Default value
false
default-metric
Default value
1
network
interface
passive-interface
redistribute
metric
Metric used for the redistributed route. If a metric is not specified, the metric configured with the default-metric
attribute in RIPng router configuration is used. If the default-metric attribute has not been configured, the default
metric for redistributed routes is 0.
metric <uint8>
route-map
Applies the conditions of the specified route-map to routes that are redistributed into the RIPng routing instance.
route-map ROUTE-MAP
timers
flush-interval
Default value
120
holddown-interval
Default value
180
update-interval
Default value
30
distribute-list
access-list
Access-list name.
access-list ACCESS-LIST
prefix-list
Prefix-list name.
prefix-list PREFIX-LIST
offset-list
metric (mandatory)
Route metric.
metric <uint8>
access-list (mandatory)
Access-list name.
access-list ACCESS-LIST
Route protocol.
vrouter> show state vrf <vrf> routing ripng state route <route> protocol
Route type.
vrouter> show state vrf <vrf> routing ripng state route <route> route-type
vrouter> show state vrf <vrf> routing ripng state route <route> nexthop
Route metric.
vrouter> show state vrf <vrf> routing ripng state route <route> metric
The time when the most recent RIP update was received from this neighbor.
vrouter> show state vrf <vrf> routing ripng state neighbor <neighbor> last-update
The number of RIP invalid packets received from this neighbor which were subsequently discarded for any reason
(e.g. a version 0 packet, or an unknown command type).
vrouter> show state vrf <vrf> routing ripng state neighbor <neighbor> bad-packets-
˓→received
The number of routes received from this neighbor, in valid RIP packets, which were ignored for any reason (e.g.
unknown address family, or invalid metric).
vrouter> show state vrf <vrf> routing ripng state neighbor <neighbor> bad-routes-
˓→received
policy-based-routing
ipv4-rule
not
not
match
inbound-interface
inbound-interface INBOUND-INTERFACE
mark
mark MARK
source
source SOURCE
destination
destination DESTINATION
vrouter> show state vrf <vrf> routing policy-based-routing ipv4-rule <0-99999> match␣
˓→outbound-interface
vrouter> show state vrf <vrf> routing policy-based-routing ipv4-rule <0-99999> match␣
˓→tos
vrouter> show state vrf <vrf> routing policy-based-routing ipv4-rule <0-99999> match␣
˓→other <string> value
action
lookup (mandatory)
lookup LOOKUP
vrouter> show state vrf <vrf> routing policy-based-routing ipv4-rule <0-99999> action␣
˓→goto
Other actions.
vrouter> show state vrf <vrf> routing policy-based-routing ipv4-rule <0-99999> action␣
˓→other
ipv6-rule
not
not
match
inbound-interface
inbound-interface INBOUND-INTERFACE
mark
mark MARK
source
source SOURCE
destination
destination DESTINATION
vrouter> show state vrf <vrf> routing policy-based-routing ipv6-rule <0-99999> match␣
˓→outbound-interface
vrouter> show state vrf <vrf> routing policy-based-routing ipv6-rule <0-99999> match␣
˓→tos
vrouter> show state vrf <vrf> routing policy-based-routing ipv6-rule <0-99999> match␣
˓→other <string> value
action
lookup (mandatory)
lookup LOOKUP
vrouter> show state vrf <vrf> routing policy-based-routing ipv6-rule <0-99999> action␣
˓→goto
Other actions.
vrouter> show state vrf <vrf> routing policy-based-routing ipv6-rule <0-99999> action␣
˓→other
vrouter> show state vrf <vrf> routing rib ipv4-count kernel routes
vrouter> show state vrf <vrf> routing rib ipv4-count kernel installed-routes
vrouter> show state vrf <vrf> routing rib ipv4-count connected routes
vrouter> show state vrf <vrf> routing rib ipv4-count connected installed-routes
vrouter> show state vrf <vrf> routing rib ipv4-count static routes
vrouter> show state vrf <vrf> routing rib ipv4-count static installed-routes
vrouter> show state vrf <vrf> routing rib ipv4-count ospf routes
vrouter> show state vrf <vrf> routing rib ipv4-count ospf installed-routes
vrouter> show state vrf <vrf> routing rib ipv4-count ebgp routes
vrouter> show state vrf <vrf> routing rib ipv4-count ebgp installed-routes
vrouter> show state vrf <vrf> routing rib ipv4-count ibgp routes
vrouter> show state vrf <vrf> routing rib ipv4-count ibgp installed-routes
vrouter> show state vrf <vrf> routing rib ipv4-count nhrp routes
vrouter> show state vrf <vrf> routing rib ipv4-count nhrp installed-routes
vrouter> show state vrf <vrf> routing rib ipv4-count total routes
vrouter> show state vrf <vrf> routing rib ipv4-count total installed-routes
vrouter> show state vrf <vrf> routing rib ipv6-count kernel routes
vrouter> show state vrf <vrf> routing rib ipv6-count kernel installed-routes
vrouter> show state vrf <vrf> routing rib ipv6-count connected routes
vrouter> show state vrf <vrf> routing rib ipv6-count connected installed-routes
vrouter> show state vrf <vrf> routing rib ipv6-count static routes
vrouter> show state vrf <vrf> routing rib ipv6-count static installed-routes
vrouter> show state vrf <vrf> routing rib ipv6-count ospf routes
vrouter> show state vrf <vrf> routing rib ipv6-count ospf installed-routes
vrouter> show state vrf <vrf> routing rib ipv6-count ebgp routes
vrouter> show state vrf <vrf> routing rib ipv6-count ebgp installed-routes
vrouter> show state vrf <vrf> routing rib ipv6-count ibgp routes
vrouter> show state vrf <vrf> routing rib ipv6-count ibgp installed-routes
vrouter> show state vrf <vrf> routing rib ipv6-count nhrp routes
vrouter> show state vrf <vrf> routing rib ipv6-count nhrp installed-routes
vrouter> show state vrf <vrf> routing rib ipv6-count total routes
vrouter> show state vrf <vrf> routing rib ipv6-count total installed-routes
Route next-hops.
Route protocol.
vrouter> show state vrf <vrf> routing rib ipv4-route <ipv4-route> next-hop <next-hop>␣
˓→protocol
vrouter> show state vrf <vrf> routing rib ipv4-route <ipv4-route> next-hop <next-hop>␣
˓→distance
Route metric.
vrouter> show state vrf <vrf> routing rib ipv4-route <ipv4-route> next-hop <next-hop>␣
˓→metric
Output interface.
vrouter> show state vrf <vrf> routing rib ipv4-route <ipv4-route> next-hop <next-hop>␣
˓→interface
vrouter> show state vrf <vrf> routing rib ipv4-route <ipv4-route> next-hop <next-hop>␣
˓→selected
vrouter> show state vrf <vrf> routing rib ipv4-route <ipv4-route> next-hop <next-hop>␣
˓→fib
vrouter> show state vrf <vrf> routing rib ipv4-route <ipv4-route> next-hop <next-hop>␣
˓→directly-connected
vrouter> show state vrf <vrf> routing rib ipv4-route <ipv4-route> next-hop <next-hop>␣
˓→duplicate
vrouter> show state vrf <vrf> routing rib ipv4-route <ipv4-route> next-hop <next-hop>␣
˓→active
vrouter> show state vrf <vrf> routing rib ipv4-route <ipv4-route> next-hop <next-hop>␣
˓→on-link
vrouter> show state vrf <vrf> routing rib ipv4-route <ipv4-route> next-hop <next-hop>␣
˓→recursive
Route uptime.
vrouter> show state vrf <vrf> routing rib ipv4-route <ipv4-route> next-hop <next-hop>␣
˓→uptime
Route next-hops.
Route protocol.
vrouter> show state vrf <vrf> routing rib ipv6-route <ipv6-route> next-hop <next-hop>␣
˓→protocol
vrouter> show state vrf <vrf> routing rib ipv6-route <ipv6-route> next-hop <next-hop>␣
˓→distance
Route metric.
vrouter> show state vrf <vrf> routing rib ipv6-route <ipv6-route> next-hop <next-hop>␣
˓→metric
Output interface.
vrouter> show state vrf <vrf> routing rib ipv6-route <ipv6-route> next-hop <next-hop>␣
˓→interface
vrouter> show state vrf <vrf> routing rib ipv6-route <ipv6-route> next-hop <next-hop>␣
˓→selected
vrouter> show state vrf <vrf> routing rib ipv6-route <ipv6-route> next-hop <next-hop>␣
˓→fib
vrouter> show state vrf <vrf> routing rib ipv6-route <ipv6-route> next-hop <next-hop>␣
˓→directly-connected
vrouter> show state vrf <vrf> routing rib ipv6-route <ipv6-route> next-hop <next-hop>␣
˓→duplicate
vrouter> show state vrf <vrf> routing rib ipv6-route <ipv6-route> next-hop <next-hop>␣
˓→active
vrouter> show state vrf <vrf> routing rib ipv6-route <ipv6-route> next-hop <next-hop>␣
˓→on-link
vrouter> show state vrf <vrf> routing rib ipv6-route <ipv6-route> next-hop <next-hop>␣
˓→recursive
Route uptime.
vrouter> show state vrf <vrf> routing rib ipv6-route <ipv6-route> next-hop <next-hop>␣
˓→uptime
3.2.30 DHCP
server
enabled
Default value
true
default-lease-time
Default network address lease time assigned to DHCP clients (in seconds, at least 180s).
Default value
43200
max-lease-time
Maximum network address lease time assigned to DHCP clients (in seconds, at least 180s or the default-lease value).
Default value
86400
dhcp-options
dhcp-server-identifier
DHCP server identifier (IPv4 address) used in DHCP messages to allow the client to distinguish between lease
offers.
domain-name
domain-name-server
ntp-server
interface-mtu
netbios-name-server
netbios-node-type
netbios-scope
NETBIOS over TCP/IP scope parameter for the client as specified in RFC 1001/1002.
time-offset
subnet
Subnet configuration.
interface
default-gateway
default-lease-time
Default network address lease time assigned to DHCP clients for this subnet (in seconds, at least 180s).
max-lease-time
Maximum network address lease time assigned to DHCP clients for this subnet (in seconds, at least 180s or the
default-lease value).
Subnet state.
vrouter> show state vrf <vrf> dhcp server subnet <subnet> state
range
IPv4 range.
host
MAC-ADDRESS (mandatory)
MAC-ADDRESS
IP-ADDRESS (mandatory)
IP-ADDRESS
dhcp-options
vrouter running config# vrf <vrf> dhcp server subnet <subnet> dhcp-options
dhcp-server-identifier
DHCP server identifier (IPv4 address) used in DHCP messages to allow the client to distinguish between lease
offers.
vrouter running config# vrf <vrf> dhcp server subnet <subnet> dhcp-options
vrouter running dhcp-options# dhcp-server-identifier DHCP-SERVER-IDENTIFIER
domain-name
vrouter running config# vrf <vrf> dhcp server subnet <subnet> dhcp-options
vrouter running dhcp-options# domain-name <string>
domain-name-server
vrouter running config# vrf <vrf> dhcp server subnet <subnet> dhcp-options
vrouter running dhcp-options# domain-name-server DOMAIN-NAME-SERVER
ntp-server
vrouter running config# vrf <vrf> dhcp server subnet <subnet> dhcp-options
vrouter running dhcp-options# ntp-server NTP-SERVER
interface-mtu
vrouter running config# vrf <vrf> dhcp server subnet <subnet> dhcp-options
vrouter running dhcp-options# interface-mtu <uint16>
netbios-name-server
vrouter running config# vrf <vrf> dhcp server subnet <subnet> dhcp-options
vrouter running dhcp-options# netbios-name-server NETBIOS-NAME-SERVER
netbios-node-type
vrouter running config# vrf <vrf> dhcp server subnet <subnet> dhcp-options
vrouter running dhcp-options# netbios-node-type NETBIOS-NODE-TYPE
netbios-scope
NETBIOS over TCP/IP scope parameter for the client as specified in RFC 1001/1002.
vrouter running config# vrf <vrf> dhcp server subnet <subnet> dhcp-options
vrouter running dhcp-options# netbios-scope <string>
time-offset
vrouter running config# vrf <vrf> dhcp server subnet <subnet> dhcp-options
vrouter running dhcp-options# time-offset <int32>
vrouter> show state vrf <vrf> dhcp server dhcp-server-leases <dhcp-server-leases> ends
MAC address of the network interface on which the lease will be used.
vrouter> show state vrf <vrf> dhcp server dhcp-server-leases <dhcp-server-leases> hw-
˓→mac-address
vrouter> show state vrf <vrf> dhcp server dhcp-server-leases <dhcp-server-leases> uid
State the lease will move to when the current state expires.
vrouter> show state vrf <vrf> dhcp server dhcp-server-leases <dhcp-server-leases> next-
˓→binding-state
relay
enabled
Default value
true
handle-option
HANDLE-OPTION Description
values
append Append our own set of relay options to the packet, leaving the supplied option field
intact.
replace Replace the existing agent option field.
forward Forward the packet unchanged.
discard Discard the packet.
Default value
append
drop-unmatched
If true, drop packets from upstream servers if they were generated in response to a different relay agent.
Default value
false
hop-count
Default value
10
max-size
Maximum packet size to send to a DHCPv4 server. If a DHCP packet size surpasses this value it will be forwarded
without appending relay agent information.
Default value
576
dhcp-server
enabled
Default value
true
interface
Interface(s) on which to listen to DHCPv4 queries. If ommitted, DHCP relay will listen on all broadcast interfaces.
handle-option
Handling of DHCPv4 packets that already contain relay agent options. Override the matching option in root context.
HANDLE-OPTION Description
values
append Append our own set of relay options to the packet, leaving the supplied option field
intact.
replace Replace the existing agent option field.
forward Forward the packet unchanged.
discard Discard the packet.
drop-unmatched
If true, drop packets from upstream servers if they were generated in response to a different relay agent. Override
the matching option in root context.
hop-count
Maximum hop count before packets are discarded. Override the matching option in root context.
max-size
Maximum packet size to send to a DHCPv4 server. If a DHCP packet size surpasses this value it will be forwarded
without appending relay agent information. Override the matching option in root context.
3.2.31 fast-path
enabled
Default value
true
port
core-mask
fast-path
exception
Control plane cores allocated to exception packets processing. If unset, use the first non fast path core.
linux-to-fp
Fast path cores that can receive packets from Linux. It must be included in fast path mask. If unset, all fast path
cores can receive packets from Linux.
qos
Fast path cores dedicated for qos schedulers. These cores do not received any packets from the NIC or Linux.
port
Map fast path cores with network ports, specifying which logical cores poll which ports. Example:
‘c1=0:1/c2=2/c3=0:1:2’ means the logical core 1 polls the port 0 and 1, the core 2 polls the port 2, and the core 3
polls the ports 0, 1, and 2. If unset, each port is polled by all the logical cores of the same socket.
cp-protection
budget
Default value
10
crypto
driver
offload-core-mask
Fast path cores that can do crypto operations for other fast path cores. It must be included in fast path mask. The
crypto offloading is always done on cores in the same NUMA node.
nb-session
nb-buffer
Maximum number of cryptographic buffers, representing the maximum number of in-flight operations, either being
processed by the asynchronous crypto engine, or waiting in crypto device queues.
advanced
nb-mbuf
Number of mbufs (network packet descriptors). The value can be an integer representing the total number of mbufs,
an integer prefixed with ‘+’ representing the number of mbufs to add to the automatic value. In case of NUMA, the
value can be a per-socket list. If unset, nb-mbuf is determined automatically.
machine-memory
Set the memory that will be used by the fast path (hugepages, shm, mallocs. . . ) so it can run on a machine with this
amount of physical memory.
mainloop-sleep-delay
If set, add a sleep time after each idle mainloop turn. This will drastically decrease performance. If the value is 0,
it means it is disabled.
offload
Enable or disabled advanced offload features such as TSO, L4 checksum offloading, or offload information forward-
ing from a guest to the NIC through a virtual interface. If unset, use default product configuration.
vlan-strip
Strip the VLAN header from incoming frames if supported by the hardware. By default, vlan stripping feature is
disabled.
intercore-ring-size
Set the size of the intercore rings, used by dataplane cores to send messages to another dataplane core. The default
size depends on the product.
software-txq
Set the default size of Tx software queue. This field must be a power of 2. Default is 0 (no software queue).
nb-rxd
Set the default number of Rx hardware descriptors for Ethernet ports. The value must be accepted by all devices on
the system. If unset, an automatic value is used.
nb-txd
Set the default number of Tx hardware descriptors for Ethernet ports. The value must be accepted by all devices on
the system. If unset, an automatic value is used.
reserve-hugepages
Enable or disable the automatic huge pages allocation by the fast path. When disabled, the user is responsible for
providing enough huge pages for the fast path to start.
ipv4-netfilter-cache
Default value
true
ipv6-netfilter-cache
Default value
true
ipv4-pre-ipsec-fragmentation
Configure IPv4 pre IPsec fragmentation. When enabled, this behavior helps releasing pressure on the decrypting
device, as the reassembly will be done on the destination host of the inner packet instead of the decrypting device.
It applies only in tunnel mode.
Description
IPV4-PRE-IPSEC-FRAGMENTATION
values
always Pre IPsec fragmentation is always performed.
check-df-bit Pre IPsec fragmentation is performed only if the don’t fragment bit is not set on
the inner packet. Applies only to IPv4 inner packets.
off Post IPsec fragmentation is performed.
Default value
off
ipv6-pre-ipsec-fragmentation
Configure IPv6 pre IPsec fragmentation. When enabled, this behavior helps releasing pressure on the decrypting
device, as the reassembly will be done on the destination host of the inner packet instead of the decrypting device.
It applies only in tunnel mode.
Description
IPV6-PRE-IPSEC-FRAGMENTATION
values
always Pre IPsec fragmentation is always performed.
check-df-bit Pre IPsec fragmentation is performed only if the don’t fragment bit is not set on
the inner packet. Applies only to IPv4 inner packets.
off Post IPsec fragmentation is performed.
Default value
off
hardware-queue-map
Hardware queue map used to change the destination queue according the hash computed on the packet from the
RSS function.
limits
fp-max-if
Maximum number of interfaces. It includes physical ports and virtual interfaces like gre, vlan, . . .
fp-max-vrf
ip4-max-addr
ip4-max-route
ip4-max-neigh
ip6-max-addr
ip6-max-route
ip6-max-neigh
pbr-max-rule
filter4-max-rule
filter6-max-rule
filter4-max-ct
filter6-max-ct
filter-max-ipset
filter-max-ipset-entry
filter-bridge-max-rule
vxlan-max-port
vxlan-max-if
vxlan-max-fdb
reass4-max-queue
reass6-max-queue
ipsec-max-sp
ipsec-max-sa
ip-max-8-table
ip-max-lpm-table
ip-max-lpm-memory
filter-max-cache
filter6-max-cache
vlan-max-if
macvlan-max-if
gre-max-if
svti-max-if
Current number of interfaces. It includes physical ports and virtual interfaces like gre, vlan, . . .
Current amount of memory reserved for IPv4 and IPv6 LPM tree.
cg-nat
max-conntracks
max-nat-entries
max-users
max-blocks
max-block-size
linux-sync
fpm-socket-size
Buffer size of the socket used to communicate between the cache manager and the fast path manager.
Default value
2097152
nl-socket-size
Default value
67108864
ipset-dump-delay
Default value
1
disable
3.2.32 logging
Global Settings
rate-limit
interval
Amount of time that is being measured for rate limiting. A value of 0 disables rate limiting.
Default value
30
burst
Amount of messages that have to occur in the rate limit interval to trigger rate limiting. A value of 0 disables rate
limiting.
Default value
1000
Per-VRF Settings
syslog
Syslog configuration.
enabled
Enable syslog.
Default value
true
remote-server
Description
<remote-server>
val-
ues
<A.B.C.D>
An IPv4 address.
<X:X::X:X>
An IPv6 address.
<host- The domain-name type represents a DNS domain name. Fully quallified left to the models which utilize
name>this type. Internet domain names are only loosely specified. Section 3.5 of RFC 1034 recommends a
syntax (modified in Section 2.1 of RFC 1123). The pattern above is intended to allow for current practice
in domain name use, and some possible future expansion. It is designed to hold various types of domain
names, including names used for A or AAAA records (host names) and other records, such as SRV records.
Note that Internet host names have a stricter syntax (described in RFC 952) than the DNS recommendations
in RFCs 1034 and 1123, and that systems that want to store host names in schema nodes using the domain-
name type are recommended to adhere to this stricter standard to ensure interoperability. The encoding
of DNS names in the DNS protocol is limited to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual
dotted notation. Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase
US-ASCII characters. Internationalized domain names MUST be encoded in punycode as described in
RFC 3492.
protocol
Transmission protocol.
PROTOCOL Description
values
udp Traditional UDP transport. Extremely lossy but standard.
tcp Plain TCP based transport. Loses messages only during certain situations but is widely
available.
Default value
tcp
port
Sets the destination port number for syslog UDP messages to the server.
PORT A 16-bit port number used by a transport protocol such as TCP or UDP.
Default value
514
log-filter
level
EQUAL
EQUAL
greater-or-equal
Send messages with a greater or equal level than the selected one to the server.
greater-or-equal GREATER-OR-EQUAL
not
not LEVEL
LEVEL
LEVEL
tls
enabled
Default value
true
ca-certificate (mandatory)
certificate
private-key
server-authentication
anonymous
No authentication.
anonymous
certificate
certificate
name
name <string>
<string>
<string>
fingerprint
fingerprint <string>
<string>
<string>
HA groups
group
The list of high-availability groups on the device, used to advertise an high-availability status. Each group can be
associated to one notifier and several subscribers.
state
HA neighbor
enabled
Default value
true
node-id (mandatory)
local-address (mandatory)
listen-ha-group (mandatory)
interface (mandatory)
HA conntrack
enabled
Default value
true
local-address (mandatory)
listen-ha-group (mandatory)
interface (mandatory)
protocol-list
accept (mandatory)
protocol
address-list
accept (mandatory)
address
3.2.34 group
Address and network group configuration. They can then be used in the firewall configuration.
ipv4
address-group
Address group.
address
AD- An IPv4 address without a zone index. This type, derived from ipv4-address, may be used in situations
DRESS where the zone is known from the context and hence no zone index is needed.
vrouter> show state vrf <vrf> group ipv4 address-group <string> used
network-group
Network group.
network
vrouter> show state vrf <vrf> group ipv4 network-group <string> used
ipv6
address-group
Address group.
address
AD- An IPv6 address without a zone index. This type, derived from ipv6-address, may be used in situations
DRESS where the zone is known from the context and hence no zone index is needed.
vrouter> show state vrf <vrf> group ipv6 address-group <string> used
network-group
Network group.
network
vrouter> show state vrf <vrf> group ipv6 network-group <string> used
4. Troubleshooting
This guide references common configuration issues one may encounter when using Turbo Router, and indications
on how to address them. These indications suppose you are logged as root and have access to the Linux shell.
In case you cannot investigate and resolve the issue by yourself using this document, make sure you open a ticket
on your 6WIND Customer Zone with the relevant troubleshooting information.
This information can be generated and exported using the following commands:
OK.
vrouter>
See also:
The CLI User Guide, Basics / Commands section for details.
The troubleshooting report includes the following information:
• Linux networking information
– Stats on all known links
– interfaces, addresses, routes, neighbours and IPsec
– active network connections
– Netfilter tables, bridge
• system information
– topology
– processors hierarchy
– interrupts
– memory
– PCI peripherals
– DMI/MBIOS
– kernel version, logs, cmdline and loaded modules
– distribution
– services list
– logs
– processes list
– cpuset
– devices (/dev)
– IRQ affinity
– mounted partitions
• core dumps
• fast path information
– configuration, version, logs, status
– debug info (ports, tables, etc.)
• running and startup configurations
• license information
– average network throughput (measured in Rx)
– average and current number of IPsec tunnels
– average and current number of CG-NAT connections
Symptoms
• systemctl status turbo shows issues
Hints
• On Intel and Arm, check whether the configuration file is correct by looking at fast-path.sh config
output for relevancy, and by checking config file syntactic correctness with fast-path.sh config -c.
Follow the advice regarding deprecated options as it may become problematic in later versions. Take
into account the WARNINGs in the output.
• If you tried running the fast path and it crashed or failed along the way, some “runtime-only” files may
be left unremoved. Make sure to call fast-path.sh stop before trying to start the fast path again.
• Look for error messages either on the console or in the logs. See rsyslog and journalctl sections for
details regarding what can be found in the logs.
• Executable paths may change between two Turbo Router versions. Some shells (bash for example) keep
a cache of the executable paths. After upgrading Turbo Router, if some commands are not found, you
may need to start a new shell.
Hugepages fragmentation
Symptoms
• One of the following messages appears on he console or in the logs:
EAL: Not enough memory available! Requested: <X>MB, available: <Y smaller␣
˓→than X>MB
Not enough physically contiguous memory to allocate the mbuf pool on this␣
˓→socket (0): max_seg_size=178257920, total_mem=459276288, nb_seg=35
Increase the number of huge pages, use larger huge pages, or reboot the␣
˓→machine
PANIC in fpn_socket_mbufpool_create():
Cannot create mbuf pool for socket 0
Hints
• There is a problem with the available memory.
• Add more memory.
• Check the output from /proc/meminfo, especially the MemFree and HugePage_Free fields. See mem-
info section for details.
MemFree gives an indication of how much memory you may use for the fast path shared memory.
HugePage_Free indicates how many huge pages are available for use by the fast path.
Beware, if hugepages are fragmented, you need to allocate more or simply reboot, as the DPDK requires
contiguous physical memory.
Symptoms
• The following message appears on he console or in the logs (and subsequent commands fail with similar
messages):
...
EAL: PCI memory mapped at 0x7ffae4a40000
PMD: eth_em_dev_init(): port_id 2 vendorID=0x8086 deviceID=0x100e
Using fpn_port 0x7ffae654c000 size=150576 (0M)
Killed
//usr/bin/fast-path.sh: error starting //usr/bin//fp-rte. Check logs for␣
˓→details.
At this point, the machine may have hung. Check the logs after reboot, especially if they contain some-
thing similar to:
...
fp-rte[5113]: Using fp_ebtables_vr_shared=0x7ffae63c2000 size=4352 (0M)
fp-rte[5113]: Using fp-tc-shared=0x7ffad976f000 size=524608 (0M)
kernel: [ 1022.485264] fp-rte invoked oom-killer: gfp_mask=0x2d2, order=0,␣
˓→oom_score_adj=0
Note: Look for error messages either on the console or in the logs. See rsyslog and journalctl sections
for details regarding what can be found in the logs.
Hints
• There is a problem with the available memory, the fast path process has been killed because available
memory was getting too small. Typically, after hugepages allocation, the fast path tried to allocate
memory and there was not enough free.
• Add more memory.
• Check the output from /proc/meminfo, especially the MemFree field. See meminfo section for details.
MemFree estimates how much memory is free before starting the fast path.
1G hugepages problems
Symptoms
• The following message appears on he console or in the logs:
Hints
• It seems you enabled the support of 1G hugepages in the kernel boot command line (hugepagesz=1G
default_hugepagesz=1G). The fast path starting script failed to allocate the required amount of
hugepages.
Symptoms
• With VMware 6.0 and vSphere desktop client, starting Turbo Router VM from OVA file fails with the
following message:
See https://kb.vmware.com/s/article/2151537.
Hints
• Use the vSphere HTML5 client (the desktop client is deprecated).
• Repackage the OVA file to use SHA1 hashing instead of the latest SHA256 using ovftool available at
https://www.vmware.com/support/developer/ovf/.
SR-IOV problems
Symptoms
• Starting a VM (with PCI passthrough in its conf) with libvirt fails, yielding:
Hints
• Your NIC and your motherboard must support SR-IOV, and the Linux kernel must have booted with
appropriate options. Enable the Directed I/O parameter in the BIOS (Basic Input/Output System), and
ensure “intel_iommu=on” is provided in the kernel command line.
Symptoms
• Starting Turbo Router with i40e devices in a VM hangs. Looking at the logs:
˓→c20=0/c21=0/c22=1/c23=1/c24=1/c25=1/c26=1/c27=1/c28=1/c29=1/c30=1/c31=1/
˓→vr=16
Jun 22 22:15:07 dut-vm fp-rte[14244]: EAL: Some devices want iova as va but␣
˓→pa will be used because.. EAL: vfio-noiommu mode configured
Hints
• The i40e hardware has a known issue with regards to INTX interrupts. A workaround has been im-
plemented in the vfio-pci kernel driver to hide INTX support and force a fallback to MSIX. The
workaround must be applied on both the VM side and the hypervisor side. Upstream patch: https:
//git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=450744051d20
This issue can be checked by looking at the kernel logs. Without the patch, some interrupt ends up as
an orphan:
But, with the patch, vfio-pci reports that it has hidden INTX support:
Symptoms
• No ports are displayed when calling fp-cli iface.
Hints
• If you are dealing with physical NIC: Check that your NIC is detected by Linux, using lspci. See lspci
section for details.
• Check the output from fast-path.sh config --display and make sure your NIC is among the selected
ethernet cards.
Symptoms
• No packets are forwarded.
• fp-cli stats non-zero shows no (or low) IpForwDatagrams stats.
• fp-cli dpdk-port-stats <port> shows no (or low) rx/tx packets stats.
• ip -s link show <interface> shows no (or low) rx/tx packets stats.
• kill -USR1 $(pidof fp-rte) (Intel and Arm only) shows no (or low) rx/tx packets stats.
Hints
• Check whether configurations between Linux and the fast path are consistent:
– Check IP addresses and routes configured in the kernel, using ip address show and ip route
show. Check whether the interfaces and bridges are up and running using ip link show and
brctl show <bridge_name>.
• Check IP addresses and routes known to the fast path, using fp-cli route4 type all.
• If you are using bridges, check whether your bridges have correct states, using fp-cli bridge.
• Check that fp_dropped fast path statistics are not too high using fp-cli stats percore non-zero.
A high fp_dropped stat suggests that packets are somehow not acceptable for the fast path. The ideal
case is when forwarding stats are evenly spread throughout cores, that is when each core more or less
forwards as many packets as the others. See Fast Path statistics section for an example of stats.
• Check that exception stats fast path statistics are not too high. Basic exceptions indicate how many
packets could not be processed by the fast path, and have thus been injected in the linux stack for slow
path processing. If the value is high, it is a good indicator that IP addresses/routes/tunnels in the fast
path are badly configured. See Fast Path statistics section for an example of stats.
• Check whether it works correctly when the fast path is turned off. See Turn Fast Path off section for
details.
Symptoms
• Packets are not filtered according to your iptables rules.
Hints
• Check whether filtering rules between Linux and fast path are consistent:
– Check filtering rules in the kernel, using ip[6]tables -S. Refer to the ip[6]tables manpage
for details on this command.
– Check filtering rules known to the fast path, using fp-cli nf[4|6]-table
<filter|mangle|nat> [all|nonzero]. Check also whether the filtering module is en-
abled, using fp-cli nf[4|6]. Some targets and rules are not supported in the fast path: check
that you are using only documented supported options.
Connectivity problems
Symptoms
• I can no longer connect (via the network) to my machine.
• The VM was configured to redirect connections to the guest (using something like -netdev user,
id=user.0,hostfwd=tcp::35047-:22).
Hints
• When starting Turbo Router, NIC kernel drivers have been unloaded and thus all IP configuration lost.
Symptoms
• My network configuration no longer works after reboot or Turbo Router restart. For example:
1. My linux bridge is empty after stopping (or restarting) the fast path:
# brctl show
bridge name bridge id STP enabled interfaces
Hints
• The fast path may replace, change, delete and create netdevices. Any tool (brctl, iproute2, etc.) that
use “old” references to netdevices must have its configuration refreshed when the fast path is stopped.
– For linux bridge, recreate the bridge and re-add the ports if need be. e.g.:
Symptoms
• Modules recompilation/removal with DKMS takes too long.
Hints
• Edit the DKMS configuration in /etc/dkms/framework.conf, to prevent it from running some long
operations:
# mkdir -p /etc/dkms
# echo 'no_initrd="y"' >> /etc/dkms/framework.conf
# echo 'no_depmod="y"' >> /etc/dkms/framework.conf
• Disable weak-modules:
Symptoms
• VRRP reports master state on all members but no member receives packets intended for the VRRP
virtual IP
Cause
The VMware VSwitch drops frames to MAC addresses that are unknown from the network card properties of the
• VRRP gives the ability to define a virtual IP that can move between machines. By design, the virtual
IP is associated to a virtual MAC address - different from the real network card’s MAC address.
Using a virtual MAC address instead of a real MAC address makes the switchover quicker as no
update of ARP tables is needed. However, a Virtual MAC address is not supported by the VMware
VSwitch. Unlike physical switches, the VSwitch has no MAC learning mechanism capability. The
network section of the VM properties defines virtual network cards and one MAC address per card.
The VSwitch only knows those addresses to determine on what port to send a frame. Frames to any
unknown addresses, including virtual VRRP MAC addresses, are dropped.
• VRRP uses multicast packets to send VRRP protocol messages between its members. Multicast
packets use typical multicast MAC addresses that are also not known by the VSwitch.
Hints
One of the following solutions should be applied:
• Warning: this solution may impact the performance on VMware hypervisor. Enable promiscuous
mode on all VSwitches associated with the VLAN you want VRRP to run on. Basically, the VM will
receive all traffic within the VSwitch VLAN. Refer to https://kb.vmware.com/s/article/1002934 for
more information.
• Set up the VRRP instance to disable the usage of a virtual MAC address “vmac” and to use manual
unicast peers to exchange VRRP protocol data unit instead of using multicast. This solution is only
applicable to VMware and should not be applied on any other context without an explicit request
from support. In this mode, the virtual IP address is associated to the real NIC MAC address of
the active member. Upon member switchover, a gratuitous ARP is sent to advertise other machines
to update their ARP table with the new MAC. You must ensure and test that gratuitous ARP are
treated correctly by all machines. If not, some machines would lose connectivity until the ARP
cache timeout expires.
Symptoms
• LLDPDU are not received while the source correctly sends them and the link between both machine
works.
Cause
LLDPDU may be consumed by the LLDP engine integrated in the network card firmware:
• Some Intel network adapter (like Ethernet 700 series) has built-in hardware LLDP engine, which is
enabled by default. The LLDP Engine is responsible for receiving and consuming LLDP frames,
and also replies to the LLDP frames that it receives. The LLDP engine does not forward LLDP
frames to the network stack of the Operating System. The i40e driver enable this feature by default.
Hints
The firmware LLDP must be disabled in i40e ports:
• For fast path ports:
See also:
The FW-LLDP (Firmware Link Layer Discovery Protocol) chapter of the i40e Linux Base
Driver for Intel controller (https://downloadmirror.intel.com/24411/eng/README.txt).
Symptoms
• Packet processing performance is not as high as expected.
Hints
• Follow the advice provided in fast-path.sh config -i when using the advanced configuration.
• If running in a VM, check that the qemu instance handling your VM is pinned on specific cores. See
CPU Pinning for VMs section for details.
Symptoms:
• Packet processing is slower than expected
Hints:
• On Dell and SuperMicro servers, PCI read buffer may be misconfigured for ConnectX-3/ConnectX-3-
Pro NICs. Check the output of setpci -s <NIC_PCI_address> 68.w. For instance:
Warning: Beware with the following command, it is known to cause spontaneous reboot on some
systems.
If the value is below 0x5020 (here that’s the case), set it to 0x5020:
4.2.4 OpenStack
This section gathers issues that happen with Turbo Router started in an OpenStack environment.
VM start errors
Symptoms
• My VM can’t start, or is in a bad state (NOSTATE):
$ nova list
+--------------------------------------+------+--------+------------+---------
˓→----+------------------------------+
Hints
• Check the /var/log/nova/nova-compute.log file for ERROR. Considering the output, check the
following issues.
Symptoms My VM can’t start, or is in a bad state (NOSTATE). On the compute node hosting the VM. /var/log/
nova/nova-compute.log shows ERRORs and TRACEs like those:
Hints
• Add more memory to your compute node.
Symptoms Nova displays an error “Unable to find any usable hugetlbfs mount”.
On the controller node, /var/log/nova/nova-conductor.log shows ERRORs and TRACEs like this one:
error: Unable to find any usable hugetlbfs mount for 1048576 KiB
Hints
• Hugepages cannot be allocated for the VM. It may be due to the size of the hugepages. Try to allocate
more but smaller hugepages.
Symptoms
• VM packet processing is slower than expected.
Hints
• Consider disabling security groups as numerous packets processing require many iptables/ebtables look-
ups to direct packets properly when they’re enabled.
Refer to OpenStack documentation on how to do that considering your running version.
4.2.5 Management
Symptoms
• SNMP process crashes during SNMP walking when the router has loaded the full internet routing table.
Hints
• Blacklist route table OID so that SNMP process is not overloaded.
• Add the following SNMP configuration:
Use fp-cli stats [percore] [non-zero] to get the statistics recorded by the fast path:
4.3.2 fp-cpu-usage
Use this command to get the fast path usage per core, and the number of cycles to process one packet:
# fp-cpu-usage
Fast path CPU usage:
cpu: %busy cycles cycles/packet
2: 70% 227166479 990
3: 69% 222733174 991
...
average cycles/packets received from NIC: 991 (5389132282/5436242)
It is a good indicator regarding how busy the fast path cores are, processing packets.
Use the following command to turn most of the fast path off:
By doing this, no processing will be done by the fast path. As soon as the fast path receives a packet on a port,
without any processing, it will inject it in the linux stack.
If the test works with the fast path thus disabled, it usually means the fast path drops packets.
For each virtual CPU, QEMU uses one pthread for actually running the VM and pthreads for management. For best
performance, you need to make sure cores used to run fast path dataplane are only used for that.
To get the threads associated with each virtual CPU, use info cpus in QEMU monitor console:
To get all threads associated with your running VM (including management threads) and what CPU they are currently
pinned on, call:
You may also pin a VM after it has been started, using the PID (Process Identifier) of its threads. For instance, to
change the physical CPU on which to pin the virtual CPU #0, use:
When using libvirt, you may use <cputune> with vcpupin to pin virtual CPUs to physical ones. e.g.:
<vcpu cpuset='7-8,27-28'>4</vcpu>
<cputune>
<vcpupin vcpu="0" cpuset="7"/>
<vcpupin vcpu="1" cpuset="8"/>
<vcpupin vcpu="2" cpuset="27"/>
<vcpupin vcpu="3" cpuset="28"/>
</cputune>
We can look at htop results (after filtering results for this qemu instance) to confirm what threads are actually used:
PID USER VIRT RES SHR S CPU% MEM% TIME+ NLWP Command
26770 mazon 7032M 4067M 7092 S 200. 25.5 2h19:55 7 |- qemu-system-x86_64 -
˓→daemonize --enable-kvm -m 6G -cpu host -smp sockets=1,cores=4,threads=1 ...
27053 mazon 7032M 4067M 7092 S 0.0 25.5 0:01.13 7 | |- qemu-system-x86_64 -
˓→daemonize --enable-kvm -m 6G -cpu host (continues
-smp sockets=1,cores=4,threads=1 ... on next page)
You may even change CPU affinity by typing a when on a specific PID line in htop.
Similarly, you can get threads PID by looking in /proc/<pid>/task/, e.g.:
# ls /proc/26773/task
26770/ 26771/ 26773/ 26774/ 26775/ 26776/ 27053/
The fp-cli dpdk-port-stats command is used to display and set options related to network drivers (for those
that support it).
To display the statistics for a given port, use fp-cli dpdk-port-stats <port>:
rx_good_packets: 261064663
tx_good_packets: 256512062
rx_good_bytes: 15663879780
tx_good_bytes: 15390725600
rx_missed_errors: 0
rx_errors: 36554346
tx_errors: 0
rx_mbuf_allocation_errors: 0
rx_q0_packets: 32632951
rx_q0_bytes: 1957977060
rx_q0_errors: 0
...
tx_q0_packets: 128251039
tx_q0_bytes: 7695062334
...
rx_total_packets: 297619011
rx_total_bytes: 17857140760
(continues on next page)
The most important stats to look at are the {r,t}x_good_{packets,bytes} and errors.
They indicate globally how well the port is handling packets.
There is also per queue statistics that might be interesting in case of multiqueue. It’s better to have packets transmitted
on as many different queues as possible, but it depends on various factors, such as the IP addresses and UDP / TCP
ports.
The drop statistics provide useful information about why packets are dropped. For instance, the rx_missed_errors
counter represents the number of packets dropped because the CPU was not fast enough to dequeue them. A non-
zero value for rx_mbuf_allocation_errors shows that there is not enough mbuf structure configured in the fast
path.
fp-cli dpdk-port-offload can be used to check whether offload is enabled, using the following:
If you want to enable TSO (TCP Segmentation Offload) (which should provide you with better performance for
TCP, as the hardware will handle the segmentation), use:
Note: You can get various error messages when trying to change hardware parameters. For instance, Cannot
change tcp-segmentation-offload may appear if the driver does not support to dynamically change TSO
offload.
4.4.3 lspci
The lspci command is useful to display information about PCI buses. In most cases, we look for “Ethernet”
devices.
Use lspci to get basic information on all connected devices:
# lspci
00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02)
00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]
00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II]
00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
00:02.0 VGA compatible controller: Device 1234:1111 (rev 02)
00:03.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Controller␣
˓→(rev 03)
# lspci -k
00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02)
Subsystem: Red Hat, Inc Qemu virtual machine
00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]
Subsystem: Red Hat, Inc Qemu virtual machine
00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II]
Subsystem: Red Hat, Inc Qemu virtual machine
Kernel driver in use: ata_piix
00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
Subsystem: Red Hat, Inc Qemu virtual machine
00:02.0 VGA compatible controller: Device 1234:1111 (rev 02)
Subsystem: Red Hat, Inc Device 1100
00:03.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Controller␣
˓→(rev 03)
4.4.4 lstopo
lstopo provides a global view of the system’s topology. It details what machines contain what nodes, containing
sockets, containing cores, containing processor units.
The following command presents a graphical representation of a big machine’s topology:
4.4.5 meminfo
The file /proc/meminfo presents a memory status summary. You can also look at memory by node through /sys/
devices/system/node/node<node_id>/meminfo.
On a VM with 1GB of RAM (Random-Access Memory) running redhat-7, we have this:
# cat /proc/meminfo
MemTotal: 1016548 kB
MemFree: 107716 kB
MemAvailable: 735736 kB
Buffers: 83244 kB
Cached: 626528 kB
SwapCached: 0 kB
Active: 400416 kB
Inactive: 352892 kB
Active(anon): 49808 kB
Inactive(anon): 13304 kB
Active(file): 350608 kB
Inactive(file): 339588 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 43652 kB
Mapped: 9500 kB
Shmem: 19572 kB
Slab: 130972 kB
SReclaimable: 100896 kB
SUnreclaim: 30076 kB
KernelStack: 1888 kB
PageTables: 2692 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 507248 kB
Committed_AS: 214004 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 4412 kB
VmallocChunk: 34359730912 kB
HardwareCorrupted: 0 kB
AnonHugePages: 4096 kB
HugePages_Total: 1
HugePages_Free: 0
(continues on next page)
4.4.6 numastat
This tool shows per-NUMA-node memory statistics for processes and the operating system.
Without argument, it displays per-node NUMA hit and miss system statistics from the kernel memory allocator. A
high value in other_node means that there are cross-NUMA memory transfers, which impacts performance. This
information is dynamic and can be monitored with the watch command.
# numastat
node0 node1
numa_hit 589246433 556912817
numa_miss 0 0
numa_foreign 0 0
interleave_hit 11616 17088
local_node 589229023 556900289
other_node 17410 12528
When a PID or a pattern is passed, it shows per-node memory allocation information for the specified process (in-
cluding all its pthreads). The hugepages correspond to the DPDK memory, and the private area mainly corresponds
to the shared memories.
# numastat fp-rte
Per-node process memory usage (in MBs) for PID 2176 (fp-rte:8)
Node 0 Node 1 Total
--------------- --------------- ---------------
Huge 842.00 842.00 1684.00
Heap 0.41 0.00 0.41
Stack 0.03 0.00 0.03
Private 1004.35 24.27 1028.62
---------------- --------------- --------------- ---------------
Total 1846.79 866.27 2713.06
4.5.1 rsyslog
The rsyslogd daemon writes syslog messages in various places (considering its configuration in /etc/rsyslog.
conf). Messages for the “daemon” facility are usually stored in /var/log/daemon.log (this is the case for buil-
droot images). However all messages are usually stored in /var/log/syslog (all facilities included), too.
The fast path sends syslog messages that you can look at later to figure out what happened during startup (and
runtime). Here is an extract from /var/log/syslog:
˓→addr=0xaffced00
˓→addr=0xaffac580
If you don’t see anything in /var/log/syslog, make sure the rsyslogd daemon is running:
If rsyslogd is not running, refer to your distribution documentation on how to get it started.
Note: Refer to the appropriate manpage (e.g.: man rsyslog.conf) for configuration options.
4.5.2 journalctl
With SystemD, logging is handled by the systemd-journald daemon. It writes its log in a binary format, and one
usually uses journalctl to access it.
Use this command to see syslog messages from a given program (providing its path):
# journalctl /usr/bin/fpmd
Dec 10 15:56:44 dut-vm fpmd[11412]: bpf module registered
Dec 10 15:56:44 dut-vm fpmd[11412]: inaddr module registered
Dec 10 15:56:44 dut-vm fpmd[11412]: inroute module registered
...
You can combine it to follow logs from several programs at once. e.g.:
Note: Refer to the appropriate manpage (e.g.: man journalctl) for configuration options.
If you have an issue when starting the fast path, take a look at the /var/log/fast-path.log file for fast path
startup log messages.
For instance (on a normal startup):
# cat /var/log/fast-path.log
Starting Fast Path...
/usr/bin/fp-rte --huge-dir=/mnt/huge -n 4 -l 5-6,25-26 --socket-mem 438,0 -d librte_
˓→pmd_vhost.so -w 0000:05:00.0 -w 0000:05:00.1 -w 0000:05:00.2 -w 0000:05:00.3 -w␣
=pmd-vhost0,sockname=/tmp/pmd-vhost0,rxqmap=auto:rr/nb_ring:1,txqmap=auto:hash/nb_
˓→ring:1,loglevel=2 --vdev=pmd-vhost1,sockname=/tmp/pmd-vhost1,rxqmap=auto:rr/nb_
˓→ring:1,txqmap=auto:hash/nb_ring:1,loglevel=2
You can start fpmd with -v option to have more verbose output. To do that, either:
1. kill and restart (providing -v) the fpmd process, once the fast path has been started:
# killall fpmd
# fpmd -v
2. provide -v in FPM_OPTIONS when starting the fast path (you could set it in /etc/fpm.env too):
See also:
Linux - Fast Path Synchronization
When facing a synchronization issue, check first the line with fpm_connection in the log. It should display
connected to fpm socket when the connection is established between cmgrd and fpmd.
You can start cmgrd with -d option (use 0xffffffff for maximum debug level) to display more information
regarding received netlink messages, messages sent to fpmd, etc. To do that, either:
1. kill and restart (providing -d) the cmgrd process, once the Linux - Fast Path Synchronization has been started:
# killall cmgrd
# cmgrd -d 0xffffffff
2. provide -d in CMGR_OPTIONS when starting the Linux - Fast Path Synchronization (you could set it in /etc/
cmgr.env too):
See also:
Linux - Fast Path Synchronization
When you have an issue regarding VM spawning, take a look at /var/log/nova/nova-compute.log on the
compute node hosting the VM.
In particular, look for messages with error or trace in it. For instance:
˓→ - -] \
˓→'Interface', \
u'tap13d2cb29-d6', u'external-ids:iface-id=13d2cb29-d61c-46d9-
˓→afe9-98b6aa0a43ea', 'external-ids:iface-status=active', u'external-ids:attached-
˓→mac=fa:16:3e:6d:ac:ea', \
'external-ids:vm-uuid=1065e38c-e6c6-423f-8140-5d0c021d3af0'].␣
˓→Exception: Unexpected error while running command.
˓→] \
˓→d6', \
u'external-ids:iface-id=13d2cb29-d61c-46d9-afe9-98b6aa0a43ea', 'external-ids:iface-
˓→status=active', u'external-ids:attached-mac=fa:16:3e:6d:ac:ea', \
'external-ids:vm-uuid=1065e38c-e6c6-423f-8140-5d0c021d3af0']
2016-01-27 11:37:22.289 12945 ERROR nova.compute.manager [instance: 1065e38c-e6c6-423f-
˓→8140-5d0c021d3af0]
There are interesting files regarding running instances available on the compute nodes, in /var/lib/nova/
instances:
# tree /var/lib/nova/instances
/var/lib/nova/instances
|-- 54fff47b-fa5e-4401-8309-e2da66c01d66
| |-- console.log
| |-- disk
| |-- disk.info
| +-- libvirt.xml
|-- 7fb5ce27-cb7a-4a3b-94d8-afb84ddd3c5b
| |-- console.log
| |-- disk
| |-- disk.info
| +-- libvirt.xml
|-- _base
| +-- 775fa67e40ab15538f2f01969e50a38078c09e9b
|-- compute_nodes
+-- locks
|-- nova-775fa67e40ab15538f2f01969e50a38078c09e9b
+-- nova-storage-registry-lock
For instance, you can find the libvirt domain file used to boot the VM:
# head /var/lib/nova/instances/54fff47b-fa5e-4401-8309-e2da66c01d66/libvirt.xml
<domain type="kvm">
<uuid>54fff47b-fa5e-4401-8309-e2da66c01d66</uuid>
<name>instance-00000003</name>
<memory>524288</memory>
<memoryBacking>
<hugepages>
<page size="2048" nodeset="0" unit="KiB"/>
</hugepages>
</memoryBacking>
<numatune>
# tail /var/lib/nova/instances/54fff47b-fa5e-4401-8309-e2da66c01d66/console.log
ec2: #############################################################
-----BEGIN SSH HOST KEY KEYS-----
ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYT[...]Osfj0fFcxJvE2Roc= root@compute1-vm
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQ[...]JUYLnAaNV8oNz1AId root@compute1-vm
-----END SSH HOST KEY KEYS-----
(continues on next page)
Up 18.67 seconds
Note:
• For console logs, however, we recommend using nova console-log <ID> on the controller node, for a
similar result.
• You may also access your VM console itself by accessing horizon (which must be installed and started obvi-
ously).
From the administration panel, access Compute > Instances > [your instance] > Console:
If you want Nova to provide you with more information when running, you can configure the verbose and debug
options to True in /etc/nova/nova.conf:
• On Red Hat 7:
Similarly, if you want Neutron to provide you with more information, configure verbose and debug options in
/etc/neutron/neutron.conf:
Note: Do not keep verbose and debug options set on production environments, as it is very, very talkative. It
makes researching interesting information in the log difficult.
4.6.1 strace
strace displays system calls done by a given program. Use this command to get a first impression on what the
program is spending time on. For instance, you can see netlink messages handled by the cache manager:
epoll_wait(4,
^C
Process 5350 detached
<detached ...>