Change MTU size on a Vax 6000 using Multinet 3.2 Rev B?

Change MTU size on a Vax 6000 using Multinet 3.2 Rev B?

Post by The C » Sat, 02 Jul 2005 23:51:53



A certain major Australian ISP has decided to turn off ICMP as a means
(apparently) of defeating DOS attacks.

This appears to be preventing our mail server reaching theirs to forward
mail. After *months* of denial of any problem there from the ISP
concerned and enormous difficulty punching past their 'help' desk, and
equally fruitless efforts by our ISP to try and get any sense out of
them, or to the bottom of what was happening (we had surmised a router
problem or rogue firewall or something similar) we finally found out
this week it was due to the shutdown of ICMP. It's been suggested that
reducing the MTU size from the default 1500 bytes to say, 1468 or
thereabouts may resolve the problem.
The ISP concerned are looking at making some changes to possibly sort
the problem, but this will likely take another week or more at least and
no guarantees of success.

According to the Multinet docs,

MULTINET SET /INTERFACE SE0 /MTU=XXXX should solve it, however it
doesn't and we get error messages.

Look it up and we find...

"%MULTINET-F-MTUERR, error setting MTU for se0
-MULTINET-F-EBUSY, Mount device busy
Facility: MULTINET SET

Meaning: These messages appear when using the MULTINET
SET/INTERFACE/MTU=nn command on se0.

Action: The MTU is a property of the hardware interface and should not
be set. MultiNet uses the lower MSS when transmitting to a host not on
your network.

To diagnose this problem, use a network analyzer, TCPDUMP, or TCPVIEW,
and watch the connection when it fails (hangs). You will see the OpenVMS
host retransmitting the same TCPdata constantly, with no
acknowledgements sent back. Next, put a network analyzer at the remote
site and see if the data packets do arrive. This condition can be caused
by a "Pattern-sensitive link," a link that lets certain packets through,
but not others.

MultiNet's Path MTU Discovery (RFC1191) determines automatically the
largest MTU that can be used between the MultiNet host and a remote host."

I translate that to mean that they don't want you messing with the MTU
size on the Ethernet connection, as it will be dynamically changed when
the session is negotiated with the foreign host, which is probably
reasonable, except that the MTU Discovery apparently is broken by the
neutering of ICMP.
It appears they emphasise this by ensuring you *can't* alter it.

Anyone know of some way or means to change the MTU regardless?
Hack something?

Vax 6000-440
VMS 6.0 Multinet 3.2 Rev B....
MX for VMS 5.4 ECO1

Any help appreciated. (Aside from taking a clue stick to the ISP
concerned....)

--
Geoff Roberts
IT Support
Saint Mark's College
Port Pirie, South Australia
XXXX@XXXXX.COM
Remove all x's from email address....
 
 
 

Change MTU size on a Vax 6000 using Multinet 3.2 Rev B?

Post by S.C.Spron » Sun, 03 Jul 2005 00:21:06


But not (inflight) MTU discovery, making themselves vulnerable to UDP/TCP
buffer depletion. Joy. General advice: allow packet fragmentation on the
whole route to the upstream ISP and try to resist the urge to DOS them to
oblivion.

See < http://www.yqcomputer.com/ ; for a pithy summary.

scs

 
 
 

Change MTU size on a Vax 6000 using Multinet 3.2 Rev B?

Post by The C » Sun, 03 Jul 2005 02:19:02


Yes, which is exactly my problem.

> making themselves vulnerable to UDP/TCP

Amongst other things.


Be delighted, unfortunately I have no control over this.
Our ISP *might* be able to do something at the router we
get our feed from, (we don't own a router - the VAX feeds
striaght into a switch and then to the ISPs router)

The largish (by Oz standards) ISP that thought it a bright
idea to kill off ICMP *might* be going to partly restore
some parts of it, hopefully enough to let the Vax negotiate
an MTU size again - as the IP stack *is* using RFC1191 (or it
was until they broke it by killing ICMP) so again, this
could fix the problem - eventually. It's the 'eventually'
that I'm having trouble with. We are completely unable to
send email to that domain and unfortunately it has several
important addressees that we *must* be able to send to.
Now. Not 'maybe' in two weeks or a week or when/if they
get around to it. So I was hoping to find a way to tweak
the mtu size down as an interim measure to restore service.
It's been broken way too long and whilst we have gotten
around some of it by alternative methods (fax and the like)
some material simply *must* be emailed and we can't do it
at this point.


Given free reign, I wouldn't be that nice.....


