Going live

From freebsd.xn--wesstrm-f1a.se

Jump to: navigation, search



Time has come to throw out your old crappy broadband router and replace it with the monster you've just built. Connect your external interface directly to your DSL or cable modem and the other interface to a stand-alone switch - don't use the built-in switch on your old router. Also connect at least one of your internal computers to the switch and start everything up. You should now perform a few tests and do some final tuning.


Verifying functionality

Monitor the router while it boots and make sure there are no errors or long delays, then logon and verify that your network interfaces have IP addresses and that their status is listed as active.

# ifconfig

You should now configure one of your internal machines to use DHCP temporarily and check that it correctly receives an IP configuration from the router. Using the examples from this wiki its IP address should be between and (it will most likely be and the default router and name server should both point to the router's internal IP address You can now use the ping command in your computer to ping www.freebsd.org for example and make sure you get a reply. Browsing some sites with your web browser would be a final test to perform. If everything works you should reconfigure your computer to use a static IP address again outside the DHCP range. This is necessary to do port forwards.

Adjusting up_limit

Screenshot of a Xavi DSL modem status page showing upstream sync speed.
For the traffic shaping to work correctly you must never overload your upload bandwidth. It's not a trivial task to determine exactly what your upload bandwidth is and it's complicated by the fact that it can change for several reasons. If you have a DSL connection your modem is likely to resync from time to time and it can happen as often as several times a day. It adjusts itself to the current condition of your phone line and the speed can easily vary a 100Kbit/s up or down. A cable modem is slightly better since it will always keep the same sync speed but since several people share a limited amount of bandwidth on the antenna segment you're connected to, your speed can decrease if your neighbours are heavy users. This effect can also hit DSL users but for other reasons. For a cable connection I would recommend that you set the value of up_limit as close as possible to your true upload speed. But if you are a DSL user and you don't want to constantly tune your up_limit you will have to choose a value a few 100Kbit/s below your true speed.

Whatever method you choose you need some way of determining what value to choose and I will give you a few hints. In any case you have to understand that there is a bit of trial and error involved. You could of course choose a very low value and always have the traffic shaping work but then you wouldn't use the full potential of your upload so let's try to find a better approach.

One rather easy approach is to check the sync speed of your DSL modem. Many modems have a web based control GUI accessible through a 192.168.x.x-address. But since the modem is located on the external interface of the router and the subnet there is different than the 192.168.x.x you can't browse to it unless you specifically tell the router how to find the modem. You have to perform a little trick with the routing table and you need the modem's IP address (should be listed in the modem's manual) and its MAC-address (it's usually printed on the modem itself). Enter the following command in the router's console:

# route add -host -link em1:00:01:38:8d:58:56 -iface -static

The IP address, the network interface name and the MAC-address all have to match yours of course. After this command is entered you can browse to your modem. You can even make this setting permanent by adding the following two rows to /etc/rc.conf:

route_dsl="-host -link em1:00:01:38:8d:58:56 -iface -static"

In the example at right you can see the status screen of my Xavi X5258 DSL modem. The upstream sync speed is listed as "Us Rate (Kbps)" and is 2192 here. The sync speed is not the real upstream speed you can achieve because there is some of overhead involved that reduces it. I have found that 87% of the sync speed is a good value for up_limit which would be 1907 kbit/s but I would round that down to 1900 in this case.

Another approach would be to temporarily set a value for up_limit that is known to be too high and then start an upload and measure what speed you can actually achieve. For this to be effective you must choose a method of generating upload that will use all your available bandwidth and to seed a popular bittorrent file would probably work. When you have started the upload you can type the following command in the console:

# pfctl -vvsq

You will see an output similar to the one below that will refresh every five seconds.

queue root_em1 on em1 bandwidth 3Mb priority 0 cbq( wrr root ) {q_def, q_pri}
  [ pkts:      83260  bytes:  115585107  dropped pkts:      0 bytes:      0 ]
  [ qlength:   0/ 50  borrows:      0  suspends:      0 ]
  [ measured:   178.3 packets/s, 1.96Mb/s ]
queue  q_def on em1 bandwidth 300Kb qlimit 400 cbq( borrow default ) 
  [ pkts:      73187  bytes:  103770566  dropped pkts:      0 bytes:      0 ]
  [ qlength:   0/400  borrows:  73139  suspends:      0 ]
  [ measured:   153.1 packets/s, 1.71Mb/s ]
queue  q_pri on em1 bandwidth 2.70Mb cbq( borrow ) {q_hv, q_p2p, q_p1, q_p2}
  [ pkts:          0  bytes:          0  dropped pkts:      0 bytes:      0 ]
  [ qlength:   0/ 50  borrows:      0  suspends:      0 ]
  [ measured:     0.0 packets/s, 0 b/s ]
queue   q_p2p on em1 bandwidth 270Kb priority 3 cbq( borrow ) 
  [ pkts:       7714  bytes:   11640343  dropped pkts:      0 bytes:      0 ]
  [ qlength:   0/ 50  borrows:   4251  suspends:      0 ]
  [ measured:    20.4 packets/s, 246.48Kb/s ]
queue   q_p1 on em1 bandwidth 540Kb priority 5 cbq( borrow ) 
  [ pkts:        334  bytes:      54124  dropped pkts:      0 bytes:      0 ]
  [ qlength:   0/ 50  borrows:      0  suspends:      0 ]
  [ measured:     0.6 packets/s, 455.20 b/s ]
queue   q_p2 on em1 bandwidth 1.89Mb priority 7 cbq( borrow ) 
  [ pkts:       2021  bytes:     118830  dropped pkts:      0 bytes:      0 ]
  [ qlength:   0/ 50  borrows:      0  suspends:      0 ]
  [ measured:     4.3 packets/s, 2.00Kb/s ]

It shows the current bandwidth utilization in each of the queues you have defined. Let it run for a while and monitor the far right value on the fourth row. It shows the current total upload speed (1.96Mb/s in this example) and it shouldn't vary much. 1.96Mb/s is the same as 1960Kb/s (yes, it's decimal bits here) and very close to the value 1907 that was reached in the first method. So a value of 97% or so of what you reach here would probably be an optimal number for up_limit.

When you have changed the up_limit value, you don't have to restart the router for it to take effect. You can simply reload the firewall rules but first check that there are no errors in the file:

# pfctl -nf /etc/pf.conf

Then you flush the current queue rules and reload the configuration file.

# pfctl -F queue ; pfctl -f /etc/pf.conf
altq cleared

Now the new up_limit is active. If you make changes to the rules or NAT (port forwarding) you can use the same command above to reload the changes without rebooting but instead of flushing queue you flush rules or nat.

Now you have a fully working traffic shaping router/firewall but you really should consider installing and configuring the services described in the next chapter of this wiki.


  • route can be used to manipulate the routing table.
  • To view the routing table, type netstat -rn

Unresolved issues

  • Some general mechanism to automatically monitor the true upload bandwidth to adjust the altq definition on-the-fly. Parsing the sync speed of the modems who provide such data is of course achievable through a script but not available always.

Next guide: Keeping your domain name updated
Personal tools