CLOUD LAB

BUILDING A NESTED HYPERVISOR LAB TO TEST VARIOUS CLOUD TECHNOLOGIESRather than standing up multiple boxes to test various hypervisors, container systems and SDN infrastructure, Iwanted to try and nest all of it inside of KVM. The goal here is to stand up multiple nested virtual platformsinside of KVM for these testing purposes. This will allow me to test various API’s and environments from a singleunderlying platform without having separate physical servers laying all over the place. It is important to note youshould not expect to see outstanding performance when testing within nested hypervisors. This type of setup issolely for the purpose of testing automation, orchestration and platform interoperability.  Once you validate yourdesigns within this platform, you can roll them into a production quality hardware environment.

This entire lab is built and assembled fro scratch in effort to get the best possible performance and options forthe price. We are going to virtualize all of the L2 and L3 functionality in the lab though the virtual FreeBSDgateway device. In this design, physical switch ports will be moved into the Proxmox hypervisor and pinned tothe FreeBSD VM. The idea for this lab is to get rid of the L2 switch completely and have the virtual FreeBSDinstance become the physical switch itself. This will not only remove an unnecessary component, but also giveus better control over the physical ports without having to make an API calls or manage another device.Everything around L2, L3 and L7 firewalling will be controlled via the FreeBSD virtual gateway instances.

THE BUILD

Here is my hardware list. You can size it up or down according to your specific need:

Case: LIAN LI PC­A75. This is one massive full tower case. I chose this case for several reasons:

Build quality. LIAN LI makes all of their cases out of aluminum with high quality rivets. There are never anysharp edges you may cut your hands on.Space and design. The case is designed to maximize air flow with 3 x 120mm fans in the front, 1 x 120mmin the rear, 2 x 120mm fans in the top and 1 x 120mm fan below the power supply. This design ensures all ofthe drives are cooled uniformly and hotter air is evacuated from the case as quickly as possible. LIAN LI alsobut the power supply on the bottom of the chassis to ensure it does not obstruct the motherboard or transferunnecessary heat into the heat sink area. In addition to the excellent thermals, the case supports up to 10 x3.5″ drives for constant expansion.

2.5″ Drive Enclosures for SSD’s: Since the inside of the case is really geared toward larger 3.5″ drives, weneed somewhere to put our 2.5″ SSD’s. I decided to use the 5.5″ bays in the front of the chassis for hot swap2.5″ drive enclosure bays. This will allow quick adds/removes without having to open the cover of the chassis.AMS makes a very good unit. There are several to choose from, just make sure it will do SATA III at a minimum.

Processor, heatsinks and fans: Unfortunately, the Broadwell was not available at the time of purchase, so Iwent with the Xeon E5­2650v3. This processor provides 10 cores @ 2.30GHZ. There are two of them in thesystem, so that puts us at 20 physical cores (40 hyperthreaded). The heatsinks are Intel OEM.

The 120mm fans used throughout the chassis are Noctua NH­U12S’s. Noctua makes an outstanding fan withvery low dba. The self stabilizing oil­pressure bearing fan also contributes to longer maintenance free life. Ialways invest in high quality fans as this is one of the most common components to go in server systemsoutside of power supplies.

Memory: I chose a Crucial DDR4 2133 kit (4 x 32GB). Crucial has always provided reliable high performancememory at a good price point. They are also tend to work pretty consistently with Supermicro motherboards.

Power Supply: I wanted to make sure I had plenty of good quality power for all of the drives and add­in cards.Out of all the power supplies I have used over the years, I have found SeaSonic to be the highest quality andmost reliable. I really like the fact the Snow Silent 1050 has removable connectors so you only plug in what youneed rather than coiling up unused cables all over the place. They also use a super high quality fluid dynamicbearing fan to ensure long and trouble free fan operation. Here are some other key reasons why I continue tochoose SeaSonic:

They use 100% Japanese made solid caps, not the cheaper junk.They use Infineon fets which use lower Rds values.I have yet to run into any lower quality solder problems on the PCB.The 12V rail(s) have always performed well at high loads.The Snow Sonic 1050 is over 90% efficient even at extremely high loads.7 year warranty.Quiet and runs under 47C.