Yes, that seems to be the issue. MS cover somewhat similar ground
in some knowledgebase articles dealing with 'black hole' routers.

Oh, my XP box couldn't telnet to the mail server in question on
port 25 either. I tweaked the MTU down and it worked.
Oddly enough I increased it back to 1500 (which is supposedly the
default) and it *still* worked. Still trying to figure that one
out, MS seems to think XP uses 1500 as an mtu size on ethernet,
but this behaviour suggests it might be larger. Possibly the
XP box 'remembered' the previous connection and used a smaller
packet size.... Who knows....

---
Geoff Roberts
IT Support
Saint Mark's College
Port Pirie, South Australia
XXXX@XXXXX.COM
Remove all x's from email address....
 
 
 

Change MTU size on a Vax 6000 using Multinet 3.2 Rev B?

Post by Richard To » Sun, 03 Jul 2005 02:42:09

http://www.yqcomputer.com/ ~marcs/mtu/

What about upgrading Multinet or changing the TCP/IP stack to something
else, like TCPware or VMS TCP/IP, UCX?









----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.yqcomputer.com/ The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
 
 
 

Change MTU size on a Vax 6000 using Multinet 3.2 Rev B?

Post by S.C.Spron » Sun, 03 Jul 2005 03:07:09


I speak as a TCP/IP generalist, mainly for various Unices, and I can't
tell you how to set the MTU on your particular TCP/IP stack on VMS.
Since your alternative solutions are barred the upstream MTU should be
lowered, possibly with a temporary multihomed computer inbetween.

I gave the link to the web page -- another poster gave a more detailed
one -- as a succinct explanation for your upstream ISP. If they don't
deem to understand nor correct their mistake, they are not fulfilling
their part of your service contract.

scs
 
 
 

Change MTU size on a Vax 6000 using Multinet 3.2 Rev B?

Post by The C » Sun, 03 Jul 2005 09:58:40

.C.Sprong wrote:

Understandable.


There is some possibility that our ISP will accomodate that. Bear in
mind that it's not their network that's broken, but a 3rd partys.


Yes, I figured that, as I said, *in time* the problem will doubtless be
fixed, either by our ISP making router changes or the offending ISP
(partly) restoring ICMP functionality. What I was hoping for was a
'quick fix' that would get the mail flowing again because I have no
confidence in the problem be quickly resolved by those means.


The ISP that is the heart of the problem is not one that we have a
contract with, rather they are the destination domain for email traffic
we need to be able to send. Our own ISP are trying to resolve the
problem, but they were *unable* to get hold of anyone in the offending
organisation that would even admit there was a problem. If anything
they are as frustrated by their intransigence as I am. I have even
been to the Telcommunications Ombudsman about this and they are unable
to help as the ISP that is the root cause of the problem is not one that
we purchase a service from. The offending ISP also refuses to allow 3rd
parties to lodge a fault as they do not accept such from parties they do
not have a contract with ie you must be one of their customers to lodge
a complaint about their service. Otherwise you get well meaning morons
in their 'help' wanting to send you to a forum to discuss your
'configuration problem' and they were *adamant* that there could not
possbily be any problem with their network. My assistant called their
XXXXXDirect service that deals with high volume commercial customers and
tried to lodge a fault through that channel. He was told in no
uncertain terms that if there was a problem 'we would know about it'.

It's taken almost 3 months of almost daily bashing at their helpdesk and
several 'escalations' which mostly resulted in a phone call from a tech
requesting more info and nothing else. Then they tried to tell us we
were on a blocklist and when I challenged *that* they tried to tell me
the ip address of our mailserver was 192.168.0.1! I was very patient
and didn't swear at the nice man on the phone....
They have now quit claiming that, but it seems that whoever you speak to
has a different story and it took a *week* for them to acknowledge a fax
detailing the problem that we sent them at their request. (Email is out
for obvious reasons.....)
Do you see the problem? I can't reach down a phone line and strangle
the right people, and frankly I really feel like doing that.
After endless bashing at their clueless helpdesk interface it was *this
Friday* I finally got a call from an engineer somewhere in the labyrinth
there and he was the one that told me about ICMP being turned off. This
was the first time I had a specific admission that something they had
done was responsible for the problem. I immediately passed this on to
our ISP and they are now looking to see what they can do to help, and
the techs are now *finally* talking to each other so I've no doubt it
will get sorted *eventually*. The offending ISP claim they have only had
a handful of complaints, but I suspect the real reason is that people
having trouble either can't get past the helpdesk because they don't
have an account with them and/or they have not yet identified the
problem. It took me a month to notice as the volume of mail we send to
them i
 
 
 

