Netlink, route monitoring, RTM_DELROUTE not issued for ppp peer address. Bug or feature?

Netlink, route monitoring, RTM_DELROUTE not issued for ppp peer address. Bug or feature?

[Denys Fedoryshchenko]

Hi

I am trying to implement my own routing daemon, and using 
RTMGRP_IPV4_ROUTE to monitor routes.
I notice, that on PPPoE, when interface disappearing, RTM_DELROUTE will 
be sent to listener only for local address, but nothing about peer 
address attached to this interface.

CBSS_PPPoE ~ # ifconfig ppp0
ppp0      Link encap:Point-to-Point Protocol
           inet addr:172.16.146.1  P-t-P:172.16.146.10  
Mask:255.255.255.255
           UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1200  Metric:1
           RX packets:40439 errors:0 dropped:0 overruns:0 frame:0
           TX packets:63211 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:3
           RX bytes:3584507 (3.4 MiB)  TX bytes:47180929 (44.9 MiB)

CBSS_PPPoE ~ # pppkill tek234@visp.net.lb  (this is killing pppd 
process for ppp0 interface)

ip monitor route will show only RTM_DELROUTE for RTN_LOCAL, but nothing 
about RTN_UNICAST for 172.16.146.10.
"Deleted local 172.16.146.1 dev ppp0  table local  proto kernel  scope 
host  src 172.16.146.1"
My program also receive same.

Is it a bug, that no RTM_DELROUTE issued for peer ip address? Or should 
i monitor also RTMGRP_IPV4_IFADDR for link disappearance?

Thanks for help!

SV: Netlink, route monitoring, RTM_DELROUTE not issued for ppp peer address. Bug or feature?

[Stian Skjelstad]

I've seen the same issue, and got no response so far to that very same question. Have you tested this on older kernels? I have worked around this issue by testing my local copy of routing entries that use 'via'. If they are not routable when after the RTM_DELROUTE event, I autoremove them from my local copy.

Stian Skjelstad

-----Opprinnelig melding-----
Fra: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] På vegne av Denys Fedoryshchenko
Sendt: 13. april 2012 14:11
Til: netdev@vger.kernel.org
Emne: Netlink, route monitoring, RTM_DELROUTE not issued for ppp peer address. Bug or feature?

Hi

I am trying to implement my own routing daemon, and using RTMGRP_IPV4_ROUTE to monitor routes.
I notice, that on PPPoE, when interface disappearing, RTM_DELROUTE will be sent to listener only for local address, but nothing about peer address attached to this interface.

CBSS_PPPoE ~ # ifconfig ppp0
ppp0      Link encap:Point-to-Point Protocol
           inet addr:172.16.146.1  P-t-P:172.16.146.10
Mask:255.255.255.255
           UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1200  Metric:1
           RX packets:40439 errors:0 dropped:0 overruns:0 frame:0
           TX packets:63211 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:3
           RX bytes:3584507 (3.4 MiB)  TX bytes:47180929 (44.9 MiB)

CBSS_PPPoE ~ # pppkill tek234@visp.net.lb  (this is killing pppd process for ppp0 interface)

ip monitor route will show only RTM_DELROUTE for RTN_LOCAL, but nothing about RTN_UNICAST for 172.16.146.10.
"Deleted local 172.16.146.1 dev ppp0  table local  proto kernel  scope host  src 172.16.146.1"
My program also receive same.

Is it a bug, that no RTM_DELROUTE issued for peer ip address? Or should i monitor also RTMGRP_IPV4_IFADDR for link disappearance?

Thanks for help!
--
To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: SV: Netlink, route monitoring, RTM_DELROUTE not issued for ppp peer address. Bug or feature?

[Denys Fedoryshchenko]

After digging the code, i came to conclusion:
fib_del_ifaddr, will check if deleted address are exist as prefsrc or 
interface are shut down, they will do fi->fib_flags |= RTNH_F_DEAD;
Then fib_flush -> fib_table_flush -> trie_flush_leaf -> trie_flush_list 
will delete such routes.
But trie_flush_list won't notify over netlink that route are deleted.

