eth0과 eth1이 브리지된 Debian 8.3 시스템을 설정하려고 하는데 브리지를 통해 패킷을 가져올 수 없습니다. 현재 eth0은 DHCP 서버를 포함한 다른 많은 호스트와 함께 LAN에 연결되어 있습니다. Eth1은 일반 스위치에 연결되어 머신에 연결됩니다.
이것은 내 /etc/network/interfaces입니다.
iface eth0 inet manual
iface eth1 inet manual
allow-hotplug br0
auto br0
iface br0 inet static
bridge_ports eth0 eth1
address 172.16.1.111
netmask 255.255.0.0
broadcast 172.16.255.255
gateway 172.16.1.254
dns-servers 172.16.1.1
/proc/sys/net/ipv4/ip_forward가 1로 설정됩니다.
eth1 네트워크에 연결된 테스트 머신에서 실행된 tcpdump에 따르면 테스트 머신은 DHCP 요청을 보내고 있지만 브리지 호스트에서 실행된 tcpdump에 따르면 그러한 요청을 받지 못하고 있습니다.
eth1에 연결된 스위치에 연결된 다른 호스트도 테스트 시스템이 실제로 DHCP 요청을 보내고 있음을 확인할 수 있지만 브리지 호스트에서 tcpdump를 실행하면 들어오는 DHCP 요청이 표시되지 않습니다.
브리지 호스트의 eth1에서 tcpdump를 실행하면 네트워크의 eth0 측에서 나오는 것으로 추정되는 패킷이 표시됩니다. 그러나 tcpdump에서 이러한 패킷이 eth1에서 나가고 있다고 주장하더라도 eth1의 어떤 호스트에서도 이를 볼 수 없습니다. 모든 패킷을 네트워크로 연결합니다. 그들을.
eth1에 연결된 테스트 시스템에 고정 IP 172.16.1.112를 제공하면 브리지 호스트(172.16.1.111)로부터 핑 응답을 받지 못합니다. 스위치에 연결된 다른 호스트는 172.16.1.111 요청이 있는 arp를 만드는 테스트 호스트를 볼 수 있지만 브리지 호스트의 eth1에서 tcpdump를 실행하면 들어오는 arp 요청이 표시되지 않습니다.
네트워크 브리지를 모두 삭제하고 eth1에 IP 192.168.200.1을 할당하고 테스트 머신의 IP를 eth1에 192.168.200.2로 삽입한 다음 ping과 ssh를 실행하면 모든 것이 정상이므로 물리적인 문제가 없음을 나타냅니다. 네트워크 연결. 또한 두 인터페이스 모두에 대한 "ifconfig ethx promisc up"도 도움이 되지 않았습니다.
ifconfig에서:
br0 Link encap:Ethernet HWaddr 00:22:19:d5:48:a5
inet addr:172.16.1.111 Bcast:172.16.255.255 Mask:255.255.0.0
inet6 addr: fe80::222:19ff:fed5:48a5/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1789546 errors:0 dropped:0 overruns:0 frame:0
TX packets:7077 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:89574606 (85.4 MiB) TX bytes:1096756 (1.0 MiB)
eth0 Link encap:Ethernet HWaddr 00:22:19:d5:48:a5
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:1796423 errors:0 dropped:6430 overruns:0 frame:0
TX packets:7124 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:123614592 (117.8 MiB) TX bytes:1159358 (1.1 MiB)
Interrupt:16
eth1 Link encap:Ethernet HWaddr 00:22:19:d5:48:a6
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:6437 errors:0 dropped:6435 overruns:0 frame:0
TX packets:1782083 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1737578 (1.6 MiB) TX bytes:121076196 (115.4 MiB)
Interrupt:17
ebtables에 대해서는 다른 곳에서 이야기한 적이 있는데, 여기에 내 내용이 있습니다.
root@face:~# ebtables -L
Bridge table: filter
Bridge chain: INPUT, entries: 0, policy: ACCEPT
Bridge chain: FORWARD, entries: 0, policy: ACCEPT
Bridge chain: OUTPUT, entries: 0, policy: ACCEPT
그리고 iptables는 다음과 같습니다.
# Generated by iptables-save v1.4.21 on Fri Mar 25 12:07:16 2016
*mangle
:PREROUTING ACCEPT [160073:12825881]
:INPUT ACCEPT [125398:10762899]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [2598:515898]
:POSTROUTING ACCEPT [2598:515898]
COMMIT
# Completed on Fri Mar 25 12:07:16 2016
# Generated by iptables-save v1.4.21 on Fri Mar 25 12:07:16 2016
*filter
:INPUT ACCEPT [125467:10767745]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [2631:519386]
COMMIT
# Completed on Fri Mar 25 12:07:16 2016
# Generated by iptables-save v1.4.21 on Fri Mar 25 12:07:16 2016
*nat
:PREROUTING ACCEPT [59097:4965900]
:INPUT ACCEPT [24420:2902790]
:OUTPUT ACCEPT [513:27017]
:POSTROUTING ACCEPT [513:27017]
COMMIT
# Completed on Fri Mar 25 12:07:16 2016
brctl 내용:
root@face:~# brctl show
bridge name bridge id STP enabled interfaces
br0 8000.002219d548a5 no eth0
eth1
root@face:~# bridge link show
2: eth0 state UP : <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 4
3: eth1 state UP : <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 19
root@face:~#
뭔가 멍청한 걸 놓치고 있는 게 틀림없지만 그게 뭔지 알 수가 없어요. 내가 뭘 잘못했나요?
편집하다: 위에 붙여넣은 iptables-save 덤프가 실행 중인 전체 iptables 구성임을 실제로 확인할 수 있습니다. 이제 재부팅 후 iptables-save는 아무것도 반환하지 않습니다.
인터페이스 구성의 br0 섹션에 "bridge_fd 0" 및 "bridge_maxwait 1"도 추가했는데, 이렇게 변경하고 재부팅한 지 10분 정도 지나도 여전히 아무데도 트래픽이 흐르지 않습니다.
eth0과 eth1 라인을 바꿨는데 eth0이 연결된 곳이 br0이 핑에 응답하는 곳인 것 같습니다. 몇 분 동안 핑을 보낸 후에도 여전히 트래픽이 들어오지 않았습니다.
문제를 더 자세히 조사하기 위해 /etc/udev/rules.d/70-pertant-net.rules에서 mac 주소를 교체하여 eth0이 이제 eth1이 되고 eth1이 이전 eth0 mac 주소를 갖게 되었습니다. 재부팅 후에도 br0에는 여전히 eth0의 MAC(현재 eth1)이 있으며 이는 여전히 들어오는 패킷을 승인하는 유일한 측입니다. br0을 eth0 또는 eth1 이외의 세 번째 MAC 주소로 설정할 수 있습니까?
답변1
이것은 매우 오래된 질문이지만 다른 사람들에게 도움이 될 수 있습니다.
잘못 구성하면 Linux 브리지가 패킷을 삭제할 수 있습니다. 저도 같은 문제가 있었는데 다음 정보를 사용하여 문제를 해결할 수 있었습니다.
- https://serverfault.com/questions/347676/linux-bridge-brctl-is-dropping-packets
- https://superuser.com/questions/1211852/why-linux-bridge-doesnt-work
즉, 브리지를 구성하는 몇 가지 옵션이 있습니다.
# do not query iptables for packet routing
echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables
# no additional processing for multicast packets
echo 0 > /sys/devices/virtual/net/br0/bridge/multicast_querier
echo 0 > /sys/devices/virtual/net/br0/bridge/multicast_snooping
답변2
구성이 대략적으로 올바른 것 같습니다(즉, 큰 문제는 보이지 않습니다).
그러나 스패닝 트리 지연 값이 누락되었습니다. 이는 브리지가 시작 후 15초(기본값) 동안 패킷을 전달하지 않음을 의미합니다. bridge_fd
인터페이스 구성에 추가하여 수정되었습니다. 0
다른 관련 브리지가 없으면 이 값을 사용하고, 네트워크에 루프가 발생할 가능성이 있으면 더 큰 값을 사용하십시오.
또한 값을 추가할 때 브릿지 초기화 중에 계속하기 전에 기다려야 하는 최대 시간을 줄이는 것이 좋습니다. 일반적 bridge_maxwait
으로 그보다 1초 더 길게 설정하면 충분하다는 것을 알았습니다 .bridge_fd
bridge_fd 0
bridge_maxwait 1