Re: Access Concentrators and MTU.

Pretty good.
Now, do common (cisco, redback) PPPoE implementations allow a 1500octets MRU for the PPP layer payload?

My current assumptions are the following: 1) if common service gateways/access concentrators can process IEEE802.3 + IEEE802.1Q tagged packets (4bytes overhead), then they should probably be able to handle 8 bytes of overhead (PPP/PPPoE).

2) if common service gateways/access concentrators can process _non-standard_ "jumbo frames", then they should probably be able to handle a "jumbo frame" of 1518+8.

But, again, it depends on the implementation.

Thanks for the help.
jld.

                                                                                                             
                    Manuel Stol                                                                              
                    ,              
                    dData.com>            ,                     
                    Sent by:             cc:                                                                 
                    owner-pppoe@ip       Subject:     Re: Access Concentrators and MTU.                      
                    sec.org                                                                                  
                                                                                                             
                                                                                                             
                    06/20/2003                                                                               
                    06:52 AM                                                                                 
                                                                                                             
                                                                                                             

According to RFC 1661 PPP:
- the default MRU is 1500 octets
- any side of a PPP link must accept packets of 1500 octets   (for debugging reasons)
- only if a MRU other than 1500 is required,   will the MRU be negotiated.

So, PPP clients and servers will skip the MTU negotiation, if both sides want a MRU of 1500. And the MTU defaults to 1500. However, a PPP client or server should _not_ ignore a MRU option during the LCP negotiation. If either side requests a MRU of 1492, the other side should accept or reject it. Ignoring the MRU option in the sense that it is not explicitly accepted, is the same as accepting it. But this is not in accordance with RCF1661, I think.

Do you need help?
In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related ipsec.org Links pppoe Request more information about Pantek

Tschüß,
Manuel

On Friday 20 June 2003 00:02, John O'Keefe wrote:
> My understanding is that the "clients" such as windows use a value of

--
************************legal disclaimer*****************************
This message, and any attachment, is confidential and may be
legally privileged or otherwise protected from disclosure.
If you are not the intended recipient, please notify the sender
immediately by return e-mail.  You may not copy this message or
attachment, or disclose the contents, to any other person.  You
Do you need more help?
In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software:
Learn more about Pantek's Technical Support offerings
Place an order for 24/7/365 Technical Support here
Learn more about Pantek, who we are, and what we do
Chat with a Live Operator
Related ipsec.org Links
pppoe
Request more information about Pantek
must destroy all copies of the original message and attachment.
Allied Data Technologies is neither liable for the proper nor
complete transmission of the information contained in this
e-mail communication, nor for any delay in its receipt.
*********************************************************************