Change MTU size on a Vax 6000 using Multinet 3.2 Rev B?

Post by The C » Sun, 03 Jul 2005 10:01:56


For various reasons, not the least of which is $$$, this is not going to
happen. Even if I could, why should I? It's not *our* system that is
broken.

--
Geoff Roberts
IT Support
Saint Mark's College
Port Pirie, South Australia
XXXX@XXXXX.COM
Remove all x's from email address....
 
 
 

Change MTU size on a Vax 6000 using Multinet 3.2 Rev B?

Post by Richard To » Sun, 03 Jul 2005 15:56:00

I thought that you said you were not able to adjust the MTU size as you had
wanted to.
If that is the case, possibly a newer or different version of the TCP/IP
stack would enable you to be able to do that.

rtt








----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.yqcomputer.com/ The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
 
 
 

Change MTU size on a Vax 6000 using Multinet 3.2 Rev B?

Post by S.C.Spron » Sun, 03 Jul 2005 17:15:27


[ MTU discovery and no ICMP ]


I certainly see the problem, because this kind of nonsense is ubiquituous
and it drives everyone with a clue and has a desire to make things _work_
right up the wall. I think that your best course of action is to vent off
steam in alt.sysadmin.recovery (I'm serious).


The problem is trivial, but the solution isn't, thanks to human
organisation.

Good luck!
scs
 
 
 

Change MTU size on a Vax 6000 using Multinet 3.2 Rev B?

Post by The C » Mon, 04 Jul 2005 09:02:01


It doesn't seem so.


Several later versions of Multinet appear to have the same issue. UCX
can (apparently) deal with it, but that would require a VMS upgrade,
which would require spending money and I'm not able to do that on this
system. I still maintain that it's not this system that's broken so I
fail to see why we should spend money to accomodate the rogue ISP's
brain damaged network anyway. I hoped someone might know of a hack to
temporarily alter it, but it seems to be non trivial.


--
Geoff Roberts
IT Support
Saint Mark's College
Port Pirie, South Australia
XXXX@XXXXX.COM
Remove all x's from email address....
 
 
 

Change MTU size on a Vax 6000 using Multinet 3.2 Rev B?

Post by Richard To » Mon, 04 Jul 2005 11:30:05

The intermediate multi-homed system seems like a good idea.
Get a cheap PC, use NetBSD or LINUX with two NIC's and set it up in between
the VMS machine and the ISP.

I do agree, if you are not broke, then you shouldn't have to pay, but you
are broke, so to speak. ;-) Just a joke.





had



----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.yqcomputer.com/ The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
 
 
 

Change MTU size on a Vax 6000 using Multinet 3.2 Rev B?

Post by Stefaan A » Mon, 04 Jul 2005 18:49:43

On Sat, 2 Jul 2005 22:30:05 -0400



If you want less maintenance, get a SOHO router with bridging
capabilities. I use a ZyWALL 5 (about AU$250) for the purpose. Once
it's set up, you can forget about it (plus it uses less electricity
than a PC and has an excellent firewall).

Take care,

--
Stefaan
--
As complexity rises, precise statements lose meaning,
and meaningful statements lose precision. -- Lotfi Zadeh
 
 
 

Change MTU size on a Vax 6000 using Multinet 3.2 Rev B?

Post by huw.davie » Mon, 04 Jul 2005 23:32:41


Even cheaper, get a Linksys WRT54G (around $99) and get a free wireless
network as well. With the stanard Linksys software you can set the MTU
on the outgoing ("Internet") port to practically anything.
--
Huw Davies | e-mail: XXXX@XXXXX.COM
Melbourne | "If soccer was meant to be played in the
Australia | air, the sky would be painted green"
 
 
 

Change MTU size on a Vax 6000 using Multinet 3.2 Rev B?

Post by Stefaan A » Tue, 05 Jul 2005 03:20:11

On Sun, 03 Jul 2005 14:32:41 -0000



Will it work in bridging mode? Last time I looked, it insisted
on NATing everything.

--
Stefaan
--
As complexity rises, precise statements lose meaning,
and meaningful statements lose precision. -- Lotfi Zadeh
 
 
 

Change MTU size on a Vax 6000 using Multinet 3.2 Rev B?

Post by huw.davie » Tue, 05 Jul 2005 10:54:54


I suspect with the standard Linksys firmware you may well be right and
I can't check this as I run a non-standard configuration.
--
Huw Davies | e-mail: XXXX@XXXXX.COM
Melbourne | "If soccer was meant to be played in the
Australia | air, the sky would be painted green"