When you use something like DUPLEX(*AUTO), there is extra communication between your adapter and whatever it is connected to (your switch). The two send info back and forth to tell the other what they support. At some point, your switch says “Okay, I’ll reset for the best setting that you said was good for you.” Your adapter may do something similar.

That really should only happen when the two first start talking, so it’s not a big deal… most of the time.

The same kind of thing happens with some other operational parameters, e.g., LINESPEED(*AUTO).

Generally, when a high value is negotiated, transient errors may cause a throttling back later.

Regardless, if you believe that a value is supported, and you are trying to track down problems, it can be very useful to eliminate elements that (1) aren’t needed and (2) affect the area you’re investigating.

If DUPLEX(*FULL) is supposed to work, then set it that way. You could perform some network analysis to see if DUPLEX(*AUTO) actually results in DUPLEX(*FULL), but it’s a lot easier just to set it and see if it is used. Eliminate any *AUTO negotiation.

Until you prove it, you don’t really know if the two devices are choosing a useful setting.

BTW, you should be sure that you have a way to undo anything you set. If the adapter is your only communication path into the system, then some alternative needs to be established in case the setting really turns out to be unsupported on either end. In such cases, I’ll often set up a small CL program in the job scheduler to run maybe 10 minutes in the future to undo changes. If things work, I can always stop it from running in a couple minutes.

Tom

Have set the Ethernet line to *FULL

Ethernet standard . . . . . . . . : ETHSTD *ETHV2
Line speed . . . . . . . . . . . . : LINESPEED *AUTO
Current line speed . . . . . . . . : 1G
Duplex . . . . . . . . . . . . . . : DUPLEX *AUTO
Current duplex . . . . . . . . . . : *FULL
Serviceability options . . . . . . : SRVOPT *NONE
Maximum frame size . . . . . . . . : MAXFRAME 1496

What do you mean by “skip negotiations”

Thanks

If the RST bit shows on the segment that the (remote) server is on, then that server is where any specific reason will be found. There’s no way to determine a cause of RST from anywhere else.

Technically, the RST bit is expected to be handled by the receiving end of the socket by the receiving application closing the socket and attempting to reopen the connection. It’s a messy item for something like FTP because you have no control over the programming. No reason is sent across to say why it was done.

The only way to determine any reason is to go the sending device and look for the reason.

…before relocating the switch ports are already configured.

That sounds like it’s a ‘managed switch’. Do you know if it is? It probably should be.

…both AS400 and switch are set 1Gb line and *AUTO.

*AUTO for the switch implies it handles full duplex. Set the AS/400 line to full and skip negotiation. Get it out of the equation if possible.

So far, there’s nothing obvious. The only real clue would be in verifying the physical source of any reset. That won’t necessarily be where any fix is done, but it’s the only device that knows the reason it set RST in the first place.

Tom

-Yes it is physically the same system. There are no other configuration changes other than the changes in IP. Initially, during relocation I tried to implement a virtual IP setup. But when these issues came up, I switched back to single IP setup.

-The TCP/IP interface on both AS400 and switch are set 1Gb line and *AUTO.

-The other devices connected to the switch now, are the as400 tape drive and HMC console. Just to highlight, before relocating the switch ports are already configured. When we plugged in, the ports are not working though. Our network guy did a so-called reset on the ports and it worked. I dont know if this could be a factor as well.

-The RESET was shown in both communication trace in AS400 and from our network trace.

-Yes we have tried to replace the cables. We have even tried to use the actual cable from our DEV server (the one with working FTP) but issue still persists.

Thanks

However:

We have opened up all ports in firewall to eliminate any restriction issues.

Can you clarify your network a little? If they’re on the same segment, where does a firewall get involved? Or are you saying that the (remote) Windows server is on the outside of the firewall?

…relocating our AS400 from one site to another.

So, it is physically the same system? Do you know of any configuration changes that were involved in the relocation?

The first area I would check is the match between the TCP/IP interface on the AS/400 and the switch it connects to. First thing to check is the half-/full-duplex setting. If it’s set to *AUTO, test setting it manually to the appropriate value in case the auto-negotiation is contributing to any problem.

Also, are there other devices that were connected to the same switch during the relocation? Any one of those could be causing trouble, especially during any negotiation.

How did you determine that the RESET was actually coming from the remote server? The RST bit could be set by almost any device along the route. It’s possible that an auto-negotiate results in a reset.

And you might simply replace the cable to your AS/400. It’s too easy and inexpensive to skip a simple replacement check.

Tom