О сетях: всего понемногу

Недавно у нас были небольшие обучающие курсы для повышения нашей компетенции в сетевой части нашей инфраструктуры. Основную идею этих курсов, покрывающую OSPF/BGP/MPLS я тут повторять не буду ибо:

• Пока ещё явно недостаточно компетентен.
• Есть много более объективные ресурсы рассказывающие об этих темах.

Так что тут я опишу интересные около-сетевые моменты которые были затронуты в процессе обучения. Часть из этого может показаться вам банальным, однако постараюсь компенсировать возможную скуку при прочтении обилием ссылок на дополнительные материалы

Ссылки на вики зачастую более примечательны секциями «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: Operation
of 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 Address
Selection 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.conf
FreeBSD: ip6addrctl show

«Специальные» IPv4 адреса

Просто интересная статья для саморазвития: Special Use IPv4 Addresses. Если
убрать всё банальное(приватные адреса и мультикаст) и не особо
интересное(тестовые сети), то остаётся заначка(в виде 240.0.0.0/4) и 6to4 Relay Anycast.

IPv6

Мы также довольно много времени уделили обсуждению IPv6 и dual-stack. Про это я уже писал, так что не буду повторяться, а просто оставлю ссылку на Основы IPv6

Вместо заключения

Вот такие получились заметки на полях. Если найдёте какие неточности — говорите — обсудим, поправлю