summaryrefslogtreecommitdiff
path: root/doc/bird.sgml
diff options
context:
space:
mode:
authorOndrej Zajicek (work) <santiago@crfreenet.org>2020-05-26 18:21:43 +0200
committerOndrej Zajicek (work) <santiago@crfreenet.org>2020-05-26 18:21:43 +0200
commitc1632ad0f39f7221d649a9e469cacc38105528e2 (patch)
tree02567e33e3d6c06954ef35cd65aceb19e18b2c3a /doc/bird.sgml
parent1ca7665fa4a9858a6d4c591ccff5b61e5e6aed13 (diff)
OSPF: Fix handling of unnumbered PtPs
This issue has a long history. In 2012, we changed data field for unnumbered PtP links from iface id (specified by RFC) to IP address based on reports of bugs in Quagga that required it, and we used out-of-band information to distinquish unnumberred PtPs with the same local IP address. Then with OSPF graceful restart implementation, we found that we can no longer use out-of-band information, and we need to use only LSAdb info for routing table calculation, but i forgot to finish handling of this case, so multiple unnumbered PtPs with the same local IP addresses were broken. Considering that even recent Mikrotik RouterOS has broken next hop calculation that depends on IP address in PtP link data field, we cannot just switch back to the iface id for unnumbered PtP links. The patch makes two changes: First, it goes back to use out-of-band (position) info for distinguishing local interfaces in SPF when graceful restart is not enabled, while still uses LSAdb-only approach for SPF calculation when graceful restart is enabled. Second, it adds OSPF interface option 'ptp address', which controls whether IP address or iface id is used in data field. It is enabled by default except for unnumbered PtP links with enabled graceful restart. Thanks to Kenth Eriksson for the bugreport and Joakim Tjernlund for suggestions.
Diffstat (limited to 'doc/bird.sgml')
-rw-r--r--doc/bird.sgml27
1 files changed, 22 insertions, 5 deletions
diff --git a/doc/bird.sgml b/doc/bird.sgml
index 401b4035..552f6509 100644
--- a/doc/bird.sgml
+++ b/doc/bird.sgml
@@ -3760,11 +3760,28 @@ protocol ospf [v2|v3] &lt;name&gt; {
In <cf/type ptp/ network configurations, OSPFv2 implementations should
ignore received netmask field in hello packets and should send hello
packets with zero netmask field on unnumbered PtP links. But some OSPFv2
- implementations perform netmask checking even for PtP links. This option
- specifies whether real netmask will be used in hello packets on <cf/type
- ptp/ interfaces. You should ignore this option unless you meet some
- compatibility problems related to this issue. Default value is no for
- unnumbered PtP links, yes otherwise.
+ implementations perform netmask checking even for PtP links.
+
+ This option specifies whether real netmask will be used in hello packets
+ on <cf/type ptp/ interfaces. You should ignore this option unless you
+ meet some compatibility problems related to this issue. Default value is
+ no for unnumbered PtP links, yes otherwise.
+
+ <tag><label id="ospf-ptp-address">ptp address <m/switch/</tag>
+ In <cf/type ptp/ network configurations, OSPFv2 implementations should
+ use IP address for regular PtP links and interface id for unnumbered PtP
+ links in data field of link description records in router LSA. This data
+ field has only local meaning for PtP links, but some broken OSPFv2
+ implementations assume there is an IP address and use it as a next hop
+ in SPF calculations. Note that interface id for unnumbered PtP links is
+ necessary when graceful restart is enabled to distinguish PtP links with
+ the same local IP address.
+
+ This option specifies whether an IP address will be used in data field
+ for <cf/type ptp/ interfaces, it is ignored for other interfaces. You
+ should ignore this option unless you meet some compatibility problems
+ related to this issue. Default value is no for unnumbered PtP links when
+ graceful restart is enabled, yes otherwise.
<tag><label id="ospf-check-link">check link <M>switch</M></tag>
If set, a hardware link state (reported by OS) is taken into consideration.