O host Mininet não responde ao ping

2

Estou tentando implementar o MPLS no mininet e consegui fazer isso com sucesso. Eu sou capaz de empurrar, trocar e inserir tags corretamente.

Estou com dificuldades quando estou tentando fazer ping de um host para outro. Esta é a rede com a qual estou trabalhando:

h1--s1--r1--r5--r8--r4--s4--h4

Eu notei que quando o r4 entrega o pacote para s4, o s4 não faz nada com ele e nunca chega ao host (h4), então eu decidi remover os switches completamente e apenas usar os hosts e roteadores

h1--r1--r5--r8--r4--h4

e comecei a capturar o que h4 está recebendo, e notei que ele está recebendo o ping de h1 (10.0.1.10), mas h4 (10.0.4.10) nunca responde.

Esta é a saída em h4:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on h4-eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
18:11:31.984633 IP 10.0.1.10 > 10.0.4.10: ICMP echo request, id 5767, seq 1, length 64
18:11:31.984961 ARP, Request who-has 10.0.4.1 tell 10.0.4.10, length 28
18:11:31.984970 ARP, Reply 10.0.4.1 is-at fe:65:4f:0c:2f:17 (oui Unknown), length 28
18:11:31.984972 IP 10.0.4.10.49609 > 172.16.219.2.domain: 52855+ PTR? 10.4.0.10.in-addr.arpa. (40)
18:11:31.984983 IP 10.0.4.1 > 10.0.4.10: ICMP net 172.16.219.2 unreachable, length 76
18:11:36.990650 IP 10.0.4.10.49609 > 172.16.219.2.domain: 52855+ PTR? 10.4.0.10.in-addr.arpa. (40)
18:11:36.990609 ARP, Request who-has 10.0.4.10 tell 10.0.4.1, length 28
18:11:52.006132 IP 10.0.4.10.38978 > 172.16.219.2.domain: 7045+ PTR? 1.4.0.10.in-addr.arpa. (39)
18:12:02.018454 IP 10.0.4.10.45969 > 172.16.219.2.domain: 62742+ PTR? 2.219.16.172.in-addr.arpa. (43)
18:12:02.018478 IP 10.0.4.1 > 10.0.4.10: ICMP net 172.16.219.2 unreachable, length 79

esta é a tabela de roteamento h4 e tem um gateway:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         10.0.4.1        0.0.0.0         UG    0      0        0 h4-eth0
10.0.4.0        *               255.255.255.0   U     0      0        0 h4-eth0

qualquer ajuda é muito apreciada.

UPDATE

netstat -s de h4 antes de testar

Ip:
    1329 total packets received
    0 forwarded
    0 incoming packets discarded
    1329 incoming packets delivered
    1329 requests sent out
Icmp:
    24 ICMP messages received
    0 input ICMP message failed.
    ICMP input histogram:
        destination unreachable: 8
        echo requests: 8
        echo replies: 8
    16 ICMP messages sent
    0 ICMP messages failed
    ICMP output histogram:
        echo request: 8
        echo replies: 8
IcmpMsg:
        InType0: 8
        InType3: 8
        InType8: 8
        OutType0: 8
        OutType8: 8
Tcp:
    1 active connections openings
    1 passive connection openings
    0 failed connection attempts
    0 connection resets received
    2 connections established
    1305 segments received
    1305 segments send out
    0 segments retransmited
    0 bad segments received.
    0 resets sent
Udp:
    0 packets received
    0 packets to unknown port received.
    0 packet receive errors
    8 packets sent
UdpLite:
TcpExt:
    65 delayed acks sent
    856 packet headers predicted
    28 acknowledgments not containing data payload received
    805 predicted acknowledgments
    TCPRcvCoalesce: 14
    TCPOrigDataSent: 974
    TCPKeepAlive: 1
IpExt:
    InOctets: 3413476
    OutOctets: 3413252
    InNoECTPkts: 1329

netstat -s de h4 após o teste

Ip:
    1384 total packets received
    0 forwarded
    0 incoming packets discarded
    1384 incoming packets delivered
    1384 requests sent out