So the only solution is to fetch first, then keep full routing table in 
userspace also, and keep tracking if local addresses deleted, and do the 
same in userspace and check for prefsrc...

Maybe it should be fixed? E.g. netlink message sent when any route are 
deleted, even over the flush

On 2012-04-13 16:59, Stian Skjelstad wrote:
> I've seen the same issue, and got no response so far to that very
> same question. Have you tested this on older kernels? I have worked
> around this issue by testing my local copy of routing entries that 
> use
> 'via'. If they are not routable when after the RTM_DELROUTE event, I
> autoremove them from my local copy.
>
> Stian Skjelstad
>
> -----Opprinnelig melding-----
> Fra: netdev-owner@vger.kernel.org
> [mailto:netdev-owner@vger.kernel.org] På vegne av Denys 
> Fedoryshchenko
> Sendt: 13. april 2012 14:11
> Til: netdev@vger.kernel.org
> Emne: Netlink, route monitoring, RTM_DELROUTE not issued for ppp peer
> address. Bug or feature?
>
> Hi
>
> I am trying to implement my own routing daemon, and using
> RTMGRP_IPV4_ROUTE to monitor routes.
> I notice, that on PPPoE, when interface disappearing, RTM_DELROUTE
> will be sent to listener only for local address, but nothing about
> peer address attached to this interface.
>
> CBSS_PPPoE ~ # ifconfig ppp0
> ppp0      Link encap:Point-to-Point Protocol
>            inet addr:172.16.146.1  P-t-P:172.16.146.10
> Mask:255.255.255.255
>            UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1200  Metric:1
>            RX packets:40439 errors:0 dropped:0 overruns:0 frame:0
>            TX packets:63211 errors:0 dropped:0 overruns:0 carrier:0
>            collisions:0 txqueuelen:3
>            RX bytes:3584507 (3.4 MiB)  TX bytes:47180929 (44.9 MiB)
>
> CBSS_PPPoE ~ # pppkill tek234@visp.net.lb  (this is killing pppd
> process for ppp0 interface)
>
> ip monitor route will show only RTM_DELROUTE for RTN_LOCAL, but
> nothing about RTN_UNICAST for 172.16.146.10.
> "Deleted local 172.16.146.1 dev ppp0  table local  proto kernel
> scope host  src 172.16.146.1"
> My program also receive same.
>
> Is it a bug, that no RTM_DELROUTE issued for peer ip address? Or
> should i monitor also RTMGRP_IPV4_IFADDR for link disappearance?
>
> Thanks for help!
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org More majordomo 
> info
> at  http://vger.kernel.org/majordomo-info.html
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Netlink, route monitoring, RTM_DELROUTE not issued for ppp peer address. Bug or feature?

[Stephen Hemminger]

On Mon, 16 Apr 2012 13:37:14 +0300
Denys Fedoryshchenko <denys@visp.net.lb> wrote:

> After digging the code, i came to conclusion:
> fib_del_ifaddr, will check if deleted address are exist as prefsrc or 
> interface are shut down, they will do fi->fib_flags |= RTNH_F_DEAD;
> Then fib_flush -> fib_table_flush -> trie_flush_leaf -> trie_flush_list 
> will delete such routes.
> But trie_flush_list won't notify over netlink that route are deleted.
> 
> So the only solution is to fetch first, then keep full routing table in 
> userspace also, and keep tracking if local addresses deleted, and do the 
> same in userspace and check for prefsrc...
> 
> Maybe it should be fixed? E.g. netlink message sent when any route are 
> deleted, even over the flush
> 
> On 2012-04-13 16:59, Stian Skjelstad wrote:
> > I've seen the same issue, and got no response so far to that very
> > same question. Have you tested this on older kernels? I have worked
> > around this issue by testing my local copy of routing entries that 
> > use
> > 'via'. If they are not routable when after the RTM_DELROUTE event, I
> > autoremove them from my local copy.
> >
> > Stian Skjelstad
> >


Looking at Quagga, it knows that deleting interface address
removes connected routes and silently cleans up.

You have to be really careful here making any changes to not break
applications that expect existing behavior.

