Changing MTU Size for Management Processor NIC

[bradclif]

We use an ssh client on remote PCs to connect to the management processors (MP) on our rx6600 servers.  Everything was working until we moved one of the MPs into a new VLAN.  Now every time we try to dump logs, we lose our connection to the MP.  Our network engineer tracked it down to the packet size.  Is there a way to change the MTU size on the MP NIC?

[Patrick Wallek · Accepted solution]

It does not appear possible.  Here is part of the help for the 'LC' command from the MP on an rx2600.

LC  : LAN Configuration usage (IP address, etc.)

Command access level: MP Configuration access.

This command modifies the LAN Configuration.  Configurable parameters: DHCP enable/disable, MP IP Address, MP host name, subnet mask, gateway, web access port number, SSH access port number, LAN speed, and autonegotiation.

 Notice that it does not list the MTU size as a configurable parameter.

[bradclif]

Thank you for being the first reply to my first post.

The MP commands are the same for the rx6600.  I was just wondering there was a way outside of the normal commands, even if it means bringing in an HP service engineer.  I don't believe there's a way to do it either, but I thought I would give this posting a shot before telling our network admin "no."

[Matti_Kurkela]

Configuring MTU sizes manually is so 1980's, don't you think?

In 1990, a technique called Path MTU Discovery (PMTUD) was developed and standardized in RFC 1191. It removes the need to manually set MTU values, as a suitable MTU value will be auto-adjusted for each connection as soon as the first packet that is too large for the current connection is detected. This requires minimal processing power: basically any microcontroller that is powerful enough to implement a reasonably full-featured version of TCP can easily implement PMTUD too.

By year 2002, it was estimated that PMTUD was in use in about 80 - 90 % of all internet-connected systems.

At least Windows 95 and all versions of Windows after it have had PMTUD enabled by default, unless you make an effort to disable it.

Today, in 2012, PMTUD is a standard part of IPv4 networking.

PMTUD has only one requirement: the end-points of the network connection must both be able to receive ICMP Fragmentation Needed messages (ICMP Type 3, Code 4) from any intervening routers. The endpoints won't ever need to send anything, and receiving the ICMP Fragmentation Needed messages should not cause any endpoint system to (re)send anything it hasn't already sent in the first place.

Firewall administrators normally block everything that is not explicitly required, and that is a good policy in general. However, some of them over-zealously block all ICMP unless told otherwise. My position is that PMTUD is a standard part of today's IP networking, and blocking it can cause unnecessary work as MTU values need to be tuned manually. With some embedded systems (like management processors) disabling PMTUD may not even be possible, causing loss of functionality if the ICMP messages it needs are blocked.

The use of PMTUD is easy to recognize in network traffic dumps: if outgoing IP traffic from a system always has the IP protocol "Don't Fragment" (DF) flag set, the system uses PMTUD.

Any reasonable firewall (except the most dumbed-down units for unsophisticated home users) should already have the functionality to filter ICMP messages by type: thus, it should not be necessary to allow all ICMP. Only the ICMP Type 3 Code 4 messages are needed by PMTUD.

Any reasonable enterprise firewall already does connection state tracking: it should also be capable of automatically blocking any spurious ICMP Fragmentation Needed messages (i.e. messages that don't seem to be associated with any established and/or allowed connection/packet flow). If that is not enough to satisfy security paranoia, it should be no problem to rate-limit the number of ICMP Fragmentation Needed messages in the firewall, down to a rate that matches the rate of expected legitimate connections or even some reasonable fraction of it.

A simple introduction:

http://en.wikipedia.org/wiki/Path_mtu_discovery

The actual standard:

http://tools.ietf.org/html/rfc1191

More arguments against blocking PMTUD and failure scenarios if all ICMP is blocked:

http://www.netheaven.com/pmtu.html