Недавно у нас были небольшие обучающие курсы для повышения нашей компетенции в сетевой части нашей инфраструктуры. Основную идею этих курсов, покрывающую OSPF/BGP/MPLS я тут повторять не буду ибо:
Так что тут я опишу интересные около-сетевые моменты которые были затронуты в процессе обучения. Часть из этого может показаться вам банальным, однако постараюсь компенсировать возможную скуку при прочтении обилием ссылок на дополнительные материалы
Ссылки на вики зачастую более примечательны секциями «External links» и «References» нежели самим содержанием
Ethernet Frame на самом деле не такая уж простая штука. Все знают о DMAC,
SMAC и VLAN Tag. Однако о Preamble, Start of frame и Interframe gap обычно
забывают. Я уж не говорю про FCS про который забывать очень нехорошо. Поле
Size/Type так вообще стоит время от времени освежать в памяти.
Существует несколько режимов switching'а. Вот самые популярные из них:
Есть специальный RFC на тему использования маски 255.255.255.254 — RFC 3021.
Если вкратце — делая point-to-point линки можно экономить пространство IP-адрессов юзая /31 маски.
Во время разговора о TCP в общем и TCP congestion avoidance в частности,
заговорили на тему определения дропов. Обычный ACK (так же называемый
cumulative acknowledgment) позволяет определить только один потерянный пакет за
один RTT, а учитывая текущие скорости сетей и размеры окон (про Window
Scaling тоже рекомендую почитать. Для тех кому лень: WND должно быть больше BDP) есть большие шансы множественных дропов в одном окне. На случай одного
дропа у TCP припасён Fast recovery. Однако теряется сразу несколько пакетов,
а RTT у линка большой, то производительность TCP резко падает.
Кстати от дропов защищает ECN, если не слышали, можете и о нём почитать-с.
На самом деле структура MAC адреса не совсем случайна. Большинство админов
знают, что MAC делится на две части: OUI (который однозначно указывает на
производителя) и NIC Specific (уникальный номер сетевушки).
Но есть и ещё два особых бита в MAC'е: 7ой и 8ой биты первого октета. Если 8ой
бит выставлен в 1, то адрес multicast, иначе unicast. Если 7ой бит равен
единице, то адрес является т.н. locally administered адресом, т.е. адрес
назначен сетевухе вручную (ну или же его использует железо/софт, которым IEEE
не выделила OUI).
Так, например, интерфейс Virtual Box'а у меня на машине имеет MAC
0a:00:27:00:00:00 — заметьте, что он является unicast и locally administered
ибо 0x0a = 0b00001010.
А у STP протокола multicast MAC 01:80:C2:00:00:00 — восьмой бит первого октета
выставлен в единицу.
Если у кого вдруг возник вопрос почему же выбрали такие странные биты, 7 и 8,
то ответ чертовски прост: при передачи байтов по сети каждый байт передаётся
задом наперёд, что подробно описано в RFC 2469.
Тут для меня было довольно много нового.
Да и в общем про 802.11 я знаю очень-очень мало, радует разве только то, что не один я такой =)
Буквы сверху — мнемоническая запись процесса выбора наилучшего BGP-маршрута.
N valid next-hop, W weights, L – local preferency, L – locally originated, A –
as path, O – origin, M – med, N –neighbour type, I – IGP metric.
Взято из CCIE Routing and Switching Exam Certification Guide (3rd Edition).
Это надо осознать. AS — это не только 32-битный номер. Также рекомендуется к
прочтению RFC 1930
Подробнее про их различия можно почитать в ripe-127
Пока обсуждали всякое legacy типа RIP и его holddown timer'ы вспомнилась
прекрасная вещь — Bidirectional Forwarding Detection, которая позволяет двум
directly connected железкам определить живость Forwarding Engine'а другой
стороны и целостность линка с sub-second точностью: RFC 5880. Ещё есть
вариант проверки IPv4/IPv6 связности между, опять же, directly connected
хостами: RFC 5881.
Как альтернативу BFD можно выкручивать таймеры у IGP, но у данного метода есть
свои минусы, о которых пишет сама Cisco: Bidirectional Forwarding Detection
for OSPF
3-tier архитектура разработана и предложена Cisco'й в качестве стандарта. Смысл
заключается в разделении сети на части: Core, Distribution and Access. Наш
лектор очень рекомендовал на каждом из уровней использовать L3 свитчи, дабы
терминировать L2 как можно дальше от ядра. Однако для простых смертных сойдёт и
схема с L2 на Access.
По теме написана вагон и маленькая тележка(в виде QoS), так что повторятся не
буду, а сделаю лишь отсылку на Enterprise Campus 3.0 Architecture: Overview
and Framework.
Схема которая признаёт существование разных AS в пределах нашей архитектуры.
Впервые наравне с CDA я её увидел в книжке Junos High Availability: Best
Practices for High Network Uptime, кою и рекомендую вам прочитать-с (стр.
339).
Все привыкли, что маска подсети может быть выражена префиксом, то есть иметь
последовательный набор единиц слева(или же полное их отсутствие). Однако маски
могут быть рваными, так например, маска вида:
может являться вполне валидной и будет match'ить каждый второй хост /24'ой
подсети. Конечно же далеко не всё оборудование поддерживает рваные маски.
Использование рваных масок вне тестовой среды крайне противопоказано. You've
been warned.
Крайне часто anycast упоминается в только контексте IPv6. Конечно, ещё в далёком
RFC1886, уже как раза три устаревшего, был назван такой тип адресов как Anycast.
Однако, это не первый RFC их описывающий (одно из первых упоминаний Anycast'а я
нашёл в RFC1546: Host Anycasting Service) да и применяется он уже давно в
IPv4 часто в связке с BGP/IGP. Так например часть DNS root servers — это
Anycast адреса.
По ГОСТу^W RFC anycast это:
Заметьте: не протокол, не стандарт, а просто, методология (или как её ещё модно
называть Best Practice) по созданию отказоустойчивого, децентрализованного
сервиса. Сами
of Anycast Services
Вышецетированное RFC 4291 нам как бы намекает на то, что отличить anycast
адрес от unicast «на глаз» в общем случае не реально.
ПС. Конечно стоит отдать должное IPv6 в котором понятие Anycast всё-таки более
менее формализовано, так например, первый и последние 128 хостов подсети
являются по-определению anycast-адресами. Подробнее можно почитать в Reserved
IPv6 Subnet Anycast Addresses
В IPv4 мире всё было очень просто: был
появлением IPv6 всё стало куда интереснее: теперь есть getaddrinfo(3) в
котором
Selection for Internet Protocol version 6 (IPv6). Вот их список из BSD'шного
Это фактически означает, что DNS round-robin теперь не совсем чесный.
В поисках дополнительной информации и дефолтных значений можно поглядеть:
Linux:
FreeBSD:
Просто интересная статья для саморазвития: Special Use IPv4 Addresses. Если
убрать всё банальное(приватные адреса и мультикаст) и не особо
интересное(тестовые сети), то остаётся заначка(в виде
Мы также довольно много времени уделили обсуждению IPv6 и dual-stack. Про это я уже писал, так что не буду повторяться, а просто оставлю ссылку на Основы IPv6
Вот такие получились заметки на полях. Если найдёте какие неточности — говорите — обсудим, поправлю
- Пока ещё явно недостаточно компетентен.
- Есть много более объективные ресурсы рассказывающие об этих темах.
Так что тут я опишу интересные около-сетевые моменты которые были затронуты в процессе обучения. Часть из этого может показаться вам банальным, однако постараюсь компенсировать возможную скуку при прочтении обилием ссылок на дополнительные материалы
Ссылки на вики зачастую более примечательны секциями «External links» и «References» нежели самим содержанием
Ethernet Frame Format
Ethernet Frame на самом деле не такая уж простая штука. Все знают о DMAC,
SMAC и VLAN Tag. Однако о Preamble, Start of frame и Interframe gap обычно
забывают. Я уж не говорю про FCS про который забывать очень нехорошо. Поле
Size/Type так вообще стоит время от времени освежать в памяти.
Режимы работы коммутатора
Существует несколько режимов switching'а. Вот самые популярные из них:
- Store and forward — Обрабатывает пакет целиком. Проверяет FCS. Учит SMAC.
Надёжнее, ибо определяет битые фреймы. - Cut-through — Смотрит только на DMAC. Моден в Infiniband и остальном HPC
ибо уменьшает задержки. Требует ручного заполнения таблицы коммутации. Есть
его подвид: Fragment-free, однако используется только в доменах где возможны
коллизии.
Маска /31
Есть специальный RFC на тему использования маски 255.255.255.254 — RFC 3021.
Если вкратце — делая point-to-point линки можно экономить пространство IP-адрессов юзая /31 маски.
Selective ACK
Во время разговора о TCP в общем и TCP congestion avoidance в частности,
заговорили на тему определения дропов. Обычный ACK (так же называемый
cumulative acknowledgment) позволяет определить только один потерянный пакет за
один RTT, а учитывая текущие скорости сетей и размеры окон (про Window
Scaling тоже рекомендую почитать. Для тех кому лень: WND должно быть больше BDP) есть большие шансы множественных дропов в одном окне. На случай одного
дропа у TCP припасён Fast recovery. Однако теряется сразу несколько пакетов,
а RTT у линка большой, то производительность TCP резко падает.
Кстати от дропов защищает ECN, если не слышали, можете и о нём почитать-с.
MAC адрес
На самом деле структура MAC адреса не совсем случайна. Большинство админов
знают, что MAC делится на две части: OUI (который однозначно указывает на
производителя) и NIC Specific (уникальный номер сетевушки).
Но есть и ещё два особых бита в MAC'е: 7ой и 8ой биты первого октета. Если 8ой
бит выставлен в 1, то адрес multicast, иначе unicast. Если 7ой бит равен
единице, то адрес является т.н. locally administered адресом, т.е. адрес
назначен сетевухе вручную (ну или же его использует железо/софт, которым IEEE
не выделила OUI).
Так, например, интерфейс Virtual Box'а у меня на машине имеет MAC
0a:00:27:00:00:00 — заметьте, что он является unicast и locally administered
ибо 0x0a = 0b00001010.
А у STP протокола multicast MAC 01:80:C2:00:00:00 — восьмой бит первого октета
выставлен в единицу.
Если у кого вдруг возник вопрос почему же выбрали такие странные биты, 7 и 8,
то ответ чертовски прост: при передачи байтов по сети каждый байт передаётся
задом наперёд, что подробно описано в RFC 2469.
Wi-Fi
Тут для меня было довольно много нового.
- 802.11n может использовать RTS/CTS! Этож прям RS-232 какой-то =). Кстати,
RTS/CTS это реализация Carrier sense multiple access with collision
avoidance (CSMA/CA), а в Ethernet сегментах с хабами используется Carrier
sense multiple access with collision detection (CSMA/CD). - 802.11s — mesh networking — peer-to-peer для Wi-Fi. Много читал коммитов
во FreeBSD на эту тему, но так и не трогал. - Протоколы управления и провижонинга точек доступа: Lightweight Access Point
Protocol и Control And Provisioning of Wireless Access Points
Да и в общем про 802.11 я знаю очень-очень мало, радует разве только то, что не один я такой =)
BGP
N WLLA OMNI
Буквы сверху — мнемоническая запись процесса выбора наилучшего BGP-маршрута.
N valid next-hop, W weights, L – local preferency, L – locally originated, A –
as path, O – origin, M – med, N –neighbour type, I – IGP metric.
Взято из CCIE Routing and Switching Exam Certification Guide (3rd Edition).
Автономная система
An AS is a connected group of one or more IP prefixes run by one or more network operators which has a SINGLE and CLEARLY DEFINED routing policy.
Это надо осознать. AS — это не только 32-битный номер. Также рекомендуется к
прочтению RFC 1930
Internet голоссарий
Огранизации
- ICANN — Управляющая организация для IANA.
- IANA — Организация управляющая распределением IP'шников. Так же они держат
root-dns сервера. Кстати у неё на сайтике есть отличная страничка с числами,
прям читать не перечитать: Protocol Registries - RIR — Региональные регистраторы. Выполняют всю чёрную работу для IANA. На
данный момент их 5. Ещё в 2002 было всего 3. Так глядишь и у Антарктиды свой
появится. - NIR — Национальные регистраторы. Есть лишь в некоторых странах (например, Япония, Китай, Корея итд.)
- LIR — Им может стать любой крупный провайдер получивший большой блок
IP'шников.
Типы адресов
- PI — Провайдеронезависимые адреса — тащи с собой куда хочешь.
- PA — Адреса привязанные к вышестоящему провайдеру — если он вас покидает — остаётесь без них.
Подробнее про их различия можно почитать в ripe-127
BFD
Пока обсуждали всякое legacy типа RIP и его holddown timer'ы вспомнилась
прекрасная вещь — Bidirectional Forwarding Detection, которая позволяет двум
directly connected железкам определить живость Forwarding Engine'а другой
стороны и целостность линка с sub-second точностью: RFC 5880. Ещё есть
вариант проверки IPv4/IPv6 связности между, опять же, directly connected
хостами: RFC 5881.
Как альтернативу BFD можно выкручивать таймеры у IGP, но у данного метода есть
свои минусы, о которых пишет сама Cisco: Bidirectional Forwarding Detection
for OSPF
Архитектуры постоения сетей
CDA
3-tier архитектура разработана и предложена Cisco'й в качестве стандарта. Смысл
заключается в разделении сети на части: Core, Distribution and Access. Наш
лектор очень рекомендовал на каждом из уровней использовать L3 свитчи, дабы
терминировать L2 как можно дальше от ядра. Однако для простых смертных сойдёт и
схема с L2 на Access.
По теме написана вагон и маленькая тележка(в виде QoS), так что повторятся не
буду, а сделаю лишь отсылку на Enterprise Campus 3.0 Architecture: Overview
and Framework.
CE-PE
Схема которая признаёт существование разных AS в пределах нашей архитектуры.
Впервые наравне с CDA я её увидел в книжке Junos High Availability: Best
Practices for High Network Uptime, кою и рекомендую вам прочитать-с (стр.
339).
Discontiguous subnet masks aka «рваные» маски
Все привыкли, что маска подсети может быть выражена префиксом, то есть иметь
последовательный набор единиц слева(или же полное их отсутствие). Однако маски
могут быть рваными, так например, маска вида:
11111111.11111111.11111111.00000001может являться вполне валидной и будет match'ить каждый второй хост /24'ой
подсети. Конечно же далеко не всё оборудование поддерживает рваные маски.
Использование рваных масок вне тестовой среды крайне противопоказано. You've
been warned.
Anycast
Крайне часто anycast упоминается в только контексте IPv6. Конечно, ещё в далёком
RFC1886, уже как раза три устаревшего, был назван такой тип адресов как Anycast.
Однако, это не первый RFC их описывающий (одно из первых упоминаний Anycast'а я
нашёл в RFC1546: Host Anycasting Service) да и применяется он уже давно в
IPv4 часто в связке с BGP/IGP. Так например часть DNS root servers — это
Anycast адреса.
По ГОСТу^W RFC anycast это:
Anycast: the practice of making a particular Service Address
available in multiple, discrete, autonomous locations, such that
datagrams sent are routed to one of several available locations.
Заметьте: не протокол, не стандарт, а просто, методология (или как её ещё модно
называть Best Practice) по созданию отказоустойчивого, децентрализованного
сервиса. Сами
anycast-best-practices можно почитать в RFC 4786: Operationof Anycast Services
Anycast addresses are allocated from the unicast address space, using
any of the defined unicast address formats. Thus, anycast addresses
are syntactically indistinguishable from unicast addresses. When a
unicast address is assigned to more than one interface, thus turning
it into an anycast address, the nodes to which the address is
assigned must be explicitly configured to know that it is an anycast
address.
Вышецетированное RFC 4291 нам как бы намекает на то, что отличить anycast
адрес от unicast «на глаз» в общем случае не реально.
ПС. Конечно стоит отдать должное IPv6 в котором понятие Anycast всё-таки более
менее формализовано, так например, первый и последние 128 хостов подсети
являются по-определению anycast-адресами. Подробнее можно почитать в Reserved
IPv6 Subnet Anycast Addresses
Address selection в общем.
В IPv4 мире всё было очень просто: был
gethostbyname(3), у которого былh_addr или, в крайнем случае, собственная логика вокруг h_addr_list. Споявлением IPv6 всё стало куда интереснее: теперь есть getaddrinfo(3) в
котором
addrinfo список сортируется по нетривиальным правилам: Default AddressSelection for Internet Protocol version 6 (IPv6). Вот их список из BSD'шного
libc:/* * Rule 1: Avoid unusable destinations. * XXX: we currently do not consider if an appropriate route exists. */ /* Rule 2: Prefer matching scope. */ /* Rule 3: Avoid deprecated addresses. */ /* Rule 4: Prefer home addresses. */ /* XXX: not implemented yet */ /* Rule 5: Prefer matching label. */ /* Rule 6: Prefer higher precedence. */ /* Rule 7: Prefer native transport. */ /* XXX: not implemented yet */ /* Rule 8: Prefer smaller scope. */ /* * Rule 9: Use longest matching prefix. * We compare the match length in a same AF only. */ /* Rule 10: Otherwise, leave the order unchanged. */
Это фактически означает, что DNS round-robin теперь не совсем чесный.
В поисках дополнительной информации и дефолтных значений можно поглядеть:
Linux:
cat /etc/gai.confFreeBSD:
ip6addrctl show«Специальные» IPv4 адреса
Просто интересная статья для саморазвития: Special Use IPv4 Addresses. Если
убрать всё банальное(приватные адреса и мультикаст) и не особо
интересное(тестовые сети), то остаётся заначка(в виде
240.0.0.0/4) и 6to4 Relay Anycast.IPv6
Мы также довольно много времени уделили обсуждению IPv6 и dual-stack. Про это я уже писал, так что не буду повторяться, а просто оставлю ссылку на Основы IPv6
Вместо заключения
Вот такие получились заметки на полях. Если найдёте какие неточности — говорите — обсудим, поправлю
