百度360必应搜狗淘宝本站头条
linux 远程linux 文件命令linux 是什么查看文件 linux删除文件 linux
当前位置：网站首页 > 技术文章 > 正文

Linux 网络设备 - Bridge & Veth Pair

ahcoder 2025-05-26 13:12 6 浏览

我们继续介绍 Linux 中常见的网络设备，今天主要讲的是 Linux Bridge 和 Veth Pair，理解清楚这两种设备对后续理解容器化网络会比较有帮助。

1.veth pair 两端互通

我们先看一下 veth pair，这是成对出现的虚拟网络设备，可以简单想象这是两块网卡，中间有一条网线相连。

通过 ip 命令，可以创建 veth pair，我们创建veth0和veth1，分别绑定 IP 并置为 UP 状态：

$ ip link add veth0 type veth peer name veth1
$ ip link add veth0 type veth peer name veth1

$ ip addr add 10.1.1.100/24 dev veth0
$ ip addr add 10.1.1.101/24 dev veth1

$ ip link set veth0 up
$ ip link set veth1 up

ip a查看一下网络设备状态，veth0和veth1已经正常创建并绑定 IP：

$ ip a
...
20: veth1@veth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 36:c9:5b:1a:6d:9b brd ff:ff:ff:ff:ff:ff
    inet 10.1.1.101/24 scope global veth1
       valid_lft forever preferred_lft forever
    inet6 fe80::34c9:5bff:fe1a:6d9b/64 scope link
       valid_lft forever preferred_lft forever
21: veth0@veth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether c6:5e:14:55:f5:b1 brd ff:ff:ff:ff:ff:ff
    inet 10.1.1.100/24 scope global veth0
       valid_lft forever preferred_lft forever
    inet6 fe80::c45e:14ff:fe55:f5b1/64 scope link
       valid_lft forever preferred_lft forever

我们尝试一下将 vair pair 的一段置为 DOWN，再查看一下网络设备状态，可以看到我只是将veth0置为 DOWN，但是随之veth1也进入 M-DOWN 的状态。因为 veth pair 的两块网络设备彼此对向，当veth0置为 DOWN 时，意味着它无法接受数据，随之另一端veth1也就不能正常工作，所以内核会将其自动置为 M-DOWN，以保持两端的一致性。

$ ip link set veth1 down
$ ip a
20: veth1@veth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 36:c9:5b:1a:6d:9b brd ff:ff:ff:ff:ff:ff
    inet 10.1.1.101/24 scope global veth1
       valid_lft forever preferred_lft forever
21: veth0@veth1: <NO-CARRIER,BROADCAST,MULTICAST,UP,M-DOWN> mtu 1500 qdisc noqueue state LOWERLAYERDOWN group default qlen 1000
    link/ether c6:5e:14:55:f5:b1 brd ff:ff:ff:ff:ff:ff
    inet 10.1.1.100/24 scope global veth0
       valid_lft forever preferred_lft forever
    inet6 fe80::c45e:14ff:fe55:f5b1/64 scope link
       valid_lft forever preferred_lft forever

我们说veth0和veth1逻辑上有一根网线相连，所以理论上通过veth0 ping veth1是能通的，我们试一下：

ping -c 1 -I veth0 10.1.1.101
PING 10.1.1.101 (10.1.1.101) from 10.1.1.100 veth0: 56(84) bytes of data.
From 10.1.1.100 icmp_seq=1 Destination Host Unreachable
--- 10.1.1.101 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

可以看到并不能 ping 通，我们在veth0抓包看下：

tcpdump -n -i veth0
14:41:23.473479 ARP, Request who-has 10.1.1.101 tell 10.1.1.100, length 28
14:41:24.496485 ARP, Request who-has 10.1.1.101 tell 10.1.1.100, length 28
14:41:25.520479 ARP, Request who-has 10.1.1.101 tell 10.1.1.100, length 28

原因是veth0和veth1虽然处在同一网段，但由于是第一次通信，所以 ARP 表中并不存在10.1.1.101的 MAC 信息，需要先发送 ARP Request，但是并没有收到响应。这是因为 Ubuntu 内核中一些默认配置限制导致的，我们先放开限制：

