Networking on OS X - configd

Learn more about how OS X configures it's routes and interfaces.

This is one of the things that OS X does like no other Unix/Linux OS. So, before you pull your hair out trying to use ifconfig read this.

OS X Networking

Part 1 - Why OS X isn't like other Unixes

Let's call this the first in an occasional series on the networking "peculiarities" of OS X.

The single most common pet peeve I've heard from Unix admins coming to OS X is how to manage basic network settings. These admins are used to using ifconfig to bend their networks to their will. They've been doing it for years, it works well on every flavor of Unix/Linux out there, so it's no surprise that they continue the trend on OS X.

Of course this begins the slippery slope to one cheesed off Unix admin.

Every other Unix variant sticks to a pretty traditional, very static, network infrastructure. Let me explain before too many former Unix admins take issue with that statement. Most other operating systems are given an IP to use, and they use it. No questions, no sass. The machine will hold on to that IP come broken network or missing route statements until told otherwise. That's what I mean by static configuration.

Apple, on the other hand, wanted to change things a bit. Go figure.

Enter configd.

Instead of just taking an IP and using it, OS X wants to dynamically react to a changing network landscape. Since Macs are for grandmas in addition to admins, Apple had to make the system as usable as possible for those who are clueless about networking. This is what configd does.

When you set an IP configuration using the System Preferences that information is stored in a configuration file /Library/Preferences/SystemConfiguration/preferences.plist. Configd watches this file and waits for changes to happen.

When a change does occur, configd re-reads the entire configuration specified by this file. It breaks the configuration up by different protocol, ie. IP, AppleTalk, PPP, and sends the configuration on to a collection of agents that it has. There is an AppleTalk Agent, an IP Agent and a PPP Agent among others. These then make the changes to the interfaces as appropriate using systems calls like "ifconfig."

Configd then tells the IP Monitor Agent (IPMA), another one of configd's minions, about the network settings. The IPMA figures out what interface is highest in the list, makes that interface's gateway the default route out, and then adds routing statements to cover any other networks that might be connected to other interfaces. This dynamically builds OS X's routing table.

Makes sense so far. Everybody has a job. OS X handles the routing automatically. Cool.

There is another agent, however, that drives Unix admins into fits. The Kernel Event Monitor (KEM) waits for kernel events that tell it that an interface has gone down. When this happens it informs configd which interface has gone down. Configd then re-reads its config from the preference.plist file and sends out the new settings to the configuration agents which make sure the interfaces are configured they way they should be. This then triggers the IPMA which redoes the routing table according to the new information.

And that is what trips up the admins. They use their traditional methods of configuring an interface and use ifconfig to make it so. This works great. Until, for whatever reason, the KEM tells Configd things have changed. Configd then reverts everything back to whatever is held in the preference.plist file. This cheeses Unix admins off.

Another potential source of frustration is the fact that if an interface goes down configd will automatically remove that interface's IP from the routing table.

For example, if the ethernet cable gets unplugged from the NIC, the KEM gets the message that that interface is no more. Configd adjusts accordingly. The IP address that the interface had is no long accessible from the local machine. It's gone from the interface and its gone from the route table. Bummer. This is why you can't always depend on the IP address being there. Especially on flaky networks.

Another interesting feature of this mechanism is the kicker bundle, which can be found at /System/Library/SystemConfiguration/Kicker.bundle. This app is called when configd changes the networking configuration. It's the kicker's job to go around and restart any services that need to be told that a network change has occurred. For example, after an IP change has occurred the kicker bundle relaunches the Apple File Server and changes the local host name.

While this is a bit of a hack, you can add your own actions that occur after a network change by editing the kicker's configuration file at /System/Library/SystemConfiguration/Kicker.bundle/Contents/Resources/Kicker.xml.