VIMAGE Jails, renamed bridge devices, and errors.

This is something that I had noticed on 10.3 —

While putting together a Mininet Switch class that uses the if_bridge network bridge device, I noticed that there was some strange behavior: I would create a bridge within a jail, rename it, and when it came time to destroy it, I would receive an error:

ifconfig: SIOCIFDESTROY: Invalid argument

(If the ifconfig makes you wonder – Mininet Switch objects are merely references to shells started in a network namespace, or in my case, a jail, so they work as glorified shell scripts that configure a software switch of your choice.)

The bridge would then get destroyed along with the jail when Mininet runs jail -r, upon which it becomes “lost”. Trying to create another bridge with the same original name afterwards would fail:

# ifconfig bridge2 create
ifconfig: SIOCIFCREATE2: File exists

Manually recreating the steps that Mininet runs through with jexec let me reproduce this odd behavior.

# jexec 26 ifconfig bridge create
# jexec 26 ifconfig bridge2 | grep bridge
bridge2: flags=8802 metric 0 mtu 1500
# jexec 26 ifconfig bridge2 name test2 
# jexec 26 ifconfig test2 | grep test
test2: flags=8802 metric 0 mtu 1500
# jexec 26 ifconfig test2 destroy
ifconfig: SIOCIFDESTROY: Invalid argument

Playing around a bit more revealed that renaming it back to any name of the original format (bridge[n], n a number), would allow the bridge to be destroyed using that new-new name:

# jexec 26 ifconfig test2 name bridge100
# jexec 26 ifconfig -a | grep bridge
bridge2: flags=8802 metric 0 mtu 1500
# jexec 26 ifconfig bridge100 destroy
# jexec 26 ifconfig -a | grep bridge

Another option is to pull the renamed bridge from the jail, and to destroy it in the host environment.

The workaround in my case was simply to not rename the bridge device to match the name of the Switch object – this also had the added benefit of reducing the number of ifconfig invocations.

Now, the correct solution would probably be to file a bug report, or to dig around myself…

UPDATE: The behavior seems to have been fixed in 11.0.

A salad of carrot greens.

Carrot greens aren’t toxic like many people seem to believe, and in fact, are very much edible. It reminds me of a tougher version of parsley with a carrot background flavor. This is an improvised chopped salad inspired by tabbouleh.


  • A small bunch (1 cup’s worth) of carrot greens, just the leafy parts
  • 1/2 US cup parsley curly or flat leaf
  • 1 cup cooked quinoa
  • 1 small tomato
  • 1 scallion, or 1/4 onion
  • 1/4 to 1 carrot, or enough for about 1/4 cup minced
  • 1 Tbsp olive oil
  • juice of 1 lemon
  • salt, pepper, sumac to taste


  1. Remove the non-leafy parts of the stems of the carrot greens as they are tough
  2. Finely chop carrot greens, parsley, carrot, tomato, and scallions/onions to about the same size.
  3. Combine quinoa with the chopped ingredients
  4. Mix together oil, lemon juice, salt, pepper, and sumac to make dressing to taste
  5. Add the dressing to the salad, and combine well
  6. Let rest in fridge for an hour or two

For a kick, add a clove of finely minced garlic.

A no-churn Earl Grey chocolate chip ice cream.

A no-churn Earl-Grey ice cream loosely based on this recipe and inspired by Smitten‘s Earl Grey chocolate chip ice cream.

The amount of cream to condensed milk can be calibrated depending on desired sweetness and firmness. I found the original recipe’s ratio to be a bit too sweet, and set too softly for my tastes, hence the very different proportions.


  • 3.5 US cups whipping cream
  • 1 can sweetened condensed milk
  • 6 heaping Tbsps Earl Grey tea
  • 4 Tbsp chocolate shavings
  • 1 tsp vanilla extract (optional)


  1. Combine the tea leaves with the cream and barely simmer for 5 minutes. let cool and refrigerate until well-chilled.
  2. Strain cream into a well-chilled bowl sitting in an ice bath.
  3. Whip the cream until peaks form.
  4. Fold condensed milk and chocolate shavings (and vanilla, if adding) into the cream.
  5. Set in freezer for at least 6 hours, or until frozen.

A red wine lentil farro stew.

A one-pot lentil stew recipe. Soaking the lentils overnight makes them cook faster, but is not necessary.


  • 1.25 US cups dry lentils
  • 1 US cup farro, rinsed
  • 2-4 tomatoes, or enough for 1.5 cups chopped
  • 1 large onion, chopped
  • 0.5 US cups parsley, chopped
  • 4 cloves garlic, minced
  • 1 US cup dry red wine
  • 1 quart stock (vegetable, chicken, beef – anything works)
  • 1 Tbsp oil
  • 2 bay leaves
  • 1 heaping tsp thyme
  • 1 tsp salt
  • pepper, lemon to taste


  1. In a medium pot, fry the onions and garlic with oil, until onion is translucent.
  2. Add tomatoes to fried onions and garlic.
  3. Once tomatoes soften, add the wine and let it simmer for a few minutes.
  4. Add lentils, parsley, thyme, bay leaves, salt, and stock. Add water or stock if the lentils aren’t covered.
  5. Simmer for 45 minutes to an hour, or until lentils are tender. Add some water if mixture gets too thick for your taste.
  6. At the 45 minute mark, add the farro.
  7. Simmer until the farro is tender, about 15 minutes.

