diff options
| -rw-r--r-- | docs/_static/images/vrf-example-topology-01.png | bin | 0 -> 32567 bytes | |||
| -rw-r--r-- | docs/_static/images/wireguard_site2site_diagram.jpg | bin | 0 -> 21630 bytes | |||
| -rw-r--r-- | docs/automation/cloud-init.rst | 72 | ||||
| -rw-r--r-- | docs/configuration/interfaces/index.rst | 2 | ||||
| -rw-r--r-- | docs/configuration/interfaces/wireguard.rst | 162 | ||||
| -rw-r--r-- | docs/configuration/policy/index.rst | 16 | ||||
| -rw-r--r-- | docs/configuration/protocols/static.rst | 18 | ||||
| -rw-r--r-- | docs/configuration/vpn/index.rst | 3 | ||||
| -rw-r--r-- | docs/configuration/vrf/index.rst | 126 |
9 files changed, 312 insertions, 87 deletions
diff --git a/docs/_static/images/vrf-example-topology-01.png b/docs/_static/images/vrf-example-topology-01.png Binary files differnew file mode 100644 index 00000000..57357509 --- /dev/null +++ b/docs/_static/images/vrf-example-topology-01.png diff --git a/docs/_static/images/wireguard_site2site_diagram.jpg b/docs/_static/images/wireguard_site2site_diagram.jpg Binary files differnew file mode 100644 index 00000000..fc305952 --- /dev/null +++ b/docs/_static/images/wireguard_site2site_diagram.jpg diff --git a/docs/automation/cloud-init.rst b/docs/automation/cloud-init.rst index 7b2d53fb..2be66f7f 100644 --- a/docs/automation/cloud-init.rst +++ b/docs/automation/cloud-init.rst @@ -1,15 +1,15 @@ -:lastproofread: 2021-06-27 +:lastproofread: 2021-07-12 -. _cloud-init: +.. _cloud-init: ############### VyOS cloud-init ############### -Cloud instances of VyOS are initialized using the industry-standard -cloud-init. Via cloud-init, the system performs tasks such as injecting -SSH keys and configuring the network. In addition, the user can supply a custom -configuration at the time of instance launch. +Cloud and virtualized instances of VyOS are initialized using the +industry-standard cloud-init. Via cloud-init, the system performs tasks such as +injecting SSH keys and configuring the network. In addition, the user can supply +a custom configuration at the time of instance launch. ************** Config Sources @@ -20,34 +20,46 @@ VyOS support three types of config sources. * Metadata - Metadata is sourced by the cloud platform or hypervisor. In some clouds, there is implemented as an HTTP endpoint at http://169.254.169.254. - * Network configuration - This config source informs the system about the - network. - + network settings like IP addresses, routes, DNS. Available only in several + cloud and virtualization platforms. * User-data - User-data is specified by the user. This config source offers the - most flexibility and will be the focus of this documentation. - + ability to insert any CLI configuration commands into the configuration before + the first boot. ********* User-data ********* -Major cloud providers offer a means of providing user-data at the time -of instance launch. Typically the user includes user-data as plain -text and the cloud provider's platform base64 encodes the user-data -before injecting it into the instance. +Major cloud providers offer a means of providing user-data at the time of +instance launch. It can be provided as plain text or as base64-encoded text, +depending on cloud provider. Also, it can be compressed using gzip, which makes +sense with a long configuration commands list, because of the hard limit to +~16384 bytes for the whole user-data. -VyOS implements a user-data format called cloud-config. +The easiest way to configure the system via user-data is the Cloud-config syntax +described below. +******************** +Cloud-config modules +******************** + +In VyOS, by default, enabled only two modules: + +* ``write_files`` - this module allows to insert any files into the filesystem + before the first boot, for example, pre-generated encryption keys, + certificates, or even a whole ``config.boot`` file. +* ``vyos_userdata`` - the module accepts a list of CLI configuration commands in + a ``vyos_config_commands`` section, which gives an easy way to configure the + system during deployment. ************************ cloud-config file format ************************ - A cloud-config document is written in YAML. The file must begin -with "#cloud-config". The key used to designate a VyOS configuration -is "vyos_config_commands". What follows is VyOS configuration using +with ``#cloud-config`` line. The key used to designate a VyOS configuration +is ``vyos_config_commands``. What follows is VyOS configuration using the "set-style" syntax. Both "set" and "delete" commands are supported. Commands requirements: @@ -56,13 +68,12 @@ Commands requirements: * if command ends in a value, it must be inside single quotes * a single-quote symbol is not allowed inside command or value - -The commands list produced by the `show configuration commands` command on a +The commands list produced by the ``show configuration commands`` command on a VyOS router should comply with all the requirements, so it is easy to get a proper commands list by copying it from another router. -The configuration specified in the cloud-config document is merged with -the default configuration and saved to /config/config.boot. +The configuration specified in the cloud-config document overwrites default +configuration values and values configured via Metadata. Here is an example cloud-config. @@ -74,8 +85,8 @@ Here is an example cloud-config. - set system ntp server 1.pool.ntp.org - set system ntp server 2.pool.ntp.org - delete interfaces ethernet eth1 address 'dhcp' - - set interfaces ethernet eth1 address '172.31.7.247/20' - - set protocols static route '172.31.0.0/16' next-hop '100.64.16.1' + - set interfaces ethernet eth1 address '192.0.2.247/24' + - set protocols static route 198.51.100.0/24 next-hop '192.0.2.1' ************************* System Defaults/Fallbacks @@ -84,13 +95,11 @@ System Defaults/Fallbacks These are the VyOS defaults and fallbacks. * SSH is configured on port 22 -* vyos/vyos credentials if no others specified by data source +* ``vyos``/``vyos`` credentials if no others specified by data source * DHCP on first Ethernet interface if no network configuration is provided - All of these can be overridden using the configuration in user-data. - *************** Troubleshooting *************** @@ -100,5 +109,10 @@ valid YAML. Online resources such as https://yamlvalidator.com/ provide a simple tool for validating YAML. cloud-init logs to /var/log/cloud-init.log. This file can be helpful in -determining why the configuration varies from what you expect. +determining why the configuration varies from what you expect. You can fetch the +most important data filtering output for ``vyos`` keyword: + +.. code-block:: none + + sudo grep vyos /var/log/cloud-init.log diff --git a/docs/configuration/interfaces/index.rst b/docs/configuration/interfaces/index.rst index 3c75f482..23792203 100644 --- a/docs/configuration/interfaces/index.rst +++ b/docs/configuration/interfaces/index.rst @@ -16,12 +16,12 @@ Interfaces loopback macsec openvpn + wireguard pppoe pseudo-ethernet tunnel vti vxlan - wireguard wireless wwan diff --git a/docs/configuration/interfaces/wireguard.rst b/docs/configuration/interfaces/wireguard.rst index ddfbe620..bb2418b1 100644 --- a/docs/configuration/interfaces/wireguard.rst +++ b/docs/configuration/interfaces/wireguard.rst @@ -1,7 +1,5 @@ .. _wireguard: -.. include:: /_include/need_improvement.txt - ######### WireGuard ######### @@ -10,10 +8,24 @@ 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. +**************** +Site to Site VPN +**************** + +This diagram corresponds with the example site to site configuration below. + +.. figure:: /_static/images/wireguard_site2site_diagram.jpg + ************* Configuration ************* + + +******** +Keypairs +******** + WireGuard requires the generation of a keypair, which includes a private key to decrypt incoming traffic, and a public key for peer(s) to encrypt traffic. @@ -55,8 +67,9 @@ own keypairs. vyos@vyos:~$ generate wireguard named-keypairs KP02 +*********************** Interface configuration -======================= +*********************** The next step is to configure your local side as well as the policy based trusted destination addresses. If you only initiate a connection, @@ -71,18 +84,31 @@ 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** +**local side - commands** .. code-block:: none - set interfaces wireguard wg01 address '10.1.0.1/24' + set interfaces wireguard wg01 address '10.1.0.1/30' set interfaces wireguard wg01 description 'VPN-to-wg02' - set interfaces wireguard wg01 peer to-wg02 allowed-ips '10.2.0.0/24' - set interfaces wireguard wg01 peer to-wg02 address '192.168.0.142' - set interfaces wireguard wg01 peer to-wg02 port '12345' + set interfaces wireguard wg01 peer to-wg02 allowed-ips '192.168.2.0/24' + set interfaces wireguard wg01 peer to-wg02 address '<Site1 Pub IP>' + set interfaces wireguard wg01 peer to-wg02 port '51820' set interfaces wireguard wg01 peer to-wg02 pubkey 'XMrlPykaxhdAAiSjhtPlvi30NVkvLQliQuKP7AI7CyI=' - set interfaces wireguard wg01 port '12345' - set protocols static route 10.2.0.0/24 interface wg01 + set interfaces wireguard wg01 port '51820' + set protocols static route 192.168.2.0/24 interface wg01 + +**local side - annotated commands** + +.. code-block:: none + + set interfaces wireguard wg01 address '10.1.0.1/30' # Address of the wg01 tunnel interface. + set interfaces wireguard wg01 description 'VPN-to-wg02' + set interfaces wireguard wg01 peer to-wg02 allowed-ips '192.168.2.0/24' # Subnets that are allowed to travel over the tunnel + set interfaces wireguard wg01 peer to-wg02 address '<Site2 Pub IP>' # Public IP of the peer + set interfaces wireguard wg01 peer to-wg02 port '58120' # Port of the Peer + set interfaces wireguard wg01 peer to-wg02 pubkey '<pubkey>' # Public Key of the Peer + set interfaces wireguard wg01 port '51820' # Port of own server + set protocols static route 192.168.2.0/24 interface wg01 # Static route to remote subnet 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 @@ -90,7 +116,7 @@ defined and routed. The last check is allowed-ips which either prevents or allows the traffic. .. note:: You can not assign the same allowed-ips statement to multiple - WireGuard peers. This a a design decission. For more information please + WireGuard peers. This a a design decision. For more information please check the `WireGuard mailing list`_. .. cfgcmd:: set interfaces wireguard <interface> private-key <name> @@ -106,33 +132,70 @@ or allows the traffic. public key, which needs to be shared with the peer. -**remote side** +**remote side - commands** .. code-block:: none - set interfaces wireguard wg01 address '10.2.0.1/24' + set interfaces wireguard wg01 address '10.1.0.2/30' set interfaces wireguard wg01 description 'VPN-to-wg01' - set interfaces wireguard wg01 peer to-wg02 allowed-ips '10.1.0.0/24' - set interfaces wireguard wg01 peer to-wg02 address '192.168.0.124' - set interfaces wireguard wg01 peer to-wg02 port '12345' + set interfaces wireguard wg01 peer to-wg02 allowed-ips '192.168.1.0/24' + set interfaces wireguard wg01 peer to-wg02 address '<Site1 Pub IP>' + set interfaces wireguard wg01 peer to-wg02 port '51820' set interfaces wireguard wg01 peer to-wg02 pubkey 'u41jO3OF73Gq1WARMMFG7tOfk7+r8o8AzPxJ1FZRhzk=' - set interfaces wireguard wg01 port '12345' - set protocols static route 10.1.0.0/24 interface wg01 + set interfaces wireguard wg01 port '51820' + set protocols static route 192.168.1.0/24 interface wg01 + +**remote side - annotated commands** + +.. code-block:: none + + set interfaces wireguard wg01 address '10.1.0.2/30' # Address of the wg01 tunnel interface. + set interfaces wireguard wg01 description 'VPN-to-wg01' + set interfaces wireguard wg01 peer to-wg02 allowed-ips '192.168.1.0/24' # Subnets that are allowed to travel over the tunnel + set interfaces wireguard wg01 peer to-wg02 address 'Site1 Pub IP' # Public IP address of the Peer + set interfaces wireguard wg01 peer to-wg02 port '51820' # Port of the Peer + set interfaces wireguard wg01 peer to-wg02 pubkey '<pubkey>' # Public key of the Peer + set interfaces wireguard wg01 port '51820' # Port of own server + set protocols static route 192.168.1.0/24 interface wg01 # Static route to remote subnet + +******************* +Firewall Exceptions +******************* -Assure that your firewall rules allow the traffic, in which case you -have a working VPN using WireGuard. +For the WireGuard traffic to pass through the WAN interface, you must create a firewall exception. .. code-block:: none - wg01# ping 10.2.0.1 - PING 10.2.0.1 (10.2.0.1) 56(84) bytes of data. - 64 bytes from 10.2.0.1: icmp_seq=1 ttl=64 time=1.16 ms - 64 bytes from 10.2.0.1: icmp_seq=2 ttl=64 time=1.77 ms + set firewall name OUTSIDE_LOCAL rule 10 action accept + set firewall name OUTSIDE_LOCAL rule 10 description 'Allow established/related' + set firewall name OUTSIDE_LOCAL rule 10 state established enable + set firewall name OUTSIDE_LOCAL rule 10 state related enable + set firewall name OUTSIDE_LOCAL rule 20 action accept + set firewall name OUTSIDE_LOCAL rule 20 description WireGuard_IN + set firewall name OUTSIDE_LOCAL rule 20 destination port 51820 + set firewall name OUTSIDE_LOCAL rule 20 log enable + set firewall name OUTSIDE_LOCAL rule 20 protocol udp + set firewall name OUTSIDE_LOCAL rule 20 source - wg02# ping 10.1.0.1 - PING 10.1.0.1 (10.1.0.1) 56(84) bytes of data. - 64 bytes from 10.1.0.1: icmp_seq=1 ttl=64 time=4.40 ms - 64 bytes from 10.1.0.1: icmp_seq=2 ttl=64 time=1.02 ms +You should also ensure that the OUTISDE_LOCAL firewall group is applied to the WAN interface and a direction (local). + +.. code-block:: none + + set interfaces ethernet eth0 firewall local name 'OUTSIDE-LOCAL' + +Assure that your firewall rules allow the traffic, in which case you have a working VPN using WireGuard. + +.. code-block:: none + + wg01# ping 192.168.1.1 + PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data. + 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=1.16 ms + 64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=1.77 ms + + wg02# ping 192.168.2.1 + PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data. + 64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=4.40 ms + 64 bytes from 192.168.2.1: icmp_seq=2 ttl=64 time=1.02 ms An additional layer of symmetric-key crypto can be used on top of the asymmetric crypto. This is optional. @@ -151,8 +214,10 @@ its content. Make sure you distribute the key in a safe manner, wg01# set interfaces wireguard wg01 peer to-wg02 preshared-key 'rvVDOoc2IYEnV+k5p7TNAmHBMEGTHbPU8Qqg8c/sUqc=' wg02# set interfaces wireguard wg01 peer to-wg01 preshared-key 'rvVDOoc2IYEnV+k5p7TNAmHBMEGTHbPU8Qqg8c/sUqc=' -Road Warrior Example --------------------- + +*********************************** +Remote Access "RoadWarrior" Example +*********************************** With WireGuard, a Road Warrior VPN config is similar to a site-to-site VPN. It just lacks the ``address`` and ``port`` statements. @@ -182,7 +247,7 @@ the peers. This allows the peers to interact with one another. } The following is the config for the iPhone peer above. It's important to -note that the ``AllowedIPs`` setting directs all IPv4 and IPv6 traffic +note that the ``AllowedIPs`` wildcard setting directs all IPv4 and IPv6 traffic through the connection. .. code-block:: none @@ -198,9 +263,9 @@ through the connection. Endpoint = 192.0.2.1:2224 PersistentKeepalive = 25 - -This MacBook peer is doing split-tunneling, where only the subnets local -to the server go over the connection. +However, split-tunneling can be achieved by specifing the remote subnets. +This ensures that only traffic destined for the remote site is sent over the tunnel. +All other traffic is unaffected. .. code-block:: none @@ -222,6 +287,25 @@ Operational Commands Status ====== +.. opcmd:: show interfaces wireguard wg0 summary + + Show info about the Wireguard service. + Also shows the latest handshake. + + .. code-block:: none + + vyos@vyos:~$ show interfaces wireguard wg0 summary + interface: wg0 + public key: + private key: (hidden) + listening port: 51820 + + peer: <peer pubkey> + endpoint: <peer public IP> + allowed ips: 10.69.69.2/32 + latest handshake: 23 hours, 45 minutes, 26 seconds ago + transfer: 1.26 MiB received, 6.47 MiB sent + .. opcmd:: show interfaces wireguard Get a list of all wireguard interfaces @@ -252,8 +336,9 @@ Status TX: bytes packets errors dropped carrier collisions 0 0 0 0 0 0 +*************** Encryption Keys -=============== +*************** .. opcmd:: show wireguard keypair pubkey <name> @@ -284,15 +369,16 @@ Encryption Keys vyos@vyos:~$ delete wireguard keypair default -Mobile "RoadWarrior" clients -============================ +*********************************** +Remote Access "RoadWarrior" clients +*********************************** Some users tend to connect their mobile devices using WireGuard to their VyOS router. To ease deployment one can generate a "per mobile" configuration from the VyOS CLI. .. warning:: From a security perspective it is not recommended to let a third - party create the private key for a secured connection. You should create the + party create and share the private key for a secured connection. You should create the private portion on your own and only hand out the public key. Please keep this in mind when using this convenience feature. diff --git a/docs/configuration/policy/index.rst b/docs/configuration/policy/index.rst index 7a329500..7127957a 100644 --- a/docs/configuration/policy/index.rst +++ b/docs/configuration/policy/index.rst @@ -1,3 +1,5 @@ +:lastproofread:2021-07-12 + .. include:: /_include/need_improvement.txt ###### @@ -53,7 +55,7 @@ neighbor. .. code-block:: none - vyos@vos1:~$ sho ip b + vyos@vos1:~$ show ip bgp BGP table version is 0, local router ID is 192.168.56.101 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, R Removed @@ -182,7 +184,7 @@ ISP's and VyOS router will respond from the same interface that the packet was received. Also, it used, if we want that one VPN tunnel to be through one provider, and the second through another. -* ``203.0.113.0.254`` IP addreess on VyOS eth1 from ISP1 +* ``203.0.113.254`` IP addreess on VyOS eth1 from ISP1 * ``192.168.2.254`` IP addreess on VyOS eth2 from ISP2 * ``table 10`` Routing table used for ISP1 * ``table 11`` Routing table used for ISP2 @@ -191,18 +193,18 @@ provider, and the second through another. .. code-block:: none set policy local-route rule 101 set table '10' - set policy local-route rule 101 source '203.0.113.0.254' + set policy local-route rule 101 source '203.0.113.254' set policy local-route rule 102 set table '11' set policy local-route rule 102 source '192.0.2.254' - set protocols static table 10 route '0.0.0.0/0' next-hop '203.0.113.0.1' - set protocols static table 11 route '0.0.0.0/0' next-hop '192.0.2.2' + set protocols static table 10 route 0.0.0.0/0 next-hop '203.0.113.1' + set protocols static table 11 route 0.0.0.0/0 next-hop '192.0.2.2' Add multiple source IP in one rule with same priority .. code-block:: none set policy local-route rule 101 set table '10' - set policy local-route rule 101 source '203.0.113.0.254' - set policy local-route rule 101 source '203.0.113.0.253' + set policy local-route rule 101 source '203.0.113.254' + set policy local-route rule 101 source '203.0.113.253' set policy local-route rule 101 source '198.51.100.0/24' diff --git a/docs/configuration/protocols/static.rst b/docs/configuration/protocols/static.rst index fed0dd22..da471b86 100644 --- a/docs/configuration/protocols/static.rst +++ b/docs/configuration/protocols/static.rst @@ -32,7 +32,7 @@ Static Routes distance <distance> Defines next-hop distance for this route, routes with smaller administrative - distance are elected prior those with a higher distance. + distance are elected prior to those with a higher distance. Range is 1 to 255, default is 1. @@ -52,7 +52,7 @@ Static Routes distance <distance> Defines next-hop distance for this route, routes with smaller administrative - distance are elected prior those with a higher distance. + distance are elected prior to those with a higher distance. Range is 1 to 255, default is 1. @@ -67,7 +67,7 @@ Interface Routes <interface> Allows you to configure the next-hop interface for an interface-based IPv4 - static route. `<interface>` will be the next-hop interface where trafic is + static route. `<interface>` will be the next-hop interface where traffic is routed for the given `<subnet>`. .. cfgcmd:: set protocols static route <subnet> interface @@ -79,7 +79,7 @@ Interface Routes <interface> distance <distance> Defines next-hop distance for this route, routes with smaller administrative - distance are elected prior those with a higher distance. + distance are elected prior to those with a higher distance. Range is 1 to 255, default is 1. @@ -87,7 +87,7 @@ Interface Routes <interface> Allows you to configure the next-hop interface for an interface-based IPv6 - static route. `<interface>` will be the next-hop interface where trafic is + static route. `<interface>` will be the next-hop interface where traffic is routed for the given `<subnet>`. .. cfgcmd:: set protocols static route6 <subnet> interface @@ -99,7 +99,7 @@ Interface Routes <interface> distance <distance> Defines next-hop distance for this route, routes with smaller administrative - distance are elected prior those with a higher distance. + distance are elected prior to those with a higher distance. Range is 1 to 255, default is 1. @@ -118,7 +118,7 @@ Blackhole .. cfgcmd:: set protocols static route <subnet> blackhole distance <distance> Defines blackhole distance for this route, routes with smaller administrative - distance are elected prior those with a higher distance. + distance are elected prior to those with a higher distance. .. cfgcmd:: set protocols static route6 <subnet> blackhole @@ -131,7 +131,7 @@ Blackhole .. cfgcmd:: set protocols static route6 <subnet> blackhole distance <distance> Defines blackhole distance for this route, routes with smaller administrative - distance are elected prior those with a higher distance. + distance are elected prior to those with a higher distance. Alternate Routing Tables @@ -139,7 +139,7 @@ Alternate Routing Tables TBD -Alternate routing tables are used with policy based routing of by utilizing +Alternate routing tables are used with policy based routing by utilizing :ref:`vrf`. diff --git a/docs/configuration/vpn/index.rst b/docs/configuration/vpn/index.rst index abaca198..3cd9e50d 100644 --- a/docs/configuration/vpn/index.rst +++ b/docs/configuration/vpn/index.rst @@ -15,7 +15,6 @@ VPN sstp - pages to sort .. toctree:: @@ -23,4 +22,4 @@ pages to sort :includehidden: dmvpn - site2site_ipsec
\ No newline at end of file + site2site_ipsec diff --git a/docs/configuration/vrf/index.rst b/docs/configuration/vrf/index.rst index a65f0073..23bc5422 100644 --- a/docs/configuration/vrf/index.rst +++ b/docs/configuration/vrf/index.rst @@ -183,9 +183,133 @@ For VRF maintenance the following operational commands are in place. .. opcmd:: traceroute vrf <name> [ipv4 | ipv6] <host> Displays the route packets taken to a network host utilizing VRF instance - identified by `<name>`. When using the IPv4 or IPv6 option, displays the + identified by `<name>`. When using the IPv4 or IPv6 option, displays the route packets taken to the given hosts IP address family. This option is useful when the host is specified as a hostname rather than an IP address. +Example +======= + +VRF route leaking +----------------- + +The following example topology was build using EVE-NG. + +.. figure:: /_static/images/vrf-example-topology-01.png + :alt: VRF topology example + + VRF route leaking + +* PC1 is in the ``default`` VRF and acting as e.g. a "fileserver" +* PC2 is in VRF ``blue`` which is the development department +* PC3 and PC4 are connected to a bridge device on router ``R1`` which is in VRF + ``red``. Say this is the HR department. +* R1 is managed through an out-of-band network that resides in VRF ``mgmt`` + +Configuration +^^^^^^^^^^^^^ + + .. code-block:: none + + set interfaces bridge br10 address '10.30.0.254/24' + set interfaces bridge br10 member interface eth3 + set interfaces bridge br10 member interface eth4 + set interfaces bridge br10 vrf 'red' + + set interfaces ethernet eth0 address 'dhcp' + set interfaces ethernet eth0 vrf 'mgmt' + set interfaces ethernet eth1 address '10.0.0.254/24' + set interfaces ethernet eth2 address '10.20.0.254/24' + set interfaces ethernet eth2 vrf 'blue' + + set protocols static route 10.20.0.0/24 interface eth2 vrf 'blue' + set protocols static route 10.30.0.0/24 interface br10 vrf 'red' + + set service ssh disable-host-validation + set service ssh vrf 'mgmt' + + set system name-servers-dhcp 'eth0' + + set vrf name blue protocols static route 10.0.0.0/24 interface eth1 vrf 'default' + set vrf name blue table '3000' + set vrf name mgmt table '1000' + set vrf name red protocols static route 10.0.0.0/24 interface eth1 vrf 'default' + set vrf name red table '2000' + +Operation +^^^^^^^^^ + +After committing the configuration we can verify all leaked routes are installed, +and try to ICMP ping PC1 from PC3. + + .. code-block:: none + + PCS> ping 10.0.0.1 + + 84 bytes from 10.0.0.1 icmp_seq=1 ttl=63 time=1.943 ms + 84 bytes from 10.0.0.1 icmp_seq=2 ttl=63 time=1.618 ms + 84 bytes from 10.0.0.1 icmp_seq=3 ttl=63 time=1.745 ms + + .. code-block:: none + + VPCS> show ip + + NAME : VPCS[1] + IP/MASK : 10.30.0.1/24 + GATEWAY : 10.30.0.254 + DNS : + MAC : 00:50:79:66:68:0f + +VRF default routing table +""""""""""""""""""""""""" + + .. code-block:: none + + vyos@R1:~$ show ip route + Codes: K - kernel route, C - connected, S - static, R - RIP, + O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP, + T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP, + F - PBR, f - OpenFabric, + > - selected route, * - FIB route, q - queued, r - rejected, b - backup + + C>* 10.0.0.0/24 is directly connected, eth1, 00:07:44 + S>* 10.20.0.0/24 [1/0] is directly connected, eth2 (vrf blue), weight 1, 00:07:38 + S>* 10.30.0.0/24 [1/0] is directly connected, br10 (vrf red), weight 1, 00:07:38 + +VRF red routing table +""""""""""""""""""""" + + .. code-block:: none + + vyos@R1:~$ show ip route vrf red + Codes: K - kernel route, C - connected, S - static, R - RIP, + O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP, + T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP, + F - PBR, f - OpenFabric, + > - selected route, * - FIB route, q - queued, r - rejected, b - backup + + VRF red: + K>* 0.0.0.0/0 [255/8192] unreachable (ICMP unreachable), 00:07:57 + S>* 10.0.0.0/24 [1/0] is directly connected, eth1 (vrf default), weight 1, 00:07:40 + C>* 10.30.0.0/24 is directly connected, br10, 00:07:54 + +VRF blue routing table +"""""""""""""""""""""" + + .. code-block:: none + + vyos@R1:~$ show ip route vrf blue + Codes: K - kernel route, C - connected, S - static, R - RIP, + O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP, + T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP, + F - PBR, f - OpenFabric, + > - selected route, * - FIB route, q - queued, r - rejected, b - backup + + VRF blue: + K>* 0.0.0.0/0 [255/8192] unreachable (ICMP unreachable), 00:08:00 + S>* 10.0.0.0/24 [1/0] is directly connected, eth1 (vrf default), weight 1, 00:07:44 + C>* 10.20.0.0/24 is directly connected, eth2, 00:07:53 + + .. include:: /_include/common-references.txt |