Icmp:
    32 ICMP messages received
    0 input ICMP message failed.
    ICMP input histogram:
        destination unreachable: 16
        echo requests: 8
        echo replies: 8
    16 ICMP messages sent
    0 ICMP messages failed
    ICMP output histogram:
        echo request: 8
        echo replies: 8
IcmpMsg:
        InType0: 8
        InType3: 16
        InType8: 8
        OutType0: 8
        OutType8: 8
Tcp:
    1 active connections openings
    1 passive connection openings
    0 failed connection attempts
    0 connection resets received
    2 connections established
    1352 segments received
    1352 segments send out
    0 segments retransmited
    0 bad segments received.
    0 resets sent
Udp:
    0 packets received
    0 packets to unknown port received.
    0 packet receive errors
    16 packets sent
UdpLite:
TcpExt:
    72 delayed acks sent
    872 packet headers predicted
    28 acknowledgments not containing data payload received
    828 predicted acknowledgments
    TCPRcvCoalesce: 16
    TCPOrigDataSent: 1000
    TCPKeepAlive: 1
IpExt:
    InOctets: 3421472
    OutOctets: 3421024
    InNoECTPkts: 1384

Primeiro eu estava usando o roteamento estático, estas são as rotas:

r1 ip route add 10.0.4.0/24  via 172.16.1.2
r4 ip route add 10.0.1.0/24  via 172.16.4.2
r5 ip route add 10.0.1.0/24  via 172.16.1.1
r5 ip route add 10.0.4.0/24  via 172.16.8.2
r8 ip route add 10.0.1.0/24 via 172.16.8.1
r8 ip route add 10.0.4.0/24 via 172.16.4.1

Então eu o substituo por MPLS:

r1 ip route add 10.0.4.0/24 encap mpls 400 via inet 172.16.1.2
r5 ip -f mpls route add 400 as 400 via inet 172.16.8.2
r8 ip -f mpls route add 400 as 400 via inet 172.16.4.1
r4 ip -f mpls route add 400 dev r4-eth0

r4 ip route add 10.0.1.0/24 encap mpls 100 via inet 172.16.4.2
r8 ip -f mpls route add 100 as 100 via inet 172.16.8.1
r5 ip -f mpls route add 100 as 100 via inet 172.16.1.1
r1 ip -f mpls route add 100 dev r1-eth0  

qualquer ajuda é muito apreciada.

UPDATE

Uma captura wireshark anexada confirma que h4 não está respondendo

    
por Rafael Luciano 04.11.2017 / 16:34

1 resposta

1

A listagem 172.16.219.2 em /etc/resolv.conf não parece ser útil no momento.

Teste se h4 pode executar ping em seu próprio endereço de loopback e, em seguida, teste o ping em seu endereço 10.0.4.10. Dê uma espiada para ver se o dmesg ou o syslog oferecem alguma sugestão.

Verifique se o iptables ou outro filtro de pacotes não está tomando uma decisão política que impeça a entrega do pacote de entrada (tcpdump o viu, mas talvez o ponto de extremidade do kernel não) ou impeça a entrega de uma resposta de saída.

Veja as primeiras seções da saída netstat -s do h4 e observe quais contadores aumentam entre o início e o final do teste experimental.

Você nos mostrou um único pacote de entrada em 18: 11: 31.984633, seguido por falta de cache do ARP para o roteador padrão. Se h1 está continuamente enviando pings, e h4 não tem um erro de cache, vemos resultados diferentes?

H1 está estimulando o sistema em teste com um pacote ICMP. Ao usar o tcpdump para escutar o handshake de três vias, tente outro estímulo de h1, talvez a porta 22 ou a porta 80: telnet 10.0.4.10 80

EDIT: Você observa que "[depois de remover] as rotas para usar MPLS o problema começou." Isso sugere que os pacotes não estão saindo via rota padrão. Tente um estímulo de saída (talvez ping) para ajudar a identificar se o r4 até vê pacotes que você espera que estejam saindo de h4.

E no netstat -s, o +8 ICMP dest unreach parece um problema, apontando novamente para a rota estática versus sua rota padrão. Ele corresponde a +0 ICMPs enviados, algo que você já confirmou com o tcpdump.

    
por 04.11.2017 / 18:55

Tags