summaryrefslogtreecommitdiffstats
path: root/src/network/networkd-route.h (follow)
Commit message (Collapse)AuthorAgeFilesLines
* network/route: use generic [Route] section parser moreYu Watanabe2024-10-111-8/+8
|
* network/route-nexthop: use generic [Route] section parser moreYu Watanabe2024-10-111-0/+5
|
* network/route-metric: merge conf parsers for route metricYu Watanabe2024-10-111-0/+15
| | | | | This introduces a generic [Route] section parser, then embed conf parsers for route metric into it.
* network/route: also update source, status, and so on EEXISTYu Watanabe2024-09-011-1/+1
| | | | | Otherwise, an existing route may be labeled as foreign even after we reconfigure it.
* network/ndisc: remove conflicting routes on configuring routes based on ↵Yu Watanabe2024-02-141-0/+1
| | | | | | | | | | newly received RA The linux kernel does not update several parameters, e.g. RTA_PREF. Hence, when we configure routes based on a RA, we need to remove existing conflicting routes. Fixes #28426 and #28439.
* network/route: remove existing route if some property conflict with ↵Yu Watanabe2024-02-141-0/+2
| | | | | | requested ones Fixes #28853.
* network: rename link_drop_managed_xyz() -> link_drop_static_xyz()Yu Watanabe2024-02-141-1/+1
| | | | | | | | | | | | | | As networkd does not configure nexthops, neighbors, or routing policy rules dynamically, this only changes link_drop_managed_addresses(). Previously it also removed dynamic addresses, but with this commit, now it only removes static addresses. Note, link_drop_managed_routes() has removed only static routes, so this commit only changes its name. Note. as commented in the code, the dynamic addresses will be removed on lease expiration or stopping client, and link_drop_managed_xyz() are called on reconfiguration or so, and at that time, all dynamic addressing clients are stopped or restarted, so this should not effective behavior change.
* network/route: introduce reverse map for route with nexthop IDYu Watanabe2024-01-251-0/+1
| | | | | | | It is not used in this commit, but will be used later. Preparation for later commits. This is the one for routes of 531c7246829a41dd7e51847bd4d77aa012ff478f.
* network/route: introduce ref/unref functions for Route objectYu Watanabe2024-01-251-2/+5
| | | | | | | Then, Route object can live if it is detached from the owner (Manager, Network, or Wireguard object). This is the one for routes of ebd96906477aac2bbc6b9de0d6e9bd0f39db5581.
* network/route: introduce route_remove_and_cancel()Yu Watanabe2024-01-251-3/+2
| | | | | | | | | | | | Then, replace route_remove_and_drop() with it. If a route is requested, and the request is already called, we may not received its reply and notification from the kernel, and the corresponding Route object may not be remembered. Even in such case, we need to remove the route, otherwise the route will come later after the function called. This is the version for route of f22b586a215962416bdbd692aabb89b1ac2999d0.
* network/route: manage all routes by Manager objectYu Watanabe2024-01-241-6/+10
| | | | | | | | | | | | | | | | | | Previously, a Route object is owned by a Link object corresponding to the outgoing interface of the route, and a Route object that does not have outgoing interface is owned by the Manager object. However, there were several issues: - if a route has a nexthop ID, then the corresponding nexthop may be changed to use another interface, hence the outgoing interface of the route may be changed. - if a route requested with MultiPathRoute=, then the link who requests the route is different from the outgoing interface of the configured route. So, we need to find routes on other interfaces on reconfiguring or so. By this change, the limit of the number of routes per-interface is tentatively dropped. Let's re-introduce the limit later in a nicer way.
* network/route: convert route before requestingYu Watanabe2024-01-191-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, 1. use the passed Route object as is when a route is requested, 2. when the route becomes ready to configure, convert the Route object if necessary, to resolve outgoing interface name, and split multipath routes, and save them to the associated interfaces, 3. configure the route with the passed Route object. However, there are several inconsistencies with what kernel does: - The kernel does not merge nor split IPv4 multipath routes. However, we unconditionally split multipath routes to manage. - The kernel does not set gateway or so to a route if it has nexthop ID. Fortunately, I do not find any issues caused by the inconsistencies. But for safety, let's manage routes in a consistent way with the kernel. This makes, 1. when a route is requested, split IPv6 multipath routes, but keep IPv4 multipath routes as is, and queue (possibly multiple) requests for the route. 2. when the route becomes ready to configure, resolve nexthop and interface name, and requeue request if necessary. 3. configure the (possibly split) route. By using the logic, - Now we manage routes in a mostly consistent way with the kernel. - We can drop ConvertedRoutes object. - Hopefully the code becomes much simpler.
* network/route-nexthop: introduce route_nexthops_copy()Yu Watanabe2024-01-191-1/+1
| | | | | | | This also introduce an extra argument for route_dup(), but it is currently unused, will be used later. No functional change, just preparation for later commits.
* network/route: reorder elements in Route object and add commentsYu Watanabe2024-01-161-14/+15
|
* network/route: relocate route_new() and friendsYu Watanabe2024-01-161-2/+3
| | | | No functional change, preparation for later commits.
* network/route: also use RouteNextHop for managing gatewayYu Watanabe2024-01-151-4/+2
| | | | No functional change, just refactoring.
* network/route-nexthop: introduce struct RouteNextHop and replace ↵Yu Watanabe2024-01-151-1/+3
| | | | | | | MultipathRoute with it It is mostly equivalent to MultipathRoute. So, no functional change, just refactoring and preparation for later commits.
* wireguard: verify routes configured in .netdev fileYu Watanabe2024-01-131-0/+4
| | | | | Then, scope and friends are correctly adjusted, and the behavior should be matched when the same route is configured in .network file.
* Merge pull request #30897 from yuwata/network-route-expirationLuca Boccassi2024-01-131-7/+9
|\ | | | | network: several cleanups for route expiration handling
| * network/route: update expiration timer only when we know the route existsYu Watanabe2024-01-121-1/+1
| |
| * network/route: save if the route expiration is managed by the kernelYu Watanabe2024-01-121-6/+8
| | | | | | | | | | Otherwise, our own expiration timer will be setup on updating a route. See comment in link_request_route().
* | network/route: move two more conf parsers to networkd-route-nexthop.[ch]Yu Watanabe2024-01-121-2/+0
|/ | | | Let's manage nexthop (gateway) handling in networkd-route-nexthop.[ch].
* network/route-metric: introduce RouteMetricYu Watanabe2024-01-071-9/+3
| | | | | | | | Then, split out route metric handling from networkd-route.c to networkd-route-metric.c. No functional change, just refactoring and preparation for later commits.
* network/route: move several conf parsers to networkd-route-metric.c and ↵Yu Watanabe2024-01-061-10/+4
| | | | | | | | | networkd-route-nexthop.c This also split config_parse_route_boolean() into two: for GatewayOnline= and boolean route metrics. No functional change, just refactoring and preparation for later commits.
* network/route: drop TTL propagate support for MPLS routesYu Watanabe2024-01-031-1/+0
| | | | | | This effectively reverts 9b88f20aba6a78baf18d89e99ff31d5ee40856b8. We do not support MPLS routes, only IPv4 or IPv6 routes are supported.
* network: static route - Allow to configure per route hop liimtSusant Sahani2023-08-181-0/+1
|
* network: Route - allow to set TCP RTOSusant Sahani2023-08-171-0/+2
|
* network: ndisc - Honour CurHopLimitSusant Sahani2023-07-301-0/+1
| | | | | | | | | | | RFC4861 Neighbor Discovery – Sections 4.2 and 6.3.4 From section 4.2. Router Advertisement Message Format: Cur Hop Limit 8-bit unsigned integer. The default value that should be placed in the Hop Count field of the IP header for outgoing IP packets. A value of zero means unspecified (by this router).
* network: DHCP4 allow to set InitialCongestionWindow and ↵Susant Sahani2023-07-151-0/+1
| | | | InitialAdvertisedReceiveWindow
* network: introduce {address,route}_remove_and_drop()Yu Watanabe2022-10-031-0/+1
| | | | Preparation for later commits.
* network: don't forget old RAs when a new one arrivesThomas Hebb2022-10-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | IPv6 Neighbor Discovery lets us autoconfigure a link's IPv6 addresses, routes, DNS servers, and DNS search domains by listening for Router Advertisement (RA) packets broadcast by one or more routers on the link. Each RA can contain zero or more "options," each describing one piece of configuration (e.g. a single route). Currently, when we receive an RA from a router, we delete any addresses, routes, etc. that originated from that router's previous RAs unless they're also present as options in the new RA. That behavior is a violation of RFC 4861[1]. In Section 9, the RFC states that Senders MAY send a subset of options in different packets. ... Thus, a receiver MUST NOT associate any action with the absence of an option in a particular packet. This protocol specifies that receivers should only act on the expiration of timers and on the information that is received in the packets. Several other passages in the RFC reiterate this. Section 6.2.3: A router MAY choose not to include some or all options when sending unsolicited Router Advertisements. Section 6.3.4: Hosts accept the union of all received information; the receipt of a Router Advertisement MUST NOT invalidate all information received in a previous advertisement or from another source. At least one consumer router in production today, the Google Nest Wifi, often sends RAs that omit its global IPv6 prefix. When current versions of systemd-networkd receive those RAs, they immediately delete the interface's global IPv6 address, which breaks IPv6 connectivity. Fix the issue by removing the invalidation logic entirely. It's not needed at all, since we already invalidate addresses, routes, and DNS configuration when the interface goes down or their lifetimes expire. This fix does have the side effect of preventing changes to the .network file (e.g. denylisted prefixes, whether to add routes from RAs) from taking effect as soon as a new RA arrives. Instead, a full interface reconfiguration is needed. But triggering those changes on RA receipt was already rather arbitrary and out of the administrator's control, so I think this change is fine. commit 69203fba700e ("network: ndisc: remove old addresses and routes after at least one SLAAC address becomes ready") introduced this behavior. commit 50550722e3ba fixed it partially, by preventing one router's RAs from invalidating another router's configuration. [1] https://www.rfc-editor.org/rfc/rfc4861 Fixes: 69203fba700e ("network: ndisc: remove old addresses and routes after at least one SLAAC address becomes ready")
* network: introduce TCPCongestionControlAlgorithm=Yu Watanabe2022-08-261-0/+2
| | | | Closes #24432.
* network: re-design request queueYu Watanabe2022-03-111-3/+0
| | | | | | | | This makes Request object takes hash, compare, free, and process functions. With this change, the logic in networkd-queue.c can be mostly independent of the type of the request or the object (e.g. Address) assigned to the request, and it becomes simpler.
* network: introduce request_call_netlink_async()Yu Watanabe2022-03-111-3/+10
| | | | | | | | | | | | | | | | | | | | | In most netlink handlers, we do the following, 1. decrease the message counter, 2. check the link state, 3. error handling, 4. update link state via e.g. link_check_ready(). The first two steps are mostly common, hence let's extract it. Moreover, this is not only extracting the common logic, but provide a strong advantage; `request_call_netlink_async()` assigns the relevant Request object to the userdata of the netlink slot, and the request object has full information about the message we sent. Hence, in the future, netlink handler can print more detailed error message. E.g. when an address is failed to configure, then currently we only show an address is failed to configure, but with this commit, potentially we can show which address is failed explicitly. This does not change such error handling yet. But let's do that later.
* network: make request_process_address() and friends take Link and ↵Yu Watanabe2022-03-111-1/+1
| | | | | | | | | | | | | | | | | corresponding object This also renames e.g. request_process_address() -> address_process_request(). Also, this drops type checks such as `assert(req->type == REQUEST_TYPE_ADDRESS)`, as in the later commits, the function of processing request, e.g. `address_process_request()`, will be assigned to the Request object when it is created. And the request type will be used to distinguish and to avoid deduplicating requests which do not have any assigned objects, like REQUEST_TYPE_DHCP4_CLIENT. Hence, the type checks in process functions are mostly not necessary and redundant. This is mostly cleanups and preparation for later commits, and should not change any behavior.
* network: remove only managed configs on reconfigure or carrier lostYu Watanabe2022-02-011-1/+1
| | | | | | Otherwise, if the carrir of the non-managed interface is lost, the configs such as addresses or routes on the interface will be removed by networkd.
* network: rename NetworkConfigSection -> ConfigSectionYu Watanabe2022-01-191-2/+2
| | | | And move it and relevant functions to conf-parser.[ch].
* network: route: make route_cancel_request() take Link*Yu Watanabe2021-12-061-1/+1
| | | | As the Route object may be managed by Manager.
* network: route: expose route_hash_opsYu Watanabe2021-11-301-0/+1
|
* network: split networkd-route.[ch]Yu Watanabe2021-11-141-6/+0
|
* network: manage route and nexthop flagsYu Watanabe2021-11-131-2/+2
|
* network: delay dropping addresses or so on reloading .network filesYu Watanabe2021-10-261-0/+1
| | | | | | | When a .network file is updated but its change is not so big, it is not necessary to first drop all configs and then reassign later again. This slightly optimize such situation. First foreignize all configs, and then drop later when it is not requested by the updated .network file.
* network: route: rename lifetime -> lifetime_usecYu Watanabe2021-10-211-1/+4
|
* network: make several hash_ops staticYu Watanabe2021-10-041-1/+0
|
* network: use NetworkConfigSource/State to manage addresses and routesYu Watanabe2021-09-241-7/+11
| | | | This also fixes #20146.
* network: do not use RouteTable= in [DHCPv4] section for DHCPv6 routesYu Watanabe2021-09-141-3/+0
| | | | | We forgot to add RouteTable= in [DHCPv6] section when we split [DHCP] into two.
* network: fix logic for checking gateway address is readyYu Watanabe2021-08-221-1/+1
| | | | | | | | | This fixes the followings: - The corresponding route or address to the gateway address must be in the same link. - IPv6 link local address is not necessary to be reachable. Fixes an issue reported in https://github.com/systemd/systemd/issues/8686#issuecomment-902562324.
* network: use address_equal()/route_equal() to compare addresses or routes ↵Yu Watanabe2021-08-041-0/+1
| | | | | | configured by NDisc Fixes #20244.
* network: make manager_find_uplink() uses stored route informationYu Watanabe2021-06-071-0/+1
| | | | | | | networkd already has all information about routes. It is not necessary to re-read them by using local_gateways(). This also makes manager_find_uplink() take family.
* network: drop unused "callback" arguments in route_remove() and address_remove()Yu Watanabe2021-05-191-2/+1
|