OpenVMS V7.1, UCX V4.2 ECO 5, how to change MTU

[Russ Carraro]

Customer has a cluster of two Alpha server 2100s running OpenVMS V7.1 and UCX V4.2, ECO5. The "ucx show interface" command shows an MTU value of 1500. How do I change that value to something lower, say 1300?

[Duncan Morris]

Russ,

see "Ask the Wizard" -

http://h71000.www7.hp.com/wizard/wiz_6443.html

With V4.x series releases and YOU MUST HAVE THE CURRENT ECO KITS
INSTALLED, use the commands:

SET CONF COMM/TYPE=DEFAULT
SET CONF COMM/TYPE=FDDI
SET CONF COMM/TYPE=ETHER

and

SET PROTOCOL TCP /MTU_SEGMENT_SIZE

[Andy Bustamante]

With VMS 7.1 you can upgrade to TCPIP 5.0a with ECOs or 5.1 with limited ECO support. Of courese both TCPIP versions and VMS 7.1 are long out of support.

Andy Bustamante

[Russ Carraro]

Duncan,

The /MTU_SEGMENT is an on/off switch for using MTU (1500) value or a default (512). What I'm looking for is changing MTU from 1500 to 1300. Thanks.

Andy,

These are legacy systems and applications that the customer has at multiple locations. They are well aware of how old they are and are not supported but upgrading the OS or UCX (to TCPIP) is not an option. Thanks.

[Wim Van den Wyngaert]

I wonder if the on/off switch is not enabling the discovery. It will then get back icmp messages saying that it must lower the value of mtu. And it will then do retransmit until the size fits.

Wim

[marsh_1]

hi,

i thought the only way to do that was using ifconfig which i don't think was available until v5.

[Wim Van den Wyngaert]

I was wrong. It indeeds sets the mtu size to 512. I think the mtu discovery is always on. So, after a few retrans, it should work.

Why are they asking it ?

Wim

[Russ Carraro]

Wim,

They made some sort of network change, they called it MPLS. Apparently MPLS doesn't accept packets over 1300 so they changed all their servers and were asking if the Alphas could be changed. In any case, they've made the change and the Alphas are running fine. They'll keep an eye on the network.

[Jim_McKinney]

I believe that MPLS is VPN technology.

Consider how a VPN works. The original TCP frame (packet) is wrapped inside of another. Imagine that the medium used for transporting both the original packets and the resultant wrapped packets are both ethernet. So, the original packet leaves the point of origin with a MTU of 1500 - its likely 1500 bytes long as this would be most efficient use of a packet. When it hits the VPN it needs to be repackaged and placed inside a new frame. Since the medium is ethernet the largest size that the frame can be is 1500 bytes - but if the original is 1500 bytes in length its too big to fit inside another packet and will have to be split (fragmented) into two chunks before being encapsulated. And when it gets to the other end of the VPN the (now) two packets will be unbundled and the original packet reconstructed. So, it becomes more efficient to just insure that that the original packets are small enough to fit inside of the VPN's packets - restricting the MTU of the origin to 1300 will guarantee that you won't experience the fragmentation of packets (and associated performance impact) jumping onto the VPN. If most/all packets are heading towards the VPN then it'll likely be a good win to trade the smaller payload size for the prevention of the fragmentation.

[Wim Van den Wyngaert]

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

I would expect it to work without changing anything but would do ucx sho prot to see what the counter say.

Wim