Re: BGP on /32 (/128) interfaces
On Tue, May 14, 2024 at 03:58:06PM +0200, Arzhel Younsi wrote: > Thank you all for your replies, > > > Thinking about it, it makes sense to have something like direct mode that > works with unnumbered interfaces (or ones with /32 address). > > We also think that's would be very useful, either transparently to the user > (depending on next hop resolution, eBGP/iBGP, IP's subnet mask) or through > the addition of an explicit "direct" keyword. > > What would be the process to turn this thread into a feature request ? And > would the Bird maintainers be interested in implementing it ? Hi I already made it a feature request and plan to implement it. > Perhaps the presence of the ‘direct’ keyword combined with a manual > ‘interface X’ in a protocol block could signal to bypass the usual > evaluation and force a neighbor to be considered ‘direct’? That seems like a reasonable idea, but it has some caveats. Common IP range is used not only to find the interface but also to select the local address. If both 'direct' and 'interface' were changed to not wait for common IP range, then it may start the session immediately after the interface went up but before the IP address is assigned to it, using different IP address, therefore changing the current behavior. One way would be to make specifying local IP mandatory, another one would be to add option like 'onlink' to state explicitly that the neighbor is not expected to be on a shared IP range. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Re: use TCP_NODELAY on TCP sockets?
On Wed, May 15, 2024 at 06:37:18PM +0200, Job Snijders via Bird-users wrote: > Dear BIRD people, > > On most systems RFC 896 TCP congestion control is used, also known as > "Nagle's algorithm". This algorithm is intended to help coalesce > consecutive small packets from userland applications (like BIRD) into a > single larger TCP packet. The idea being it reduces bandwidth because > there is less TCP overhead if data is bundled into fewer packets. > ... > I think using TCP_NODELAY is interesting to consider, because it seems > sensible to try to deliver BGP messages as fast as possible. OpenBGPD > and FRR set the TCP_NODELAY socket option. Hi Yeah, i think that using TCP_NODELAY for BGP makes sense, considering there is already non-trivial framing and we write individual BGP messages with one write(). -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Re: EVPN support in BIRD
On Mon, May 06, 2024 at 12:24:07PM +0200, Tim Weippert via Bird-users wrote: > Hi Ondrej, > > just a quick question, should bird2 announce type 2 prefixes > in this state? > > i do some tests with an FRR EVPN network and add one bird2 evpn node. I > receive evpn routes and see them in the appropriate tables (evpntab and > etab), but while on the FRR side i get only the l2 parts of a type 2 > route if i interpret the output form FRR correctly: > > Also i'm wondering should bird2 also add the corresponding arp entries > to the neigh table in kernel? > > Some hints for me where to look further on the issue? Hi First, thanks for testing EVPN in BIRD. We do not set IP part of type 2 and do not use it to configure neigh table. That is optional part of EVPN not yet supported in BIRD (while setting MAC part and configuring bridge table is mandatory). Do you need this feature? Anyway, what was your experience with EVPN in BIRD? Was it understandable and accessible from user point? Is there anything you missed? -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Re: Large communities indicating RPKI VALID status
On Sun, Apr 28, 2024 at 01:00:40PM +0200, Job Snijders wrote: > On Sat, Apr 27, 2024 at 03:00:45PM +0200, Ondrej Zajicek via Bird-users wrote: > > On Sat, Apr 27, 2024 at 08:18:18AM +0200, Daniel Suchy via Bird-users wrote: > > > There's internet draft describing in detail, why it's not a good idea to > > > store RPKI validation state inside community variables at all.. > > > > > > https://www.ietf.org/archive/id/draft-ietf-sidrops-avoid-rpki-state-in-bgp-00.html > > > > Well, note that this draft is primarily about not announcing validation > > state in transitive attributes to the whole internet. > > Yes > > > But there are good reasons for having validation state in > > non-transitive BGP attributes (or communities properly filtered out on > > AS egress). Validating RPKI and marking routes at AS ingress ensures > > that all routers within AS have consistent routing state and thus > > avoiding routing loops. > > Perhaps I am missing something, but how does marking in itself help > avoid routing loops? > > I am under the impression that a requirement for intra-AS transitive > marking follows from non-standard modifying of non-transitive local > attributes (for example, 'weight' or 'preference') based on the > validation state - which is not what I'd recommend to begin with. Well, you are right. there are three ways how to define policy based on RPKI status: 1) Validate RPKI for all routes and apply policy based on the validation state on all routers. 2) Validate RPKI only for EBGP routes on border routers, mark result with communities, then apply policy based on marks on all routers. 3) Validate RPKI only for EBGP routes on border routers, apply policy based on validation state there and use (non-transitive) BGP attributes for policy (like bgp_local_pref) to propagate it through AS. The first approach is bad and can easily lead to inconsistent routing, the second is better as marking ensures that different routers have consistent view of validation states of routes, but the third approach is even better and does not require explicit marking of validation states (although one could argue that the validation state is implicitly encoded in the policy-carrying BGP attributes). > Merely rejecting RPKI-invalid routes at the AS ingress and *not* > manipulating any other local or transitive path attributes will also > ensure a consistent routing state. Obviously. > > Unfortunately large communities do not have transitive flag like > > extended ones > > so perhaps it would make sense to use extended community for this > > purpose. Or perhaps there should be well-known extended community for > > that ... > > https://www.rfc-editor.org/rfc/rfc8097.html ? Thanks, i was not aware of this. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Re: How to set ospf as external route as ext1?
On Sun, Apr 28, 2024 at 02:29:42PM +, chan alfie wrote: > The default ospf ASE will be set as rts_ospf_ext2, how to change it, and set > the ospf ASE as rts_ospf_ext1? Hi Set ospf_metric1 route attribute in export filters. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Re: Large communities indicating RPKI VALID status
On Sat, Apr 27, 2024 at 08:18:18AM +0200, Daniel Suchy via Bird-users wrote: > There's internet draft describing in detail, why it's not a good idea to > store RPKI validation state inside community variables at all.. > > https://www.ietf.org/archive/id/draft-ietf-sidrops-avoid-rpki-state-in-bgp-00.html Well, note that this draft is primarily about not announcing validation state in transitive attributes to the whole internet. But there are good reasons for having validation state in non-transitive BGP attributes (or communities properly filtered out on AS egress). Validating RPKI and marking routes at AS ingress ensures that all routers within AS have consistent routing state and thus avoiding routing loops. Unfortunately large communities do not have transitive flag like extended ones, so perhaps it would make sense to use extended community for this purpose. Or perhaps there should be well-known extended community for that ... -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Re: IPv4 next-hops over IPv6
On Fri, Apr 19, 2024 at 02:29:44PM -0500, Jay Hanke via Bird-users wrote: > Has anyone implemented lab or production IPv4 next hops over an IPv6 > only IX vlan with BIRD as the route server? > > I'm interested to hear your experiences. Specifically router vendor interop. Note that there is an Euro-IX working group targetting this issue: https://github.com/euro-ix/rfc8950-ixp -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Re: babel RTT metric false samples
On Sat, Apr 13, 2024 at 04:38:47PM +0200, Erin Shepherd wrote: > I guess it might not fit with bird's abstractions (or perhaps the Babel > protocol), but has thought been given to using SO_TIMESTAMPING to have the > kernel compute TX/RX timestamps? Yeah, that is definitely a better solution. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Re: OSPF bad packet
On Mon, Apr 15, 2024 at 02:22:01PM +, Benoit Chesneau wrote: > Hi Ondrej, > > Not sure I undersand, these are the IPs of this router itself: > > ``` > root@gw0:~ # ifconfig vlan600 > vlan600: flags=1008843 > metric 0 mtu 9000 > description: backbone > > options=1c680703 > ether fa:9b:80:06:d7:f9 > inet 198.19.4.33 netmask 0xffe0 broadcast 198.19.4.63 > inet6 fe80::f89b:80ff:fe06:d7f9%vlan600 prefixlen 64 scopeid 0x5 > inet6 2001:7f8::2:103::1 prefixlen 64 > groups: vlan > vlan: 600 vlanproto: 802.1q vlanpcp: 0 parent interface: mce0 > media: Ethernet 25GBase-SR > status: active > nd6 options=21 > ``` > > > I didn't find equivalent router id on the network. I also tried to uniquely > change the ID but the same error appears. Is there anything I could do to > debug this issue ? Hi It seems like the OSPF receives its own packets back. There is a check that should make them to be silently ignored: /* We want just packets from sk->iface. Unfortunately, on BSD we cannot filter out other packets at kernel level and we receive all packets on all sockets */ if (sk->lifindex != sk->iface->index) return 1; But for some reason it does not work in your case, AFAIK it worked in older BSDs. It should be harmless outside of spanning your logs. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Re: BGP on /32 (/128) interfaces
On Mon, Apr 15, 2024 at 12:10:05PM +0200, Daniel Gröber wrote: > Hi Arzhel, > > On Fri, Apr 12, 2024 at 11:57:38AM +0200, Arzhel Younsi wrote: > > But for IPv6, it's cleaner to only require the router's link local address: > > testvm2006:~$ ip -6 addr > > inet6 2620:0:860:140:10:192:24:4/128 scope global > > testvm2006:~$ ip -6 route > > default via fe80::2022:22ff:fe22:2201 dev ens13 metric 1024 pref medium > > > > In Bird: > > neighbor fe80::2022:22ff:fe22:2201%ens13 external; > > > > But then the link local address doesn't work with multihop (for obvious > > reason). > > bird: /etc/bird/bird.conf:22:1 Multihop BGP cannot be used with link-local > > addresses > > I use lladdrs for BGP endpoints in my network and that works fine. I think > using `direct` instead of `multihop` in the v6-lladdr case would make it > work for you. > > One word of advice: don't use the %scope syntax, use the `interface` > directive instead. I don't recall exactly why but I had some subtle problem > with that. > > As for your v4/32 problem, give `multihop 1` a try. That enforces no > routers on the path to the peer like direct but allows off-subnet > endpoints. Do keep in mind the docs recommend setting the source address > explicitly when enabling multihop. Hi Note that using multihop fixes the issue with waiting for the address range to appear, but there is still an issue with next hop resolution. Multihop routes use recursive next hop resolution and in the case of /32 address ranges, there is no route for resolving neighbor IP announced as next hop. One would need a static route like: route NBR-IP/32 via "IFACE"; So the next hop will be resolved. Thinking about it, it makes sense to have something like direct mode that works with unnumbered interfaces (or ones with /32 address). -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Re: 2.0 user's guide shows incorrect date format for passwords
On Wed, Mar 27, 2024 at 11:25:12AM +, Pisilä Janne via Bird-users wrote: > Hello, > > The password protocol option section in user's guide 2.0 > https://bird.network.cz/?get_doc=20=bird-3.html#proto-pass > incorrectly shows date format as dd-mm- when it should be -mm-dd in > BIRD v2. Hello Thanks, fixed. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Re: 回复: How to config a ospf stub area?
On Wed, Apr 10, 2024 at 02:48:11AM +, chan alfie wrote:
> rt3
> ```
> rt3# bird -c /etc/bird/lab/rt3.conf -p
> bird: /etc/bird/lab/rt3.conf:173:1 ASBR must be in non-stub area
> ```
> does it mean this router is an ASBR? but this router only connect to rt4. and
> does not contain static route, here is the complete bird.conf
Yes. In BIRD, router is considered ASBR if the export filter of the OSPF
protocol is set to something different than 'none' (so it could export
external routes, regardless of whether it actually exported them).
That is also a reason why it does not allow it the area 172.16.34.0 to be
set as stub area (as ASBRs cannot be in stub areas).
Just do not set export filter in OSPF if you do not want to export external
routes.
> protocol ospf v2 {
> ipv4 {
> import all;
> export all;
> };
> area 172.16.34.0 {
> stub;
> summary yes;
> interface "veth34" {
> type bcast;
> cost 10;
> hello 10;
> };
> interface "lo3" {
> stub yes;
> };
> };
> }
--
Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
"To err is human -- to blame it on a computer is even more so."
Re: [PATCH] Build failure with parallel make
On Mon, Apr 08, 2024 at 12:26:45PM +0100, Jim Hague via Bird-users wrote: > Hi all, > > While building a Buildroot project, I ran into an occasional Bird build > failure. In a parallel make environment, nest can try to write proto-build.c > to objdir/nest before that directory exists. I think this patch fixes: Hi It is already fixed: https://gitlab.nic.cz/labs/bird/-/commit/23f3dd5cfbe8681b4e71c8d7345bdeaafc86e077 It seems that there is an old version of BIRD in the Buildroot project. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Re: OSPF for IPv4 over IPv6 only?
On Sat, Apr 06, 2024 at 04:54:48PM +0200, Pim van Pelt via Bird-users wrote: > Hoi Ondrej, Bird users, > > TL/DR: Ondrej's patch works and allows Bird to use OSPFv3 with either > completely unnumbered interfaces, where it 'borrows' a valid IPv4 address > from a loopback device. It does so without breaking RFC5838! > > I wrote up my findings on > https://ipng.ch/s/articles/2024/03/06/vpp-ospf.html Hi Thanks for your wonderful blogposts. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Re: OSPF for IPv4 over IPv6 only?
On Fri, Apr 05, 2024 at 04:27:27PM +0200, Pim van Pelt wrote: > Hoi, > > On 4/5/24 15:23, Ondrej Zajicek wrote: > > I have almost implemented 'extended next hop' for OSPFv3. But then i > > pivoted to supporting properly IPv4 loopback nexthop [*]. Now i have > > doubts about usefulness of 'extended next hop', as any IPv4 router needs > > at one IPv4 address anyways (at least to be able to send ICMP messages) > > and there is no need to put IPv4 addresses on links. Are there any good > > arguments for it? > In VPP, an interface that does not have an ip4 address, will not allow for > ip4 traffic to enter it. In other words, there must be an ip4 address on the > interface before forwarding is turned on. > I know how to change that behavior in VPP, but it's not a problem in > practice, because we can set 'unnumbered' interface and borrow an IPv4 > address from another interface, usually a loopback interface with a /32 ip4 > and /128 ip6. > > I think it'd be super cool to use OSPFv3 without IPv4 transit networks and > just reusing the loopback addresses, like so: > > root@vpp0-2:~# ip -br a > lo UNKNOWN 127.0.0.1/8 ::1/128 > loop0 UNKNOWN 192.168.10.2/32 2001:678:d78:200::2/128 > fe80::dcad:ff:fe00:0/64 > e0 UP 192.168.10.2/32 2001:678:d78:200::2/128 > fe80::5054:ff:fef0:1120/64 > e1 UP 192.168.10.2/32 2001:678:d78:200::2/128 > fe80::5054:ff:fef0:1121/64 > * > *However, up-thread (message of 2024-04-30, 16:04) I had that configuration, > saw the LSAs but did not see Linux (nor VPP) pick up the routes. Even if LSAs are here the question is whether OSPF generated such routes (i.e. whether birdc show route would show them). In order for kernel to pick them up, OSPF has to generate them and with 'onlink' flag on next hop. > My > suspicion is that your commit will be inert in this scenario, because e0 > already has an IPv4 address, so loopback_addr_used will remain 0. I think it might help, because even if loopback_addr_used will remain 0, there is also this change in the patch: https://gitlab.nic.cz/labs/bird/-/commit/280daed57d061eb1ebc89013637c683fe23465e8#da87cc518d8a6ca24bc804dfc6ad134504731a9c That for OSPFv3-IPv4 removes next-hop-in-address-range check (and automatically adds onlink flag), which caused rejection of such next hops. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Re: OSPF for IPv4 over IPv6 only?
On Tue, Apr 02, 2024 at 11:49:21PM +0200, Pim van Pelt via Bird-users wrote: > Hoi Ondrej, > > On 02.04.2024 16:40, Ondrej Zajicek via Bird-users wrote: > > Although one could have option that forces it to interpret as IPv6, i > > would prefer to have 'extended next hop' option that allows to accept > > both IPv4 and IPv6 next hops in Link-LSA. > ps - even with IPv4 on the interface and RFC5838 as it was intended, I still > don't see Bird emit the learned routes to the kernel (see my message to > Benoit on 30.03.2024, 15:50); so I think even setting extended next hop > aside, I cannot confirm that OSPFv3 with ipv4 channel works in that > configuration. Hi I have almost implemented 'extended next hop' for OSPFv3. But then i pivoted to supporting properly IPv4 loopback nexthop [*]. Now i have doubts about usefulness of 'extended next hop', as any IPv4 router needs at one IPv4 address anyways (at least to be able to send ICMP messages) and there is no need to put IPv4 addresses on links. Are there any good arguments for it? [*] https://bird.network.cz/pipermail/bird-users/2024-April/017555.html -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Re: announce IPV4 loopback via an OSPF v3 backbone
On Wed, Mar 27, 2024 at 09:08:35AM +, Benoit Chesneau wrote: > Hi everyone, > > I was reading the ospv3 spec and this link > https://networklessons.com/ospf/ospfv3-for-ipv4- and was wondering if such > features is supported in bird 2. Can we announce loopbacks via OSPFv3 and > remove the need to use OSPFv2 and ptp subnets ? > > I see it as a good opportunity to reduce the usage of the IPv4 addresses if > we can just advertise loopbacks... Hi This feature was not implemented in BIRD 2, i just implemented it yesterday: https://gitlab.nic.cz/labs/bird/-/commit/280daed57d061eb1ebc89013637c683fe23465e8 If there is no IPv4 address on the iface, it chooses an IPv4 address from another OSPF-managed iface (preferably /32 or stub) and announces that. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Re: OSPF for IPv4 over IPv6 only?
On Tue, Apr 02, 2024 at 11:49:21PM +0200, Pim van Pelt via Bird-users wrote: > Hoi Ondrej, Hi > On 02.04.2024 16:40, Ondrej Zajicek via Bird-users wrote: > > Although one could have option that forces it to interpret as IPv6, i > > would prefer to have 'extended next hop' option that allows to accept > > both IPv4 and IPv6 next hops in Link-LSA. > Did you mean that: > 1) under normal circumstances, an ipv4 channel with an ipv6 ospfv3 > adjacency, will respect RFC5838 and overload the link-lsa with the ipv4 > address; > 2) when `extended next hop` is active on the interface, an ipv4 channel with > ipv6 ospfv3 adjacency, will use the ipv6 nexthop in the link-lsa? Yes, if there is no IPv4 address or when forced (like your 'extended next hop always'). > If so, (2) will make Bird break interoperability with any other RFC5838 > neighbor. Yes, such option will break interoperability, but if you have no IPv4 address on the interface, what address put to Link-LSA anyway? > Is an alternative perhaps, to make Bird choose the message neighbor as > nexthop, and ignore the link-lsa value when `extended next hop` is set? Or > is that gross? > > Example: if neighbor fe80:foo::1234/64 sent the LSA with nexthop as > c201.00* (192.0.2.1), AND `extended next hop` is set AND the interface > doesn't have an IPv4 address, only then do we ignore the link-lsa but use > fe80:foo::1234%iface instead. There is an alternative way to get route nexthops, from (Hello packet) source addresses stored in neighbor structures, indexed by neighbor's router ID. That is probably what you mean by 'message neighbor'. We use this for PtP/PtMP links in OSPFv2 and OSPFv3-IPv6. But it is problematic on multi-access links, where you have adjacency just with DR/BDR. It cannot be used for NBMA links (as you may have no communication with other neighbors). On broadcast links, you have at least Hello exchange with neighbors, but there are still some problematic cases when multiple interfaces are used to connect to one network. > Incidentally, if we decide to merge the babel patch I offered, we can > further create analogous behavior by allowing `extended next hop always` > which would use the message neighbor address even if an IPv4 address is > present. > > ps - even with IPv4 on the interface and RFC5838 as it was intended, I still > don't see Bird emit the learned routes to the kernel (see my message to > Benoit on 30.03.2024, 15:50); so I think even setting extended next hop > aside, I cannot confirm that OSPFv3 with ipv4 channel works in that > configuration. Will check that both. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Re: Coexistence of multiple babel daemons on the same host
On Sun, Mar 31, 2024 at 11:34:43AM +0200, Daniel Gröber wrote: > Hi Babelers, > > I've just come across a reason I'd want to run babel with both bird and > babeld on the same node and have them become neighbours. The details are > tedious -- my usual disclamer applies ;) If you want to have both bird and babeld on the same node and have them neighbors, you could create veth pair, assign bird to one end and babeld on the other end. You probably should use different routing tables for each (as Juliusz Chroboczek noted) and they should use different set of interfaces. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Re: OSPF for IPv4 over IPv6 only?
On Mon, Apr 01, 2024 at 04:14:51PM +0200, Sebastian Hahn wrote: > > Sebastian - my interpretation of 5838 is slightly different, and I don't > > think it expressly forbids xAF nexthops: > > > 2.5: Although IPv6 link local addresses could be used as next hops for > > > IPv4 address families, it is desirable to have IPv4 next-hop addresses. > > My understanding came from this: > > > In order to achieve this, the link's IPv4 address will be advertised > > in the "link local address" field of the IPv4 instance's Link-LSA. > > This address is placed in the first 32 bits of the "link local > > address" field and is used for IPv4 next-hop calculations. The > > remaining bits MUST be set to zero. > > which to me reads like the statement about desirability just explains > why the technical design doesn't allow IPv6 next hops. I would be > happy to be wrong here. Hi Unfortunately, RFC 5838 chose the worst way to represent IPv4 in Link-LSA, so there is no reliable way to know whether received Link-LSA should be interpreted as IPv4 or IPv6. Although one could have option that forces it to interpret as IPv6, i would prefer to have 'extended next hop' option that allows to accept both IPv4 and IPv6 next hops in Link-LSA. We could use heuristic, like if first u32 is fe80, it is IPv6, if remaining u32s are 0, it is IPv4, And hope that nobody uses both fe80::0 and 254.128.0.0. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Re: Export shows new filters after "configure soft" before any update
On Fri, Mar 22, 2024 at 03:56:12PM +0100, Inrin via Bird-users wrote: > Hiho, > > I noticed that `birdc show route export ` after a `configure soft` > shows the state with the new export filter, even if no update ocurred. > The PCAP also shows, as long as no external update comes in, no updates > are send out on the wire. > > Using export tables makes it possible to see the "real" state. > For example, until a new external update or a `reload out` it shows the > "old filter" state. > > For import filters it's different. > It shows the "old" state until an external update comes in or `reload in` is > used. With or without import tables or `keep filtered on`. > > Since the help states: > configure soft [""] [timeout []]Reload configuration and > ignore changes in filters > it should be like for the import case and show the "old" state until an > update comes in or `reload out` is used. > > Finally to my question: > Is this behaviour intentional? Hi It is intentional. Unless explicitly requested by 'show route import table' or 'show route export table', we use data from regular routing tables for this commands. Therefore, it shows routes that either really are in the routing table (i.e. 'old' state when import filters are changed), or compute current export filter for 'show route export'. We have to use the current export filter, as after reconfigure we do not keep the old one. > Best would be to even make it possible to ignore the new filters until > manual reload, but thats probably a bigger change ;) Yes, that is something that would make more sense. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Re: [2.14] show route not showing all tables (rpki)
On Fri, Mar 22, 2024 at 03:57:23PM +0100, Maria Matejka via Bird-users wrote: > For BIRD 2, we extrapolated that to show at most one table per network type. > These design choices are always some kind of looking for equilibrium – if > you have 1K+ tables, you typically don'ŧ want to dump them all. OTOH, in > your case, it would make better sense to show all of them. Where is the > boundary? > > While writing this and thinking about it, what if we made it configurable, > to let you say for each table whether show by defaultor not? Yes, i also thought about this and per-table option seems to me like a reasonable approach. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Re: [2.14] show route not showing all tables (rpki)
On Thu, Mar 21, 2024 at 09:05:04PM +, Elmar K. Bins via Bird-users wrote: > Hello folks, > > we're running 2.14 on FreeBSD 13.3 (out of the current bird2-2.14 pkg). > > A long time ago we set up RPKI feeds that put their routes into tables > r4 and r6. > > I've just added a second RPKI source that feeds into table r44 and r66. > "show route count" does NOT include these tables: > > --- > bird> show route count > 25524 of 25524 routes for 14191 networks in table master4 > 2775 of 2775 routes for 1808 networks in table master6 > 421637 of 421637 routes for 421637 networks in table r4 > 101571 of 101571 routes for 101571 networks in table r6 > Total: 551507 of 551507 routes for 539207 networks in 4 tables > > bird> show route table r44 count > 401463 of 401463 routes for 401463 networks in table r44 > > bird> shor route table r66 count > No such command. Press `?' for help. > --- > > (ys, birdc has been fully restarted, just in case something was hanging). > > Any idea why? Is this intentional, an oversight, or a bug? Hi The command 'show route' by default shows the first table for each network type. Use 'show route table all' if you want all tables. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Re: 2.15, ospf is broken
On Tue, Mar 19, 2024 at 08:50:22AM +0400, Dmitry Melekhov wrote: > Hello! > > Just upgraded and got: > ... > Downgrade to 2.14 solved problem. > > Is there fix for this or workaround? Hello There are two issues, both caused by commit 31aa62ae6d2e111e87c08b4b27a16ead968f0689: 1) BIRD could generate ECMP routes with multiple dev-only nexthops, which Linux kernel accepts only in IPv4 but not in IPv6 case. 2) The commit breaks the way how next hops are inherited during next hop calculations. Both issues are restricted to physical PtP links (including L3 tunnels like GRE). The first issue is limited to ECMP IPv6 and can be workarounded by disabling ECMP, the second one has wider impact. Soha Jin sent patches for both of this issues [*], but i am leaning towards making a quick bugfix release that reverts the original commit, so we can take more time to evaluate the change. [*] Patches: https://bird.network.cz/pipermail/bird-users/2024-March/017475.html https://bird.network.cz/pipermail/bird-users/2024-March/017504.html -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Re: 2.15, ospf is broken
On Tue, Mar 19, 2024 at 02:51:50PM +0400, Dmitry Melekhov wrote: > 19.03.2024 13:15, Soha Jin пишет: > > > > Hi All, > > > > I have found the problem (inherit next hop from a pointopoint router) > > and already drafted a patch. I will post the patch to the list once I > > have tested it. > > > > Problem is caused by some change , may be it is possible just revert it? The change is commit 31aa62ae6d2e111e87c08b4b27a16ead968f0689, you could revert it for yourself to get working BIRD. But that commit solved some other problem in different setups, so we would like to find a fix that works for the original issue and not causing further problems. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Re: RTBH (Remotely Triggered Black Hole) using Bird
On Mon, Mar 18, 2024 at 09:57:22AM +, Mazur, Dariusz via Bird-users wrote: > Hello Bird Users, > I am trying to implement RTBH (Remotely Triggered Black Hole) in below setup: > > 0.Simplified Topology: > > * ebgp fabric > * inside fabric we use only IPv6, so we announce IPv4 blocks with IPv6 > next hop (extended next hop) > * tor --- leaf --- spine---3xstem(3xborder_leaf) --- border > * tor announces 192.168.66.1/32 tagged with (65535,666) up to border > > 1.Border has static route: > r04.border01.labkrk05.fab> show route for 23.0.0.255 > 23.0.0.255/32blackhole [DISCARD_ROUTE_v4 2024-01-08] * (200) > > 2.Border learns 192.168.66.1/32. In import filter I change next hop to > 23.0.0.255 to blackhole traffic to 192.168.66.1/32. > I don’t see this change in “show route” but I see this in “show route all” > > Can you give me a tip how to change eBGP next hop in this scenario and > resolve it recursively via static route? Hello In BIRD, there is BGP Next Hop attribute (bgp_next_hop) and immediate next hop (gw). In case of non-recursive next hop processing (like from EBGP), gw is initialized from bgp_next_hop by BGP, but further changes to the bgp_next_hop (in BGP import filter) does not change gw. In recursive next hop processing, there is also an indirect next hop that is initialized from bgp_next_hop by BGP and it is used for route table lookups to compute gw. As in the non-recursive case, further changes to the bgp_next_hop does not change the indirect next hop. And this indirect next hop is not accessible from filters. In your case i would suggest to avoid indirect resolving through the blackhole route and instead to change received RTBH routes directly to blackhole routes: if ... then dest = RTD_BLACKHOLE; -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Re: show bfd sessions
On Mon, Mar 11, 2024 at 11:27:34PM +0100, Alexander Zubkov via Bird-users wrote: > Hi all, > > I noticed in the new version 'show bfd sessions' was extended with > 'all' option. But I also noticed that in case of 'show protocols', > 'show ospf state|topology' this option comes before [name], but for > 'show bfd sessions' it is the other way. I think it would be better to > be consistent here and use 'all' keyword before [name] too. Hi In fact, for 'show bfd sessions' you can use the option 'all' either before or after [name], as there is no fixed order of options for this command. In documentation, there is an order in which they appear, e.g.: show bfd sessions [] [address ] [(interface|dev) ""] [ipv4|ipv6] [direct|multihop] [all] but that is just simplification, they can be used in any order. In general, there are commands that have a few options and depend on fixed order (e.g. 'show protocols' or 'show ospf neighbors'), and there are commands that have more complex options, use key/value scheme and allow options in arbitrary order (e.g. 'show route', 'show ospf lsadb', or 'show bfd sessions'). I think that the first scheme is lazy and non-extensible, and most commands should be converted to the second scheme. > I also noticed some incompleteness of the "Remote control" > documentation now. I.e. it lists: > show protocols [all] > When it is actually: > show protocols [all] [|""] Yes, that is missing. > Also "show route ... [options]" does not have clear description of > what these options are. Not sure if you mean interactive help or reference documentation, as in the documentation they are described: https://bird.network.cz/?get_doc=20=bird-4.html#cli-show-route (but of course, it could always be improved.) > It seems there are ways to improve this part of the documentation. I > can offer a hand to examine it in more details what else might be > missing and maybe prepare patches. You are welcome. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Re: BIRD 2.15
On Mon, Mar 11, 2024 at 11:30:12AM +, Zagorski, Michal via Bird-users wrote: > Hi, > Looks like our build from sources with reconfiguration failed on static > routes config definitions. > When configuring with ./configure --with-protocols="bgp static bmp pipe rpki" > - static without bfd, > DEV keyword in proto/static/config.Y isn't recognized: > $ make -j9 Thanks, merged. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
EVPN support in BIRD
Hello Recently, we made a beta release of EVPN support in BIRD: https://gitlab.nic.cz/labs/bird/-/tree/evpn (branch 'evpn' in BIRD git repository) You are welcome to try it and give us your feedback and suggestions. The primary documentation is still missing, but there are comprehensive examples and comments here: https://gitlab.nic.cz/labs/bird-tools/-/tree/master/netlab/cf-evpn-bgp (especially bird_m11.conf and bird_m12.conf) For filter expressions related to EVPN, see function t_net_evpn() in: https://gitlab.nic.cz/labs/bird/-/blob/evpn/filter/test.conf If you have any questions, feel free to ask here on the mailing list. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Re: BIRD 2.15
On Sun, Mar 10, 2024 at 10:13:56PM +0100, Pim van Pelt via Bird-users wrote:
> Hoi,
>
> Thanks for the release! I was wondering about this one:
>o Static routes can have both nexthop and interface specified
> Could I not have already been able to set 'route 192.0.2.1/32 via
> 100.64.0.1%eth0 onlink' ? If this is different, can you share a canonical
> syntax ?
Hi
Yes, it is something that could already be done using the IPv6-scope
syntax, but that was both a hack (outside IPv6 link-local) and was
limited in allowed characters in interface name. Now you can use:
route 192.0.2.1/32 via 100.64.0.1 dev "eth0" onlink;
https://bird.network.cz/?get_doc=20=bird-6.html#static-route-dev
For details, see this thread:
http://trubka.network.cz/pipermail/bird-users/2024-February/017411.html
> By the way, the following yields a crash upon startup of Bird 2.14 (perhaps
> in 2.15 also, I will check):
>
> protocol static s1 {
> ipv4 { export all; };
> route 192.0.2.1/32 via 192.168.10.2%e0 *onlink bfd*;
> }
Will check that
--
Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
"To err is human -- to blame it on a computer is even more so."
Re: bird not exporting OSPF route
On Wed, Feb 28, 2024 at 04:15:32PM +0900, Nico Schottelius via Bird-users wrote:
>
> Good morning,
>
> after switching over to the following filter, as mentioned in the last
> mails:
>
> filter static_and_bgp_and_ospf {
> if(source = RTS_STATIC || source = RTS_BGP || source = RTS_OSPF) then
> accept;
> reject;
> }
Hi
OSPF generates routes with four source values:
RTS_OSPF, RTS_OSPF_IA, RTS_OSPF_EXT1 and RTS_OSPF_EXT2.
(for internal, inter-area, type 1 external and type 2 external routes).
So in your case you just export internal OSPF routes, not the E2 route.
Also note you can write the condition using sets:
if source ~ [ RTS_STATIC, RTS_BGP, RTS_OSPF, RTS_OSPF_IA, RTS_OSPF_EXT1,
RTS_OSPF_EXT2 ] then ...
>
> bird> show route all for 2a0a:e5c0:2:a::b
> Table master6:
> 2a0a:e5c0:2:a::b/128 unicast [ospf6 2024-02-26] * E2 (150/10/1)
> [147.78.194.129]
> via fe80::3eec:efff:fecb:d81a on eth0
> Type: OSPF-E2 univ
> OSPF.metric1: 10
> OSPF.metric2: 1
> OSPF.tag: 0x
> OSPF.router_id: 147.78.194.129
>
> And is there actually a CLI syntax for
> verifying that a route is accepted by a filter?
show route export
(for should be exported)
or
show route exported
(for was exported)
--
Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
"To err is human -- to blame it on a computer is even more so."
Re: L3VPN and BGP add-path
On Sun, Feb 25, 2024 at 11:04:07PM +0100, Marcel Menzel via Bird-users wrote: > Hello List, > > I am running the new MPLS L3VPN feature for quite a while now, and it's > working without issues so far for me, but I have one question: > > I set "add paths on;" on my iBGP peer template in all SAFIs and while it was > running successfully before the migration to L3VPN, the additional routes in > the RIB are now gone, but the capabilities are still exchanged between > peers. Hello I am not sure where these 'add paths on' are in your setup. On BGP sessions ended inside VPNs? On BGP sessions between VPN routers, with VPN SAFI or IP SAFI? I am sure that existence of VPN SAFI should not affect functionality of ADD-PATH on IP SAFI on the same BGP session. I did not test whether ADD-PATH works for VPN SAFI, but i think it should. > Furthermore, I can't set "add paths on;" property for any SAFI in the L3VPN > protocol, this might be the reason why those additional routes are missing? Yes, that is not supported. L3VPN takes the best route for each IP prefix inside and convert it to VPN route outside, and it takes best route for each (RD, IP prefix) outside and convert it to IP route inside, so you can end with multiple IP routes for the same prefix inside VPN, but they are due to different RD, not due to ADD-PATH. > My only question now is if this just hasn't been implemented yet with BIRD > (I am just being curious hence I'm asking), my config is something missing > or this being the general fact that add-path with MPLS L3VPN simply is not a > thing with other vendors aswell (to be fair, I've never seen an L3VPN > network with add-path enabled in production so far). Well, in principle there is no reason why ADD-PATH should not work on BGP with VPN SAFI, but they are partially overlapping features. If you want to propagate into your internal network an IP prefix from multiple edge routers, you need ADD-PATH to avoid best path selection in route reflector. But if you want to propagate an IP prefix in one VPN, then each edge/PE router would use different RD, so you do not need ADD-PATH. Unless you already receive multiple paths to one IP prefix from CE to your PE and want to propagate them all to other PEs, in that case ADD-PATH would make sense. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Re: [patch] add 'source address' configuration option to RPKI protocols
On Wed, Feb 21, 2024 at 07:14:18PM +0100, Job Snijders via Bird-users wrote: > Dear BIRD team, > > Greetings from Amsterdam! > > I'd like to be able to explicitly configure the source IP address for > RPKI-To-Router sessions. Predictable source addresses are useful for > minimizing the holes to be poked in ACLs. The below changeset adds a > 'source address' configuration option to RPKI protocols. Thanks, merged: https://gitlab.nic.cz/labs/bird/-/commit/e2728c8078161d9811d6c24a11e4c95efd1c9313 I just changed the name from 'source address' to 'local address'. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Re: FOSDEM 2024 talk recording - Flying higher: hardware offloading with BIRD
On Tue, Feb 20, 2024 at 10:22:00AM +, Asbjørn Sloth Tønnesen wrote: > Hi Tim, > > The talk was a bit crammed for time, but the next speaker didn't show up, so > we unexpectedly had time for questions. > > Once I get the last bit's done, I will do a more detailed blog post, about > the setup we are making at my hackerspace Labitat (AS2052350), for that we > also need forwarding to directly connected hosts and reverse path filtering. > One of > the last slides has a picture of this setup, with a thin client and a > ConnectX-5 running at <15W while doing 10G > routing (DAC). Hi Thanks for the post, that seems like an interesting way to do high-performance forwarding. Is is possible to use this approach when a packet is forwarded between NICs (or at least between multiple ports on one NIC)? So it seems there are at least three ways how to do high-performance forwarding with Linux and BIRD: 1) White-box routers with hardware forwarding plane 2) VPP dataplane 3) tc-based rules that are offloaded to NIC -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Re: [patch] SendHoldTimer BGP Error code
On Sat, Feb 17, 2024 at 11:29:12AM +0100, Job Snijders via Bird-users wrote: > Dear all, > > IANA registered an "Early Allocation" BGP Error code for > draft-ietf-idr-bgp-sendholdtimer, see > https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp-parameters-3 > > The below changeset aligns bird with IANA's Border Gateway Protocol > (BGP) Parameters registry. Hi Thanks, merged: https://gitlab.nic.cz/labs/bird/-/commit/44a16bff6cbf3f5ae8db21ffcec602bc51295d0a -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Re: Static route IPv4 via FE80::2/64 and interface issue
On Wed, Feb 14, 2024 at 10:05:59AM +, Saklak, Marcin via Bird-users wrote:
> Hello Bird Users,
>
> I have an issue with adding static route and interfaces. I use two different
> platform one has interface names like eth-1_1_32 and second eth-1\1\64.
> First one works as I would expect.
>
> route 192.168.1.5/32 via fe80::2 % "eth-1\1\64";
> bird> configure
>
> Reading configuration from /mnt/storage/config/bird.conf
>
> /mnt/storage/config/bird.conf:29:51 syntax error, unexpected TEXT
>
> for:
> route 192.168.1.5/32 via "fe80::2%eth-1\1\64";
> no error and no entries in linux
> I did also tests with
> route 192.168.1.5/32 via "fe80::2%eth-1\\\1\\\64";
> route 192.168.1.5/32 via "fe80::2%eth-1\\1\\64";
>
> route 192.168.1.5/32 via fe80::2 % ’eth-1\\\1\\\64’;
> route 192.168.1.5/32 via fe80::2 % ’eth-1\\1\\64’;
>
> without any success
>
> Is it possible to make it work on both cases or there is some other way to
> configure such static route?
Hi
Looking now at the lexer and grammar rules, it is:
Quoted symbols (e.g. 'abc') can contain alphanumeric, '_', '-', '.' and ':'.
Doublequoted strings (e.g. "abc") can contain everything except '"',
as there is no quoting. It would be just "eth-1\1\64"
Unfortunately, for static route with link-local IPv6 address, the grammar
requires symbol not string, so one could just write something like fe80::1%eth0.
Therefore, it is not possible to use such interface name here directly.
You could do it indirectly, by defining it as a direct route and setting
nexthop in filter:
route 2001:db8:10::/48 via "eth-1\1\64" { gw = fe80::2; };
I think that we should accept more sane syntax for static routes with
link-local next hops, like one used by 'ip' command from iproute2,
i.e.:
route 2001:db8:10::/48 via fe80::1 dev "eth0";
--
Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
"To err is human -- to blame it on a computer is even more so."
Re: Multiple ebgp neighbours to the same peer
On Fri, Dec 29, 2023 at 09:43:43PM +0100, Alexander Zubkov wrote: > Hi, > > Let's resurrect this question. :) I've made a patch to illustrate what > I mean about the wildcard address in the lock object. Hi Thanks, merged: https://gitlab.nic.cz/labs/bird/-/commit/574d7eb241a60622b0573ab1460cb23d968ba1cc (with some cosmetic modifications) -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Re: Strict Bind usability
On Sun, Jan 14, 2024 at 10:50:18PM +0100, Sebastian Hahn wrote: > Hi list, > > I've been using strict bind for bgp, but there might be a lack in my > understanding or I have a proposal for a new feature. > Strict bind seems to be a bit more restrictive than I'd like (and than I > think it is necessary): > > I would like to use dynamic bgp (using a range for neighbour) with > auto-configured LL IPv6 adresses. This doesn't work, of course, if I need > to statically configure the source address, which I am forced to with the > strict bind option. I am wondering, is this restriction really needed? Hi You are right, this is something that could be easily changed. Will look at it. > In addition, it would be great if a strict bind option could be added for the > babel protocol. Babel (and OSPF, RIP) already uses one socket per interface. Such socket is not bound to specific IP address using bind(), but is bound to the specific interface using setsockopt(SO_BINDTODEVICE), at least in Linux. We cannot use bind() with local IP address for multicast sockets, as they would reject multicast packets (as they have different dst address as one the socket is bound). Anyway, it should not be necessary. AFAIK, setups that require strict bind in BGP should work out of the box in Babel. Or what specific setup does not work for you? > Also let me say Thanks for bird, it's a pleasure to use! Thanks! -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Re: [PATCH] birdc: Do not execute cmd on non interactive help request
On Thu, Dec 28, 2023 at 12:37:26PM +0100, Inrin via Bird-users wrote: > Hi! > > A pal of mine noticed that `echo ? | birdc` executes the command > after showing it's help text is shown. I later confirmed that `birdcl` > in > comparison to `birdc` does not show this behaviour. > > Since this is a non intuitive side effect on birdc's side, here a > proposed patch to align birdc and birdcl's behaviour. > > Please advise if fixing it on another part might be preferred. > I chose birdc.c, to minimize the changes needed. Thanks, merged. Sorry for the delay, i missed / forgot about the patch. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Re: OSPF for IPv4 over IPv6 only?
On Tue, Jan 30, 2024 at 12:20:41PM +0100, Sebastian Hahn wrote: > Hi Nico, > > > On 30. Jan 2024, at 10:32, Nico Schottelius via Bird-users > > wrote: > > OSPFv3 works fine on IPv6 and when creating two instances, one for IPv6 > > one for IPv4, things look correct. But how does OSFPv3 conceptually work > > if the interface of the ospf area do not have IPv4 addresses themselves? > > > > In the BGP case we can use "extended next hop on;" to use the IPv6 > > nexthop for IPv4, but I did not find a similar setting for OSPF to > > accept IPv6 nexthops for IGP IPv4 addresses. > > > > Is there a way to purely go IPv6 only and still relay stub network IPv4 > > information via an IPv6 only internal area? > > I was facing the same issue before, and unfortunately, RFC 5838 > explicitly forbids IPv4 over IPv6 for OSPF. Well, we could add 'extended next hop' option to override it, even if it would be non-standard. It is rather small deviation. I also thought about 'integrated-OSPFv3', where both IPv4 and IPv6 ranges are propagated in one instance, but that seems like much larger deviation. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Re: Question about MPLS L3VPN
On Sat, Jan 27, 2024 at 02:59:57PM +0100, Ondrej Zajicek wrote:
> On Sat, Jan 27, 2024 at 01:42:57PM +0100, Marcel Menzel via Bird-users wrote:
> > Hello List,
> >
> > I am doing a test setup with the new MPLS L3VPN feature (for background
> > information: I am running IPsec with L2TP on top, with OSPF as IGP and iBGP
> > between loopbacks)
> > with one router receiving an IPv6 fulltable via eBGP and the other one
> > establishing the BGP session through a tunnel described above, and I noticed
> > periodic high CPU usage on the router receiving the routes at the end of the
> > tunnel.
> >
> > It seems, that BIRD keeps exporting the whole table to the kernel every 30
> > seconds, as it is configured in the kernel protocol scan time with the "vrf"
> > directive set:
>
> Hello
>
> It is possible that BIRD exports some route but receives back from kernel
> something slightly different than it expected, so it will try to re-send
> it during the scan.
>
> ... and i just noticed that the bug manifests even in my test case, so
> i will check it.
Fixed:
https://gitlab.nic.cz/labs/bird/-/commit/f40e2bc270d3635be518ae80251ce0b5c519c6f4
You can try attached patch.
--
Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
"To err is human -- to blame it on a computer is even more so."
commit f40e2bc270d3635be518ae80251ce0b5c519c6f4
Author: Ondrej Zajicek
Date: Sat Jan 27 17:38:06 2024 +0100
Nest: Fix bug in recursive routes with MPLS-labeled nexthops
When a recursive route with MPLS-labeled nexthop was exported to kernel
and read back, the nexthop_same() failed due to different labels_orig
field and kernel protocol reinstalled it unnecessarily.
For comparing hext hops, route cache has to distinguish ones with
different labels_orig, but KRT has to ignore that, so we need two
nexthop compare functions.
Thanks to Marcel Menzel for the bugreport.
diff --git a/nest/route.h b/nest/route.h
index d26a4b8c..e6f6c64a 100644
--- a/nest/route.h
+++ b/nest/route.h
@@ -694,6 +694,9 @@ static inline size_t nexthop_size(const struct nexthop *nh)
int nexthop__same(struct nexthop *x, struct nexthop *y); /* Compare multipath nexthops */
static inline int nexthop_same(struct nexthop *x, struct nexthop *y)
{ return (x == y) || nexthop__same(x, y); }
+int nexthop_equal_(struct nexthop *x, struct nexthop *y); /* Compare multipath nexthops, ignore labels_orig */
+static inline int nexthop_equal(struct nexthop *x, struct nexthop *y)
+{ return (x == y) || nexthop_equal_(x, y); }
struct nexthop *nexthop_merge(struct nexthop *x, struct nexthop *y, int rx, int ry, int max, linpool *lp);
struct nexthop *nexthop_sort(struct nexthop *x);
static inline void nexthop_link(struct rta *a, const struct nexthop *from)
diff --git a/nest/rt-attr.c b/nest/rt-attr.c
index 7f3645ee..af864bdf 100644
--- a/nest/rt-attr.c
+++ b/nest/rt-attr.c
@@ -185,20 +185,40 @@ nexthop_hash(struct nexthop *x)
return h;
}
+static inline int
+nexthop_equal_1(struct nexthop *x, struct nexthop *y)
+{
+ if (!ipa_equal(x->gw, y->gw) || (x->iface != y->iface) ||
+ (x->flags != y->flags) || (x->weight != y->weight) ||
+ (x->labels != y->labels))
+return 0;
+
+ for (int i = 0; i < x->labels; i++)
+if (x->label[i] != y->label[i])
+ return 0;
+
+ return 1;
+}
+
int
-nexthop__same(struct nexthop *x, struct nexthop *y)
+nexthop_equal_(struct nexthop *x, struct nexthop *y)
{
+ /* Like nexthop_same(), but ignores difference between local labels and labels from hostentry */
+
for (; x && y; x = x->next, y = y->next)
- {
-if (!ipa_equal(x->gw, y->gw) || (x->iface != y->iface) ||
- (x->flags != y->flags) || (x->weight != y->weight) ||
- (x->labels_orig != y->labels_orig) || (x->labels != y->labels))
+if (!nexthop_equal_1(x, y))
return 0;
-for (int i = 0; i < x->labels; i++)
- if (x->label[i] != y->label[i])
- return 0;
- }
+ return x == y;
+}
+
+int
+nexthop__same(struct nexthop *x, struct nexthop *y)
+{
+ for (; x && y; x = x->next, y = y->next)
+if (!nexthop_equal_1(x, y) ||
+ (x->labels_orig != y->labels_orig))
+ return 0;
return x == y;
}
diff --git a/sysdep/unix/krt.c b/sysdep/unix/krt.c
index 3a4b24dc..7a078fb9 100644
--- a/sysdep/unix/krt.c
+++ b/sysdep/unix/krt.c
@@ -619,7 +619,7 @@ krt_same_dest(rte *k, rte *e)
return 0;
if (ka->dest == RTD_UNICAST)
-return nexthop_same(&(ka->nh), &(ea->nh));
+return nexthop_equal(&(ka->nh), &(ea->nh));
return 1;
}
Re: Question about MPLS L3VPN
On Sat, Jan 27, 2024 at 01:42:57PM +0100, Marcel Menzel via Bird-users wrote: > Hello List, > > I am doing a test setup with the new MPLS L3VPN feature (for background > information: I am running IPsec with L2TP on top, with OSPF as IGP and iBGP > between loopbacks) > with one router receiving an IPv6 fulltable via eBGP and the other one > establishing the BGP session through a tunnel described above, and I noticed > periodic high CPU usage on the router receiving the routes at the end of the > tunnel. > > It seems, that BIRD keeps exporting the whole table to the kernel every 30 > seconds, as it is configured in the kernel protocol scan time with the "vrf" > directive set: Hello It is possible that BIRD exports some route but receives back from kernel something slightly different than it expected, so it will try to re-send it during the scan. If you enable 'debug all' on the kernel protocol (both global and in VRF), you can see: 2024-01-27 14:53:50.313 kernel1v6: 2001:db8:1:2::/64: seen or: 2024-01-27 14:53:50.313 kernel2v6: 2001:db8:1:2::/64: updating ... and i just noticed that the bug manifests even in my test case, so i will check it. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Re: Re : Re: BIRD at CSNOG and NANOG
> Le mer. 24 janv. 2024 à 11:54, Benoit Chesneau > <[beno...@enki-multimedia.eu](mailto:Le mer. 24 janv. 2024 à 11:54, Benoit > Chesneau < a écrit : > > > this is pretty cool. Will it works on freebsd as well? On Wed, Jan 24, 2024 at 10:55:36AM +, Benoit Chesneau wrote: > disregard . I misread the first slide :) Well, the first slide was about BIRD in general. Most of the MPLS and EVPN code is protocol independent, but the OS-specific code uses Netlink and assumes Linux. And some implicit assumtions from Linux probably leak also into the OS-independent code. I have no idea how bridging or VXLANs works on BSD. There is the new BSD netlink API, not sure if it covers also this features. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Re: BIRD at CSNOG and NANOG
> > On Jan 16, 2024, at 20:02, Pim van Pelt via Bird-users > > wrote: > > > > Hoi Maria, > > > > Thanks for the headsup! I have been anticipating learning more about the > > MPLS plans (particularly now that we have Linux CP implementation of MPLS > > P/PE). I'd love to learn more, even if my Czech isn't fabulous :) > > Ondrej - if there's a presentation or other artefact with details that you > > can share after your talk, perhaps I can use some Czech friends, or > > Generative AI to translate it and learn about these upcoming capabilities! > > I’d be interested in the same material as well, but for the EVPN part ;) Hi, here are slides (attached), they are in english. The talk was in czech, there is/will be video recording public somewhere (AFAIK), but most info are in slides, although just in basic points. If you have any questions, feel free to ask. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) "To err is human -- to blame it on a computer is even more so." slides-csnog2024-ozajicek.pdf Description: Adobe PDF document
Re: BGP Peering shuts down with "add paths tx;"
On Tue, Jan 09, 2024 at 05:10:49PM +0100, Tim Weippert via Bird-users wrote: > > Hi All, > > i try to activate "add paths tx;" from my Bird2 (2.0.12) Routeserver to a > Cisco IOS-XR Systems (7.9.2), after i add > the config on Bird side, the IOS-XR shuts down the peering: > > %ROUTING-BGP-3-MALFORM_UPDATE : Malformed UPDATE message received from > neighbor (VRF: INTERNET) - message length 160 bytes, error flags > 0x0008, action taken "Reset". Error details: "Error 0x0008, Field > "MP_REACH-NLRI", Attribute 14 (Flags 0x00, Length 0), Data [6d]". NLRIs: > [IPv4 Unicast] > %ROUTING-BGP-5-ADJCHANGE : neighbor Down - BGP Notification sent, > illegal network (VRF: INTERNET) (AS: 65000) > ... > > Does this means, that bird doesn't add the path-id as expected? > Is there some known caveouts around? Hi Well, it should work as expected. Can you establish a session without sending anything (to not trigger the bug) and send the output of 'show protocols all'? Or perhaps make a tcpdump/pcap of such session with updates? -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Re: Direct vs kernel 'learn all'
On Sat, Jan 06, 2024 at 10:48:54AM +, Chris Webb wrote: > Very happy long-term bird user here - thanks for a great routing daemon! > > In the changelog for 2.14, I noticed > > > https://gitlab.nic.cz/labs/bird/-/commit/e83beb70bd14923cece5b35411606ade6fb8fbee > > which introduces 'learn all' for the kernel protocol, allowing device routes > to be imported as with the direct protocol. > > Is there any reason/situation to prefer either the direct protocol or 'learn > all' on the v4/v6 kernel protocol? > > If not, is your intention that direct be retired in favour of kernel 'learn > all' eventually? That is a good point. we do not have any explicit intention with that, but it makes more sense to use ones learned from the kernel protocol, as they are more likely to be consistent with the kernel routing table. Although they have bad (too low) preference. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Re: Inject default route via OSPF, but only to specific OSPF peer and contingent on BGP session established
On Wed, Jan 10, 2024 at 10:02:49AM +0100, Lukas Haase via Bird-users wrote: > Hi Maria, > > Thank you for respecting. First of all, sorry for my duplicate message. (My > browser crashed and I did not realize the email was sent) > > > Gesendet: Mittwoch, den 10.01.2024 um 08:52 Uhr > > Von: "Maria Matejka via Bird-users" > > An: bird-users@network.cz > > Betreff: Re: Inject default route via OSPF, but only to specific OSPF peer > > and contingent on BGP session established > > > > Hello! > > > > TL;DR: That's currently not possible. But there are other options. > > To me, my setup sounds like the most common, most normal configuration one > could imagine. The fact that this sounds so troubling makes me think: Am I > doing something conceptually wrong? > > How would one implement my scenario? In general, OSPF supposes that all routers in one area have the same set of routes / network destinations, they are not announced to some specific router, but to everybody in the area. You wrote: > Both border gateways act as default gateways for the internal router. > In order to create redundancy, each border gateway should send the > default route via OSPF to the internal router. However, the default route > should not be sent to any other device (otherwise it would mess up > everything, incl tunnels). The other devices do not have a default route? Or use one from the internal router? You could probably have separate area for gateways and internal router, and another area (perhaps stub / NSSA) for one with other devices, or just use IBGP as you suggested. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Re: bird and on-interface p2p routes
On Thu, Jan 11, 2024 at 02:13:11PM +0500, Eugene M. Zheganin wrote: > Hello, > > On 11.01.2024 13:29, Alexander Zubkov wrote: > > You mean exporting to the kernel? You can alter the routes in input > > filters. Or pipe routes to another table, altering them in the pipe export > > filter, and then export to the kernel from that other table. > > > Nope, I need quite the opposite - I need to redistribute these into the > OSPF; they are already present in the KRT. As far as I can see, bird just > totally ignores these. Yes, if you get 'strange next-hop' log message, then such route is rejected during parsing of netlink sockets, so it cannot be changed by filters. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Re: ripng on sit tunnel interface
On Thu, Jan 11, 2024 at 06:35:42PM +0500, Ivan wrote: > Hello. > I am using bird 1.6 on Linux. > If I run the ripng protocol on the sit tunnel interface, until an IPv6 > LinkLocal address is assigned to the interface, the ripng protocol does not > start (does not receive or send messages). Even if a static unicast IPv6 > address is assigned to the sit interface. > > Can ripng in bird 1.6 implementation use an interface with static unicast > address but without LinkLocal ? Hello No, BIRD requires link-local IPv6 address on both sides for RIPng - it is not active on ifaces without link-local address, and it ignores RIP packets with source address that is not link local. This is required by RIPng RFC (RFC 2080). -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Re: Filters for decentralised networking
On Tue, Dec 26, 2023 at 06:32:22PM +0100, Nico Schottelius via Bird-users wrote: > > Hello everyone, > > I was wondering how you typically handle announcing > a decentralised infrastructure to its upstreams / the Internet and how > you handle receiving your own routes again on other upstreams. > > The scenario is as follows: > > CUSTOMER > PEERINGS 1 -- AS P6 --- CUSTOMER PEERINGS 2 > |/ > | / > AS P5 AS P10 --- UPSTREAM 1 > | \ / \ > | AS P7---\ \ > | AS P15 --- UPSTREAM 2 >\ UPSTREAM 3 >\ UPSTREAM 4 > > > So essentialy the different AS are somewhat connected internally (*) (not > full mesh due to physical constraints) and the objective is to > announce all internal and all customer peerings to all upstreams. Hello So i understand that AS P5 - AS P15 are different ASNs, but under common administrative control, and one of issues is that different AS path lengths conflicts with optimal path based on real topology? In that case i would suggest to use AIGP (RFC 7311), if you keep IGPs separate in each AS. To handle customer routes, i would just mark them with custom community on ingress to distinguish from other routes (e.g. for the purpose of propagation to upstreams). And another custom community for upstream routes (with similar behavior to OTC, RFC 9234). Of course, these communities must be filtered out on all ingresses before proper one is assigned. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Re: logging via udp
On Wed, Dec 13, 2023 at 02:59:47PM +0100, Alexander Zubkov wrote: > > > And could you, please, also explain another moment: > > > https://gitlab.nic.cz/labs/bird/-/commit/2c7555cf2ac8439713dd9148b348128c57222a38#bc490dc797778621d2345fabe1fb0b59fce18264_141_179 > > > Here your free the sk resource. Maybe this is done exactly because of > > > the io loop list, but I cannot find how sk_free() would remove the > > > socket from sock_list. It seems to me it would still refer the socket > > > after it is freed. > > > > sk_free() calls rem_node(>n) for non-SKF_THREAD sockets, so it would > > remove it from sock_list anyway. > > As it is SKF_THREAD, it is not relevant yet. But I see here fd is set > to -1 before rfree(): > https://gitlab.nic.cz/labs/bird/-/commit/2c7555cf2ac8439713dd9148b348128c57222a38#bc490dc797778621d2345fabe1fb0b59fce18264_141_179 > And sk_free() will not call rem_node() in this case: > https://gitlab.nic.cz/labs/bird/-/blob/2c7555cf2ac8439713dd9148b348128c57222a38/sysdep/unix/io.c#L834 > I worry it can lead to a hidden error in the future. You are right, it would be better to have some sk invalidationg function that would set fd to -1 and unlink it, instead of doing that manually. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Re: logging via udp
On Wed, Dec 13, 2023 at 11:50:42AM +0100, Alexander Zubkov wrote: > Hi, > > Thanks! I looked throught your version and it is unclear to me if the > sk is still added to the io loop list (sock_list) or not. It seems > that sk_insert() still should be called on log udp socket, because I > see no exception for it. Hi I use SKF_THREAD (like in your patch), so it is not inserted intoo sock_list. > And could you, please, also explain another moment: > https://gitlab.nic.cz/labs/bird/-/commit/2c7555cf2ac8439713dd9148b348128c57222a38#bc490dc797778621d2345fabe1fb0b59fce18264_141_179 > Here your free the sk resource. Maybe this is done exactly because of > the io loop list, but I cannot find how sk_free() would remove the > socket from sock_list. It seems to me it would still refer the socket > after it is freed. sk_free() calls rem_node(>n) for non-SKF_THREAD sockets, so it would remove it from sock_list anyway. The socket structure is freed because it is no longer needed, as the fd is tracked by the rfile structure anyway. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Re: logging via udp
On Sun, Jan 02, 2022 at 04:58:33PM +0100, Alexander Zubkov wrote:
> Updated my last patch. I found a problem with that version, it hang on
> reconfigure sometimes. It turned out that birdsocks are added to the
> loop poll and it caused problems. Fixed that with SKF_THREAD flag, but
> that may be a bit tricky. Also found myself that there is already a
> structure for log config. And I also now do not abuse sk_write()
> function for this patch, because it may be not suitable for that.
Hi
Finally got to merge that patch. :-)
Replaced the unformatted output with RFC 3164 syslog format, so it is
properly parsed by rsyslog (and hopefully others), also made some
cleanups, restructuring and bugfixes.
https://gitlab.nic.cz/labs/bird/-/commit/2c7555cf2ac8439713dd9148b348128c57222a38
> On Sun, Jan 2, 2022 at 2:35 PM Alexander Zubkov wrote:
> >
> > Hi,
> >
> > Is there reason agains adding udp log destination in bird? I have in
> > attachmealsont a reworked version of the patch.
> > This version does not use direct socket interface, but extends
> > birdsock API for its needs. It also should not call (and possibly
> > block) getaddrinfo() in case when plain IP is specified.
> > It is a bit hacky - it uses birdsock to bind and connect the socket,
> > then "steals" its file descriptor for rfile. But it shoud close
> > correctly as I understand.
> > And I'm not sure about my implementation using "log_udp_cfg" variable
> > in the parser to gather configuration. Maybe it is not "safe" and it
> > should not be global, but some space in pool should be allocated for
> > it each time.
> > There are other decisions, I'm not sure about. So if anything is bad -
> > I can try to update it.
> >
> > On Wed, Dec 18, 2019 at 8:15 PM Alexander Zubkov wrote:
> > >
> > > Hi,
> > >
> > > On Wed, Dec 18, 2019 at 1:01 PM Ondrej Zajicek
> > > wrote:
> > > >
> > > > On Wed, Dec 18, 2019 at 09:14:43AM +0100, Alexander Zubkov wrote:
> > > > > Hello,
> > > > >
> > > > > Made some dirty patch for myself to allow bird to send logs via udp.
> > > > > But it may be useful not only for me, so posting it here. It could be
> > > > > useful when server experiencing high IO-load. As syslog and file
> > > > > operations in bird are blocking, it can be blocked on writing to it
> > > > > for indefinite time, which could lead to various problems like
> > > > > protocol timeouts. So udp logging comes in handy here. The tradeoff is
> > > > > that we can miss some logs if they are not processed in time.
> > > > > You can specify udp log destination like that:
> > > > > log udp [host IP|"hostname"] [port NUMBER|"portname"] ...
> > > >
> > > > Hello
> > > >
> > > > Is this compatible with some standard for UDP logging or with other
> > > > infrastructure (log deamons), or you just collect it using netcat?
> > >
> > > Not sure if it is standard now. And message format could be relatively
> > > easily converted into one. That is one of the reasons the patch is
> > > dirty. :)
> > > From my experience syslog servers are mostly ok with non formatted
> > > plain text udp messages with some issues, which are more or less
> > > severe depending on what you do with these logs later. For example
> > > just tested couple of them:
> > >
> > > * syslog-ng with simple source config:
> > >
> > > source s_net { network(ip(127.0.0.1) transport(udp) port(514)); };
> > >
> > > It most cases it takes the message from packet, prepends it with
> > > timestamp and hostname (ip) from which the packet was received. There
> > > are several options of how to parse messages, though. I get logs like
> > > those with syslog-ng:
> > >
> > > Dec 18 21:16:51 127.0.0.1 2019-12-18 21:16:51.773 Reconfigured
> > > Dec 18 21:17:09 127.0.0.1 2019-12-18 21:17:09.090 Reconfiguring
> > > Dec 18 21:17:09 127.0.0.1 2019-12-18 21:17:09.090 Reconfigured
> > >
> > > * rsyslog with simple udp config:
> > >
> > > module(load="imudp")
> > > input(type="imudp" address="127.0.0.1" port="514")
> > >
> > > It is also mostly ok with plaintext messages, it prepends them with
> > > timestamp, but it tries to parse first field of the message as a
> > > hostname. I get logs like those with rsyslog:
> > >
> > > Dec 18 21:51:27 2019-12-18 21: 51:27.917 Started
> > > Dec 18 21:51:41 2019-12-18 21: 51:41.273 Reconfiguring
> > >
> > > There can also be issues with message splitting. If message is cut
> > > into two packets or several messages are there in one packet. This
> > > should be also taken into consideration when we look at the resulting
--
Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
"To err is human -- to blame it on a computer is even more so."
Re: dump size in bgp_log_error()
On Fri, Dec 01, 2023 at 11:17:50AM +0100, Marco d'Itri wrote: > bgp_log_error() in proto/bgp/packets.c attempts to dump the message > received from the neighbor, in this case containing the BGP attribute > considered invalid: > > bird[681]: PEERNAME: Received: Malformed AS_PATH: > 40021a02061b1b8b0e8b > > but the hex dump is limited to 16 characters and this makes impossible > to know exactly what the neighbor is complaining about: > > if (len > 16) > len = 16; > > It makes sense to limit the size of log messages, but please make the > limit much higher because I am sure that we can all spare the space. Hi You are right, 16 is too low. Will fix that. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Re: Understanding bird2's behavior
On Thu, Dec 07, 2023 at 12:29:04PM +0100, Antonios Chariton (daknob) via Bird-users wrote: > Hello everyone, > > I have a Debian router that’s running bird2 off of the Debian repo > (2.0.12-7). This also occurred on 2.0.7-4.1. > > It is using only BGP, with 9 IPv4 + 9 IPv6 peers. It’s in a private > environment with < 100 routes on the RIB. > > When I’m running “show route table master6” (happens on v4 too), I see some > normal routes, e.g.: > > 2a0d:3dc0:500::216:50/128 unicast [peer1_v6 2023-12-02] * (100) [AS65000i] > via 2a0d:3dc0:501::a1 on if4 > > But I also see some routes that have a “!” Instead of the “*”: > > 2a0d:3dc0:500::216:48/128 unicast [peer1_v6 2023-12-06] ! (100) [AS65000i] > via 2a0d:3dc0:501::a1 on if4 > > I couldn’t find exactly what “!” means in the docs, and some quick searching > in the git repo wasn’t successful either, but I probably missed something. > I’d expect it to mean unreachable, invalid, or something similar. Hello It means that kernel sync failed for that route. Don't you have some error messages in logs? -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Re: [PATCH] OSPF: on PtP ospf_iface with physical PtP links, skip next-hop resolving
On Fri, Nov 10, 2023 at 01:43:02PM +0100, Maximilian Wilhelm wrote: > Hi, > > Anno domini 2023 Ondrej Zajicek scripsit: > > [...] > > I hope it does not break some multipoint tunnels like Wireguard, they > > often have bad flags reported by kernel, but they should be configured as > > PtMP anyways. > > I disagree on the PtMP part. > > I've deliberately set up a bunch of Wireguard tunnels, which by design > are PTP, as in, there are only ever two peers. I know that Wireguard > *can* handles PTMP, however having to enforce this in bird config > would be weird to me. Hi I see that my comment was ambiguous, it should be 'those Wireguard tunnels that are multipoint should be configured as OSPF PtMP anyways.' PTP Wireguard tunnels should work with OSPF PTP, of course. My point was that even those Wireguard tunnels that are PtMP have flags saying they are PtP: wg0: -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@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."
Re: [PATCH] OSPF: on PtP ospf_iface with physical PtP links, skip next-hop resolving
Hi Thanks, merged. I hope it does not break some multipoint tunnels like Wireguard, they often have bad flags reported by kernel, but they should be configured as PtMP anyways. I wonder what use case is fixed by this patch, as the iface still needs an IP address just to be considered in ospf_ifa_notifyX(). -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@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."
Re: [RESEND PATCH v3] Babel: allow choosing link quality estimation algorithm
On Thu, Nov 09, 2023 at 11:25:10AM +0100, Toke Høiland-Jørgensen via Bird-users wrote: > Nick Cao via Bird-users writes: > > Sorry for missing this earlier, but it looks like with your patch bird > will no longer honour the "wires" or "wireless" setting at all? Which > will break old configs, so please don't do that. > > The right way to do this is to have "wired" and "wireless" serve as > "presets", and then have the link quality override that setting. So that > just setting "wireless" will get the same settings as today, but setting > "wired + etx" will get you just the ETX setting. Agreed. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@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."
Re: Babel RTT mechanism [Was: [RESEND PATCH v3] Babel: allow choosing link quality estimation] algorithm]
On Wed, Nov 08, 2023 at 11:56:32AM -0500, Nick Cao wrote: > I think it is the intended design. Link quality is about packet losses, > while RTT is about, well, RTT, they cover different characteristics of the > link, which should all be taken into account for metric calculation. RTT has two sources, propagation delay (which is just a question of distance) and queuing/retransmission/MAC delay (which depends on link quality). On wifi with worsening link quality / congestion it starts with raising RTT (due to MAC delay and L2 retransmissions) and fluently continues with raising packet loss, so i would say that both packet loss and RTT are parameters of link quality and should be handled together by one mechanism, instead of two independent mechanisms. > And babeld the reference implementation also allows enabling link quality > estimation and the RTT extension at the same time, matching the current > behavior of bird. I agree that it make sense to handle both packet loss and RTT information for purposes of metric estimation. I just do not think it makes sense to estimate two separate metrics and then sum it. Considering that ETX estimates number of retransmissions, then for algorithm that takes into account both RTT and packet loss it makes more sense to have RTT metric multiplied by ETX coeficient? > On 11/8/23 11:44, Ondrej Zajicek wrote: > > On Sat, Oct 28, 2023 at 09:24:56PM -0400, Nick Cao via Bird-users wrote: > > > Resend of the patch in > > > http://trubka.network.cz/pipermail/bird-users/2023-June/017058.html > > > > > > ETX link quality estimation algorithm is useful for link types other than > > > wireless, > > > especially when using babel with tunnels where packet losses do occur. > > > > Hi > > > > I looked at your patch with intent of merging it, i like a separate > > option for selection of dynamic metric algorithm, but i noticed that i > > misunderstood how recently added RTT mechanism interacts with the rest. > > > > I thought we have three alternative link quality / metric estimation > > algorithms: > > > > - fixed (k-out-of-j) > > - ETX > > - RTT > > > > But in fact RTT is independent metric, which is added on top of fixed/ETX > > metric. > > > > Is this intentional? Does it make sense? > > > > (This is mainly a question for Toke or Juliusz) > > -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@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."
Babel RTT mechanism [Was: [RESEND PATCH v3] Babel: allow choosing link quality estimation] algorithm]
On Sat, Oct 28, 2023 at 09:24:56PM -0400, Nick Cao via Bird-users wrote: > Resend of the patch in > http://trubka.network.cz/pipermail/bird-users/2023-June/017058.html > > ETX link quality estimation algorithm is useful for link types other than > wireless, > especially when using babel with tunnels where packet losses do occur. Hi I looked at your patch with intent of merging it, i like a separate option for selection of dynamic metric algorithm, but i noticed that i misunderstood how recently added RTT mechanism interacts with the rest. I thought we have three alternative link quality / metric estimation algorithms: - fixed (k-out-of-j) - ETX - RTT But in fact RTT is independent metric, which is added on top of fixed/ETX metric. Is this intentional? Does it make sense? (This is mainly a question for Toke or Juliusz) -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@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."
Re: BIRD meetup on Tue [not Thu] 07 Nov 2023, Prague, 19:00
Hi Fixed day of week in the subject. On Sat, Nov 04, 2023 at 11:14:58AM +0100, Maria Matejka via Bird-users wrote: > … we decided on Tuesday evening, beginning around 19:00, in some pub nearby. > The exact location is still TBD. ICS attached. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@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."
Re: Use bgp_aigp instead of bgp_med to select the optimal route based on delay
On Mon, Oct 09, 2023 at 11:29:33PM +0800, Brandon Zhi wrote: > Hi all, > > I plan to use bgp_aigp instead of bgp_med to find the optimal route based > on incremental pings per node. For example, if the delay between one node > and another node is 40, then bgp_aigp increases by 40 after passing this > ibgp. > > void bgp_aigp [O] > This attribute contains accumulated IGP metric, which is a total > distance to the destination through multiple autonomous systems. > Currently, the attribute is not accessible from filters. > > But it seems I can't modify this value? Hi You cannot modify bgp_aigp - total distance, but you can modify per-hop distance, which is added to it automatically in each (inter-AS) step. It is either regular IGP metric (e.g. the attribute 'ospf_metric1' in case of OSPF), or manually configured one (the attribute 'igp_metric'), or configured cost of inter-AS link [0]. [0] https://bird.network.cz/?get_doc=20=bird-6.html#bgp-cost I think that using bgp_aigp is the right tool for your use case, but details depend on specific topology of your confederation - whether each internal AS in the confederation is nontrivial network with IGP, flat network, or just one router. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@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."
Re: BIRD 2.14
On Sun, Oct 08, 2023 at 11:47:42PM +0200, Robert Scheck wrote: > > >>Or you can try to revert commit d61505b039bf0aa6697e28b2a4e07907c89ba1fb. > > >>I > > >>can't guarantee it working out of the box, though. > > >Or rather f8bcb037b5b71a19209f1b63d52895c8c34c675b > > > > Oh sorry, messed up two commits from the same person, mea culpa. You're > > right, disregard my hash, please. > > https://gitlab.nic.cz/labs/bird/-/commit/f8bcb037b5b71a19209f1b63d52895c8c34c675b > let's the build succeed. As there is no MPLS support in CentOS/RHEL 7...do > you treat reverting this commit only for this build target as very risky or > problematic (without an in-depth analysis, just from your feeling)? Reverting this patch for CentOS is safe. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@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."
Re: kernel: does not learn routes with RTPROT_KERNEL
On Tue, Aug 29, 2023 at 04:16:16PM +0200, Pavel Šorejs via Bird-users wrote: > Here it is > > On 8/29/23 14:02, Ondrej Zajicek wrote: > > On Thu, Aug 24, 2023 at 01:38:12AM +0200, Pavel Šorejs via Bird-users wrote: > > > Here is first version - based on master > > Hi > > > > Seems like your patch is mangled (likely lines wrapped by e-mail client). > > Could you send it as an attachment? Hi Merged and included in the v2.14 -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@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."
Re: BIRD 2.14
On Sun, Oct 08, 2023 at 10:18:24PM +0200, Maria Matejka via Bird-users wrote:
> Hello Robert,
>
> On 2023-10-08 21:40, Robert Scheck wrote:
> > Unfortunately, building BIRD 2.14 on CentOS/RHEL 7 fails like this:
> >
> > > sysdep/linux/netlink.c: In function 'rta_get_via':
> > > sysdep/linux/netlink.c:499:11: error: dereferencing pointer to incomplete
> > > type 'struct rtvia'
> > > switch(v->rtvia_family) {
> > > ^~
> > While I assume that the kernel in CentOS/RHEL 7 is simply too old to
> > support the desired functionality in BIRD, is at least possible to have
> > the change #ifdef'ed (or so), that it builds without the new feature?
>
> Sorry, support for CentOS / RHEL 7 has been discontinued due to a too old
> kernel version and backwards-incompatible Netlink changes. I think the
> easiest way would be to add a dependency on a newer kernel, e.g. kernel-lt
> which is now afaik 5.4 (supported).
>
> Or you can try to revert commit d61505b039bf0aa6697e28b2a4e07907c89ba1fb. I
> can't guarantee it working out of the box, though.
Or rather f8bcb037b5b71a19209f1b63d52895c8c34c675b
--
Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santi...@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."
Re: bird rip question
On Fri, Oct 06, 2023 at 04:05:28PM +0200, Miklós Máté wrote: > Hi, > > I'm trying to set up BIRD to demonstrate RIP in a Mininet environment, but > it doesn't seem to work. I'm using the attached configs. The OSPF one works > properly, but with RIP it only sends a Request message on startup, and then > nothing. According to the log the Request is received properly, but no > Response is sent, and the periodic timer doesn't do anything either. Hi With RIP and other vector distance protocols, you need to provide local direct routes using Direct protocol (they are not learned from Kernel protocol). See this: https://gitlab.nic.cz/labs/bird-tools/-/blob/master/netlab/cf-rip-base/README.md https://gitlab.nic.cz/labs/bird-tools/-/blob/master/netlab/cf-rip-base/bird_m1.conf -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@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."
Re: Doing something wrong with VRF's
On Thu, Sep 28, 2023 at 07:07:03PM +0200, Daniel Gröber wrote: > On Thu, Sep 28, 2023 at 04:03:33PM +, Nigel Kukard via Bird-users wrote: > > Well .. I feel embarrassed now. The issue was a missing "kernel table ;" > > in the kernel protocol. Hi Well, i feel embarrassed that BIRD requires you to specify that. It would make more sense if the kernel protocol used the proper value from VRF automatically. > Don't feel bad. I was going to look into using VRFs with bird and now > there's a nice worked example ready to play with at in my inbox :) There is also an example from our tests: https://gitlab.nic.cz/labs/bird-tools/-/blob/master/netlab/cf-ospf-vrf/README.md https://gitlab.nic.cz/labs/bird-tools/-/blob/master/netlab/cf-ospf-vrf/bird_m1.conf -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@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."
Re: Path Attribute Attack
On Mon, Sep 18, 2023 at 09:41:32AM -0400, Michael Lambert wrote: > As outlined in https://kb.cert.org/vuls/id/347067, there is an attack that > uses specially crafted Path Attributes in a BGP UPDATE message to disrupt > peering sessions. I don’t recall seeing any discussions of this attack on > this list. Is BIRD susceptible? Hi AFAIK it is not. See 'Unimpacted Vendors' in: https://blog.benjojo.co.uk/post/bgp-path-attributes-grave-error-handling -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@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."
Re: BGP best path algorithm in RR environment
On Wed, Sep 13, 2023 at 09:35:26AM +, Mazur, Dariusz via Bird-users wrote: > Hello Bird Users, > Have a question about bgp best path algorithm in Route Refletector > environment and possible fix: > > > Topology ( we use only iBGP with multiply RR): > r01a.tor - r01.leaf.105---r01.spiner01.leaf108-r09a.tor > > I announce the same block 172.232.0.0/19 from both tors > > r01.leaf108 receives 172.232.0.0/19 from r01.spine and r09a.tor, and treat > them as equal path (multipath). > > All BGP attributes are equal except of BGP originator id and cluster-list > > r01.leaf108.ord02.fab> show route for 172.232.0.0/19 all > 172.232.0.0/19 > unicast [192.168.226.56__r01.spine101 > 2023-09-06] * (100) [AS4250527481?] > via 192.168.226.56 on vlan.101 > Type: BGP univ > BGP.origin: Incomplete > BGP.as_path: 4250527481 > BGP.next_hop: 192.168.226.56 > BGP.med: 0 > BGP.local_pref: 400 > BGP.atomic_aggr: > BGP.aggregator: 23.192.121.225 AS4250527481 > BGP.community: (63949,1000) (63949,1002) (63949,1004) > (63949,1005) (65110,31107) (65310,31107) (65518,31107) > BGP.originator_id: 23.205.212.134 > BGP.cluster_list: 23.205.212.8 23.205.212.112 > > unicast [192.168.198.35__r09b.tor108 2023-09-06] (100) > [AS4250827489?] > via 192.168.198.35 on vlan.218 > Type: BGP univ > BGP.origin: Incomplete > BGP.as_path: 4250827489 > BGP.next_hop: 192.168.198.35 > BGP.med: 0 > BGP.local_pref: 400 > BGP.atomic_aggr: > BGP.aggregator: 23.213.15.233 AS4250827489 > BGP.community: (63949,1000) (63949,1002) (63949,1004) > (63949,1005) (65110,31107) (65310,31107) (65518,31107) > > Looks like Bird does not check cluster_list length to determine better > route, is it intentional? Can you suggest any possible fix to prefer route > from r09a.tor using cluster-list or anything what is local for router (local > pref is not option because all routers are in the same asn and use iBGP) Hi BIRD does compare cluster_list, but consistently with RFC 4456 section 9 only after almost all other criteria, including comparison of peer router id / originator id. Unfortunately peer router id is not in the 'show route all' output, but i would guess that the peer router id for the second route is higher than the originator_id of the first route, that is why it is sorted the way it is. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@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."
Re: BGP: connect delay timer vs connect retry timer
On Tue, Aug 29, 2023 at 09:11:27PM +0530, Bala Sajja wrote: > Hi Ondrej, > OK. understood. We can configure connect-retry-interval in the > range 1..65535. We are trying to test this with different values as > pasted below with logs. Things work as expected till the 1..25 seconds > range. After that we always see the connection delay timer getting > triggered, connect retry timer config has no impact. This is really unrelated to connection delay timer. You get this behavior because besides our connect retry timer there is also OS-level timer for TCP connections. If our retry timer is small, it timeouts and we retry the connection. If our timer is large, we get socket error from OS first (that is the log message 'Connection lost (Connection timed out)'), which leads to complete restart of BGP state machine, including going through the initial connection delay time. It is true that we could likely avoid full restart from socket error when we are still in the CONNECT state, and wait for our connect retry timer. First case: > Line 167: Aug 29 14:02:36 bird: bgp_10: Connecting to 10.220.152.55 > from local address 10.220.152.53 > Line 185: Aug 29 14:02:53 bird: bgp_10: Connecting to 10.220.152.55 > from local address 10.220.152.53 > Line 191: Aug 29 14:03:12 bird: bgp_10: Connecting to 10.220.152.55 > from local address 10.220.152.53 > Line 195: Aug 29 14:03:30 bird: bgp_10: Connecting to 10.220.152.55 > from local address 10.220.152.53 > Line 214: Aug 29 14:03:48 bird: bgp_10: Connecting to 10.220.152.55 > from local address 10.220.152.53 Second case: > Line 297: Aug 29 14:05:12 bird: bgp_10: Started > Line 298: Aug 29 14:05:12 bird: bgp_10: Connect delayed by 5 seconds > Line 308: Aug 29 14:05:16 bird: bgp_10: Connecting to 10.220.152.55 > from local address 10.220.152.53 > Line 348: Aug 29 14:05:48 bird: bgp_10: Connection lost (Connection timed out) > Line 349: Aug 29 14:05:48 bird: bgp_10: Connect delayed by 5 seconds > Line 351: Aug 29 14:05:52 bird: bgp_10: Connecting to 10.220.152.55 > from local address 10.220.152.53 > Line 360: Aug 29 14:06:24 bird: bgp_10: Connection lost (Connection timed out) > Line 361: Aug 29 14:06:24 bird: bgp_10: Connect delayed by 5 seconds > Line 363: Aug 29 14:06:28 bird: bgp_10: Connecting to 10.220.152.55 > from local address 10.220.152.53 > Line 384: Aug 29 14:07:00 bird: bgp_10: Connection lost (Connection timed out) -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@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."
Re: Bird is bringing down bgp connection upon receiving Admin Down
On Wed, Aug 09, 2023 at 06:57:29AM +, Sunnat Samadov wrote: > > > > This is the detailed explanation of the previously raised issue. > > > > We are using BIRD https://gitlab.nic.cz/labs/bird/-/tags/v2.0.11. And there > > is an issue with respect to BFD + BGP as described below. > > > > When Peer device ( Cisco ASR router) sends an BFD admin down, Bird is > > bringing down the BGP connection which is using BFD mode ON, which is not > > correct. The expected behavior is upon receiving BFD admin down from peer > > device, Bird should fall back to the Normal BGP mode of working. > > Hi, > > Is there any update on this issue? Hi Just fixed that issue, thanks for the bugreport and sorry for the late answer. https://gitlab.nic.cz/labs/bird/-/commit/aa70e14c9e4cfeb70d2dc9cee497c40057dc105e -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@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."
Re: BGP: connect delay timer vs connect retry timer
On Mon, Aug 28, 2023 at 05:02:40PM +0530, Bala Sajja wrote:
> Hi,
>It seems where BGP connect retry timer to be kicked in use cases
> also, connect delay timer gets kicked in. In the below function,
> though bgp_setup_conn(p, conn) sets connect_timer to connect retry
> timer, later it's over written by bgp_start_timer(conn->connect_timer,
> delay) which sets connect_timer to connect delay timer. Is this right
> ? Could we make the connect retry timer work properly ?
Hi
I am not sure what do you mean. The timer connect_timer is used for two
purposes, for connect_delay_time before we try to connnect (in the state
BS_ACTIVE), and for connect_retry_time while we try to connect (in the
state BS_CONNECT). The first is initialized in bgp_active(), the second
in bgp_connect(). The call bgp_setup_conn(p, conn) just allocates the
timer, but it does not sets it to any interval.
>
> bgp_active(struct bgp_proto *p)
> {
> int delay = MAX(1, p->cf->connect_delay_time);
> struct bgp_conn *conn = >outgoing_conn;
>
> BGP_TRACE(D_EVENTS, "Connect delayed by %d seconds", delay);
> bgp_setup_conn(p, conn);
> bgp_conn_set_state(conn, BS_ACTIVE);
> bgp_start_timer(conn->connect_timer, delay);
> }
--
Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santi...@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."
Re: kernel: does not learn routes with RTPROT_KERNEL
On Thu, Aug 24, 2023 at 01:38:12AM +0200, Pavel Šorejs via Bird-users wrote: > Here is first version - based on master Hi Seems like your patch is mangled (likely lines wrapped by e-mail client). Could you send it as an attachment? -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@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."
Re: [PATCH] adding custom options in radv protocol, strict ipv6 regex
On Fri, Aug 25, 2023 at 04:20:04AM +0200, Alexander Zubkov wrote: > And I forgot to ask about kw_sym. "kw_sym: FROM_HEX" definition is not > needed? To provide fallback for someone using such name in config > already. I plan to add all keywords to kw_sym (through M4 macro) in some followup commit, so no need for manual definition. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@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."
Re: [PATCH] adding custom options in radv protocol, strict ipv6 regex
On Thu, Jul 27, 2023 at 03:38:27PM +0200, Alexander Zubkov wrote: > Hi, > > Have you had a chance to look at all this? Hi Sorry for keeping you wait, i finally got to this patchset and merged it. I did some changes: 1) Removal of support for multiline string literals - the patch is simple but it has an awkward consequence of making incomprehensible error messages for unterminated strings. We discussed that and decided to drop it. 2) Refactor of bstrhextobin() and bstrbintohex() to be more generic and not depend bstrtobyte16(), which was removed. I never liked it anyway. Also, there is an explicit string of allowed delimiters in bstrhextobin(), for from_hex(), instead of ignoring everything that is not a letter. 3) Change val_format() to not add 'hex:' prefix when printing bytestring. It offers human readable, but not necessary back-parsable form (i.e more like Scheme function 'display' than 'write'). That is consistent with its behavior for strings, where quotation marks are also not added. 4) Use different approach for bytestring or string argument for password keys, so the target expression can know which variant was used. For other details, see the commits. Thanks for the patchset. I especially like the cf_eval() / cf_eval_int() changes. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@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."
Re: Bird considers the VRF interface to be outside the VRF
On Tue, Jul 18, 2023 at 12:25:41PM +0200, Erin Shepherd wrote: > Bird only treats the interfaces enslaved to the VRF as part of the VRF, > but not the VRF virtual interface itself. This means that e.g. OSPF won't > pick up loopback addresses defined on the VRF interface itself. You have > to additionally add a dummy interfaces with the IPs attached, which seems > to cause some confusion of its own on the kernel side. > > Ideally the VRF interfaces would be considered to be in the VRF. > > I've attached a patch which fixes this; I don't think the design is quite > right, and its possible I introduced some bugs, but in testing it seems to > work fine Hi Sorry for late answer, i somehow missed/forgot your mail. You are right, VRF interfaces are supposed to be inside respective VRFs. One can see that from e.g. 'local' routes generated by the kernel for IP addresses of VRF ifaces. Your patch was mostly ok, there was just a minor issue that the code of if_in_vrf() you used would consider VRF interfaces both inside and outside VRFs (for protocols that are explicitly bound to 'main' VRF, called as if_in_vrf(x, NULL)). That was surprisingly complicated to fix, as one had to implement parsing interface type in Netlink to tell apart regular and VRF interfaces. The fixed code was merged: https://gitlab.nic.cz/labs/bird/-/commit/e3c0eca95642a846ab65261424a51dd99d954017 -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@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."
Re: [OSPF3 IPv6] error "wrong authentication length" between Proxmox 8 (Debian 12) (bird2 2.13.1) and MikroTik RouterOS 7.11 (stable)
On Sun, Aug 20, 2023 at 08:07:16PM +0200, Chriztoffer (bird-users) wrote: > Hello bird-users list, > > I am seeking input into if anyone can provide suggestions on how to > debug the below described error message. > > Cheers, Chriztoffer > > When trying to establish the OSPFv3 IPv6 connections between the three > nodes. The connection from the two Proxmox nodes to the MikroTik > Router fails with error "wrong authentication length" when logged by > bird2. Hello Thanks for the bugreport and debugging. This seems like a straightforward bug in Mikrotik: RFC 7166 4.1: Auth Data Len This is the length in octets of the Authentication Trailer (AT), including both the 16-octet fixed header and the variable-length message digest. For HMAC SHA-512, variable length is 512/8 = 64, so auth data length should be 16+64 = 80. Seems like the Mikrotik omits the length of fixed header in the field, so they just put 64 there. > From looking at the PCAP I do indeed see the auth-data is not of the > same length. > > ## MikroTik (MAC OUI 4c:5e:0c) > > OSPF Authentication Trailer > Authentication Type: HMAC Cryptographic Authentication (1) > Authentication Data Length: **64** > Reserved: 0x > Security Association Identifier (SA ID): 0x > Cryptographic Sequence Number: 71479 > Authentication Data: > 021d5635eac7b92d28bfad6507bcda7702a5f1e323197be18d42d436dcae998f5ae462da… > > ## Bird 2.13.1 (MAC OUI 70:54:d2) > > OSPF Authentication Trailer > Authentication Type: HMAC Cryptographic Authentication (1) > Authentication Data Length: **80** > Reserved: 0x > Security Association Identifier (SA ID): 0x > Cryptographic Sequence Number: 405 > Authentication Data: > 95c0ecfcd54a50e0da70acbf242181d3f45fce7dd1d8b6ccdb783d96c319c49e0cb77e5e… -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@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."
Re: two AS announce config migration 1.6.6 -> 2.0.12
On Thu, Jul 27, 2023 at 04:39:23AM +0300, nixx wrote: > show route for 192.168.200.100 > and > show route protocol TestMain all > in attachments. > > Has something changed in the work process of the bird, or am I doing > something wrong? Yes, it seems that there is a minor change in interpretation of 'next hop keep' option. In v1.6 it affected both originating and forwarding of the bgp_next_hop attribute, while in v2.0 it affects just forwarding of an existing attribute (as during originating, there is no bgp_next_hop to keep). Therefore TestPeer when originating these routes is used its IP address as bgp_next_hop, it used its IP address as bgp_next_hop, as it is expected for EBGP peer when the original route has gw on different iface. Simple workaround is to set bgp_next_hop manually in TestPeer export filter, e.g.: bgp_next_hop = gw; Also note that in v2, you could simplify the setup by removing TestPeer and just adding ASN 65065 to bgp_path either in static protocol import filter, or in TestMain export filter: bgp_path.prepend(65065); This would not work in v1.6, as there was a different order of processing export filter and internal BGP attribute processing. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@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."
Re: changing bgp_med attributes cause route been filited
On Thu, Jul 20, 2023 at 08:25:24PM +0800, Brandon Zhi wrote: > Hi all, > > I was doing research about selecting the best route on multiple nodes based > on bgp_med attributes. > > > My idea is to add bgp_med value between each node based on ping, and then > bird will select the route which has the lowest bgp_med value (which is the > total ping delay) > > But some routes will be filled, which i don't want it. > > I found that the code " bgp_med = bgp_med + bgp_med_ping + bgp_med_ping;" > will cause some routes to be filtered. > > Can someone tell me why? I only want to modify bgp_med and don't want my > routes to be filtered. Hi Perhaps there are some error in logs about filter failures? I guess that when bgp_med is not defined, then expression 'bgp_med + X' fails. You could try something like: if (defined(bgp_med)) bgp_med = bgp_med + X; else bgp_med = X; And perhaps even better than use bgp_med for this is to use bgp_aigp attribute and associated BGP options (aigp, cost). -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@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."
Re: two AS announce config migration 1.6.6 -> 2.0.12
On Wed, Jul 26, 2023 at 11:00:26PM +0300, nixx wrote: > Hello. > > I need to announce one autonomous system from under another so that the > path "world -> AS65007 -> AS65065" must be visible from the outside world. > I successfully do it on version 1.6.6 (config-file and 'show route' from > live system with changed ip-addresses in attach). Hello That is an interesting question. By usint 'multihop 2' you implicitly changed gateway mode for TestMain from 'direct' to 'recursive', which means that it tries to resolve 192.168.200.100 in the master table. But that is the same for both v1.6 and v2.0. Perhaps there is some detail that you have direct protocol in v1.6 but not in v2.0? What you get from commands: show route for 192.168.200.100 show route protocol TestMain all ? -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@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."
Re: Bird is bringing down bgp connection upon receiving Admin Down
On Wed, Jul 12, 2023 at 09:53:47AM +, Sunnat Samadov wrote: > Hi birds, > > This is the detailed explanation of the previously raised issue. > > > We are using BIRD https://gitlab.nic.cz/labs/bird/-/tags/v2.0.11. And there > is an issue with respect to BFD + BGP as described below. > > When Peer device ( Cisco ASR router) sends an BFD admin down, Bird is > bringing down the BGP connection which is using BFD mode ON, which is not > correct. The expected behavior is upon receiving BFD admin down from peer > device, Bird should fall back to the Normal BGP mode of working. Hi Thanks for the report, i will check that. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@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."
Re: [PATCH] adding custom options in radv protocol, strict ipv6 regex
On Mon, Jun 26, 2023 at 03:24:47AM +0200, Alexander Zubkov wrote:
> On Sat, Jun 24, 2023 at 3:16 PM Ondrej Zajicek wrote:
> >
> > On Sat, Jun 24, 2023 at 02:20:03AM +0200, Alexander Zubkov wrote:
> > > > Yes, the original idea there was to add bytestring as a data type, make
> > > > hex() a regular (filter) function instead of special function-like
> > > > syntax, and add equivalent of 'expr' grammar term for other data types.
> > > >
> > >
> > > I see. I think I can look into preparing a patch for that too.
> > > But for such variant I would suggest using function names like
> > > "from_hex/base64" instead of "hex/base64", or something including
> > > bytestring reference: "bs_hex". Because the simple variants could be
> > > misleading when used not only in the limited set of scopes.
> > > they can be thought of converting to hex/base64 representation too. Or
> > > they
> > > could collide with "hex" function to convert from string to int, which
> > > someone would need to implement in the future.
> >
> > Yes, that is true.
> >
> > You can try it if you are brave enough to add new f_val type.
>
> Take a look at the patch, please. Waiting for the critics and
> improvement suggestions.
Hi
It looks pretty good. First, could you split it to at least four patches?
1) unrelated changes, like the newline-in-string-constant
2) preparatory changes (functions in lib/bytestring.c, change to BYTESTRING
lexer)
3) adding bytestring type to filter code (including FI_FROM_HEX inst)
4) change to parser related to f_eval_val(), bytestring nonterminal and so on.
Some more comments:
> It was needed to add another function like f_eval_int(), so I decided
> to do some more generic approach and replaced all occurences of
> f_eval_int() with it.
That is good approach, although it would be probably better to call this
function like cf_eval(), associated macro as cf_eval_val, and keep some
inline functions like cf_eval_int(), cf_eval_bs() and so on.
Or perhaps cf_eval() could return f_val as return value, and have
shorthand functions like:
static inline cf_eval_int(..) { return cf_eval(.., T_INT).i; }
I will give more comments later.
--
Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santi...@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."
Re: [PATCH] adding custom options in radv protocol, strict ipv6 regex
On Mon, Jun 26, 2023 at 03:01:55AM +0200, Alexander Zubkov wrote: > Attached the patch with the new syntax for custom options and to use > WALK_LIST. Thanks, merged: https://gitlab.nic.cz/labs/bird/-/commit/ccfa48a24aea64d1a844fb97cfe15965197c0908 -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@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."
Re: [PATCH] adding custom options in radv protocol, strict ipv6 regex
On Thu, Jun 15, 2023 at 03:57:10AM +0200, Alexander Zubkov wrote:
> Hi,
>
> While waiting for the fate of the previous patches, I was thinking
> about that thing about using keywords as symbols. So here is another
> longread. :)
>
> Now it is not possible to mix a keyword and a keyword as a symbol
> together. Here is what I mean. With current master bird if I use
> config:
> ...
> protocol device {}
> function role() { int role = 1; return role; }
> template bgp { local role peer; }
Hi
You are right, but note that keywords collide just with top-level symbols
(e.g. protocols, tables, functions, ...), while scoped symbols do not
affect it, e.g, this is okay:
function xyz() { int role = 1; return role; }
template bgp { local role peer; }
While it is inconvenient, it preserves backward compatibility (compared
to the previous approach, where keywords always dominate symbols), as a
configuration valid for an older version of BIRD is valid in a newer
version of BIRD that adds new keywords (the configuration may contain
such names used as symbols, but not as keywords).
> Because "role" is converted to a symbol and it is not possible to use
> it as a keyword anymore. I thought if something can be done about that
> and I probably have a solution. See the attached patch. It maybe not
> the best design, just to show the idea. I change the order of
> detecting symbol and keyword in the lexer, so it always returns a
> keyword for a keyword, and it is converted into a symbol only in the
> parser when it is used as a symbol. As we can hit such symbol keyword
> many times, I check if it has already been defined and create a new
> one if needed. Then I replace mentions of CF_SYM_KNOWN with
> symbol_known, which can be CF_SYM_KNOWN or kw_sym. So, with this patch
> applied, both configs are successfully parsed and work well.
We thought about this approach, but it has issues with conflicts in our
rather irregular grammar. Note that current kw_sym is almost empty,
i originally planned it to contain all keywords (unless explicitly
excluded), and i would likely to do that soon. Even with almost empty
kw_sym, your patch added 2 grammar conflicts. If we add most symbols
to kw_sym, it will cause many conflicts.
OTOH, the current approach accepts kw_sym only in 'symbol' [*], which is
much scarced in grammar, and therefore causes minimum conflicts.
[*] Which is in-fact more like symbol_unknown, but also accepts known
symbols for purpose of redefining them in different scope.
I would prefer to avoid such changes now, as Maria is doing some rework
on symbols and we have some divergence in symbol processing between
master and 3.0 branches.
> Also, I think that the current realization in bird relies on the fact
> that lexer would not have symbols parsed in advance, i.e. that further
> mentions of the keyword should return CF_SYM_KNOWN. But if it is not
> the case and the lexer parses forward for some reason (before the
> parser creates the symbol for the keyword) it would not return
> CF_SYM_KNOWN. I don't know the internals of the lexer and parser much,
> maybe it is impossible situation (parser does not backtrack, etc.).
> And there is no need to worry here.
Yes, it is kind of strange, in long-term, it would make more sense to move all
symbol processing from lexer to parser.
> Some additional notes.
>
> My previous remark regarding the missing "|" in "kw_sym: MIN MAX"
> seems to be correct, because current bird master fails on such config:
Yes that is true. I just added it ad-hoc in order to have some kw_sym
defined in nest/config.Y, so it is not empty when BIRD is compiled
without BGP.
> But if I try to call "eval role()" from cli, I get an error: "runtime
> error", and the daemon logs this:
>
> bird: filters, line 2: Argument 1 of VAR_INIT must be of type int, got type
> void
>
> So it looks like it tries to initialize it with the void value and
> fails to do it. I haven't tracked the source of this bug.
Will look at this.
--
Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santi...@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."
Re: [PATCH] adding custom options in radv protocol, strict ipv6 regex
On Sat, Jun 24, 2023 at 02:03:08AM +0200, Alexander Zubkov wrote:
> On Fri, Jun 23, 2023, 17:47 Ondrej Zajicek wrote:
> > The only objection from me is that 'other type' option name is kind of
> > non-descriptive, does not indicate it is related to RA options (nor it is
> > implicated by context). I do not really have a good idea for alternative,
> > perhaps just 'custom option'? What do you think?
> >
>
> Yes, I was thinking about "custom" too. But it introduces a new keyword. So
> I tried too choose something suitable from available keywords. But if it is
> not a problem, I would prefer "custom" too as more descriptive.
I think 'custom option' would be ok. It has two arguments, thinking about
it, BIRD style would be more like:
custom option type 10 value 12:34:56:78:12:34:56:78:12:34:56:78:12:34:56:78;
instead of just:
custom option 10 12:34:56:78:12:34:56:78:12:34:56:78:12:34:56:78;
> > Could you prepare a patch for documentation?
> >
>
> Sure, just will wait for the final decision about the syntax ("other" vs
> "custom").
okay.
> > BTW, why not to use WALK_LIST() in radv_prepare_custom()?
> > (just noticed in now)
> >
>
> That is a good question. Actually I just used the structure of the similar
> function for the predefined option and didn't thought much about it. Now
> that you pointed that out, I remember that macro from the other parts of
> the code. And it seems reasonable to use it here, and probably in the
> "source" function too. I can prepare a patch for that.
Okay. I see the 'source' funcions has more complex structure (two nested
whiles), so perhaps it does not fit to them.
--
Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santi...@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."
Re: [PATCH] adding custom options in radv protocol, strict ipv6 regex
On Sat, Jun 24, 2023 at 02:20:03AM +0200, Alexander Zubkov wrote:
> > Yes, the original idea there was to add bytestring as a data type, make
> > hex() a regular (filter) function instead of special function-like
> > syntax, and add equivalent of 'expr' grammar term for other data types.
> >
>
> I see. I think I can look into preparing a patch for that too.
> But for such variant I would suggest using function names like
> "from_hex/base64" instead of "hex/base64", or something including
> bytestring reference: "bs_hex". Because the simple variants could be
> misleading when used not only in the limited set of scopes.
> they can be thought of converting to hex/base64 representation too. Or they
> could collide with "hex" function to convert from string to int, which
> someone would need to implement in the future.
Yes, that is true.
You can try it if you are brave enough to add new f_val type.
> > > I think this should be quite good too, the only problem with it
> > > is inability to mix "hex" symbol with hex("...") bytestrings.
> >
> > This is an issue with any keyword, so not a big thing.
> >
>
> Yes. By the way what do you think about the patch that allows using
> keywords and symbols together? Is it viable?
Answered there.
--
Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santi...@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."
Void values in variables (Was: Re: [PATCH] adding custom options in radv protocol, strict ipv6 regex)
On Sat, Jun 24, 2023 at 03:13:11PM +0200, Ondrej Zajicek wrote:
> > But if I try to call "eval role()" from cli, I get an error: "runtime
> > error", and the daemon logs this:
> >
> > bird: filters, line 2: Argument 1 of VAR_INIT must be of type int, got type
> > void
> >
> > So it looks like it tries to initialize it with the void value and
> > fails to do it. I haven't tracked the source of this bug.
Yes, it fails on run-time type check, as VAR_INIT instruction tries to
initialize the variable with T_VOID value. This is not an issue with
old-style variable definitions, as they are not initialized by an
bytecode instruction, they are just memset to zero (i.e. T_VOID) when a
stack frame is created during function call. I did not noticed that in
tests as all my tests use initialization to an explicit value.
Similar issue is here also with old-style variables, which are
pre-initialized with T_VOID:
function fun() int x; int y; { x = y; return x; }
In this case both x and y are initialized to T_VOID, but then the
assignment x = y fails in VAR_SET instruction, as it expects int and
got void from y. This was (unintentionally) introduced in 2.0.8, with
improved typechecking of filters.
The example above is a toy example, but there are realistic examples
with route attributes (which are void when undefined):
int x = bgp_med; # fails with error when bgp_med is undefined
while in older BIRD (pre 2.0.8) an equivalent of:
int x = bgp_med;
if defined(x) then ...
worked.
The handling of undefined value is inconsistent, and i now i remember
that we had this discussion in the past:
https://bird.network.cz/pipermail/bird-users/2018-January/011826.html
--
Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santi...@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."
Re: [PATCH] IPv4 over IPv6 nexthop support on FreeBSD
On Mon, Jun 19, 2023 at 10:32:45AM +0100, Alexander Chernikov wrote:
> > There is a question how handle feature divergence (primarily divergence
> > in which structures and enum values are defined for compile-time) in
> > Netlink between Linux and FreeBSD. I would prefer to not have autoconf
> > test for each such feature. For example we could probably remove
> > HAVE_MPLS_KERNEL altogether just for Linux (as the check is unnecessary
> > for non-obsolete kernels, but i am not sure about FreeBSD headers).
>
> I understand the pain. To add to this, the feature existence doesn’t always
> mean the full feature parity.
> For example, current nexthop/nexthop group implementation doesn’t have the
> support for adding resilient nexthop groups.
>
> The only solution I could think of is adding a bit of ugliness to the headers
> and have the defines for each enum item (for commands) and a separate define
> for the structures / small enums.
> Then the features could be defined in the sysdep//netlink-sys.h .
>
> What do you think?
I think it would be nice.
First, i thought it does not really help considering they are not in
Linux kernel headers and even when added, we would still need to support
older ones, but we can just define them for Linux in sysdep/linux/netlink-sys.h
Strange is that some enums in Linux rtnetlink headers have these
(e.g. RTM_* values), while others do not * (e.g. RTN_* values):
enum {
RTM_BASE= 16,
#define RTM_BASERTM_BASE
RTM_NEWLINK = 16,
#define RTM_NEWLINK RTM_NEWLINK
RTM_DELLINK,
#define RTM_DELLINK RTM_DELLINK
RTM_GETLINK,
#define RTM_GETLINK RTM_GETLINK
RTM_SETLINK,
#define RTM_SETLINK RTM_SETLINK
...
enum {
RTN_UNSPEC,
RTN_UNICAST,/* Gateway or direct route */
RTN_LOCAL, /* Accept locally */
RTN_BROADCAST, /* Accept locally as broadcast,
send as broadcast */
...
(not sure if there is any system in that, or just usual ad-hoc
inconsistencies)
--
Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santi...@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."
Re: [PATCH] adding custom options in radv protocol, strict ipv6 regex
On Wed, Jun 14, 2023 at 12:40:47AM +0200, Alexander Zubkov wrote:
> Hi,
>
> Please look at these patches:
>
> bytestring-hex-prefix.patch - syntax with "hex:" prefix
> I allowed mixed colons with no-divider there, so hex:12:345678:90 is
> allowed. As there is a distinguishing prefix here, this should not be
> a problem.
> Empty bytestrings are allowed too: "hex:"
Hi
Merged:
https://gitlab.nic.cz/labs/bird/-/commit/65d6a525944faa3f77041419991d77106d8f0a0d
I have mixed opinion on mixed colons here :-)
> bytestring-hex-function.patch - function-like hex("...") syntax (on
> top of the other patch)
> It wasn't too complex, but you might have wanted to do it some other
> way.
Yes, the original idea there was to add bytestring as a data type, make
hex() a regular (filter) function instead of special function-like
syntax, and add equivalent of 'expr' grammar term for other data types.
> I think this should be quite good too, the only problem with it
> is inability to mix "hex" symbol with hex("...") bytestrings.
This is an issue with any keyword, so not a big thing.
> There probably was a mistake in nest/config.Y with missing "|" here:
> "kw_sym: MIN MAX ;"
You are right there.
> I also enabled TEXT literals to be multiline. Didn't know it was not
> allowed already, so I think it should not break things, but allows to
> be more flexible with binary strings.
That is probably right.
--
Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santi...@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."
Re: [PATCH] adding custom options in radv protocol, strict ipv6 regex
On Mon, Jun 12, 2023 at 01:08:15PM +0200, Alexander Zubkov via Bird-users wrote: > Hi, > > Currently one can use only a predefined set of advertised options in radv > protocol, that are supported by bird's configuration. It would be > convenient to be able to specify other possible options at least manually > as a blob so one should not wait until it is supported in the code, > released, etc. Hi Merged: https://gitlab.nic.cz/labs/bird/-/commit/9c81250c04798fd274ae9d77380e93b941ac2d7f Hopefully there is no requirement for RA options to be sorted by type, at least i did not find it in RFC 4861. The only objection from me is that 'other type' option name is kind of non-descriptive, does not indicate it is related to RA options (nor it is implicated by context). I do not really have a good idea for alternative, perhaps just 'custom option'? What do you think? Could you prepare a patch for documentation? BTW, why not to use WALK_LIST() in radv_prepare_custom()? (just noticed in now) -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@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."
Re: [PATCH] adding custom options in radv protocol, strict ipv6 regex
On Thu, Jun 22, 2023 at 09:04:11PM +0200, Alexander Zubkov wrote: > Hi, > > Please give some feedback. Hi Sorry for letting you wait, will look at it tomorrow. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@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."
Re: Bad Peer AS with 4B AS issue
On Wed, Jun 14, 2023 at 05:29:41PM +0200, Łukasz Jarosz wrote: > I highly doubt that, but their NOC is not exactly helpful on the matter. > > They say that peer is configured for my ASN, but as I said router is out of > my control. > Nothing else, just Bad peer AS. I hope screenshot was not cut, but in case > tshark dump below: > BIRD initiation: >From tha output 4B ASN are supported, so i cannot imagine anything other than misconfigured peer. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@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."
Re: [PATCH] IPv4 over IPv6 nexthop support on FreeBSD
On Wed, Jun 14, 2023 at 02:54:49PM +0200, Luiz Amaral wrote: > Hello, > > I did not find any other patch (for Netlink) in that thread, but i could > > try to hack it myself. > > Here is the patch as an attachment. Merged. It breaks build for some very old Linux systems (e.g. Debian 8, CentOS 7), as HAVE_MPLS_KERNEL also checks for struct rtvia existence, but these systems have obsolete/unsupported kernel versions anyways. There is a question how handle feature divergence (primarily divergence in which structures and enum values are defined for compile-time) in Netlink between Linux and FreeBSD. I would prefer to not have autoconf test for each such feature. For example we could probably remove HAVE_MPLS_KERNEL altogether just for Linux (as the check is unnecessary for non-obsolete kernels, but i am not sure about FreeBSD headers). -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@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."
Re: [PATCH] IPv4 over IPv6 nexthop support on FreeBSD
On Wed, Jun 14, 2023 at 11:14:55AM +0100, Alexander Chernikov wrote: > Hi Ondrej, > > Could you please consider merging IPv4 over IPv6 support for FreeBSD Netlink > as well? > It seems like the patch slipped through the cracks :-( Hi I did not find any other patch (for Netlink) in that thread, but i could try to hack it myself. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@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."
Re: Bad Peer AS with 4B AS issue
On Wed, Jun 14, 2023 at 12:20:37PM +0200, Łukasz Jarosz wrote: > I think worth mentioning is that I have 4B AS whilst my peer has 2B AS. > All I get is this error: > > I checked pcap dumps and they seem reasonable. BIRD open is followed by peer > OPEN with piggybacked NOTIFICATION message. > > Based on MAC address my peer is Juniper, but that is just my guess. It is possible that the peer is so old that it does not support 4B ASN extension? Or isn't the peer just misconfigured, expecting different ASN? In logs, aren't there some value in 'Bad peer AS' message after colon (like 'Bad peer AS: XYZ')? -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@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."
Re: [PATCH] adding custom options in radv protocol, strict ipv6 regex
On Tue, Jun 13, 2023 at 05:34:18PM +0200, Alexander Zubkov wrote:
> On Tue, Jun 13, 2023, 16:07 Ondrej Zajicek wrote:
>
> > We agreed on keeping existing format for suffiently long hex bytestrings,
> > using hex: prefix for bytestrings of any length, and adding hex("...") /
> > base64("...") as ordinary expressions.
>
> Hi,
>
> So full house. :) I can try to implement it. Do you need a hand?
If you implement hex: prefix, we could easily merge that. The
hex("...") / base64("...") is not priority and would require some
nontrivial changes to be done properly.
--
Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santi...@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."
Re: AdminDown is tearing down BGP session
On Sun, Jun 04, 2023 at 06:06:22PM +, Sunnat Samadov wrote: > Dear Birds, > > I am reaching out to seek assistance and guidance from the community > regarding an issue we are facing with BIRD, specifically version 2.0.11, > which we have been using in our network configuration. > > Our setup involves configuring BIRD with BGP+BFD, where BIRD initiates the > BGP session establishment. However, we have observed an unexpected behavior: > after the BIRD daemon successfully establishes the BGP connection, router > sends a BFD Admin-down message and requests a new BFD session. This action by > router leads to BIRD transitioning to a BFD down state and tearing down the > previously established BGP session. Hi Sorry for late reaction. That is BIRD 2.0.11 on both sides? -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@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."
Re: [PATCH] adding custom options in radv protocol, strict ipv6 regex
On Mon, Jun 12, 2023 at 05:55:34PM +0200, Alexander Zubkov wrote:
> BTW, if we put a string literal inside the brackets, we can mimic a
> function call without dirty lexer/parser hacks:
> hex("...")
>
> Or maybe you have already agreed on something?
Hi
We agreed on keeping existing format for suffiently long hex bytestrings,
using hex: prefix for bytestrings of any length, and adding hex("...") /
base64("...") as ordinary expressions.
--
Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santi...@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."
Re: Different export route target for different prefixes of a same VRF
On Tue, Jun 13, 2023 at 10:47:08AM +0530, Ramanathan Selvamani wrote:
> Hi Team,
>
> I configured l3vpn in BIRD and I was able to see the routes are learnt and
> advertised based on RT.
>
> All the routes in this VRF are advertised with RT (1:11) to neighbors.
Hi
I am glad you tried this MPLS L3VPN branch, i would be interested in
your experiences and suggestions with it.
> I have a use case in which I want to apply different RT for different
> routes belonging to the same VRF.
>
> For example,
> I have the following prefixes in this VRF "vrf2".
> 101.1.1.0/24
> 103.1.1.0/24
> 105.1.1.0/24
>
> I would like to add different "export route target" as below for routes
> belong to same VRF
> 101.1.1.0/24 : export RT 1:11
> 103.1.1.0/24 : export RT 1:20
> 105.1.1.0/24 : export RT 1:30
Currently, the implicit export RT processing works by removing all RT
communitines and then adding ones specified in the export target
option.
If you want to set individual route targets, you could just keep the
export target set empty and add individual communities ex-post in vpn4
channel import filter (VRF export direction first passes through ipvX
channel export filter, then internal processing, then vpnX channel import
filter), with something like:
case (net) {
1:11 101.1.1.0/24: bgp_ext_community.add((rt, 1, 11));
1:11 103.1.1.0/24: bgp_ext_community.add((rt, 1, 20));
1:11 105.1.1.0/24: bgp_ext_community.add((rt, 1, 30));
}
(note that in vpnX import filter the route is already converted to VPNv4 NLRI,
so 'net'
is RD + prefix.
There is an alternative approach, which is not yet implemented, but there
should be an option with EC set that instead of appriori removing all
existing RTs during export, it should keep a defined subset (say [(rt, 1,
10..40)]), and then these RTs could be passed from original IP routes
from VRF.
--
Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santi...@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."
Re: [PATCH] adding custom options in radv protocol, strict ipv6 regex
On Mon, Jun 12, 2023 at 03:32:20PM +0200, Maria Matejka wrote: > We can simply change the lexer state externally from the parser as soon as > the hex( prefix is seen, and provide the result directly from the lexer. > > This way, we can allow all the syntaxes like hex(de-ad-be-ef), > hex(de:ad:be:ef), hex(de ad be ef) or even hex(dea:db-eef) just by ignoring > nonalnum characters altogether. > > Here I'd strongly prefer nicer user experience over setting the syntax to > best fit our needs. Which would lead to syntax that is extremely confusing (i.e. hard to intuitively grasp the right mental model just from meeting examples), so i think hex(...) variant is also worse from user experience point. As a user, i always hated unexpected special cases in syntax, even if they might be expedient in some cases. > I don't think any user really cares about the lexer/parser difference. People came with some preconceptions based on knowledge of syntax of other programming / configuration (and also regular) languages, so they have (either explicit or intuitive) concept of elementary / compound statement. If there is someting that looks like existing compound statement, but is in fact something completely different, it is confusing. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@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."
