Hi, It looks like someone needs to abstract out the address manager code a little - adding/removing/querying routing table information is an OS specific thing and should be moved into a module.
Then yes, you could use the protocol flags mentioned to do it on freebsd, complete with whatever other OS specific stuff has to happen. -a On 24 August 2014 07:58, jmoore <jmo...@devalias.io> wrote: > ---- On Sat, 23 Aug 2014 13:33:04 -0400 Nikolay Denev > <nik...@cytexbg.com> wrote ---- > > On Sat, Aug 23, 2014 at 8:49 AM, Adrian Chadd <adr...@freebsd.org> > wrote: > > Ok, so how does the whole protocol thing implement priority? > > > > > > -a > > Ah, sorry, reading again I don't think it does that. For some reason I > was under the impression it does. > So, it looks like it's just a 8 bit tag applied to each route, not > involved in the actual routing, but allows you > to filter when displaying etc. > From linux ip-route(8) man page : > > protocol RTPROTO > the routing protocol identifier of this route. RTPROTO may be a > number or a string from the file /etc/iproute2/rt_protos. If > the routing protocol ID is not given, ip assumes protocol boot > (i.e. it assumes the route was added by someone who doesn't > understand what they are doing). Several protocol values have a > fixed interpretation. Namely: > > redirect - the route was installed due to an ICMP > redirect. > > kernel - the route was installed by the kernel during > autoconfiguration. > > boot - the route was installed during the bootup > sequence. If a routing daemon starts, it will purge all > of them. > > static - the route was installed by the administrator to > override dynamic routing. Routing daemon will respect > them and, probably, even advertise them to its peers. > > ra - the route was installed by Router Discovery > protocol. > > The rest of the values are not reserved and the administrator is > free to assign (or not to assign) protocol tags. > > > > --Nikolay > > > The context for this questions is updating this script[1] to allow a > (currently) unsupported FreeBSD instance running on Google Compute Engine to > be able to use their load balancers. In this case, the proto is used as a > magic number, as necessary internal routes are programmatically determined > and then compared to current routes, adding/removing as needed. > > [1] > https://github.com/GoogleCloudPlatform/compute-image-packages/blob/master/google-daemon/usr/share/google/google_daemon/address_manager.py > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"