Vyos
Vyos
Release 1.2.0-beta
1 Installation 3
2 Command-Line Interface 5
4 Configuration Overview 11
5 Network Interfaces 15
5.1 Interface Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.2 Dummy Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.3 Ethernet Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.4 Wireless Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.5 Bridging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.6 Bonding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.7 Tunnel Interfaces (vti) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.8 VLAN Sub-Interfaces (802.1Q) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.9 QinQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.10 VXLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.11 WireGuard VPN Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6 Routing 31
6.1 Static . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.2 RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.3 OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.4 BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.5 ARP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
7 Policy Routing 37
8 Firewall 39
8.1 Zone-based Firewall Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
8.2 Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
8.3 Rule-Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
8.4 Applying a Rule-Set to an Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
8.5 Applying a Rule-Set to a Zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
i
8.6 Example Partial Config . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
9 NAT 43
9.1 Source NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
9.2 Destination NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
9.3 1-to-1 NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
9.4 1-to-1 NAT example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
9.5 NPTv6 (RFC6296) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
9.6 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
9.7 VyOS Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
10 VPN 49
10.1 OpenVPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
10.2 L2TP over IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
10.3 Site-to-Site IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
10.4 DMVPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
10.5 PPTP-Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
10.6 WireGuard VPN Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
12 Services 91
12.1 Conntrack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
12.2 DHCP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
12.3 DHCPv6 server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
12.4 DHCP Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
12.5 DNS Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
12.6 Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
12.7 LLDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
12.8 mDNS Repeater . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
12.9 PPPoE server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
12.10 UDP broadcast relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
12.11 SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
12.12 SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
12.13 TFTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
12.14 Webproxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
13 System 121
13.1 Event Handler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
13.2 Flow Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
13.3 Host Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
13.4 System Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
13.5 Syslog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
13.6 Task scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
13.7 Config Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
ii
14.5 Preemption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
14.6 Unicast VRRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
14.7 Scripting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
15 Clustering 133
22 Development 169
iii
iv
VyOS Documentation, Release 1.2.0-beta
Contents: 1
VyOS Documentation, Release 1.2.0-beta
2 Contents:
CHAPTER 1
Installation
vyos@vyos:~$ uname -a
Linux vyos 4.18.11-amd64-vyos #23 SMP Mon Oct 1 17:29:22 CEST 2018 x86_64 GNU/Linux
Unlike general purpose Linux distributions, VyOS uses “image installation” that mimics the user experience of tradi-
tional hardware routers and allows you to keep multiple VyOS versions on the same machine and switch to a previous
version if something breaks after upgrade. Every version is contained in its own squashfs image that is mounted in a
union filesystem together with a directory for mutable data (configs etc.).
Note: Older versions used to support non-image installation (install system command). It’s been deprecated since
the time image installation was introduced (long before the fork), and does not provide any version management
capabilities. You should not use it for new installations even if it’s still available in new versions. You should not
worry about older systems installed that way though, they can be upgraded with add system image. In addition
the install system command has been removed in VyOS 1.2 (Crux).
3
VyOS Documentation, Release 1.2.0-beta
Which drive should GRUB modify the boot partition on? [sda]:
Setting up grub: OK
Done!
vyos@vyos:~$
After the installation is complete, remove the Live CD and reboot the system:
vyos@vyos:~$ reboot
Proceed with reboot? (Yes/No) [No] Yes
4 Chapter 1. Installation
CHAPTER 2
Command-Line Interface
vyos@vyos:~$ s[tab]
set show
vyos@vyos:~$
5
VyOS Documentation, Release 1.2.0-beta
When the output of a command results in more lines than can be displayed on the terminal screen the output is
paginated as indicated by a : prompt.
When viewing in page mode the following commands are available:
• [q] key can be used to cancel output
• [space] will scroll down one page
• [b] will scroll back one page
• [return] will scroll down one line
• [up-arrow] and [down-arrow] will scroll up or down one line at a time respectively
• [left-arrow] and [right-arrow] can be used to scroll left or right in the event that the output has lines
which exceed the terminal size.
To enter configuration mode use the configure command:
vyos@vyos:~$ configure
[edit]
vyos@vyos:~#
vyos@vyos:~# exit
exit
vyos@vyos:~$
See the configuration section of this document for more information on configuration mode.
Below is a very basic configuration example that will provide a NAT gateway for a device with two interfaces.
Enter configuration mode:
vyos@vyos$ configure
vyos@vyos#
7
VyOS Documentation, Release 1.2.0-beta
vyos@vyos# commit
vyos@vyos# save
Saving configuration to '/config/config.boot'...
Done
vyos@vyos# exit
vyos@vyos$
The traffic policy subsystem provides an interface to Linux traffic control (tc).
One common use of traffic policy is to limit bandwidth for an interface. In the example below we limit bandwidth for
our LAN connection to 200 Mbit download and out WAN connection to 50 Mbit upload:
traffic-policy {
shaper WAN-OUT {
bandwidth 50Mbit
default {
bandwidth 50%
ceiling 100%
queue-type fair-queue
}
}
shaper LAN-OUT {
bandwidth 200Mbit
default {
bandwidth 50%
ceiling 100%
queue-type fair-queue
}
}
}
Once defined, a traffic policy can be applied to each interface using the interface-level traffic-policy directive:
Note: A traffic policy can also be defined to match specific traffic flows using class statements.
Configuration Overview
VyOS makes use of a unified configuration file for all system configuration: config.boot. This allows for easy template
creation, backup, and replication of system configuration.
The current configuration can be viewed using the show configuration command.
vyos@vyos:~$ show configuration
interfaces {
ethernet eth0 {
address dhcp
hw-id 00:0c:29:44:3b:0f
}
loopback lo {
}
}
service {
ssh {
port 22
}
}
system {
config-management {
commit-revisions 20
}
console {
device ttyS0 {
speed 9600
}
}
login {
user vyos {
authentication {
encrypted-password ****************
}
level admin
}
(continues on next page)
11
VyOS Documentation, Release 1.2.0-beta
Because configuration changes are made using set and delete commands, the commands to generate the active config-
uration can also be displayed using the show configuration commands command.
Configuration changes made do not take effect until committed using the commit command in configuration mode.
vyos@vyos# commit
[edit]
vyos@vyos# exit
Warning: configuration changes have not been saved.
vyos@vyos:~$
In order to preserve configuration changes upon reboot, the configuration must also be saved once applied. This is
done using the save command in configuration mode.
vyos@vyos# save
Saving configuration to '/config/config.boot'...
Done
[edit]
vyos@vyos#
The show command within configuration mode will show the current configuration indicating line changes with a +
for additions and a - for deletions.
vyos@vyos:~$ configure
[edit]
vyos@vyos# show interfaces
ethernet eth0 {
address dhcp
hw-id 00:0c:29:44:3b:0f
}
loopback lo {
}
[edit]
vyos@vyos# set interfaces ethernet eth0 description 'OUTSIDE'
[edit]
vyos@vyos# show interfaces
ethernet eth0 {
address dhcp
+ description OUTSIDE
hw-id 00:0c:29:44:3b:0f
}
loopback lo {
}
[edit]
vyos@vyos#
Configuration mode can not be exited while uncommitted changes exist. To exit configuration mode without applying
changes, the exit discard command can be used.
vyos@vyos# exit
Cannot exit: configuration modified.
Use 'exit discard' to discard the changes and exit.
[edit]
vyos@vyos# exit discard
exit
vyos@vyos:~$
VyOS also maintains backups of previous configurations. To compare configuration revisions in configuration mode,
use the compare command:
vyos@vyos# compare [tab]
Possible completions:
<Enter> Compare working & active configurations
saved Compare working & saved configurations
<N> Compare working with revision N
<N> <M> Compare revision N with M
Revisions:
0 2013-12-17 20:01:37 root by boot-config-loader
1 2013-12-13 15:59:31 root by boot-config-loader
2 2013-12-12 21:56:22 vyos by cli
3 2013-12-12 21:55:11 vyos by cli
4 2013-12-12 21:27:54 vyos by cli
5 2013-12-12 21:23:29 vyos by cli
6 2013-12-12 21:13:59 root by boot-config-loader
7 2013-12-12 16:25:19 vyos by cli
8 2013-12-12 15:44:36 vyos by cli
9 2013-12-12 15:42:07 root by boot-config-loader
10 2013-12-12 15:42:06 root by init
(continues on next page)
13
VyOS Documentation, Release 1.2.0-beta
[edit]
vyos@vyos#
You can rollback configuration using the rollback command, however this command will currently trigger a system
reboot.
vyos@vyos# compare 1
[edit system]
>host-name vyos-1
[edit]
vyos@vyos# rollback 1
Proceed with reboot? [confirm][y]
Broadcast message from root@vyos-1 (pts/0) (Tue Dec 17 21:07:45 2013):
The system is going down for reboot NOW!
[edit]
vyos@vyos#
VyOS also supports saving and loading configuration remotely using SCP, FTP, or TFTP.
Network Interfaces
Configured interfaces on a VyOS system can be displayed using the show interfaces command.
A specific interface can be shown using the show interfaces <type> <name> command.
Different network interfaces provide type-specific configuration. Ethernet interfaces, for example, allow the configu-
ration of speed and duplex.
Many services, such as network routing, firewall, and traffic policy also maintain interface-specific configuration.
These will be covered in their respective sections.
15
VyOS Documentation, Release 1.2.0-beta
Each interface can be configured with a description and address. Interface addresses might be:
• Static IPv4 address 172.16.51.129/24
• Static IPv6 address 2001:db8:1::ffff/64
• DHCP IPv4 address dhcp
• DHCP IPv6 address dhcpv6
An interface description is assigned using the following command:
5.1.1 IPv4
Static Address
This method is supported on all interfaces, apart from OpenVPN that uses different syntax and wireless modems that
are always autoconfigured through PPP.
The command is set interfaces $type $name address $address. Examples:
DHCP
This method is supported on all physical interfaces, and those that are directly connected to a physical interface
(ethernet, VLAN, bridge, bond, pseudo-ethernet, wireless).
The command is set interfaces $type $name address dhcp. Examples:
5.1.2 IPv6
Static Address
This method is supported on all interfaces, apart from OpenVPN that uses different syntax and wireless modems that
are always autoconfigured through PPP. Static IPv6 addresses are supported on all interfaces except Tunnel Interfaces
(vti).
The command is set interfaces $type $name address $address. Examples:
DHCP
This method is supported on all physical interfaces, and those that are directly connected to a physical interface
(ethernet, VLAN, bridge, bond, pseudo-ethernet, wireless).
The command is set interfaces $type $name address dhcpv6. Examples:
Autoconfiguration (SLAAC)
SLAAC is specified in RFC4862. This method is supported on all physical interfaces, and those that are directly
connected to a physical interface (ethernet, VLAN, bridge, bond, pseudo-ethernet, wireless).
The command is set interfaces $type $name ipv6 address autoconf. Examples:
Note: This method automatically disables IPv6 traffic forwarding on the interface in question.
EUI-64
EUI-64 (64-Bit Extended Unique Identifier) as specified in RFC4291. IPv6 addresses in /64 networks can be automat-
ically generated from the prefix and MAC address, if you specify the prefix.
The command is set interfaces $type $name ipv6 address eui64 $prefix. Examples:
Dummy interfaces — much like the loopback, except you can have as many as you want. Dummy interfaces can be
used as interfaces that always stay up (in the same fashion to loopbacks in IOS), or for testing purposes.
Configuration commands:
interfaces
dummy <dum[0-999]>
+ address IP address
description Description
disable Disable interface
> ip IPv4 routing parameters
> ipv6 IPv6 routing parameters
redirect Incoming packet redirection destination
> traffic-policy Traffic-policy for interface
Ethernet interfaces allow for the configuration of speed, duplex, and hw-id (MAC address). Below is an example
configuration:
set interfaces ethernet eth1 address '192.168.0.1/24'
set interfaces ethernet eth1 address '2001:db8:1::ffff/64'
set interfaces ethernet eth1 description 'INSIDE'
set interfaces ethernet eth1 duplex 'auto'
set interfaces ethernet eth1 speed 'auto'
Resulting in:
ethernet eth1 {
address 192.168.0.1/24
address 2001:db8:1::ffff/64
description INSIDE
duplex auto
hw-id 00:0c:29:44:3b:19
smp_affinity auto
speed auto
}
In addition, Ethernet interfaces provide the extended operational commands show interfaces ethernet <name> physical
and show interfaces ethernet <name> statistics. Statistics available are driver dependent.
vyos@vyos:~$ show interfaces ethernet eth0 physical
Settings for eth0:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
MDI-X: Unknown
Supports Wake-on: d
Wake-on: d
Current message level: 0x00000007 (7)
Link detected: yes
driver: e1000
version: 7.3.21-k8-NAPI
firmware-version:
bus-info: 0000:02:01.0
Wireless, for example WiFi 802.11 b/g/n, interfaces allow for connection to WiFi networks or act as an access-point.
If your device is configurable it will appear as wlan in show interfaces.
To be able to use the wireless interfaces you will first need to set a regulatory domain with the country code of your
locaion.
set system wifi-regulatory-domain SE
Resulting in
interfaces {
[...]
wireless wlan0 {
address 192.168.99.1/24
channel 1
mode g
security {
wpa {
cipher CCMP
mode wpa2
passphrase "<your passphrase>"
}
}
ssid "<your ssid>"
type access-point
}
}
system {
[...]
wifi-regulatory-domain SE
}
To get it to work as a access point with this configuration you will need to set up a DHCP server to work with that
network.
5.5 Bridging
Interfaces in VyOS can be bridged together to provide software switching of Layer-2 traffic.
A bridge is created when a bridge interface is defined. In the example below we will be creating a bridge for VLAN
100 and assigning a VIF to the bridge.
set interfaces bridge 'br100'
set interfaces ethernet eth1 vif 100 bridge-group bridge br100
Interfaces assigned to a bridge-group do not have address configuration. An IP address can be assigned to the bridge
interface itself, however, like any normal interface.
set interfaces bridge br100 address '192.168.100.1/24'
set interfaces bridge br100 address '2001:db8:100::1/64'
Example Result:
bridge br100 {
address 192.168.100.1/24
address 2001:db8:100::1/64
}
[...]
ethernet eth1 {
[...]
vif 100 {
bridge-group {
bridge br100
}
}
}
In addition to normal IP interface configuration, bridge interfaces support Spanning-Tree Protocol. STP is disabled by
default.
Note: Please use caution when introducing spanning-tree protocol on a network as it may result in topology changes.
To enable spanning-tree use the set interfaces bridge <name> stp true command:
set interfaces bridge br100 stp true
STP priority, forwarding-delay, hello-time, and max-age can be configured for the bridge-group. The MAC aging
time can also be configured using the aging directive.
For member interfaces, the bridge-group priority and cost can be configured.
The show bridge operational command can be used to display configured bridges:
vyos@vyos:~$ show bridge
bridge name bridge id STP enabled interfaces
br100 0000.000c29443b19 yes eth1.100
If spanning-tree is enabled, the show bridge <name> spanning-tree command can be used to show STP configuration:
vyos@vyos:~$ show bridge br100 spanning-tree
br100
bridge id 0000.000c29443b19
designated root 0000.000c29443b19
root port 0 path cost 0
max age 20.00 bridge max age 20.00
hello time 2.00 bridge hello time 2.00
(continues on next page)
eth1.100 (1)
port id 8001 state forwarding
designated root 0000.000c29443b19 path cost 4
designated bridge 0000.000c29443b19 message age timer 0.00
designated port 8001 forward delay timer 0.00
designated cost 0 hold timer 0.00
flags
The MAC address-table for a bridge can be displayed using the show bridge <name> macs command:
5.6 Bonding
You can combine (aggregate) 2 or more physical interfaces into a single logical one. It’s called bonding, or LAG, or
ether-channel, or port-channel.
Create interface bondX, where X is just a number:
For example:
You may want to set IEEE 802.3ad Dynamic link aggregation (802.3ad) AKA LACP (don’t forget to setup it on the
other end of these links):
5.6. Bonding 21
VyOS Documentation, Release 1.2.0-beta
After a commit you may treat bond0 as almost a physical interface (you can’t change its‘ duplex, for example) and
assign IPs or VIFs on it.
You may check the result:
Results in:
802.1Q VLAN interfaces are represented as virtual sub-interfaces in VyOS. The term used for this is vif. Configuration
of a tagged sub-interface is accomplished using the configuration command set interfaces ethernet <name> vif <vlan-
id>.
Resulting in:
ethernet eth1 {
address 192.168.100.1/24
address 2001:db8:100::1/64
description INSIDE
duplex auto
hw-id 00:0c:29:44:3b:19
smp_affinity auto
speed auto
vif 100 {
address 192.168.100.1/24
description "VLAN 100"
}
}
5.9 QinQ
QinQ (802.1ad) — allows multiple VLAN tags to be inserted into a single frame.
QinQ can be used to tunnel vlans in a vlan.
vif-s and vif-c stand for the ethertype tags that get set:
The inner tag is the tag which is closest to the payload portion of the frame; it is officially called C-TAG (Customer
tag, with ethertype 0x8100). The outer tag is the one closer/closest to the Ethernet header; its name is S-TAG (Service
tag, ethertype 0x88a8).
Configuration commands:
interfaces
ethernet <eth[0-999]>
address <ipv4>
address <ipv6>
description <txt>
disable
ip
<usual IP options>
ipv6
<usual IPv6 options>
vif-s <[0-4096]>
address <ipv4>
address <ipv6>
description <txt>
disable
(continues on next page)
5.9. QinQ 23
VyOS Documentation, Release 1.2.0-beta
Example:
5.10 VXLAN
Example Topology:
PC4 - Leaf2 - Spine1 - Leaf3 - PC5
PC4 has IP 10.0.0.4/24 and PC5 has IP 10.0.0.5/24, so they believe they are in the same broadcast domain.
Let’s assume PC4 on Leaf2 wants to ping PC5 on Leaf3. Instead of setting Leaf3 as our remote end manually, Leaf2
encapsulates the packet into a UDP-packet and sends it to its designated multicast-address via Spine1. When Spine1
receives this packet it forwards it to all other Leafs who has joined the same multicast-group, in this case Leaf3. When
Leaf3 receives the packet it forwards it, while at the same time learning that PC4 is reachable behind Leaf2, because
the encapsulated packet had Leaf2’s IP-address set as source IP.
PC5 receives the ping echo, responds with an echo reply that Leaf3 receives and this time forwards to Leaf2’s unicast
address directly because it learned the location of PC4 above. When Leaf2 receives the echo reply from PC5 it sees
that it came from Leaf3 and so remembers that PC5 is reachable via Leaf3.
Thanks to this discovery, any subsequent traffic between PC4 and PC5 will not be using the multicast-address between
the Leafs as they both know behind which Leaf the PCs are connected. This saves traffic as less multicast packets sent
reduces the load on the network, which improves scalability when more Leafs are added.
For optimal scalability Multicast shouldn’t be used at all, but instead use BGP to signal all connected devices between
leafs. Unfortunately, VyOS does not yet support this.
1 https://datatracker.ietf.org/doc/rfc7348/
interfaces
vxlan <vxlan[0-16777215]>
address # IP address of the VXLAN interface
bridge-group # Configure a L2 bridge-group
description # Description
group <ipv4> # IPv4 Multicast group address (required)
ip # IPv4 routing options
ipv6 # IPv6 routing options
link <dev> # IP interface for underlay of this vxlan overlay (optional)
mtu # MTU
policy # Policy routing options
remote # Remote address of the VXLAN tunnel, used for PTP instead of
˓→multicast
Spine1:
fa0/2 towards Leaf2, IP-address: 10.1.2.1/24
fa0/3 towards Leaf3, IP-address: 10.1.3.1/24
Leaf2:
Eth0 towards Spine1, IP-address: 10.1.2.2/24
Eth1 towards a vlan-aware switch
Leaf3:
Eth0 towards Spine1, IP-address 10.1.3.3/24
Eth1 towards a vlan-aware switch
Spine1 Configuration:
conf t
ip multicast-routing
!
interface fastethernet0/2
ip address 10.1.2.1 255.255.255.0
ip pim sparse-dense-mode
!
interface fastethernet0/3
ip address 10.1.3.1 255.255.255.0
ip pim sparse-dense-mode
!
router ospf 1
network 10.0.0.0 0.255.255.255 area 0
5.10. VXLAN 25
VyOS Documentation, Release 1.2.0-beta
Multicast-routing is required for the leafs to forward traffic between each other in a more scalable way. This also
requires PIM to be enabled towards the Leafs so that the Spine can learn what multicast groups each Leaf expect
traffic from.
Leaf2 configuration:
Leaf3 configuration:
As you can see, Leaf2 and Leaf3 configuration is almost identical. There are lots of commands above, I’ll try to into
more detail below, command descriptions are placed under the command boxes:
This commands creates a bridge that is used to bind traffic on eth1 vlan 241 with the vxlan241-interface. The IP-
address is not required. It may however be used as a default gateway for each Leaf which allows devices on the vlan to
reach other subnets. This requires that the subnets are redistributed by OSPF so that the Spine will learn how to reach
it. To do this you need to change the OSPF network from ‘10.0.0.0/8’ to ‘0.0.0.0/0’ to allow 172.16/12-networks to be
advertised.
Binds eth1 vif 241 and vxlan241 to each other by putting them in the same bridge-group. Internal VyOS requirement.
The multicast-group used by all Leafs for this vlan extension. Has to be the same on all Leafs that has this interface.
Sets the interface to listen for multicast packets on. Could be a loopback, not yet tested.
Sets the unique id for this vxlan-interface. Not sure how it correlates with multicast-address.
The destination port used for creating a VXLAN interface in Linux defaults to its pre-standard value of 8472 to
preserve backwards compatibility. A configuration directive to support a user-specified destination port to override
that behavior is available using the above command.
Example for bridging normal L2 segment and vxlan overlay network, and using a vxlan interface as routing interface.
interfaces {
bridge br0 {
}
ethernet eth0 {
address dhcp
}
loopback lo {
}
vxlan vxlan0 {
bridge-group {
bridge br0
}
group 239.0.0.1
vni 0
}
vxlan vxlan1 {
address 192.168.0.1/24
link eth0
group 239.0.0.1
vni 1
}
}
Here is a working configuration that creates a VXLAN between two routers. Each router has a VLAN interface (26)
facing the client devices and a VLAN interface (30) that connects it to the other routers. With this configuration,
traffic can flow between both routers’ VLAN 26, but can’t escape since there is no L3 gateway. You can add an IP to
a bridge-group to create a gateway.
5.10. VXLAN 27
VyOS Documentation, Release 1.2.0-beta
interfaces {
bridge br0 {
}
ethernet eth0 {
duplex auto
smp-affinity auto
speed auto
vif 26 {
bridge-group {
bridge br0
}
}
vif 30 {
address 10.7.50.6/24
}
}
loopback lo {
}
vxlan vxlan0 {
bridge-group {
bridge br0
}
group 239.0.0.241
vni 241
}
}
WireGuard is an extremely simple yet fast and modern VPN that utilizes state-of-the-art cryptography. See https:
//www.wireguard.com for more information.
5.11.1 Configuration
Generate the keypair, which creates a public and private part and stores it within VyOS.
wg01:~$ configure
wg01# run generate wireguard keypair
The public key is being shared with your peer(s), your peer will encrypt all traffic to your system using this public key.
The next step is to configure your local side as well as the policy based trusted destination addresses. If you only
initiate a connection, the listen port and endpoint is optional, if you however act as a server and endpoints initiate the
connections to your system, you need to define a port your clients can connect to, otherwise it’s randomly chosen and
may make it difficult with firewall rules, since the port may be a different one when you reboot your system.
You will also need the public key of your peer as well as the network(s) you want to tunnel (allowed-ips) to configure
a wireguard tunnel. The public key below is always the public key from your peer, not your local one.
local side
The last step is to define an interface route for 10.2.0.0/24 to get through the wireguard interface wg01. Multiple IPs
or networks can be defined and routed, the last check is allowed-ips which either prevents or allows the traffic.
remote side
Assure that your firewall rules allow the traffic, in which case you have a working VPN using wireguard.
An additional layer of symmetric-key crypto can be used on top of the asymmetric crypto, which is optional.
Copy the key, it is not stored on the local file system. Make sure you distribute that key in a safe manner, it’s a
symmatric key, so only you and your peer should have knowledge if its content.
operational commands
interface: wg01
public key: xHvgSJC8RTClfvjc0oX6OALxU6GGLapjthjw7x82CSw=
private key: (hidden)
listening port: 12345
Routing
VyOS is a “router first” network operating system. It supports static routing, policy routing, and dynamic routing
using standard protocols (RIP, OSPF, and BGP).
6.1 Static
Another common use of static routes is to blackhole (drop) traffic. In the example below, RFC 1918 private IP networks
are set as blackhole routes. This does not prevent networks within these segments from being used, since the most
specific route is always used. It does, however, prevent traffic to unknown private networks from leaving the router.
Commonly refereed to as leaking.
Note: Routes with a distance of 255 are effectively disabled and not installed into the kernel.
6.2 RIP
31
VyOS Documentation, Release 1.2.0-beta
Node 2:
6.3 OSPF
6.3.1 IPv4
A typical configuration using 2 nodes, redistribute loopback address and the node 1 sending the default route:
Node 1:
Node 2:
6.3.2 IPv6
32 Chapter 6. Routing
VyOS Documentation, Release 1.2.0-beta
Node 2:
6.4 BGP
6.4.1 IPv4
Node 2:
Don’t forget, the CIDR declared in the network statement MUST exist in your routing table (dynamic or static),
the best way to make sure that is true is creating a static route:
Node 1:
Node 2:
6.4.2 IPv6
Node 2:
6.4. BGP 33
VyOS Documentation, Release 1.2.0-beta
Don’t forget, the CIDR declared in the network statement MUST exist in your routing table (dynamic or static),
the best way to make sure that is true is creating a static route:
Node 1:
Node 2:
Node2:
34 Chapter 6. Routing
VyOS Documentation, Release 1.2.0-beta
We could expand on this and also deny link local and multicast in the rule 20 action deny.
6.5 ARP
To manipulate or display ARP table entries, the following commands are implemented.
6.5. ARP 35
VyOS Documentation, Release 1.2.0-beta
36 Chapter 6. Routing
CHAPTER 7
Policy Routing
VyOS supports Policy Routing, allowing traffic to be assigned to a different routing table. Traffic can be matched
using standard 5-tuple matching (source address, destination address, protocol, source port, destination port).
The following example will show how VyOS can be used to redirect web traffic to an external transparent proxy:
This creates a route policy called FILTER-WEB with one rule to set the routing table for matching traffic (TCP port
80) to table ID 100 instead of the default routing table.
To create routing table 100 and add a new default gateway to be used by traffic matching our route policy:
This can be confirmed using the show ip route table 100 operational command.
Finally, to apply the policy route to ingress traffic on our LAN interface, we use:
The route policy functionality in VyOS can also be used to rewrite TCP MSS using the set policy route <name> rule
<rule> set tcp-mss <value> directive, modify DSCP value using set dscp <value>, or mark the traffic with an internal
ID using set mark <value> for further processing (e.g. QOS) on a per-rule basis for matching traffic.
In addition to 5-tuple matching, additional options such as time-based rules, are available. See the built-in help for a
complete list of options.
37
VyOS Documentation, Release 1.2.0-beta
Firewall
As an alternative to applying policy to an interface directly, a zone-based firewall can be created to simplify configu-
ration when multiple interfaces belong to the same security zone. Instead of applying to rulesets to interfaces they are
applied to source zone-destination zone pairs.
An introduction to zone-based firewalls can be found [[A primer to Zone Based Firewall|here]]. For an example see
[[Zone-policy_example|Zone-policy example]].
8.2 Groups
Firewall groups represent collections of IP addresses, networks, or ports. Once created, a group can be referenced by
firewall rules as either a source or destination. Members can be added or removed from a group without changes to or
the need to reload individual firewall rules.
39
VyOS Documentation, Release 1.2.0-beta
While network groups accept IP networks in CIDR notation, specific IP addresses can be added as a 32-bit prefix. If
you foresee the need to add a mix of addresses and networks, the network group is recommended.
Here is an example of a network group for the IP networks that make up the internal network:
A port group represents only port numbers, not the protocol. Port groups can be referenced for either TCP or UDP.
It is recommended that TCP and UDP groups are created separately to avoid accidentally filtering unnecessary ports.
Ranges of ports can be specified by using -.
Here is an example of a port group a server:
8.3 Rule-Sets
A rule-set is a named collection of firewall rules that can be applied to an interface or zone. Each rule is numbered,
has an action to apply if the rule is matched, and the ability to specify the criteria to match.
Example of a rule-set to filter traffic to the internal network:
Note: Only one rule-set can be applied to each interface for in, out, or local traffic for each protocol (IPv4 and IPv6).
A named rule-set can also be applied to a zone relationship (note, zones must first be created):
40 Chapter 8. Firewall
VyOS Documentation, Release 1.2.0-beta
firewall {
all-ping enable
broadcast-ping disable
config-trap disable
group {
network-group BAD-NETWORKS {
network 1.2.3.0/24
network 1.2.4.0/24
}
network-group GOOD-NETWORKS {
network 4.5.6.0/24
network 4.5.7.0/24
}
port-group BAD-PORTS {
port 65535
}
}
name FROM-INTERNET {
default-action accept
description "From the Internet"
rule 10 {
action accept
description "Authorized Networks"
protocol all
source {
group {
network-group GOOD-NETWORKS
}
}
}
rule 11 {
action drop
description "Bad Networks"
protocol all
source {
group {
network-group BAD-NETWORKS
}
}
}
rule 30 {
action drop
description "BAD PORTS"
destination {
group {
port-group BAD-PORTS
}
}
log enable
protocol all
}
}
}
interfaces {
ethernet eth1 {
(continues on next page)
42 Chapter 8. Firewall
CHAPTER 9
NAT
Source NAT is typically referred to simply as NAT. To be more correct, what most people refer to as NAT is actually
the process of Port Address Translation (PAT), or NAT Overload. The process of having many internal host systems
communicate to the Internet using a single or subset of IP addresses.
To setup SNAT, we need to know: * The internal IP addresses we want to translate * The outgoing interface to perform
the translation on * The external IP address to translate to
In the example used for the Quick Start configuration above, we demonstrate the following configuration:
set nat source rule 100 outbound-interface ‘eth0’ set nat source rule 100 source address ‘192.168.0.0/24’
set nat source rule 100 translation address ‘masquerade’
Which generates the following configuration:
rule 100 {
outbound-interface eth0
source {
address 192.168.0.0/24
}
translation {
address masquerade
}
}
In this example, we use masquerade as the translation address instead of an IP address. The masquerade target is
effectively an alias to say “use whatever IP address is on the outgoing interface”, rather than a statically configured IP
address. This is useful if you use DHCP for your outgoing interface and do not know what the external address will
be.
When using NAT for a large number of host systems it recommended that a minimum of 1 IP address is used to
NAT every 256 host systems. This is due to the limit of 65,000 port numbers available for unique translations and a
reserving an average of 200-300 sessions per host system.
43
VyOS Documentation, Release 1.2.0-beta
Example: For an ~8,000 host network a source NAT pool of 32 IP addresses is recommended.
A pool of addresses can be defined by using a - in the set nat source rule [n] translation address statement.
set nat source rule 100 translation address '203.0.113.32-203.0.113.63'
Linux netfilter will not NAT traffic marked as INVALID. This often confuses people into thinking that Linux (or
specifically VyOS) has a broken NAT implementation because non-NATed traffic is seen leaving an external interface.
This is actually working as intended, and a packet capture of the “leaky” traffic should reveal that the traffic is either
an additional TCP “RST”, “FIN,ACK”, or “RST,ACK” sent by client systems after Linux netfilter considers the
connection closed. The most common is the additional TCP RST some host implementations send after terminating a
connection (which is implementation- specific).
In other words, connection tracking has already observed the connection be closed and has transition the flow to
INVALID to prevent attacks from attempting to reuse the connection.
You can avoid the “leaky” behavior by using a firewall policy that drops “invalid” state packets.
Having control over the matching of INVALID state traffic, e.g. the ability to selectively log, is an important trou-
bleshooting tool for observing broken protocol behavior. For this reason, VyOS does not globally drop invalid state
traffic, instead allowing the operator to make the determination on how the traffic is handled.
A typical problem with using NAT and hosting public servers is the ability for internal systems to reach an internal
server using it’s external IP address. The solution to this is usually the use of split-DNS to correctly point host systems
to the internal address when requests are made internally. Because many smaller networks lack DNS infrastructure,
a work-around is commonly deployed to facilitate the traffic by NATing the request from internal hosts to the source
address of the internal interface on the firewall. This technique is commonly reffered to as NAT Reflection, or Hairpin
NAT.
In this example, we will be using the example Quick Start configuration above as a starting point.
To setup a NAT reflection rule, we need to create a rule to NAT connections from the internal network to the same
internal network to use the source address of the internal interface.
set nat source rule 110 description 'NAT Reflection: INSIDE'
set nat source rule 110 destination address '192.168.0.0/24'
set nat source rule 110 outbound-interface 'eth1'
set nat source rule 110 source address '192.168.0.0/24'
set nat source rule 110 translation address 'masquerade'
44 Chapter 9. NAT
VyOS Documentation, Release 1.2.0-beta
DNAT is typically referred to as a Port Forward. When using VyOS as a NAT router and firewall, a common
configuration task is to redirect incoming traffic to a system behind the firewall.
In this example, we will be using the example Quick Start configuration above as a starting point.
To setup a destination NAT rule we need to gather: * The interface traffic will be coming in on * The protocol and port
we wish to forward * The IP address of the internal system we wish to forward traffic to
In our example, we will be forwarding web server traffic to an internal web server on 192.168.0.100. HTTP traffic
makes use of the TCP protocol on port 80. For other common port numbers, see: http://en.wikipedia.org/wiki/List_
of_TCP_and_UDP_port_numbers
Our configuration commands would be:
nat {
destination {
rule 10 {
description "Port Forward: HTTP to 192.168.0.100"
destination {
port 80
}
inbound-interface eth0
protocol tcp
translation {
address 192.168.0.100
}
}
}
}
Note: If forwarding traffic to a different port than it is arriving on, you may also configure the translation port using
set nat destination rule [n] translation port.
This establishes our Port Forward rule, but if we created a firewall policy it will likely block the traffic.
It is important to note that when creating firewall rules that the DNAT translation occurs before traffic traverses the
firewall. In other words, the destination address has already been translated to 192.168.0.100.
So in our firewall policy, we want to allow traffic coming in on the outside interface, destined for TCP port 80 and the
IP address of 192.168.0.100.
rule 20 {
action accept
destination {
address 192.168.0.100
port 80
}
protocol tcp
state {
new enable
}
}
Note: If you have configured the INSIDE-OUT policy, you will need to add additional rules to permit inbound NAT
traffic.
Another term often used for DNAT is 1-to-1 NAT. For a 1-to-1 NAT configuration, both DNAT and SNAT are used to
NAT all traffic from an external IP address to an internal IP address and vice-versa.
Typically, a 1-to-1 NAT rule omits the destination port (all ports) and replaces the protocol with either all or ip.
Then a corresponding SNAT rule is created to NAT outgoing traffic for the internal IP to a reserved external IP. This
dedicates an external IP address to an internal IP address and is useful for protocols which don’t have the notion of
ports, such as GRE.
Here’s an extract of a simple 1-to-1 NAT configuration with one internal and one external interface:
46 Chapter 9. NAT
VyOS Documentation, Release 1.2.0-beta
Firewall rules are written as normal, using the internal IP address as the source of outbound rules and the destination
of inbound rules.
NPTv6 stands for Network Prefix Translation. It’s a form of NAT for IPv6. It’s described in RFC6296. NPTv6 is
supported in linux kernel since version 3.13.
9.6 Usage
NPTv6 is very useful for IPv6 multihoming. Let’s assume the following network configuration:
• eth0 : LAN
• eth1 : WAN1, with 2001:db8:e1::/48 routed towards it
• eth2 : WAN2, with 2001:db8:e2::/48 routed towards it
Regarding LAN hosts addressing, why would you choose 2001:db8:e1::/48 over 2001:db8:e2::/48? What happens
when you get a new provider with a different routed IPv6 subnet?
The solution here is to assign to your hosts ULAs and to prefix-translate their address to the right subnet when going
through your router.
• LAN Subnet : fc00:dead:beef::/48
• WAN 1 Subnet : 2001:db8:e1::/48
• WAN 2 Subnet : 2001:db8:e2::/48
• eth0 addr : fc00:dead:beef::1/48
• eth1 addr : 2001:db8:e1::1/48
• eth2 addr : 2001:db8:e2::1/48
NPTv6 support has been added in VyOS 1.2 (Crux) and is available through nat nptv6 configuration nodes.
48 Chapter 9. NAT
CHAPTER 10
VPN
10.1 OpenVPN
Traditionally hardware routers implement IPsec exclusively due to relative ease of implementing it in hardware and
insufficient CPU power for doing encryption in software. Since VyOS is a software router, this is less of a concern.
OpenVPN has been widely used on UNIX platform for a long time and is a popular option for remote access VPN,
though it’s also capable of site-to-site connections.
The advantages of OpenVPN are: * It uses a single TCP or UDP connection and does not rely on packet source
addresses, so it will work even through a double NAT: perfect for public hotspots and such
• It’s easy to setup and offers very flexible split tunneling
• There’s a variety of client GUI frontends for any platform
The disadvantages are: * It’s slower than IPsec due to higher protocol overhead and the fact it runs in user mode while
IPsec, on Linux, is in kernel mode
• None of the operating systems have client software installed by default
In the VyOS CLI, a key point often overlooked is that rather than being configured using the set vpn stanza, OpenVPN
is configured as a network interface using set interfaces openvpn.
While many are aware of OpenVPN as a Client VPN solution, it is often overlooked as a site-to-site VPN solution due
to lack of support for this mode in many router platforms.
Site-to-site mode supports x.509 but doesn’t require it and can also work with static keys, which is simpler in many
cases. In this example, we’ll configure a simple site-to-site OpenVPN tunnel using a 2048-bit pre-shared key.
First, one one of the systems generate the key using the operational command generate openvpn key <filename>. This
will generate a key with the name provided in the /config/auth/ directory. Once generated, you will need to copy this
key to the remote router.
In our example, we used the filename openvpn-1.key which we will reference in our configuration.
49
VyOS Documentation, Release 1.2.0-beta
• The public IP address of the local side of the VPN will be 198.51.100.10
• The remote will be 203.0.113.11
• The tunnel will use 10.255.1.1 for the local IP and 10.255.1.2 for the remote.
• OpenVPN allows for either TCP or UDP. UDP will provide the lowest latency, while TCP will work better for
lossy connections; generally UDP is preferred when possible.
• The official port for OpenVPN is 1194, which we reserve for client VPN; we will use 1195 for site-to-site VPN.
• The persistent-tunnel directive will allow us to configure tunnel-related attributes, such as firewall policy as we
would on any normal network interface.
• If known, the IP of the remote router can be configured using the remote-host directive; if unknown, it can be
omitted. We will assume a dynamic IP for our remote router.
Local Configuration:
Remote Configuration:
The configurations above will default to using 128-bit Blowfish in CBC mode for encryption and SHA-1 for HMAC
authentication. These are both considered weak, but a number of other encryption and hashing algorithms are available:
For Encryption:
For Hashing:
If you change the default encryption and hashing algorithms, be sure that the local and remote ends have matching
configurations, otherwise the tunnel will not come up.
Static routes can be configured referencing the tunnel interface; for example, the local router will use a network of
10.0.0.0/16, while the remote has a network of 10.1.0.0/16:
Local Configuration:
Remote Configuration:
Firewall policy can also be applied to the tunnel interface for local, in, and out directions and function identically to
ethernet interfaces.
If making use of multiple tunnels, OpenVPN must have a way to distinguish between different tunnels aside from the
pre-shared-key. This is either by referencing IP address or port number. One option is to dedicate a public IP to each
tunnel. Another option is to dedicate a port number to each tunnel (e.g. 1195,1196,1197. . . ).
OpenVPN status can be verified using the show openvpn operational commands. See the built-in help for a complete
list of options.
Multi-client server is the most popular OpenVPN mode on routers. It always uses x.509 authentication and therefore
requires a PKI setup. This guide assumes you have already setup a PKI and have a CA certificate, a server certificate
and key, a certificate revokation list, a Diffie-Hellman key exchange parameters file. You do not need client certificates
and keys for the server setup.
In this example we will use the most complicated case: a setup where each client is a router that has its own subnet
(think HQ and branch offices), since simpler setups are subsets of it.
Suppose you want to use 10.23.1.0/24 network for client tunnel endpoints and all client subnets belong to 10.23.0.0/20.
All clients need access to the 192.168.0.0/16 network.
First we need to specify the basic settings. 1194/UDP is the default. The persistent-tunnel option is recommended, it
prevents the TUN/TAP device from closing on connection resets or daemon reloads.
Then we need to specify the location of the cryptographic materials. Suppose you keep the files in /config/auth/openvpn
10.1. OpenVPN 51
VyOS Documentation, Release 1.2.0-beta
Now we need to specify the server network settings. In all cases we need to specify the subnet for client tunnel
endpoints. Since we want clients to access a specific network behind out router, we will use a push-route option for
installing that route on clients.
Since it’s a HQ and branch offices setup, we will want all clients to have fixed addresses and we will route traffic to
specific subnets through them. We need configuration for each client to achieve this.
Note: Clients are identified by the CN field of their x.509 certificates, in this example the CN is client0:
OpenVPN will not automatically create routes in the kernel for client subnets when they connect and will only use
client-subnet association internally, so we need to create a route to the 10.23.0.0/20 network ourselves:
Example for configuring a simple L2TP over IPsec VPN for remote access (works with native Windows and Mac VPN
clients):
Also note that if you wish to allow the VPN to be used for external access you will need to add the appropriate source
NAT rules to your configuration.
To be able to resolve when connected to the VPN, the following DNS rules are needed as well.
Note: Those are the Google public DNS servers. You can also use the public available servers from Quad9 (9.9.9.9)
or Cloudflare (1.1.1.1).
Established sessions can be viewed using the show vpn remote-access operational command.
The above configuration made use of local accounts on the VyOS router for authenticating L2TP/IPSec clients. In
bigger environments usually something like RADIUS (FreeRADIUS or Microsoft Network Policy Server, NPS) is
used.
VyOS supports either local or radius user authentication:
In addition one or more RADIUS servers can be configured to server for user authentication. This is done using the
radius server and radius server key nodes:
set vpn l2tp remote-access authentication radius server 1.1.1.1 key 'foo'
set vpn l2tp remote-access authentication radius server 2.2.2.2 key 'foo'
Note: Some RADIUS severs make use of an access control list who is allowed to query the server. Please configure
your VyOS router in the allowed client list.
If you are using e.g. OSPF as IGP always the nearest interface facing the RADIUS server is used. With VyOS 1.2 you
can bind all outgoing RADIUS requests to a single source IP e.g. the loopback interface.
Above command will use 3.3.3.3 as source IPv4 address for all RADIUS queries on this NAS.
Example: * eth1 is WAN interface * left subnet: 192.168.0.0/24 #s ite1, server side (i.e. locality, actually there is no
client or server roles) * left local_ip: 1.1.1.1 # server side WAN IP * right subnet: 10.0.0.0/24 # site2,remote office
side * right local_ip: 2.2.2.2 # remote office side WAN IP
# server config
set vpn ipsec esp-group office-srv-esp compression 'disable'
set vpn ipsec esp-group office-srv-esp lifetime '1800'
set vpn ipsec esp-group office-srv-esp mode 'tunnel'
set vpn ipsec esp-group office-srv-esp pfs 'enable'
set vpn ipsec esp-group office-srv-esp proposal 1 encryption 'aes256'
set vpn ipsec esp-group office-srv-esp proposal 1 hash 'sha1'
set vpn ipsec ike-group office-srv-ike ikev2-reauth 'no'
set vpn ipsec ike-group office-srv-ike key-exchange 'ikev1'
set vpn ipsec ike-group office-srv-ike lifetime '3600'
set vpn ipsec ike-group office-srv-ike proposal 1 encryption 'aes256'
set vpn ipsec ike-group office-srv-ike proposal 1 hash 'sha1'
set vpn ipsec ipsec-interfaces interface 'eth1'
set vpn ipsec site-to-site peer 2.2.2.2 authentication mode 'pre-shared-secret'
set vpn ipsec site-to-site peer 2.2.2.2 authentication pre-shared-secret
˓→'SomePreSharedKey'
# server side
set nat source rule 10 destination address '10.0.0.0/24'
set nat source rule 10 'exclude'
set nat source rule 10 outbound-interface 'eth1'
set nat source rule 10 source address '192.168.0.0/24'
To allow traffic to pass through to clients, you need to add the following rules. (if you used the default configuration
at the top of this page)
# server side
set firewall name OUTSIDE-LOCAL rule 32 action 'accept'
set firewall name OUTSIDE-LOCAL rule 32 source address '10.0.0.0/24'
10.4 DMVPN
Note: DMVPN only automates the tunnel endpoint discovery and setup. A complete solution also incorporates the
use of a routing protocol. BGP is particularly well suited for use with DMVPN.
Baseline Configuration:
STEPS:
1. Create tunnel config (interfaces tunnel)
2. Create nhrp (protocols nhrp)
3. Create ipsec vpn (optional, but recommended for security) (vpn ipsec)
The tunnel will be set to mGRE if for encapsulation gre is set, and no remote-ip is set. If the public ip is provided by
DHCP the tunnel local-ip can be set to “0.0.0.0”
interfaces
tunnel <tunN> {
address <ipv4>
encapsulation gre
(continues on next page)
10.4. DMVPN 57
VyOS Documentation, Release 1.2.0-beta
SPOKE1 Configuration:
interfaces
tunnel <tunN> {
(continues on next page)
10.4. DMVPN 59
VyOS Documentation, Release 1.2.0-beta
SPOKE2 Configuration
interfaces
tunnel <tunN> {
address <ipv4>
encapsulation gre
local-ip <public ip>
multicast enable
description <txt>
parameters {
ip {
<usual IP options>
}
}
}
}
protocols {
nhrp {
tunnel <tunN> {
cisco-authentication <key phrase>
map <ipv4/net> {
nbma-address <ipv4>
register
}
holding-time <seconds>
multicast nhs
redirect
shortcut
}
}
}
vpn {
ipsec {
esp-group <text> {
lifetime <30-86400>
mode tunnel
pfs enable
proposal <1-65535> {
encryption aes256
hash sha1
}
proposal <1-65535> {
encryption 3des
hash md5
}
}
ike-group <text> {
key-exchange ikev1
lifetime <30-86400>
proposal <1-65535> {
encryption aes256
hash sha1
}
proposal <1-65535> {
encryption aes128
hash sha1
}
}
(continues on next page)
10.4. DMVPN 61
VyOS Documentation, Release 1.2.0-beta
10.5 PPTP-Server
The Point-to-Point Tunneling Protocol (PPTP) has been implemented in VyOS only for backwards compatibility.
PPTP has many well known secrurity issues and you should use one of the many other new VPN implementations.
As per default and if not otherwise defined, mschap-v2 is being used for authentication and mppe 128-bit (stateless)
for encryption. If no gateway-address is set within the configuration, the lowest IP out of the /24 client-ip-pool is being
used. For instance, in the example below it would be 192.168.0.1.
set vpn pptp remote-access authentication local-users username test password 'test'
set vpn pptp remote-access authentication mode 'local'
set vpn pptp remote-access client-ip-pool start '192.168.0.10'
set vpn pptp remote-access client-ip-pool stop '192.168.0.15'
set vpn pptp remote-access gateway-address '10.100.100.1'
set vpn pptp remote-access outside-address '10.1.1.120'
Install the client software via apt and execute pptpsetup to generate the configuration.
pon TESTTUNNEL
The command pon TESTUNNEL establishes the PPTP tunnel to the remote system.
All tunnel sessions can be checked via:
WireGuard is an extremely simple yet fast and modern VPN that utilizes state-of-the-art cryptography. See https:
//www.wireguard.com for more information.
10.6.1 Configuration
Generate the keypair, which creates a public and private part and stores it within VyOS.
10.5. PPTP-Server 63
VyOS Documentation, Release 1.2.0-beta
wg01:~$ configure
wg01# run generate wireguard keypair
The public key is being shared with your peer(s), your peer will encrypt all traffic to your system using this public key.
The next step is to configure your local side as well as the policy based trusted destination addresses. If you only
initiate a connection, the listen port and endpoint is optional, if you however act as a server and endpoints initiate the
connections to your system, you need to define a port your clients can connect to, otherwise it’s randomly chosen and
may make it difficult with firewall rules, since the port may be a different one when you reboot your system.
You will also need the public key of your peer as well as the network(s) you want to tunnel (allowed-ips) to configure
a wireguard tunnel. The public key below is always the public key from your peer, not your local one.
local side
The last step is to define an interface route for 10.2.0.0/24 to get through the wireguard interface wg01. Multiple IPs
or networks can be defined and routed, the last check is allowed-ips which either prevents or allows the traffic.
remote side
Assure that your firewall rules allow the traffic, in which case you have a working VPN using wireguard.
An additional layer of symmetric-key crypto can be used on top of the asymmetric crypto, which is optional.
Copy the key, it is not stored on the local file system. Make sure you distribute that key in a safe manner, it’s a
symmatric key, so only you and your peer should have knowledge if its content.
operational commands
interface: wg01
public key: xHvgSJC8RTClfvjc0oX6OALxU6GGLapjthjw7x82CSw=
private key: (hidden)
listening port: 12345
peer: 9Ek3R30mG6Vk+GHsENtPF0b9Ul+ftxx4dDBa1bdBxX8=
endpoint: 192.168.0.142:12345
allowed ips: 10.2.0.0/24
latest handshake: 4 minutes, 22 seconds ago
transfer: 860 B received, 948 B sent
VyOS uses tc as backend for QoS. VyOS provides its users with configuration nodes for the following shap-
ing/queueing/policing disciplines:
• HTB
• HFSC
• SFQ
• pfifo
• network-emulator
• PRIO
• GRED
• TBF
• DRR
VyOS QoS configuration is done in two steps. The first one consists in setting up your classes/queues and traffic filters
to distribute traffic amongst them. The second step is to apply such traffic policy to an interface ingress or egress.
67
VyOS Documentation, Release 1.2.0-beta
This policy sets download and upload bandwidth maximums (roughly 90% of the speeds possible), then divvies up
the traffic into buckets of importance, giving guaranteed bandwidth chunks to types of traffic that are necessary for
general interactive internet use, like web browsing, streaming, or gaming.
After identifying and prioritizing that traffic, it drops the remaining traffic into a general-priority bucket, which it gives
a lower priority than what is required for real-time use. If there is no real-time traffic that needs the bandwidth, the
lower-priority traffic can use most of the connection. This ensures that the connection can be used fully by whatever
wants it, without suffocating real-time traffic or throttling background traffic too much.
set traffic-policy shaper download bandwidth '175mbit'
set traffic-policy shaper download class 10 bandwidth '10%'
set traffic-policy shaper download class 10 burst '15k'
set traffic-policy shaper download class 10 ceiling '100%'
set traffic-policy shaper download class 10 match dns ip source port '53'
set traffic-policy shaper download class 10 match icmp ip protocol 'icmp'
set traffic-policy shaper download class 10 match ssh ip source port '22'
set traffic-policy shaper download class 10 priority '5'
set traffic-policy shaper download class 10 queue-type 'fair-queue'
set traffic-policy shaper download class 20 bandwidth '10%'
set traffic-policy shaper download class 20 burst '15k'
set traffic-policy shaper download class 20 ceiling '100%'
set traffic-policy shaper download class 20 match http ip source port '80'
set traffic-policy shaper download class 20 match https ip source port '443'
set traffic-policy shaper download class 20 priority '4'
set traffic-policy shaper download class 20 queue-type 'fair-queue'
set traffic-policy shaper download default bandwidth '70%'
set traffic-policy shaper download default burst '15k'
set traffic-policy shaper download default ceiling '100%'
set traffic-policy shaper download default priority '3'
set traffic-policy shaper download default queue-type 'fair-queue'
set traffic-policy shaper upload bandwidth '18mbit'
set traffic-policy shaper upload class 2 bandwidth '10%'
set traffic-policy shaper upload class 2 burst '15k'
set traffic-policy shaper upload class 2 ceiling '100%'
(continues on next page)
A packet queuing mechanism on a FIFO (First In, First Out) basis; packets are sent out in the same order as they
arrive. The queue has a defined length, packets arriving after the queue is filled up will be dropped (hence the name
drop tail, the “tail” of the queue will be dropped). With this policy in place, all traffic is treated equally and put into a
single queue. Applicable to outbound traffic only.
Available commands:
• Define a drop-tail policy (unique name, exclusive to this policy):
set traffic-policy drop-tail <policy name>
• Add a description:
set traffic-policy drop-tail <policy name> description <description>
• Set the queue length limit (max. number of packets in queue), range 0. . . 4294967295 packets:
set traffic-policy drop-tail <policy name> queue-limit <limit>
Fair queue is a packet queuing mechanism that separates traffic flows based on their source/destination IP addresses
and/or source port and places them into buckets. Bandwidth is allocated fairly between buckets based on the Stochastic
airness Queuing algorithm. Applicable to outbound traffic only.
Available commands:
11.2.3 Limiter
The limiter performs ingress policing of traffic flows. Multiple classes of traffic can be defined and traffic limits can be
applied to each class. Traffic exceeding the defined bandwidth limits is dropped. Applicable to inbound traffic only.
Available commands:
• Define a traffic limiter policy: set traffic-policy limiter <policy-name>
• Add a description: set traffic-policy limiter <policy-name> description
<description>
Traffic classes
• Define a traffic class for a limiter policy, range for class ID is 1. . . 4095:
set traffic-policy limiter <policy-name> class <class ID>
• Add a class description:
set traffic-policy limiter <policy-name> class <class ID> description
<description>
• Specify a bandwidth limit for a class, in kbit/s:
set traffic-policy limiter <policy-name> class <class ID> bandwidth
<rate>.
Available suffixes:
• kbit (kilobits per second, default)
• mbit (megabits per second)
• gbit (gigabits per second)
• kbps (kilobytes per second)
• mbps (megabytes per second)
• gbps (gigabytes per second)
• Set a burst size for a class, the maximum amount of traffic that can be sent, in bytes:
set traffic-policy limiter <policy-name> class <class ID> burst
<burst-size>.
Available suffixes:
• kb (kilobytes)
• mb (megabytes)
• gb (gigabytes)
Default class
• Define a default class for a limiter policy that applies to traffic not matching any other classes for this policy:
set traffic-policy limiter <policy name> default
• Specify a bandwidth limit for the default class, in kbit/s:
set traffic-policy limiter <policy name> default bandwidth <rate>.
Available suffixes:
• kbit (kilobits per second, default)
• mbit (megabits per second)
• gbit (gigabits per second)
• kbps (kilobytes per second)
• mbps (megabytes per second)
• gbps (gigabytes per second)
• Set a burst size for the default class, the maximum amount of traffic that can be sent, in bytes:
set traffic-policy limiter <policy-name> default burst <burst-size>.
Available suffixes:
• kb (kilobytes)
• mb (megabytes)
• gb (gigabytes)
• Specify the priority of the default class to set the order in which the rules are evaluated, the higher the number
the lower the priority, range 0. . . 20 (default 20):
set traffic-policy limiter <policy name> default priority <priority>
Matching rules
set traffic-policy limiter <policy name> class <class ID> match <match
name> ipv6 source <IPv6 address|port>
• Specify a match criterion based on DSCP (Differentiated Services Code Point) value, DSCP value may be
specified as decimal or hexadecimal number:
set traffic-policy limiter <policy name> class <class ID> match <match
name> ipv6 dscp <DSCP value>
• Specify a match criterion based on IPv6 protocol, protocol may be specified by name (i.e. icmp) or IANA-
assigned number:
set traffic-policy limiter <policy name> class <class ID> match <match
name> ipv6 protocol <proto>
The network emulator policy emulates WAN traffic, which is useful for testing purposes. Applicable to outbound
traffic only.
Available commands:
• Define a network emulator policy:
set traffic-policy network-emulator <policy name>
• Add a description:
set traffic-policy network-emulator <policy name> description
<description>
• Specify a bandwidth limit in kbit/s:
set traffic-policy network-emulator <policy name> bandwidth <rate>
Available suffixes:
• kbit (kilobits per second, default)
• mbit (megabits per second)
• gbit (gigabits per second)
• kbps (kilobytes per second)
• mbps (megabytes per second)
• gbps (gigabytes per second)
• Set a burst size, the maximum amount of traffic that can be sent, in bytes:
set traffic-policy network-emulator <policy name> burst <burst size>
Available suffixes:
• kb (kilobytes)
• mb (megabytes)
• gb (gigabytes)
• Define a delay between packets:
set traffic-policy network-emulator <policy name> network-delay <delay>
Available suffixes:
• secs (seconds)
• ms (milliseconds, default)
• us (microseconds)
• Set a percentage of corrupted of packets (one bit flip, unchanged checksum):
set traffic-policy network-emulator <policy name> packet-corruption
<percent>
• Set a percentage of random packet loss:
set traffic-policy network-emulator <policy name> packet-loss <percent>
• Set a percentage of packets for random reordering:
set traffic-policy network-emulator <policy name> packet-reordering
<percent>
• Set a queue length limit in packets, range 0. . . 4294967295, default 127:
set traffic-policy network-emulator <policy name> queue-limit <limit>
Up to seven queues with differing priorities can be defined, packets are placed into queues based on associated match
criteria. Packets are transmitted from the queues in priority order. If queues with a higher order are being filled with
packets continuously, packets from lower priority queues will only be transmitted after traffic volume from higher
priority queues decreases.
Available commands:
• Define a priority queue:
set traffic-policy priority-queue <policy name>
• Add a description:
set traffic-policy priority-queue <policy name> description <description>
Traffic classes
• Define a traffic class, each class is a separate queue, range for class ID is 1. . . 7, while 1 being the lowest priority:
set traffic-policy priority-queue <policy name> class <class ID>
• Add a class description:
set traffic-policy priority-queue <policy name> class <class ID>
description <description>
• Set a queue length limit in packets, default 1000:
set traffic-policy priority-queue <policy name> class <class ID>
queue-limit <limit>
• Specify a queue type for a traffic class, available queue types:
• drop-tail
• fair-queue
• random-detect
Default class
Matching rules
RED
A Random Early Detection (RED) policy starts randomly dropping packets from a queue before it reaches its queue
limit thus avoiding congestion. It is also beneficial for TCP connections as the gradual dropping of packets acts as a
signal for the sender to decrease its transmission rate, avoiding global TCP synchronisation. Applicable to outbound
traffic only.
Available commands:
• Define a RED policy:
set traffic-policy random-detect <policy name>
• Add a description:
set traffic-policy random-detect <policy name> description <description>
• Set a bandwidth limit, default auto:
set traffic-policy random-detect <policy name> bandwidth <rate>
Available suffixes:</u>
• auto (bandwidth limit based on interface speed, default)
• kbit (kilobits per second)
• mbit (megabits per second)
• gbit (gigabits per second)
• kbps (kilobytes per second)
• mbps (megabytes per second)
• gbps (gigabytes per second)
WRED
In contrast to RED, Weighted Random Early Detection (WRED) differentiates between classes of traffic in a single
queue and assigns different precedence to traffic flows accordingly; low priority packets are dropped from a queue
earlier than high priority packets. This is achieved by using the first three bits of the ToS (Type of Service) field to
categorise data streams and in accordance with the defined precedence parameters a decision is made. A WRED policy
is defined with the following parameters:
• precedence
• min-threshold
• max-threshold
• average-packet
• mark-probability
• queue-limit
If the average queue size is lower than the min-threshold, an arriving packet is placed in the queue. If the
average queue size is between min-threshold and max-threshold an arriving packet is either dropped or
placed in the queue depending on the defined mark-probability. In case the average queue size is larger than
max-threshold, packets are dropped. If the current queue size is larger than queue-limit, packets are dropped.
The average queue size depends on its former average size and its current size. If max-threshold is set but
min-threshold is not, then min-threshold is scaled to 50% of max-threshold. In principle, values must
be min-threshold < max-threshold < queue-limit. Applicable to outbound traffic only.
Precedence Priority
7 Network Control
6 Internetwork Control
5 CRITIC/ECP
4 Flash Override
3 Flash
2 Immediate
1 Priority
0 Routine
• min-threshold - Min value for the average queue length, packets are dropped if the average queue length reaches
this threshold. Range 0. . . 4096, default is dependent on precedence:
• max-threshold - Max value for the average queue length, packets are dropped if this value is exceeded. Range
0. . . 4096 packets, default 18.
• average-packet - Average packet size in bytes, default 1024.
• mark-probability - The fraction of packets (n/probability) dropped from the queue when the average queue
length reaches <code>max-threshold</code>, default 10.
• queue-limit - Packets are dropped when the current queue length reaches this value, default 4*<code>max-
threshold</code>.
Usage:
set traffic-policy random-detect <policy-name> precedence <precedence>
[average-packet <bytes> | mark-probability <probability> | max-threshold <max>
| min-threshold <min> | queue-limit <packets>]
The rate control policy uses the Token Bucket Filter (TBF) algorithm to limit the packet flow to a set rate. Short bursts
can be allowed to exceed the limit. Applicable to outbound traffic only.
Available commands:
• Define a rate control policy:
set traffic-policy rate-control <policy-name>
• Add a description:
set traffic-policy rate-control <policy-name> description <description>
The round robin policy divides available bandwidth between all defined traffic classes.
Available commands:
• Define a round robin policy:
set traffic-policy round-robin <policy-name>
• Add a description:
set traffic-policy round-robin <policy-name> description <description>
• Define a traffic class ID, range 2. . . 4095:
set traffic-policy round-robin <policy-name> class <class>
Default policy:
• Define a default priority queue:
set traffic-policy round-robin <policy name> default
• Set the number of packets that can be sent per scheduling quantum:
set traffic-policy round-robin <policy name> default quantum <packets>
• Define a maximum queue lenght for the default policy in packets:
set traffic-policy round-robin <policy name> default queue-limit <limit>
• Specify the queuing type for the default policy, available queue types:
• drop-tail
• fair-queue
• priority (based on the DSCP values in the ToS byte)
set traffic-policy round-robin <policy name> default
queue-type <type>
Matching rules
• Specify a match criterion based on destination IPv4 address and/or port, port may be specified as number or
service name (i.e. ssh):
set traffic-policy round-robin <policy name> class <class ID> match <match
name> ip destination <IPv4 address|port>
• Specify a match criterion based on source IPv4 address and/or port, port may be specified as number or
service name (i.e. ssh):
set traffic-policy round-robin <policy name> class <class ID> match <match
name> ip source <IPv4 address|port>
• Specify a match criterion based on DSCP (Differentiated Services Code Point) value, DSCP value may be
specified as decimal or hexadecimal number:
set traffic-policy round-robin <policy name> class <class ID> match <match
name> ip dscp <DSCP value>
• Specify a match criterion based on IPv4 protocol, protocol may be specified by name (i.e. icmp) or IANA-
assigned number:
set traffic-policy round-robin <policy name> class <class ID> match <match
name> ip protocol <proto>
IPv6
• Specify a match criterion based on destination IPv6 address and/or port, port may be specified as number or
service name (i.e. ssh):
set traffic-policy round-robin <policy name> class <class ID> match <match
name> ipv6 destination <IPv6 address|port>
• Specify a match criterion based on source IPv6 address and/or port, port may be specified as number or
service name (i.e. ssh):
set traffic-policy round-robin <policy name> class <class ID> match <match
name> ipv6 source <IPv6 address|port>
• Specify a match criterion based on DSCP (Differentiated Services Code Point) value, DSCP value may be
specified as decimal or hexadecimal number:
set traffic-policy round-robin <policy name> class <class ID> match <match
name> ipv6 dscp <DSCP value>
• Specify a match criterion based on IPv6 protocol, protocol may be specified by name (i.e. icmp) or IANA-
assigned number:
set traffic-policy round-robin <policy name> class <class ID> match <match
name> ipv6 protocol <proto>
The shaper policy uses the Hierarchical Token Bucket algorithm to allocate different amounts of bandwidth to different
traffic classes. In contrast to round robin, shaper limits bandwidth allocation by traffic class whereas round robin
divides the total available bandwidth between classes.
Avialable commands:
• Define a shaper policy:
set traffic-policy shaper <policy-name>
• Add a description:
set traffic-policy shaper <policy-name> description <description>
• Set the available bandwidth for all combined traffic of this policy in kbit/s, default 100%:
set traffic-policy shaper <policy-name> bandwidth <rate>
Available suffixes:
• % (percentage of total bandwidth)
• kbit (kilobits per second)
• mbit (megabits per second)
• gbit (gigabits per second)
• kbps (kilobytes per second)
• mbps (megabytes per second)
• gbps (gigabytes per second)
Traffic classes
• Define a traffic class for a shaper policy, range for class ID is 2. . . 4095:
set traffic-policy shaper <policy-name> class <class ID>
• Add a class description:
set traffic-policy shaper <policy name> class <class ID> description
<description>
• Specify a bandwidth limit for a class, in kbit/s:
set traffic-policy shaper <policy-name> class <class ID> bandwidth <rate>
Available suffixes:
• kbit (kilobits per second, default)
• mbit (megabits per second)
• gbit (gigabits per second)
• kbps (kilobytes per second)
• mbps (megabytes per second)
• gbps (gigabytes per second)
• Set a burst size for a class, the maximum amount of traffic that can be sent, in bytes:
set traffic-policy shaper <policy-name> class <class ID> burst
<burst-size>
Available suffixes:
• kb (kilobytes)
• mb (megabytes)
• gb (gigabytes)
Matching rules
set traffic-policy shaper <policy name> class <class ID> match <match
name> ipv6 protocol <proto>
TBD
The case of ingress shaping. Only a limiter policy can be applied directly for ingress traffic on an interface. It is
possible though to use what is called an Intermediate Functional Block (IFB) to allow the usage of any policy on the
ingress traffic.
Let’s assume eth0 is your WAN link. You created two traffic-policies: WAN-IN and WAN-OUT.
Steps to do:
• First, create the IFB:
set interfaces input ifb0 description "WAN Input"
• Apply the WAN-OUT traffic-policy to ifb0 input.
set interfaces input ifb0 traffic-policy in WAN-IN
• Redirect traffic from eth0 to ifb0
set interfaces ethernet eth0 redirect ifb0
limiter, round-robin, priority-queue, shaper and shaper-hfsc distribute traffic into different classes with different op-
tions. In VyOS, classes are numbered and work like firewall rules. e.g:
set traffic-policy shaper SHAPER class 30
Example:
A match filter contains multiple criteria and will match traffic if all those criteria are true.
For example:
description
set traffic-policy shaper SHAPER class 30 match MATCH description "match filter
˓→description"
ether
destination
protocol
source
interface
ip
destination
dscp
max-length
Will match ipv4 packets with a total length lesser than set value.
protocol
source
tcp
Note: You must set ip protocol to TCP to use the TCP filters.
Note: This filter will only match packets with an IPv4 header length of 20 bytes (which is the majority of IPv4
packets anyway).
ipv6
destination
dscp
max-length
Will match ipv6 packets with a payload length lesser than set value.
protocol
source
tcp
Note: You must set ipv6 protocol to TCP to use the TCP filters.
Note: This filter will only match IPv6 packets with no header extension, see http://en.wikipedia.org/wiki/IPv6_
packet#Extension_headers for no header extension.
mark
vif
Services
12.1 Conntrack
One of the important features built on top of the Netfilter framework is connection tracking. Connection tracking
allows the kernel to keep track of all logical network connections or sessions, and thereby relate all of the packets
which may make up that connection. NAT relies on this information to translate all related packets in the same way,
and iptables can use this information to act as a stateful firewall.
The connection state however is completely independent of any upper-level state, such as TCP’s or SCTP’s state.
Part of the reason for this is that when merely forwarding packets, i.e. no local delivery, the TCP engine may not
necessarily be invoked at all. Even connectionless-mode transmissions such as UDP, IPsec (AH/ESP), GRE and other
tunneling protocols have, at least, a pseudo connection state. The heuristic for such protocols is often based upon a
preset timeout value for inactivity, after whose expiration a Netfilter connection is dropped.
Each Netfilter connection is uniquely identified by a (layer-3 protocol, source address, destination address, layer-4
protocol, layer-4 key) tuple. The layer-4 key depends on the transport protocol; for TCP/UDP it is the port numbers,
for tunnels it can be their tunnel ID, but otherwise is just zero, as if it were not part of the tuple. To be able to inspect
the TCP port in all cases, packets will be mandatorily defragmented.
12.1.1 Configuration
# Protocols only for which local conntrack entries will be synced (tcp, udp, icmp,
˓→sctp)
# Protocol for which expect entries need to be synchronized. (all, ftp, h323, nfs,
˓→sip, sqlnet)
(continues on next page)
91
VyOS Documentation, Release 1.2.0-beta
12.1.2 Example
If the table is empty and you have a warning message, it means conntrack is not enabled. To enable conntrack, just
create a NAT or a firewall rule.
On the active router, you should have informations in the internal-cache of conntrack-sync. The same current active
connections number should be shown in the external-cache of the standby router
On active router run:
cache internal:
current active connections: 10
connections created: 8517 failed: 0
connections updated: 127 failed: 0
connections destroyed: 8507 failed: 0
cache external:
current active connections: 0
connections created: 0 failed: 0
connections updated: 0 failed: 0
connections destroyed: 0 failed: 0
traffic processed:
0 Bytes 0 Pckts
12.1. Conntrack 93
VyOS Documentation, Release 1.2.0-beta
message tracking:
0 Malformed msgs 0 Lost msgs
cache internal:
current active connections: 0
connections created: 0 failed: 0
connections updated: 0 failed: 0
connections destroyed: 0 failed: 0
cache external:
current active connections: 10
connections created: 888 failed: 0
connections updated: 134 failed: 0
connections destroyed: 878 failed: 0
traffic processed:
0 Bytes 0 Pckts
message tracking:
0 Malformed msgs 0 Lost msgs
Multiple DHCP Servers can be run from a single machine. Each DHCP service is identified by a shared-network-name.
In this example, we are offering address space in the 172.16.17.0/24 network, which is on eth1, and pppoe0 is our
connection to the internet. We are using the network name dhcpexample.
12.2.2 Prerequisites
Configuring the PPPoE interface is assumed to be done already, and appears on pppoe0
12.2.4 Explanation
12.2.5 Failover
The primary and secondary statements determines whether the server is primary or secondary
or
Note: In order for the primary and the secondary DHCP server to keep their lease tables in sync, they must be able to
reach each other on TCP port 647. If you have firewall rules in effect, adjust them accordingly.
VyOS provides DHCPv6 server functionality which is described in this section. In order to use the DHCPv6 server it
has to be enabled first:
Clients receiving advertise messages from multiple servers choose the server with the highest preference value. The
range for this value is 0. . . 255. Set a preference value for the DHCPv6 server:
Delete a preference:
The default lease time for DHCPv6 leases is 24 hours. This can be changed by supplying a default-time, maximum-time
and minimum-time (all values in seconds):
A Network Information (NIS) domain can be set to be used for DHCPv6 clients:
The procedure to specify a Network Information Service Plus (NIS+) domain is similar to the NIS domain one:
By IPv6 address
A Session Initiation Protocol (SIP) server address can be specified for DHCPv6 clients:
By FQDN
Simple Network Time Protocol (SNTP) server address for DHCPv6 clients
DHCPv6 address pools must be configured for the system to act as a DHCPv6 server. The following example describes
a common scenario.
A shared network named NET1 serves subnet 2001:db8:100::/64 which is connected to eth1, a DNS server at
2001:db8:111::111 is used for name services. The range of the address pool shall be ::100 through ::199. The
lease time will be left at the default value which is 24 hours.
commit
show service dhcpv6-server
shared-network-name NET1 {
subnet 2001:db8:100::/64 {
address-range {
start 2001:db8:100::100 {
stop 2001:db8:100::199
}
}
name-server 2001:db8:111::111
}
}
In order to map specific IPv6 addresses to specific hosts static mappings can be created. The following example
explains the process.
IPv6 address 2001:db8:100::101 shall be statically mapped to a device with MAC address 00:15:c5:b7:5e:23, this
host-specific mapping shall be named client1.
Note: The MAC address identifier is defined by the last 4 byte of the MAC address.
If you want your router to forward DHCP requests to an external DHCP server you can configure the system to act as
a DHCP relay agent. The DHCP relay agent works with IPv4 and IPv6 addresses.
All interfaces used for the DHCP relay must be configured. See https://wiki.vyos.net/wiki/Network_address_setup.
In this example the interfaces used for the DHCP relay are eth1 and eth2. The router receives DHCP client requests
on eth1 and relays them through eth2 to the DHCP server at 10.0.1.4.
12.4.2 Configuration
The router should discard DHCP packages already containing relay agent information to ensure that only requests
from DHCP clients are forwarded:
commit
show service dhcp-relay
interface eth1
interface eth2
server 10.0.1.4
relay-options {
relay-agents-packets discard
}
In this example DHCPv6 requests are received by the router on eth1 (listening interface) and forwarded through eth2
(upstream interface) to the external DHCPv6 server at 2001:db8:100::4.
Configuration
Set eth2 to be the upstream interface and specify the IPv6 address of the DHCPv6 server:
commit
show service dhcpv6-relay
listen-interface eth1 {
}
upstream-interface eth2 {
address 2001:db8:100::4
}
Set the maximum hop count before packets are discarded. Range 0. . . 255, default 10.
• set service dhcp-relay relay-options hop-count 'count'
Set maximum size of DHCP packets including relay agent information. If a DHCP packet size surpasses this value it
will be forwarded without appending relay agent information. Range 64. . . 1400, default 576.
• set service dhcp-relay relay-options max-size 'size'
Four policies for reforwarding DHCP packets exist:
• append: The relay agent is allowed to append its own relay information to a received DHCP packet, disregarding
relay information already present in the packet.
• discard: Received packets which already contain relay information will be discarded.
• forward: All packets are forwarded, relay information already present will be ignored.
• replace: Relay information already present in a packet is stripped and replaced with the router’s own relay
information set.
• set service dhcp-relay relay-options relay-agents-packet 'policy'
Set maximum hop count before packets are discarded. Default: 10.
• set service dhcpv6-relay max-hop-count 'count'
If this is set the relay agent will insert the interface ID. This option is set automatically if more than one listening
interfaces are in use.
• set service dhcpv6-relay use-interface-id-option
Use DNS forwarding if you want your router to function as a DNS server for the local network. There are several
options, the easiest being ‘forward all traffic to the system DNS server(s)’ (defined with set system name-server):
12.5.1 Example 1
Router with two interfaces eth0 (WAN link) and eth1 (LAN). A DNS server for the local domain (example.com) is at
192.0.2.1, other DNS requests are forwarded to Google’s DNS servers.
12.5.2 Example 2
Same as example 1 but with additional IPv6 addresses for Google’s public DNS servers:
set service dns forwarding domain example.com server 192.0.2.1
set service dns forwarding name-server 8.8.8.8
set service dns forwarding name-server 8.8.4.4
set service dns forwarding name-server 2001:4860:4860::8888
set service dns forwarding name-server 2001:4860:4860::8844
set service dns forwarding listen-on 'eth1'
VyOS is able to update a remote DNS record when an interface gets a new IP address. In order to do so, VyOS
includes ddclient, a perl script written for this exact purpose.
ddclient uses two methods to update a DNS record. The first one will send updates directly to the DNS daemon, in
compliance with RFC2136. The second one involves a third party service, like DynDNS.com or any other similar
website. This method uses HTTP requests to transmit the new IP address. You can configure both in VyOS.
You can optionally set a TTL (note : default value is 600 seconds) :
set ttl 600
You can also keep a different dns zone updated. Just create a new config node:
edit service dns dynamic interface eth0 rfc2136 <confignode2>
VyOS is also able to use any service relying on protocols supported by ddclient.
To use such a service, you must define a login, a password, one or multiple hostnames, a protocol and a server.
edit service dns dynamic interface eth0 service HeNet
set login my-login # set password my-password
set host-name my-tunnel-id
set protocol dyndns2
set server ipv4.tunnelbroker.net
VyOS is also shipped with a list of known services. You don’t need to set the protocol and server value as VyOS has
defaults provided for those. These are the services VyOS knows about:
• afraid
• changeip
• dnspark
• dslreports
• dyndns
• easydns
• namecheap
• noip
• zoneedit
To use DynDNS for example:
edit service dns dynamic interface eth0 service dyndns
set login my-login
set password my-password
set host-name my-dyndns-hostname
By default, ddclient will update a dynamic dns record using the IP address directly attached to the interface. If your
VyOS instance is behind NAT, your record will be updated to point to your internal IP.
ddclient has another way to determine the WAN IP address. This is controlled by these two options:
ddclient will load the webpage at [url] and will try to extract an IP address for the response. ddclient will skip any
address located before the string set in [skip].
12.7 LLDP
The Link Layer Discovery Protocol (LLDP) is a vendor-neutral link layer protocol in the Internet Protocol Suite used
by network devices for advertising their identity, capabilities, and neighbors on an IEEE 802 local area network,
principally wired Ethernet.[1] The protocol is formally referred to by the IEEE as Station and Media Access Control
Connectivity Discovery specified in IEEE 802.1AB and IEEE 802.3-2012 section 6 clause 79.
LLDP performs functions similar to several proprietary protocols, such as Cisco Discovery Protocol, Foundry Discov-
ery Protocol, Nortel Discovery Protocol and Link Layer Topology Discovery.
Information gathered with LLDP is stored in the device as a management information database (MIB) and can be
queried with the Simple Network Management Protocol (SNMP) as specified in RFC 2922. The topology of an
LLDP-enabled network can be discovered by crawling the hosts and querying this database. Information that may be
retrieved include:
• System name and description
• Port name and description
• VLAN name
• IP management address
• System capabilities (switching, routing, etc.)
• MAC/PHY information
• MDI power
• Link aggregation
12.7.2 Configuration
Options
• Display with:
show lldp neighbors
Exemple:
• Options:
• detail - Show lldp neighbors detail
• interface - Show LLDP for specified interface
12.7.4 Troubleshooting
Starting with VyOS 1.2 a Multicast DNS (mDNS) repeater functionality is provided.
Multicast DNS uses the 224.0.0.51 address, which is “administratively scoped” and does not leave the subnet. It re-
broadcast mDNS packets from one interface to other interfaces. This enables support for e.g. Apple Airplay devices
across multiple VLANs.
To enable mDNS repeater you need to configure at least two interfaces. To re- broadcast all mDNS packets from eth0
to eth1 and vice versa run:
mDNS repeater can be temporarily disabled without deleting the service using
Note: You can not run this in a VRRP setup, if multiple mDNS repeaters are launched in a subnet you will experience
the mDNS packet storm death!
VyOS utilizes accel-ppp to provide PPPoE server functionality. It can be used with local authentication or a connected
RADIUS server.
Note: Please be aware, due to an upstream bug, config changes/commits will restart the ppp daemon and will reset
existing PPPoE connections from connected users, in order to become effective.**
12.9.1 Configuration
The example below uses ACN as access-concentrator name, assigns an address from the pool 10.1.1.100-111, termi-
nates at the local endpoint 10.1.1.1 and serves requests only on eth1.
To use a radius server, you need to switch to authentication mode radius and of course need to specify an IP for the
server. You can have multiple RADIUS server configured, if you wish to achieve redundancy.
Certain vendors use broadcasts to identify their equipemnt within one ethernet segment. Unfortunately if you split
your network with multiple VLANs you loose the ability of identifying your equiment.
This is where “UDP broadcast relay” comes into play! It will forward received broadcasts to other configured net-
works.
Every UDP port which will be forward requires one unique ID. Currently we support 99 IDs!
Example #1: To forward all broadcast packets received on UDP port 1900 on eth3, eth4 or eth5 to all other interfaces
in this configuration.
Example #2: To Forward all broadcasts packets received on UDP port 6969 on eth3 or eth4 to the other interface in
this configuration.
Each broadcast relay instance can be individually disabled without deleting the configured node by using the following
command:
In addition you can also disable the whole service without removing the configuration by:
Note: You can run the UDP broadcast relay service on multiple routers connected to a subnet. There is NO UDP
broadcast relay packet storm!
12.11 SNMP
Simple Network Management Protocol (SNMP) is an Internet Standard protocol for collecting and organizing infor-
mation about managed devices on IP networks and for modifying that information to change device behavior. Devices
that typically support SNMP include cable modems, routers, switches, servers, workstations, printers, and more.
SNMP is widely used in network management for network monitoring. SNMP exposes management data in the form
of variables on the managed systems organized in a management information base (MIB) which describe the system
status and configuration. These variables can then be remotely queried (and, in some circumstances, manipulated) by
managing applications.
Three significant versions of SNMP have been developed and deployed. SNMPv1 is the original version of the proto-
col. More recent versions, SNMPv2c and SNMPv3, feature improvements in performance, flexibility and security.
SNMP is a component of the Internet Protocol Suite as defined by the Internet Engineering Task Force (IETF). It
consists of a set of standards for network management, including an application layer protocol, a database schema,
and a set of data objects.
In typical uses of SNMP, one or more administrative computers called managers have the task of monitoring or
managing a group of hosts or devices on a computer network. Each managed system executes a software component
called an agent which reports information via SNMP to the manager.
An SNMP-managed network consists of three key components:
• Managed devices
• Agent – software which runs on managed devices
• Network management station (NMS) – software which runs on the manager
A managed device is a network node that implements an SNMP interface that allows unidirectional (read-only) or
bidirectional (read and write) access to node-specific information. Managed devices exchange node-specific informa-
tion with the NMSs. Sometimes called network elements, the managed devices can be any type of device, including,
but not limited to, routers, access servers, switches, cable modems, bridges, hubs, IP telephones, IP video cameras,
computer hosts, and printers.
An agent is a network-management software module that resides on a managed device. An agent has local knowledge
of management information and translates that information to or from an SNMP-specific form.
A network management station executes applications that monitor and control managed devices. NMSs provide the
bulk of the processing and memory resources required for network management. One or more NMSs may exist on
any managed network.
VyOS itself supports SNMPv2 (version 2) and SNMPv3 (version 3) where the later is recommended because of
improved security (optional authentication and encryption).
12.11.3 SNMPv2
SNMPv2 is the original and most commonly used version. For authorizing clients, SNMP uses the concept of commu-
nities. Communities may have authorization set to read only (this is most common) or to read and write (this option is
not actively used in VyOS).
SNMP can work synchronously or asynchronously. In synchronous communication, the monitoring system queries
the router periodically. In asynchronous, the router sends notification to the “trap” (the monitoring host).
SNMPv2 does not support any authentication mechanisms, other than client source address, so you should specify
addresses of clients allowed to monitor the router. Note that SNMPv2 also supports no encryption and always sends
data in plain text.
Example
# Define a community
set service snmp community routers authorization ro
12.11.4 SNMPv3
SNMPv3 is an updated version that, among other things, supports encryption and cryptographic authentication of
clients.
Example
Note: SNMPv3 keys won’t we stored in plaintext. On commit the keys will be encrypted and the encrypted key is
based on the engineid!
12.12 SSH
Secure Shell (SSH) is a cryptographic network protocol for operating network services securely over an unsecured
network.[1] The standard TCP port for SSH is 22. The best known example application is for remote login to computer
systems by users.
SSH provides a secure channel over an unsecured network in a client-server architecture, connecting an SSH client
application with an SSH server. Common applications include remote command-line login and remote command
execution, but any network service can be secured with SSH. The protocol specification distinguishes between two
major versions, referred to as SSH-1 and SSH-2.
The most visible application of the protocol is for access to shell accounts on Unix-like operating systems, but it sees
some limited use on Windows as well. In 2015, Microsoft announced that they would include native support for SSH
in a future release.
SSH was designed as a replacement for Telnet and for unsecured remote shell protocols such as the Berkeley rlogin,
rsh, and rexec protocols. Those protocols send information, notably passwords, in plaintext, rendering them sus-
ceptible to interception and disclosure using packet analysis. The encryption used by SSH is intended to provide
confidentiality and integrity of data over an unsecured network, such as the Internet.
12.12.1 Configuration
Enabling SSH only requires you to add service ssh port NN, where ‘NN’ is the port you want SSH to listen
on. By default, SSH runs on port 22.
Options
• Listening address - Specify the IPv4/IPv6 listening address for connection requests. Multiple
listen-address nodes can be defined.
set service ssh listen-address <address>
• Allow root login, this can be set to allow root logins on SSH connections, however it is not advisable to use
this setting as this bears serious security risks. The default system user posesses all required privileges.
set service ssh allow-root
• Allowed ciphers - A number of allowed ciphers can be specified, use multiple occurances to allow multiple
ciphers.
set service ssh ciphers <cipher>
Available ciphers:
• 3des-cbc
• aes128-cbc
• aes192-cbc
• aes256-cbc
• aes128-ctr
• aes192-ctr
• aes256-ctr
• arcfour128
• arcfour256
• arcfour
• blowfish-cbc
• cast128-cbc
• Disable password authentication - If SSH key authentication is set up, password-based user authetication can be
disabled. This hardens security!
set service ssh disable-password-authentication
• Disable host validation - Disable the host validation through reverse DNS lookups.
set service ssh disable-host-validation
• MAC algorithms - Specifies the available MAC (message authentication code) algorithms. The MAC algorithm
is used in protocol version 2 for data integrity protection. Multiple algorithms can be entered.
set service ssh macs <macs>
Supported MACs:
• hmac-md5
• hmac-md5-96
• hmac-ripemd160
• hmac-sha1
• hmac-sha1-96
• hmac-sha2-256
• hmac-sha2-512
• [email protected]
• [email protected]
• [email protected]
• [email protected]
• [email protected]
• [email protected]
• [email protected]
• [email protected]
• [email protected]
• [email protected]
Key Authentication
It is highly recommended to use SSH Key authentication. By default there is only one user (vyos), and you can assign
any number of keys to that user. You can generate a ssh key with the ssh-keygen command on your local machine,
which will (by default) save it as ~/.ssh/id_rsa.pub which is in three parts:
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAA...VByBD5lKwEWB username@host.
example.com
Only the type (ssh-rsa) and the key (AAAB3N...) are used. Note that the key will usually be several hundred
characters long, and you will need to copy and paste it. Some terminal emulators may accidentally split this over
several lines. Be attentive when you paste it that it only pastes as a single line. The third part is simply an identifier,
and is for your own reference.
Assign SSH Key to user
Under the user (in this example, vyos), add the public key and the type. The identifier is simply a string that is
relevant to you.
set system login user vyos authentication public-keys 'identifier' key "AAAAB3Nz...."
set system login user vyos authentication public-keys 'identifier' type ssh-rsa"
You can assign multiple keys to the same user by changing the identifier. In the following example, both Unicron and
xrobau will be able to SSH into VyOS as the vyos user using their own keys.
set system login user vyos authentication public-keys 'Unicron' key "AAAAB3Nz...."
set system login user vyos authentication public-keys 'Unicron' type ssh-rsa
set system login user vyos authentication public-keys 'xrobau' key "AAAAQ39x...."
set system login user vyos authentication public-keys 'xrobau' type ssh-rsa
12.13 TFTP
Trivial File Transfer Protocol (TFTP) is a simple lockstep File Transfer Protocol which allows a client to get a file
from or put a file onto a remote host. One of its primary uses is in the early stages of nodes booting from a local area
network. TFTP has been used for this application because it is very simple to implement.
12.13.1 Example
# If you want to enable uploads, else TFTP server will act as read-only (optional)
set service tftp-server allow-upload
Note: Choose your directory location carefully or you will loose the content on image upgrades. Any directory
under /config is save at this will be migrated.
12.14 Webproxy
The proxy service in VyOS is based on Squid3 and some related modules.
Squid is a caching and forwarding HTTP web proxy. It has a wide variety of uses, including speeding up a web
server by caching repeated requests, caching web, DNS and other computer network lookups for a group of people
sharing network resources, and aiding security by filtering traffic. Although primarily used for HTTP and FTP, Squid
includes limited support for several other protocols including Internet Gopher, SSL,[6] TLS and HTTPS. Squid does
not support the SOCKS protocol.
All examples here assumes that your inside ip address is 192.168.0.1. Replace with your own where applicable.
URL Filtering is provided by Squidguard.
12.14.1 Configuration
# By default it will listen to port 3128. If you wan't something else you have to
˓→define that.
# By default the transparent proxy on that interface is enabled. To disable that you
˓→simply
Options
If you wan’t to use existing blacklists you have to create/download a database first. Otherwise you will not be able to
commit the config changes.
vyos@vyos# commit
[ service webproxy ]
Warning: no blacklists installed
Unknown block-category [ads] for policy [default]
12.14.3 Authentication
TBD: https://wiki.vyos.net/wiki/Web_proxy_LDAP_authentication
Some services don’t work correctly when being handled via a web proxy. So sometimes it is useful to bypass a
transparent proxy:
• To bypass the proxy for every request that is directed to a specific destination:
set service webproxy whitelist destination-address 1.2.3.4
set service webproxy whitelist destination-address 4.5.6.0/24
• To bypass the proxy for every request that is coming from a specific source:
set service webproxy whitelist source-address 192.168.1.2
set service webproxy whitelist source-address 192.168.2.0/24
(This can be useful when a called service has many and/or often changing destination addresses - e.g. Netflix.)
System
After a basic system setup by setting up Interface Addresses, VyOS should be ready for further configuration which is
described in this chapter.
Event handler allows you to execute scripts when a string that matches a regex appears in a text stream (e.g. log file).
It uses “feeds” (output of commands, or a named pipes) and “policies” that define what to execute if a regex is matched.
system
event-handler
feed <name>
description <feed description>
policy <policy name>
source
preset
syslog # Use the syslog logs for feed
custom
command <command to execute> # E.g. "tail -f /var/log/somelogfile"
named-pipe <path to a names pipe>
policy <policy name>
description <policy description>
event <event name>
description <event description>
pattern <regex>
run <command to run>
In this small example a script runs every time a login failed and an interface goes down
121
VyOS Documentation, Release 1.2.0-beta
NetFlow is a protocol originating from Cisco Systems. It works on level3. VyOS supports version 1, 5 and 9
NetFlow v5 example:
This section describes the system’s host information and how to configure them, it covers the following topics:
• Host name
• Domain
• IP address
• Default gateway
• Aliases
A hostname is the label (name) assigned to a network device (a host) on a network and is used to distinguish one
device from another on specific networks or over the internet.
Set a system host name:
A domainname is the label (name) assigned to a computer network and is thus unique!
Set the system’s domain:
Show domain:
How to assign IPs to interfaces is described in chapter Interface Addresses. This section shows how to statically map
a system IP to its host name for local (meaning on this VyOS instance) DNS resolution:
Example: Create a static mapping between the system’s hostname RT01 and IP address 10.20.30.41:
set system static-host-mapping host-name RT01 inet 10.20.30.41
commit
show system static-host-mapping
host-name RT01 {
inet 10.20.30.41
}
Aliases
Show aliases:
show system static-mapping
Delete alias:
delete system static-host-mapping host-name <hostname> alias <alias>
In the past (VyOS 1.1.8) used a gateway-address configured in the system tree (set system gateway-address <IP
address>) this is no longer supported and existing configurations are migrated to the new CLI commands.
It is replaced by inserting a static route into the routing table using:
set protocols static route 0.0.0.0/0 next-hop <gateway ip>
The default vyos user account, as well as newly created user accounts, have all capabilities to configure the system. All
accounts have sudo capabilities and therefore can operate as root on the system. Setting the level to admin is optional,
all accounts on the system will have admin privileges.
The command:
user jsmith {
authentication {
encrypted-password $6$0OQHjuQ8M$AYXVn7jufdfqPrSk4/
˓→XXsDBw99JBtNsETkQKDgVLptXogHA2bU9BWlvViOFPBoFxIi.iqjqrvsQdQ./cfiiPT.
plaintext-password ""
}
full-name "Johan Smith"
level admin
}
The following command will load the public key dev.pub for user jsmith
Note: This requires uploading the dev.pub public key to the VyOS router first. As an alternative you can also load the
SSH public key directly from a remote system:
13.5 Syslog
Per default VyOSs has minimal syslog logging enabled which is stored and rotated locally. Errors will be always
logged to a local file, which includes local7 error messages, emergency messages will be sent to the console, too.
To configure syslog, you need to switch into configuration mode.
Use the [tab] function to display all facilities and levels which can be configured.
Logging to a custom file, rotation size and the number of rotate files left on the system can be configured.
The very same setting can be applied to the global configuration, to modify the defaults for the global logging.
Logging to a remote host leaves the local logging configuration intact, it can be configured in parallel. You can log ro
multiple hosts at the same time, using either TCP or UDP. The default is sending the messages via UDP.
UDP
TCP
If logging to a local useraccount is configured, all defined log messages are display on the console if the local user is
logged in, if the user is not logged in, no messages are being displayed.
Task scheduler — allows scheduled task execution. Note that scripts excecuted this way are executed as root user -
this may be dangerous.
Together with Command scripting this can be used for automating configuration.
system
task-scheduler
task <name>
cron-spec <UNIX cron time spec>
executable
arguments <arguments string>
path <path to executable>
interval
<int32>[mhd]
13.6.1 Interval
13.6.2 Example
system
task-scheduler
task mytask
interval 2h
executable
path /config/scripts/mytask
arguments "arg1 arg2 arg3"
task anothertask
cron-spec "* * * 1 *"
executable
path /config/scripts/anothertask
The following changes the number of commit revisions. In the default settings, 20 revisions are stored locally.
If you want to save all config changes to a remote destination. Set the commit-archive location. Every time a commit
is successfully the config.boot file will be copied to the defined destinations.
vyos@vyos-R1# commit
Archiving config...
tftp://10.0.0.2 OK
[edit]
vyos@vyos-R1#
High availability
VRRP (Virtual Redundancy Protocol) provides active/backup redundancy for routers. Every VRRP router has a phys-
ical IP/IPv6 address, and a virtual address. On startup, routers elect the master, and the router with the highest priority
becomes the master and assigns the virtual address to its interface. All routers with lower priorities become backup
routers. The master then starts sending keepalive packets to notify other routers that it’s available. If the master fails
and stops sending keepalive packets, router with the next highest priority becomes the new master and takes over the
virtual address.
VRRP keepalive packets use multicast, and VRRP setups are limited to a single datalink layer segment. You can
setup multiple VRRP groups (also called virtual routers). Virtual routers are identified by a VRID (Virtual Router
IDentifier). If you setup multiple groups on the same interface, their VRIDs must be unique, but it’s possible (even if
not recommended for readability reasons) to use duplicate VRIDs on different interfaces.
VRRP groups are created with the set high-availability vrrp group $GROUP_NAME commands. The
required parameters are interface, vrid, and virtual-address.
mininmal config
You can verify your VRRP group status with the operational mode run show vrrp command:
129
VyOS Documentation, Release 1.2.0-beta
The virtual-address parameter can be either an IPv4 or IPv6 address, but you cannot mix IPv4 and IPv6 in the
same group, and will need to create groups with different VRIDs specially for IPv4 and IPv6.
A disabled group will be removed from the VRRP process and your router will not participate in VRRP for that VRID.
It will disappear from operational mode commands output, rather than enter the backup state.
The priority must be an interger number from 1 to 255. Higher priority value increases router’s precedence in the
master elections.
14.5 Preemption
VRRP can use two modes: preemptive and non-preemptive. In the preemptive mode, if a router with a higher priority
fails and then comes back, routers with lower priority will give up their master status. In non-preemptive mode, the
newly elected master will keep the master status and the virtual address indenfinitely.
By default VRRP uses preemption. You can disable it with the “no-preempt” option:
You can also configure the time interval for preemption with the “preempt-delay” option. For example, to set the
higher priority router to take over in 180 seconds, use:
By default VRRP uses multicast packets. If your network does not support multicast for whatever reason, you can
make VRRP use unicast communication instead.
14.7 Scripting
VRRP functionality can be extended with scripts. VyOS supports two kinds of scripts: health check scripts and
transition scripts. Health check scripts execute custom checks in addition to the master router reachability. Transition
scripts are executed when VRRP state changes from master to backup or fault and vice versa and can be used to enable
or disable certain services, for example.
This setup will make the VRRP process execute the /config/scripts/vrrp-check.sh script every 60
seconds, and transition the group to the fault state if it fails (i.e. exits with non-zero status) three times:
Transition scripts can help you implement various fixups, such as starting and stopping services, or even modifying
the VyOS config on VRRP transition. This setup will make the VRRP process execute the /config/scripts/
vrrp-fail.sh with argument Foo when VRRP fails, and the /config/scripts/vrrp-master.sh when
the router becomes the master:
Clustering
VyOS supports multicast and unicast clustering. Multicast is default and to use the unicast method you can add the
peer directive to the interface with the ip of the other cluster member.
In the example below SSH is clustered between two nodes with the unicast method.
cluster {
dead-interval 20000
group cluster {
auto-failback false
primary vyos
secondary vyos2
service ssh
service 192.168.0.123/24/eth0
}
interface eth0 {
peer 192.168.0.121
}
keepalive-interval 5000
monitor-dead-interval 20000
pre-shared-secret S3cr#t
}
133
VyOS Documentation, Release 1.2.0-beta
The VyOS image-based installation is implemented by creating a directory for each image on the storage device
selected during the install process.
The directory structure of the boot device:
/
/boot
/boot/grub
/boot/1.2.0-rolling+201810021347
The image directory contains the system kernel, a compressed image of the root filesystem for the OS, and a directory
for persistent storage, such as configuration.
On boot, the system will extract the OS image into memory and mount the appropriate live-rw sub-directories to
provide persistent storage system configuration.
This process allows for a system to always boot to a known working state, as the OS image is fixed and non-persistent.
It also allows for multiple releases of VyOS to be installed on the same storage device.
The image can be selected manually at boot if needed, but the system will otherwise boot the image configured to be
the default.
The default boot image can be set using the set system image default-boot command in operational mode.
A list of available images can be shown using the show system image command in operational mode.
135
VyOS Documentation, Release 1.2.0-beta
vyos@vyos:~$
Images no longer needed can be removed using the delete system image command.
Finally, new system images can be added using the add system image command. The add image command will extract
the image from the release ISO (either on the local filesystem or remotely if a URL is provided). The image install
process will prompt you to use the current system configuration and SSH security keys, allowing for the new image to
boot using the current configuration.
Note: Rolling releases are not GPG signed, only the real release build will have a proper GPG signature.
Note: VyOS configuration is associated to each image, and each image has a unique copy of its configuration. This
is different than a traditional network router where the configuration is shared across all images.
If you need some files from a previous images - take a look inside a /live directory.
Command scripting
VyOS supports executing configuration and operational commands non-interactively from shell scripts.
To include VyOS-specific functions and aliases you need to source /opt/vyatta/etc/functions/
script-template files at the top of your script.
#!/bin/vbash
source /opt/vyatta/etc/functions/script-template
exit
Configuration commands are executed just like from a normal config session.
For example, if you want to disable a BGP peer on VRRP transition to backup:
#!/bin/vbash
source /opt/vyatta/etc/functions/script-template
configure
commit
exit
Unlike a normal configuration sessions, all operational commands must be prepended with run, even if you haven’t
created a session with configure.
137
VyOS Documentation, Release 1.2.0-beta
#!/bin/vbash
source /opt/vyatta/etc/functions/script-template
exit
If you want to script the configs in a language other than bash you can have your script output commands and then
source them in a bash script.
Here is a simple example:
#!/usr/bin/env python
print "delete firewall group address-group somehosts"
print "set firewall group address-group somehosts address '1.1.1.1'"
print "set firewall group address-group somehosts address '1.1.1.2'"
#!bin/vbash
source /opt/vyatta/etc/functions/script-template
configure
source <(/config/scripts/setfirewallgroup.py)
commit
There is a pitfall when working with configuration scripts. It is tempting to call configuration scripts with “sudo” (i.e.,
temporary root permissions), because that’s the common way on most Linux platforms to call system commands.
On VyOS this will cause the following problem: After modifying the configuration via script like this once, it is not
possible to manually modify the config anymore:
To avoid these problems, the proper way is to call a script with the vyattacfg group, e.g., by using the sg (switch
group) command:
sg vyattacfg -c ./myscript.sh
To make sure that a script is not accidentally called without the vyattacfg group, the script can be safeguarded like
this:
Appendix A - Troubleshooting
Sometimes things break or don’t work as expected. This section describes several troubleshooting tools provided by
VyOS that can help when something goes wrong.
Verifying connectivity can be done with the familiar ping and traceroute commands. The options for each are shown
(the options for each command were displayed using the built-in help as described in the Command-Line Interface
section and are omitted from the output here):
vyos@vyos:~$ ping
Possible completions:
<hostname> Send Internet Control Message Protocol (ICMP) echo request
<x.x.x.x>
<h:h:h:h:h:h:h:h>
141
VyOS Documentation, Release 1.2.0-beta
vyos@vyos:~$ traceroute
Possible completions:
<hostname> Track network path to specified node
<x.x.x.x>
<h:h:h:h:h:h:h:h>
ipv4 Track network path to <hostname|IPv4 address>
ipv6 Track network path to <hostname|IPv6 address>
However, another tool, mtr, is available which combines ping and traceroute into a single tool. An example of its
output is shown:
My traceroute [v0.85]
vyos (0.0.0.0)
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. 10.11.110.4 0.0% 34 0.5 0.5 0.4 0.8 0.1
2. 10.62.255.184 0.0% 34 1.1 1.0 0.9 1.4 0.1
3. 10.62.255.71 0.0% 34 1.4 1.4 1.3 2.0 0.1
4. 10.62.212.12 0.0% 34 1.6 1.6 1.6 1.7 0.0
Note: The output of mtr consumes the screen and will replace your command prompt.
Several options are available for changing the display output. Press h to invoke the built in help system. To quit, just
press q and you’ll be returned to the VyOS command prompt.
18.2 Monitoring
It’s possible to monitor network traffic, either at the flow level or protocol level. This can be useful when troubleshoot-
ing a variety of protocols and configurations. The following interface types can be monitored:
To monitor traffic flows, issue the monitor interfaces <type> <name> flow command, replacing
<type> and <name> with your desired interface type and name, respectively. Output looks like the following:
12.5Kb 25.0Kb 37.5Kb 50.0Kb
˓→ 62.5Kb
??????????????????????????????????????????????????????????????????????????????????????
˓→??????????????
Several options are available for changing the display output. Press h to invoke the built in help system. To quit, just
press q and you’ll be returned to the VyOS command prompt.
To monitor interface traffic, issue the monitor interfaces <type> <name> traffic command, replac-
ing <type> and <name> with your desired interface type and name, respectively. This command invokes the familiar
tshark utility and the following options are available:
vyos@vyos:~$ monitor interfaces ethernet eth0 traffic
Possible completions:
<Enter> Execute the current command
detail Monitor detailed traffic for the specified ethernet interface
filter Monitor filtered traffic for the specified ethernet interface
(continues on next page)
To quit monitoring, press Ctrl-c and you’ll be returned to the VyOS command prompt. The detail keyword provides
verbose output of the traffic seen on the monitored interface. The filter keyword accepts valid PCAP filter expressions,
enclosed in single or double quotes (e.g. “port 25” or “port 161 and udp”). The save keyword allows you to save the
traffic dump to a file. The unlimited keyword is used to specify that an unlimited number of packets can be captured
(by default, 1,000 packets are captured and you’re returned to the VyOS command prompt).
to take a quick view on the used bandwith of an interface use the monitor bandwith command
eth0
˓→ bmon 3.5
Interfaces RX bps pps % TX bps pps %
>eth0 141B 2 272B 1
B (RX Bytes/second)
198.00 .|....|.....................................................
165.00 .|....|.....................................................
132.00 ||..|.|.....................................................
99.00 ||..|.|.....................................................
66.00 |||||||.....................................................
33.00 |||||||.....................................................
1 5 10 15 20 25 30 35 40 45 50 55 60
KiB (TX Bytes/second)
3.67 ......|.....................................................
3.06 ......|.....................................................
2.45 ......|.....................................................
1.84 ......|.....................................................
1.22 ......|.....................................................
0.61 :::::||.....................................................
1 5 10 15 20 25 30 35 40 45 50 55 60
To take a look on the network bandwith between two nodes, the monitor bandwidth-test command is used to
run iperf.
The accept command open a listen iperf server on TCP Port 5001
The initiate command conncet to this server.
The command follow the same logic as the set command in configuration mode.
19.1.1 Configuration
147
VyOS Documentation, Release 1.2.0-beta
This example is verified with a Cisco 2811 platform running IOS 15.1(4)M9 and VyOS 1.1.7 (helium) up to VyOS
1.2 (Crux).
Cisco IOS Software, 2800 Software (C2800NM-ADVENTERPRISEK9-M), Version 15.1(4)M9,
˓→RELEASE SOFTWARE (fc3)
See the the full Command tree in Operational mode and Configuration mode
Operational mode allows for commands to perform operational system tasks and view system and service status. After
this is the first view after the login. Please see Command-Line Interface for navigation in the CLI
vyos@vyos:~$ [tab]
Possible completions:
add Add an object to a service
clear Clear system information
clone Clone an object
configure Enter configure mode
connect Establish a connection
copy Copy an object
delete Delete an object
disconnect Take down a connection
force Force an operation
format Format a device
generate Generate an object
install Install a new system
monitor Monitor system information
ping Send IPv4 or IPv6 ICMP (Internet Control Message Protocol) echo
˓→requests
151
VyOS Documentation, Release 1.2.0-beta
20.1.1 Add
20.1.2 Clear
20.1.3 Clone
The clone command allows you to clone a configuration from a system image to another one, or from the running
config to another system image. To clone the running config to a system image:
20.1.4 Configure
vyos@vyos:~$ configure
[edit]
vyos@vyos#
20.1.5 Connect
The connect command allows you to bring up a connection oriented interface, like a pppoe interface.
20.1.6 Copy
The copy command allows you to copy a file to your running config or over images.
It can look like this example:
20.1.7 Delete
20.1.8 Disconnect
The disconnect command allows you to take down a connection oriented interface, like a pppoe interface.
20.1.9 Force
20.1.10 Format
The format command allows you to format a disk the same way as another one.
20.1.11 Generate
20.1.12 Install
The install command allows you to install the system image on the disk.
install image
20.1.13 Monitor
20.1.14 Ping
The ping command allows you to send an ICMP-EchoRequest packet and display the ICMP-EchoReply received.
20.1.15 Poweroff
The poweroff command allows you to properly shut down the VyOS instance. Without any modifier, the command
is executed immediately.
<Enter> Execute the current command
at Poweroff at a specific time
cancel Cancel a pending poweroff
in Poweroff in X minutes
now Poweroff the system without confirmation
20.1.16 Reboot
The reboot command allows you to properly restart the VyOS instance. Without any modifier, the command is
executed immediately.
<Enter> Execute the current command
at Poweroff at a specific time
cancel Cancel a pending poweroff
in Poweroff in X minutes
now Poweroff the system without confirmation
20.1.17 Release
20.1.18 Rename
20.1.19 Renew
20.1.20 Reset
20.1.21 Restart
20.1.22 Set
20.1.23 Show
20.1.24 Telnet
In the past the telnet command allowed you to connect remotely to another device using the telnet protocol. Telnet
is unencrypted and should not use anymore. But its nice to test if an TCP Port to a host is open.
20.1.25 Traceroute
The traceroute command allows you to trace the path taken to a particular device.
<hostname> Track network path to specified node
<x.x.x.x>
<h:h:h:h:h:h:h:h>
ipv4 Track network path to <hostname|IPv4 address>
ipv6 Track network path to <hostname|IPv6 address>
20.1.26 Update
20.2.1 Confirm
20.2.2 Comment
The comment commands allow you to insert a comment above the current configuration section. The command
cannot be used at the top of the configuration hierarchy, only on subsections. Comments needs to be commited, just
like other config changes.
To add a comment to a section, while being already at the proper section level:
[edit <section>]
vyos@vyos# comment "Type Comment Here"
[edit]
vyos@vyos# comment <section> "Type Comment Here"
[edit <section>]
vyos@vyos# comment ""
Examples
[edit]
vyos@vyos# edit interfaces
[edit interfaces]
vyos@vyos# comment "Here is a comment"
[edit interfaces]
vyos@vyos# commit
[edit]
vyos@vyos# show
/* Here is a comment */
interfaces {
ethernet eth0 {
[...]
An important thing to note is that since the comment is added on top of the section, it will not appear if the show
<section> command is used. With the above example, the show interfaces command would return starting
after the “interfaces {” line, hiding the comment:
[edit]
vyos@vyos# show interfaces
ethernet eth0 {
[...]
[edit]
vyos@vyos# comment interfaces "test"
The comment can be added to any node that already exists, even if it’s multiple levels lower:
[edit]
vyos@vyos# comment interfaces ethernet eth0 vif 222 address "Far down comment"
20.2.3 Commit
The commit command commits the proposed changes to the configuration file. Every changes done in the configu-
ration session is only applied when the configuration is committed. To view the changes that will be applied, use the
show command. To discard the changes without committing, use the discard command. The commit command
doesn’t save the configuration, you need to manually use the save command.
The confirm keyword can be added, see commit-confirm. A comment can be entered, it will appear in the commit
log.
[edit]
vyos@vyos# commit
Possible completions:
<Enter> Commit working configuration
comment Comment for commit log
20.2.4 Commit-confirm
The commit-confirm command commits the proposed changes to the configuration file and starts a timer. If the
confirm command is not entered before the timer expiration, the configuration will be rolled back and VyOS will
reboot. The default timer value is 10 minutes, but a custom value can be entered.
[edit]
vyos@vyos# commit-confirm
Possible completions:
<Enter> Commit, rollback/reboot in 10 minutes if no confirm
<N> Commit, rollback/reboot in N minutes if no confirm
comment Comment for commit log
20.2.5 Compare
VyOS maintains backups of previous configurations. To compare configuration revisions in configuration mode, use
the compare command:
[edit]
vyos@vyos# compare
Possible completions:
<Enter> Compare working & active configurations
saved Compare working & saved configurations
<N> Compare working with revision N
<N> <M> Compare revision N with M
Revisions:
0 2019-03-20 20:57:22 root by boot-config-loader
1 2019-03-15 20:00:04 root by boot-config-loader
2 2019-03-05 01:58:39 vyos by cli
3 2019-03-05 01:54:59 vyos by cli
4 2019-03-05 01:53:08 vyos by cli
5 2019-03-05 01:52:21 vyos by cli
6 2019-02-24 21:01:24 root by boot-config-loader
7 2019-02-21 22:00:12 vyos by cli
8 2019-02-21 21:56:49 vyos by cli
20.2.6 Copy
20.2.7 Delete
20.2.8 Discard
[edit]
vyos@vyos# discard
20.2.9 Edit
The edit command allows you to navigate down into the configuration tree. To get back to an upper level, use the
up command or use the top command to get back to the upper most level. The [edit] text displays where the user
is located in the configuration tree.
[edit]
vyos@vyos# edit interfaces
[edit interfaces]
vyos@vyos# edit ethernet eth0
[edit interfaces ethernet eth0]
20.2.10 Exit
The exit command exits the current configuration mode. If the current configuration level isn’t the top-most, then
the configuration level is put back to the top-most level. If the configuration level is at the top-most level, then it
exits the configuration mode and returns to operational mode. The exit command cannot be used if uncommitted
changes exists in the configuration file. To exit with uncommitted changes, you either need to use the exit discard
command or you need to commit the changes before exiting. The exit command doesn’t save the configuration, only
the save command does. A warning will be given when exiting with unsaved changes. Using the exit command in
operational mode will logout the session.
Exiting from a configuration level:
[edit interfaces ethernet eth0]
vyos@vyos# exit
[edit]
vyos@vyos#
20.2.11 Load
The load command load a configuration from a local or remote file. You have to be use commit to make the change
active
<Enter> Load from system config file
<file> Load from file on local machine
scp://<user>:<passwd>@<host>/<file> Load from file on remote machine
sftp://<user>:<passwd>@<host>/<file> Load from file on remote machine
ftp://<user>:<passwd>@<host>/<file> Load from file on remote machine
http://<host>/<file> Load from file on remote machine
(continues on next page)
[edit]
vyos@vyos# load
Loading configuration from '/config/config.boot'...
20.2.12 Loadkey
20.2.13 Merge
The merge command merge the config from a local or remote file with the running config.
In the example below exist a default-firewall.config file with some common firewall rules you saved earlier.
[edit]
vyos@vyos# show firewall
Configuration under specified path is empty
[edit]
vyos@vyos# merge default-firewall.config
Loading configuration from '/config/default-firewall.config'...
20.2.14 Rename
20.2.15 Rollback
You can rollback configuration using the rollback command, however this command will currently trigger a system
reboot. Use the compare command to verify the configuration you want to rollback to.
vyos@vyos# compare 1
[edit system]
>host-name vyos-1
[edit]
vyos@vyos# rollback 1
Proceed with reboot? [confirm][y]
20.2.16 Run
The run command allows you to execute any operational mode commands without exiting the configuration session.
[edit]
vyos@vyos# run show interfaces
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface IP Address S/L Description
--------- ---------- --- -----------
eth0 10.1.1.1/24 u/u
20.2.17 Save
The save command saves the current configuration to non-volatile storage. VyOS also supports saving and loading
configuration remotely using SCP, FTP, or TFTP.
20.2.18 Set
[edit]
vyos@vyos# set protocols static route 0.0.0.0/0 next-hop 192.168.1.1
20.2.19 Show
The show command in the configuration mode displays the configuration and show uncommitted changes.
Show the hole config, the address and description of eth1 is moving to vlan 2 if you commit the changes.
[edit]
vyos@vyos# show
interfaces {
dummy dum0 {
address 10.3.3.3/24
}
ethernet eth0 {
address dhcp
(continues on next page)
For Bug Reports and Feature Requests please take a look at Phabricator here:
https://phabricator.vyos.net
To create a Bugreport use the quick link in the left side under the specific project.
Please think about the next points:
To send a Feature Request please search in Phabricator if there is already a Feature Request. You can enhance it or if
you don’t find one create a new one by use the quick link in the left side under the specific project.
167
VyOS Documentation, Release 1.2.0-beta
Development
169
VyOS Documentation, Release 1.2.0-beta
VyOS CLI
The bash completion in VyOS is defined in templates. Templates are text files stored in a directory tree, where
directory names define command names, and template files define command behaviour. Befor VyOS 1.2.x this files
were created by hand. After a complex redesing process the new style template are in XML.
XML interface definitions for VyOS come with a RelaxNG schema and are located here vyos-1x
This schema is a slightly modified schema from VyConf alias VyOS 2.0
So VyOS 1.2.x interface definitions will be reusable in Nextgen VyOS Versions with very minimal changes.
The great thing about schemas is not only that people can know the complete grammar for certain, but also that it can
be automatically verified. The scripts/build-command-templates script that converts the XML definitions to old style
templates also verifies them against the schema, so a bad definition will cause the package build to fail. I do agree that
the format is verbose, but there is no other format now that would allow this. Besides, a specialized XML editor can
alleviate the issue with verbosity.
<?xml version="1.0"?>
<!-- Cron configuration -->
<interfaceDefinition>
<node name="system">
<children>
<node name="task-scheduler">
<properties>
<help>Task scheduler settings</help>
</properties>
<children>
<tagNode name="task" owner="${vyos_conf_scripts_dir}/task_scheduler.py">
<properties>
(continues on next page)
171
VyOS Documentation, Release 1.2.0-beta
Command definitions are purely declarative, and cannot contain any logic. All logic for generating config files for
target applications, restarting services and so on is implemented in configuration scripts instead.
Use of numbers
Use of numbers in command names should be avoided unless a number is a part of a protocol name or similar. Thus,
“protocols ospfv3” is perfectly fine, but something like “server-1” is questionable at best.
To ensure uniform look and feel, and improve readability, we should follow a set of guidelines consistently.
The first word of every help string must be capitalized. There must not be a period at the end of help strings.
Rationale: this seems to be the unwritten standard in network device CLIs, and a good aesthetic compromise.
Examples:
• Good: “Frobnication algorithm”
• Bad: “frobnication algorithm”
• Bad: “Frobnication algorithm.”
• Horrible: “frobnication algorithm.”
• Bad: radius (unless it’s about the distance between a center of a circle and any of its points)
Some abbreviations are traditionally written in mixed case. Generally, if it contains words “over” or “version”, the
letter should be lowercase. If there’s an accepted spelling (especially if defined by an RFC or another standard), it
must be followed.
Examples:
• Good: PPPoE, IPsec
• Bad: PPPOE, IPSEC
• Bad: pppoe, ipsec
Use of verbs
Prefer infinitives
23.3 Mapping from the old node.def style to the new XML definitions
23.3. Mapping from the old node.def style to the new XML definitions 175
VyOS Documentation, Release 1.2.0-beta
The switch to the Python programming language for new code is not merely a change of the language, but a chance to
rethink and improve the programming approach.
Let’s face it: VyOS is full of spaghetti code where logic for reading the VyOS config, generating daemon configs,
and restarting processes is all mixed up. Python (or any other language, for that matter) does not provide automatic
protection from bad design, so we need to also devise design guidelines and follow them to keep the system extensible
and maintainable.
import sys
def get_config():
vc = Config()
# Convert the VyOS config to an abstract internal representation
config = ...
return config
def verify(config):
# Verify that configuration is valid
if invalid:
raise ConfigError("Descriptive message")
return True
def generate(config):
# Generate daemon configs
pass
177
VyOS Documentation, Release 1.2.0-beta
try:
config = get_config()
verify(config)
except ConfigError as e:
print(e)
sys.exit(1)
The get_config() function must convert the VyOS config to an abstract internal representation. No other function is
allowed to call vyos.config.Config object methods directly. The rationale for it is that when config reads are mixed
with other logic, it’s very hard to change the config syntax since you need to weed out every occurence of the old
syntax. If syntax-specific code is confined to a single function, the rest of the code can be left untouched as long as the
internal representation remains compatible.
Another advantage is testability of the code. Mocking the entire config subsystem is hard, while constructing an
internal representation by hand is way simpler.
The verify() function takes an internal representation of the config and checks if it’s valid, otherwise it must raise
VyOSError with an error message that describes the problem and possibly suggests how to fix it. It must not make
any changes to the system. The rationale for it is again testability and, in the future when the config backend is ready
and every script is rewritten in this fashion, ability to execute commit dry run (“commit test” like in JunOS) and abort
commit before making any changes to the system if an error is found in any component.
The generate() function generates config files for system components.
The apply() function applies the generated configuration to the live system. It should use non-disruptive reload
whenever possible. It may execute disruptive operations such as daemon process restart if a particular component
does not support non-disruptive reload, or when the expected service degradation is minimal (for example, in case of
auxillary services such as LLDPd). In case of high impact services such as VPN daemon and routing protocols, when
non-disruptive reload is supported for some but not all types of configuration changes, scripts authors should make
effort to determine if a configuration change can be done in a non-disruptive way and only resort to disruptive restart
if it cannot be avoided.
Unless absolutely necessary, configuration scripts should not modify the active configuration of system components
directly. Whenever at all possible, scripts should generate a configuration file or files that can be applied with a single
command such as reloading a service through systemd/SysV init. Inserting statements one by one is particularly
discouraged, for example, when configuring netfilter rules, saving them to a file and loading it with iptables-restore
should always be preferred to executing iptables directly.
The apply() and generate() functions may raise ConfigError if, for example, the daemon failed to start with the
updated config. It shouldn’t be a substitute for proper config checking in the verify() function. All reasonable effort
should be made to verify that generated configuration is valid and will be accepted by the daemon, including, when
necessary, cross-checks with other VyOS configuration subtrees.
Exceptions, including VyOSError (which is raised by vyos.config.Config on improper config operations, such as trying
to use list_nodes() on a non-tag node) should not be silenced or caught and re-raised as config error. Sure this will
not look pretty on user’s screen, but it will make way better bug reports, and help users (and most VyOS users are IT
professionals) do their own debugging as well.
24.2.1 Language
Python 3 shall be used. How long can we keep Python 2 alive anyway?
No considerations for Python 2 compatibility should be taken.
24.2.2 Formatting
Template processor should be used for generating config files. Built-in string formatting may be used for simple
line-oriented formats where every line is self-contained, such as iptables rules. Template processor must be used for
structured, multi-line formats such as those used by ISC DHCPd.
The default template processor for VyOS code is jinja2.
When modifying the source code, remember these rules of the legacy elimination campaign:
• No new features in Perl
• No old style command definitions
• No code incompatible with Python3