FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian User

 
 
LinkBack Thread Tools
 
Old 08-31-2011, 04:09 PM
Camaleón
 
Default MTU and Postfix

Hello,

I've been busy on these days trying to solve a problem with Postfix that
drove me nuts.

Sporadically (let's say one in hundred e-mails) my Postfix had problems
for delivering messages with ~3 MiB of attachment to some e-mail hosts.
DSN service returned the final notice of delivery to the user and logs
displayed an error like "timed out while sending message body".

These hosts were not of those "difficult" ones like Hotmail, Gmail,
Yahoo! or the like that because to their high volume of traffic implement
additional (and sometimes strambotic) measures to prevent spam and such
"anti-all" systems that may require a different transport definiton in
Postfix to get e-mails delivered.

Moreover, these hosts were not e-mail servers that are behind Cisco PIX
devices or using MS Exchange servers that are also well-known to be
conflictive to "dialogue" with.

Nope, I was having problems for delivering to common, small hosts of mid-
size companies, one of the hosts running a Debian system, like mine. So I
had to run some tests to find out what could be the problem here.

I first tried to define a less conservative values (by increasing the
time) for "smtp_data_done_timeout", "smtp_data_xfer_timeout" and
"smtp_data_init_timeout" but this had no effect at all and again, some e-
mails were still undelivered.

Googling around I found some posts and articles¹ pointing to the MTU
value (my bonded interface was set by default to 1500) and as I had
nothing to lose, I changed this and lowered to 1400.

This turned out to work wonders and since then (that's more than a week
ago) I still had no other DSN delivery errors. Besides, e-mails in
deferred queue that could not be sent in that time, after lowering the
MTU value were also delivered with no apparent problems.

I'm still monitoring this but if this is the "cure" to prevent such
errors, are there any expected drawbacks for lowering MTU "system-wide"?

The server has dual gigabit NIC which are bonded (in backup mode) and
server itself is behind a FTTH gigabit router. The server also hosts a
web server.

Any comments or experiences on this are welcome :-)

¹http://www.hsc.fr/ressources/cours/postfix/doc/faq.html#timeouts

Greetings,

--
Camaleón


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: pan.2011.08.31.16.09.23@gmail.com">http://lists.debian.org/pan.2011.08.31.16.09.23@gmail.com
 
Old 09-04-2011, 10:40 AM
Camaleón
 
Default MTU and Postfix

On Wed, 31 Aug 2011 16:09:23 +0000, Camaleón wrote:

(...)

> I'm still monitoring this but if this is the "cure" to prevent such
> errors, are there any expected drawbacks for lowering MTU "system-wide"?

(...)

Mmm, no replies yet...

Does it mean then that there are no gotchas to care about in setting a
MTU value of 1400 for a bonded interface? :-)

Greetings,

--
Camaleón


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: pan.2011.09.04.10.40.29@gmail.com">http://lists.debian.org/pan.2011.09.04.10.40.29@gmail.com
 
Old 09-04-2011, 11:33 AM
lina
 
Default MTU and Postfix

On Sun, Sep 4, 2011 at 6:40 PM, Camaleón <noelamac@gmail.com> wrote:
> On Wed, 31 Aug 2011 16:09:23 +0000, Camaleón wrote:
>
> (...)
>
>> I'm still monitoring this but if this is the "cure" to prevent such
>> errors, are there any expected drawbacks for lowering MTU "system-wide"?
>
> (...)
>
> Mmm, no replies yet...

Reply:

Sorry, I do not understand well most what you said even I read three times.
May I ask one thing here,
Last time I tried the icedove but don't know how to set the SMTP for
hotmail one.
Is the icedove a good choice (for me) to grab emails from hotmail and gmail?
Seems Postfix is "heavy" for me?

Thanks,
>
> Does it mean then that there are no gotchas to care about in setting a
> MTU value of 1400 for a bonded interface? :-)
>
> Greetings,
>
> --
> Camaleón
>
>
> --
> To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: http://lists.debian.org/pan.2011.09.04.10.40.29@gmail.com
>
>



--
Best Regards,

