Yutaro Hayakawa 6e61cd407d Add a basic support for nexthop
Add a basic support of Linux's ip nexthop equivalent. In this PR, I
specifically focused on implementing a minimal feature to accomplish
IPv4 prefix with IPv6 (link-local) nexthop which is used by various
implementation like FRR to support technique called BGP Unnumbered.

The summary of the new features are:

- Introduce a low level primitive for nexthop in the nl package
- Introduce NexthopAdd/Del/List/Replace APIs (supports
  NHA_ID/BLACKHOLE/GATEWAY, and protocol field)
- Introduce NHID field to the Route object which allows attaching
  nexthop to routes.

Signed-off-by: Yutaro Hayakawa <yutaro.hayakawa@isovalent.com>

=== Squashed Commits ===

nl: Fix some wrong error and done message handling

The current logic of parsing ERROR and DONE message is, first reads
error field and when NLM_F_ACK_TLVS exists, tries to read the original
request header, payload of the request, and extended ACK.

We have three issues here:

1. The existence of the original request header is not indicated by
   NLM_F_ACK_TLVS flag. At least the original request header always
   exists.
2. We are missing the check for NLM_F_CAPPED flag. When the flag exists,
   the payload of the request doesn't exist. In that case, we shouldn't
   try to skip the payload. Otherwise, we may end up with the
   out-of-range read.
3. NLMSG_DONE doesn't contain the original request, so we shouldn't
   apply original request parsing logic to it.

In this commit, we fix these issues by:

1. We first check the existence of the NLM_F_CAPPED. When it exists,
   only skip the original request header. Otherwise, skip the payload as
   well. Don't apply this logic to the DONE message.
2. After that, check the existence of the NLM_F_ACK_TLVS. When it
   exists, try to read extended ACK for both of DONE and ERROR messages.
   Otherwise, don't.

Ref: https://docs.kernel.org/userspace-api/netlink/intro.html#netlink-message-types

Signed-off-by: Yutaro Hayakawa <yutaro.hayakawa@isovalent.com>

nexthop: Add a low-level API for the nexthop

Preparation for the support of the nexthop object.

Signed-off-by: Yutaro Hayakawa <yutaro.hayakawa@isovalent.com>

Add basic operation for nexthop

Add a basic support of the Linux's nexthop object (ip nexthop XXX). This
commit aims to introduce a basic operations (add, list, del) with
minimal attributes. Further features can be added later incrementally.

Signed-off-by: Yutaro Hayakawa <yutaro.hayakawa@isovalent.com>

nexthop: Support NHA_OIF

It can be used for expressing direct nexthop on specific link.

Signed-off-by: Yutaro Hayakawa <yutaro.hayakawa@isovalent.com>

nexthop: Support NHA_GATEWAY

It can express an IP nexthop. A unique use case we can accomplish by
this is attaching IPv6 nexthop to the routes with an IPv4 prefix which
we cannot do with the existing `ip route` equivalents.

Signed-off-by: Yutaro Hayakawa <yutaro.hayakawa@isovalent.com>

nexthop: Support protocol

Allow setting protocol for nexthop.

Signed-off-by: Yutaro Hayakawa <yutaro.hayakawa@isovalent.com>

route: Support RTA_NHID

Support attaching nexthop object to route object via NHID field.

Signed-off-by: Yutaro Hayakawa <yutaro.hayakawa@isovalent.com>

nexthop: Add Replace operation support

Add `ip nexthop replace` equivalent

Signed-off-by: Yutaro Hayakawa <yutaro.hayakawa@isovalent.com>
2025-10-31 23:37:11 -07:00
2025-09-11 09:44:45 -07:00
2025-10-31 23:37:11 -07:00
2020-09-24 21:36:22 -04:00
2020-06-03 11:20:50 -07:00
2024-09-22 00:00:40 -07:00
2022-12-14 10:59:49 -08:00
2024-09-22 00:00:40 -07:00
2025-03-26 11:10:41 -07:00
2024-09-22 00:00:40 -07:00
2024-09-22 00:00:40 -07:00
2025-03-27 22:15:54 -07:00
2014-08-31 20:34:46 -07:00
2024-09-22 00:00:40 -07:00
2018-10-29 15:31:34 -07:00
2021-09-21 09:10:48 -05:00
2025-10-31 23:37:11 -07:00
2017-02-04 16:48:17 -08:00
2022-01-12 16:57:20 -06:00
2025-10-31 23:37:11 -07:00
2025-10-31 23:37:11 -07:00
2025-10-31 23:37:11 -07:00
2024-09-22 00:00:40 -07:00
2024-09-22 00:00:40 -07:00
2024-01-26 09:08:48 -08:00
2024-01-26 09:08:48 -08:00
2024-02-21 09:21:27 -08:00
2024-09-22 00:00:40 -07:00
2024-09-22 00:00:40 -07:00
2023-10-24 10:58:52 -07:00

netlink - netlink library for go

Build Status GoDoc

The netlink package provides a simple netlink library for go. Netlink is the interface a user-space program in linux uses to communicate with the kernel. It can be used to add and remove interfaces, set ip addresses and routes, and configure ipsec. Netlink communication requires elevated privileges, so in most cases this code needs to be run as root. Since low-level netlink messages are inscrutable at best, the library attempts to provide an api that is loosely modeled on the CLI provided by iproute2. Actions like ip link add will be accomplished via a similarly named function like AddLink(). This library began its life as a fork of the netlink functionality in docker/libcontainer but was heavily rewritten to improve testability, performance, and to add new functionality like ipsec xfrm handling.

Local Build and Test

You can use go get command:

go get github.com/vishvananda/netlink

Testing dependencies:

go get github.com/vishvananda/netns

Testing (requires root):

sudo -E go test github.com/vishvananda/netlink

Examples

Add a new bridge and add eth1 into it:

package main

import (
    "fmt"
    "github.com/vishvananda/netlink"
)

func main() {
    la := netlink.NewLinkAttrs()
    la.Name = "foo"
    mybridge := &netlink.Bridge{LinkAttrs: la}
    err := netlink.LinkAdd(mybridge)
    if err != nil  {
        fmt.Printf("could not add %s: %v\n", la.Name, err)
    }
    eth1, _ := netlink.LinkByName("eth1")
    netlink.LinkSetMaster(eth1, mybridge)
}

Note NewLinkAttrs constructor, it sets default values in structure. For now it sets only TxQLen to -1, so kernel will set default by itself. If you're using simple initialization(LinkAttrs{Name: "foo"}) TxQLen will be set to 0 unless you specify it like LinkAttrs{Name: "foo", TxQLen: 1000}.

Add a new ip address to loopback:

package main

import (
    "github.com/vishvananda/netlink"
)

func main() {
    lo, _ := netlink.LinkByName("lo")
    addr, _ := netlink.ParseAddr("169.254.169.254/32")
    netlink.AddrAdd(lo, addr)
}

Future Work

Many pieces of netlink are not yet fully supported in the high-level interface. Aspects of virtually all of the high-level objects don't exist. Many of the underlying primitives are there, so its a matter of putting the right fields into the high-level objects and making sure that they are serialized and deserialized correctly in the Add and List methods.

There are also a few pieces of low level netlink functionality that still need to be implemented. Routing rules are not in place and some of the more advanced link types. Hopefully there is decent structure and testing in place to make these fairly straightforward to add.

Description
Simple netlink library for go.
Readme 8.3 MiB
Languages
Go 99.9%