| Message ID | 52804865.8090206@cn.fujitsu.com |
|---|---|
| State | Deferred, archived |
| Delegated to: | David Miller |
| Headers | show |
On Mon, Nov 11, 2013 at 11:00:53AM +0800, Duan Jiong wrote: > Now the kernel only match those routes that have the same > metirc, so if those routes are non-reachable, then the packets > can't be sent out. > > But according to the rfc 4191 section 3.2, if the best route > points to a non-reachable route, the next best route should be > consulted. So the kernel should not only match those routes that > have minimum metric, and should also match others. I am not so keen on chaning how metrics get handled. Please note that metrics are a pure linux-centric concept and are not standardized. I bet some people depend on how these work and have the same semantic as IPv4 ones because they use the same code in their routing daemon backends. Also, I think it is better targetted for net-next, which is currently closed. So we have some time to discuss. ;) Greetings, Hannes -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
于 2013年11月11日 14:07, Hannes Frederic Sowa 写道: > On Mon, Nov 11, 2013 at 11:00:53AM +0800, Duan Jiong wrote: >> Now the kernel only match those routes that have the same >> metirc, so if those routes are non-reachable, then the packets >> can't be sent out. >> >> But according to the rfc 4191 section 3.2, if the best route >> points to a non-reachable route, the next best route should be >> consulted. So the kernel should not only match those routes that >> have minimum metric, and should also match others. > > I am not so keen on chaning how metrics get handled. Please note that > metrics are a pure linux-centric concept and are not standardized. I bet > some people depend on how these work and have the same semantic as IPv4 > ones because they use the same code in their routing daemon backends. > I have a question. If we only match those routes that have lowest metric, others will never be used, so why the other routes are inserted to the router table? Thanks, Duan > Also, I think it is better targetted for net-next, which is currently closed. > So we have some time to discuss. ;) > > Greetings, > > Hannes > > -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Nov 11, 2013 at 03:16:24PM +0800, Duan Jiong wrote: > 于 2013年11月11日 14:07, Hannes Frederic Sowa 写道: > > On Mon, Nov 11, 2013 at 11:00:53AM +0800, Duan Jiong wrote: > >> Now the kernel only match those routes that have the same > >> metirc, so if those routes are non-reachable, then the packets > >> can't be sent out. > >> > >> But according to the rfc 4191 section 3.2, if the best route > >> points to a non-reachable route, the next best route should be > >> consulted. So the kernel should not only match those routes that > >> have minimum metric, and should also match others. > > > > I am not so keen on chaning how metrics get handled. Please note that > > metrics are a pure linux-centric concept and are not standardized. I bet > > some people depend on how these work and have the same semantic as IPv4 > > ones because they use the same code in their routing daemon backends. > > > > I have a question. If we only match those routes that have lowest metric, others > will never be used, so why the other routes are inserted to the router table? Metrics could get used by software which manages dynamic interfaces, e.g. vpn/ppp software, to make sure they have priority over the current routing settings. If we don't respect metrics there, this could lead to security problems. (if the interface vanishes, the other route gets active again). It could also be used by dynamic routing software, e.g. is-is, ospf, bgp and does reflect the admins choice where traffic should get routed. Some routing daemon apply the whole routing table to the fib. If we don't respect metrics there, they could lose money, because maybe they pay for the traffic. They really get interesting if you have more than one routing protocol active at the same time. ;) Greetings, Hannes -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
于 2013年11月11日 15:39, Hannes Frederic Sowa 写道: > On Mon, Nov 11, 2013 at 03:16:24PM +0800, Duan Jiong wrote: >> 于 2013年11月11日 14:07, Hannes Frederic Sowa 写道: >>> On Mon, Nov 11, 2013 at 11:00:53AM +0800, Duan Jiong wrote: >>>> Now the kernel only match those routes that have the same >>>> metirc, so if those routes are non-reachable, then the packets >>>> can't be sent out. >>>> >>>> But according to the rfc 4191 section 3.2, if the best route >>>> points to a non-reachable route, the next best route should be >>>> consulted. So the kernel should not only match those routes that >>>> have minimum metric, and should also match others. >>> >>> I am not so keen on chaning how metrics get handled. Please note that >>> metrics are a pure linux-centric concept and are not standardized. I bet >>> some people depend on how these work and have the same semantic as IPv4 >>> ones because they use the same code in their routing daemon backends. >>> >> >> I have a question. If we only match those routes that have lowest metric, others >> will never be used, so why the other routes are inserted to the router table? > > Metrics could get used by software which manages dynamic interfaces, e.g. > vpn/ppp software, to make sure they have priority over the current routing > settings. If we don't respect metrics there, this could lead to security > problems. (if the interface vanishes, the other route gets active again). > > It could also be used by dynamic routing software, e.g. is-is, ospf, bgp and > does reflect the admins choice where traffic should get routed. Some routing > daemon apply the whole routing table to the fib. If we don't respect metrics > there, they could lose money, because maybe they pay for the traffic. > They really get interesting if you have more than one routing protocol active > at the same time. ;) > Thanks for your reply. I think i don't fully understand the metric, and this patch should be ignored! I am sorry that bothers your. Thanks, Duan -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/net/ipv6/route.c b/net/ipv6/route.c index 7faa9d5..96cd22a 100644 --- a/net/ipv6/route.c +++ b/net/ipv6/route.c @@ -629,7 +629,7 @@ static struct rt6_info *find_match(struct rt6_info *rt, int oif, int strict, if (strict & RT6_LOOKUP_F_REACHABLE) rt6_probe(rt); - if (m > *mpri) { + if (m > *mpri && (!match || rt->rt6i_metric == match->rt6i_metric)) { *do_rr = match_do_rr; *mpri = m; match = rt; @@ -639,19 +639,13 @@ out: } static struct rt6_info *find_rr_leaf(struct fib6_node *fn, - struct rt6_info *rr_head, - u32 metric, int oif, int strict, - bool *do_rr) + int oif, int strict, bool *do_rr) { struct rt6_info *rt, *match; int mpri = -1; match = NULL; - for (rt = rr_head; rt && rt->rt6i_metric == metric; - rt = rt->dst.rt6_next) - match = find_match(rt, oif, strict, &mpri, match, do_rr); - for (rt = fn->leaf; rt && rt != rr_head && rt->rt6i_metric == metric; - rt = rt->dst.rt6_next) + for (rt = fn->leaf; rt; rt = rt->dst.rt6_next) match = find_match(rt, oif, strict, &mpri, match, do_rr); return match; @@ -667,14 +661,13 @@ static struct rt6_info *rt6_select(struct fib6_node *fn, int oif, int strict) if (!rt0) fn->rr_ptr = rt0 = fn->leaf; - match = find_rr_leaf(fn, rt0, rt0->rt6i_metric, oif, strict, - &do_rr); + match = find_rr_leaf(fn, oif, strict, &do_rr); if (do_rr) { struct rt6_info *next = rt0->dst.rt6_next; /* no entries matched; do round-robin */ - if (!next || next->rt6i_metric != rt0->rt6i_metric) + if (!next) next = fn->leaf; if (next != rt0)
Now the kernel only match those routes that have the same metirc, so if those routes are non-reachable, then the packets can't be sent out. But according to the rfc 4191 section 3.2, if the best route points to a non-reachable route, the next best route should be consulted. So the kernel should not only match those routes that have minimum metric, and should also match others. Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com> --- net/ipv6/route.c | 17 +++++------------ 1 file changed, 5 insertions(+), 12 deletions(-)