lina


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAG9cJmmvf7CE0RxeYbkRpU4EjwUaGFr1marezPxY7BsBiN=DQ w@mail.gmail.com">http://lists.debian.org/CAG9cJmmvf7CE0RxeYbkRpU4EjwUaGFr1marezPxY7BsBiN=DQ w@mail.gmail.com
 
Old 09-04-2011, 11:54 AM
Mihira Fernando
 
Default MTU and Postfix

On Sunday 04 September 2011 5:03:41 pm lina wrote:
> Sorry, I do not understand well most what you said even I read three times.
> May I ask one thing here,
> Last time I tried the icedove but don't know how to set the SMTP for
> hotmail one.
> Is the icedove a good choice (for me) to grab emails from hotmail and
> gmail? Seems Postfix is "heavy" for me?
>
> Thanks,

Icedove works fine with Gmail. From gmail settings, enable POP3 access and
then in Icedove, set the setttings as given here :
http://mail.google.com/support/bin/answer.py?answer=86400


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201109041724.16757.mihiratheace@gmail.com">http://lists.debian.org/201109041724.16757.mihiratheace@gmail.com
 
Old 09-04-2011, 11:56 AM
Osamu Aoki
 
Default MTU and Postfix

HI,

On Sun, Sep 04, 2011 at 10:40:29AM +0000, Camaleón wrote:
> On Wed, 31 Aug 2011 16:09:23 +0000, Camaleón wrote:
>
> (...)
>
> > I'm still monitoring this but if this is the "cure" to prevent such
> > errors, are there any expected drawbacks for lowering MTU "system-wide"?
>
> (...)
>
> Mmm, no replies yet...
>
> Does it mean then that there are no gotchas to care about in setting a
> MTU value of 1400 for a bonded interface? :-)
>
> Greetings,

Some router between you and outside have issue, I guess.

It is a bit complicated. My best effort information is here:

http://www.debian.org/doc/manuals/debian-reference/ch05.en.html#_finding_optimal_mtu

Osamu


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110904115651.GA8722@debian.org">http://lists.debian.org/20110904115651.GA8722@debian.org
 
Old 09-04-2011, 12:14 PM
D G Teed
 
Default MTU and Postfix

On Wed, Aug 31, 2011 at 1:09 PM, Camaleón <noelamac@gmail.com> wrote:

Hello,



I've been busy on these days trying to solve a problem with Postfix that

drove me nuts.



Sporadically (let's say one in hundred e-mails) my Postfix had problems

for delivering messages with ~3 MiB of attachment to some e-mail hosts.

DSN service returned the final notice of delivery to the user and logs

displayed an error like "timed out while sending message body".



These hosts were not of those "difficult" ones like Hotmail, Gmail,

Yahoo! or the like that because to their high volume of traffic implement

additional (and sometimes strambotic) measures to prevent spam and such

"anti-all" systems that may require a different transport definiton in

Postfix to get e-mails delivered.



Moreover, these hosts were not e-mail servers that are behind Cisco PIX

devices or using MS Exchange servers that are also well-known to be

conflictive to "dialogue" with.



Nope, I was having problems for delivering to common, small hosts of mid-

size companies, one of the hosts running a Debian system, like mine. So I

had to run some tests to find out what could be the problem here.



I first tried to define a less conservative values (by increasing the

time) for "smtp_data_done_timeout", "smtp_data_xfer_timeout" and

"smtp_data_init_timeout" but this had no effect at all and again, some e-

mails were still undelivered.



Googling around I found some posts and articles¹ pointing to the MTU

value (my bonded interface was set by default to 1500) and as I had

nothing to lose, I changed this and lowered to 1400.



This turned out to work wonders and since then (that's more than a week

ago) I still had no other DSN delivery errors. Besides, e-mails in

deferred queue that could not be sent in that time, after lowering the

MTU value were also delivered with no apparent problems.



I'm still monitoring this but if this is the "cure" to prevent such

errors, are there any expected drawbacks for lowering MTU "system-wide"?



The server has dual gigabit NIC which are bonded (in backup mode) and

server itself is behind a FTTH gigabit router. The server also hosts a

web server.



Any comments or experiences on this are welcome :-)



¹http://www.hsc.fr/ressources/cours/postfix/doc/faq.html#timeouts



