netdev - Re: linux-3.0.x regression with ipv4 routes having mtu

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20111222.135127.1577166695312077920.davem@davemloft.net>
Date:	Thu, 22 Dec 2011 13:51:27 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	steffen.klassert@...unet.com
Cc:	timo.teras@....fi, netdev@...r.kernel.org
Subject: Re: linux-3.0.x regression with ipv4 routes having mtu

From: Steffen Klassert <steffen.klassert@...unet.com>
Date: Thu, 22 Dec 2011 11:25:26 +0100

> Actually, I'm getting some doubts on the concept of caching
> the metrics on the inetpeer. How should we handle the case when
> we have multiple routes with different metrics to the same
> destination? As it is, we can cache just one of them on the
> inetpeer.

In such cases the metrics won't be perfect.

Actually, we have two kinds of metrics and it might be best in the
long term to seperate them out explicitly.

We have "loose" metrics (such as all the TCP measurements) which,
if incorrect, will lead to suboptimal performance but will not
dramatically effect connectivity.

Then we have "strict" metrics like PMTU information and redirects,
which could have more fatal consequences if wrong.

The core issue is I want to keep these things tied only to destination
address, it is the only sane way to get the routing cache removed.

Sockets and the packet forwarding path in the future will be using
routes that cover whole subnets, or even the default route.  There
will be no "rt->rt_dst" and there will also be not attached inetpeer.

The inetpeer, or something like it, will be managed seperately.
Therefore metrics will need to be calculated using both objects (rt
and inetpeer).

This is one of the longer term design issues we face in the routing
cache removal and for which I don't have exact plans for yet.  I'm
still concentrating on "ref-less" neighbour entries, so once I finish
that work I can think more seriously about metrics in a world without
the routing cache.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html