Motherboard: I choose the Supermicro X10DAC workstation/server motherboard. This board willaccommodate dual Xeon v3/v4 processors up to 160W each, 2TB of LRDIMM memory, dual 12Gbps SAS viaLSI 3008 and has three 16x PCIe slots for GPU’s (should I want to use those later). The board does NOT havean Aspeed IPMI controller or 10GbE as I did not need either of these for the lab testing I was going to beconducting. If you need IPMI or 10 GbE, you will want to look at the 100% server version of this board.

This board is a good balance of server features and workstation features that will accommodate either a type 1hypervisor (bare metal install virtual environment) or type 2 hypervisor (virtual environment installed as apackages in a running O/S). It can even be used as a normal everyday workstation with powerful hypervisor

back­end functionality as part of its daily duty (e.g. Virtual Box, VMWare Workstation, KVM with Libvirt frontend,etc).

Metadata controller and drives: In an effort to provide more discrete performance between the O/S, cachesand slow metadata tiers, I physically separated the LSI 3008 controllers. I also wanted to make sure I had betterflexibility around direct PCIe mappings into the hypervisor.

As mentioned above, I wanted the O/S and SSD’s to be on a discrete controller from the 3.5″ drives. The firstreason I did this is to ensure consistent performance patterns between SSD’s and the SAS spinning disks. Thesecond reason for this to ensure I can selectively pass the entire card through via PCI pass­thru in thehypervisor for a specific purpose (e.g. pass the NL­SAS controller through to a ZFS VM for virtual storage andloop it back through in the way of pNFS, iSCSI or iSER).

The Supermicro motherboard I selected has two on­board 12Gbps SAS ports. I also added an LSI 3008 cardwhich will be dedicated to the SAS metadata drives.The following images show how all of these connecttogether. I chose Seagate 2TB 6Gbps ES.3 drives due to lower cost for the lab and the fact I did not need12Gbps drives yet. I can always upgrade later! There will be a total of 8 ES.3’s connected directly to thecontroller. All channels are 1:1, to each drive. This insures the highest level of throughput per port.

I did have to order some special cables to ensure the proper connectivity into the SAS drives. The ports on SASdrives are all inclusive (e.g. the Molex includes both data and power in one cable).

The dual port LSI 3008 ports on the motherboard will be dedicated directly to the SSD drive enclosure. Becausethe ports coming off the board are SAS, there is a special cable needed to ensure compatibility (SAS toSATA). Luckily, Supermicro included this cable with the motherboard. The drive enclosure(s) used are the AMSVenus 4 x 2.5″. These fit right into the 5.25″ bays at the top of the chassis.

I stuck with the 8 x 120GB Intel DC3500 series SSD’s as I have had good luck with them in the past. There arefaster options out there, however the Intel’s are very reliable. In my experiences, the Intel’s handle wear levelsand put reliability in front of sheer performance. Again, I ensured each drive is 1:1 per channel for maximumthroughput.

Important: I will be using ZFS throughout the platform, so I am running all of the LSI controllers in IT mode, notIR mode. IT mode = SATA/SAS HBA (e.g. no hardware RAID), IR mode = SATA/SAS hardware RAID. Payattention to the firmware as you may need to flash to correct mode. You do not want to run a software RAIDfilesystems on a HW RAID 0 volume as it defeats the purpose of using software RAID completely. Regardless ofwhat the documents say, you can always change IT/IR modes via a flash using MegaCLI even on theembedded controllers built into the motherboards. Follow this guide to change modes on the LSI controllers.You just issue the command via MegaCLI and wait a few minutes for it to complete:

After the flash process is complete, it will tell you what mode the controller is running on. On next boot. it willalso show it during the scan:

As you can see, the onboard Supermicro controller is now running in IT mode.

Video card: I just added in a a cheap ASUS GeForce FX PCIe video card with 1GB of memory. Since I am notusing VDI at this time, I do not need anything fancy.

The system is now fully assembled and ready for the Type 1 hypervisor installation:

Operational specs:Dual XEON 10­core @ 2.30Ghz (40 virtual core w/ hyperthreading)128GB ECC DDR4 RAM16TB raw SAS storage @ 6Gbps960GB eMLC SSD storage @ 6Gbps

HYPERVISOR SELECTION AND REQUIREMENTS

