> From: "Rodney W. Grimes" <freebsd-...@gndrsh.dnsmgr.net>
> Subject: Re: ip(8) in base
> Date: Sun, 16 Aug 2020 09:38:47 -0700 (PDT)
> > > From: "Alexander V. Chernikov" <melif...@ipfw.ru>
> > > To: net <n...@freebsd.org>, freebsd-hackers <freebsd-hack...@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 nexthops,
> > > 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
> > > drastically change the tool by introducing [route nhop add], [route
> > > nhgroup add] 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 specific.
> 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 seem
> > 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 ability 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 groups
> > > 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 Linux
> > > 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] [proxyfib
> > > 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 add?
> Could that not be handled as either a route flag ala
> -iface/-static/-reject/-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 expression
> of the "next hop" as far as the kernel goes, or are we now doing lsdb type
> routing in the kernel?
> >
> > > cmd -46m nhgroup create nhops 1,2,3,4,5,6 [fib X]
> > > cmd -46 nhgroup create nhops 1=100,2=100,3=200,4=100 [proxyfib 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 rgri...@freebsd.org
> _______________________________________________
> freebsd-net@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
_______________________________________________
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
