Назад | Перейти на главную страницу

Хост Mininet не отвечает на пинг

Я пытаюсь реализовать MPLS на mininet, и мне это удалось. Я могу правильно вставлять, менять местами и вставлять теги.

У меня возникают трудности, когда я пытаюсь выполнить эхо-запрос с одного хоста на другой. Это сеть, с которой я работаю:

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

Я заметил, что когда r4 доставляет пакет на s4, s4 ничего с ним не делает и никогда не достигает хоста (h4), поэтому я решил полностью удалить переключатели и просто использовать хосты и маршрутизаторы.

h1 - r1 - r5 - r8 - r4 - h4

и я начал захватывать то, что получает h4, и заметил, что он получает пинг от h1 (10.0.1.10), но h4 (10.0.4.10) никогда не отвечает.

Это вывод на 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

это таблица маршрутизации h4 и у нее есть шлюз:

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

любая помощь приветствуется.

ОБНОВИТЬ

netstat -s of h4 перед тестированием

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 of h4 после тестирования

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

Сначала я использовал статическую маршрутизацию, это маршруты:

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

Затем я заменяю его на 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  

любая помощь приветствуется.

ОБНОВИТЬ

Приложенный снимок wirehark подтверждает, что h4 не отвечает

Листинг 172.16.219.2 в /etc/resolv.conf в настоящее время кажется бесполезным.

Проверьте, может ли h4 пинговать свой собственный адрес обратной связи, затем проверьте связь с его адресом 10.0.4.10. Взгляните, есть ли подсказки в dmesg или syslog.

Убедитесь, что iptables или другой фильтр пакетов не принимает политическое решение, которое предотвращает доставку входящего пакета (tcpdump его видел, но, возможно, конечная точка ядра нет) или предотвращает доставку исходящего ответа.

Посмотреть несколько первых разделов h4 netstat -s вывода и обратите внимание, какие счетчики увеличиваются между началом и концом вашего экспериментального исследования.

Вы показали нам один входящий пакет в 18: 11: 31.984633, за которым последовал промах кэша ARP для маршрутизатора по умолчанию. Если h1 постоянно отправляет эхо-запросы, а h4 не имеет промаха кеша, видим ли мы разные результаты?

H1 стимулирует тестируемую систему пакетом ICMP. При использовании tcpdump для прослушивания трехстороннего рукопожатия попробуйте другой стимул от h1, возможно, порт 22 или порт 80: telnet 10.0.4.10 80

РЕДАКТИРОВАТЬ: Вы заметили, что «[после удаления] маршрутов для использования MPLS возникла проблема». Это говорит о том, что пакеты не уходят по маршруту по умолчанию. Попробуйте исходящий стимул (например, пинг), чтобы определить, видит ли r4 даже пакеты, которые, как вы надеетесь, исходят из h4.

И в netstat -s недостижение +8 ICMP dest кажется проблемой, снова указывая на статический маршрут против вашего маршрута по умолчанию. Он совпадает с +0 отправленными ICMP, что вы уже подтвердили с помощью tcpdump.