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
hwid j1900-i211 ! cpu_port int eth0 eth - 127.0.0.1 20001 127.0.0.1 20002 ! freerouter control port for message packet-in/out in P4 VRF _ONLY_ tcp2vrf 9080 p4 9080 ! freeroouter local access in p4 VRF _ONLY_ tcp2vrf 2323 p4 23 ! launch a process called "veth0" that actually link to veth0b ! cmd for control plane/dataplane communication unified messaging: ip link add veth0a type veth peer name veth0b ! cmd for appliance Linux access: ip link add veth1a type veth peer name veth1b ! cmd for integrated wifi: ip link add veth2a type veth peer name veth2b ! external wifi AP proc hostapd /usr/sbin/hostapd /etc/hostapd/hostapd.conf ! integrated wifi AP proc wlan /rtr/pcap2pcap.bin wlan0 veth2a ! DP/CP communication process proc veth0 /rtr/pcapInt.bin veth0a 20002 127.0.0.1 20001 127.0.0.1 ! DP DPDK process 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
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-devbind.py --status Network devices using DPDK-compatible driver ============================================ 0000:01:00.0 'I211 Gigabit Network Connection 1539' drv=uio_pci_generic unused=igb 0000:02:00.0 'I211 Gigabit Network Connection 1539' drv=uio_pci_generic unused=igb 0000:05:00.0 'I211 Gigabit Network Connection 1539' drv=uio_pci_generic unused=igb 0000:06:00.0 'I211 Gigabit Network Connection 1539' drv=uio_pci_generic unused=igb 0000:07:00.0 'I211 Gigabit Network Connection 1539' drv=uio_pci_generic unused=igb 0000:08:00.0 'I211 Gigabit Network Connection 1539' drv=uio_pci_generic unused=igb Network devices using kernel driver =================================== 0000:09:00.0 'AR928X Wireless Network Adapter (PCI-Express) 002a' if=wlan0 drv=ath9k unused=uio_pci_generic No 'Baseband' devices detected ============================== Other Crypto devices ==================== 0000:00:1a.0 'Atom Processor Z36xxx/Z37xxx Series Trusted Execution Engine 0f18' unused=uio_pci_generic No 'Eventdev' devices detected ============================== No 'Mempool' devices detected ============================= No 'Compress' devices detected ============================== No 'Misc (rawdev)' devices detected ===================================
- 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.
hostname mjolnir buggy ! ! vrf definition inet exit ! vrf definition p4 exit ! interface ethernet0 description freerouter@P4_CPU_PORT[veth0a] no shutdown no log-link-change exit ! interface sdn1 description freerouter@DPDK[port-1] mtu 1500 vrf forwarding inet ipv4 address 192.168.0.90 255.255.255.0 no shutdown no log-link-change exit ! interface sdn2 description freerouter@DPDK[port-2] mtu 1500 shutdown no log-link-change exit ! interface sdn3 description freerouter@DPDK[port-3] mtu 1500 shutdown no log-link-change exit ! interface sdn4 description freerouter@DPDK[port-4] mtu 1500 shutdown no log-link-change exit ! interface sdn5 description freerouter@DPDK[port-5] mtu 1500 shutdown no log-link-change exit ! interface sdn6 description freerouter@DPDK[port-6] mtu 1500 shutdown no log-link-change exit ! interface sdn998 description freerouter@DPDK[port-7 --> veth2a] integrated wifi mtu 1500 shutdown no log-link-change exit ! interface sdn999 description freerouter@OOBM[port-8 --> veth1a] Linux management mtu 1500 vrf forwarding inet ipv4 address 192.168.128.1 255.255.255.0 no shutdown no log-link-change exit server telnet telnet security protocol telnet no exec authorization no login authentication vrf p4 exit ! server p4lang p4 export-vrf inet 1 export-port sdn1 0 1 0 0 0 export-port sdn2 1 1 0 0 0 export-port sdn3 2 1 0 0 0 export-port sdn4 3 1 0 0 0 export-port sdn5 4 1 0 0 0 export-port sdn6 5 1 0 0 0 export-port sdn998 7 1 0 0 0 export-port sdn999 8 1 0 0 0 interconnect ethernet0 vrf p4 exit ! ! end
- 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
ip addr flush dev veth1a ip addr add 192.168.128.254/24 dev veth1a
- management IP seen from freeRouter@sdn999 with IP 192.168.128.1 within 192.168.128.0/24
- with configured a Linux static routes
route add default gw 192.168.128.1
- 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
ping 192.168.0.254 /vrf inet /interface sdn1 pinging 192.168.0.254, src=192.168.0.90, vrf=inet, cnt=5, len=64, tim=1000, ttl=255, tos=0, sweep=false !!!!! result=100%, recv/sent/lost=5/5/0, rtt min/avg/max/total=0/0/1/4
mjolnir#sh ipv4 arp sdn1 mac address time static 0024.d4a0.0cd3 192.168.0.254 00:00:20 false
sh int sdn1 sdn1 is up (since 13:14:14, 2 changes) description: mjolnir@LAN1[01:00.0] type is sdn, hwaddr=003b.7671.764f, mtu=1500, bw=8000kbps, vrf=inet ip4 address=192.168.0.90/24, netmask=255.255.255.0, ifcid=10014 received 64038 packets (17841459 bytes) dropped 4 packets (326 bytes) transmitted 250217 packets (38032822 bytes) promisc=false macsec=false
show interfaces summary interface state tx rx drop ethernet0 up 74690935 51798769 0 sdn1 up 37954707 17828649 326 sdn2 admin 0 0 0 sdn3 admin 0 0 0 sdn4 admin 0 0 0 sdn5 admin 0 0 0 sdn6 admin 0 0 0 sdn998 admin 0 0 0 sdn999 up 23646 17904 0
interface state tx rx drop sdn1 up 674397352 3883928390 948 sdn2 admin 0 0 0 sdn3 admin 0 0 0 sdn4 admin 0 0 0 sdn5 admin 0 0 0 sdn6 admin 0 0 0 sdn998 admin 0 0 0 sdn999 up 110520 85072 0
Check Linux appliance local routes
root@mjolnir:~# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.128.1 0.0.0.0 UG 0 0 0 veth1a
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 !