$ echo 1 > /proc/sys/net/ipv4/conf/veth0/accept_local
$ echo 1 > /proc/sys/net/ipv4/conf/veth1/accept_local

现在就能 ping 通了：

$ ping -c 1 -I veth0 10.1.1.101
PING 10.1.1.101 (10.1.1.101) from 10.1.1.100 veth0: 56(84) bytes of data.
64 bytes from 10.1.1.101: icmp_seq=1 ttl=64 time=0.140 ms
--- 10.1.1.101 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms

我们在veth0和veth1抓包看一下过程：

# shell-0
$ tcpdump -n -i veth0 icmp
14:54:33.638414 IP 10.1.1.100 > 10.1.1.101: ICMP echo request, id 12, seq 1, length 64

# shell-1
$ tcpdump -n -i veth1 icmp
14:54:33.638420 IP 10.1.1.100 > 10.1.1.101: ICMP echo request, id 12, seq 1, length 64

# shell-2
$ ping -c 1 -I veth0 10.1.1.101
PING 10.1.1.101 (10.1.1.101) from 10.1.1.100 veth0: 56(84) bytes of data.
64 bytes from 10.1.1.101: icmp_seq=1 ttl=64 time=0.043 ms
--- 10.1.1.101 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms

从shell-0和shell-1的微小的时间戳上的差异，我们可以看到当执行 ping 命令时，veth0先接收到 ICMP Request，随即立刻发送给对端的veth1，但是在两个设备上都没有看到 ICMP Reply，可 ping 命令确实显示 1 packets transmitted。 其实原因很简单，ICMP Reply 是走的 loopback 的口。

$ tcpdump -n -i lo icmp
14:54:33.638441 IP 10.1.1.101 > 10.1.1.100: ICMP echo reply, id 12, seq 1, length 64

我们来看一下数据包的流转过程：

流程大致如下：

  1. 首先 ping 程序构造 ICMP Request，通过 Socket API 发送给内核的网络协议栈；
  2. 在 ping 中我们通过-I veth0指定走veth0网卡，所以协议栈会将数据包交给veth0；
  3. 由于veth0和veth1间有逻辑上存在的网线，数据包会直接交到veth1；
  4. veth1接收到数据包后也不做处理，转手交给内核协议栈；
  5. 内核协议栈在接收到数据包后，发现10.1.1.101是本地的 IP，所以会构造 ICMP Reply的包，查看路由表之后发现10.1.1.101应该走 loopback 的口（ip route show table local）；
  6. loopback 接收到 ICMP Reply 后，转发给内核协议栈；
  7. 最终协议栈将数据包交给 ping 进程，ping 成功收到 ICMP Reply包；

当给veth0和veth1配置 IP 时，内核会自动在local表中添加路由：

$ ip route show table local
local 10.1.1.100 dev veth0 proto kernel scope host src 10.1.1.100
local 10.1.1.101 dev veth1 proto kernel scope host src 10.1.1.101
broadcast 10.1.1.255 dev veth1 proto kernel scope link src 10.1.1.101
broadcast 10.1.1.255 dev veth0 proto kernel scope link src 10.1.1.100
...

2.宿主机与容器间的网络

我们知道在容器里大量用到 namespace 来实现容器间的隔离性，对容器网络也是一样的，我们先看一下在宿主机默认的 namespace 下的网络设备：

$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:cb:f0:b3 brd ff:ff:ff:ff:ff:ff
    inet 192.168.31.92/24 brd 192.168.31.255 scope global dynamic noprefixroute enp1s0
       valid_lft 42114sec preferred_lft 42114sec
    inet6 fe80::b5fc:b1f8:2b4:a62d/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

然后我们创建一个 netns ns1，再查看下ns1中的网络设备：

$ ip netns add ns1
$ ip netns exec ns1 ip a
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
root@bridge1:~#

可以看到在ns1中，只有一个默认创建lo设备，除此之外，所有的路由规则、防火墙规则等也与默认 namespace 是完全隔离的。

这时候我们想将ns1的网络与宿主机打通，就可以考虑使用 veth pair：

# 创建 namespace ns1
$ ip netns add ns1

# 创建 veth pair
$ ip link add veth0 type veth peer name veth1

