Ping на всички узли IPv6 на канала

Остатъкът от дните до старта на новия курс «Мрежов инженер» от OTUS. Във връзка с това искаме да споделим с вас превод на полезен материал по темата.

Серия статии в блога, посветени на съветите и препоръките за отстраняване на проблеми, свързани с пинга на IPv6 (ICMPv6 Echo Request/Echo Reply)

Обърнете внимание, че използвам Linux (в частност Fedora 31), но синтаксисът на командата ping за други операционни системи, надявам се, ще е много подобен.

Ping на всички узли IPv6 на канала

Първият и най-прост съвет е да пингувате всички IPv6 възли в канала.

IPv6 използва multicast адреси за всички видове връзка «един към много». Няма broadcast (или широковещателни) IPv6 адреси. Това отличава IPv6 от IPv4, където съществуват различни видове broadcast адреси, например, «limited broadcast» адрес 255.255.255.255 [RFC1122].

Въпреки това, съществува адрес за multicast на всички възли (all-nodes multicast) IPv6, така че ще го използваме, за да пингуваме всички IPv6 възли в канала. («Широковещателен» адрес всъщност е просто специално наименован multicast адрес, който е група от многоадресна разпространение, включваща всички възли. Обърнете внимание, че например битът «група» или multicast адресът е включен в broadcast адресите на Ethernet на канално ниво).

All-nodes multicast IPv6 адрес за канала: ff02::1. ff означава multicast IPv6 адрес. Следващото 0 — това е част от флага с неизменени битове.

Напред 2 определя обхвата на multicast групата. За разлика от multicast IPv4 адресите, multicast IPv6 адресите имат scope (обхват). Стойността на scope указва част от мрежата, по която е разрешено разпространението на multicast пакет. Веднъж след като пакетът достигне границата на указаното scope, пакетът трябва да бъде отхвърлен, независимо от това дали полето му за брояча на преходите (Hop Count) е ненулево. Разбира се, ако броячът на преходите достигне нула преди да достигне указаната граница на multicast групата, той също незабавно се изхвърля. Ето пълния списък на multicast scope IPv6.

Накрая, ::1 укажава групата на all-nodes multicast.

За адреса ff02::1 трябва да се отбележи, че той е неясен. На IPv6 възел с няколко интерфейса, като маршрутизатор или многоадресен хост, адресът ff02::1 няма нищо, където да можем да посочим на какъв интерфейс да изпращаме eхо-запроси ICMPv6 или да очакваме получаване на eхо-ответи ICMPv6, когато те пристигнат. ff02::1 валиден е и може да се използва на който и да е от интерфейсите и каналите, свързани с многоинтерфейсен възел.

Следователно, когато пингуваме всички IPv6 възли на канала, трябва по някакъв начин да уведомим утилитата ping за IPv6, кой интерфейс да използва.

Определянето на интерфейсите е параметър на командния ред

Както вече видяхме, multicast адресът all-nodes, който искаме да използваме — ff02::1 не предоставя никаква информация относно това, на кой интерфейс да изпраща и получава пакетите eхо-запрос и eхо-ответ на ICMPv6.

И така, как можем да посочим интерфейса, който ще се използва за мултикаст адресите или юникастовите Link-Local адреси?

Първият и най-очевиден начин е да го предоставим като параметър на приложението, което използваме.

За утилитата ping го предоставяме чрез опцията -I.

[mark@opy ~]$ ping -w 1 -I enp3s2 ff02::1
ping: Warning: source address might be selected on device other than: enp3s2
PING ff02::1(ff02::1) from :: enp3s2: 56 data bytes
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 ms
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.589 ms (DUP!)
64 bytes from fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 time=5.15 ms (DUP!)
64 bytes from fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 time=58.0 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 time=62.3 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 time=62.8 ms (DUP!)
 
--- ff02::1 ping statistics ---
1 packets transmitted, 1 received, +5 duplicates, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.438/31.544/62.786/29.566 ms
[mark@opy ~]$