Since there will be many different people of varying skill sets using this system, I wanted to make sure thehypervisor has a user friendly interface that has good role base access controls. I also wanted to make theplatform is free. With some modifications, Proxmox fits the bill.

Proxmox has some really good advanced feature sets that other hypervisors lack. Here are some areas I feltmake it ideal for this lab environment:

It uses KVM in conjunction with LXC for containers. Both products are fully automated through the GUI (ahuge plus for the less experienced users). A stated above, I wanted to make sure the platform is easy to use.ZFS is now standard in the latest releases. While Proxmox does not allow actual creation of ZFS pool fromthe GUI, it allows control and assignment of them once they are created from the command line.OVS creation and deletion is baked into the GUI. You can simply replace Linux Bridges with OVS within theGUI through a few clicks.Turnkey Linux templates are built into the product and easily downloaded.Proxmox has a pretty good set of basic RRD graphs for the overall system and each VM.Security/firewall groups are very simple to create, modify and assign through the GUI.

Here is a high level diagram for reference:

L2, L3 AND FIREWALL

We will be creating a FreeBSD PF router and firewall as he default gateway within the Proxmox virtualenvironment. PF has long been one of the most flexible and robust firewalls available. It is also 100% free! Wewill also be installing advanced l7 capabilities on the firewall as well (IDS/IPS, traffic shaping, flow monitoring,etc). Here is a list of the services/components we will be installing:

A very simple L3 routing VM for other VM’s and containers running inside of the Proxmox environment. Forthis, we will use standard BSD IP forwarding (e.g. gateway_enable=”YES” in rc.conf).A l7 firewall for ingress/egress packet filtering. We will use PF, which is now part of FreeBSD distro’s bydefault. We do, however, need to recompile the kernel to fully enable all of PF’s advanced capabilities.A traffic shaper. PF will also do basic traffic shaping though ALTQ. This is also easily enabled by adding theoptions into the BSD kernel followed by a recompile.Traffic flow monitoring. Since all traffic will be passing through various interfaces on this firewall, we will wantto enable basic L7 monitoring to monitor/track traffic.

Now that we have the basic firewall requirements out of the way, we need to add a few caveats:

You can use E1000 or VMXNET drives, but DO NOT use any realtek emulated drivers. They are terrible. Ialways use either a VMXNET (VMWare 10GbE interface) or Virtio (RedHat 10GbE+). If you are installing onKVM, be sure to use the the Virtio driver. If you do use the Virtio drivers you will need to disable tx/rxchecksums otherwise you will experience timeouts. I will provide an example of how to make this changepersistent via the rc.conf.It is recommended that you put the firewall on an SSD backed ZFS or LVM/Ext4 filesystem. This will allowyou to grow the pool/fs without throwing more volumes at the firewall as monitoring data retention

requirements increase.Always trim and recompile the BSD kernel. The kernel is loaded with necessary drivers by default. 75% orhigh of these drivers can be commented out. I will show you how to do this as part of the initial setup.We need to do some sysctl tuning in order to get the firewall up to 10Gbps spec. I will go over the sysctl’s inmore detail later in the guide.

PREPPING THE NEW SYSTEM

We will need to download and install the base hypervisor platform the BSD firewall will be installed on. Proxmoxis a type 1 hypervisor, so it will install entirely from a USB stick or DVD. Here are some basic hardwarerequirements the underlying hypervisor should meet:

The hypervisor should have at least (2) 1GBE or 10GBE interfaces. Each of these interfaces will be pinnedthrough the hypervisor to the BSD gateway VM.Depending on the size of the PF implementation (tables, states, etc), it can be somewhat CPU heavy. It isrecommended at least (2) cores are allocated with NUMA enabled.  NUMA will ensure more consistentscheduling and improved memory pages.You will want to dedicate a minimum of 16GB of memory to the BSD gateway VM, especially if the VM isusing ZFS for root as ZFS is memory intensive.Use the default KVM64 processor type for the BSD gateway VM.Use Virtio for the underlying disk driver rather than the default LSI virtual contoller. The Virtio driver willprovide more consistent writes and reads.It is recommended you remove the default vmbr0 and replace it with an OVS. I would also do the same withthe secondary interface that will be pinned into the FreeBSD gateway VM. Why OVS vs. bridges? OVSforwards in kernel and the fact it stores datpaths in memory ensures must faster performance. OVS also hasbetter flexibility around aggregation, taps, spanning, etc.Ensure you have a good quality NIC. This means something other than an Intel. My recommendation is aChelsio T5 as they have a much better hardware offload. They also exhibit better throughput characteristicswhen under excessive load.Go with XEON Broadwell processors rather than Haswell if you can. Why is this?

