PPPoE (over Ethernet) ---> Ethernet max 1500 But I'm very curious if there are some non standards drafts over ethernet for such kind of applications ?

Chris

...

...

"Spiess Bernd" Bernd.Spiess@happynet.at 12.06.2007 18:00 >>>

thanx for the suggestions - the mtu path discovery problem was the reason why i asked.

fyi: here in austria we have own access to the copper from "telekom austria" (colocation/"unbundling") we have our own dslaḿs and our own selection of cpés - so we can build or configure whatever we like. actually we use static ip on a switched layer 2 vlan-trunk environment. if possible we want to avoid PPPoA because we are no atm people.

as i understand you correct mtu 1492 under PPPoE is still an issue in the mentioned cases.

has anyone tried to build PPPoE with an MTU 1508 infrastructure ?

bernd

-----Original Message----- From: swinog-bounces@lists.swinog.ch [mailto:swinog-bounces@lists.swinog.ch] On Behalf Of Fabian Wenk Sent: Tuesday, June 12, 2007 12:52 PM To: swinog@swinog.ch Subject: [Spam] Re: [swinog] feedback on pppoe needed

Hello Bernd

Spiess Bernd wrote:

as i know many postings around the world regarding pppoe mtu problems and advices to customers to reduce mtu on their clients down to 1492, i wanted

The problems with MTU 1492 could be on other places, eg. if a web server admin decides to filter ICMP on his server which will prevent Path MTU Discovery to work. For example this can have the effect, that from a website (hosted on a server which does not get the ICMP messages) the HTML part arrived (smaller then 1500 bytes), but the corresponding pictrures do not. I did once write a paper about the ADSL MTU problem, see "Swiss ADSL with PPPoA (and MTU 1500)" [1] for more informations.

[1] http://www.wenks.ch/fabian/ADSL-PPPoA.html

I hope for you, that ADSL with PPPoA will also work in Austria.

bye Fabian _______________________________________________ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog _______________________________________________ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

I was thinking about the cheap CPE side, perhaps the next generation of CPE's with Giga ports will solve this issue ? ;-)

...

...

Christian.Kuster@swisscom.com 13.06.2007 11:40 >>>

Why non standard? Gigabit Ethernet supports jumbo frames.....only Ethernet and Fastethernet have this limitation..

-----Original Message----- From: swinog-bounces@lists.swinog.ch [mailto:swinog-bounces@lists.swinog.ch] On Behalf Of Christian Jouas Sent: Wednesday, June 13, 2007 11:30 AM To: swinog@swinog.ch Subject: Re: [swinog] feedback on pppoe needed

PPPoE (over Ethernet) ---> Ethernet max 1500 But I'm very curious if there are some non standards drafts over ethernet for such kind of applications ?

Chris

_______________________________________________ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Hi all,

We just had a case where we missed some mails from a vendor, and those mails now have arrived with three month delay. After some investigation we found the reason for the delay: the vendor is using Exchange 2003 SP2, which has a known, still unfixed bug. It causes outbound mail to domains that implement greylisting to be jailed in a black hole until the SMTP service is restarted.

If you are having an issue with greylisting, please review the problem description below. Should your problem match the description below and the workaround works for you, Microsoft has advised me to ask you to raise a support call with them. When you raise your support call, please ask that they link the call to the EMEA case SRZ060302000872. This way, should a number of customers be seeing the problem, it can be tracked within Microsoft.

SYMPTOMS =========

When Exchange tries to send mails to certain domains that implement "greylisting", the mails fail to get delivered, without any intimation to the sender on the first attempt. Thereafter on either restarting the server or SMTP service, the mails get delivered to the destination domains. At times, NDRs for these delayed mails are also generated after rebooting.

PROBLEM ========

The issue is intermittent and occurs only when the destination domains have greylisting implemented and mail is sent to the greylisted domain the very first time.

WORKAROUNDS ===========

1. Write a script to restart the SMTP service at least once a day. 2. Modify the registry on the sender Exchange server, to change the Glitch Retry key. 3. Clarify that there is no 3rd party AV software in the environment which could be causing the issue.

-- Martin

Martin Blapp, mb@imp.ch mbr@FreeBSD.org ------------------------------------------------------------------ ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 61 826 93 00 Fax: +41 61 826 93 01 PGP: <finger -l mbr@freebsd.org> PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E ------------------------------------------------------------------

4. remove MS Exchange as its unable to fulfill internet capabilities.

or