С помощта на този all-nodes multicast ping получихме отговори от 6 IPv6 възли. Отговорите дойдоха от адресите на Link-Local IPv6 възлите, започващи с префикса fe80::/10.

За да ping не продължаваше безкрайно да изпраща eхо-запроси ICMPv6, докато не го прекратим, обикновено посочваме броя на пакетите за изпращане чрез опцията -c. Въпреки това, това също не позволява на ping да приеме и покаже повече от един eхо-ответ ICMPv6, когато изпраща multicast eхо-запрос ICMPv6. Вместо това използвахме параметъра -w, за да посочим, че ping трябва да завърши след 1 секунда, независимо от това колко eхо-запроса или eхо-ответи ICMPv6 бяха изпратени или получени.

Още нещо, на което да се обърне внимание, е (DUP!) изход на втория и следващите отговори. Тези пакети се идентифицират като дубликати на отговора, тъй като имат същата стойност на ICMP последователността като индивидуалните ехо заявки ICMPv6, които са били изпратени първоначално. Те се появяват, защото многокастовите ехо заявки ICMPv6 водят до няколко индивидуални юникаст отговора. Броят на дубликатите също се посочва в обобщението на статистиката.

Определяне на интерфейсите — Zone ID

Още един начин за предоставяне на интерфейс за употреба е част от параметъра на адреса IPv6.

Можем да наблюдаваме пример за това в изхода на ping, където адресите на отговарящите IPv6 възли също имат суфикс %enp3s2, например:

64 байта от fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 време=0.438 ms

Този метод за задаване на интерфейсите е формално описан в [RFC4007], „Архитектура с зададени IPv6 адреси“. Въпреки че обикновено се наричат интерфейс на операционната система, всъщност те определят нещо по-общо — „зона“ или „област на действие“.

Причината за наличието на по-общи зони или scope зони е, че, както се споменава в [RFC4007], IPv6 възел може да има няколко различни IPv6 интерфейса, свързани към един и същ канал. Тези интерфейси са членове на една зона.

Трябва да бъде възможно да се групират няколко интерфейса в рамките на зона под операционната система; В момента не знам дали това е възможно под Linux и как да стане.

Използвайки суфикса %, можем да премахнем параметъра на командния ред -I ping.