The Broadwell line will give you a 20 – 25% performance boost when using AES encrypted workloads.The updated ADCX/ADOX instructions will further increase asymmetric workloads. The newer versions ofOpenSSL will take full advantage of these improvements, so plan accordingly.VM exit overhead is greatly reduced. Broadwell designs eliminate the additional burden of dealing withAPIC R&W Register Access. This new process is called “posted interrupts” and the support is built intonewer versions of KVM.

VM exit overhead is greatly reduced. Broadwell designs eliminate the additional burden of dealing withAPIC R&W Register Access. This new process is called “posted interrupts” and the support is built intonewer versions of KVM.

Since the purpose of this envionment is a lab, I just installed the root O/S to one SSD. If you want/needadditional redundancy, just throw two SSD’s into a RAID 1 mirror prior to the installation.

HYPERVISOR INSTALLATION

Installing Proxmox is very easy. Just follow the prompts. All that you will need to do is configure the primaryinterface so you can connect to the web console after the system reboots. The remaining configuration will bedone via CLI and GUI. After the system reboots, you will connect to the IP you specified during the installation toeither login via SSH or through the GUI:

You will now want to finish your networking configuration and setup you storage pools. Let’s start with the rootLinux Bridge conversion and creation of the secondary OVS for the secondary NIC:

1. Navigate to the Proxmox node (PVE1) and select network on the top of the navigation bar.2. Select the root Linux Bridge and select remove. eth0 will now be unassigned.3. Select create and select OVS Bridge. Fill in all the information (IP, Gateway, etc) just as it was specified in theLinux Bridge and pin it to eth0. Save the configuration.

4. Reboot the node and test IP connectivity.5. After the primary OVS Bridge is deemed working after reboot, configure the secondary OVS and pin it toyour other NIC (e.g. eth1).You will want to ensure you have an ip address attached to the interface prior toreboot as well.

6. You will need to reboot once again. Upon successful reboot, ping the interface from the pve console toensure it is working properly.

7. You are now ready to build the storage layout.

STORAGE

We are going to use ZFS. Here is why:

ZFS is mature and free of obnoxious hardware RAID card underpinnings. You create your own VDEV’s andsoftware RAID’s, otherwise known as RAIDZ’s.ZFS has an excellent second level caching mechanisim called L2ARC. This cache can be distributed acrosslow latency SSD’s or NVMe’s for increased performance. The important point is the second tier cachesreside wherever you want them.ZFS is free and now implemented into Linux, otherwise known as ZOL (ZFS on Linux). This does NOT useFuse, so you can expect better native performance now when using ZFS on Linux.ZFS primary caching operations use cheap NVRAM by default. Need more cache? Just add more real cheapRAM.ZFS scales into the Petabytes easily.ZFS includes dedupe, compression and nmband by default.You can add drives into existing pools with one simple command.You can put your intent logs, otherwise known as ZIL on any disks you want, including SSD’s.

Here is a quick high­level diagram I put together showing the different components of ZFS:

As mentioned previously, Proxmox does some level of ZFS provisioning, but you must build the basic storagepools first. There are two different ZFS pools we are going to build:

One pool on the SSD’s for QCOW2’s that require higher IOPS. This pool will have its own L2ARC and Intentlogs as part of the overall pool. For the purposes in the lab, it will configured as a RAIDZ (equivalent to RAID5). If this was an extremely high­performance environment, you would want to consider using the SSD’s in amirrored V­DEV configuration. Two SSD’s out of the eight will be used as L2ARC and ZIL for the slower SASdisks.One pool on the slower SAS drives. This will also be a RAIDZ pool allowing one parity stripe. This pool will belarge @ 10TB in size. All normal QCOW’s will reside here. As mentioned previously, these SAS drives willhave an L2ARC and ZIL on two of the Intel DC3500 SSD’s. This will ensure uniform performance at higherloads.

