Я пытаюсь реализовать 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.