# 将`veth1`的 netns 设置为`ns1`
$ ip link set veth1 netns ns1

# 分别初始化`veth0`和`veth1`的设置
$ ip addr add 10.1.1.100/24 dev veth0
$ ip link set veth0 up
$ ip netns exec ns1 ip addr add 10.1.1.101/24 dev veth1
$ ip netns exec ns1 ip link set veth1 up

这时候查看默认 namespace 和ns1的网络设备，可以看到veth0和veth1设备配置正常：

$ ip a
...
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:cb:f0:b3 brd ff:ff:ff:ff:ff:ff
    inet 192.168.31.92/24 brd 192.168.31.255 scope global dynamic noprefixroute enp1s0
       valid_lft 41661sec preferred_lft 41661sec
    inet6 fe80::b5fc:b1f8:2b4:a62d/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
10: veth0@if9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether c6:5e:14:55:f5:b1 brd ff:ff:ff:ff:ff:ff link-netns ns1
    inet 10.1.1.100/24 scope global veth0
       valid_lft forever preferred_lft forever
    inet6 fe80::c45e:14ff:fe55:f5b1/64 scope link
       valid_lft forever preferred_lft forever

$ ip netns exec ns1 ip a
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
9: veth1@if10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 36:c9:5b:1a:6d:9b brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.1.1.101/24 scope global veth1
       valid_lft forever preferred_lft forever
    inet6 fe80::34c9:5bff:fe1a:6d9b/64 scope link
       valid_lft forever preferred_lft forever

然后尝试下通过ns1的veth1接口来 ping 默认 namespace 下的veth0，并在veth0上抓包：

# shell-0
$ ip netns exec ns1 ping -c 1 10.1.1.100
PING 10.1.1.100 (10.1.1.100) 56(84) bytes of data.
64 bytes from 10.1.1.100: icmp_seq=1 ttl=64 time=0.143 ms
64 bytes from 10.1.1.100: icmp_seq=2 ttl=64 time=0.046 ms
--- 10.1.1.100 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 1026ms

# shell-1
$ tcpdump -n -i veth0 icmp
08:39:52.182061 IP 10.1.1.101 > 10.1.1.100: ICMP echo request, id 44179, seq 1, length 64
08:39:52.182131 IP 10.1.1.100 > 10.1.1.101: ICMP echo reply, id 44179, seq 1, length 64

因为 veth pair 的特性，所以即便veth0和veth1处在不同的 namespace，它们之间也可以正常通信，并且在veth0网卡上我们可以看到完整的 ICMP Request 和 ICMP Reply 数据包。

还记得在上面的例子中，ICMP Reply 是走的 loopback 的口吗？在当前的场景里，因为veth0和veth1已经在不同的 namespace 下了，所以当veth0在回包时，去路由表local查询，并不会认为veth1 10.1.1.100是本地接口，所以会正常从veth0回包，我们可以看下这两个 namespace 的路由表来验证判断：

$ ip route show table local
local 10.1.1.100 dev veth0 proto kernel scope host src 10.1.1.100
broadcast 10.1.1.255 dev veth0 proto kernel scope link src 10.1.1.100
...
$ ip netns exec ns1 ip route show table local
local 10.1.1.101 dev veth1 proto kernel scope host src 10.1.1.101
broadcast 10.1.1.255 dev veth1 proto kernel scope link src 10.1.1.101

3.容器间的网络

我们刚才看到了在宿主机默认 namespace 和容器 namespace ns1之间，通过 veth pair 可以打通网络，逻辑上就相当于宿主机和容器是两台独立的主机，通过一条网线连接在了一起。

正常一台宿主机里不会只有一个容器，宿主机和容器是一对多的关系，如果要打通容器之间的网络，单纯的依赖 veth pair 也可以做到，但配置就比较复杂，所以在这里我们引入 bridge 来实现。

Linux 的 bridge 是内核提供的虚拟以太网桥，原理上类似于物理交换机，工作在第二层。我们在 Linux 上创建一个 bridge，然后将容器通过 veth pair 插入到这个 bridge 上，以实现容器间的网络互通。

首先创建并启用 bridge br0：

$ brctl addbr br0
$ ip link set br0 up

