Лічені дні залишаються до старту нового потоку за курсом від OTUS. У зв'язку із цим хочемо поділитися з вами перекладом корисного матеріалу на тему.
Серія статей у блозі, присвячених порадам та рекомендаціям щодо усунення несправностей, пов'язаних з пінгом IPv6 (ICMPv6 Echo Request/Echo Reply)
Зверніть увагу, що я використовую Linux (зокрема Fedora 31), однак синтаксис команди ping для інших операційних систем, сподіваюся, повинен бути дуже схожим.
Пінг усіх вузлів IPv6 на каналі
Перша та найпростіша порада – пропінгувати всі вузли IPv6 на каналі.
IPv6 використовує мультикаст-адреси для всіх типів зв'язку один до багатьох. Немає бродкастних (чи широкомовних) IPv6-адрес. Це відрізняє IPv6 від IPv4, де є кілька типів бродкастних адрес, наприклад, «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) ненульовим. Звичайно, якщо лічильник переходів досягає нуля до досягнення вказаної межі мультикастової групи, він також негайно скидається. Ось повний список мультикаст IPv6 scope.
Нарешті, ::1 вказує all-nodes multicast групу.
Про адресу ff02::1 Слід зазначити, що він неоднозначний. На сайті IPv6 з декількома інтерфейсами, такими як маршрутизатор або багатомережевий хост, в адресі ff02::1 немає нічого, де можна було б вказати, якому інтерфейсу відправляти луна-запити ICMPv6 чи очікувати отримання луна-відповідей ICMPv6, коли вони приходять. ff02::1 дійсний і може використовуватися на будь-якому з інтерфейсів та каналів, що прикріплені до багатоінтерфейсного вузла.
Тому, коли ми пропінгуємо всі вузли IPv6 на каналі, нам потрібно якось також повідомити утиліту ping для IPv6 який інтерфейс використовувати.
Визначення інтерфейсів – параметр командного рядка
Як ми вже бачили, all-nodes multicast адреса, яку ми хочемо використовувати. ff02::1 — не надає жодної інформації щодо того, на який інтерфейс відправляти та отримувати пакети ехо-запиту та відлуння 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 пінгу ми отримали відповіді від 6 IPv6-вузлів. Відповіді надійшли від вузлових Link-Local IPv6-адрес, починаючи з префікса fe80::/10.
Щоб ping не продовжував нескінченно відправляти луна-запити ICMPv6 доти, доки ми не перервемо його, ми зазвичай вказуємо кількість пакетів для відправки через опцію -c. Однак це також не дозволяє ping прийняти і відобразити більше одного луни ICMPv6 при відправці мультикаст луна-запиту ICMPv6. Замість цього ми використовували параметр -w, щоб вказати, що ping повинен завершуватися через 1 секунду, незалежно від того, скільки луна-запитів або луна-відповідей ICMPv6 було надіслано або отримано.
Ще одна річ, на яку слід звернути увагу, це (DUP!) висновок на другому та наступних відповідях. Ці пакети ідентифікуються як дублікати відповіді, оскільки вони мають те саме значення послідовності ICMP, що й окремі відлуння ICMPv6, які були відправлені в першу чергу. Вони з'являються, тому що мультикаст ехо-запит ICMPv6 призводить до кількох індивідуальних юнікаст відповідей. Кількість дублікатів також зазначається у зведенні статистики.
Визначення інтерфейсів - Zone ID
Ще один спосіб надання інтерфейсу для використання – це частина параметра IPv6 адреси.
Ми можемо спостерігати приклад цього у виведенні ping, де адреси відповідних IPv6-вузлів також мають суфікс %enp3s2, Наприклад:
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 msЦей спосіб завдання інтерфейсів формально описаний в [RFC4007], «Архітектура із заданими IPv6 адресами». Хоча зазвичай вони називаються інтерфейсом операційної системи, вони насправді визначають щось загальне — «зона» чи «область дії».
Причина більш загальних зон або scope зон полягає в тому, що, як згадується в [RFC4007], вузол IPv6 може мати кілька різних інтерфейсів IPv6, підключених до одного і того ж каналу. Ці інтерфейси є членами однієї зони.
Повинно бути можливо згрупувати кілька інтерфейсів у межах зони під операційною системою; В даний час я не знаю, чи це можливо під Linux і як це зробити.
Використовуючи суфікс %<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 ~]$Відповіді Link-Local адрес
Від цього all-nodes multicast пінгу ми отримали 6 унікальних відповідей.
Ці відповіді надійшли від юнікаст Link-Local адрес вузлів IPv6. Наприклад, ось перша відповідь:
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=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 адресацій.
Причиною цієї дефолтної поведінки є те, що при відправленні мультикаст пакетів може бути слухаючий локальний мультикастовий додаток, що працює на самому відправляє хості, так само як і десь в мережі. Ця локальна програма також повинні отримувати мультикаст пакети.
Ми можемо бачити цей мультикастовий локальний цикл у нашому 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. Якщо ми відправляємо пінг 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 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!)
...Пінг Link-Local Адреси
Як ви можете здогадатися, юнікастові Link-Local адреси самі по собі також не надають достатньо інформації, щоб вказати, який інтерфейс використовуватиме їх досягнення. Як і у випадку all-nodes multicast пінгу, нам також необхідно вказати інтерфейс як параметр командного рядка ping або zone ID з адресою при пінгу Link-Local адрес.
На цей раз ми можемо використовувати -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 ~]$Пінгувати (всі) інші IPv6-адреси?
У цій статті ми побачили, як пропінгувати всі IPv6-вузли на каналі, використовуючи all-nodes multicast IPv6-адресу ff02::1. Ми також бачили, як вказати, який інтерфейс використовувати з all-nodes multicast IPv6-адресою, оскільки сама по собі адреса не може надати цю інформацію. Ми використовували або параметр командного рядка ping, або вказали інтерфейс через суфікс %<zone_id>.
Потім ми дізналися про юнікастові Link-Local адреси, які є адресами, що використовуються для відповідей на all-nodes multicast луна-запити ICMPv6.
Ми також бачили, як мультикаст пакети повертаються в відправляючий вузол за замовчуванням і як вимкнути це для утиліти ping.
Нарешті, ми пропінгували одиночну Link-Local адресу, використовуючи суфікс %<zone_id>, тому що Link-Local адреси самі по собі також не надають інформацію про вихідний інтерфейс.
Так як щодо пінгу всіх інших вузлів та отримання їх глобальних юнікаст адрес (GUA) (тобто їх загальнодоступних адрес в Інтернеті) чи їх унікальних локальних юнікаст адрес (ULA)? Ми розглянемо це у наступній статті блогу.
На цьому все.
Дізнатися докладніше про наш курс можна в.
Джерело: habr.com