summaryrefslogtreecommitdiff
path: root/proto
AgeCommit message (Collapse)Author
2023-01-23Merge commit '8b06a4d8af46511f0f8dbb8905afa88590a831b6' into thread-nextMaria Matejka
2023-01-21Merge commit '1e47b9f203aaaad0fb658d40a1670f1d0437f1f8' into thread-nextMaria Matejka
2023-01-21Merge commit '3859e4efc1597368df647323c5a3cc1771cb64ca' into thread-nextMaria Matejka
2022-12-24Babel: Rework seqno request handlingToke Høiland-Jørgensen
The seqno request retransmission handling was tracking the destination that a forwarded request was being sent to and always retransmitting to that same destination. This is unnecessary because we only need to retransmit requests we originate ourselves, not those we forward on behalf of others; in fact retransmitting on behalf of others can lead to exponential multiplication of requests, which would be bad. So rework the seqno request tracking so that instead of storing the destination of a request, we just track whether it was a request that we forwarded on behalf of another node, or if it was a request we originated ourselves. Forwarded requests are not retransmitted, they are only used for duplicate suppression, and for triggering an update when satisfied. If we end up originating a request that we previously forwarded, we "upgrade" the old request and restart the retransmit counter. One complication with this is that requests sent in response to unfeasible updates (section 3.8.2.2 of the RFC) have to be sent as unicast to a particular peer. However, we don't really need to retransmit those as there's no starvation when sending such a request; so we just change such requests to be one-off unicast requests that are not subject to retransmission or duplicate suppression. This is the same behaviour as babeld has for such requests. Minor changes from committer.
2022-12-10BGP: Log unacceptable hold time as decimal numberOndrej Zajicek
Thanks Johannes Moos for the suggestion.
2022-12-09BGP: Improve handling of hold and keepalive timersOndrej Zajicek
The effective keepalive time now scales relative to the negotiated hold time, to maintain proportion between the keepalive time and the hold time. This avoids issues when both keepalive and hold times were configured, the hold time was negotiated to a smaller value, but the keepalive time stayed the same. Add new options 'min hold time' and 'min keepalive time', which reject session attempts with too small hold time. Improve validation of config options an their documentation. Thanks to Alexander Zubkov and Sergei Goriunov for suggestions.
2022-11-07Merge commit '8f79e6b9' into thread-nextMaria Matejka
2022-11-07Merge commit '8478de88' into thread-nextMaria Matejka
2022-11-07Merge commit '54430df9' into thread-nextMaria Matejka
2022-10-12BGP refeed and reload with Adj-RIB-In/Out is done without route refreshMaria Matejka
2022-10-12Fixed BGP reload limitsMaria Matejka
2022-10-12BGP: End route refresh before another startsMaria Matejka
2022-10-10BGP: Add option 'next hop prefer global'Ondrej Zajicek
Add BGP channel option 'next hop prefer global' that modifies BGP recursive next hop resolution to use global next hop IPv6 address instead of link-local next hop IPv6 address for immediate next hop of received routes.
2022-10-05Fixed pipe reload/refeed to properly propagate as route refresh to the other ↵Maria Matejka
table
2022-10-03BGP: Do not assume that all channels are struct bgp_channelOndrej Zajicek
In principle, the channel list is a list of parent struct proto and can contain general structures of type struct channel, That is useful e.g. for adding MPLS channels to BGP.
2022-10-03BGP: Some fixes related to VRF and MPLS interactionsOndrej Zajicek
- When next hop is reset to local IP, we should remove BGP label stack, as it is related to original next hop - BGP next hop or immediate next hop from one VRF should not be passed to another VRF, as they are different IP namespaces
2022-10-03RPKI: wait for retry_time if we get error immediately after connectedMaria Matejka
2022-09-26Merge commit '3fd1f461' into thread-nextMaria Matejka
closes #16 closes #17 closes #18
2022-09-21Flushing tmp_linpool in tree test and in static protocolMaria Matejka
2022-09-20Pipe kick-and-drain packed into a neat structure and functions.Maria Matejka
2022-09-20BFD: The old pipe notification mechanism replaced by eventsMaria Matejka
2022-09-20Merge commit 'adf37d8e' into thread-nextMaria Matejka
2022-09-18Merge commit '4f3fa162' into HEADMaria Matejka
2022-09-09Merge commit 'd2c1036a42881d413ec97203ede92a69f8cd218f' into thread-nextMaria Matejka
2022-09-08Table access is now locked.Maria Matejka
2022-09-05Exporter routine refactoring to allow for nicer table lockingMaria Matejka
2022-09-01Miscellaneous refactoringMaria Matejka
2022-09-01Default tables are not created unless actually used.Maria Matejka
This allows for setting default table values at the beginning of config file before "master4" and "master6" tables are initialized.
2022-08-18Simplified the protocol hookup code in MakefilesMaria Matejka
2022-08-05Merge branch 'backport' into thread-nextMaria Matejka
2022-08-05Merge commit '2e484f8d' into thread-nextMaria Matejka
2022-08-05Merge commit '971721c9' into thread-nextMaria Matejka
2022-08-03Merge commit '082905a8' into HEADMaria Matejka
2022-08-03rip_rte_better() uses the IGP_METRIC_UNKNOWN instead of protocol-specific ↵Maria Matejka
infinity
2022-08-03Merge commit '97476e00' into thread-nextMaria Matejka
Had to fix route source locking inside BGP export table as we need to keep the route sources properly allocated until even last BGP pending update is sent out, therefore the export table printout is accurate.
2022-08-03BGP: The bucket/prefix hashes are now a resource to allow for proper cleanupMaria Matejka
2022-08-02Merge commit 'f0507f05ce57398e135651896dace4cb68eeed54' into thread-nextMaria Matejka
2022-08-02BGP: respecting table corkMaria Matejka
2022-07-24Merge branch 'master' into backportOndrej Zajicek
2022-07-22Fixed a rarely used part of Babel: comparing two routes in table by their metricMaria Matejka
2022-07-18Merge commit '94eb0858' into thread-nextMaria Matejka
2022-07-18Merge commit 'a4451535' into thread-nextMaria Matejka
2022-07-15Merge commit 'c70b3198' into thread-next [lots of conflicts]Maria Matejka
There were more conflicts that I'd like to see, most notably in route export. If a bisect identifies this commit with something related, it may be simply true that this commit introduces that bug. Let's hope it doesn't happen.
2022-07-14Fixed invalid routes handlingMaria Matejka
The invalid routes were filtered out before they could ever get exported, yet some of the routines need them available, e.g. for display or import reload. Now the invalid routes are properly exported and dropped in channel export routines instead.
2022-07-13Merge commit '2e5bfeb73ac25e236a24b6c1a88d0f2221ca303f' into thread-nextMaria Matejka
2022-07-13Merge commit 'd429bc5c841a8e9d4c81786973edfa56d20a407e' into thread-nextMaria Matejka
2022-07-13Merge commit '7e9cede1fd1878fb4c00e793bccd0ca6c18ad452' into thread-nextMaria Matejka
2022-07-12BGP: Minor improvements to BGP rolesOndrej Zajicek
Add support for bgp_otc in filters and warning for configuration inside confederations.
2022-07-12Removing the rte_modify APIMaria Matejka
For BGP LLGR purposes, there was an API allowing a protocol to directly modify their stale routes in table before flushing them. This API was called by the table prune routine which violates the future locking requirements. Instead of this, BGP now requests a special route export and reimports these routes into the table, allowing for asynchronous execution without locking the table on export.
2022-07-12Route refresh in tables uses a stale counter.Maria Matejka
Until now, we were marking routes as REF_STALE and REF_DISCARD to cleanup old routes after route refresh. This needed a synchronous route table walk at both beginning and the end of route refresh routine, marking the routes by the flags. We avoid these walks by using a stale counter. Every route contains: u8 stale_cycle; Every import hook contains: u8 stale_set; u8 stale_valid; u8 stale_pruned; u8 stale_pruning; In base_state, stale_set == stale_valid == stale_pruned == stale_pruning and all routes' stale_cycle also have the same value. The route refresh looks like follows: + ----------- + --------- + ----------- + ------------- + ------------ + | | stale_set | stale_valid | stale_pruning | stale_pruned | | Base | x | x | x | x | | Begin | x+1 | x | x | x | ... now routes are being inserted with stale_cycle == (x+1) | End | x+1 | x+1 | x | x | ... now table pruning routine is scheduled | Prune begin | x+1 | x+1 | x+1 | x | ... now routes with stale_cycle not between stale_set and stale_valid are deleted | Prune end | x+1 | x+1 | x+1 | x+1 | + ----------- + --------- + ----------- + ------------- + ------------ + The pruning routine is asynchronous and may have high latency in high-load environments. Therefore, multiple route refresh requests may happen before the pruning routine starts, leading to this situation: | Prune begin | x+k | x+k | x -> x+k | x | ... or even | Prune begin | x+k+1 | x+k | x -> x+k | x | ... if the prune event starts while another route refresh is running. In such a case, the pruning routine still deletes routes not fitting between stale_set and and stale_valid, effectively pruning the remnants of all unpruned route refreshes from before: | Prune end | x+k | x+k | x+k | x+k | In extremely rare cases, there may happen too many route refreshes before any route prune routine finishes. If the difference between stale_valid and stale_pruned becomes more than 128 when requesting for another route refresh, the routine walks the table synchronously and resets all the stale values to a base state, while logging a warning.