Ladle into bowls, and serve with parsley, pepper, and/or a lemon wedge. The stew can be blended for a smoother soup.

epairs and duplicate address (DAD) warnings.

After the initial step of determining the set of commands needed to bring up a VIMAGE/jail network (described here), I started reorganizing it to more closely mimic the order in which these commands would be called by a Mininet script. The typical order of operations and their corresponding commands are roughly:

  1. Instantiate a topology (Topo) object: (no corresponding step)
  2. Add Switches and Hosts to Topo object: Start up some jails with bridges, if they are switches, and shells, if they’re hosts
  3. Interconnect the Switches and Hosts by adding Links to the Topo object: create epairs, and move the interfaces to the jails)
  4. Initialize the network with the Topo object as its topology: Bring the interfaces up, and if the jails represent switches, add the interface to the bridge

But, while trying to recreate the same –linear,2 network, I noticed the following messages in dmesg:

epair2b: DAD detected duplicate IPv6 address fe80:2::ff:70ff:fe00:40b: NS in/out/loopback=4/1/0, NA in=0
epair2b: DAD complete for fe80:2::ff:70ff:fe00:40b - duplicate found
epair2b: manual intervention required
epair2b: possible hardware address duplication detected, disable IPv6
epair3b: DAD detected duplicate IPv6 address fe80:2::ff:70ff:fe00:40b: NS in/out/loopback=4/1/0, NA in=0
epair3b: DAD complete for fe80:2::ff:70ff:fe00:40b - duplicate found
epair3b: manual intervention required
epair3b: possible hardware address duplication detected, disable IPv6

And a bit above, the following:

epair2a: Ethernet address: 02:ff:20:00:03:0a
epair2b: Ethernet address: 02:ff:70:00:04:0b
epair2a: link state changed to UP
epair2b: link state changed to UP
epair3a: Ethernet address: 02:ff:20:00:03:0a
epair3b: Ethernet address: 02:ff:70:00:04:0b
epair3a: link state changed to UP
epair3b: link state changed to UP

As the DAD (Duplicate Address Detection) warnings suggested, the same MAC (hardware) addresses were indeed being reused for the epair* interfaces being created.

Searching for the warnings eventually brought me to a thread describing the exact mechanics behind the issue – I had interleaved the steps for creating and moving the interfaces. The MAC addresses for epair* interfaces are generated from a globally tracked if_index counter. This value increases by one for each interface created (so +2 for each ifconfig epair create), and decreases by one for each destroyed or moved to a VIMAGE jail. The problem arises when epair creation is interleaved with moving them to jails; The if_index:

  1. increases by two for the first epairs created
  2. drops back down by two when they are moved, and
  3. take on the same values as for the first epairs when the next epairs are created

In fact, since the value of if_index is used directly in the 4th and 5th byte of the MAC address (first and last are hard-coded and the rest, set by other means), we can see in the dmesg output that the index values 3 and 4 are being reused repeatedly.

It also explains why I didn’t see this issue initially, since I was creating all of the epairs at once and then moving them later on, making the changes in if_index monotonic. While I could reorganize the commands so that it both follows Mininet’s conventions and the if_index doesn’t fluctuate, I manually assigned unique addresses to each epair for the time being:

# ifconfig epair1a ether 02:ff:00:00:01:14    #from s1 (jid 1) to h1 (jid 4)
# ifconfig epair1b ether 02:ff:00:00:01:41    #from s1 (jid 4) to h1 (jid 1)

Of course, I’ll use a less manual approach for generating a unique MAC address in Mininet.

[update]: if_index is not guaranteed to monotonically increase, but the number in the interface name (the ‘n’ in epair[n]) does, so I decided to use that as a base for my unique MACs.


Creating networks with VIMAGE jails and epairs.

This is part of a series of notes on the experimental process of getting Mininet to run on FreeBSD.

The first step is to identify the components and commands that are required to implement the basic features. For an emulator like Mininet, this would be 1) the ability to build custom network topologies, and 2) the ability to interact with the topology by sending traffic across it, and monitoring the traffic flowing through the network.

Custom topologies

Mininet allows users to build custom network topologies by interconnecting node and link Mininet objects. Here, jails with VIMAGE replace the mount and network namespaces used to implement the nodes, and epairs replace the veth virtual Ethernet pairs implementing the links.

This link provides clear instructions for getting VIMAGE up and running for a simple topology, making it a good place to start. At the time that this post was written, the stable release (10.2) VIMAGE isn’t enabled by default, and required a custom kernel.

Since the initial (and primary) focus at this time is in building custom topologies, the jails aren’t given their own directory trees, and their paths are set to /.

Handling traffic

In addition to being able to build out topologies, Mininet also allows users to interact with their networks with tools such as ping, traceroute, and tcpdump, which require creating raw sockets from within the jails. This can be enabled by settingĀ security.jail.allow_raw_sockets to 1, or by passing allow.raw_sockets as a command to the jail utility when creating the jails.