[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 байта данни
64 байта от fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 време=0.106 ms
64 байта от fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 време=0.453 ms (DUP!)
64 байта от fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 време=0.606 ms (DUP!)
64 байта от fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 време=6.23 ms (DUP!)
64 байта от fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 време=157 ms (DUP!)
64 байта от fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 време=159 ms (DUP!)
64 байта от fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 време=161 ms (DUP!)
64 байта от fe80::23d:e8ff:feec:958c%enp3s2: icmp_seq=1 ttl=64 време=179 ms (DUP!)
 
--- ff02::1%enp3s2 ping статистика ---
1 пакета предадени, 1 получен, +7 дубликата, 0% загуба на пакети, време 0ms
rtt min/средно/макс/мdev = 0.106/82.858/179.216/81.281 ms
 
[mark@opy ~]$

Отговори на Link-Local адреси

От този all-nodes multicast ping получихме общо 6 уникални отговора.

Тези отговори са от юникаст Link-Local адреси на IPv6 възли. Например, ето първия отговор:

64 байта от fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 време=0.106 ms

Уникастните Link-Local IPv6 адреси са задължителни на всички интерфейси с поддръжка на IPv6 [RFC4291], „Архитектура на адресацията IP версия 6“. Причината за това е, че IPv6 възел винаги автоматично разполага с уникастен IPv6 адрес, който може да използва поне за комуникация с други възли по директно свързаните си канали. Това включва комуникация с приложения на други хостове чрез Link-Local адресите на хостовете.

Това опростява разработката и внедряването на протоколи, като IPv6 Neighbor Discovery и OSPFv3. Това също така позволява на приложенията на крайни потребители на хостовете да обменят данни през канала, без да изискват друга поддържаща IPv6 инфраструктура. За директна комуникация между свързаните хостове, IPv6 рутер или DHCPv6 сървър не е необходим.

Link-Local адресите започват с 10-битен префикс fe80, следван от 54 нулеви бита и след това 64-битен идентификатор на интерфейса (IID). В горния първи отговор, 2392:6213:a15b:66ff — това е 64-битен IID.

Looped Multicast

По подразбиране, мултикастовите пакети се връщат вътрешно на възела, който ги изпраща. Това важи за IPv6 и IPv4 адресацията.

Причината за това поведение по подразбиране е, че при изпращане на мултикастови пакети може също да работи слушащо локално мултикастово приложение на самия изпращащ хост, точно както и някъде в мрежата. Това локално приложение също трябва да получава мултикастовите пакети.

Можем да видим този мултикастов локален цикъл в нашия ping изход:

[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 data bytes
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 ms
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.453 ms (DUP!)
...

Първият и най-бърз отговор (0.106 мс в сравнение с 0.453 мс) идва от Link-Local адреса, конфигуриран на самия интерфейс enp3s2.

[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
    inet6 fe80::2392:6213:a15b:66ff/64 scope link noprefixroute 
[mark@opy ~]$

Утилита ping предоставя начин за потискане на локалната обратна връзка от мултикастовата разпръскваща мрежа чрез параметър -L. Ако изпратим пинг към мултикаста на всичките възли с този флаг, отговорите ще са ограничени до отдалечени възли. Няма да получим отговор от Link-Local адреса на интерфейса на изпращача.

[mark@opy ~]$ ping -L -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 data bytes
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.383 ms

64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.467 ms (DUP!)
...

Ping на Link-Local адреси

Как можете да се досетите, юникастовите Link-Local адреси също сами по себе си не предоставят достатъчно информация, за да укажем кой интерфейс да използваме за тяхното достигане. Както при all-nodes multicast ping, ние също трябва да посочим интерфейса като параметър на командния ред. ping или zone ID с адреса при ping на Link-Local адреси.

Този път можем да използваме -c, за да ограничим количеството пакети и отговори, изпращани и получавани ping, тъй като извършваме юникастен ping.

[mark@opy ~]$ ping -c 1 fe80::f31c:ccff:fe26:a6d9%enp3s2
 
PING fe80::f31c:ccff:fe26:a6d9%enp3s2(fe80::fad1:11ff:feb7:3704%enp3s2) 56 data bytes
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.395 ms
 
--- fe80::f31c:ccff:fe26:a6d9%enp3s2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.395/0.395/0.395/0.000 ms
[mark@opy ~]$

Да пингуваме (всички) други IPv6 адреси?

В тази статия видяхме как да пингуваме всички IPv6 възли в канала, използвайки all-nodes multicast IPv6 адрес. ff02::1Също така видяхме как да укажем кой интерфейс да използваме с all-nodes multicast IPv6 адреса, тъй като самият адрес не може да предостави тази информация. Използвахме или параметър на командния ред ping, или посочихме интерфейс чрез суфикс %.

След това научихме за юникастовите Link-Local адреси, които са адресите, използвани за отговори на all-nodes multicast echo заявки ICMPv6.

Също така видяхме как multicast пакетите се връщат на изпращащия възел по подразбиране и как да изключим това за утилитата. ping.

Накрая направихме ping на единичен Link-Local адрес, използвайки суфикс %, тъй като Link-Local адресите сами по себе си също не предоставят информация за изходящия интерфейс.

Какво ще кажете за пинга на всички други възли и получаването на техните глобални юникаст адреси (GUA) (тоест техните публични адреси в интернет) или уникални локални юникаст адреси (ULA)? Ще разгледаме това в следващата статия на блога.

На това е всичко.

Научете повече за нашия курс в запис на деня на отворените врати.

Източник: habr.com