ipfw improvement on FreeBSD -current

Few days ago Alexander V. Chernikov posted on the FreeBSD -net mailing list an "HEADS UP: Merging projects/ipfw to HEAD" with lot's of promises:

• Tables are now identified by names, not numbers. There can be up to 65k tables with up to 63-byte long names.
• Tables are now set-aware (default off), so you can switch/move them atomically with rules.
• More functionality is supported (swap, lock, limits, user-level lookup, batched add/del) by generic table code.
• New table types are added (flow) so you can match multiple packet fields at once.
• Ability to add different type of lookup algorithms for particular table type has been added.
• New table algorithms are added (cidr:hash, iface:array, number:array and flow:hash) to make certain types of lookup more effective.
• Table value are now capable of holding multiple data fields for different tablearg users

I'm not an expert of ipfw(8), but I would check the impact of this improved-ipfw on forwarding performance. By "performance" I mean how this code impact the throughput (in term of packet-per-second) of my FreeBSD firewall (I didn't bench all the parameters requiered by RFC3511).
Once the code was committed as r272840 on -head, I've generated a new nanobsd(8) image on my 10gigabit bench lab… and here are the results:

More than 100K pps of differences! Now I dream of an ipfw_sync equivalent to pf_sync(4).
And here are the ministat output for statistician extremists.
Regarding ipfw in stateless mode:


x 272685.ipfw-stateless
+ 273009.ipfw-stateless
+----------------------------------------------------------------------+
|x      x     x    x                                  + + +      +    +|
|   |______A__M___|                                                    |
|                                                     |___M__A_____|   |
+----------------------------------------------------------------------+
    N           Min           Max        Median           Avg        Stddev
x   5       1585928       1619817       1608891     1604564.2     12728.878
+   5       1683246       1712607       1690405     1695508.6      12250.89
Difference at 95.0% confidence
        90944.4 +/- 18219.1
        5.66786% +/- 1.13546%
        (Student's t, pooled s = 12492.2)

And regarding ipfw in statefull mode:


x 272685.ipfw-statefull
+ 273009.ipfw-statefull
+----------------------------------------------------------------------+
|xx    x   x    x                       ++   +    +                   +|
||_____A______|                                                        |
|                                    |_______M___A____________|        |
+----------------------------------------------------------------------+
    N           Min           Max        Median           Avg        Stddev
x   5       1390415       1433678       1407058     1408663.4     18451.472
+   5       1502719       1589778       1517320     1529871.8     35404.181
Difference at 95.0% confidence
        121208 +/- 41172.4
        8.6045% +/- 2.9228%
        (Student's t, pooled s = 28230.4)

PuTTY and Solarized colors

I'm using the Solarized color palette on all my FreeBSD desktops, but at work I had to works from a MS Windows desktop :-(
Here are my PuTTY settings for a correct rendering of Solarized colors.

Softwares used

• PuTTY and it's authentication agent (There is KiTTY, an improved version of PuTTY too)
• MTPuTTY (Multi-Tabbed Putty) for adding tabbed feature to PuTTY/KiTTY
• Solarized PuTTY settings

Installation steps

Installing PuTTY or MTPuTTY didn't need specials instruction.
If you're using KiTTY, the Solarized PuTTY.reg files need to be adapted by opening them into a text editor and replacing the line:
[HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\Sessions\Solarized%20Dark]
By this one:
[HKEY_CURRENT_USER\Software\9bis.com\KiTTY\Sessions\Solarized%20Dark]
Then import the .reg files.

KiTTY/PuTTY configuration

Now start KiTTY or PuTTY, load the Dark or Light Solarized session and modify this session with:

• Window - Colours : Enable "Allow terminal to use xterm 256-colour mode"
• Connection - Data - Terminal details : Terminal-type string : "xterm-256color"

You can then add more customization, for example:

• Terminal - Bell : Visual Bell
• Window - Appearance - Font Settings - Font: "Consolas" - 12point
• Window - Appearance - Font Settings - Font quality: ClearType
• Window - Translation - Remote character set: UTF-8
• Window - Lines of scrollback: 10000
• Window - Selection - Control use of mouse: xterm (Right extends, Middle Past)
• Connection : Second between keepalives: 25
• Connection : Enable TCP keepalives
• Connection - SSH - X11: Enable X11 forwarding

Once all your customization done, save the session as "Default Settings".

Checking parameters

Start a KiTTY/PuTTY, check that your preferences are loaded by default and open a SSH session to an *nix machine.
Once logged, the command "echo $TERM" should answer "xterm-256color".
And, if you've solarized your VIM (you don't need to use let g:solarized_termcolors=256!), you should correctly see the column after entering a "set colorcolumn=80".

tmux

tmux need to be configured for advertise a 256color term by adding in ~/.tmux.conf the line:
set -g default-terminal "screen-256color"

Configuration IPv6 propre d'une Kimsufi sous FreeBSD

Pour configurer une passerelle par défaut IPv6 sur un Kimsufi, le guide officiel se résume à:

1. Paramétrer l'IPv6 de votre interface avec votre préfixe /64 (2001:41D0:1:46e::/64 par exemple)
2. Suivre la règle IP:v:6:FF:FF:FF:FF:FF pour déduire votre passerelle par défaut (dans notre exemple elle est donc 2001:41D0:1:4FF:FF:FF:FF:FF).

Sauf qu'avec cette règle l'IP de la passerelle est en dehors de votre réseau (/64)… donc injoignable !
«À ce qu'il paraît» cela ne pose pas de problème aux GNU/Linux…no comment.
Une autre section du guide propose de récupérer les RA pour trouver la route par défaut "link-local" annoncée par le routeur, mais cela ne fonctionne plus car ils ont été désactivés.
La solution la plus commune à ce problème est de paramétrer un préfixe /56 à la place du /64 sur votre interface: du coup la passerelle par défaut se trouve dans votre réseau et le problème est résolus.
Mais OVH m'a donné un /64, je ne vois pas pourquoi je lui déclarerai un /56!

Une jolie solution (soufflée par flo@) permettant de paramétrer un /64 tout en utilisant cette route par défaut est la suivante:

ifconfig_re0_ipv6="inet6 2001:41D0:1:46e::1 prefixlen 64"
ipv6_static_routes="mac"
ipv6_route_mac="-host 2001:41D0:1:4FF:FF:FF:FF:FF -iface re0"
ipv6_defaultrouter="2001:41D0:1:4FF:FF:FF:FF:FF"