Let’s create the ZFS pools:

1. You will need to ensure you have all of the device id’s. Do a dmesg | more and record the device id’s.2. Once you have all of the device id’s, create the SSD high IOPS pool:

zpool create ‐f ‐o ashift=12 <pool‐name> <device> log <log_device>

3. Now create the zpool on the slower SAS disks with Intent Log and L2ARC each on an SSD:

zpool create ‐f ‐o ashift=12 <pool‐name> <device> cache <cache_device> log <log_device>

4. Once the zpools are created, we will assign them in Proxmox. This is done by selecting the datacenter. thenstorage. You will then select “Add” then ZFS. Fill in the ID you created in the previous step. Once this isdone, you can select the ZFS Pool you wish to assign. Promox let’s you define the purpose of the pool. SinceI will be using this pool for QCOW2’s and containers, I will select those as the content options. After you aredone, hit “Add”. That is it. You can now start using the ZFS pool for VM’s and content.

Now that all of the ZFS pools have been created and the OVS’s are setup, we need to make some systemtweaks to ensure proper nested operation. First, let’s see what the current nested state looks like:

root@proxmox:~# cat /sys/module/kvm_amd/parameters/nested                                                                                                                                                                                                         0

If the response comes back as “0”, you will need to change the nested state:

echo “options kvm­intel nested=1” > /etc/modprobe.d/kvm­intel.conf

Now we can either reboot the server or just do a modprobe to load in the modules:

modprobe ‐r kvm‐intel modprobe kvm‐intel

Check the status again. It should now show a “1” for enabled:

root@proxmox:~# cat /sys/module/kvm_amd/parameters/nested                                                                                                                                                                                                         1

VIRTUAL BSD FIREWALL

Proxmox is very complete, but it does not provide any advanced L2, L3 or L7 capabilities. To enable gatewayfunctionality between all of the VM’s and beyond, we are going to build a virtual BSD router from scratch.Alternatively, you can use something quick like PfSense, ClearOS, etc, but I prefer the high level ofcustomization and lack of bloat the basic BSD installation provides.

You will need to download the latest FreeBSD ISO and download it into Proxmox. I highly recommend usingFreeBSD 11 current as it has some key optimizations around ZFS and PF version 10 does not have. Once thefirewall has been downloaded and uploaded into Proxmox, make the following customizations prior to startingthe VM:

Create two bridges (one bound to each OVS is Proxmox) and assign an E1000 driver to each. Do NOT use avirtio driver… there are still some issues with rx/tx checksums that need to be resolved.When creating the hard disks, you can use a SATA or Virtio driver. I do recommend using the Virtio driver fordisk as it seems to perform better.Change the processor type from KVM64 to QEMU64.Use 16GB of memory, especially given the BSD VM will be using ZFS.

Install FreeBSD with the following installation options:

Install src, ports and docs.Use ZFS as the root filesystem. ZFS provides better flexibility over UFS.Assign the IP for you egress NAT to the first em0 interface. There is no need to configure em1 at this time.We will do this via rc.conf at a later time when we go to setup PF.

Once BSD is up and running, you will want to trim the kernel down, add PF device/options, recompile and installthe new kernel.

To recompile the kernel:

cd /usr/src/sys/amd64/conf

Locate the kernel file called “GENERIC” and copy it:

cp GENERIC ../NEWKERNEL

Edit the file and comment out all of the drivers you will not be using. Note: Be extremely careful doing this. If youdisable the wrong controller driver, etc the system may not boot back up! If you are unsure, just leaveeverything alone.

While in the new kernel file, you need to add PF and all of the PF options. Without this, the firewall will not run.Add the following in the devices section:

device          pf device          pflog

And the options for QOS:

options         ALTQ options         ALTQ_CBQ        # Class Based Queuing (CBQ) options         ALTQ_RED        # Random Early Detection (RED) options         ALTQ_RIO        # RED In/Out options         ALTQ_HFSC       # Hierarchical Packet Scheduler (HFSC) options         ALTQ_PRIQ       # Priority Queuing (PRIQ)

Save the new kernel file, cd to /usr/src, recompile the kernel, install the kernel and reboot. This process will takearound 15 minutes.

cd /usr/src make buildkernel KERNCONF=NEWKERNEL && make installkernel KERNCONF=NEWKERNEL && reboot

