Community discussions

 
jmginer
Member Candidate
Member Candidate
Topic Author
Posts: 115
Joined: Tue Dec 11, 2012 4:56 am

GRE MTU issue

Fri Mar 13, 2015 6:00 pm

Hello, I have created some GRE tunnels btw 3 routers:

uk1 --> mad1 --> ali1

uk1 GRE:
[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] > 
mad1 GRE:
[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] > 
ali1 GRE:
[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
Looking on exim doc:
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!
 
User avatar
ZeroByte
Forum Guru
Forum Guru
Posts: 4051
Joined: Wed May 11, 2011 6:08 pm

Re: GRE MTU issue

Fri Mar 13, 2015 6:32 pm

<rant>
Broken path MTU discovery is one of the many woes of networking caused by people just discarding all ICMP
</rant>

(I don't mean you - I mean "people")

Try making a mangle rule to clamp the mss of the exim host at whichever router is closest to it. Clamp it silly crazy low like 1200 and see if that makes any difference for you. Move forward from there.
When given a spoon,
you should not cling to your fork.
The soup will get cold.
 
jmginer
Member Candidate
Member Candidate
Topic Author
Posts: 115
Joined: Tue Dec 11, 2012 4:56 am

Re: GRE MTU issue

Fri Mar 13, 2015 6:49 pm

I have this mangle rule on all routers:
[login@mad1] > ip firewall mangle print 
Flags: X - disabled, I - invalid, D - dynamic 
 0    chain=postrouting action=change-mss new-mss=clamp-to-pmtu passthrough=yes tcp-flags=syn protocol=tcp log=no log-prefix="" 
[login@mad1] >
But the issue is still.


I've solved changing the MTU in all GRE's to 1500, incoming mails are entering Ok, also other services seems run ok...

[login@uk1-router] > interface gre print            
Flags: X - disabled, R - running 
 1  R name="mad1" mtu=1500 actual-mtu=1500 local-address=IP.uk1 remote-address=IP.mad1 dscp=inherit clamp-tcp-mss=yes dont-fragment=no 
[login@uk1-router] > 
Can I have other issues related a 1500 MTU in GRE ??
 
User avatar
ZeroByte
Forum Guru
Forum Guru
Posts: 4051
Joined: Wed May 11, 2011 6:08 pm

Re: GRE MTU issue

Fri Mar 13, 2015 6:58 pm

I have this mangle rule on all routers:
[login@mad1] > ip firewall mangle print 
Flags: X - disabled, I - invalid, D - dynamic 
 0    chain=postrouting action=change-mss new-mss=clamp-to-pmtu passthrough=yes tcp-flags=syn protocol=tcp log=no log-prefix="" 
[login@mad1] >
But the issue is still.

Can I have other issues related a 1500 MTU in GRE ??
If pmtu discovery is broken in general, I would expect the mangle rule to fail also.

The only issue with 1500 MTU in GRE is that your routers will now be performing packet fragmentation / reassembly, which can be anything from a complete non-issue to a show-stopping disaster. It depends on how much bandwidth goes through the routers, how much fragmentation happens (100Mbps of VoIP would not matter, because it is already small packets, for instance), and how much horsepower your routers have.

Just watch system load and if the routers don't get overloaded, then you should be okay.
When given a spoon,
you should not cling to your fork.
The soup will get cold.
 
jmginer
Member Candidate
Member Candidate
Topic Author
Posts: 115
Joined: Tue Dec 11, 2012 4:56 am

Re: GRE MTU issue

Fri Mar 13, 2015 7:41 pm

Thanks @ZeroByte for your support!
 
User avatar
ZeroByte
Forum Guru
Forum Guru
Posts: 4051
Joined: Wed May 11, 2011 6:08 pm

Re: GRE MTU issue

Fri Mar 13, 2015 7:48 pm

Thanks @ZeroByte for your support!
No problem.

Remember: Comment, Like, and Subscribe! :lol:
When given a spoon,
you should not cling to your fork.
The soup will get cold.
 
jmginer
Member Candidate
Member Candidate
Topic Author
Posts: 115
Joined: Tue Dec 11, 2012 4:56 am

Re: GRE MTU issue

Thu Apr 16, 2015 4:12 pm

With MTU 1500 on the GRE tunnels, the issue that we detect is that wget downloads from servers connected to mad1 or ali1 and with a IP routed via the GRE (a protected IP) never finish... the download start, but not finish.

Also, if I change the MTU to 1476 (default), the download is Ok, but I have problems with the e-mails (main issue)

In all routers I have the ICMP disabled

/ip firewall filter
add action=drop chain=output comment="Bloquear PING / Trace" protocol=icmp
/ip firewall mangle
add action=change-mss chain=forward new-mss=clamp-to-pmtu passthrough=no protocol=tcp tcp-flags=syn
 
User avatar
ZeroByte
Forum Guru
Forum Guru
Posts: 4051
Joined: Wed May 11, 2011 6:08 pm

Re: GRE MTU issue

Thu Apr 16, 2015 4:32 pm

I sent a long PM about this - but for the sake of the thread, try disabling the ICMP filter, and post here whether that fixes the issue. (even if you stop blocking your own outgoing "icmp fragmentation required" messages, someone else might also be filtering them)

This icmp message is critical in the functioning of path mtu discovery.
When given a spoon,
you should not cling to your fork.
The soup will get cold.
 
jmginer
Member Candidate
Member Candidate
Topic Author
Posts: 115
Joined: Tue Dec 11, 2012 4:56 am

Re: GRE MTU issue

Thu Apr 16, 2015 5:56 pm

Thanks! I'm checking, going to return MTU to 1476 and remove ICMP block rule from firewall.

Why I'm blocking ICMP? Simple reason -> DDoS

If someone wants to DDoS me entire network, just need to DDoS the core router.

If I block ICMP, is not possible to know the IP of the router, so, more difficult to put down the network.
 
User avatar
ZeroByte
Forum Guru
Forum Guru
Posts: 4051
Joined: Wed May 11, 2011 6:08 pm

Re: GRE MTU issue

Thu Apr 16, 2015 6:26 pm

. . . or they can DDoS any host behind the core router, and the link will be flooded anyway....
. . . or they could just send it to random IPs all over your ranges because they don't care - they just want to flood everything. Plus you can't blackhole a victim IP in some tier1's backbone if your entire CIDR block is the victim IP....

If you want to harden the core router against CPU load from processing so much traffic - Put a rate-limit on input chain for ICMP Echo Request ~ 5 per second, burst = 10. This is far below DDoS levels, far above throwing away all ICMP of all types just to block pings. Heck, while you're at it, make an IP address list of managment servers (NOC IP addresses, etc) and put a rate limit input for everything not in that list, and not routing protocols from your own routers and valid ebgp neighbors....

A friend and I were having a conversation just last night on this very topic.
Everyone knows where CIA headquarters is.
It's on Google Earth
Try to go break into it.
When given a spoon,
you should not cling to your fork.
The soup will get cold.

Who is online

Users browsing this forum: No registered users and 92 guests