uk1 --> mad1 --> ali1
[login@uk1] > interface gre print Flags: X - disabled, R - running 0 R name="mad1" mtu=auto actual-mtu=1476 local-address=IP.uk1 remote-address=IP.mad1 dscp=inherit clamp-tcp-mss=yes dont-fragment=no [login@uk1] >
[login@mad1] > interface gre print Flags: X - disabled, R - running 0 R name="ali1" mtu=auto actual-mtu=1476 local-address=IP.mad1 remote-address=IP.ali1 dscp=inherit clamp-tcp-mss=yes dont-fragment=no 1 R name="uk1" mtu=auto actual-mtu=1476 local-address=IP.mad1 remote-address=IP.uk1 dscp=inherit clamp-tcp-mss=yes dont-fragment=no [login@mad1] >
[login@ali1] > interface gre print Flags: X - disabled, R - running 0 R name="mad1" mtu=auto actual-mtu=1476 local-address=IP.ali1 remote-address=IP.mad1 dscp=inherit clamp-tcp-mss=yes dont-fragment=no [login@ali1-router] >
The issue that I have is receiving e-mails in the routed IPs via the GRE.
In the Exim log I get the error:
SMTP data timeout (message abandoned) on connection from sender.domain.com
It means that there was a timeout while Exim was reading the contents of a message on an incoming SMTP connection. That is, it had successfully accepted a MAIL command, one or more RCPT commands, and a DATA command, and was in the process of reading the data itself. The length of timeout is controlled by the smtp_receive_timeout option.
If you get this error regularly, the cause may be incorrect handling of large packets by a router or firewall. The maximum size of a packet is restricted on some links; routers should split packets that are larger. There is a feature called “path MTU discovery” that enables a sender to discover the maximum packet size over an entire path (multiple Internet links). This can be broken by misconfigured firewalls and routers. There is a good explanation at http://www.netheaven.com/pmtu.html. Reducing the MTU on your local network can sometimes work round this problem. See Q0017 (3) for further discussion.
Any idea about how to solve?
Thanks in advance!