Finally, the jails that represent network nodes (e.g. switches and routers, as opposed to end hosts) need some mechanism to move traffic. In Mininet, this would typically be an OpenFlow-programmable software switch such as Open vSwitch or the CPqD software switch. Although the former is available in the ports collection, to reduce the number of moving parts, the if_bridge network device will be used for the time being to narrow down to the core set of commands needed to bring up a topology capable of carrying traffic.

Manual topology construction

The following steps identify the steps and commands required to manually construct what Mininet calls a linear,2 topology:

|    |
h1   h2

where h1 and h2 represent hosts on the network, and s1 and s2, the network nodes (switches).

  1. Prepare the host. After enabling VIMAGE in the kernel:
    # kldload if_bridge
    # sysctl security.jail.allow_raw_sockets=1
  2. Create jails. Since allow_raw_sockets was set in the host, there is no need to pass allow.raw_sockets to jail.
    # jail -c vnet name=s1 jid=1 path=/ persist
    # jail -c vnet name=s2 jid=2 path=/ persist
    # jail -c vnet name=h1 jid=3 path=/ persist
    # jail -c vnet name=h2 jid=4 path=/ persist

    jls should now show your jails (jls -v will show you more, including the assigned names):

    # jls
       JID  IP Address      Hostname                      Path
         1  -                                             /
         2  -                                             /
         3  -                                             /
         4  -                                             /
  3. Create bridges in the ‘network node’ jails (JIDs 1,2, and 3)
    # jexec s1 ifconfig bridge1 create up
    # jexec s2 ifconfig bridge2 create up
  4. Create virtual Ethernet links (epairs) and interconnect the jails
    # ifconfig epair1 create      # s1  h1
    # ifconfig epair2 create      # s2  h2
    # ifconfig epair3 create      # s1  s2
    # ifconfig epair1a vnet s1
    # ifconfig epair1b vnet h1
    # ifconfig epair2a vnet s2
    # ifconfig epair2b vnet h2
    # ifconfig epair3a vnet s1
    # ifconfig epair3b vnet s2
  5. Add epair interfaces to each bridge and bring them up
    jexec s1 ifconfig bridge1 addm epair1a addm epair3a
    jexec s1 ifconfig epair1a up
    jexec s1 ifconfig epair3a up
    jexec s2 ifconfig bridge2 addm epair2a addm epair3b
    jexec s2 ifconfig epair2a up
    jexec s2 ifconfig epair3b up
  6. Configure IP addresses for ‘host’ jail interfaces
    # jexec h1 ifconfig epair1b up
    # jexec h2 ifconfig epair2b up

Sanity-checking the topology

It should now be possible to ping from one host to another:

# jexec h1 ping
PING ( 56 data bytes
64 bytes from icmp_seq=0 ttl=64 time=0.046 ms
--- ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.046/0.052/0.055/0.004 ms

It should also be possible to monitor the traffic passing through a network node (e.g. by running tcpdump) while the hosts are pinging one another.


Once a topology is no longer needed, it should be torn down and the virtual links and jails destroyed.

  1. Remove epairs from jails and destroy them (removing one end of an epair destroys both endpoints)
    # ifconfig epair1a -vnet s1
    # ifconfig epair2a -vnet s2
    # ifconfig epair1a destroy
    # ifconfig epair2a destroy
  2. Destroy the bridges
    jexec s1 ifconfig bridge1 destroy
    jexec s2 ifconfig bridge2 destroy
  3. Destroy jails
    jail -r s1
    jail -r s2
    jail -r h1
    jail -r h2

The idea is that the commands (and procedures) that have been identified here can be retrofitted into Mininet.

[to be continued]

Changing pager settings for Git.

It seems that on FreeBSD, the default pager is more. For Git commands involving the pager, this has the effect of displaying ANSI color escape sequences as ‘ESC[ …’ rather than coloring the text:

$ git diff
ESC[1mdiff --git a/mininet/ b/mininet/link.pyESC[m
ESC[1mindex 9703ce7..559b5da 100644ESC[m
ESC[1m--- a/mininet/link.pyESC[m
ESC[1m+++ b/mininet/link.pyESC[m
ESC[36m@@ -25,7 +25,7 @@ESC[m
 from mininet.log import info, error, debugESC[m
ESC[31m-from mininet.util import makeIntfPairESC[m
ESC[32m+ESC[mESC[32mfrom mininet.util import makeIntfPair, quietRun

A quick search of the man pages for more (which actually leads to less(1)) shows that the -R flag would allow the raw (ANSI) control characters to be displayed properly:

       -R or --RAW-CONTROL-CHARS
              Like  -r,  but  only ANSI "color" escape sequences are output in
              "raw" form.  Unlike -r, the screen appearance is maintained cor-
              rectly  in  most  cases.   ANSI  "color"  escape  sequences  are
              sequences of the form:

                   ESC [ ... m

Setting the PAGER environment variable to ‘more -R’ is a solution, but one way to only affect Git’s behavior is to set its configurations using git config:

$ git config --global core.pager 'more -R'