: Add support for multipath route realms
Subsystems (2)
[IPROUTE]: Add support for multipath route realms
Routing realms exist per nexthop, but iproute currently only allows to send a single route realm, which is refused by the kernel for multipath routes. Add support for specifying per nexthop realms. Old kernels only return the first realm back to userspace when dumping, so the others can't be displayed, besides that it will also behave correctly on old kernels.
old kernel:
1.2.3.4 realm 1
nexthop dev dummy0 weight 1
nexthop dev dummy1 weight 1
nexthop dev dummy2 weight 1
nexthop dev dummy3 weight 1
new kernel:
1.2.3.4
nexthop realm 1 dev dummy0 weight 1
nexthop realm 2 dev dummy1 weight 1
nexthop realm 3 dev dummy2 weight 1
nexthop realm 4 dev dummy3 weight 1
route queries on both old and new kernel:
1.2.3.4 dev dummy0 src 10.0.0.1 realm 1
cache mtu 1500 advmss 1460 metric 10 64
1.2.3.4 dev dummy1 src 10.0.0.1 realm 2
cache mtu 1500 advmss 1460 metric 10 64
1.2.3.4 dev dummy2 src 10.0.0.1 realm 3
cache mtu 1500 advmss 1460 metric 10 64
1.2.3.4 dev dummy3 src 10.0.0.1 realm 4
cache mtu 1500 advmss 1460 metric 10 64---
commit dbc39a8d37d658776a8959d2393b1047ea124436
tree be59669a06709aaa3b194f050529fe3986928dc8
parent 8f8a36487119a3cd1afe86a9649704aca088567b
author Patrick McHardy <[email protected]> Tue, 25 Jul 2006 05:55:36 +0200 committer Patrick McHardy <[email protected]> Tue, 25 Jul 2006 05:55:36 +0200
ip/iproute.c | 19 +++++++++++++++++++ 1 files changed, 19 insertions(+), 0 deletions(-)
ip/iproute.c +19 -0
@@ -557,6 +557,18 @@ #endifRTA_DATA (tb[RTA_GATEWAY ]), abuf, sizeof(abuf))); } +if (tb[RTA_FLOW ]) { +__u32 to = *(__u32 *)RTA_DATA (tb[RTA_FLOW ]); +__u32 from = to>>16 ; + to &=0xFFFF ; +fprintf (fp," realm%s " , from ?"s" :"" ); +if (from) { +fprintf (fp,"%s/" , +rtnl_rtrealm_n2a (from, b1,sizeof (b1))); + } +fprintf (fp,"%s" , +rtnl_rtrealm_n2a (to, b1,sizeof (b1))); + } }if (r->rtm_flags&RTM_F_CLONED && r->rtm_type ==RTN_MULTICAST ) {fprintf (fp," %s" ,ll_index_to_name (nh->rtnh_ifindex));
@@ -606,6 +618,13 @@ int parse_one_nh(struct rtattr *rta, str rtnh->rtnh_hops = w -1 ; }else if (strcmp (*argv,"onlink" ) ==0 ) { rtnh->rtnh_flags |=RTNH_F_ONLINK ; + }else if (matches (*argv,"realms" ) ==0 ) { +__u32 realm; +NEXT_ARG (); +if (get_rt_realms (&realm, *argv)) +invarg ("\"realm\" value is invalid\n" , *argv); +rta_addattr32 (rta,4096 ,RTA_FLOW , realm); + rtnh->rtnh_len +=sizeof (struct rtattr ) +4 ; }else break ; }
Quoted 17 lines · Patrick McHardy
[IPROUTE]: Add support for multipath route realms
Routing realms exist per nexthop, but iproute currently only allows to send a single route realm, which is refused by the kernel for multipath routes. Add support for specifying per nexthop realms. Old kernels only return the first realm back to userspace when dumping, so the others can't be displayed, besides that it will also behave correctly on old kernels.
old kernel:
1.2.3.4 realm 1
nexthop dev dummy0 weight 1
nexthop dev dummy1 weight 1
nexthop dev dummy2 weight 1
nexthop dev dummy3 weight 1
Quoted 7 lines
new kernel:
1.2.3.4
nexthop realm 1 dev dummy0 weight 1
nexthop realm 2 dev dummy1 weight 1
nexthop realm 3 dev dummy2 weight 1
nexthop realm 4 dev dummy3 weight 1
This really looks like papering over fundamental brokenness of IP_ROUTE_MULTIPATH_CACHED since you wouldn't otherwise get these entries in the routing cache.
This reminds me that I better revisit the reasons that people gave for actually using IP_ROUTE_MULTIPATH_CACHED the last time we tried to get rid of it.
Cheers,
Signature · 4 lines
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txtQuoted 27 lines · Herbert Xu
Quoted 16 lines · Patrick McHardy
[IPROUTE]: Add support for multipath route realms
Routing realms exist per nexthop, but iproute currently only allows to send a single route realm, which is refused by the kernel for multipath routes. Add support for specifying per nexthop realms. Old kernels only return the first realm back to userspace when dumping, so the others can't be displayed, besides that it will also behave correctly on old kernels.
old kernel:
1.2.3.4 realm 1
nexthop dev dummy0 weight 1
nexthop dev dummy1 weight 1
nexthop dev dummy2 weight 1
nexthop dev dummy3 weight 1Quoted 7 lines
new kernel:
1.2.3.4
nexthop realm 1 dev dummy0 weight 1
nexthop realm 2 dev dummy1 weight 1
nexthop realm 3 dev dummy2 weight 1
nexthop realm 4 dev dummy3 weight 1
Quoted 7 lines
This really looks like papering over fundamental brokenness of
IP_ROUTE_MULTIPATH_CACHEDsince you wouldn't otherwise get these entries in the routing cache.This reminds me that I better revisit the reasons that people gave for actually using
IP_ROUTE_MULTIPATH_CACHEDthe last time we tried to get rid of it.
Actually it has nothing to do with MULTIPATH_CACHED, it didn't even use it in these tests unless I seriously mixed something up. The realm can be used by netfilter to find out which nexthop was chosen and bind the connection to this nexthop manually using CONNMARK and MARK.
Quoted 9 lines · Herbert Xu
Quoted 8 lines
new kernel:
1.2.3.4
nexthop realm 1 dev dummy0 weight 1
nexthop realm 2 dev dummy1 weight 1
nexthop realm 3 dev dummy2 weight 1
nexthop realm 4 dev dummy3 weight 1
Quoted 3 lines
This really looks like papering over fundamental brokenness of
IP_ROUTE_MULTIPATH_CACHEDsince you wouldn't otherwise get these entries in the routing cache.
Nevermind, I misread your changelog. Your patch is obviously not related to IP_ROUTE_MULTIPATH_CACHED :)
Signature · 4 lines
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txtStephen Hemminger
AppliedOn Tue, 25 Jul 2006 05:58:36 +0200
Patrick McHardy <[email protected]> wrote:
applied
Signature · 2 lines
Stephen Hemminger <[email protected]> "And in the Packet there writ down that doome"
Quoted 1 line · Stephen Hemminger
applied
Have you had a chance to look at the time cleanup patches and the increased number of routing rule patch? Please let me know if you want me to resend.