然后通过 namespace 来模拟容器网络：

# ns0作为容器网络，将 veth pair 的一端放入ns0，另一端插入交换机br0
$ ip netns add ns0
$ ip link add veth0 type veth peer name veth0_br
$ ip link set veth0 netns ns0
$ ip netns exec ns0 ip addr add 10.1.1.100/24 dev veth0
$ ip link set veth0_br up
$ ip netns exec ns0 ip link set veth0 up
$ brctl addif br0 veth0_br

# `ns1`作为容器网络，将 veth pair 的一端放入`ns1`，另一端插入交换机`br0`
$ ip netns add ns1
$ ip link add veth1 type veth peer name veth1_br
$ ip link set veth1 netns ns1
$ ip netns exec ns1 ip addr add 10.1.1.101/24 dev veth1
$ ip link set veth1_br up
$ ip netns exec ns1 ip link set veth1 up
$ brctl addif br0 veth1_br

可以看到容器网络可以正常打通：

ip netns exec ns0 ping -c1 10.1.1.101
PING 10.1.1.101 (10.1.1.101) 56(84) bytes of data.
64 bytes from 10.1.1.101: icmp_seq=1 ttl=64 time=0.058 ms
--- 10.1.1.101 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms

4.容器访问外部网络

在刚才的例子中，处在不同 namespace 的容器网络可以通过 veth pair 与 bridge 相连的方式来相互打通，但是如果容器内想要访问外部的网络，就还需要做一些额外的配置。

这里说明一下我的网络环境，我用来测试的 Ubuntu 的机器是插在一个路由器上的，这个路由器的 IP 是 192.168.31.1，DHCP 的网段是 192.168.31.0/24，为了使容器网络能跟外部网络通信，这里我们采用简单一点的方式，就是将容器的网卡 IP 设置成物理网卡的 IP 处在同一网段。

首先创建 bridge br0：

$ brctl addbr br0
$ ip link set br0 up

然后创建 namespace ns0作为容器网络，创建 veth pair veth0和veth0_br，其一端放入ns0，另一端插入网桥br0（这里注意一下我给veth0配置的 IP 192.168.31.100是物理网络的网段）。

$ ip netns add ns0

$ ip link add veth0 type veth peer name veth0_br
$ ip link set veth0 netns ns0
$ ip netns exec ns0 ip addr add 192.168.31.100/24 dev veth0
$ ip link set veth0_br up
$ ip netns exec ns0 ip link set veth0 up

$ brctl addif br0 veth0_br

这里还有一个重要的配置，是在ns0中将默认路由的网关配置为192.168.31.1这个物理网络的网关。

$ ip netns exec ns0 ip route add default via 192.168.31.1 dev veth0
$ ip netns exec ns0 route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.31.1    0.0.0.0         UG    0      0        0 veth0
192.168.31.0    0.0.0.0         255.255.255.0   U     0      0        0 veth0

此时br0上已经插入了veth0_br网卡，但我们知道如果仅仅是这样是无法与外部网络通信的，我们还需要将物理网卡也插入网桥，这样逻辑上物理路由器、物理网卡、veth0_br和veth0会处在一个二层内。

ip addr add 192.168.31.92/24 dev br0
ip addr del 192.168.31.92/24 dev enp1s0
brctl addif br0 enp1s0

通过这样的配置，容器就能正常访问外部网络了。

$ ip netns exec ns0 ping -c 1 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 39.156.66.10: icmp_seq=1 ttl=46 time=37.3 ms
--- 39.156.66.10 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 2003ms

今天介绍了通过 bridge + veth pair 来实现单节点的容器网络的思路，后续会介绍跨节点的场景下的实现。

相关推荐

Linux系统CPU性能评估（linux cpu性能评估工具）

对于Linux系统观察CPU性能的工具很多，如sar,vmstat,mpstat等，下面我们选最常用的vmstat做一个讲解说明。因为不同的系统同样的命令，结果可能会有差异，如centos和u...

「云计算培训摩尔狮」Linux 内存映射:性能提升的隐藏宝藏

在Linux编程领域，内存管理是一个极为关键的环节，它对应用程序的性能有着重大影响。Linux内存映射，便是一项常常未被充分利用的强大技术。接下来，我们将深入探讨内存映射的概念、工作机制，以及如...

