Считанные дни остаются до старта нового потока по курсу «Сетевой инженер» от OTUS. В связи с этим хотим поделиться с вами переводом полезного материала по теме.
ff02::1. ff
обозначает мультикастовый IPv6-адрес. Следующий 0 — это часть флага с неустановленными битами.2
определяет область мультикастовой группы. В отличие от мультикаст IPv4-адресов, мультикаст IPv6-адреса имеют scope (область видимости). Значение scope указывает часть сети, по которой разрешено пересылать мультикастный пакет. Как только пакет достигает границы указанного scope, пакет должен быть отброшен, независимо от того, является ли его поле счетчика переходов (Hop Count) ненулевым. Конечно, если счетчик переходов достигает нуля до достижения указанной границы мультикастовой группы, он также немедленно сбрасывается. Вот полный список мультикаст scope IPv6.::1
указывает all-nodes multicast группу.ff02::1
следует заметить, что он неоднозначен. На узле IPv6 с несколькими интерфейсами, такими как маршрутизатор или многосетевой хост, в адресе ff02::1
нет ничего, где бы можно было указать, какому интерфейсу отправлять эхо-запросы ICMPv6 или ожидать получения эхо-ответов ICMPv6, когда они приходят. ff02::1
действителен и может использоваться на любом из интерфейсов и каналов, прикрепленных к многоинтерфейсному узлу.ping
для IPv6, какой интерфейс использовать.ff02::1
— не предоставляет никакой информации относительно того, на какой интерфейс отправлять и получать пакеты эхо-запроса и эхо-ответа ICMPv6.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 ~]$
fe80::/10
.ping
не продолжал бесконечно отправлять эхо-запросы ICMPv6 до тех пор, пока мы не прервем его, мы обычно указываем количество пакетов для отправки через опцию -c. Однако это также не позволяет ping принять и отобразить более одного эхо-ответа ICMPv6 при отправке мультикаст эхо-запроса ICMPv6. Вместо этого мы использовали параметр -w, чтобы указать, что ping должен завершаться через 1 секунду, независимо от того, сколько эхо-запросов или эхо-ответов ICMPv6 было отправлено или получено.DUP!
) вывод на втором и последующих ответах. Эти пакеты идентифицируются как дубликаты ответа, поскольку они имеют то же значение последовательности ICMP, что и отдельные эхо-запросы ICMPv6, которые были отправлены в первую очередь. Они появляются, потому что мультикаст эхо-запрос ICMPv6 приводит к нескольким индивидуальным юникаст ответам. Количество дубликатов также указывается в сводке статистики.%enp3s2
, например:64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 ms
%<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 ~]$
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 ms
fe80
, за которым следуют 54 нулевых бита, а затем 64-битный идентификатор интерфейса (IID). В приведенном выше первом ответе 2392:6213:a15b:66ff
— это 64-битный IID.[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!)
...
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!)
...
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 ~]$
ff02::1
. Мы также видели, как указать, какой интерфейс использовать с all-nodes multicast IPv6-адресом, поскольку сам по себе адрес не может предоставить эту информацию. Мы использовали либо параметр командной строки ping
, либо указали интерфейс через суффикс %<zone_id>
.ping
.%<zone_id>
, так как Link-Local адреса сами по себе также не предоставляют информацию об исходящем интерфейсе.К сожалению, не доступен сервер mySQL