Остало је неколико дана до почетка новог протока по стопи фром ОТУС. С тим у вези, желимо да поделимо са вама превод корисног материјала на ову тему.
Низ постова на блогу о саветима и триковима за решавање проблема са ИПв6 пингом (ИЦМПв6 Ецхо Рекуест/Ецхо Репли)
Имајте на уму да користим Линук (посебно Федора 31), међутим, надамо се да би синтакса команде пинг за друге оперативне системе требала бити врло слична.
Пингујте све ИПв6 чворове на каналу
Први и најједноставнији савет је да пингујете све ИПв6 чворове на линку.
ИПв6 користи вишеструке адресе за све врсте комуникација један-према-више. Не постоје ИПв6 адресе за емитовање (или емитовање). Ово разликује ИПв6 од ИПв4, где постоји неколико типова адреса за емитовање, на пример, адреса „ограниченог емитовања“ 255.255.255.255 [РФЦ1122].
Међутим, постоји ИПв6 адреса „мултицаст“ са свим чворовима, тако да ћемо је користити за пинговање свих ИПв6 чворова на вези. ("Броадцаст" адреса је заправо само посебно названа мултицаст адреса, која је група за вишеструко емитовање која укључује све чворове. Имајте на уму да је, на пример, бит "групне" или вишеструке адресе укључен у Етернет адресе емитовања на слоју везе ).
Мултицаст ИПв6 адреса свих чворова за канал: ff02::1. ff означава мултицаст ИПв6 адресу. Следећа 0 је део заставе са непостављеним битовима.
Даље 2 дефинише област вишекастне групе. За разлику од мултицаст ИПв4 адреса, мултицаст ИПв6 адресе имају опсег. Вредност опсега означава део мреже преко којег је дозвољено прослеђивање вишеструког пакета. Када пакет достигне границу наведеног опсега, пакет мора бити одбачен, без обзира да ли је његово поље Хоп Цоунт различито од нуле. Наравно, ако број скокова достигне нулу пре него што достигне одређену границу вишеструке групе, он се такође одмах ресетује. Ево комплетне листе ИПв6 мултицаст опсега.
Коначно, ::1 специфицира мултицаст групу са свим чворовима.
О адреси ff02::1 Треба напоменути да је двосмислен. На ИПв6 хосту са више интерфејса, као што је рутер или вишедомни хост, адреса ff02::1 не постоји ништа где можете да одредите ком интерфејсу да пошаљете ИЦМПв6 ехо захтеве или да очекујете да ћете примити ИЦМПв6 ехо одговоре када стигну. ff02::1 је валидан и може се користити на било ком од интерфејса и канала повезаних са чвором са више интерфејса.
Дакле, када пингујемо све ИПв6 чворове на линку, морамо некако да кажемо и услужном програму ping за ИПв6, који интерфејс користити.
Дефинисање интерфејса – опција командне линије
Као што смо већ видели, мултицаст адреса свих чворова коју желимо да користимо је − ff02::1 - не пружа никакве информације о томе који интерфејс треба послати и примити ИЦМПв6 пакете ехо захтева и ехо одговора.
Дакле, како да наведемо интерфејс који ће се користити за мултицаст адресни простор или уницаст Линк-Лоцал адресни простор?
Први и најочигледнији начин је да га обезбедимо као параметар за апликацију коју користимо.
За корисност 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 ~]$Користећи овај мултицаст пинг за све чворове, добили смо одговоре од 6 ИПв6 чворова. Одговори су дошли са адреса Линк-Лоцал ИПв6 чворова, почевши од префикса fe80::/10.
Да ping не наставља да шаље ИЦМПв6 ехо захтеве на неодређено време док га не прекинемо, обично наводимо број пакета за слање преко опције -ц. Међутим, ово такође спречава пинг да прихвати и прикаже више од једног ИЦМПв6 ехо одговора приликом слања вишеструког ИЦМПв6 ехо захтева. Уместо тога, користили смо опцију -в да наведемо да пинг треба да се заврши после 1 секунде, без обзира колико ИЦМПв6 ехо захтева или ехо одговора је послато или примљено.
Још једна ствар на коју треба обратити пажњу је (DUP!) излаз на други и наредни одговори. Ови пакети су идентификовани као дупли одговори јер имају исту вредност ИЦМП секвенце као појединачни ИЦМПв6 ехо захтеви који су послати на првом месту. Појављују се зато што ИЦМПв6 мултицаст ехо захтев резултира вишеструким појединачним одговорима. Број дупликата је такође наведен у резимеу статистике.
Дефинисање интерфејса - ИД зоне
Други начин да се интерфејс изложи за употребу је као део параметра ИПв6 адресе.
Пример овога можемо видети у пинг излазу, где адресе ИПв6 хостова који одговарају такође имају суфикс %enp3s2, на пример:
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 msОвај метод специфицирања интерфејса је формално описан у [РФЦ4007], „ИПв6 дефинисана адресна архитектура“. Иако се обично називају интерфејсом оперативног система, они заправо дефинишу нешто општије — „зону“ или „опсег“.
Разлог за постојање општијих зона или зона опсега је тај што, као што је поменуто у [РФЦ4007], ИПв6 чвор може имати неколико различитих ИПв6 интерфејса повезаних на исти канал. Ови интерфејси су чланови исте зоне.
Требало би да постоји могућност груписања више интерфејса унутар зоне под оперативним системом; Тренутно не знам да ли је то могуће под Линуком или како то учинити.
Коришћењем суфикса %<zone_id>, можемо уклонити опцију командне линије -I 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!)
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.606 ms (DUP!)
64 bytes from fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 time=6.23 ms (DUP!)
64 bytes from fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 time=157 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 time=159 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 time=161 ms (DUP!)
64 bytes from fe80::23d:e8ff:feec:958c%enp3s2: icmp_seq=1 ttl=64 time=179 ms (DUP!)
--- ff02::1%enp3s2 ping statistics ---
1 packets transmitted, 1 received, +7 duplicates, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.106/82.858/179.216/81.281 ms
[mark@opy ~]$Линк-Лоцал Аддресс Респонсес
Од овог мултицаст пинга свих чворова добили смо укупно 6 јединствених одговора.
Ови одговори су дошли са једноструких Линк-Лоцал ИПв6 адреса хоста. На пример, ево првог одговора:
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 msУницаст Линк-Лоцал ИПв6 адресе су потребне на свим ИПв6-омогућеним интерфејсима [РФЦ4291], „ИП Верзија 6 Архитектура адресирања“. Разлог за то је тај што ИПв6 чвор увек аутоматски има једносмерну ИПв6 адресу, коју барем може да користи за комуникацију са другим чворовима на својим директно повезаним везама. Ово укључује комуникацију са апликацијама на другим хостовима преко Линк-Лоцал хост адреса.
Ово поједностављује дизајн и имплементацију протокола као што су ИПв6 Неигхбор Дисцовери и ОСПФв3. Такође омогућава апликацијама крајњих корисника на хостовима да комуницирају преко канала без потребе за било којом другом подршком ИПв6 инфраструктуром на каналу. Директна комуникација између повезаних ИПв6 хостова не захтева ИПв6 рутер или ДХЦПв6 сервер на вези.
Линк-Лоцал адресе почињу са 10-битним префиксом fe80, затим 54 нула бита и затим 64-битни идентификатор интерфејса (ИИД). У горњем првом одговору 2392:6213:a15b:66ff је 64-битни ИИД.
Лоопед Мултицаст
Подразумевано, мултицаст пакети се враћају интерно чвору који их је послао. Ово се дешава и за ИПв6 и за ИПв4 адресирање.
Разлог за ово подразумевано понашање је тај што када се шаљу мултицаст пакети, можда постоји и локална мултицаст апликација која слуша на самом хосту који шаље, као и негде на мрежи. Ова локална апликација такође мора да прима мултицаст пакете.
Ову мултицаст локалну петљу можемо видети у нашем пинг излазу:
[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 мс) долази од Линк-Лоцал адресе конфигурисане на самом интерфејсу enp3s2.
[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
inet6 fe80::2392:6213:a15b:66ff/64 scope link noprefixroute
[mark@opy ~]$Корисност ping пружа начин за сузбијање локалне мултицаст повратне информације помоћу параметра -L. Ако пошаљемо мултицаст пинг за све чворове са овом заставицом, одговори су ограничени на удаљене чворове. Не добијамо одговор са Линк-Лоцал адресе интерфејса за слање.
[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 или ИД зоне са адресом приликом пинговања Линк-Лоцал адреса.
Овај пут можемо да искористимо -cда ограничите број послатих и примљених пакета и одговора 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 ~]$Пинговати (све) друге ИПв6 адресе?
У овом чланку смо видели како пинговати све ИПв6 чворове на каналу користећи мултицаст ИПв6 адресу свих чворова ff02::1. Такође смо видели како да одредимо који интерфејс да користимо са мултицаст ИПв6 адресом са свим чворовима, пошто сама адреса не може да пружи ове информације. Користили смо или опцију командне линије ping, или специфицира интерфејс користећи суфикс %<zone_id>.
Затим смо сазнали за уницаст Линк-Лоцал адресе, које су адресе које се користе за одговарање на мултицаст ИЦМПв6 ехо захтеве свих чворова.
Такође смо видели како се мултицаст пакети подразумевано враћају чвору за слање и како то онемогућити за услужни програм ping.
Коначно, пинговали смо једну локалну адресу везе користећи суфикс %<zone_id>, пошто саме Линк-Лоцал адресе такође не пружају информације о одлазном интерфејсу.
Дакле, шта је са пинговањем свих осталих чворова и добијањем њихових глобалних уницаст адреса (ГУА) (тј. њихових јавних адреса на Интернету) или њихових јединствених локалних уницаст адреса (УЛА)? Ово ћемо погледати у следећем посту на блогу.
То је све.
Више о нашем курсу можете сазнати на.
Извор: ввв.хабр.цом