Swapping routes without deletion

Sun May 21 16:13:09 CEST 2023

Good job 👍

Dne ne 21. 5. 2023 12:28 uživatel Pim van Pelt via Bird-users <
bird-users at network.cz> napsal:

> Hoi,
>
> To close out my monologue -- I sent https://gerrit.fd.io/r/c/vpp/+/38854
> to make VPP's Linux Controlplane plugin aware of NLM_F_REPLACE messages.
> Rolled that out at AS8283 this morning, and our duplicate FIB entry issue
> is gone. Nothing to see here, moving along :)
>
> groet,
> Pim
>
> On Sat, May 20, 2023 at 11:50 PM Pim van Pelt <pim at ipng.nl> wrote:
>
>> Hoi,
>>
>> I think I've found the answer to my question by taking a look at git
>> history in netlink handling.
>>
>> This commit:
>>
>> commit 8235c4747dcc92de2ea991f78cdf9c6b8fa7f522
>>
>> Author: Ondrej Zajicek (work) <santiago at crfreenet.org>
>>
>> Date:   Mon Jul 15 16:23:18 2019 +0200
>>
>>
>>     Netlink: Use route replace for IPv4
>>
>>
>> Started using NL_OP_REPLACE for IPv4, but it kept it disabled for IPv6,
>> and then this commit:
>>
>>
>> commit 722daa950046a7ad307fd7aca8e0506f30b3d000
>>
>> Author: Ondrej Zajicek <santiago at crfreenet.org>
>>
>> Date:   Mon Jul 25 00:11:40 2022 +0200
>>
>>
>>     Netlink: Simplify handling of IPv6 ECMP routes
>>
>>
>> started using for IPv6 as well, where this commit:
>>
>>
>> commit ddb1bdf2819ce69248d5a51e71d803f13548b217
>>
>> Author: Ondrej Zajicek <santiago at crfreenet.org>
>>
>> Date:   Tue Jul 26 18:45:20 2022 +0200
>>
>>
>>     Netlink: Restrict route replace for IPv6
>>
>>
>> added a nice guard in nl_allow_replace() -- this explains the replace
>> semantics (which 'ip monitor route' does not show), and answers my
>> question. For my application, I'll have to take a good look at consuming
>> messages with flag NLM_F_CREATE|NLM_F_REPLACE set; and otherwise perhaps
>> add the ability to Bird2/Bird3 to holdback and
>> issue NL_OP_DELETE + NL_OP_ADD.
>>
>> For the curious, the application is Vector Packet Processing [ref
>> <https://ipng.ch/s/articles/2021/09/02/vpp-5.html>] which consumes
>> Netlink messages from the Linux kernel, and uses them to program a
>> userspace dataplane, see [Linux Control Plane
>> <https://s3-docs.fd.io/vpp/23.06/developer/plugins/lcp.html>] for
>> details. Until now, this system consumes RTM_NEWROUTE and RTM_DELROUTE but
>> is not yet capable of consuming this replacing logic. I'll take a look at
>> adding that.
>>
>> groet,
>> Pim
>>
>>
>>
>> On Sat, May 20, 2023 at 11:10 PM Pim van Pelt <pim at ipng.nl> wrote:
>>
>>> Hoi,
>>>
>>> As a quick followup why I'm asking about versions -- on a Bird2.0.7, I
>>> do see the delete-before-insert:
>>>
>>> root at chgtg0:~# ip -6 monitor route | grep 2001:678:d78::6
>>>
>>>
>>> # Raise OSPFv3 cost to prefer tf-0-0
>>>
>>> *Deleted* 2001:678:d78::6 via fe80::21b:21ff:febd:c718 dev
>>> xe0-3.3102.20 proto bird metric 32 pref medium
>>>
>>> 2001:678:d78::6 via fe80::6eb3:11ff:fe20:e0c4 dev tf0-0 proto bird
>>> metric 32 pref medium
>>>
>>>
>>> # Lower OSPFv3 cost to prefer xe0-3.3102.20 again
>>>
>>> *Deleted* 2001:678:d78::6 via fe80::6eb3:11ff:fe20:e0c4 dev tf0-0 proto
>>> bird metric 32 pref medium
>>>
>>> 2001:678:d78::6 via fe80::21b:21ff:febd:c718 dev xe0-3.3102.20 proto
>>> bird metric 32 pref medium
>>>
>>> groet,
>>> Pim
>>>
>>> On Sat, May 20, 2023 at 10:51 PM Pim van Pelt <pim at ipng.nl> wrote:
>>>
>>>> Hoi folks,
>>>>
>>>> At Coloclue AS8283, we upgraded from Bird1.6.8 to Bird2.0.12 this week.
>>>> We use two separate processes, one for IPv4 and one for IPv6 - and 2.0.7 in
>>>> Debian is missing the ability to select 'accept ipv4' and 'accept ipv6' in
>>>> BFD, so we installed backports and version 2.0.12).
>>>>
>>>> I am wondering if Bird2 later than 2.0.7 perhaps has an optimization
>>>> when swapping routes? I would expect a swap to be "delete + add" but I am
>>>> seeing only "add with new nexthop" appear in Netlink.
>>>>
>>>> Considering the following topology with link names and OSPFv3 costs
>>>> associated:
>>>>
>>>>   dcg-1  bond0.130 ---- bond0.130 eun-2
>>>>
>>>>    |               2000             |
>>>>
>>>> enp1s0f3                         enp1s0f2
>>>>
>>>>    |                                |
>>>>
>>>>    | 10                          10 |
>>>>
>>>>    |                                |
>>>>
>>>> enp1s0f3                         enp1s0f3
>>>>
>>>>    |               1000             |
>>>>
>>>>   dcg-2  eno2.3469 ---- eno2.3469 eun-3
>>>>
>>>> If I restart the OSPFv3 protocol, I see that the topology settles in
>>>> the expected way.  What I observed with bird 2.0.12 is that there is a
>>>> deletion of the currently selected route followed by one addition, when the
>>>> shortest path reveales (dcg1 - dcg2 - eun3 - eun2, ospf_metric1 is 1020,
>>>> this is fine):
>>>>
>>>> root at dcg-1:~# birdc -s /run/bird/bird6.ctl restart ospf1
>>>>
>>>> root at dcg-1:~# ip -6 monitor route | grep 2a02:898:0:300::3
>>>>
>>>> Deleted 2a02:898:0:300::3 via fe80::669d:99ff:feb1:31af dev bond0.130
>>>> proto bird metric 32 pref medium
>>>>
>>>> 2a02:898:0:300::3 via fe80::669d:99ff:feb1:3910 dev enp1s0f3 proto bird
>>>> metric 32 pref medium
>>>>
>>>> Now I lower the cost of the dcg-1 -- eun-2 link from 2000 to 100, so
>>>> that it becomes preferred (cost ospf_metric is 120):
>>>>
>>>> root at dcg-1:~# birdc -s /run/bird/bird6.ctl reconfigure ospf1
>>>>
>>>> root at dcg-1:~# ip -6 monitor route | grep 2a02:898:0:300::3
>>>>
>>>> *[[ HERE ]]*
>>>>
>>>> 2a02:898:0:300::3 via fe80::669d:99ff:feb1:31af dev bond0.130 proto
>>>> bird metric 32 pref medium
>>>>
>>>> I would expect this new addition of the installed route on bond0.130 to
>>>> be *preceded by a deletion* of the previous route from enp1s0f3, but
>>>> this is not the case (marked in red with [[ HERE ]]).
>>>>
>>>> To anyone's knowledge: *Has this behavior changed between 2.0.7 and
>>>> 2.0.12 ?*
>>>>
>>>> groet,
>>>> Pim
>>>> --
>>>> Pim van Pelt <pim at ipng.nl>
>>>> PBVP1-RIPE - http://www.ipng.nl/
>>>>
>>>
>>>
>>> --
>>> Pim van Pelt <pim at ipng.nl>
>>> PBVP1-RIPE - http://www.ipng.nl/
>>>
>>
>>
>> --
>> Pim van Pelt <pim at ipng.nl>
>> PBVP1-RIPE - http://www.ipng.nl/
>>
>
>
> --
> Pim van Pelt <pim at ipng.nl>
> PBVP1-RIPE - http://www.ipng.nl/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20230521/fce86991/attachment.htm>