5. use a smarthost instead of connecting MS Exchange directly to the internet :-)

-- Martin

Hi,

I can't believe that even Exchange would be unable to do a retry - there are plenty of situations where a server might return a temporary 45x error.

The error isn't easy to reproduce. It seems that some conditions are necessary. It might be a race condition.

Exchange never managed it to 100% comply with the existing RFCs. That hasn't changed at all. And it still looks like Microsoft doesn't handle bugs seriously if only a small to average userbase is affected. This bug has only made it up to the second level support of Microsoft.

-- Martin

Martin Blapp wrote:

Hi,

...

I can't believe that even Exchange would be unable to do a retry - there are plenty of situations where a server might return a temporary 45x error.

The error isn't easy to reproduce. It seems that some conditions are necessary. It might be a race condition.

Exchange never managed it to 100% comply with the existing RFCs.

That I can easily believe, but it just seems incredible that it wouldn't be able to deal with a retry. Which is why I doubt it should somehow be related to greylisting.

Chris,

http://mirror.switch.ch/rfc/4638.txt describes exactly the discussed topic.

btw it also states that no current IEEE standard supports the use of "jumbo frames" altough these are widely used in various network scenarios.

stefan

-----Original Message----- From: swinog-bounces@lists.swinog.ch [mailto:swinog-bounces@lists.swinog.ch] On Behalf Of Christian Jouas Sent: Wednesday, June 13, 2007 11:30 AM To: swinog@swinog.ch Subject: Re: [swinog] feedback on pppoe needed

PPPoE (over Ethernet) ---> Ethernet max 1500 But I'm very curious if there are some non standards drafts over ethernet for such kind of applications ?

Chris

...

...

"Spiess Bernd" Bernd.Spiess@happynet.at 12.06.2007 18:00 >>>

thanx for the suggestions - the mtu path discovery problem was the reason why i asked.

fyi: here in austria we have own access to the copper from "telekom austria" (colocation/"unbundling") we have our own dslaḿs and our own selection of cpés - so we can build or configure whatever we like. actually we use static ip on a switched layer 2 vlan-trunk environment. if possible we want to avoid PPPoA because we are no atm people.

as i understand you correct mtu 1492 under PPPoE is still an issue in the mentioned cases.

has anyone tried to build PPPoE with an MTU 1508 infrastructure ?

bernd

-----Original Message----- From: swinog-bounces@lists.swinog.ch [mailto:swinog-bounces@lists.swinog.ch] On Behalf Of Fabian Wenk Sent: Tuesday, June 12, 2007 12:52 PM To: swinog@swinog.ch Subject: [Spam] Re: [swinog] feedback on pppoe needed

Hello Bernd

Spiess Bernd wrote:

as i know many postings around the world regarding pppoe mtu problems and advices to customers to reduce mtu on their clients down to 1492, i wanted

The problems with MTU 1492 could be on other places, eg. if a web server admin decides to filter ICMP on his server which will prevent Path MTU Discovery to work. For example this can have the effect, that from a website (hosted on a server which does not get the ICMP messages) the HTML part arrived (smaller then 1500 bytes), but the corresponding pictrures do not. I did once write a paper about the ADSL MTU problem, see "Swiss ADSL with PPPoA (and MTU 1500)" [1] for more informations.

[1] http://www.wenks.ch/fabian/ADSL-PPPoA.html

I hope for you, that ADSL with PPPoA will also work in Austria.

bye Fabian _______________________________________________ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog _______________________________________________ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog _______________________________________________ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Hoi Fabian,

Am 12.6.2007 12:52 Uhr, Fabian Wenk schrieb:

...

as i know many postings around the world regarding pppoe mtu problems and advices to customers to reduce mtu on their clients down to 1492, i wanted

The problems with MTU 1492 could be on other places, eg. if a web server admin decides to filter ICMP on his server which will prevent Path MTU Discovery to work. For example this can have the effect, that from a website (hosted on a server which does not get the ICMP messages) the HTML part arrived (smaller then 1500 bytes), but the corresponding pictrures do not. I did once write a paper about the ADSL MTU problem, see "Swiss ADSL with PPPoA (and MTU 1500)" [1] for more informations.

[1] http://www.wenks.ch/fabian/ADSL-PPPoA.html

I hope for you, that ADSL with PPPoA will also work in Austria.

Ist es möglich den 642R auch als Bridge zu konfigurieren um PPPoA zu benutzen?

PS: Was ist denn tracepath für ein Tool?

Ihsan