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

    Недавно у нас были небольшие обучающие курсы для повышения нашей компетенции в сетевой части нашей инфраструктуры. Основную идею этих курсов, покрывающую 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.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


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


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

    Подробнее
    Реклама
    Комментарии 24
    • 0
      Интересная статья для общего развития.
      Хотелось бы конечно ссылок на нормальные статьи, а не RFC. Штука полезная, не спорю, но читать их архимуторно.
      • +1
        Если просто читать — согласен, муторно. А вот если требуется описанное реализовать в софте/железе — тут и начинаешь ценить эту дотошность RFC! :)
        • 0
          Вот тут посмотрите Книга бывшего преподавателя, думаю что на большинство вопросов ответы Ва там сможете найти
      • +2
        Не первый год знаком с сетями, но почерпнул много интересного. Реально полезные вещи.
        Спасибо.
        • 0
          Не знал про рванные маски… спасибо
          Мои заметки на полях про IPv6 vasilisc.com/ipv6
          Сейчас активно изучаю на тестовом стенде по купленной книге.
          • +1
            >Если 8ой бит выставлен в 1, то адрес multicast

            Понятие multicast НЕприменимо ко второму уровню. Тут ходят BROADCAST. Мультикасты ходят на третьем (IP) уровне. Но multicast на втором уровне передаются посредством broadcast, это да.
            =)
            • 0
              А как же тогда igmp, подписка на группы и прочее?
              • +1
                igmp — это третий уровень. Адрес в igmp — это IP адрес. Точнее IP-milticast.

                MAC-адреса работают на втором уровне. Установка 8-го бита в первом октете MAC-адреса в поле DMAC — это BROADCAST.

                В противном случае приведите мне пример отличия broadcast от multicast выраженные на втором уровне в MAC-адресе.
                • 0
                  Ну и что, что igmp — третий уровень?
                  Кадры с broadcast-адресом должны отсылатся всем в подсети, а кадры с multicast-адресом можно тем, кто не учавствует в группе, не отправлять. Это отличие на втором уровне. Да, большинство свичей не умеет определять, кто в какой группе, но некоторые умеют, и этим пользуются.
              • 0
                Неправда
                • 0
                  На этом месте спотыкались люди даже, разбирающиеся в сетях.
                  Приведу тут ссылку на самый достоверный источник(с) Multicast address
                  • +1
                    Ну wikimedia первый раз вижу, так что за достоверный источник не приму.
                    Тогда уж велкам ту CiscoWiki

                    Ну чтож, прийдётся согласиться.
                    Если стоит 8-ой бит первого октета — то это MULTICAST
                    Если стоят все F — то это BROADCAST

                    НО!
                    С точки зрения коммутатора — в чём разница?
                    И то и другое получат все в данном L2-cегменте.

                    Я частенько ковыряюсь в дампах сети и просто держу в голове утверждение — «если у пакета есть 8-ой бит — значит это BROADCAST».
                    В сущности при разборе дампов главное понимать как раз то, кто этот пакет получит. А получат его как раз все участники текущего L2-домена, так что нельзя сказать, что моё утверждение ложно.

                    Хотя если коммутатор поддерживает igmp, то тогда пакет получат только участники рассылки.

                    Впрочем в большинстве случаев если вы получили пакет с 8-мым битом, то скорее всего его получили также все в этой сети.
                    Таким образом рассылается например STP BPDU(только что проверил — DMAC=01:80...), который явно должен рассылаться броадкастом и всем, а не мультикастом и выборочно.
                    • 0
                      Есть 2 вопроса:
                      1) Почему STP BPDU «который явно должен рассылаться броадкастом и всем» шлётся не на FF:FF:FF:FF:FF:FF?
                      2) Зачем конечному хосту не совместимому со стандартом 802.1D получать BPDU?
                      • 0
                        0)Трафик снимал SPAN-сессией между cisco2950 и cisco2821.

                        1)Факт не реклама. Понятия не имею почему, но часто сталкивался с тем, что широковещательные пакеты шлются именно с выставленным 8-мым битом, а не на FF:FF:FF:FF:FF:FF.
                        Собственно поэтому и имел заблуждение на счёт того, что это и есть броадкаст.
                        Чистый броадкаст как-то редко встречается в природе =)
                        Ну разве что ARP.

                        2)Тем не менее с конфигом по умолчанию коммутатор шлёт BPDU на все порты без разбору кто там подключен и это правильно, ибо коммутатор не может знать, что будет подключено к порту(хост или другой свитч), а петли обнаруживать надо в любом случае.
                        • 0
                          Основной смысл multicast адреса на L2 в том, что даже умные свитчи понимающие IGMP/MLD не будут заглядывать в L3 заголовок для определения типа пакета — оно не нужно ибо всё отражено в MAC-адресе(хоть и не без false-positives). Да и в FDB, насколько я понимаю, хранятся не IP'шники, а MAC'и.
                          Так же заметьте, что multicast трафик не будет нагружать CPU железки которая его не должна принимать. Сравните вывод tcpdump и tcpdump -p.
                  • 0
                    а как же 01-00-5E-xx-xx-xx?
                  • +1
                    ЕМНИП, RTS/CTS использовалась во всех Wi-Fi, начиная с чистого 802.11 и включая a, b и g.
                    • 0
                      Автор, а чем ваш лектор аргументировал, что L2 нужно терминировать как можно раньше и уже на access'е держать L3? Просто то было актуально черте когда. Тенденции-то сейчас совершенно обратные, т.к. современное оборудование уже на access'е может фильтровать пакеты чуть ли не до седьмого уровня (а также бродкасты зафильтровать и так далее) и смысла нарезать все на L3-домены нет никакого — можно так «чисто и гладенько» причесать трафик, что он в виде L2 хоть до ядра дойдет и никому ничего плохого не сделает… В итоге — просто и гибко. Заодно и немного деньжат экономим, т.к. L3 чуть повыше ставим.
                      • 0
                        Слишком много всего нужно учитывать: Broadcast штормы, ARP спуфинг, STP root hijack, VLAN hopping. Это только то что с ходу вспомнилось, на практике я думаю на практике там много больше всего(соответственно ACL'и на свитчах будут гигантские). Так что лучше перестраховаться и давать клиентам L3.
                        • –1
                          Гм. Ну может где-то, где очень правила хитрые — там да. А при обслуживании массового клиента ничего там гигантского нет — поверьте мне, сам делал. Для половины даже ACL не надо — встроенными средствами коммутаторов режется все, что надо — только «галочку» поставь. У меня L2 сегмент на 3 тыс. человек работал вообще без проблем, бродкастовых штормов и т.п. При том что клиенты — вирус на вирусе и вирусом погоняет. :-) И, например, Билайн в Москве аналогично строит — L3 выделяется только на целый район.
                          Впрочем, это все провайдинг. В корпоративе, очевидно, несколько иначе, но конкретные аргументы все равно было бы любопытно услушать.
                          • 0
                            Ну, например, один из основных аргументов для корпоратива — это то, что при аварии роутинг-протоколы сходятся на порядок быстрее RSTP.
                      • 0
                        коллеги, кажется почти все из хтого должно быть в памяти всегда, как же вы работали без этого раньше?
                        • 0
                          Мы админы/программисты, а не НОКи. Специка нашей работы не подразумевает знания всего этого.

                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.