VRRP with VPF Filtering and Outside NAT¶
This example is a two-node VRRP high availability (HA) cluster with internal and external VR address with NAT and filtering handled by VPF. This recipe also includes optional DNS and DHCP service for local clients.
VPF HA provides state synchronization which allows connections to continue flowing seamlessly through the cluster when a node fails.
See also
For an example without filtering or NAT, see VRRP Example.
In this example, the WAN-side VR address (203.0.113.228) is used for
outbound NAT from the internal private subnet 10.28.0.0/24. Clients will use
the LAN-side VR address (10.28.0.1) as their gateway.
Interface tracking is included in the example to protect against a single failure of either WAN or LAN.
See also
Required Information¶
These tables contain all information necessary to configure the cluster.
The information in this first table is related to the setup in general, not a specific cluster node.
Item |
Value |
|---|---|
Upstream Gateway |
203.0.113.1 |
Shared WAN VR Address |
203.0.113.228 |
NAT Address |
203.0.113.228 |
Shared LAN VR Address |
10.2.0.1 |
LAN Client Gateway |
10.2.0.1 |
This information is for the primary node, which in this example is called R1.
Item |
Value |
|---|---|
R1 WAN Interface |
0000:06:13.0 |
R1 WAN IP Address |
203.0.113.28/24 |
R1 WAN VR ID |
228 |
R1 WAN VR Priority |
254 |
R1 LAN Interface |
0000:06:14.0 |
R1 LAN IP Address |
10.28.0.2/24 |
R1 LAN VR ID |
28 |
R1 LAN VR Priority |
254 |
R1 Priority Decrease |
240 (14) |
R1 SYNC Interface |
0000:06:15.0 |
R1 SYNC IP Address |
10.28.1.1/30 |
This information is for the secondary node, which in this example is called R2. Note that the interface addresses are different than R1, but the same VR address is used.
Item |
Value |
|---|---|
R2 WAN Interface |
0000:06:00.0 |
R2 WAN IP Address |
203.0.113.29/24 |
R2 WAN VR ID |
228 |
R2 WAN VR Priority |
100 |
R2 LAN Interface |
0000:06:00.1 |
R2 LAN IP Address |
10.28.0.3/24 |
R2 LAN VR ID |
28 |
R2 LAN VR Priority |
100 |
R2 Priority Decrease |
90 (10) |
R2 SYNC Interface |
0000:06:15.0 |
R2 SYNC IP Address |
10.28.2.1/30 |
The configuration commands in this recipe apply the settings from these tables to each node. Some additional settings in the commands are not in the tables, but the example commands include them with default values for emphasis.
Interface Names¶
The first configuration task is to setup custom interface names on both nodes. In this example setup the hardware is identical, so the configuration is also identical.
Use the following commands on both nodes:
tnsr(config)# dataplane dpdk dev 0000:06:13.0 network name WAN
tnsr(config)# dataplane dpdk dev 0000:06:14.0 network name LAN
tnsr(config)# dataplane dpdk dev 0000:06:15.0 network name SYNC
tnsr(config)# service dataplane restart
Note
While this is not a required step, it is a best practice. Aside from being more convenient for administrators, VPF high availability state synchronization indexes by interface names. This enables VPF to associate state data with proper interfaces even when the hardware is not identical.
See also
Interface Addresses¶
Now configure the interface addresses for each node. The interfaces must have IP addresses before they can accept VRRP addresses.
Interface setup for R1:
r1 tnsr(config)# interface WAN
r1 tnsr(config-interface)# ip address 203.0.113.28/24
r1 tnsr(config-interface)# enable
r1 tnsr(config-interface)# exit
r1 tnsr(config)# interface LAN
r1 tnsr(config-interface)# ip address 10.28.0.2/24
r1 tnsr(config-interface)# enable
r1 tnsr(config-interface)# exit
r1 tnsr(config)# interface SYNC
r1 tnsr(config-interface)# ip addr 10.28.1.1/30
r1 tnsr(config-interface)# enable
r1 tnsr(config-interface)# exit
r1 tnsr(config)#
Interface setup for R2:
r2 tnsr(config)# interface WAN
r2 tnsr(config-interface)# ip address 203.0.113.29/24
r2 tnsr(config-interface)# enable
r2 tnsr(config-interface)# exit
r2 tnsr(config)# interface LAN
r2 tnsr(config-interface)# ip address 10.28.0.3/24
r2 tnsr(config-interface)# enable
r2 tnsr(config-interface)# exit
r2 tnsr(config)# interface SYNC
r2 tnsr(config-interface)# ip addr 10.28.1.2/30
r2 tnsr(config-interface)# enable
r2 tnsr(config-interface)# exit
r2 tnsr(config)#
See also
Default Route¶
After configuring the interfaces, both nodes need a default route through the upstream gateway on WAN.
Run the following commands on both nodes:
tnsr(config)# route table default
tnsr(config-route-table)# id 0
tnsr(config-route-table)# route 0.0.0.0/0
tnsr(config-rttbl4-next-hop)# next-hop 0 via 203.0.113.1
tnsr(config-rttbl4-next-hop)# exit
tnsr(config-route-table)# exit
tnsr(config)#
See also
VRRP Addresses¶
With the interfaces and routing in place, the next step is to add the VRRP addresses to the interfaces on each node.
First, add the VRRP addresses to the primary node, R1:
r1 tnsr(config)# int WAN
r1 tnsr(config-interface)# ip vrrp-virtual-router 228
r1 tnsr(config-vrrp4)# preempt true
r1 tnsr(config-vrrp4)# accept-mode true
r1 tnsr(config-vrrp4)# v3-advertisement-interval 100
r1 tnsr(config-vrrp4)# priority 254
r1 tnsr(config-vrrp4)# track-interface LAN priority-decrement 240
r1 tnsr(config-vrrp4)# virtual-address 203.0.113.228
r1 tnsr(config-vrrp4)# exit
r1 tnsr(config-interface)# exit
r1 tnsr(config)# int LAN
r1 tnsr(config-interface)# ip vrrp-virtual-router 28
r1 tnsr(config-vrrp4)# preempt true
r1 tnsr(config-vrrp4)# accept-mode true
r1 tnsr(config-vrrp4)# v3-advertisement-interval 100
r1 tnsr(config-vrrp4)# priority 254
r1 tnsr(config-vrrp4)# track-interface WAN priority-decrement 240
r1 tnsr(config-vrrp4)# virtual-address 10.28.0.1
r1 tnsr(config-vrrp4)# exit
r1 tnsr(config-interface)# exit
r1 tnsr(config)#
Next, add the VRRP addresses to the secondary node, R2:
r2 tnsr(config)# int WAN
r2 tnsr(config-interface)# ip vrrp-virtual-router 228
r2 tnsr(config-vrrp4)# preempt true
r2 tnsr(config-vrrp4)# accept-mode true
r2 tnsr(config-vrrp4)# v3-advertisement-interval 100
r2 tnsr(config-vrrp4)# priority 100
r2 tnsr(config-vrrp4)# track-interface LAN priority-decrement 90
r2 tnsr(config-vrrp4)# virtual-address 203.0.113.228
r2 tnsr(config-vrrp4)# exit
r2 tnsr(config-interface)# exit
r2 tnsr(config)# int LAN
r2 tnsr(config-interface)# ip vrrp-virtual-router 28
r2 tnsr(config-vrrp4)# preempt true
r2 tnsr(config-vrrp4)# accept-mode true
r2 tnsr(config-vrrp4)# v3-advertisement-interval 100
r2 tnsr(config-vrrp4)# priority 100
r2 tnsr(config-vrrp4)# track-interface WAN priority-decrement 90
r2 tnsr(config-vrrp4)# virtual-address 10.28.0.1
r2 tnsr(config-vrrp4)# exit
r2 tnsr(config-interface)# exit
r2 tnsr(config)#
See also
VPF Filtering¶
This example uses VPF filter rules prevent unwanted traffic from entering or exiting TNSR. There is a VPF filter ruleset for each interface.
The rules for this example are identical for both nodes.
Note
The best practice is to have these rules in place before activating services on TNSR so that there is no window where those services are exposed without filtering.
See also
WAN Interface Filter Rules¶
These WAN interface rules control traffic flow into and out of the WAN interface. This example setup is focused on outbound client traffic, so it does not allow other traffic is inbound.
Add the WAN filter ruleset on both nodes:
tnsr(config)# vpf filter ruleset WAN-filter
tnsr(config-vpf-filter-ruleset)# description Filter rules for WAN
This rule allows ICMP inbound for diagnostic and network control purposes:
tnsr(config-vpf-filter-ruleset)# rule 10
tnsr(config-vpf-filter-rule)# description Allow ICMP inbound
tnsr(config-vpf-filter-rule)# pass
tnsr(config-vpf-filter-rule)# direction in
tnsr(config-vpf-filter-rule)# stateful
tnsr(config-vpf-filter-rule)# ip-version ipv4
tnsr(config-vpf-filter-rule)# protocol icmp
tnsr(config-vpf-filter-rule)# exit
These rules allow VRRP to communicate inbound and outbound to ensure both nodes can exchange heartbeats:
tnsr(config-vpf-filter-ruleset)# rule 20
tnsr(config-vpf-filter-rule)# description Allow VRRP inbound
tnsr(config-vpf-filter-rule)# pass
tnsr(config-vpf-filter-rule)# direction in
tnsr(config-vpf-filter-rule)# ip-version ipv4
tnsr(config-vpf-filter-rule)# protocol vrrp
tnsr(config-vpf-filter-rule)# exit
tnsr(config-vpf-filter-ruleset)# rule 21
tnsr(config-vpf-filter-rule)# description Allow VRRP outbound
tnsr(config-vpf-filter-rule)# pass
tnsr(config-vpf-filter-rule)# direction out
tnsr(config-vpf-filter-rule)# ip-version ipv4
tnsr(config-vpf-filter-rule)# protocol vrrp
tnsr(config-vpf-filter-rule)# exit
Note
The VRRP rules could be more strict, allowing only a source of the peer
interface IP address and/or to a destination of 224.0.0.18.
Do not use stateful on VRRP rules as it is multicast and has no return
traffic, so the state never has traffic it can match.
This rule allows traffic outbound from TNSR itself and for traffic routed through TNSR egressing through the WAN interface on TNSR:
tnsr(config-vpf-filter-ruleset)# rule 1000
tnsr(config-vpf-filter-rule)# description Pass outbound from TNSR to any destination
tnsr(config-vpf-filter-rule)# pass
tnsr(config-vpf-filter-rule)# direction out
tnsr(config-vpf-filter-rule)# stateful
tnsr(config-vpf-filter-rule)# ip-version ipv4
tnsr(config-vpf-filter-rule)# exit
Exit out to complete the ruleset:
tnsr(config-vpf-filter-ruleset)# exit
Next, activate the WAN filter ruleset:
tnsr(config)# vpf options
tnsr(config-vpf-option)# interface WAN filter-ruleset WAN-filter
tnsr(config-vpf-option)# exit
LAN Interface Filter Rules¶
These LAN rules allow traffic from local clients on the LAN interface to and through TNSR.
Create the LAN interface filter ruleset on both nodes:
tnsr(config)# vpf filter ruleset LAN-filter
tnsr(config-vpf-filter-ruleset)# description Filter Rules for LAN
If TNSR is acting as a DHCP server (DHCP Server (Optional)), the rules must allow DHCP-related packets from clients on LAN:
tnsr(config-vpf-filter-ruleset)# rule 10
tnsr(config-vpf-filter-rule)# description Allow DHCP Discovery
tnsr(config-vpf-filter-rule)# pass
tnsr(config-vpf-filter-rule)# direction in
tnsr(config-vpf-filter-rule)# stateful
tnsr(config-vpf-filter-rule)# ip-version ipv4
tnsr(config-vpf-filter-rule)# from ipv4-prefix 0.0.0.0/32
tnsr(config-vpf-filter-rule)# from port 68
tnsr(config-vpf-filter-rule)# to port 67
tnsr(config-vpf-filter-rule)# to ipv4-prefix 255.255.255.255/32
tnsr(config-vpf-filter-rule)# exit
tnsr(config-vpf-filter-ruleset)# rule 11
tnsr(config-vpf-filter-rule)# description Allow DHCP Requests
tnsr(config-vpf-filter-rule)# pass
tnsr(config-vpf-filter-rule)# direction in
tnsr(config-vpf-filter-rule)# stateful
tnsr(config-vpf-filter-rule)# ip-version ipv4
tnsr(config-vpf-filter-rule)# from port 68
tnsr(config-vpf-filter-rule)# to port 67
tnsr(config-vpf-filter-rule)# to ipv4-prefix 10.28.0.1/32
tnsr(config-vpf-filter-rule)# exit
These rules allow VRRP to communicate inbound and outbound to ensure both nodes can exchange heartbeats:
tnsr(config-vpf-filter-ruleset)# rule 20
tnsr(config-vpf-filter-rule)# description Allow VRRP inbound
tnsr(config-vpf-filter-rule)# pass
tnsr(config-vpf-filter-rule)# direction in
tnsr(config-vpf-filter-rule)# ip-version ipv4
tnsr(config-vpf-filter-rule)# protocol vrrp
tnsr(config-vpf-filter-rule)# exit
tnsr(config-vpf-filter-ruleset)# rule 21
tnsr(config-vpf-filter-rule)# description Allow VRRP outbound
tnsr(config-vpf-filter-rule)# pass
tnsr(config-vpf-filter-rule)# direction out
tnsr(config-vpf-filter-rule)# ip-version ipv4
tnsr(config-vpf-filter-rule)# protocol vrrp
tnsr(config-vpf-filter-rule)# exit
This rule allows clients on LAN to reach any destination on or through TNSR:
tnsr(config-vpf-filter-ruleset)# rule 30
tnsr(config-vpf-filter-rule)# description Allow LAN inbound to Any destination
tnsr(config-vpf-filter-rule)# pass
tnsr(config-vpf-filter-rule)# direction in
tnsr(config-vpf-filter-rule)# stateful
tnsr(config-vpf-filter-rule)# ip-version ipv4
tnsr(config-vpf-filter-rule)# from ipv4-prefix 10.28.0.0/24
tnsr(config-vpf-filter-rule)# exit
This rule allows traffic outbound from TNSR itself and for traffic routed through TNSR egressing through the LAN interface on TNSR:
tnsr(config-vpf-filter-ruleset)# rule 40
tnsr(config-vpf-filter-rule)# description Pass outbound from TNSR to LAN
tnsr(config-vpf-filter-rule)# pass
tnsr(config-vpf-filter-rule)# direction out
tnsr(config-vpf-filter-rule)# stateful
tnsr(config-vpf-filter-rule)# ip-version ipv4
tnsr(config-vpf-filter-rule)# to ipv4-prefix 10.28.0.0/24
tnsr(config-vpf-filter-rule)# exit
Exit out to complete the ruleset:
tnsr(config-vpf-filter-ruleset)# exit
Next, activate the LAN filter ruleset:
tnsr(config)# vpf options
tnsr(config-vpf-option)# interface LAN filter-ruleset LAN-filter
tnsr(config-vpf-option)# exit
SYNC Interface Filter Rules¶
The rules for the SYNC interface specifically allow the VPF HA state synchronization traffic as well as anything else outbound from TNSR itself. A dedicated synchronization interface like this may be a direct cross-connection from the peer, in which case it can be safe to omit these rules. However, it is still a best practice to ensure that TNSR only allows expected traffic on the interface.
Danger
Do not use stateful on rules for VPF HA synchronization. Tracking state
on these rules will cause VPF HA to enter a loop updating the peer with data
about its own state synchronization traffic which will consume large amounts
of resources.
VPF HA data is stateless and the sender does not check for nor does it get any indication that the peer received the data. As such there are no return packets that would match a state, so keeping state is unnecessary.
Create the SYNC interface filter ruleset on both nodes:
tnsr(config)# vpf filter ruleset SYNC-filter
tnsr(config-vpf-filter-ruleset)# description Filter Rules for SYNC
This rule allows VPF HA state synchronization traffic outbound from this node to the peer:
tnsr(config-vpf-filter-ruleset)# rule 10
tnsr(config-vpf-filter-rule)# description Allow outbound VPF state synchronization
tnsr(config-vpf-filter-rule)# pass
tnsr(config-vpf-filter-rule)# direction out
tnsr(config-vpf-filter-rule)# ip-version ipv4
tnsr(config-vpf-filter-rule)# protocol udp
tnsr(config-vpf-filter-rule)# from ipv4-prefix 10.28.1.0/30
tnsr(config-vpf-filter-rule)# to ipv4-prefix 10.28.1.0/30
tnsr(config-vpf-filter-rule)# to port 8000
tnsr(config-vpf-filter-rule)# exit
This rule allows VPF HA state synchronization traffic inbound to this node from the peer:
tnsr(config-vpf-filter-ruleset)# rule 11
tnsr(config-vpf-filter-rule)# description Allow inbound VPF state synchronization
tnsr(config-vpf-filter-rule)# pass
tnsr(config-vpf-filter-rule)# direction in
tnsr(config-vpf-filter-rule)# ip-version ipv4
tnsr(config-vpf-filter-rule)# protocol udp
tnsr(config-vpf-filter-rule)# from ipv4-prefix 10.28.1.0/30
tnsr(config-vpf-filter-rule)# from port 9000
tnsr(config-vpf-filter-rule)# to ipv4-prefix 10.28.1.0/30
tnsr(config-vpf-filter-rule)# to port 8000
tnsr(config-vpf-filter-rule)# exit
This rule allows all other traffic outbound from TNSR itself on the SYNC interface:
tnsr(config-vpf-filter-ruleset)# rule 100
tnsr(config-vpf-filter-rule)# description Pass outbound from TNSR to SYNC
tnsr(config-vpf-filter-rule)# pass
tnsr(config-vpf-filter-rule)# direction out
tnsr(config-vpf-filter-rule)# stateful
tnsr(config-vpf-filter-rule)# ip-version ipv4
tnsr(config-vpf-filter-rule)# exit
Exit out to complete the ruleset:
tnsr(config-vpf-filter-ruleset)# exit
Next, activate the SYNC filter ruleset:
tnsr(config)# vpf options
tnsr(config-vpf-option)# interface SYNC filter-ruleset SYNC-filter
tnsr(config-vpf-option)# exit
VPF NAT¶
This example uses VPF NAT to provide translation for traffic passing through the TNSR HA cluster.
See also
Outbound NAT translates LAN addresses to an external address, but in this case the external address is the VRRP IP address. This is part of providing seamless failover to the other HA node. Since the state data will be identical on both nodes, client sessions can remain active through either node.
The NAT ruleset is the same for both nodes:
tnsr(config)# vpf nat ruleset WAN-nat
tnsr(config-vpf-nat-ruleset)# description NAT out WAN
tnsr(config-vpf-nat-ruleset)# rule 1000
tnsr(config-vpf-nat-rule)# description NAT from LAN prefix using VRRP
tnsr(config-vpf-nat-rule)# direction out
tnsr(config-vpf-nat-rule)# dynamic
tnsr(config-vpf-nat-rule)# algorithm ip-hash
tnsr(config-vpf-nat-rule)# from ipv4-prefix 10.28.0.0/24
tnsr(config-vpf-nat-rule)# nat-prefix 203.0.113.228/32
tnsr(config-vpf-nat-rule)# exit
tnsr(config-vpf-nat-ruleset)# exit
tnsr(config)#
Now apply that ruleset to the WAN interface:
tnsr(config)# vpf options
tnsr(config-vpf-option)# interface WAN nat-ruleset WAN-nat
tnsr(config-vpf-option)# exit
tnsr(config)#
VPF HA State Data Synchronization¶
With the filter and NAT rules in place the next step is to configure VPF HA importer and exporter definitions for each node so they can exchange state data.
Configure the VPF HA importer and exporter on R1:
r1 tnsr(config)# vpf ha
r1 tnsr(config-vpf-ha)# importer local-address 10.28.1.1 local-port 8000
remote-address 10.28.1.2 remote-port 9000
r1 tnsr(config-vpf-ha)# exporter local-address 10.28.1.1 local-port 9000
remote-address 10.28.1.2 remote-port 8000 mtu 1500
r1 tnsr(config-vpf-ha)# exit
Configure the VPF HA importer and exporter on R2:
r2 tnsr(config)# vpf ha
r2 tnsr(config-vpf-ha)# importer local-address 10.28.1.2 local-port 8000
remote-address 10.28.1.1 remote-port 9000
r2 tnsr(config-vpf-ha)# exporter local-address 10.28.1.2 local-port 9000
remote-address 10.28.1.1 remote-port 8000 mtu 1500
r2 tnsr(config-vpf-ha)# exit
See also
Enable VPF¶
Finally, enable VPF:
tnsr(config)# vpf enable
tnsr(config)#
At this point, VPF filtering and NAT will be active and processing packets passing through TNSR.
DNS Server (Optional)¶
TNSR can optionally act as a DNS server for clients, but this gets a bit more complicated for an HA cluster. The best practice is to use an external DNS server, however TNSR can act in this role with additional configuration.
Currently the DNS server daemon is not directly compatible with using VRRP IP addresses. Due to that limitation, the available methods to make DNS service from TNSR available to clients in a redundant manner have drawbacks.
Currently there are three methods to provide DNS service from a TNSR HA cluster:
- Pass cluster addresses to clients directly:
Configure all cluster nodes as DNS servers on clients directly or via DHCP.
While this is easier to setup on TNSR, some clients do not behave well with this method. Clients may continue trying to contact a node which is offline, causing delays as DNS requests timeout before they contact other DNS servers.
- Loopback Interface DNS Server Address:
Configure a loopback interface with a unique IP address reachable by clients, then provide that address to clients as the DNS server.
As the loopback is not communicating outside of the node, it does not cause a conflict on the network and clients can reach it through either node.
This address can be an internal network address, such as one in a private or reserved network.
- Redirect DNS requests with NAT:
Configure the internal VRRP IP address in the client subnet and then use an inbound NAT rule to redirect incoming client DNS requests.
This setup is a bit more complicated than the others as it must also utilize a loopback interface, similar to the previous method, but this allows the clients to contact the VRRP address for service which is easier in some ways.
The details of this setup can be found below in DNS NAT Redirect (Optional).
Warning
Do not bind the DNS server to a VRRP address. The DNS server daemon fails to start on VRRP IP addresses unless the address is currently present and in master state. This also causes the daemon to fail at boot time even on the node which typically has a VRRP address in master state.
Configure the DNS server on R1 and bind to its LAN interface IP address:
r1 tnsr(config)# unbound server
r1 tnsr(config-unbound)# interface 10.28.0.2
r1 tnsr(config-unbound)# interface 127.0.0.1
r1 tnsr(config-unbound)# access-control 10.28.0.0/24 allow
r1 tnsr(config-unbound)# access-control 127.0.0.0/8 allow
r1 tnsr(config-unbound)# outgoing-interface 203.0.113.28
r1 tnsr(config-unbound)# exit
r1 tnsr(config)# unbound enable
Configure the DNS server on R2 and bind to its LAN interface IP address:
r2 tnsr(config)# unbound server
r2 tnsr(config-unbound)# interface 10.28.0.3
r2 tnsr(config-unbound)# interface 127.0.0.1
r2 tnsr(config-unbound)# access-control 10.28.0.0/24 allow
r2 tnsr(config-unbound)# access-control 127.0.0.0/8 allow
r2 tnsr(config-unbound)# outgoing-interface 203.0.113.29
r2 tnsr(config-unbound)# exit
r2 tnsr(config)# unbound enable
Optionally configure the TNSR dataplane to use this DNS server locally in its namespace:
tnsr(config)# system dns-resolver dataplane
tnsr(config-dns-resolver)# server localhost 127.0.0.1
tnsr(config-dns-resolver)# exit
Configure the host namespace to use external DNS servers as the service in the dataplane namespace cannot be reached directly by the host namespace.
tnsr(config)# system dns-resolver host
tnsr(config-dns-resolver)# server g1 8.8.8.8
tnsr(config-dns-resolver)# server g2 8.8.4.4
tnsr(config-dns-resolver)# exit
See also
Note
If using the NAT DNS redirect method, continue and follow the directions in DNS NAT Redirect (Optional).
DNS NAT Redirect (Optional)¶
If TNSR is acting as a DNS server and clients should use the VRRP IP address as their DNS server, this method allows that to function. The NAT redirect captures the DNS requests clients send to the VRRP IP address and redirects them to a loopback interface.
Note
The target can be an interface address on either node, but that requires the configuration to be different on each node. This method allows the same configuration to be applied to all nodes.
The configuration in this section is identical on all nodes, run the same commands on each.
First, setup a loopback interface:
tnsr(config)# interface loopback dnsredirect
tnsr(config-loopback)# instance 0
tnsr(config-loopback)# exit
tnsr(config)# interface loop0
tnsr(config-interface)# ip address 10.28.1.5/32
tnsr(config-interface)# enable
tnsr(config-interface)# exit
Next, inform the DNS server to listen on the loopback interface address:
tnsr(config)# unbound server
tnsr(config-unbound)# interface 10.28.1.5
tnsr(config-unbound)# exit
Now create a NAT redirect rule to capture the DNS requests and send them to the loopback address:
tnsr(config)# vpf nat ruleset LAN-nat
tnsr(config-vpf-nat-ruleset)# rule 100
tnsr(config-vpf-nat-rule)# description Forward DNS Requests
tnsr(config-vpf-nat-rule)# direction in
tnsr(config-vpf-nat-rule)# dynamic
tnsr(config-vpf-nat-rule)# protocol tcp udp
tnsr(config-vpf-nat-rule)# to ipv4-prefix 10.28.0.1/32
tnsr(config-vpf-nat-rule)# to port 53
tnsr(config-vpf-nat-rule)# nat-prefix 10.28.1.5/32
tnsr(config-vpf-nat-rule)# nat-port 53
tnsr(config-vpf-nat-rule)# exit
tnsr(config-vpf-nat-ruleset)# exit
Finally, apply this ruleset on the LAN interface as it must be on the same interface where the client requests originate:
tnsr(config)# vpf options
tnsr(config-vpf-option)# interface LAN nat-ruleset LAN-nat
tnsr(config-vpf-option)# exit
tnsr(config)#
DHCP Server (Optional)¶
TNSR can allocate addresses to local clients using DHCP, but doing so with HA is more complicated as the DHCP service on TNSR does not currently support HA coordination between multiple nodes.
Tip
Due to this limitation, the best practice is to use a separate external DHCP server.
Both TNSR HA nodes can act as independent DHCP servers provided they are not allocating addresses out of the same space. This is not ideal as clients may decide randomly to pick an address from one server or the other, and leases from node one cannot be honored by the other, so the servers may provide conflicting information to clients.
When configuring a DHCP server on the LAN, provide the LAN VRRP address to clients for the router. If using an external DNS server or the loopback method, provide the appropriate address to clients here. If using the NAT redirect method, provide the VRRP IP address instead.
This example uses a /24 IPv4 subnet on the LAN. There will be relatively few
clients so each server can provide addresses from half the available space. In
this example there are 100 IP addresses available for clients in the range
10.28.0.100-10.28.0.199. Each node provides addresses from half that range
each, so the total number of clients must be below 50.
Configure R1 for the start of the DHCP address range:
r1 tnsr(config)# dhcp4 server
r1 tnsr(config-kea-dhcp4)# description LAN DHCP Server (Primary)
r1 tnsr(config-kea-dhcp4)# interface listen LAN
r1 tnsr(config-kea-dhcp4)# lease lfc-interval 3600
r1 tnsr(config-kea-dhcp4)# subnet 10.28.0.0/24
r1 tnsr(config-kea-subnet4)# id 1
r1 tnsr(config-kea-subnet4)# pool 10.28.0.100-10.28.0.149
r1 tnsr(config-kea-subnet4-pool)# exit
r1 tnsr(config-kea-subnet4)# interface LAN
r1 tnsr(config-kea-subnet4)# option domain-name-servers
r1 tnsr(config-kea-subnet4-opt)# data 10.28.0.1
r1 tnsr(config-kea-subnet4-opt)# exit
r1 tnsr(config-kea-subnet4)# option routers
r1 tnsr(config-kea-subnet4-opt)# data 10.28.0.1
r1 tnsr(config-kea-subnet4-opt)# exit
r1 tnsr(config-kea-subnet4)# exit
r1 tnsr(config-kea-dhcp4)# exit
r1 tnsr(config)# dhcp4 enable
Configure R2 for the end of the DHCP address range:
r2 tnsr(config)# dhcp4 server
r2 tnsr(config-kea-dhcp4)# description LAN DHCP Server (Secondary)
r2 tnsr(config-kea-dhcp4)# interface listen LAN
r2 tnsr(config-kea-dhcp4)# lease lfc-interval 3600
r2 tnsr(config-kea-dhcp4)# subnet 10.28.0.0/24
r2 tnsr(config-kea-subnet4)# id 1
r2 tnsr(config-kea-subnet4)# pool 10.28.0.150-10.28.0.199
r2 tnsr(config-kea-subnet4-pool)# exit
r2 tnsr(config-kea-subnet4)# interface LAN
r2 tnsr(config-kea-subnet4)# option domain-name-servers
r2 tnsr(config-kea-subnet4-opt)# data 10.28.0.1
r2 tnsr(config-kea-subnet4-opt)# exit
r2 tnsr(config-kea-subnet4)# option routers
r2 tnsr(config-kea-subnet4-opt)# data 10.28.0.1
r2 tnsr(config-kea-subnet4-opt)# exit
r2 tnsr(config-kea-subnet4)# exit
r2 tnsr(config-kea-dhcp4)# exit
r2 tnsr(config)# dhcp4 enable
See also
Finish Up¶
The configuration is now complete. Clients on the LAN interface should be able to obtain an address, resolve hostnames, and make outbound connections through the TNSR HA cluster. Persistent connections should stay connected and continue to pass packets if the primary node (R1) goes offline.