The code generating LSAs for ptp ospf links is buggy. The current behavior is that it generates ptp link if there is a full/ptp neighbor and stub link if there isn't. According to RFC 2328, the correct behavior is to generate stub link in both cases (in the first case together with ptp link). And because of buggy detection of unnumbered networks, for numbered networks the code creates stub links with 0.0.0.0/32. The first patch corrects this behavior, but i am not sure what is the best behavior for unnumbered (ptp-address) networks. The code contains variable ptp_unnumbered_stub_lsa that determines whether unnumbered ptp links should generate stub links. If enabled, stub links are generated regardless there is a full/ptp neighbor. The second patch makes ospf dump more informative. -- 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."
Ondrej Zajicek wrote:
The code generating LSAs for ptp ospf links is buggy. The current behavior is that it generates ptp link if there is a full/ptp neighbor and stub link if there isn't. According to RFC 2328, the correct behavior is to generate stub link in both cases (in the first case together with ptp link).
You are true. I will fix it.
And because of buggy detection of unnumbered networks, for numbered networks the code creates stub links with 0.0.0.0/32.
OK!
The first patch corrects this behavior, but i am not sure what is the best behavior for unnumbered (ptp-address) networks. The code contains variable ptp_unnumbered_stub_lsa that determines whether unnumbered ptp links should generate stub links. If enabled, stub links are generated regardless there is a full/ptp neighbor.
OK, I will look at it. And hopefully this will go to the next release. as well. Maybe I am too tired now, but what is the meaning of 'ln_after' variable?
The second patch makes ospf dump more informative.
OK, I will include it. Ondrej
On Mon, Aug 25, 2008 at 01:13:34AM +0200, Ondrej Filip wrote:
The first patch corrects this behavior, but i am not sure what is the best behavior for unnumbered (ptp-address) networks. The code contains variable ptp_unnumbered_stub_lsa that determines whether unnumbered ptp links should generate stub links. If enabled, stub links are generated regardless there is a full/ptp neighbor.
OK, I will look at it. And hopefully this will go to the next release. as well. Maybe I am too tired now, but what is the meaning of 'ln_after' variable?
The end of an allocated buffer, i added check testing whether we don't write after allocated buffer, because code looked easy-to-break for me. -- 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)
-
Ondrej Filip -
Ondrej Zajicek