From: Herbert Xu <[EMAIL PROTECTED]>
Date: Fri, 24 Mar 2006 22:51:16 +1100
> On Thu, Feb 16, 2006 at 10:04:14PM +0200, Ilia Sotnikov wrote:
> >
> > Here it is, against 2.6.16-rc3.
>
> OK, I've brought this patch up-to-date with 2.6.16 and got rid of a few
> more references to tos in ip_rt_redire
On Thu, Feb 16, 2006 at 10:04:14PM +0200, Ilia Sotnikov wrote:
>
> Here it is, against 2.6.16-rc3.
OK, I've brought this patch up-to-date with 2.6.16 and got rid of a few
more references to tos in ip_rt_redirect. Please note that the author
of this patch is Ilia Sotnikov <[EMAIL PROTECTED]>.
Fr
On 2/15/06, Herbert Xu <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 15, 2006 at 03:21:50PM +0200, Ilia Sotnikov wrote:
> >
> > Totally agree but perhaps we should ask the confirmation from someone?
>
> That's what this list is for :) Send a patch and if there are no objections
> it should be go in.
He
On Wed, Feb 15, 2006 at 03:21:50PM +0200, Ilia Sotnikov wrote:
>
> Totally agree but perhaps we should ask the confirmation from someone?
That's what this list is for :) Send a patch and if there are no objections
it should be go in.
> The removal of routing decisions by TOS field would made the
On 2/15/06, Herbert Xu <[EMAIL PROTECTED]> wrote:
> How about dropping TOS from the hash code instead? How many people
> out there actually route using the TOS and use more than two TOS values?
Totally agree but perhaps we should ask the confirmation from someone?
The removal of routing decisions
On Wed, Feb 15, 2006 at 09:34:23AM +0200, Ilia Sotnikov wrote:
>
> In some cases the patch could led to a large number of lookups on
> rt_hash_code over all possible TOS values (additional 8 passes). In
> complex configurations with many routing tables it could be
> computationally expensive. Tha
On 2/15/06, Herbert Xu <[EMAIL PROTECTED]> wrote:
>
> What about doing this unconditionally?
>
In some cases the patch could led to a large number of lookups on
rt_hash_code over all possible TOS values (additional 8 passes). In
complex configurations with many routing tables it could be
computat
Ilia Sotnikov <[EMAIL PROTECTED]> wrote:
>
> +match_tos_for_pmtud
> +---
> +
> +Boolean: 0 (default) - ignore TOS, 1 - match TOS
> +Flag to match the TOS value embedded in ICMP errors during the PMTUD process.
> +By default, the PMTU value is propagated to all routing cach
Recently we run into the problems with Path MTU Discovery.
An Internet host sent ICMP 3/4 "Fragmentation needed and DF bit set"
message but included IP header of original packet had diferent TOS
field rather than we sent. As far as I know it's permitted and some of
ISPs do that to implement their
