Date: Sun, 16 Aug 2020 13:21:19 -0500 From: Mike Karels <mike@karels.net> To: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net> Cc: "Alexander V. Chernikov" <melifaro@ipfw.ru>, net <net@freebsd.org> Subject: Re: ip(8) in base Message-ID: <202008161821.07GILJH3055045@mail.karels.net> In-Reply-To: Your message of Sun, 16 Aug 2020 09:38:47 -0700. <202008161638.07GGclX4056884@gndrsh.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> From: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net> > Subject: Re: ip(8) in base > Date: Sun, 16 Aug 2020 09:38:47 -0700 (PDT) > > > From: "Alexander V. Chernikov" <melifaro@ipfw.ru> > > > To: net <net@freebsd.org>, freebsd-hackers <freebsd-hackers@freebsd.= org> > > > Subject: ip(8) in base > > > Date: Sun, 16 Aug 2020 10:11:11 +0100 > > = > > > I want to introduce ip(8) or something similar in base. > > > Basically, I need some userland tool to explicitly operates on nexth= ops, nexthop groups and fib lookup algorithms. > > = > > > The existing tools are not well suited for the job: route(8) may be = a candidate, but (a) it would either add another bunch of options or dras= tically change the tool by introducing [route nhop add], [route nhgroup ad= d] and (b) listing is traditionally done by netstat(8). > > = > > I agree with the others who said not to use ip(8) if the tool is not > > compatible with the Linux ip. Also, routing is (at least in theory) > > independent of address family, and that makes the name "ip" too specif= ic. > I strongly agree with this. > > However, I think that route and netstat are sufficiently extensible to > > add additional facilities, as they have been so far. One suggestion, > > though, would be to preserve the general strategy of using "route verb= ...", > > e.g. "route add nhop ..." rather than "route nhop add ...". These see= m > > sufficiently similar to existing functionality to share a tool. > Again, I agree with the above statement by Mike. > The proposed commands are all in support of "route" features, > and in BSD it is the route command that is used to maniplate > these, please do not deviate from that. I have seen no strong > reason given that route(8) and netstat(1) can not be extended > to add the desired functionality. > > Similarly, if possible I would prefer to see --libxo json rather than = -j. > I have no skin in this one, other than to state that iirc the > route(8) command is currently without any long options so > adding this --libxo would require adding long option support, > which is probably not justifiable for 1 option. I think the reporting ("list") should be in netstat rather than route, with the possible exception of enhancements to "route get". Of course, netstat already uses libxo. > > > I feel like there is a need of some cli tool that provides the abili= ty to easily extend it by having separate namespaces for each sub-command = (hello, ifconfig). > > = > > > Naming is hard. I can, for example, use "rt" as a name to address my= use cases. > > > However, given the kernel interfaces for managing nexthops/nexhop gr= oups are the same as with routes/arp/ndp, why not spending some additional= time and support operating on routes and neighbors and name it ip? > > = > > > Though, that arises multiple questions. > > > Are we comfortable with ip(8) as a name in general? > > > If we are, what's our take on having the compatible interface with L= inux ip(8)? = > > = > > > Any comments/feedback is welcome :-) > > = > > = > > > Appendix = > > > List of commands I need implemented > > = > > > cmd [-46m] nhop create [gw XX] [iface YYY] [mtu YYY] [reject] [proxy= fib Y] [fib X][ipv4] [ipv6] > > > cmd [-46m] nhop delete nhop_id > > > cmd -46m nhop list = > > > cmd -j nhop list # json = > What is special about these nhop routes that this is not just a route ad= d? > Could that not be handled as either a route flag ala -iface/-static/-rej= ect/-blackhole > or via a route modifier ala -osi/-xns/-inet/-inet6? > I am actually a bit confused in that all routes are really just an expre= ssion > of the "next hop" as far as the kernel goes, or are we now doing lsdb ty= pe > routing in the kernel? > > = > > > cmd -46m nhgroup create nhops 1,2,3,4,5,6 [fib X] > > > cmd -46 nhgroup create nhops 1=3D100,2=3D100,3=3D200,4=3D100 [proxyf= ib Y][fib X] > > > cmd -46 nhroup list > ^ nhgroup? > > > cmd -46 nhgroup delete nhgroup_id > > = > > > cmd -46 fib algo list > > > cmd -46 fib algo set algo dpdk_lpm6 fib 0 > > > cmd -46 fib algo set algo auto fib 0 > > = > > = > > > /Alexander > -- = > Rod Grimes rgrimes@freeb= sd.org > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202008161821.07GILJH3055045>