Остават броени дни до старта на новия поток по курса от OTUS. В тази връзка искаме да споделим с вас превод на полезен материал по темата.
Серия от статии в блога, посветени на съвети и препоръки за отстраняване на проблеми, свързани с пинга на IPv6 (ICMPv6 Echo Request/Echo Reply)
Обърнете внимание, че използвам Linux (в частност, Fedora 31), но синтаксисът на командата ping за други операционни системи, се надявам, ще бъде много подобен.
Пинг на всички IPv6 възли в канала
Първият и най-прост съвет е да пропингувате всички IPv6 възли в канала.
IPv6 използва multicast адреси за всички типове свързване «един към много». Не съществуват broadcast (или широковещателни) IPv6 адреси. Това отличава IPv6 от IPv4, където съществуват няколко типа broadcast адреси, например, «limited broadcast» адрес 255.255.255.255 [RFC1122].
Съществува обаче “all-nodes multicast” (общ мултикаст) IPv6 адрес, затова ще го използваме за пинг на всички IPv6 възли в канала. (Широковещателният адрес всъщност е просто специално наименуван многопосочен адрес, който е група от многоадресни разпратки, включваща всички възли. Обърнете внимание, че например битът „група“ или многопосочният адрес е включен в адресите за разпространение на Ethernet на канално ниво).
All-nodes multicast IPv6 адрес за канала: ff02::1. ff означава множество IPv6 адрес. Следващото 0 е част от флага с неизползвани битове.
Напред 2 определява обхвата на мултикастовата група. В отличие от мултикаст IPv4 адресите, мултикаст IPv6 адресите имат обхват (scope). Стойността на scope указва част от мрежата, по която е разрешено прехвърлянето на мултикастов пакет. Щом пакетът достигне границата на посочения scope, той трябва да бъде отхвърлен, независимо от това дали полето на брояча на преходите (Hop Count) е ненулево. Разбира се, ако броячът на преходите достигне нула преди да достигне посочената граница на мултикастовата група, той също така незабавно се нулира. Ето пълен списък на мултикастовите scopes на IPv6.
Накрая, ::1 указва групата all-nodes multicast.
За адреса ff02::1 следва да се отбележи, че той не е еднозначен. На IPv6 устройство с множество интерфейси, като рутер или многосетев хост, в адреса ff02::1 няма нищо, където да може да се укаже на кой интерфейс да се изпращат ICMPv6 echo заявки или да се очакват ICMPv6 echo отговори, когато те пристигнат. ff02::1 е валиден и може да се използва на който и да е от интерфейсите и каналите, свързани с многоинтерфейсния възел.
Затова, когато пингнем всички IPv6 устройства на канала, трябва някак да уведомим утилитата ping за IPv6, какъв интерфейс да се използва.
Определяне на интерфейсите - параметър на командния ред
Както вече видяхме, multicast адресът all-nodes, който искаме да използваме - ff02::1 - не предоставя никаква информация относно това, на кой интерфейс да се изпращат и получават пакети с ICMPv6 echo request и echo reply.
И така, как да укажем интерфейса, който ще се използва за пространството на multicast адресите или за unicast 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 пинг получихме отговори от 6 IPv6-узла. Отговорите пристигнаха от узловите Link-Local IPv6 адреси, започвайки от префикса fe80::/10.
За да ping не продължаваше безкрайно да изпраща ехо-заявки ICMPv6, докато не го прекратим. Обикновено посочваме броя на пакетите за изпращане чрез опцията -c. Въпреки това, това също не позволява на ping да приеме и покаже повече от един ехо-отговор ICMPv6 при изпращане на multicast ехо-заявка ICMPv6. Вместо това използвахме параметъра -w, за да укажем, че ping трябва да приключи след 1 секунда, независимо от броя на ехо-заявките или ехо-отговорите ICMPv6, които са били изпратени или получени.
Още нещо, на което трябва да се обърне внимание, е (DUP!) изходът на вторите и по-късните отговори. Тези пакети се идентифицират като дубликати на отговори, тъй като имат същата стойност на последователността ICMP, както отделните ехо-заявки ICMPv6, които бяха изпратени първоначално. Те се появяват, защото multicast ехо-заявката 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 data bytes
64 bytes от fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 време=0.106 ms
64 bytes от fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 време=0.453 ms (DUP!)
64 bytes от fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 време=0.606 ms (DUP!)
64 bytes от fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 време=6.23 ms (DUP!)
64 bytes от fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 време=157 ms (DUP!)
64 bytes от fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 време=159 ms (DUP!)
64 bytes от fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 време=161 ms (DUP!)
64 bytes от 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/avg/max/mdev = 0.106/82.858/179.216/81.281 ms
[mark@opy ~]$Отговори на Link-Local адреси
От този multicast ping на all-nodes получихме общо 6 уникални отговора.
Тези отговори идват от юникаст Link-Local адреси на IPv6 узли. Например, ето първият отговор:
64 bytes от 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 хостове не е необходим IPv6 рутер или DHCPv6 сървър в връзката.
Адресите Link-Local започват с 10-битов префикс fe80, следван от 54 нулеви бита и след това 64-битов идентификатор на интерфейса (IID). В предоставения по-горе отговор 2392:6213:a15b:66ff — това е 64-битов IID.
Looped Multicast
По подразбиране мултикастовите пакети се връщат вътрешно към възела, който ги изпраща. Това се случва както за IPv6, така и за IPv4 адресации.
Причината за това подразбиране е, че при изпращане на мултикастови пакети може да има също така активно локално мултикастово приложение, работещо на самия изпращащ хост, както и někъде в мрежата. Това локално приложение също трябва да получава мултикастови пакети.
Можем да видим този локален цикъл на мултикаст в нашите 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 ms в сравнение с 0,453 ms) идва от 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. Ако изпратим пинг към all-nodes multicast с този флаг, отговорите ще бъдат ограничени до отдалечените възли. Няма да получим отговор от Link-Local адреса на интерфейса на изпращача.
[mark@opy ~]$ ping -L -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 data bytes
64 bytes от fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.383 ms
64 bytes от fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.467 ms (DUP!)
...Пинг на Link-Local адрес
Както можете да предположите, униicast Link-Local адресите сами по себе си също не предоставят достатъчно информация, за да се определят кой интерфейс да използваме за тяхното достигане. Както в случая с all-nodes multicast ping, ние също трябва да посочим интерфейса като параметър в командния ред. ping или zone ID с адреса при пинг на Link-Local адреси.
Този път можем да използваме -c, за да ограничим броя на пакетите и отговорите, изпращани и получавани ping, тъй като извършваме униicast 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 от fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.395 ms
--- fe80::f31c:ccff:fe26:a6d9%enp3s2 ping статистика ---
1 пакета предадени, 1 получен, 0% загуба на пакети, време 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 ехо-запитвания ICMPv6.
Също така видяхме как мултикаст пакетите се връщат в изпращащия възел по подразбиране и как да деактивираме това за утилитата ping.
. Накрая направихме ping на единичен Link-Local адрес, използвайки суфикс %, тъй като Link-Local адресите сами по себе си също не предоставят информация за изходящия интерфейс.
Какво ще кажете за ping на всички останали възли и получаване на техните глобални юникаст адреси (GUA) (т.е. техните обществени адреси в интернет) или техните уникални локални юникаст адреси (ULA)? Ще разгледаме това в следващата статия в блога.
На това е всичко.
Научете повече за нашия курс в.
Източник: habr.com
