REMSH unix command issues when adding rule for port 514

Unanswered Question
Sep 9th, 2009

Has anyone experienced any issues with Unix systems when adding rules to WAAS for port 514? This is the port RCOPY uses and is not handled by WAAS by default. We created a rule for port 514 but when we implement any type of optimization (even TFO Only) we start having problems with REMSH. This is used in one of our production scripts that normally take 10 minutes to run. When we apply the rule for port 514 the time goes as high as 45 minutes.

We wrote a test script that uses just the REMSH command and with out the 514 rule works fine but with the 514 rule goes down the tubes.

Just to add a little more information, I do not see an entry under Monitor/ Connection Statistics with the servers in question when the test script is running so am not sure where to go from here. I know there is a way to do a TCP capture from the WAAS so figure that will be the next step to see what is causing the issues.

Thoughts?? Ideas?? Suggestions??

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
bchoisser Thu, 09/10/2009 - 13:54

We are having similar issue with remote shell. In addition to the slowness we are getting timeouts when trying to connecting to another box, even after we kill the copy processes. Every other remote shell fails.

Please post if you find out any info, I will do the same.

bberry Thu, 09/10/2009 - 14:06

We are looking into possibly changing the port REMSH uses since it uses 514 by default. This would pull it out the the optimization process. I have only had a basic discussion with the server group to see if that is an acceptable work around. If nothng else maybe do that for testing purposes so we can have a better TCP capture to diagnose the root problem.

I will keep you informed.

Brent

bchoisser Sat, 09/12/2009 - 22:23

We changed our remsh port to 914 with the same results. Downgraded from 4.13a to 4.13 with same results. Problem went away when I shut down inline interface, basically creating a wire.

Are you seeing every other remsh session timeout as well?

I opened a TAC case and escalated it through our rep, also have the SE working on the issue.

bberry Sun, 09/13/2009 - 14:38

Hey,

You are working faster than our server group. According to our programmers we only have one aplication that uses REMSH heavly. The discussion with our SE was to work with TAC to do a capture with REMSH on a different port so that the total conversations between the servers could be seen. With it using the generic 514 port it was too buried to be easily seen. This would also hopefully help investigate if it is TFO that is interferring with the remsh or what. Theory is that we could also then create another rule for remsh on the new port that placed just that traffic in pass through as a work around. Getting real klugie for a problem we have not seen testing other vendors.

Thanks for the update and I will keep you informed of our progress as well.

bberry Mon, 09/14/2009 - 06:17

Odd question .. Have you tried to add a rule for handling the new port as a Pass Through and placing 514 back into optimization?

bchoisser Mon, 09/14/2009 - 11:14

Well TAC came back with a answer. They found other people with the same issue.

"It was found that the applications always used the same source and destination TCP ports. WAAS has the first connection in a "WAIT-CLOSE" state so when the next packet comes in with the same ports it is dropped." , "A defect was opened for this issue, but has not been fixed yet."

He wanted us to do a packet capture but after finding these other tickets decided it would be a waste of time and only tell us we are having a similar issue as others.

Still waiting on a suggested work around or a patch, 4.15 is suppose to come out soon but haven't heard if it will fix the problem.

With the new information I don't think even putting 514 in pass-through will fix the issue.

I will let you know if I hear anything else.

bchoisser Tue, 09/15/2009 - 11:21

We had another Webex today, they told me they have been working with your account team as well on the issue.

We are seeing the waits on the closed connections. Cisco siad the problem still might not be fixed in version 4.15.

We tried changing back to port 914 and setting it to use pass-through but when we start a rsync using remsh it is just tunneling the rsync through the remsh connection by passing any optimization.

Anything on your side?

Actions

This Discussion