Groupwise 2014 r2, SLES SP3, VMWARE, inconsistent sending

30 percent of the time to hotmail, yahoo and other domains I get the C141 DMN: MSG 1667 SMTP session ended: [98.138.112.35] (mta6.am0.yahoodns.net)
15:15:19 C141 DMN: MSG 1667 Send Failure: 420 TCP write error or I get the host down. I thought it could be the isp, but they came and the internet works fine, the only thing that I found was that the vmware driver with SLES sp3 you need to put the following command "ethtool -K eth0 tso off. But I did that, but no change.. The vmware ESXI is on a Levono ThinkServer TS430. I thought it could actually be the nic on the server, but I don´t see any dropped packets... Any help is appreciated...

Tags:

  • crobison;2464305 wrote:
    the only thing that I found was that the vmware driver with SLES sp3 you need to put the following command "ethtool -K eth0 tso off. But I did that, but no change..


    First off, we need to know what release of SLES you are running. SP3 is the service pack, not the release. Please post the output from this command:
    cat /etc/*release

    There may be other calculations offloaded to your eth0 adapter which could cause issues. Make note of them then disable all of them to see if it resolves your issue. You can see which ones are enabled with this command:
    ethtool -k eth0


    Another thing to check is the type of adapter assigned to eth0 on your virtual machine. You can see this when you edit the VMware virtual machine settings. You can try a different adapter. If your SLES release and your ESXi version support it, try VMXNET3. It is the newest virtual nic and provides the best performance.
  • LSB_VERSION="core-2.0-noarch:core-3.2-noarch:core-4.0-noarch:core-2.0-x86_64:core-3.2-x86_64:core-4.0-x86_64"
    SUSE Linux Enterprise Server 11 (x86_64)
    VERSION = 11
    PATCHLEVEL = 3

    ethtool -k eth0
    Offload parameters for eth0:
    rx-checksumming: on
    tx-checksumming: on
    scatter-gather: on
    tcp-segmentation-offload: off
    udp-fragmentation-offload: off
    generic-segmentation-offload: on
    generic-receive-offload: on
    large-receive-offload: off
    rx-vlan-offload: on
    tx-vlan-offload: on
    ntuple-filters: off
    receive-hashing: off
  • Hi,

    Just to add this in here.... the problem might not be the server but something connecting the server to the outside world. I had a mismatched duplex setting on a switch port once causing this kind of problem.

    Cheers,
  • crobison;2464305 wrote:
    420 TCP write error


    If these errors are not due to issues with your nic, you need to look elsewhere. These types of errors are sometimes difficult to debug and you may have to open an Sevice Request.

    Have you seen this TID?
    TID 7007770 "420 TCP Read" Error Sending to Specific Domains
  • The packet inspection is disabled, question the tls enabled is it referring to the ssl being enabled on the smtp agent?
  • Issues similar to yours have been reported frequently over the years. They are difficult to diagnose especially for Forum Volunteers who don't have access to your system. Often, it is not a GroupWise issue.

    Read through previous threads to see if they help. If not, then I suggest you open a Service Request.

    In each of the following forums, search for "tcp 420" using the "Search Forums" drop-down at the top of the list of threads on the right hand side.



    Good luck!
  • laurabuckley;2464368 wrote:
    the problem might not be the server but something connecting the server to the outside world.

    You are absolutely correct.

    We can try a couple of quick things that have been known to resolve similar problems but if they don't fix it then a full diagnosis is needed to pinpoint the problem before considering possible solutions. :)
  • Am 17.08.2017 um 22:44 schrieb KBOYLE:
    >
    > Issues similar to yours have been reported frequently over the years.
    > They are difficult to diagnose especially for Forum Volunteers who don't
    > have access to your system. Often, it is not a GroupWise issue.


    Let me rephrase this. It is virtually never a groupwise issue. ;)

    And it's virtually always a communication issue, and in the majority of
    cases it's the local firewall/router.

    The proper solution to find what's going on is to take a lan trace on
    the GW serve ritself, and if possible simultaneoulsy on the outmost
    device possible (firewall?) until a 420 error shows up. The lan trace
    will show what's up without having to guess or go for trial
  • I can confirm, never a groupwise Problem, i works since many years with virtual Installation on vmware 5x und 6.x and don't have any Problems!
  • The issue was resolved, never a groupwise issue. The isp used to associate the authorized ips with the mac address of the device, but they had but the wrong mac for the firewall causing all kinda problems, yesterday the but the correct mac and everything is flowing great...