 LiQuiDBSD geekPremium join:2002-08-08 Anjou, QC | reply to derekm
Re: RFC 4638 and Teksavvy Hey Gabe,
I'd be doing this on OpenBSD and on that OS, it's as simple as setting the physical-if to MTU 1508, and the pppoe pseudo-if to 1500, and restart networking services. I've tried it and noticed that a tcpdump during the session initiation shows that I'm still limited to a max payload of 1492 in the discovery phase. (the same person that implemented this on OpenBSD patched tcpdump to show this info). What's not clear is if that's a result of the portspeed limitation on the cellpipe preventing larger than 1500MTU packets, or if TSI only works with the traditional 1500byte packet that has an encapsulated payload.
Having this would make life easier for sure. Since moving from HSA I noticed that I had to add a couple of scrubbing rules to my firewall, and that triggered issues with some IM protocols and so on... just messy  -- Windows is the virus. Linux is the vaccine, FreeBSD is the CURE |
|
|
|
 InssomniakThe GlitchPremium join:2005-04-06 Cayuga, ON kudos:1 1 edit | said by LiQuiD:Hey Gabe,
I'd be doing this on OpenBSD and on that OS, it's as simple as setting the physical-if to MTU 1508, and the pppoe pseudo-if to 1500, and restart networking services. I've tried it and noticed that a tcpdump during the session initiation shows that I'm still limited to a max payload of 1492 in the discovery phase. (the same person that implemented this on OpenBSD patched tcpdump to show this info). What's not clear is if that's a result of the portspeed limitation on the cellpipe preventing larger than 1500MTU packets, or if TSI only works with the traditional 1500byte packet that has an encapsulated payload.
Having this would make life easier for sure. Since moving from HSA I noticed that I had to add a couple of scrubbing rules to my firewall, and that triggered issues with some IM protocols and so on... just messy  The PPPoE server would have to be configured for MTU max of 1500 byte packets, Im sure its not. The whole path would have to support the oversized packet size.
You are probably talking about MSS rules when you mention "scrubbing".
-- OptionsDSL Wireless Internet »www.optionsdsl.ca |
|
 brad join:2007-09-06 Etobicoke, ON | said by Inssomniak:The PPPoE server would have to be configured for MTU max of 1500 byte packets, Im sure its not. The whole path would have to support the oversized packet size. Yes, it would; if the client indicates it has RFC4638 support. That's the whole point. When the path from the ISP to the DSLAM is all GigE/10Gb Ethernet it would not be an issue. |
|
 InssomniakThe GlitchPremium join:2005-04-06 Cayuga, ON kudos:1 | said by brad:said by Inssomniak:The PPPoE server would have to be configured for MTU max of 1500 byte packets, Im sure its not. The whole path would have to support the oversized packet size. Yes, it would; if the client indicates it has RFC4638 support. That's the whole point. When the path from the ISP to the DSLAM is all GigE/10Gb Ethernet it would not be an issue. Is this the case anywhere? That TSI or any ISP using bell last mile gets GigE or better right to the DSLAM?
Im under the impression that this RFC can never work with Bell right now. -- OptionsDSL Wireless Internet »www.optionsdsl.ca |
|
 brad join:2007-09-06 Etobicoke, ON | said by Inssomniak:Is this the case anywhere? That TSI or any ISP using bell last mile gets GigE or better right to the DSLAM?
Im under the impression that this RFC can never work with Bell right now. The ISP side has been Ethernet for many many years. The FTTN remotes are Ethernet fed. They're using Juniper gear for BRAS' so those should be running 10Gb Ethernet interfaces by now. So yes in theory this is possible. |
|