[Solaris] Changing MTU in a Solaris Zone
A workaround to zoneadmd constraint
Jul 26, 2007
To set up a network presence for a zone, the zonecfg(1M) command supports two attributes in its net resource, address and physical. These attributes give a zone its IP address and the network interface to use. A zone with network access configured would appear like this:

# zonecfg -z golden info
zonename: golden
zonepath: /zones/golden
autoboot: true
...
net:
        address: 10.9.152.150/24
        physical: bge0
...

As the example shows, we can also assign a subnet mask through the address attribute. The result is a virtual network interface that is visible both locally and globally:

# ifconfig -a
...
bge0:2: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
        zone golden
        inet 10.9.152.150 netmask ffffff00 broadcast 10.9.152.255
...

There are two ways to do this, actually. Using the zonecfg command is one way. The other way is to set the interface in the global zone, using the ifconfig command, and assign it to a local zone. For example:

# ifconfig bge0 addif 10.9.151.160 zone golden
Created new logical interface bge0:4

# ifconfig bge0:4
bge0:4: flags=1001000842<BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
        zone golden
        inet 10.9.151.160 netmask ff000000 broadcast 10.255.255.255

Defining the net resource through the zonecfg command is the conventional form. However, if you have to change others attributes, such as the Maximum Transmission Unit (MTU) -- let's say because your routers don't like the default MTU for ethernet (1500) -- the zonecfg command doesn't support that ability. Neither does the physical interface's MTU value propagate, as one might hope, to its virtual interfaces:

# ifconfig bge0
bge0: flags=1001000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
        inet 10.9.151.125 netmask ffffff00 broadcast 10.9.151.255
        ether 0:3:ba:27:5:36

# ifconfig bge0 mtu 1400
# ifconfig bge0
bge0: flags=1001000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4,FIXEDMTU> mtu 1400 index 2
        inet 10.9.151.125 netmask ffffff00 broadcast 10.9.151.255 ether 0:3:ba:27:5:36

# ifconfig bge0 addif 10.9.151.160/24
Created new logical interface bge0:4

# ifconfig bge0:4
bge0:4: flags=1000842<BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
        inet 10.9.151.160 netmask ffffff00 broadcast 10.255.255.255

From this example we see there is no inheritance of the bge0 interface MTU attribute to bge0:4. The result is the same for a local zone that sets the interface through its configuration.

I don't imagine there are many cases where this lack of facility stops the show. When it is needed, however, there's a workaround.

  1. Remove the existing net resource from the local zone.
  2. Create a virtual interface in the global zone and assign it to the local zone.
  3. Incorporate the change into the start script /lib/svc/method/svc-zones.

Bear in mind that removing the net resource does not alter a running zone. The change is configuration only takes effect at the next boot:

# zonecfg -z golden remove net address=10.9.152.150

# ifconfig bge0:2
bge0:2: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
        zone golden
        inet 10.9.152.150 netmask ffffff00 broadcast 10.9.152.255

If the local zone doesn't already have a net resource, creating a local zone interface with the ifconfig command. This state change does affect the zone immediately, as would deleting it with ifconfig removeif ... command:

# ifconfig bge0 addif 10.9.151.172/24 mtu 1400 zone golden
Created new logical interface bge0:5

[root@instructor1]# ifconfig bge0:5
bge0:5: flags=1001000842<BROADCAST,RUNNING,MULTICAST,IPv4,FIXEDMTU> mtu 1400 index 2
        zone golden
        inet 10.9.151.172 netmask ffffff00 broadcast 10.255.255.255

The last bit: integrating the solution into routine startup. For zones that do not use the autoboot parameter, a kludgy, simple adjustment that is easy to script:

# zoneadm -z golden boot && ifconfig bge0 addif 10.9.151.172/24 mtu 1400 zone golden

Zones that do use the autoboot resource are managed by the start routine for the svc:/system/zones:default service, located in the /lib/svc/method/svc-zones file. The key line to consider is this one:

ctrun -l none -i none zoneadm -z $zone boot &

For the sake of keeping this entry brief and focussed, I'll leave things here for now. I haven't played with ctrun and zone booting, so I am not ready to recommend an alteration just yet. I'll say more about the ctrun command in a follow-up.



Add a comment

Title
Body
HTML : b, i, blockquote, br, p, pre, a href="", ul, ol, li
Math Quiz 6 + 7 = (Helps stop blog spam)
Name
E-mail address
Website
Remember me Yes  No 

E-mail addresses are not publicly displayed, so please only leave your e-mail address if you would like to be notified when new comments are added to this blog entry (you can opt-out later).

TrackBack to http://radio.javaranch.com/michael/addTrackBack.action?entry=1185480616929