Não é possível se comunicar com a rede no segundo NIC

1

Estou executando o XenServer 6.2 com duas NICs em sub-redes separadas:

xenbr0 : 192.168.1.50
xenbr1 : 192.168.0.50

O .1.50 NIC se comunica com uma rede interna e funciona perfeitamente. O .0.50 é conectado diretamente ao roteador externo, mas não consegue nem mesmo gerenciar um ping.

Aqui estão algumas coisas que podem ajudar:

[root@voltaire ~]# ip route
192.168.1.0/24 dev xenbr0  proto kernel  scope link  src 192.168.1.50 
192.168.0.0/24 dev xenbr1  proto kernel  scope link  src 192.168.0.50

[root@voltaire ~]# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
   link/ether 00:13:3b:0e:ae:55 brd ff:ff:ff:ff:ff:ff
3: eth2: <NO-CARRIER,BROADCAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
   link/ether 00:13:3b:0e:ae:56 brd ff:ff:ff:ff:ff:ff
4: eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
   link/ether 00:25:22:e0:a9:ce brd ff:ff:ff:ff:ff:ff
5: xenbr1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN 
   link/ether 00:13:3b:0e:ae:55 brd ff:ff:ff:ff:ff:ff
6: xenbr0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN 
   link/ether 00:25:22:e0:a9:ce brd ff:ff:ff:ff:ff:ff
7: xenbr2: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN 
   link/ether 00:13:3b:0e:ae:56 brd ff:ff:ff:ff:ff:ff
8: vif1.0: <BROADCAST,NOARP,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 32
   link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
9: vif1.1: <BROADCAST,NOARP,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 32
   link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
10: tap1.0: <BROADCAST,NOARP,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 500
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
11: tap1.1: <BROADCAST,NOARP,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 500
   link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff

[root@voltaire ~]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   inet 127.0.0.1/8 scope host lo
2: eth1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
   link/ether 00:13:3b:0e:ae:55 brd ff:ff:ff:ff:ff:ff
3: eth2: <NO-CARRIER,BROADCAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
   link/ether 00:13:3b:0e:ae:56 brd ff:ff:ff:ff:ff:ff
4: eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
    link/ether 00:25:22:e0:a9:ce brd ff:ff:ff:ff:ff:ff
5: xenbr1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN 
   link/ether 00:13:3b:0e:ae:55 brd ff:ff:ff:ff:ff:ff
   inet 192.168.0.50/24 brd 192.168.0.255 scope global xenbr1
6: xenbr0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN 
   link/ether 00:25:22:e0:a9:ce brd ff:ff:ff:ff:ff:ff
   inet 192.168.1.50/24 brd 192.168.1.255 scope global xenbr0
7: xenbr2: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN 
   link/ether 00:13:3b:0e:ae:56 brd ff:ff:ff:ff:ff:ff
8: vif1.0: <BROADCAST,NOARP,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 32
   link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
9: vif1.1: <BROADCAST,NOARP,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 32
   link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
10: tap1.0: <BROADCAST,NOARP,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 500
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
11: tap1.1: <BROADCAST,NOARP,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 500
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff

[root@voltaire ~]# ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=128 time=10.0 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=128 time=0.718 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=128 time=0.681 ms
^C
--- 192.168.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2017ms
rtt min/avg/max/mdev = 0.681/3.809/10.029/4.398 ms

[root@voltaire ~]# ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
From 192.168.0.50 icmp_seq=1 Destination Host Unreachable
From 192.168.0.50 icmp_seq=2 Destination Host Unreachable
From 192.168.0.50 icmp_seq=3 Destination Host Unreachable
^C
--- 192.168.0.1 ping statistics ---
5 packets transmitted, 0 received, +3 errors, 100% packet loss, time 4026ms, pipe 3

Eu passei as últimas 6 horas passando por todos os artigos que posso encontrar. Eu apliquei todas as correções mencionadas, mas nada parece funcionar.

Vamos começar com o óbvio:

  1. Tenho certeza de que o cabo de rede está conectado.
  2. Tenho certeza de que todos os endereços IP estão corretos e de que não há conflitos.
  3. Eu tentei configurar o NAT via iptables (mesmo que isso não seja necessário porque eu não estou tentando NAT com esta caixa)
  4. Eu tentei configurar várias tabelas de roteamento (também um pouco estranho, eu sinto, já que eu não consigo nem pingar de ambas as interfaces)

Espero que alguém aqui possa descobrir o que estou perdendo porque estou no fim da minha corda.

iptables para Giedrius Rekasius

[root@voltaire ~]# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
RH-Firewall-1-INPUT  all  --  anywhere             anywhere            

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
RH-Firewall-1-INPUT  all  --  anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
Chain RH-Firewall-1-INPUT (2 references)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     icmp --  anywhere             anywhere            icmp any 
ACCEPT     esp  --  anywhere             anywhere            
ACCEPT     ah   --  anywhere             anywhere            
ACCEPT     udp  --  anywhere             224.0.0.251         udp dpt:mdns 
ACCEPT     udp  --  anywhere             anywhere            udp dpt:ipp 
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:ipp 
ACCEPT     udp  --  anywhere             anywhere            udp dpt:bootps
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED 
ACCEPT     udp  --  anywhere             anywhere            state NEW udp dpt:ha-cluster 
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:ssh 
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:http 
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:https 
REJECT     all  --  anywhere             anywhere            reject-with icmp-host-prohibited 

Além disso, por sua pergunta sobre a configuração da VLAN no roteador: estou usando roteadores separados, um para cada sub-rede, portanto não tenho VLANs configuradas. Cada roteador é responsável por toda a classe C.

brctl show para Peter

[root@voltaire ~]# brctl show
bridge name bridge            idSTP enabledinterfaces
xenbr0      0000.002522e0a9ce no    eth0
                                    vif1.0
                                    tap1.0
xenbr1      0000.00133b0eae55 no    eth1
                                    vif1.1
                                    tap1.1
xenbr2      0000.00133b0eae56 no    eth2

Eu não tenho certeza de qual 'xen bridge hack script feio' você se refere, esta é a minha primeira incursão em redes no XenServer e praticamente tudo neste momento parece meio feio / hacky.

Se isso ajudar, eu mesmo não criei as interfaces da bridge. Eu só passei pelo processo de adicionar as interfaces. Tudo está aparecendo corretamente no XenCenter, no entanto.

    
por Isaac Hildebrandt 01.07.2014 / 10:09

1 resposta

1

Aparentemente, eu não cobri o suficiente das soluções óbvias primeiro. Eu nunca executei sysctl -p , então o encaminhamento de IP nunca foi ativado.

Eu gostaria de renunciar oficialmente ao meu chapéu de nerd. Alguém mais qualificado do que eu deveria aceitar.

    
por 01.07.2014 / 16:26