OSPF RFC compliance issue?
Hi birdsters, I'm having difficulty getting a bird OSPF instance to peer correctly with a MikroTik RouterOS device over an L2TP PTP link. The symptom is that routes originated from my bird instance show up in RouterOS's route database with no gateway, and are not added to the device's routing table as a result. MikroTik have debugged this and claim that bird's OSPF LS updates are violating RFC. After reading a packet capture and the relevant parts of RFC 2328, they seem to be correct. I've provided a PCAP capture at: http://decoder.geek.sh/misc/bird-mt-ospf.pcap The interesting packet is #14 in the capture. Bird is sending a Router LSA with bizarre link information that does not correspond at all with the PTP link information. In reality the PTP link on the bird device has address 172.18.102.37 with a peer address of 172.18.102.36, and these addresses are unique across all interfaces. I'm using bird 1.3.8 on Debian Wheezy (Linux kernel 3.2.32). Any ideas? Thanks, Aragon
Hi again, After a lot more experimenting I have things working, and a better understanding of what was up. The bizarre link information in the Router LSA turns out to be normal if the link is unnumbered. PtP interfaces are considered to be unnumbered if their netmask is 255.255.255.255 (error?). That netmask seems to be the only option with Linux pppd, but writing an ip-up script that changes it after the link is established fixes things up. The other side of the story is that MikroTik RouterOS does not support unnumbered OSPF interfaces! Hope this noise is useful to someone in future. :) Thanks, Aragon On 09/01/2013 19:54, Aragon Gouveia wrote:
Hi birdsters,
I'm having difficulty getting a bird OSPF instance to peer correctly with a MikroTik RouterOS device over an L2TP PTP link. The symptom is that routes originated from my bird instance show up in RouterOS's route database with no gateway, and are not added to the device's routing table as a result.
MikroTik have debugged this and claim that bird's OSPF LS updates are violating RFC. After reading a packet capture and the relevant parts of RFC 2328, they seem to be correct.
I've provided a PCAP capture at:
http://decoder.geek.sh/misc/bird-mt-ospf.pcap
The interesting packet is #14 in the capture. Bird is sending a Router LSA with bizarre link information that does not correspond at all with the PTP link information. In reality the PTP link on the bird device has address 172.18.102.37 with a peer address of 172.18.102.36, and these addresses are unique across all interfaces.
I'm using bird 1.3.8 on Debian Wheezy (Linux kernel 3.2.32).
Any ideas?
Thanks, Aragon
On Wed, Jan 09, 2013 at 10:12:10PM +0200, Aragon Gouveia wrote:
Hi again,
After a lot more experimenting I have things working, and a better understanding of what was up.
The bizarre link information in the Router LSA turns out to be normal if the link is unnumbered. PtP interfaces are considered to be unnumbered if their netmask is 255.255.255.255 (error?). That netmask seems to be the only option with Linux pppd, but writing an ip-up script that changes it after the link is established fixes things up.
The other side of the story is that MikroTik RouterOS does not support unnumbered OSPF interfaces!
Hope this noise is useful to someone in future. :)
Hello This is well known issue: http://www.mail-archive.com/bird-users@atrey.karlin.mff.cuni.cz/msg02187.htm... We will 'fix' that in the next version, see this commit: https://git.nic.cz/redmine/projects/bird/repository/revisions/6cadbf325bfcf2... -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
participants (2)
-
Aragon Gouveia -
Ondrej Zajicek