IP estático da bridge Linux usando apenas uma NIC

2

Parece que tenho um problema genérico, mas não consigo encontrar nenhuma solução - todas as soluções que encontrei até agora em internets não funcionam para mim. Deixe-me primeiro tentar explicar o que estou tentando fazer - eu tenho uma caixa linux com três interfaces - uma é o uplink indo para o provedor e duas outras devem ser duas partes físicas de uma única rede lógica. Então eu tenho o seguinte:

br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1488
    inet 10.0.0.1  netmask 255.0.0.0  broadcast 10.255.255.255
    ether 00:24:9b:04:3b:a7  txqueuelen 0  (Ethernet)
    RX packets 102156  bytes 8545914 (8.1 MiB)
    RX errors 0  dropped 0  overruns 0  frame 0
    TX packets 44194  bytes 7959306 (7.5 MiB)
    TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
eth1: flags=4419<UP,BROADCAST,RUNNING,PROMISC,MULTICAST>  mtu 1488
    ether 00:24:9b:04:3f:ae  txqueuelen 1000  (Ethernet)
    RX packets 56553  bytes 4992101 (4.7 MiB)
    RX errors 0  dropped 0  overruns 0  frame 0
    TX packets 15920  bytes 4418268 (4.2 MiB)
    TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
eth2: flags=4419<UP,BROADCAST,RUNNING,PROMISC,MULTICAST>  mtu 1488
    ether 00:24:9b:04:3b:a7  txqueuelen 1000  (Ethernet)
    RX packets 56298  bytes 7582661 (7.2 MiB)
    RX errors 0  dropped 0  overruns 0  frame 0
    TX packets 64175  bytes 8148316 (7.7 MiB)
    TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

br0 está criando uma ponte entre eth1 e eth2 e também deve ter um endereço estático usado como gateway. Agora aqui está o problema - se eu estou no gateway e eu tento pingar uma caixa no segmento anexado a eth2 - tudo funciona - arp é resolvido e icmp flui, mas se eu estou tentando pingar algo no segmento eth1 - eu vejo solicitações arp na eth2 e obviamente nada acontece.

Então, em geral, meu problema é que bridge está usando apenas UM endereço MAC - aquele que a eth2 tem. Quaisquer sugestões para documentação que eu possa ter perdido ou sugestões são bem-vindas!

Obrigado!

Informações adicionais conforme solicitado:

# ip r sh
default dev ppp0  scope link
10.0.0.0/8 dev br0  proto kernel  scope link  src 10.0.0.1
192.168.101.115 dev ppp0  proto kernel  scope link  src 192.168.6.59

# ip link sh
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN mode DEFAULT
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT qlen 1000
link/ether da:f3:53:e3:69:84 brd ff:ff:ff:ff:ff:ff
3: tunl0: <NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT
link/ipip 0.0.0.0 brd 0.0.0.0
4: eth1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1488 qdisc pfifo_fast master br0 state UP mode DEFAULT qlen 1000
link/ether 00:24:9b:04:3f:ae brd ff:ff:ff:ff:ff:ff
5: eth2: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1488 qdisc pfifo_fast master br0 state UP mode DEFAULT qlen 1000
link/ether 00:24:9b:04:3b:a7 brd ff:ff:ff:ff:ff:ff
6: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1488 qdisc noqueue state UP mode DEFAULT
link/ether 00:24:9b:04:3b:a7 brd ff:ff:ff:ff:ff:ff
12: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc pfifo_fast state UNKNOWN mode DEFAULT qlen 3
link/ppp

# brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.00249b043ba7       no              eth1
                                                    eth2

Ok, uma atualização curta dependendo da ordem de ifconfig / brctl addif - eu posso fazer com que ela envie pacotes via eth1 ou eth2.

    
por w1nter 23.05.2013 / 21:01

1 resposta

0

Eu não sei sobre NICs USB, mas é comum que as placas WLAN descartem qualquer quadro de saída com um MAC de origem que não seja deles.

Sua solicitação ARP transmitida pode estar deixando br0 com o MAC de origem a7 . O eth2 também tem o MAC a7 , então ele encaminha o quadro, no entanto, o eth1 tem o MAC ae , então ele cai no quadro.

Você pode confirmar isso alterando o MAC da bridge manualmente ( ip link set dev br0 address <MAC> ), primeiro para o ae MAC e verificando se sua interface "working" muda de eth2 para eth1, então para algum novo MAC aleatório e vendo se nenhuma das interfaces encaminhar o tráfego.

    
por 24.05.2013 / 14:09