Alan,

Sure, I'll look into it.   Can you open a ticket and assign it to me?

Scott

On 11/27/05, alan walters <[EMAIL PROTECTED]> wrote:
>
>
>
> radius-ip
>
> When using RADIUS for authentication, enable IP address assignment via
> RADIUS as well.
>
> From the following man page. Do we think we could add this in to the pppoe
> configuration. Sorry  to pester but I did not really get a reply
>
>
>
> http://www.bretterklieber.com/mpd/doc3/mpd22.html#22
>
>
>
> set link latency microseconds
>
> set link bandwidth bits-per-second
>
> These commands are relevant when multi-link PPP is active. They affect the
> way in which packets are chopped up into fragments before being sent over
> the various links that make up the bundle.
>
> To motivate the idea, imagine a bundle that had a modem link and a 1.5Mbps
> T1 link. If mpd sent each packet in two equal sized fragments over these
> links, then by the time the modem got around to transmitting the first byte
> of its fragment, the T1 link would have probably already sent the whole
> other fragment. Clearly this is not very good. By factoring in the latency
> and bandwidth parameters for each link, mpd can distribute the fragments in
> a more intelligent way.
>
> Mpd attempts to distribute bytes over the links so that (if the configured
> parameters are accurate) the last byte of each fragment arrives at the peer
> at the same time on each link. This minimizes latency. However, if you only
> care about maximizing throughput, simply set all of the latency values to
> zero.
>
> If all of your links are of the same type and speed (which is often the
> case), then they should be configured with the same values (or just not
> configured at all, since all links default to the same values anyway). Then
> mpd will distribute packets in equal sized fragments over the links.
>
> set link mtu numbytes
>
> set link mru numbytes
>
> The set link mtu command sets the maximum transmit unit (MTU) value for the
> link. This is the size of the largest single PPP frame (minus PPP header)
> that this link will transmit, unless the peer requests an even lower value.
> The default value is 1500 bytes.
>
> The set link mru command sets maximum receive unit (MRU) value for the link,
> which is the size of the largest single PPP frame (minus PPP header) that
> this link is capable of receiving. The default value is 1500 bytes.
>
> If PPP multilink is negotiated on a link, then these values are less
> important, because multilink allows PPP frames themselves to be fragmented,
> so a PPP frame can always pass through no matter how small the MTU is in a
> particular direction.
>
> Otherwise, mpd is responsible for making sure that the MTU configured on the
> system networking interface is low enough so that the largest transmitted IP
> packet does not exceed the peer's negotiated MRU after it becomes a PPP
> frame. This includes e.g. PPP encryption and/or compression overhead.
>
> However, mpd does not account for overhead that occurs ``outside'' of the
> PPP frame. For example, when using link types such as PPTP that encapsulate
> PPP frames within IP packets, a large outgoing ``inner'' IP packet can
> result in a fragmented ``outer'' IP packet, resulting in suboptimal
> performance. In this situation it may be useful to set the link MTU to a
> lower value to avoid fragmentation.
>
>
>
> Additionally I would feelthat for a good pppoe server configuration these
> should be configurable ideas. As different uplinks will possibly cause bad
> fragmentation within the pppoe implementation.
>
>
>
>  ________________________________
>
>
> From: alan walters
>  Sent: Friday, November 25, 2005 8:23 PM
>  To: support@pfsense.com
>  Subject: [pfSense Support] pppoe implementation of mpd
>
>   Is it possible to incorporate these attrubutes into the mpd pppoe config.
> Or am I missing something and it is already there but not worling for me.
>
>
> set radius me $nasip
> set ipcp yes radius-ip
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to