BIRD 2.0.{7,10} MED not actually send for learned routes if export table on is set
Greetings, I noticed during setting up a peering that the MED is not actually send to my peer, although bird shows it in the export. We confirmed this via tcpdump on both ends. After debugging a bit, I noticed that this only affects “learned” routes but routes from the static protocol worked just fine. After disabling the “export table” feature, the MED was send out just fine. Is this behaviour expected? This behaviour is reproducible in BIRD 2.0.7 and 2.0.10 with the following scenario (Configs to test are attached): R0 is connected to R1 and R2 R0, R1 and R2 send each one route R0 sets the MED to 300 R1 sets the MED to 100 R2 sets the MED to 200 Setting “export table on;” yields the following results: # Bird shows the MED in the export R0 $ ./birdc s r all export R1 BIRD 2.0.10 ready. Table master4: 198.18.0.0/24 unicast [static1 02:05:56.604] * (200) Type: static univ BGP.med: 300 198.18.2.0/24 unicast [R2 02:11:51.132 from 198.19.0.2] * (100) [AS4242420002i] Type: BGP univ BGP.origin: IGP BGP.as_path: 4242420002 BGP.next_hop: 198.19.0.2 BGP.med: 300 BGP.local_pref: 100 R0 $ ./birdc s r all export R2 BIRD 2.0.10 ready. Table master4: 198.18.0.0/24 unicast [static1 02:05:56.604] * (200) Type: static univ BGP.med: 300 198.18.1.0/24 unicast [R1 02:11:51.133 from 198.19.0.1] * (100) [AS4242420001i] Type: BGP univ BGP.origin: IGP BGP.as_path: 4242420001 BGP.next_hop: 198.19.0.1 BGP.med: 300 BGP.local_pref: 100 R0 # But on R1, R2 it does not appear for learned routes: R1 $ ./birdc s r all protocol R0 BIRD 2.0.10 ready. Table master4: 198.18.0.0/24 unicast [R0 02:11:51.133 from 198.19.0.0] * (100) [AS4242420000i] Type: BGP univ BGP.origin: IGP BGP.as_path: 4242420000 BGP.next_hop: 198.19.0.0 BGP.med: 300 BGP.local_pref: 100 198.18.2.0/24 unicast [R0 02:11:51.133 from 198.19.0.0] * (100) [AS4242420002i] Type: BGP univ BGP.origin: IGP BGP.as_path: 4242420000 4242420002 BGP.next_hop: 198.19.0.0 BGP.local_pref: 100 R1 $ R2 $ ./birdc s r all protocol R0 BIRD 2.0.10 ready. Table master4: 198.18.0.0/24 unicast [R0 02:11:51.132 from 198.19.0.0] * (100) [AS4242420000i] Type: BGP univ BGP.origin: IGP BGP.as_path: 4242420000 BGP.next_hop: 198.19.0.0 BGP.med: 300 BGP.local_pref: 100 198.18.1.0/24 unicast [R0 02:11:51.133 from 198.19.0.0] * (100) [AS4242420001i] Type: BGP univ BGP.origin: IGP BGP.as_path: 4242420000 4242420001 BGP.next_hop: 198.19.0.0 BGP.local_pref: 100 R2 $ Setting “export table off;” yield the expected result: R1 $ ./birdc s r all protocol R0 BIRD 2.0.10 ready. Table master4: 198.18.0.0/24 unicast [R0 03:15:47.147 from 198.19.0.0] * (100) [AS4242420000i] Type: BGP univ BGP.origin: IGP BGP.as_path: 4242420000 BGP.next_hop: 198.19.0.0 BGP.med: 300 BGP.local_pref: 100 198.18.2.0/24 unicast [R0 03:15:50.635 from 198.19.0.0] * (100) [AS4242420002i] Type: BGP univ BGP.origin: IGP BGP.as_path: 4242420000 4242420002 BGP.next_hop: 198.19.0.0 BGP.med: 300 BGP.local_pref: 100 R1 $ R2 $ ./birdc s r all protocol R0 BIRD 2.0.10 ready. Table master4: 198.18.0.0/24 unicast [R0 03:15:50.635 from 198.19.0.0] * (100) [AS4242420000i] Type: BGP univ BGP.origin: IGP BGP.as_path: 4242420000 BGP.next_hop: 198.19.0.0 BGP.med: 300 BGP.local_pref: 100 198.18.1.0/24 unicast [R0 03:15:50.635 from 198.19.0.0] * (100) [AS4242420001i] Type: BGP univ BGP.origin: IGP BGP.as_path: 4242420000 4242420001 BGP.next_hop: 198.19.0.0 BGP.med: 300 BGP.local_pref: 100 R2 $
Addendum: Using iBGP with export tables and setting the MED works. On Sun, Oct 16, 2022 at 11:17:23AM +0200, Inrin via Bird-users wrote:
Greetings,
I noticed during setting up a peering that the MED is not actually send to my peer, although bird shows it in the export. We confirmed this via tcpdump on both ends.
After debugging a bit, I noticed that this only affects “learned” routes but routes from the static protocol worked just fine.
After disabling the “export table” feature, the MED was send out just fine.
Is this behaviour expected?
This behaviour is reproducible in BIRD 2.0.7 and 2.0.10 with the following scenario (Configs to test are attached):
R0 is connected to R1 and R2 R0, R1 and R2 send each one route R0 sets the MED to 300 R1 sets the MED to 100 R2 sets the MED to 200
Setting “export table on;” yields the following results:
# Bird shows the MED in the export R0 $ ./birdc s r all export R1 BIRD 2.0.10 ready. Table master4: 198.18.0.0/24 unicast [static1 02:05:56.604] * (200) Type: static univ BGP.med: 300 198.18.2.0/24 unicast [R2 02:11:51.132 from 198.19.0.2] * (100) [AS4242420002i] Type: BGP univ BGP.origin: IGP BGP.as_path: 4242420002 BGP.next_hop: 198.19.0.2 BGP.med: 300 BGP.local_pref: 100 R0 $ ./birdc s r all export R2 BIRD 2.0.10 ready. Table master4: 198.18.0.0/24 unicast [static1 02:05:56.604] * (200) Type: static univ BGP.med: 300 198.18.1.0/24 unicast [R1 02:11:51.133 from 198.19.0.1] * (100) [AS4242420001i] Type: BGP univ BGP.origin: IGP BGP.as_path: 4242420001 BGP.next_hop: 198.19.0.1 BGP.med: 300 BGP.local_pref: 100 R0 #
But on R1, R2 it does not appear for learned routes: R1 $ ./birdc s r all protocol R0 BIRD 2.0.10 ready. Table master4: 198.18.0.0/24 unicast [R0 02:11:51.133 from 198.19.0.0] * (100) [AS4242420000i] Type: BGP univ BGP.origin: IGP BGP.as_path: 4242420000 BGP.next_hop: 198.19.0.0 BGP.med: 300 BGP.local_pref: 100 198.18.2.0/24 unicast [R0 02:11:51.133 from 198.19.0.0] * (100) [AS4242420002i] Type: BGP univ BGP.origin: IGP BGP.as_path: 4242420000 4242420002 BGP.next_hop: 198.19.0.0 BGP.local_pref: 100 R1 $
R2 $ ./birdc s r all protocol R0 BIRD 2.0.10 ready. Table master4: 198.18.0.0/24 unicast [R0 02:11:51.132 from 198.19.0.0] * (100) [AS4242420000i] Type: BGP univ BGP.origin: IGP BGP.as_path: 4242420000 BGP.next_hop: 198.19.0.0 BGP.med: 300 BGP.local_pref: 100 198.18.1.0/24 unicast [R0 02:11:51.133 from 198.19.0.0] * (100) [AS4242420001i] Type: BGP univ BGP.origin: IGP BGP.as_path: 4242420000 4242420001 BGP.next_hop: 198.19.0.0 BGP.local_pref: 100 R2 $
Setting “export table off;” yield the expected result: R1 $ ./birdc s r all protocol R0 BIRD 2.0.10 ready. Table master4: 198.18.0.0/24 unicast [R0 03:15:47.147 from 198.19.0.0] * (100) [AS4242420000i] Type: BGP univ BGP.origin: IGP BGP.as_path: 4242420000 BGP.next_hop: 198.19.0.0 BGP.med: 300 BGP.local_pref: 100 198.18.2.0/24 unicast [R0 03:15:50.635 from 198.19.0.0] * (100) [AS4242420002i] Type: BGP univ BGP.origin: IGP BGP.as_path: 4242420000 4242420002 BGP.next_hop: 198.19.0.0 BGP.med: 300 BGP.local_pref: 100 R1 $
R2 $ ./birdc s r all protocol R0 BIRD 2.0.10 ready. Table master4: 198.18.0.0/24 unicast [R0 03:15:50.635 from 198.19.0.0] * (100) [AS4242420000i] Type: BGP univ BGP.origin: IGP BGP.as_path: 4242420000 BGP.next_hop: 198.19.0.0 BGP.med: 300 BGP.local_pref: 100 198.18.1.0/24 unicast [R0 03:15:50.635 from 198.19.0.0] * (100) [AS4242420001i] Type: BGP univ BGP.origin: IGP BGP.as_path: 4242420000 4242420001 BGP.next_hop: 198.19.0.0 BGP.med: 300 BGP.local_pref: 100 R2 $
protocol static { route 198.18.0.0/24 reject; ipv4 {}; } template bgp rs_peers { local 198.19.0.0 port 1179 as 4242420000; ipv4 { import table off; export table on; import all; export filter { if source ~ [RTS_STATIC, RTS_BGP] then { bgp_med = 300; accept; } reject; }; }; };
protocol bgp R1 from rs_peers { neighbor 198.19.0.1 port 1179 as 4242420001; }; protocol bgp R2 from rs_peers { neighbor 198.19.0.2 port 1179 as 4242420002; };
protocol static { route 198.18.1.0/24 reject; ipv4 { }; } protocol bgp R0 { ipv4 { import all; export filter { if source ~ [RTS_STATIC, RTS_BGP] then { bgp_med = 100; accept; } reject; }; }; local 198.19.0.1 port 1179 as 4242420001; neighbor 198.19.0.0 port 1179 as 4242420000; };
protocol static { route 198.18.2.0/24 reject; ipv4 { }; } protocol bgp R0 { ipv4 { import all; export filter { # here we export the whole net if source ~ [RTS_STATIC, RTS_BGP] then { bgp_med = 200; accept; } reject; }; }; local 198.19.0.2 port 1179 as 4242420002; neighbor 198.19.0.0 port 1179 as 4242420000; };
On Sun, Oct 16, 2022 at 11:17:23AM +0200, Inrin via Bird-users wrote:
Greetings,
I noticed during setting up a peering that the MED is not actually send to my peer, although bird shows it in the export. We confirmed this via tcpdump on both ends.
After debugging a bit, I noticed that this only affects “learned” routes but routes from the static protocol worked just fine.
After disabling the “export table” feature, the MED was send out just fine.
Is this behaviour expected?
Hello It is not expected behavior. Note that MED on route exported to EBGP should be removed, unless it is explicitly set in the export filter. I suspect that with export table, the attribute set in the export filter is considered mistakenly as 'old' instead of 'fresh' for the purpose of MED removal test, as the route is stored in the export table in-between. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
When using the MED-as-IGP-cost feature, shouldn't the MED be exported naturally? Em dom., 16 de out. de 2022 às 23:11, Ondrej Zajicek via Bird-users < bird-users@trubka.network.cz> escreveu:
On Sun, Oct 16, 2022 at 11:17:23AM +0200, Inrin via Bird-users wrote:
Greetings,
I noticed during setting up a peering that the MED is not actually send to my peer, although bird shows it in the export. We confirmed this via tcpdump on both ends.
After debugging a bit, I noticed that this only affects “learned” routes but routes from the static protocol worked just fine.
After disabling the “export table” feature, the MED was send out just fine.
Is this behaviour expected?
Hello
It is not expected behavior. Note that MED on route exported to EBGP should be removed, unless it is explicitly set in the export filter. I suspect that with export table, the attribute set in the export filter is considered mistakenly as 'old' instead of 'fresh' for the purpose of MED removal test, as the route is stored in the export table in-between.
-- Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
-- Douglas Fernando Fischer Engº de Controle e Automação
On Mon, Oct 17, 2022 at 09:03:04AM -0300, Douglas Fischer wrote:
When using the MED-as-IGP-cost feature, shouldn't the MED be exported naturally?
You mean feature that would export IGP cost as MED? AFAIK we do not have such feature. It is one thing planned.
Em dom., 16 de out. de 2022 às 23:11, Ondrej Zajicek via Bird-users < bird-users@trubka.network.cz> escreveu:
On Sun, Oct 16, 2022 at 11:17:23AM +0200, Inrin via Bird-users wrote:
Greetings,
I noticed during setting up a peering that the MED is not actually send to my peer, although bird shows it in the export. We confirmed this via tcpdump on both ends.
After debugging a bit, I noticed that this only affects “learned” routes but routes from the static protocol worked just fine.
After disabling the “export table” feature, the MED was send out just fine.
Is this behaviour expected?
Hello
It is not expected behavior. Note that MED on route exported to EBGP should be removed, unless it is explicitly set in the export filter. I suspect that with export table, the attribute set in the export filter is considered mistakenly as 'old' instead of 'fresh' for the purpose of MED removal test, as the route is stored in the export table in-between.
-- Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
-- Douglas Fernando Fischer Engº de Controle e Automação
-- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Hello, I wanted to ask if there is a possibility to aggregate routes in bird? Greetings -- Marek Küthe m.k@mk16.de er/ihm he/him
Thanks for the answer! I hope it's not too annoying when I ask, however I can not find any information about this online: Are there also plans to implement the Babel RTT extension? On Mon, 30 Jan 2023 19:13:23 +0100 Maria Matejka via Bird-users <bird-users@network.cz> wrote:
Hello!
I wanted to ask if there is a possibility to aggregate routes in bird?
Not yet. In progress, planned for 2023/Q2.
Maria
-- Marek Küthe m.k@mk16.de er/ihm he/him
Hello! On 2/3/23 08:35, Marek Küthe wrote:
Thanks for the answer! I hope it's not too annoying when I ask, however I can not find any information about this online: Are there also plans to implement the Babel RTT extension?
The core team doesn't have this in current plans. As there is no RFC for this yet, it's under my radar. Yet it seems that Toke has some experimental version of this in his fork and I can't remember whether it is merge-ready or not. Maybe he can add more information. https://github.com/tohojo/bird/tree/babel-rtt-01 I hope that after getting the multithreaded BIRD out and stable, I get back to tracking RFC drafts and at least putting them into our roadmap. Maria
Thanks for the answer! I hope it's not too annoying when I ask, however I can not find any information about this online: Are there also plans to implement the Babel RTT extension?
The core team doesn't have this in current plans. As there is no RFC for this yet, it's under my radar.
I am planning to work on the RFC starting next week, so this is the right time to send me comments on the RTT extension. The current draft is at https://datatracker.ietf.org/doc/html/draft-ietf-babel-rtt-extension-00 -- Juliusz
Hello! On 2/3/23 13:05, Juliusz Chroboczek wrote:
Thanks for the answer! I hope it's not too annoying when I ask, however I can not find any information about this online: Are there also plans to implement the Babel RTT extension?
The core team doesn't have this in current plans. As there is no RFC for this yet, it's under my radar.
I am planning to work on the RFC starting next week, so this is the right time to send me comments on the RTT extension. The current draft is at
https://datatracker.ietf.org/doc/html/draft-ietf-babel-rtt-extension-00
I've just read this draft and I must say that it looks nice, simple and clean. My suggestion: to explicitly state how the timestamp rollover happens, e.g. that exactly one microsecond after 2**32-1 there is always timestamp of zero. As this happens quite often (every ~1h11min), it IMHO deserves an explicit definition. Maybe another question is about interoperability and setting, e.g. when there are some nodes capable of RTT and others not using this extension. Example situations include: * one node requests RTT and the other knows about this extension but doesn't have it allowed * one node requests RTT and the other doesn't implement this extension * whether it is OK to setup RTT for some links and default (hello statistics) for others -- I'd suppose that RFC 8966 / 3.4.3 says yes BTW the draft states that it updates 6126 which is outdated. Thank you for working on Babel improvements! Maria
participants (6)
-
Douglas Fischer -
Inrin -
Juliusz Chroboczek -
Marek Küthe -
Maria Matejka -
Ondrej Zajicek