When installing RARE/freeRouter on x86, you have 2 choices:
- installation with a software dataplane
- installation with a DPDK dataplane
In this precise case, we will consider a DPDK dataplane installation as our hardware is compliant to the requirement listed below.
- CPU with SSE4 support
- DPDK compatible NIC
Note that freeRouter is available where JVM is available
In this article we will pursue the SOHO network appliance installation based on the diagram below, and freeRouter installation using DPDK dataplane. In this situation, the appliance is behind ISP FTTH box demarcation point. As it is typical to French FTTH domestic deployment.
In this case, RARE/freeRouter is connected to a ISP box demarcation point that deliver copper connectivity. Nothing prevents you, following your context, to deploy a similar equipment with with SFP uplinks directly connected to your Provider Edge backbone routers if you own also the dark fiber paths local to the MAN.
[ #003 ] - RARE/freeRouter DPDK SOHO installation
Let's consider the following assumptions:
- ISP box comes with 192.168.0.0/24 subnet configured at RJ45 demarcation point
- Home networkS will be within 192.168.128.0/17
- 192.168.128.0/17 will be subnetted further into multiple /24 in order to accomodate home network requirement
- RARE/freeRouter is connected to the FTTP ISP box via appliance DPDK port #0 (interface sdn1)
- Home traffic going to outside world will be subject to port address translation (NAT/PAT) using an IPv4 within ISP subnet range
- appliance port #1 will be connected to FTTH ISP box and will have an IP within 192.168.0.0/24
IPv6 addressing plan has not been forgotten. It is not mentioned here on purpose in order to not complicate explanations. IPv6 we be the object of further articles. It is not that IPv6 is a complex topic. It just that it deserves special attention. You might not realised it, but IPv6 is everywhere and is used by default between peers as soon as IPv6 is enable. So IMHO we need to get used to it as soon as possible especially if you are a network administrator.
FreeRouter uses 2 configuration files in order to run, let's write these configuration files in /rtr
Let's spend some times on this hardware configuration file, as you might have notice there are additional interesting lines worth to mention:
- Exclamation mark "!" are comments
- hwid is a text field that would just designate the hardware on which freeRouter is running. (output of : show platform)
- proc <process-name>
It is possible within freeRouter startup to launch processes. We use here this feature to start control plane / dataplane communication via veth pair: veth0a and veth0b and also P4Emu/dpdk, p4dpdk.bin packet processing backend.
- proc p4emu /rtr/p4dpdk.bin --vdev=net_af_packet0,iface=veth0b --vdev=net_af_packet1,iface=veth2b --vdev=net_af_packet2,iface=veth1b 127.0.0.1 9080 6
In dpdk, by default dpdk interfaces have port_ids that are sequentially allocated and in the order of appearance in dpdk-devbind --status output usually sorted by pci_id. In the below output interface enp0s1 has port_id #0 and in dpdk it would be pci_id:00:01.0
enp0s1 would be: #0 with pci_id: 00:01.0
enp0s2 would be: #1 with pci_id: 00:02.0
enp0s5 would be: #2 with pci_id: 00:05.0
enp0s6 would be: #3 with pci_id: 00:06.0
enp0s7 would be: #4 with pci_id: 00:07.0
enp0s8 would be: #5 with pci_id: 00:08.0
- DPDK --vdev addition. In this precise case we instruct DPDK to take into account additional veth endpoint we created respectively for
- Control plane / data plane communication
- Linux out of band management access via SSH we installed previously during Debian package installation
- integrated hardware WIFI access point
- in DPDK vdev interface will have in order of apparition in the command line:
- DP/CP communication: 6 ↔ veth0b
- integrated WIFI: 7 ↔ veth2b
- Linux out of band management access: 8 ↔ veth1b
external WIFI access point will be bound directly to an interface of the appliance via DPDK. This will be describe in future articles.
- For now integrated wifi is shut. We will see in later article how to activate it
- At Linux level, if you noticed in the previous article
- management IP subnet is 192.168.128.0/24. OOBM appliance IP is then 192.168.128.254
- management IP seen from freeRouter@sdn999 with IP 192.168.128.1 within 192.168.128.0/24
- with configured a Linux static routes
- If you pay attention p4lang server in p4 VRF
- This VRF has no bound interface
- Is isolated then from the other VRF
- This will allow only local Linux host control plane and dataplane communication
Check Linux appliance local routes
Test local telnet access from linux/localhost
In this article
- we finally launched RARE/freeRouter with DPDK dataplane
- configure RARE/freeRouter with a vanilla config that takes into account all the appliance physical interfaces
- added veth pair in the config in order to take into account:
- Control plane / Data plane communication
- linux OOBM
- integrated WIFI
- Enabled and checked IPv4 connectivity between freeRouter@sdn1 and ISP demarcation point
- Check telnet access to freeRouter from localhost only
RARE validated design: [ SOHO #003 ] - key take-away
From this point you have a complete freeRouter connected to ISP box via SDN1 as uplink in 192.168.0.0/24 subnet. We will extend further this base configuration step by step in order to enrich user experience !
- Now you would want to enable IPv4/IPv6 connectivity to all potential hosts@home whether they are connected via RJ45 or via built-in WIFI.
- you would also want to distribute IPv4, IPv6 to all the of hosts@home
- IPv4/IPv6 connectivity is not enough, you would like to provide Domain Name Service to them
- Domain Name Service is not enough if they can't reach outside world. As we are using RFC1918 addressing plan we should figure out a way to ensure NAT/PAT address translation in order to enable egress traffic toward the Internet
- Your home might have several floors and only one WIFI access point is not enough ? Let's see how we can add additional WIFI AP in the network
- Maybe you have an outsourced network management service ? Let's see how connectivity can be enable via OpenVPN encrypted tunnel
- Last but not least, let's see how we can connect DN42 parallel network using a Wireguard tunnel relying on an IPv6 underlay.
You've guessed it, all of these points will be elaborated in the futures articles. Therefore stay tuned !