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!)
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
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
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
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...
Did you test it with active external connections?
The error we got was:
ORA-12152: TNS:unable to send break message
Regards,
Niel