You might want to try the postfix mailing list and see if they have any ideas.Be prepared for cold, hard, terse answers. *They don't chat much - busy I guess.

Was the previous MTU of 1500, a value you had set, or the default when queried?
I'm wondering because of a recent experience I had tweaking MTU. *I wanted to try jumbo frames
to improve samba throughput on large video files. *With MTU set to 9000 on Linux and Windows,throughput increased about 8 times. *But it caused problems with the web service on Linux,which was running a domain under dyndns. *I set the MTU on Linux back to unspecified, but
left the jumbo frame active on Windows side. *The performance was still very good in largesamba file transfers. *I might remember this wrong, but it seemed it was worse performancewhen Linux side specified 1500, so I left it as unspecified and it has worked well.
I still get high transfer speeds in samba with unspecified MTU on Linux but jumboof 9000 MTU on Windows side.
BTW, 1492 is a common MTU seen in FAQs. *You might get just as good with that.
 
Old 09-04-2011, 01:30 PM
Camaleón
 
Default MTU and Postfix

On Sun, 04 Sep 2011 20:56:51 +0900, Osamu Aoki wrote:

> HI,
>
> On Sun, Sep 04, 2011 at 10:40:29AM +0000, Camaleón wrote:
>> On Wed, 31 Aug 2011 16:09:23 +0000, Camaleón wrote:
>>
>> (...)
>>
>> > I'm still monitoring this but if this is the "cure" to prevent such
>> > errors, are there any expected drawbacks for lowering MTU
>> > "system-wide"?
>>
>> (...)
>>
>> Mmm, no replies yet...
>>
>> Does it mean then that there are no gotchas to care about in setting a
>> MTU value of 1400 for a bonded interface? :-)
>
> Some router between you and outside have issue, I guess.
>
> It is a bit complicated. My best effort information is here:
>
> http://www.debian.org/doc/manuals/debian-reference/ch05.en.html#_finding_optimal_mtu

Thanks... I should have imagined there must be something about this in
the manual :-)

I was indeed making that kind of tests to value what MTU size was the
best for that specific case and tried first with "1492" but messages were
still left in "deferred" queue. Once I changed to "1400" all of the
pending postings could finally be delivered.

I have now setup the bonded interface to stick to this MTU (1400) as
stated in section "5.8.2. Setting MTU".

Greetings,

--
Camaleón


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: pan.2011.09.04.13.30.45@gmail.com">http://lists.debian.org/pan.2011.09.04.13.30.45@gmail.com
 
Old 09-04-2011, 01:39 PM
Camaleón
 
Default MTU and Postfix

On Sun, 04 Sep 2011 14:06:02 +0200, Markus Schönhaber wrote:

> 04.09.2011 12:40, Camaleón:
>
>>> I'm still monitoring this but if this is the "cure" to prevent such
>>> errors, are there any expected drawbacks for lowering MTU
>>> "system-wide"?
>>
>> (...)
>>
>> Mmm, no replies yet...
>>
>> Does it mean then that there are no gotchas to care about in setting a
>> MTU value of 1400 for a bonded interface? :-)
>
> I don't see any gotchas besides the obvious one: the throughput is
> decreased somewhat, since on average more packets are needed to transmit
> the same amount of payload.
>
> OTOH, in my experience, when you can work around transmission problems
> by lowering the MTU, almost always someone has b0rked his packet filter
> and throws away those ultra-evil ICMP packets like "Fragmentation
> Needed" or "Time Exceeded in Transit" etc. If you're sure you're not the
> one killing ICMP and the problems only occur with specific sites, it
> might be helpful to have the administrators of those sites check their
> "firewall" configuration.

