Remember that MRU is the maximum receive unit. The device sending it is
saying how big packets that it receives can be. The other side could have a
different MRU.

There's no need for them to negotiate it. They don't have to agree. 

RFC 1661 also implies that even if a device advertises a value that is less
than 1500, it must still be able to receive 1500 bytes. So maybe that's why
you still see 1500.

But it may just be that you aren't looking at it as two flows. Just like the
TCP MTU option on a SYN packet, the PPP MRU only requests a max size for
packets received. The max size for sending on that device is based on the
max size that the other side can receive.

Priscilla

paul dong so wrote:
> 
> Hi All,
> 
> I have a question but can't find an answer from RFC 1661
> 
> During ppp negotiation, if A advertises MRU 1440, B advertises
> MRU 1460,
> do they have to re-negotiate to agree with a MRU? If so, should
> it be
> the lower MRU? If they don't need to re-negotiate, what MRU is
> actually
> being used? Is there any guideline for this?
> 
> I observed a ppp nego debug between cisco 7200 and an adsl
> modem, the
> result appears to be if one end advertises 1500, it becomes the
> one
> regardless what MRU the other end advertises.
> 
> Mar  7 03:25:28.768: ppp1152 PPP: Authorization required
> Mar  7 03:25:28.768: ppp1152 PPP: Phase is ESTABLISHING
> Mar  7 03:25:28.768: ppp1152 PPP: Authorization required
> Mar  7 03:25:28.768: ppp1152 LCP: O CONFREQ [Closed] id 1 len 14
> Mar  7 03:25:28.768: ppp1152 LCP:    AuthProto PAP (0x0304C023)
> Mar  7 03:25:28.768: ppp1152 LCP:    MagicNumber 0x8261E624
> (0x05068261E624)
> Mar  7 03:25:28.796: ppp1152 LCP: I CONFREQ [REQsent] id 2 len
> 14
> Mar  7 03:25:28.796: ppp1152 LCP:    MRU 1454 (0x010405AE)
> Mar  7 03:25:28.796: ppp1152 LCP:    MagicNumber 0x6DB9FEC2
> (0x05066DB9FEC2)
> Mar  7 03:25:28.796: ppp1152 LCP: O CONFNAK [REQsent] id 2 len 8
> Mar  7 03:25:28.796: ppp1152 LCP:    MRU 1500 (0x010405DC)
> Mar  7 03:25:28.800: ppp1152 LCP: I CONFACK [REQsent] id 1 len
> 14
> Mar  7 03:25:28.800: ppp1152 LCP:    AuthProto PAP (0x0304C023)
> Mar  7 03:25:28.800: ppp1152 LCP:    MagicNumber 0x8261E624
> (0x05068261E624)
> Mar  7 03:25:28.816: ppp1152 LCP: I CONFREQ [ACKrcvd] id 3 len
> 10
> Mar  7 03:25:28.816: ppp1152 LCP:    MagicNumber 0x6DB9FEC2
> (0x05066DB9FEC2)
> Mar  7 03:25:28.816: ppp1152 LCP: O CONFACK [ACKrcvd] id 3 len
> 10
> Mar  7 03:25:28.816: ppp1152 LCP:    MagicNumber 0x6DB9FEC2
> (0x05066DB9FEC2)
> Mar  7 03:25:28.816: ppp1152 LCP: State is Open
> Mar  7 03:25:28.816: ppp1152 PPP: Phase is AUTHENTICATING, by
> this end
> 
> Thanks
> 
> Paul
> 
> 




Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=66049&t=66007
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

Reply via email to