You are not logged in.
I created a SIT tunnel in systemd-networkd, but 2 interfaces turn up. One is the one I created, the other has the default name "sit0" and is always off, and is created by the default link file not my config. Why?
(If I remove my SIT tunnel both of them go away.)
$ networkctl
IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback carrier unmanaged
2 ens3 ether routable configured
3 wireguard-0 wireguard routable configured
4 sit0 sit off unmanaged
5 sit-tunnel sit routable configured
5 links listed.
$ networkctl status sit0
● 4: sit0
Link File: /usr/lib/systemd/network/99-default.link
Network File: n/a
State: off (unmanaged)
Online state: unknown
Type: sit
Kind: sit
Driver: sit
Hardware Address: 00:00:00:00
MTU: 1480 (min: 1280, max: 65555)
QDisc: noop
IPv6 Address Generation Mode: eui64
Number of Queues (Tx/Rx): 1/1
$ networkctl status sit-tunnel
● 5: sit-tunnel
NetDev File: /etc/systemd/network/20-sit-tunnel.netdev
Link File: /usr/lib/systemd/network/99-default.link
Network File: /etc/systemd/network/20-sit-tunnel.network
State: routable (configured)
Online state: online
Type: sit
Kind: sit
Driver: sit
Hardware Address: ac:f5:e2:2b
MTU: 1480 (min: 1280, max: 65555)
QDisc: noqueue
IPv6 Address Generation Mode: none
Local: REDACTED
Remote: REDACTED
Number of Queues (Tx/Rx): 1/1
Address: REDACTED
Gateway: REDACTED
Activation Policy: up
Required For Online: yes
Jan 01 15:32:57 vps systemd-networkd[373]: sit-tunnel: netdev ready
Jan 01 15:32:57 vps systemd-networkd[373]: sit-tunnel: netdev ready
Jan 01 15:32:57 vps systemd-networkd[373]: sit-tunnel: Configuring with /etc/systemd/network/20-sit-tunnel.network.
Jan 01 15:32:57 vps systemd-networkd[373]: sit-tunnel: Link UP
Jan 01 15:32:57 vps systemd-networkd[373]: sit-tunnel: Gained carrier
Last edited by Beemo (2025-01-07 13:45:53)
Offline
from unix.stackexchange.com:
How sit0 comes into play:
You might wonder what happens when Linux receives a protocol 41 packet that doesn't match any of the sit devices (e.g. it came from some random address). In this case, it gets delivered to sit0.
sit0 is a special "fallback" device set up by the sit kernel module to handle just these packets. It has local and remote addresses set to 0.0.0.0 (i.e. "any") and it's not attached to any particular physical device, so it will accept any protocol 41 packet that's not already handled by some other sit device.
Is this useful? Maybe in specific circumstances, but I imagine in the vast majority of cases, you would want to drop such packets. I'm not sure why it's not left up to the administrator whether such a catch-all device should be created. Perhaps there is some historical reason.
Offline