主页 / server / 问题 / 1062421
Accepted
Chaoxiang N
Asked: 2021-05-04 08:37:42 +0800 CST

强制mac地址时linux ipv6桥地址不起作用

  • 772

在 ubuntu 焦点上使用 linux 桥接和 ipv6 时，我遇到了一个我想了解的问题。

当我手动设置网桥mac地址时，网桥ipv6地址不再起作用，为什么？

使用系统分配的 MAC 地址进行桥接 [工作正常]

root@node:~# ip link del dev brv6
root@node:~# ip link add name brv6 type bridge
root@node:~# ip -6 address add dev brv6 scope global fdfe::401/118
root@node:~# ip link set dev brv6 up
root@node:~# ping -c2 fdfe::401
PING fdfe::401(fdfe::401) 56 data bytes
64 bytes from fdfe::401: icmp_seq=1 ttl=64 time=0.035 ms
64 bytes from fdfe::401: icmp_seq=2 ttl=64 time=0.029 ms

--- fdfe::401 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1007ms
rtt min/avg/max/mdev = 0.029/0.032/0.035/0.003 ms
root@node:~# ip link show dev brv6
13: brv6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether b2:75:42:d1:de:a9 brd ff:ff:ff:ff:ff:ff

使用手动分配的 mac 地址进行网桥 [不起作用]

root@node:~# ip link del dev brv6
root@node:~# ip link add name brv6 type bridge
root@node:~# ip link set dev brv6 address 6a:58:ea:de:65:79
root@node:~# ip -6 address add dev brv6 scope global fdfe::401/118
root@node:~# ip link set dev brv6 up
root@node:~# ping -c2 fdfe::401
PING fdfe::401(fdfe::401) 56 data bytes
From 2001:321:4321:ab:acf4::1 icmp_seq=1 Destination unreachable: Address unreachable
From 2001:321:4321:ab:acf4::1 icmp_seq=2 Destination unreachable: Address unreachable

--- fdfe::401 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1021ms
root@node:~# ip link show dev brv6
14: brv6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
    link/ether 6a:58:ea:de:65:79 brd ff:ff:ff:ff:ff:ff

谢谢你的帮助。

linux bridge ipv6

1 个回答

  1. Best Answer

    这与 IPv6（第 3 层）没有太大关系，但与接口状态（第 1 层？）有关。这个问题在实际用例中不会发生，因为桥总是至少有一个桥端口。

    当您将网桥置于“自动 MAC 分配模式”时，网桥：

    • 在管理上设置为 UP 时，在操作上是 UP（但驱动程序只是在这里告诉 UNKNOWN）。这取决于链路的运营商状态：

      # ip link show dev brv6
7: brv6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default 
    link/ether c2:15:e6:2f:0e:37 brd ff:ff:ff:ff:ff:ff

    • 将从稍后设置为桥接端口的接口继承 MAC 地址（精确行为可能取决于内核版本）。

    强制 MAC 地址时：

    • 即使在管理上设置为 UP，也会在操作上 DOWN：

      # ip link show dev brv6
8: brv6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether 6a:58:ea:de:65:79 brd ff:ff:ff:ff:ff:ff

      因为 NO-CARRIER 标志强制操作状态保持 DOWN。

    • 不会从任何设置为桥接端口的接口继承 MAC 地址。

    我不知道这种行为的确切理由，但看起来“自动”模式下的桥接器对于其未来的使用是有疑问的，并且在初始设置时被授予免费运营商 UP 状态。

    在任何一种情况下，但这可能取决于内核版本（此处使用 5.13.x 测试），一旦将接口设置为桥端口一次，行为将变得相同：桥需要至少一个端口本身处于操作状态up to be up，例如：

    • 添加 veth 接口作为网桥端口需要 veth 对的两侧都启动以启动载波并在网桥上获得此状态
    • 添加一个虚拟接口只需要虚拟接口启动，因为没有另一面。

    只要操作状态为 DOWN，并非所有从 IPv6 地址创建的自动路由都添加到路由表（在主表ip -6 route或本地表中）和/或在具有linkdown属性ip -6 route show table local时忽略这些路由。最后，无法访问此 IPv6 地址。

    此处的行为可能与 IPv4 不同，在关闭的接口上添加地址仍然可以从其他接口访问它。Linux 的 IPv6 的行为与 Linux 的 IPv4 不同。

    解决此问题的最简单方法是向网桥添加一个虚拟接口。例如像这样启动网桥（使用“压缩”命令）：

    ip link add name brv6 address 6a:58:ea:de:65:79 up type bridge
ip link add name brv6-dummy up master brv6 type dummy

    这给出了（注意实际的 UP 而不是 UNKNOWN）：

    # ip link show dev brv6
9: brv6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 6a:58:ea:de:65:79 brd ff:ff:ff:ff:ff:ff
    • 2

相关问题