Once rebooted, you are now ready to configure your secondary network interface. This will be used for theinternal subnets. If you used E1000 drivers, the interface will be em1. Remember, em0 will be your externalNAT egress.

Let’s add the second interface, pf and gateway options into the rc.conf. Open /etc/rc.conf in the editor of yourchoice and add the following. We will get into adding DHCPD, local unbound and other services after the initialsetup steps.

ifconfig_em1="inet <your ip> netmask <your netmask>" gateway_enable="YES" pf_enable="YES" pf_rules="/etc/pf.conf" pf_flags="" pflog_enable="YES" pflog_logfile="/var/log/pflog" pflog_flags="" ftp_proxy_enable="YES"

Now let’s build our pf.conf. This is a simple initial config just to get things up and running. Later, we will add intables, anchors, QOS and other goodies. Start of by copying the pf.conf sample file into /etc/:

cp /usr/share/examples/pf/pf.conf /etc

Now edit the file and change as needed. I added comments to help you along:

root@local:~ # vi /etc/pf.conf # $FreeBSD: head/share/examples/pf/pf.conf 293862 2016‐01‐14 01:32:17Z kevlo $ # $OpenBSD: pf.conf,v 1.34 2007/02/24 19:30:59 millert Exp $ # # See pf.conf(5) and /usr/share/examples/pf for syntax and examples. # Remember to set gateway_enable="YES" and/or ipv6_gateway_enable="YES" # in /etc/rc.conf if packets are to be forwarded between interfaces. 

# Modify to reflect your interfaces  ext_if="em0" int_if="em1" 

#table <spamd‐white> persist 

# There is no need to filter local interface traffic, so set skip set skip on lo 

# We don't want scrub overhead in the lab #scrub in 

# Long standing issue with PF and active and passive FTP traffic. Add a proxy to resolve. nat‐anchor "ftp‐proxy/*" rdr‐anchor "ftp‐proxy/*" # This establishes outbound NAT nat on $ext_if inet from !($ext_if) ‐> ($ext_if:0) # Redirection rule to get FTP traffic through ftp_proxy rdr pass on $int_if proto tcp to port ftp ‐> 127.0.0.1 port 8021 #no rdr on $ext_if proto tcp from <spamd‐white> to any port smtp #rdr pass on $ext_if proto tcp from any to any port smtp \ # ‐> 127.0.0.1 port spamd 

anchor "ftp‐proxy/*" 

# Pass all traffic on internal subnets pass in on $int_if # Pass everything outbound on the egress NAT pass out 

#pass quick on $int_if no state #antispoof quick for { lo $int_if } 

#pass in on $ext_if proto tcp to ($ext_if) port ssh #pass in log on $ext_if proto tcp to ($ext_if) port smtp #pass out log on $ext_if proto tcp from ($ext_if) to port smtp 

#pass in on $ext_if inet proto icmp from any to ($ext_if) icmp‐type { unreach, redir, timex }

Save the pf.conf and reboot. After the reboot, issue the following commands to ensure PF is working:

pfctl ‐s info

You should see some traffic stats if things are running properly:

If you do not see any stats, run the following command:

pfctl ‐Fa ‐f /etc/pf.conf

This will usually tell exactly why PF is not loading. Fix the offending area and reload with the same command.

OPTIMIZING PERFORMANCE

Now that the gateway configuration is out of the way, we can move forward with the other performance tweaks.We will do most of this through /etc/sysctl.conf on the Proxmox node:

# tcp_mem adjustments will increase the barriers for memory consumption modulation net.ipv4.tcp_mem=1280000 1280000 1280000 net.ipv4.tcp_wmem = 32768 131072 1280000 net.ipv4.tcp_rmem = 32768 131072 1280000 # Increase TCP window sizes to accomodate 10GbE workloads net.core.rmem_max=16777216 net.core.wmem_max=16777216 net.core.rmem_default=16777216 net.core.wmem_default=16777216 # Define socket buffer maximum ‐ 10GbE operations net.core.optmem_max=1524288 # Disable tcp timestamps. We don't need them in this configuration. Lower overhead net.ipv4.tcp_sack=0 net.ipv4.tcp_timestamps=0 net.ipv4.tcp_window_scaling=1  # Enable auto tuning of network stack net.ipv4.tcp_moderate_rcvbuf=1 # Set the network input buffer length to support high speed 10GbE operations net.core.netdev_max_backlog=30000 # Disable caching of TCP connection states. Again, we do not need this in the lab.  net.ipv4.tcp_no_metrics_save=1 # Change to the CUBIC congestion control algorithm vs. RENO. 2.6.18+ kernels do much better with CUBIC.

