Re: OSPFv3 between BIRD2 and RouterOS (Mikrotik)
Hi Ondrej, Thanks, much appreciated! I'll look into the old threads further and will try what's proposed there. Regards, Kees On 19-10-2021 21:45, Ondrej Zajicek wrote: On Tue, Oct 19, 2021 at 07:55:08PM +0200, Kees Meijs | Nefos wrote: Hi list, First of all: I'm very sorry if this has been discussed before. Anyway, we're experiencing possible (configuration) incompatibiliy between BIRD2 and Mikrotik RouterOS. To be precise, we're on BIRD 2.0.7 and RouterOS 6.48.5 (Level 6). The dummy0 interface has bound a /32 IPv4 and a /128 IPv6 address for BGP lookback. OSPFv3 should provide us with IGP in order to facilitate iBGP. Between BIRD nodes this works flawless. When adding the Mikrotik router to the mix, the /128 addresses don't get propagated. Other routes do and OSPFv3 seems to work fine, but the stub routes seem to be ignored. What am I missing here? Hi See this: https://bird.network.cz/pipermail/bird-users/2021-September/015760.html https://bird.network.cz/pipermail/bird-users/2021-September/015762.html
Re: Bird just doesn't want to find OSPF neighbors although they are there and can communicate
Hi Ondrej, > On Tue, Oct 19, 2021 at 07:49:09AM +0200, Lukas Haase wrote: > > I have googled like crazy but haven't found both pages yet. > > Maybe I should use DuckDuckGo finally. > > While those didn't fix the problem yet they are helpful. Thanks! > > > > > Have you tried setting the type to 'ptmp' or 'ptp' instead of 'nbma'? > > > > Yes, I tried ptp. > > To my understanding, bird should stop sending multicast packets. > > Instead, it continued to send packets to 224.0.0.5. > > Why is that? Doesn't make sense to me at all. > > Hi > > OSPF on PtP interfaces should always use multicast (by specification). > It is generally assumed that if you have (real) ptp iface, you do not > need dst address, you just send it to the other end (so you can also > always deliver multicast). Is the difference between ptp and broadcast then only a protocol difference but on IP level it is identical? (I.e., the IP packets have src address of the sender and destination address 224.0.0.5)? Also how about ptmp? It seems when I set bird to ptmp, the IP packets do *not* have the 224.0.0.5 as destination address but the address given as "neighbor". This is what makes it work for me, I guess. I found this: 1. https://forum.mikrotik.com/viewtopic.php?t=179552 2. https://docs.nycmesh.net/networking/vpnwireguardospf/ The latter one writes: "# Use PtP is going to a Mikrotik Router. BIRD and Mikrotik dont speak the same PTMP". Indeed, as mentioned above (and linked in the forum), Mikrotik uses 224.0.0.5 in ptmp whereas bird does not. Does this mean bird is RFC incompliant for ptmp? What is meant by "BIRD and Mikrotik dont speak the same PTMP" ? > > For this reason I went for nbma. > > > > Now I have tried ptmp and magically the two see each other now. Does make > > ZERO sense to me. > > Why would ptmp work and nbma not? > > I literally just replaced "nbma" with "ptmp" (kept "neighbors" the same, > > for example). > > I am not sure whether NBMA in BIRD works with /31 prefixes. These are > really ptp prefixes and are usually used with PtP mode. Could you try > /30 prefix? I just did. No change unfortunately. As initially reported, both OSPF hello messages show up on both ends via tcpcump and both ends do not show the neighbor at all. When I just change "nbma" to "ptmp" it works again. Crazy!! > Although technically, Wireguard is more PtMP than NBMA, but for two peers > it should not matter. I think for this wireguard link I may be happy with ptmp but I also have a link with a Mikrotik router over GRE that doesn't work either. broadcast and ptp for some reason do not work; ptmp does not work because they are not the same so what's left is nbma which seems to work on Mikrotik side. For this reason I'd like to understand why the heck nbma does not even work between two birds. Regardless, I will open a new thread for the Mikrotik one. > > What are the exact conditions that the other station shows up as OSPF > > neighbor. I confirmed already with tcpdump that the OSPF Hello packages > > appear on the interface and both look *identical* (in terms of Hello Timer, > > Dead Timer, Mask, Priority). > > What could possible happen that bird would not add such packets to the > > neighbor list? > > It is possible that BIRD just ignores the packet as it does not match its > src/dst address. > You could enable 'debug all' to see if there are Hello packets logged by BIRD. Oct 20 03:28:54 endpoint2 bird: test: Starting routing table calculation Oct 20 03:28:54 endpoint2 bird: test: Starting routing table calculation for area 0.0.0.0 Oct 20 03:28:54 endpoint2 bird: test: Starting routing table calculation for inter-area (area 0.0.0.0) Oct 20 03:28:54 endpoint2 bird: test: Starting routing table calculation for ext routes Oct 20 03:28:54 endpoint2 bird: test: Starting routing table synchronisation Oct 20 03:28:54 endpoint2 bird: test > added [best] 192.168.56.228/30 dev wg-tun Oct 20 03:28:54 endpoint2 bird: test < rejected by protocol 192.168.56.228/30 dev wg-tun Oct 20 03:28:58 endpoint2 bird: test: Wait timer fired on wg-tun Oct 20 03:28:58 endpoint2 bird: test: Interface wg-tun changed state from Waiting to DR Oct 20 03:28:59 endpoint2 bird: test: Updating router state for area 0.0.0.0 Oct 20 03:29:03 endpoint2 bird: test: HELLO packet sent via wg-tun Oct 20 03:29:05 endpoint2 bird: test: HELLO packet received from nbr 192.168.56.228 on wg-tun Oct 20 03:29:05 endpoint2 bird: test: Bad HELLO packet from nbr 192.168.56.228 on wg-tun - eligibility mismatch (1) Oct 20 03:29:13 endpoint2 bird: test: HELLO packet sent via wg-tun Oct 20 03:29:13 endpoint2 bird: test: HELLO packet sent via wg-tun Oct 20 03:29:23 endpoint2 bird: test: HELLO packet sent via wg-tun Oct 20 03:29:25 endpoint2 bird: test: HELLO packet received from nbr 192.168.56.228 on wg-tun Oct 20 03:29:25 endpoint2 bird: test: Bad HELLO packet from nbr 192.168.56.228 on wg-tun - eligibility mismatch (1) Oct 20 03:29:34 endpoint2 bird: test: HELLO packet sent
Re: OSPFv3 between BIRD2 and RouterOS (Mikrotik)
On Tue, Oct 19, 2021 at 07:55:08PM +0200, Kees Meijs | Nefos wrote: > Hi list, > > First of all: I'm very sorry if this has been discussed before. > > Anyway, we're experiencing possible (configuration) incompatibiliy between > BIRD2 and Mikrotik RouterOS. To be precise, we're on BIRD 2.0.7 and RouterOS > 6.48.5 (Level 6). > The dummy0 interface has bound a /32 IPv4 and a /128 IPv6 address for BGP > lookback. OSPFv3 should provide us with IGP in order to facilitate iBGP. > > Between BIRD nodes this works flawless. > > When adding the Mikrotik router to the mix, the /128 addresses don't get > propagated. Other routes do and OSPFv3 seems to work fine, but the stub > routes seem to be ignored. > > What am I missing here? Hi See this: https://bird.network.cz/pipermail/bird-users/2021-September/015760.html https://bird.network.cz/pipermail/bird-users/2021-September/015762.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."
OSPFv3 between BIRD2 and RouterOS (Mikrotik)
Hi list,
First of all: I'm very sorry if this has been discussed before.
Anyway, we're experiencing possible (configuration) incompatibiliy
between BIRD2 and Mikrotik RouterOS. To be precise, we're on BIRD 2.0.7
and RouterOS 6.48.5 (Level 6).
Configuration snippet from BIRD:
protocol ospf v3 ospf_v6 {
# Do not generate ECMP (equal-cost multipath) routes.
ecmp no;
area 0.0.0.0 {
interface "eth0" {
authentication cryptographic;
password "SOMETHING";
bfd yes;
};
interface "eth1" {
authentication cryptographic;
password "SOMETHINGELSE";
bfd yes;
};
interface "dummy0" {
stub;
};
interface "eth2" {
stub;
};
interface "eth3" {
type pointopoint;
bfd yes;
};
};
}
The dummy0 interface has bound a /32 IPv4 and a /128 IPv6 address for
BGP lookback. OSPFv3 should provide us with IGP in order to facilitate iBGP.
Between BIRD nodes this works flawless.
When adding the Mikrotik router to the mix, the /128 addresses don't get
propagated. Other routes do and OSPFv3 seems to work fine, but the stub
routes seem to be ignored.
What am I missing here?
Thanks!
Cheers,
Kees
--
https://nefos.nl/contact
Nefos IT bv
Ambachtsweg 25 (industrienummer 4217)
5627 BZ Eindhoven
Nederland
KvK 66494931
/Bereikbaar op maandag, dinsdag, donderdag en vrijdag tussen 09:00u en
17:00u./
Re: Bird just doesn't want to find OSPF neighbors although they are there and can communicate
On Tue, Oct 19, 2021 at 07:49:09AM +0200, Lukas Haase wrote: > I have googled like crazy but haven't found both pages yet. > Maybe I should use DuckDuckGo finally. > While those didn't fix the problem yet they are helpful. Thanks! > > > Have you tried setting the type to 'ptmp' or 'ptp' instead of 'nbma'? > > Yes, I tried ptp. > To my understanding, bird should stop sending multicast packets. > Instead, it continued to send packets to 224.0.0.5. > Why is that? Doesn't make sense to me at all. Hi OSPF on PtP interfaces should always use multicast (by specification). It is generally assumed that if you have (real) ptp iface, you do not need dst address, you just send it to the other end (so you can also always deliver multicast). > For this reason I went for nbma. > > Now I have tried ptmp and magically the two see each other now. Does make > ZERO sense to me. > Why would ptmp work and nbma not? > I literally just replaced "nbma" with "ptmp" (kept "neighbors" the same, for > example). I am not sure whether NBMA in BIRD works with /31 prefixes. These are really ptp prefixes and are usually used with PtP mode. Could you try /30 prefix? Although technically, Wireguard is more PtMP than NBMA, but for two peers it should not matter. > There is also another problem: One of my clients is a Mikrotik router. > This thing supports "broadcast, "ptp", "ptmp" and "nmba". However, I can > weirdly only configure "NBMA Neighbors". > I have tried this link with ipip, GRE, all types of connections but still no > luck yet. > > Seriously, the last time setting something up was that much of a hassle was > sendmail 25 years ago :-( For some reason, VPN interfaces often have rather strange quirks, like missing link-local addressess, not working multicast, or completely broken routing in OpenVPN. OTOH, i use BIRD OSPF on PtP GRE tunnels without any problems or tweaks (in PtP mode). > Based on one of your links it is also suggested that MTU could be the issue. > I checked but all my MTUs are consistent (1420 for the wireguard tunnel and > 1476 for the GRE tunnel). I still tried "tx length 1300". No change. This should not be necessary, BIRD learns tx length from iface MTU. > > WireGuard tunnels are default ptp between the server and clients (if > > multiple client-peers are configured on the same tunnel interface on > > the server). > > > > Or "just" ptp if only one peer is configured for a single wg tunnel on > > each side. > > This is the case but as above, this is just not working. > And on eiher side of tcpdump are still multicast packets visible (224.0.0.5) > > What are the exact conditions that the other station shows up as OSPF > neighbor. I confirmed already with tcpdump that the OSPF Hello packages > appear on the interface and both look *identical* (in terms of Hello Timer, > Dead Timer, Mask, Priority). > What could possible happen that bird would not add such packets to the > neighbor list? It is possible that BIRD just ignores the packet as it does not match its src/dst address. You could enable 'debug all' to see if there are Hello packets logged by BIRD. -- 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 adversites a direct route from an interface without carrier
On Tue, Oct 19, 2021 at 12:35:20PM +0200, Alarig Le Lay wrote: > Hello Ondrej, > > On Mon 18 Oct 2021 17:39:44 GMT, Ondrej Zajicek wrote: > > On Mon, Oct 11, 2021 at 01:20:52PM +0200, Alarig Le Lay wrote: > > > Hi, > > > > > > On one router I have an interface that used to be connected to another > > > machine, so the state is NO-CARRIER: > > > core01-arendal ~ # ip addr show enp1s0 > > > 2: enp1s0: mtu 1500 qdisc mq state > > > DOWN group default qlen 1000 > > > link/ether 00:0d:b9:48:c1:c0 brd ff:ff:ff:ff:ff:ff > > > inet 10.0.4.1/31 scope global enp1s0 > > >valid_lft forever preferred_lft forever > > > inet6 2001:4640:a14f:fffd::2/127 scope global > > >valid_lft forever preferred_lft forever > > > inet6 fe80::20d:b9ff:fe48:c1c0/64 scope link > > >valid_lft forever preferred_lft forever > > > > Hi > > > > What do you see in 'show interfaces' 'show ospf interface' and > > 'show ospf state' on given router? Is it Linux or BSD? Hi You use route from Direct protocol exported to OSPF. Contrary to other protocols, default value of 'check link' option for Direct protocol is 'no'. Just enable it: https://bird.network.cz/?get_doc&v=20&f=bird-6.html#direct-check-link -- 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 adversites a direct route from an interface without carrier
Hello Ondrej, On Mon 18 Oct 2021 17:39:44 GMT, Ondrej Zajicek wrote: > On Mon, Oct 11, 2021 at 01:20:52PM +0200, Alarig Le Lay wrote: > > Hi, > > > > On one router I have an interface that used to be connected to another > > machine, so the state is NO-CARRIER: > > core01-arendal ~ # ip addr show enp1s0 > > 2: enp1s0: mtu 1500 qdisc mq state DOWN > > group default qlen 1000 > > link/ether 00:0d:b9:48:c1:c0 brd ff:ff:ff:ff:ff:ff > > inet 10.0.4.1/31 scope global enp1s0 > >valid_lft forever preferred_lft forever > > inet6 2001:4640:a14f:fffd::2/127 scope global > >valid_lft forever preferred_lft forever > > inet6 fe80::20d:b9ff:fe48:c1c0/64 scope link > >valid_lft forever preferred_lft forever > > Hi > > What do you see in 'show interfaces' 'show ospf interface' and > 'show ospf state' on given router? Is it Linux or BSD? The router is a Linux (5.10). And for the outputs: bird> show interfaces enp1s0 up (index=2) MultiAccess Broadcast Multicast AdminUp LinkDown MTU=1500 10.0.4.1/31 (Preferred, opposite 10.0.4.0, scope site) fe80::20d:b9ff:fe48:c1c0/64 (Preferred, scope link) 2001:4640:a14f:fffd::2/127 (Preferred, opposite 2001:4640:a14f:fffd::3, scope univ) bird> show ospf interface "enp1s0" ospf_ipv4: Interface enp1s0 (10.0.4.0/31) Type: ptp Area: 4.8.8.4 (67635204) State: Loopback Priority: 1 Cost: 1 ECMP weight: 1 Hello timer: 10 Wait timer: 40 Dead timer: 40 Retransmit timer: 5 ospf_ipv6: Interface enp1s0 (IID 0) Type: broadcast Area: 4.8.8.4 (67635204) State: Loopback Priority: 1 Cost: 1 ECMP weight: 1 Hello timer: 10 Wait timer: 40 Dead timer: 40 Retransmit timer: 5 Designated router (ID): 45.91.126.254 Designated router (IP): fe80::20d:b9ff:fe48:c1c0 Backup designated router (ID): 0.0.0.0 Backup designated router (IP): :: bird> show ospf state ospf_ipv4 area 0.0.0.0 […] router 45.91.126.254 distance 0 external 10.0.4.0/31 metric2 1 […] If you want the full output, here they are: https://paste.swordarmor.fr/raw/zpAv The router from which I dumped the OSPF route is connected to enp3s0.50, which is in area 4.8.8.4, like enp1s0. However, both routers are inside 0.0.0.0 via other interfaces. If my OSPF configuration might help, it’s https://paste.swordarmor.fr/raw/OIkL The files matched by "/etc/bird.lag-*.conf" are generated by cron, adapting the cost with the latency. (so lag as time, not aggregation here) If you want a more detailed view of my router, don’t hesitate to ask me, or if you need more details as well :) Regards, -- Alarig
