Operating System - OpenVMS
1827808 Members
2136 Online
109969 Solutions
New Discussion

Delay in response after VLAN migration

 
SOLVED
Go to solution
Russ Carraro
Regular Advisor

Delay in response after VLAN migration

Customer recently migrated from WAN to VLAN. Because of a security issue they, also, introduced a "tunnel". Their shop runs a shop floor application from PC's, where the application and files are on an Alpha and the database (Oracle) is on a Sun server. The Alpha is a 4100 running OpenVMS 7.1-1H2, UCX V4.2 ECO 5 and has an EW_DE500 ethernet card with line speed 100 and full duplex off. They are now experiencing delays and are asking about MTU (maximum transfer Unit?) detection and discovery and possibly turning it off. The user has Unix and Windows experience.

I'm not familiar with MTU. Is there such a thing in this ethernet/ucx environment? Is there a counter that might reflect their "delay" problem. There are no waits or drops in "ucx show comm /mem" and nothing jumps out at me in "anal/sys show lan/dev=ewa". They are not running DECNET.

Thanks in advance for any/all responses.
3 REPLIES 3
Andy Bustamante
Honored Contributor

Re: Delay in response after VLAN migration

If possible, I'd push for a full duplex connection.

That said, the VPN tunnel may introduce addtional overhead and split packets comming from the Alpha. See

UCX> help set protocol/mtu

The VPN documenation should have a recommended maximum MTU.

Another option is to upgrade UCX to TCPIP. You should be able to run 5.0a, possibly 5.1. TCPIP provides better performance for IP traffic.

Andy
If you don't have time to do it right, when will you have time to do it over? Reach me at first_name + "." + last_name at sysmanager net
Jim_McKinney
Honored Contributor
Solution

Re: Delay in response after VLAN migration

My understanding is that with some (all) VLAN implementations, as packets are routed through the virtual pipe, they are encapsulated in an outer package that contributes numerous bytes to their size. IP implementations recongnize hardware configurations and by default try to be efficient and create packets that are already at the maximum size supported by the hardware. So, once the size is exceeded (with the addition of the VLAN's overhead) the packets have to be fragmented in order to transfer - and then re-assembled on the other end. I'm not a UCX user so I can't tell you how to (I'm sure someone else reading here can) alter the MTU (yes, the maximum transfer unit which for ethernet is ~1500 bytes) but, I can tell that using MultiNet in similar situations I've had success lowering the MTU from 1500 to 1300 to curb the need for packet fragmentation and re-assembly.
Russ Carraro
Regular Advisor

Re: Delay in response after VLAN migration

Needed the MTU option, thanks.