This commit removes the EAF_TYPE_* namespace completely and also for
route attributes, filter-based types T_* are used. This simplifies
fetching and setting route attributes from filters.
Also, there is now union bval which serves as an universal value holder
instead of private unions held separately by eattr and filter code.
Routes are now allocated only when they are just to be inserted to the
table. Updating a route needs a locally allocated route structure.
Ownership of the attributes is also now not transfered from protocols to
tables and vice versa but just borrowed which should be easier to handle
in a multithreaded environment.
Ifaces with host address (/32) were forced to be stubby, but now they
can be used as PtP or PtMP. For these ifaces we need to:
- Do not force stub mode
- Accept packets from any IP as local
- Accept any configured neighbor as local
- Detect ifaces properly as unnumbered
- Use ONLINK flag for nexthops
As specified in RFC 2328 8.1: "On physical point-to-point networks,
the IP destination is always set to the address AllSPFRouters."
Note that this likely break setups with multiple neighbors on a network
configured as PtP, which worked before. These should be configured as
PtMP.
Thanks to Senthil Kumar Nagappan for the original patch and to Joakim
Tjernlund for suggestions.
In OSPFv3, only Hello and DBDes packets contain flags specifying whether
RFC 7166 authentication trailer is used. Other packets are processed
based on stored authentication state in neighbor structure. Update this
state with each received Hello to handle authentication change from
reconfigurations.
Thanks to Joakim Tjernlund and Kenth Eriksson for the bugreport.
When a new link-LSA is originated, we need to notify intra-area-prefix-LSA
handling, like when a new link-LSA is received. Otherwise a new network
prefix added to a DR is not propagated immediately.
Thanks to Bala Sajja for the bugreport.
BFD session options are configured per interface in BFD protocol. This
patch allows to specify them also per-request in protocols requesting
sessions (currently limited to BGP).
Sometimes multicast OSPF packet is received when neighbor adjacency is
not established. Such packet should be ignored earlier in packet
processing as otherwise it causes strange error messages when OSPFv3
authentication is enabled.
Most commands like 'show ospf neighbors' fail when protocol is not
specified and there are multiple instances of given protocol type.
This is annoying in BIRD 2, as many protocols have IPv4 and IPv6
instances. The patch changes that by showing output from all protocol
instances of appropriate type.
Note that the patch also removes terminating cli_msg() call from these
commands and moves it to the common iterating code.
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.
Per RFC 3101, N-bit signalling NSSA support should be used only in Hello
packets, not in DBDES packets. BIRD since 2.0.4 verifies N-bit in
neighbor structure, which is learned from DBDES packets, therefore
NSSA-LSAs are not propagated to proper implementations of RFC 3101.
This patch fixes that. Both removing the check and removing N-bit from
DBDES packet. This will fix compatibility issues with proper
implementations, but causes compatibility issues with BIRD 2.0.4.
We need to flush learned external LSAs a bit later than other LSAs (after
first feed after end of the graceful restart) to avoid flap of external
routes.