Now we will want to apply these new sysctls. You can either reboot or just issue a sysctl ­p /etc/sysctl.conf.

Let’s do some quick checks with iperf to ensure we are seeing the desired performance and latencies:

We need to start the iperf server listener on the Proxmox server:

iperf ‐s

And finally issue the command on the CentOS VM I setup for testing:

iperf ‐c 172.168.101.254 ‐il‐t 10 ‐m

Looking good! I am seeing roughly 26.1 Gbit/s from the Proxmox box into a standard CentOS test VM. Bothhave Virtio network drivers and the sysctls outlined above installed.

Now let’s make sure we are squeezing maximum performance out of the FreeBSD gateway itself. First, we willadd the sysctl entries. Open /etc/sysctl.conf in your favorite editor and add the following:

# Fast packet forwarding in BSD will give you a 30% gain in overall packet forwarding performance.

kern.maxfiles=51200 kern.ipc.somaxconn=2048 # set to at least 16MB for 10GE hosts kern.ipc.maxsockbuf=16777216 # socket buffer tuning to ensure adequate buffer space for 10GbE workloads net.inet.tcp.recvspace=4194304 net.inet.tcp.sendspace=2097152 net.inet.tcp.sendbuf_max=16777216net.inet.tcp.recvbuf_max=16777216net.inet.tcp.sendbuf_auto=1 net.inet.tcp.recvbuf_auto=1 net.inet.tcp.sendbuf_inc=16384 net.inet.tcp.recvbuf_inc=524288 # IP forwarding must be turned on in the kernel when gateway mode is enabled. net.inet.ip.forwarding=1  # This will speed forwarding requests. net.inet.ip.fastforwarding=1 net.inet.tcp.cc.algorithm=htcp net.inet.tcp.cc.htcp.adaptive_backoff=1 net.inet.tcp.cc.htcp.rtt_scaling=1 # This will increase the maximum amount of data that can be sent in a segment. net.inet.tcp.mssdflt=1460 

net.inet.tcp.minmss=536 net.inet.tcp.syncache.rexmtlimit=0 net.inet.ip.maxfragpackets=0  net.inet.ip.maxfragsperpacket=0 net.inet.tcp.abc_l_var=44 net.inet.ip.rtexpire=10 net.inet.tcp.syncookies=0 net.inet.tcp.tso=0 hw.kbd.keymap_restrict_change=4 kern.msgbuf_show_timestamp=1  kern.randompid=7890  net.inet.icmp.drop_redirect=1  net.inet.ip.check_interface=1  net.inet.ip.process_options=0  net.inet.ip.random_id=1  net.inet.ip.redirect=0  net.inet.tcp.always_keepalive=0  net.inet.tcp.blackhole=2 # More Syn/Fin flood protection net.inet.tcp.drop_synfin=1  net.inet.tcp.fast_finwait2_recycle=1  net.inet.tcp.icmp_may_rst=0  net.inet.tcp.msl=5000  net.inet.tcp.nolocaltimewait=1  net.inet.tcp.path_mtu_discovery=0  net.inet.udp.blackhole=1  security.bsd.hardlink_check_gid=1  security.bsd.hardlink_check_uid=1  security.bsd.see_other_gids=0  security.bsd.see_other_uids=0  security.bsd.stack_guard_page=1  security.bsd.unprivileged_proc_debug=0  security.bsd.unprivileged_read_msgbuf=0 vfs.zfs.min_auto_ashift=12

Now load in all the new sysctl’s:

sysctl ‐p /etc/sysctl.conf

Now that the performance optimiztion part of the firewall is out of the way, let’s look at installing those additionalservices:

The first one will be DHCPD. During the initial install, you selected the ports tree, so you should be ready toinstall from ports. To install the ISC DHCP server, issue the following command:

cd /usr/ports/net/isc‐dhcp42‐server && make install clean

