Several months ago I was confronted with a dark reality. Configuring NIC card parameters on a machine running Solaris Operating System is painful. The commands are cryptic, inconsistent across NICs and often require service interruption.
Several key engineers from Solaris and I, launched an OpenSolaris project called Brussels to fix this problem. You can find project information at http://www.opensolaris.org/os/project/brussels/
The team is in the process of reaching out to user groups and getting valuable feedback. I shall make a humble attempt to increase awareness about the project by blogging about it.
An introduction to the problem of NIC configuration.
A popular NIC card on a Solaris machines is bge. On my test machine, the bge1 interface comes up with an Maximum Transfer Unit (MTU) of 1500:
#ifconfig -a
:
bge1: flags=201000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4,CoS> mtu 1500 index 3 inet 10.10.1.2 netmask ffffff00 broadcast 10.10.1.255 ether 0:3:ba:44:3e:9b
:
This machine has 2 interfaces, bge0 and bge1. Interface bge0 interface is the "primary" interface, connected to the corporate network. On the other hand, bge1 is a private lab network.
Let
us try to do something really basic. I want to increase the MTU of
bge1 to 9000, while keeping bge0 MTU at 1500 bytes. Please note that
9000 is the frame size for Jumbo frames. Is this a simple change? On
the contrary.
Step 1:
I have to search /etc/path_to_inst for certain “magic numbers”, and then add incomprehensible mumbo-jumbo to /kernel/drv/bge.conf
Details
are available in the following conversation thread:
http://www.sunmanagers.org/pipermail/summaries/2003-December/004776.html
I need to add the following magic string to the configuration file:
name="bge" parent="/pci@0,0" unit-address="8,1" default_mtu=9000
Step 2:
I would now like to apply these changes to the interface.
I have to first run “update_drv”. Unfortunately the update_drv(1M) man page provides some bad ( and cryptic) news. The man page says:
"Upon successfully updating the aliases, the driver binding takes effect upon reconfig boot or hotplug of the device".
The English language translation is as follows:
I have to unload the bge kernel module and then reload it. This implies that I would have to unplumb both bge0 and bge1 and then replumb/reconfigure all the network connections.
Unfortunately these steps will disrupt network services. In the real world, a system administrator would need to schedule down time to accomplish something as trivial as changing MTU size.
As if this was not painful already…If I were using ndd to configure any NIC parameters, then I would loose those settings while changing MTU size.
Brussels to the rescue!
Believe it or not, we have been inflicting this pain on our customers for several years. I am happy to say that we are finally waking up and fixing the problem. Project Brussels is a giant step in this direction.
How would Brussels configure MTU size on bge1? Here it is
#
ifconfig bge1 unplumb
#
dladm set-linkprop -p default_mtu=9000 bge1
#
ifconfig bge1 plumb 10.10.1.2/24 up
#
ifconfig bge1
bge1: flags=201000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4,CoS> mtu 9000 index 4
inet 10.10.1.2 netmask ffffff00 broadcast 10.10.1.255
ether 0:3:ba:44:3e:9b
Above mentioned commands were execute from an ssh session going through the bge1 interface. The other interface (bge0) was unaffected. Moreover, new settings are automatically persisted across reboots!
