Changing MTU size on the fly

Changing MTU size on the fly

Post by roda » Thu, 28 Feb 2008 03:54:46


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!)
 
 
 

Changing MTU size on the fly

Post by Paul Landa » Thu, 28 Feb 2008 04:20:51


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.


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

Paul Landay

 
 
 

Changing MTU size on the fly

Post by roda » Thu, 28 Feb 2008 05:57:35


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?
 
 
 

Changing MTU size on the fly

Post by Niel Lambr » Thu, 28 Feb 2008 06:51:31


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
 
 
 

Changing MTU size on the fly

Post by Paul Landa » Thu, 28 Feb 2008 23:12:25


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
 
 
 

Changing MTU size on the fly

Post by roda » Fri, 29 Feb 2008 03:46:34

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.
 
 
 

Changing MTU size on the fly

Post by Rick Jone » Fri, 29 Feb 2008 03:52:26


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.


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


--
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...
 
 
 

Changing MTU size on the fly

Post by Niel Lambr » Fri, 29 Feb 2008 06:00:18


Did you test it with active external connections?

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

Regards,
Niel