Linux
強制mac地址時linux ipv6橋地址不起作用
在 ubuntu 焦點上使用 linux 橋接和 ipv6 時，我遇到了一個我想了解的問題。
當我手動設置網橋mac地址時，網橋ipv6地址不再起作用，為什麼？
具有系統分配的 MAC 地址的網橋$$ Works fine $$
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 地址進行網橋$$ Does not work $$
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謝謝你的幫助。
這與 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