Now edit the configuration file /usr/local/etc/dhcpd.conf. You will declare your subnet and options. You can usemy dhcpd.conf as an example:

$ more dhcpd.conf # dhcpd.conf 

option domain‐name "somedomain.tld"; option domain‐name‐servers 172.168.101.1, 8.8.8.8; 

default‐lease‐time 600; max‐lease‐time 7200; 

subnet 172.168.101.0 netmask 255.255.255.0 { } 

subnet 172.168.101.0 netmask 255.255.255.0 {  range 172.168.101.150 172.168.101.180;  option domain‐name‐servers 172.168.101.1;  option domain‐name "somedomain.tld";  option routers 172.168.101.1;  option broadcast‐address 172.168.101.255;  default‐lease‐time 7200;  max‐lease‐time 7200; }

Save the dhcpd.conf and configure rc.conf to load the ISC daemon on next boot with all necessary options:

dhcpd_enable="YES" dhcpd_flags="‐q" dhcpd_conf="/usr/local/etc/dhcpd.conf" dhcpd_interfaces="em1" dhcpd_withumask="022"

Be sure to bind DHCPD to the internal interface only. Granted PF will block UDP DHCP requests on the egressinterface when asked to, it is still bad practice to bind a service like this to all interfaces. In this case, I onlybound to em1 (the internal interface).

Now we need to ensure we have a local DNS forwarder setup. Here is my /var/unbound/unbound.conf as areference. Just change the forwarders and IP’s accordingly. I do recommend putting an ACL to control wherethe queries are coming from. I will go into more advanced PF options that will restrict this further.

 root@myfirewall:/var/unbound # more unbound.conf # This file was generated by local‐unbound‐setup. # Modifications will be overwritten. server:  interface: 172.168.101.1  interface: 127.0.0.1  username: unbound  directory: /var/unbound  chroot: /var/unbound  pidfile: /var/run/local_unbound.pid  auto‐trust‐anchor‐file: /var/unbound/root.key  access‐control: 172.168.101.0/24 allow  access‐control: 127.0.0.1/32 allow include: /var/unbound/forward.conf include: /var/unbound/lan‐zones.conf include: /var/unbound/control.conf include: /var/unbound/conf.d/*.conf

Now you need to enable unbound in the rc.conf. You can do this by adding:

local_unbound_enable="YES"

Reboot and you should now be able to accept local queries. Make sure the IP’s and ACL’s are correct in/var/unbound/unbound.conf if you experience any issues with queries.

In addition to standing up the basic firewall and routing services, I also want to examine traffic flows. To do this,we are going to use NTOPNG. There is still an issue with the FreeBSD port/package, so you will need tocompile it from source. Ensure git is installed and run the following commands:

git clone https://github.com/ntop/ntopng.git  cd ntopng ./autogen.sh  ./configure  make  make install

After you have sucessfully installed ntopng, you will need to create a startup script. Navigate to/usr/local/etc/rc.d and create a new file called ntopng.sh and add the following into it:

#!/bin/sh 

# PROVIDE: ntopng startup script 

. /etc/rc.subr 

name="ntopng" rcvar=ntopng_enable start_cmd="/usr/local/bin/ntopng ‐p $pidfile 2>&1 &" 

# I know it is not graceful, but what the hell ;) stop_cmd="killall ‐HUP ntopng" 

load_rc_config $name 

ntopng() {  if checkyesno ${rcvar}; then  ........  fi } 

run_rc_command "$1"

Now you want to ensure the service starts on next boot. Add the following into /etc/rc.conf

ntopng_enable="YES" redis_enable="YES"

You can now start the ntopng service:

service ntopng start

After startup is complete, log into the web interface. Note: If you have adjusted your local subnet PF rulesoutside of defaults, you need to create a rule for port 3000 (The ntopng web port).

http://<yourgatewayip>:3000

Enter your admin/password and you should already see some traffic flowing:

Excellent! We can now see traffic flows across em0 and em1. Everything will be stored persistently into a redisDB on the gateway localhost.

You are now ready to build nested hypervisors, Docker, normal VM’s and anything else you can think of insideof this environment. Revision 2 of this guide will have all of the advanced automation and provisioninginstructions. Keep an eye out for it in the next month or so.

Ian