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.
Implement OSPFv2 (RFC 3623) and OSPFv3 (RFC 5187) graceful restart,
for both restarting and helper sides. Graceful restart is initiated
by 'graceful down' command.
The temporary atttributes are no longer removed by ea_do_prune(), but
they are undefined by store_tmp_attrs() protocol hooks. This fixes
several bugs where temporary attributes were removed when they should
not or not removed when they should be. The flag EAF_TEMP is no longer
needed and was removed.
Update all protocol make_tmp_attrs() / store_tmp_attrs() hooks to use
helper functions and to handle unset attributes properly.
Also fix some related bugs like improper handling of empty eattr list.
Keep track of whether OSPF tmpattrs are actually defined for given route
(using flags in rte->pflags). That makes them behave more like real
eattrs so a protocol can define just a subset of them or they can be
undefined by filters.
Do not set ospf_metric2 for other than type 2 external OSPF routes and do
not set ospf_tag for non-external OSPF routes. That also fixes a bug
where internal/inter-area route propagated from one OSPF instance to
another is initiated with infinity ospf_metric2.
Thanks to Yaroslav Dronskii for the bugreport.
This is a major change of how the filters are interpreted. If everything
works how it should, it should not affect you unless you are hacking the
filters themselves.
Anyway, this change should make a huge improvement in the filter performance
as previous benchmarks showed that our major problem lies in the
recursion itself.
There are also some changes in nest and protocols, related mostly to
spreading const declarations throughout the whole BIRD and also to
refactored dynamic attribute definitions. The need of these came up
during the whole work and it is too difficult to split out these
not-so-related changes.
When area is reconfigured to a different type, we need to flush LSAs as
they may not be valid (e.g. NSSA-LSA for non-NSSA area). Also, when we
have have just one OSPF area and that changes type, we could restart OSPF
as there is no state to keep anyway. That solves issue with different
handling of external routes exported to OSPF based of main area type.
External LSAs originated by OSPF routers with VPN-PE behavior enabled are
marked by DN flag and they are ignored by other OSPF routers with VPN-PE
enabled.
Direct acknowledgements should be send as unicast to a corresponding
neighbor. Only delayed acks should be send as multicast to all/designated
routers.
Master may free last DBDES packet immediately. Slave must wait dead
interval before freeing last DBDES packet and then reject duplicate
DBDES packets with SeqNumberMismatch.
In some circumstances (old LSA flushed but not acknowledged and not
removed) origination of a new LSA may wrongly triggers LSA collision
code. The patch fixes that.
Thanks to Asbjorn Mikkelsen for the bugreport and @mdelagueronniere
for the original patch.
Fix crash during reconfiguration of OSPF config with vlinks. When vlink
is reconfigured, a generic iface-reconfiguration code is used, which in
one place supposes that it is running on a regular iface.
Thanks to Cybertinus for a bugreport.
Once upon a time, far far away, there were the old Bird developers
discussing what direction of route flow shall be called import and
export. They decided to say "import to protocol" and "export to table"
when speaking about a protocol. When speaking about a table, they
spoke about "importing to table" and "exporting to protocol".
The latter terminology was adopted in configuration, then also the
bird CLI in commit ea2ae6dd0 started to use it (in year 2009). Now
it's 2018 and the terminology is the latter. Import is from protocol to
table, export is from table to protocol. Anyway, there was still an
import_control hook which executed right before route export.
One thing is funny. There are two commits in April 1999 with just two
minutes between them. The older announces the final settlement
on config terminology, the newer uses the other definition. Let's see
their commit messages as the git-log tool shows them (the newer first):
commit 9e0e485e50
Author: Martin Mares <mj@ucw.cz>
Date: Mon Apr 5 20:17:59 1999 +0000
Added some new protocol hooks (look at the comments for better explanation):
make_tmp_attrs Convert inline attributes to ea_list
store_tmp_attrs Convert ea_list to inline attributes
import_control Pre-import decisions
commit 5056c559c4
Author: Martin Mares <mj@ucw.cz>
Date: Mon Apr 5 20:15:31 1999 +0000
Changed syntax of attaching filters to protocols to hopefully the final
version:
EXPORT <filter-spec> for outbound routes (i.e., those announced
by BIRD to the rest of the world).
IMPORT <filter-spec> for inbound routes (i.e., those imported
by BIRD from the rest of the world).
where <filter-spec> is one of:
ALL pass all routes
NONE drop all routes
FILTER <name> use named filter
FILTER { <filter> } use explicitly defined filter
For all protocols, the default is IMPORT ALL, EXPORT NONE. This includes
the kernel protocol, so that you need to add EXPORT ALL to get the previous
configuration of kernel syncer (as usually, see doc/bird.conf.example for
a bird.conf example :)).
Let's say RIP to this almost 19-years-old inconsistency. For now, if you
import a route, it is always from protocol to table. If you export a
route, it is always from table to protocol.
And they lived happily ever after.
