On Wed, Apr 4, 2018 at 12:04 AM, sven falempin <sven.falem...@gmail.com> wrote: > Dear readers, > > For a long time now, using dhclient to renew a lease trigger a > RTM_DELETE, then RTM_ADD, > because it always remove everything before applying the lease (well > the IP) ( without like checking it s a renewal and nothing changed ). > > # route monitor & > # dhclient vio0 > got message of size 96 on Wed Apr 4 03:56:53 2018 > RTM_PROPOSAL: config proposal: len 96, source dhcp table 0, ifidx 1, > pid: 47718, seq -1773381169, errno 0 > flags:<UP,DONE,PROTO3> > fmask: > use: 0 mtu: 0 expire: 0 > locks: inits: > Static Routes: > Domain search: > Domain Name Servers: > vio0: bound to 100.64.1.3 from 100.64.1.2 (fe:e1:bb:d1:af:df) > got message of size 208 on Wed Apr 4 03:56:53 2018 > RTM_DELETE: Delete Route: len 208, priority 3, table 0, ifidx 1, pid: > 88062, seq 0, errno 0 > flags:<UP,HOST,DONE,LLINFO,CLONED,CACHED> > fmask: > use: 4 mtu: 0 expire: -14 > locks: inits: > sockaddrs: <DST,GATEWAY,NETMASK,IFP,IFA> > 100.64.1.2 link#1 255.255.255.255 fe:e1:bb:d1:af:de 100.64.1.3 > got message of size 192 on Wed Apr 4 03:56:53 2018 > RTM_RESOLVE: Route created by cloning: len 192, priority 3, table 0, > ifidx 1, pid: 0, seq 0, errno 0 > flags:<UP,HOST,DONE,LLINFO,CLONED,CACHED> > fmask: > use: 0 mtu: 0 expire: 0 > locks: inits: > sockaddrs: <DST,GATEWAY,IFP,IFA> > 100.64.1.2 fe:e1:ba:d0:19:81 fe:e1:bb:d1:af:de 100.64.1.3 > got message of size 144 on Wed Apr 4 03:56:53 2018 > RTM_ADD: Add Route: len 144, priority 0, table 0, ifidx 1, pid: 88062, > seq 0, errno 17 > flags:<GATEWAY,STATIC> > fmask: > use: 0 mtu: 0 expire: 0 > locks: inits: > sockaddrs: <DST,GATEWAY,NETMASK> > default 100.64.1.2 default > got message of size 192 on Wed Apr 4 03:56:55 2018 > RTM_GET: Report Metrics: len 192, priority 8, table 0, ifidx 1, pid: > 88062, seq 512726977, errno 0 > flags:<UP,GATEWAY,DONE,STATIC> > fmask: > use: 0 mtu: 0 expire: 0 > locks: inits: > sockaddrs: <DST,GATEWAY,NETMASK,IFP,IFA> > default 100.64.1.2 default fe:e1:bb:d1:af:de 100.64.1.3 > > Is there a reason behind this behavior ? is it just to set aside some > complexity ? > > Can't this trigger a (UDP) packet drop ? > > Best.
Oh, it as been fixed too, it only do that on explicit request. Great , thank you -- -- --------------------------------------------------------------------------------------------------------------------- Knowing is not enough; we must apply. Willing is not enough; we must do
