HTTP Slow Out Of VMS Through Firewall-1

[Robert Atkinson]

We have a curious problem with HTTP.

I'm in the middle of setting up a BL860 cluster on VMS 8.3-1H1. Everything works as expected, except HTTP.

Apache (CSWS) is serving up a static page of about 100K, but can take 10 minutes to transfer. When we look at the data coming over, we can see it writing incredibly slowly.

The data goes through Firewall-1, the new cluster is in a private LAN to stop any uneanted traffic from escaping.

Other IP protocols are fine. If I access the same page from within the LAN, it's also fine, so that rules out the network card/link. I've also loaded the page into IIS and accessed that through the firewall, which again is fine, so it seems to rule out problems with HTTP filtering.

We think there could be a problem related directly to Firewall-1 and the size of the packets VMS is presenting. I've got another PIX firewall that I could try, but the pass-thru module attached to the blades seems to refuse to negotiate down to 10/100, so we have to use hardware capable of gigabit.

I know this is a long shot, but I wondered if anyone else has come across anything similar, or could give me a clue where I coud start looking and tweaking parameters?

Cheers, Rob.

[marsh_1]

rob,

not much help but you're probably best off putting this in the network forum.

fwiw

[Hoff]

Seems that this traffic has exceeded the capabilities of this model of the Check Point Firewall-1 firewall.

I've seen a few firewalls crater exactly like this (including having protocol-specific speed differences), either due to the volume of data or due to the overhead of firewall-based inspections. Check the rules and settings and processing and NAT here, as a start.

Check with Check Point here first, or shop around for better bandwidth with another widget.

Ignoring the issue around setting the speed (which is generally via LANCP in OpenVMS I64) this looks to be the firewall.

[Wim Van den Wyngaert]

I know nothing but try netstat -s (ucx sho prot) on the browser side (pc in command prompt) before and after the request.

May be ICMP or other counters indicates something.

Wim

[David Jones_21]

We run into problems generally with our firewall and TCP window scaling.

[Wim Van den Wyngaert]

Rob,

Could you also define slow ?

Wim

[Cass Witkowski]

Do you have LAN_FLAG set in your SYSGEN parameters? If it is set to 64 then you have jumbo frames enabled. This is fine unless your LAN switches and such do not support them. If not then things can get very slow. You may not see issue unless you are trying to transfer more than 1KB at a time.

[Robert Atkinson]

Cass, we have LAN_FLAGS defaulted to '0' at the moment, although I will be switching Jumbo Frames on at some point.


Wilm, this is the original definition of slow from my first post :-

"Apache (CSWS) is serving up a static page of about 100K, but can take 10 minutes to transfer. When we look at the data coming over, we can see it writing incredibly slowly."


I'll give the netstat test a try as well.

Rob.

[Wim Van den Wyngaert]

Me bad reader. Sorry.

Also check "route print" (=ucx sho rout). May be a bad route is taken (traceroute on VMS, no idea how to do it on PC).

I also had once that 2 devices had the same IP address. 1 was behind the firewall but was able to get the arp request. It answered
but then the other node with the same IP answered too. This caused very slow communications (packets needed to be resend).

Wim

[Robert Gezelter]

Rob,

I suggest a first step toward diagnosing this is to get a trace of the affected connection. My preference is to use WireShark, as it can produce a dump file that can then be sent to whomever needs to view it.

I would also try a variety of experiments (all with the LAN monitoring in place) with different file lengths to see where the "shoulder" actually is.

- Bob Gezelter, http://www.rlgsc.com