linux服务器磁盘性能测试（linux服务器磁盘性能测试方法）

数据库是一个IO密集型的应用（在热点数据量比服务器可用内存大得多的情况下），IO的性能指标，是应用性能、用户体验的极其关键的一个因素，建议参考如下测试模型，对于FIO测试，标红的参数不能调整，对于单个...

微软Win10五月更新重磅来袭!7大漏洞修复，Linux子系统性能飙升

2025年5月14日，综合IT之家、新浪财经等报道微软这波操作，属实让Win10用户松了口气！就在今天凌晨，微软推送了代号KB5058379的五月累积更新，主打“安全+Linux子系统优化”，覆盖Wi...

Linux 性能更好的ftp客户端 lftp 使用详解

简介LFTP是一个命令行FTP客户端，支持多种文件传输协议，包括FTP、FTPS、HTTP、HTTPS和SFTP。它以其通过镜像、后台操作和脚本支持等特性有效管理复杂传输的能力而闻名。安装U...

Intel 13/14代酷睿最新补丁 Linux 实测!性能几乎没有损失

在Linux发布会上，Intel最近发布了一款最新的补丁，旨在提高13/14代酷睿处理器在Linux系统下的性能。今天，我们将为您详细介绍这款补丁的内容和实测结果。补丁内容Intel的...

Linux 6.15-rc6 发布 修复AMD CPU性能受限等问题 Linus回归樱桃机械键盘轴

LinusTorvalds今天发布了Linux6.15-rc6，并有望在两周内发布稳定版。本周，Linux6.15的合并版本中，6.15-rc6修复了一些意外跳过的TLB刷新问题，...

Linux Kernel 6.12震撼发布:实时性能飙升，开启全新计算时代!

概述LinusTorvalds在邮件列表中宣布推出LinuxKernel6.12，该版本带来了多项重要的更新和功能增强。更新亮点PREEMPT_RT支持主要内容：LinuxKernel...

Linux 系统性能监控工具集sysstat之sar(二)

上一篇介绍了sysstat的配置，存储以及sar如何观察CPU负载情况，这一篇介绍如何使用sar分析内存使用情况以及监控磁盘I/O活动情况上一篇：Linux系统性能监控工具集sysstat之sar（...

一文详解 Linux 性能分析命令:top

top命令是系统管理员必备的工具之一。它可以显示计算机运行时间、登录用户数、CPU负载、内存使用情况以及正在运行的进程列表。熟悉这些指标和界面，可以帮助系统管理员了解系统性能并预防故障。本文旨在帮...

Linux 系统性能监控工具集sysstat之sar(三)完结

原创不易上两篇介绍了sar监控CPU，内存，磁盘I/O活动情况第一篇：Linux系统性能监控工具集sysstat之sar（一）第二篇：Linux系统性能监控工具集sysstat之sar（二）(4)...

在Windows 11 WSL2上运行Ubuntu和原生运行有多大区别?

伴随着WindowsSubsystemforLinux（WSL）技术的不断成熟，越来越多的用户在Windows系统上体验Linux系统。那么相比较直接在设备上安装Linux系统，W...

Linux性能革命!Auto-Cpufreq 2.6重磅更新

Linux性能革命！Auto-Cpufreq2.6重磅更新，全新TUI监控让CPU状态一目了然！你是否经常为Linux系统的CPU频率波动而烦恼？想实时监控性能却找不到合适的工具？现在，auto-...

高性能Linux服务器构建实战:运维监控、性能调优与集群应用

百万级字迹详解实战案例，篇幅因素故只展现pdf目录，完整解析获取方式在篇尾了！目录读者对象Web应用篇（1至第3章）数据备份恢复篇（4至第6章）网络存储应用篇（7和第8章）运维监控与性能优化篇（9和第...

Linux:为什么性能工具需要 BPF 技术

了解更多BPF技术内幕，推荐阅读《BPF之巅：洞悉Linux系统和应用性能》一书。▼BPF是近年来Linux系统技术领域一个巨大的创新。作为Linux内核的一个关键发展节点，其重要程度不亚于虚拟...

一周热门
最近发表
标签列表