I agree. The best way to sort out these problems is by carrying out
additional tests with the host we were experiencing problems but I've had
not very good experiences when contacting Spanish admins, most of them
just don't reply at all or are not interested in solving this
problematic ;-(

Greetings,

--
Camaleón


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: pan.2011.09.04.13.39.34@gmail.com">http://lists.debian.org/pan.2011.09.04.13.39.34@gmail.com
 
Old 09-04-2011, 01:52 PM
Camaleón
 
Default MTU and Postfix

On Sun, 04 Sep 2011 09:14:45 -0300, D G Teed wrote:

> On Wed, Aug 31, 2011 at 1:09 PM, Camaleón <noelamac@gmail.com> wrote:
>
>> I've been busy on these days trying to solve a problem with Postfix
>> that drove me nuts.
>>
>> Sporadically (let's say one in hundred e-mails) my Postfix had problems
>> for delivering messages with ~3 MiB of attachment to some e-mail hosts.
>> DSN service returned the final notice of delivery to the user and logs
>> displayed an error like "timed out while sending message body".

(...)

>> Googling around I found some posts and articles¹ pointing to the MTU
>> value (my bonded interface was set by default to 1500) and as I had
>> nothing to lose, I changed this and lowered to 1400.

(...)

> You might want to try the postfix mailing list and see if they have any
> ideas.
> Be prepared for cold, hard, terse answers. They don't chat much - busy
> I guess.

:-)

Should I couldn't solve the problem, sure, I would had to post in there.

The fact is I like Postfix so much, I find it very flexible and easy to
deal with but in specific case, I didn't think the app was the culprit
but as Osamu has pointed out, a router or a filter (firewall) in between
our hosts making noise.

> Was the previous MTU of 1500, a value you had set, or the default when
> queried?

1500 was the default MTU value for the bonded interfaces. I thinks is the
system default for ethernet devices nowadays.

> I'm wondering because of a recent experience I had tweaking MTU. I
> wanted to try jumbo frames to improve samba throughput on large video
> files. With MTU set to 9000 on Linux and Windows, throughput increased
> about 8 times. But it caused problems with the web service on Linux,
> which was running a domain under dyndns. I set the MTU on Linux back to
> unspecified, but left the jumbo frame active on Windows side. The
> performance was still very good in large samba file transfers. I might
> remember this wrong, but it seemed it was worse performance when Linux
> side specified 1500, so I left it as unspecified and it has worked well.
> I still get high transfer speeds in samba with unspecified MTU on Linux
> but jumbo of 9000 MTU on Windows side.

That was exactly the kind of problems I would like to avoid :-) But as
you said, lower values for MTU are not prone to errors or conflicts but
higher ones (like jumbo frames). I hope performance is not badly
penalized for having a low value, though...

> BTW, 1492 is a common MTU seen in FAQs. You might get just as good with
> that.

MTU is now set at 1400. The host I was trying to contact seemed to be
fine with that setting so I kept it so.

Greetings,

--
Camaleón


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: pan.2011.09.04.13.52.24@gmail.com">http://lists.debian.org/pan.2011.09.04.13.52.24@gmail.com
 
Old 09-06-2011, 04:58 AM
Stan Hoeppner
 
Default MTU and Postfix

On 9/4/2011 5:40 AM, Camaleón wrote:

On Wed, 31 Aug 2011 16:09:23 +0000, Camaleón wrote:

(...)


I'm still monitoring this but if this is the "cure" to prevent such
errors, are there any expected drawbacks for lowering MTU "system-wide"?


Slightly lower overall performance when communicating with remote hosts.
Almost zero difference on the LAN.


If you want optimal performance, you should enable jumbo frames on all
LAN hosts (9000 bytes) since you're using GbE, and install an edge
router that handles jumbo frames. Then you need not worry about any of
this. Just make sure you find out from your service provider what size
frames they use. Then program the WAN interface on the router with that
frame size (MTU).


Problems such as yours are always caused by MTU mismatches. In most
cases the mismatch is between the customer's edge device and the service
provider equipment. Good routers will handle this just fine as long as
the WAN port MTU is programmed to match the service provider equipment.


Worth noting is that different network technologies use different frame
sizes. For instance, ethernet uses a 1514 octet frame. Fiber channel
uses 2112. FDDI uses 4500. SONET is 2430.


You mentioned a "FTTH gigabit router" previously. Is this SP equipment
or your independent equipment? The MTU mismatch most likely exists
inside that box. If it was provided to you, then someone probably
didn't program it correctly. It should have worked fine with different
MTUs on both sides.


--
Stan


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Archive: 4E65A875.2070201@hardwarefreak.com">http://lists.debian.org/4E65A875.2070201@hardwarefreak.com
 

Thread Tools




All times are GMT. The time now is 08:26 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org