Re: Netlink, route monitoring, RTM_DELROUTE not issued for ppp peer address. Bug or feature?

[Denys Fedoryshchenko]

On 2012-04-16 18:19, Stephen Hemminger wrote:
> On Mon, 16 Apr 2012 13:37:14 +0300
> Denys Fedoryshchenko <denys@visp.net.lb> wrote:
>
>> After digging the code, i came to conclusion:
>> fib_del_ifaddr, will check if deleted address are exist as prefsrc 
>> or
>> interface are shut down, they will do fi->fib_flags |= RTNH_F_DEAD;
>> Then fib_flush -> fib_table_flush -> trie_flush_leaf -> 
>> trie_flush_list
>> will delete such routes.
>> But trie_flush_list won't notify over netlink that route are 
>> deleted.
>>
>> So the only solution is to fetch first, then keep full routing table 
>> in
>> userspace also, and keep tracking if local addresses deleted, and do 
>> the
>> same in userspace and check for prefsrc...
>>
>> Maybe it should be fixed? E.g. netlink message sent when any route 
>> are
>> deleted, even over the flush
>>
>> On 2012-04-13 16:59, Stian Skjelstad wrote:
>> > I've seen the same issue, and got no response so far to that very
>> > same question. Have you tested this on older kernels? I have 
>> worked
>> > around this issue by testing my local copy of routing entries that
>> > use
>> > 'via'. If they are not routable when after the RTM_DELROUTE event, 
>> I
>> > autoremove them from my local copy.
>> >
>> > Stian Skjelstad
>> >
>
>
> Looking at Quagga, it knows that deleting interface address
> removes connected routes and silently cleans up.
>
> You have to be really careful here making any changes to not break
> applications that expect existing behavior.
It looks like "correct" behavior should not harm existing programs that 
much (just there will be netlink message to delete route that are 
already deleted by program, e.g. quagga), but looking to code, 
implementing this feature will make significant overhead and in some 
cases it can be harmful.
For example if full view BGP interface dropped, it is hundreds of 
thousands netlink messages. So seems better i will listen to 
address/link changes also and keep routing table in memory.
So better seems to keep as is.

Re: Netlink, route monitoring, RTM_DELROUTE not issued for ppp peer address. Bug or feature?

[Stian Skjelstad]

> It looks like "correct" behavior should not harm existing programs that
> much (just there will be netlink message to delete route that are
> already deleted by program, e.g. quagga), but looking to code,
> implementing this feature will make significant overhead and in some
> cases it can be harmful.
> For example if full view BGP interface dropped, it is hundreds of
> thousands netlink messages. So seems better i will listen to
> address/link changes also and keep routing table in memory.
> So better seems to keep as is.

If I understand correct, the "missing" RTM_DELROUTE messages actually
comes from something similar to "ip route flush dev eth0".

If the amount of traffic is a worry, couldn't there be a RTM_FLUSHROUTE or
a special RTM_DELROUTE message that tells that all routes for a given
device is removed?

Stian Skjelstad

Re: Netlink, route monitoring, RTM_DELROUTE not issued for ppp peer address. Bug or feature?

[Stephen Hemminger]

On Mon, 16 Apr 2012 22:21:46 +0200
"Stian Skjelstad" <stian@nixia.no> wrote:

> > It looks like "correct" behavior should not harm existing programs that
> > much (just there will be netlink message to delete route that are
> > already deleted by program, e.g. quagga), but looking to code,
> > implementing this feature will make significant overhead and in some
> > cases it can be harmful.
> > For example if full view BGP interface dropped, it is hundreds of
> > thousands netlink messages. So seems better i will listen to
> > address/link changes also and keep routing table in memory.
> > So better seems to keep as is.
> 
> If I understand correct, the "missing" RTM_DELROUTE messages actually
> comes from something similar to "ip route flush dev eth0".
> 
> If the amount of traffic is a worry, couldn't there be a RTM_FLUSHROUTE or
> a special RTM_DELROUTE message that tells that all routes for a given
> device is removed?
> 

No. new message type would confuse all the things that listen now.

Re: Netlink, route monitoring, RTM_DELROUTE not issued for ppp peer address. Bug or feature?

