Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Changing MTU size on the fly

1,572 views
Skip to first unread message

rodak

unread,
Feb 26, 2008, 1:54:46 PM2/26/08
to
I need to change the MTU size on three different systems (all AIX 5.3
ML03), and I need to avoid any user down-time if necessary. Normally,
I run the following commands:

ifconfig en0 down detach
chdev -l ent0 -a jumbo_frames=yes
chdev -l en0 -a mtu=9000
ifconfig en0 up

Then go to smit tcpip, select "Start Now", and that does the trick.

Questions:
1) Is there a way to automate the last step?
2) If I do this during a period of fairly low activity, how likely am
I to get away with it (I'll warn the users ahead of time, but would
like to be able to tell them that the system *probably* won't go down)

If it makes any difference, one of these servers is an application
server, and the other two are back-end Oracle DB servers that it
communicates with. I'm hoping to see some improvement in Oracle
performance from this as well (or am I kidding myself!)


Paul Landay

unread,
Feb 26, 2008, 2:20:51 PM2/26/08
to rodak
rodak wrote:
> I need to change the MTU size on three different systems (all AIX 5.3
> ML03), and I need to avoid any user down-time if necessary. Normally,
> I run the following commands:
>
> ifconfig en0 down detach
> chdev -l ent0 -a jumbo_frames=yes
> chdev -l en0 -a mtu=9000
> ifconfig en0 up
>
> Then go to smit tcpip, select "Start Now", and that does the trick.
>
> Questions:
> 1) Is there a way to automate the last step?

chdev -l en0 -a state=up

and then also do any 'route add ...'
because the 'ifconfig ... down ...' would
have deleted any non-native subnet routes
using that interface.

> 2) If I do this during a period of fairly low activity, how likely am
> I to get away with it (I'll warn the users ahead of time, but would
> like to be able to tell them that the system *probably* won't go down)

I do this quite often, but I put the commands into
a shell script and then redirect stdout and stderr.

Paul Landay

rodak

unread,
Feb 26, 2008, 3:57:35 PM2/26/08
to

Thanks, Paul, that works great. Do you have any experience doing this
to an Oracle box? My DBA fears that the Listener and database may
need to be restarted after the change. Got any experience with Oracle?

Niel Lambrechts

unread,
Feb 26, 2008, 4:51:31 PM2/26/08
to
rodak wrote:
> Thanks, Paul, that works great. Do you have any experience doing this
> to an Oracle box? My DBA fears that the Listener and database may
> need to be restarted after the change. Got any experience with Oracle?

Afaik any state change (up/down) would have this effect... since the
listener binds to all interfaces (by default). I know for a fact
removing an interface alias will break the listener, so it must be
sensitive to most other operations.

Regards,
Niel

Paul Landay

unread,
Feb 27, 2008, 9:12:25 AM2/27/08
to rodak
rodak wrote:

I've never done this on an oracle box, but I would
be suprised if the listener process or database
needed to be restarted. When the 'ifconfig ... down'
was done any existing socket connections would have
been closed. After the 'chdev ... state=up' any new
socket connections would use the new MTU value.

Keep in mind that the interface mtu is just a 'starting'
value for negotiating the actual mtu to be used.
The actual mtu could be different for different
concurrent socket connections depending on the path
taken (i.e. different routers) for the different
partners. So the listener should not need to know
or care what the interface mtu is.

Paul Landay

rodak

unread,
Feb 27, 2008, 1:46:34 PM2/27/08
to
Thanks, Paul. I just tested it on a development Oracle system
(separate App and DB servers), and it didn't cause any disruption at
all.

Rick Jones

unread,
Feb 27, 2008, 1:52:26 PM2/27/08
to
Paul Landay <lan...@attglobal.net> wrote:
> I've never done this on an oracle box, but I would be suprised if
> the listener process or database needed to be restarted. When the
> 'ifconfig ... down' was done any existing socket connections would
> have been closed. After the 'chdev ... state=up' any new socket
> connections would use the new MTU value.

Indeed - a plain listen socket shouldn't care about interface state.
It might care if it were bound to a specific IP and that IP was no
longer known to the stack. But it shouldn't care if that interface
with the IP was up or down. Particularly since, unless the system
employs a "strong end system model" traffic for that destination IP
address could in theory be received via other interfaces.

I'd think that existing socket connections using that interface
wouldn't close immediately - they would probably retransmit a bit, but
if the interface came back up "in time" they should survice the
cycling.

> Keep in mind that the interface mtu is just a 'starting' value for
> negotiating the actual mtu to be used. The actual mtu could be
> different for different concurrent socket connections depending on
> the path taken (i.e. different routers) for the different partners.
> So the listener should not need to know or care what the interface
> mtu is.

Terminology nit - what TCP exchanges at least is "MSS" or Maximum
Segment Size which will indeed be based in part on the interface MTU.

> Paul Landay

--
oxymoron n, commuter in a gas-guzzling luxury SUV with an American flag
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

Niel Lambrechts

unread,
Feb 27, 2008, 4:00:18 PM2/27/08
to

Did you test it with active external connections?

The error we got was:
ORA-12152: TNS:unable to send break message

Regards,
Niel

0 new messages