[David Lamparter]

[-- Attachment #1: Type: text/plain, Size: 1419 bytes --]

On Mon, Apr 16, 2012 at 10:21:46PM +0200, Stian Skjelstad wrote:
> > It looks like "correct" behavior should not harm existing programs that
> > much (just there will be netlink message to delete route that are
> > already deleted by program, e.g. quagga), but looking to code,
> > implementing this feature will make significant overhead and in some
> > cases it can be harmful.
> > For example if full view BGP interface dropped, it is hundreds of
> > thousands netlink messages. So seems better i will listen to
> > address/link changes also and keep routing table in memory.
> > So better seems to keep as is.

Yes, this concern is quite real, I'd very much like to avoid processing
400000 DELROUTE messages that add exactly 0 additional meaning since it
can be inferred from the interface going down.

> If I understand correct, the "missing" RTM_DELROUTE messages actually
> comes from something similar to "ip route flush dev eth0".
> 
> If the amount of traffic is a worry, couldn't there be a RTM_FLUSHROUTE or
> a special RTM_DELROUTE message that tells that all routes for a given
> device is removed?

The interface-down message has exactly these semantics. I don't know
if/where this is documented, but adding a new message seems superfluous
to me, especially at this point where compatibility is a concern.
(The ip route flush command deletes routes individually btw.)

-David

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 230 bytes --]

Re: SV: Netlink, route monitoring, RTM_DELROUTE not issued for ppp peer address. Bug or feature?

[David Miller]

From: Denys Fedoryshchenko <denys@visp.net.lb>
Date: Mon, 16 Apr 2012 13:37:14 +0300

> So the only solution is to fetch first, then keep full routing table
> in userspace also, and keep tracking if local addresses deleted, and
> do the same in userspace and check for prefsrc...

You don't need to keep full routing table in userspace, don't be
silly.

You only need to watch for the device down event, and purge in
userspace based upon that key.

Re: SV: Netlink, route monitoring, RTM_DELROUTE not issued for ppp peer address. Bug or feature?

[Denys Fedoryshchenko]

On 2012-04-16 21:40, David Miller wrote:
> From: Denys Fedoryshchenko <denys@visp.net.lb>
> Date: Mon, 16 Apr 2012 13:37:14 +0300
>
>> So the only solution is to fetch first, then keep full routing table
>> in userspace also, and keep tracking if local addresses deleted, and
>> do the same in userspace and check for prefsrc...
>
> You don't need to keep full routing table in userspace, don't be
> silly.
>
> You only need to watch for the device down event, and purge in
> userspace based upon that key.
In my specific case i should. Userspace should just send information 
that some ip came or gone on specific access server, to central node (i 
am not reinventing dynamic routing protocols, there is another reasons 
for that). Central node don't know anything about interfaces. Access 
server i was expecting to not keep anything, and just relay netlink 
routing messages, route to specific ip are appearing and disappearing. 
Because it is not possible i will just keep as you mentioned table, with 
ip+device+prefsrc, and listen to other than routing netlink events.

As i mention before, it is not big deal to do that, and i understood 
that it is not a "netlink/kernel bug", but a reasonable design choice.
I posted it, just to share my view, so in future people who have 
similar question, as Stian Skjelstad had, will have more information.

Re: Netlink, route monitoring, RTM_DELROUTE not issued for ppp peer address. Bug or feature?

[Stephen Hemminger]

On Mon, 16 Apr 2012 14:40:05 -0400 (EDT)
David Miller <davem@davemloft.net> wrote:

> From: Denys Fedoryshchenko <denys@visp.net.lb>
> Date: Mon, 16 Apr 2012 13:37:14 +0300
> 
> > So the only solution is to fetch first, then keep full routing table
> > in userspace also, and keep tracking if local addresses deleted, and
> > do the same in userspace and check for prefsrc...
> 
> You don't need to keep full routing table in userspace, don't be
> silly.

Quagga does (in multiple daemons) and uses this to manage
route distribution and recursive routes.

> You only need to watch for the device down event, and purge in
> userspace based upon that key.