Обзор решений фильтрации с простейшими примерами, встроенных в Cisco IOS. Не всё есть везде и вам скорее всего всё равно нужно будет что-то уровня ISR или ASR. Есть про tcp established, Reflexive ACL, Zone Based Firewall (самое мощное что есть) и Context Based ACL. Если есть ZBF используйте его, но вероятнее всего сеть всё равно придётся перепроектировать, разметить на зоны и активировать лицензии. Вступление к статье жизненное: "Пришёл директор насмотревшись семинаров и говорит..."

Иван Пепельняк про аппаратный дизайн устройств, подходы к этому дизайну при ограниченных возможностях FIB. Все вместе вспоминаем историю развития маршрутизаторов, но это не значит что подобные решения вендоры не применяют снова и снова.
Упоминаемые 12000 маршрутных записей это агрегация крупного города, при хорошем дизайне - L3, иерархическая адресация, суммирование, в общем если по учебнику. Если говорить про агрегацию доступа, то это тоже норм, но уже средних размеров кампус. Если хочется иметь индивидуальные маршруты до абонентов и рулить каждым из них, то конечно 12000 совсем мало.

Поуправлять этим (ужать одно в угоду другого) не всегда удаётся, мне почему-то сначала вспомнился Eltex с его system router resources, а потом Foundry BigIron когда я так переигрался с max-параметрами, что ему не хватило памяти для загрузки. В нём же была возможность агрегировать записи FIB: ip net-aggregate и dr-aggregate.
В BGP FullView можно начать с 0.0.0.0/0 даже в случае больше двух аплинк-провайдеров и добавлять только то что нужно, в большинстве случаев, если вы находитесь на границе Интернета, разницы от "неоптимальной" маршрутизации будет незаметно.

На этой неделе канал @Patchcord отмечает своё 5-летие, с чем я нас всех и поздравляю - всех кто был с первого дня и всех кто присоединился в процессе, тех кто уже ушёл и тех кто ещё придёт. Немного традиционной статистики:

Всего 260 постов за год (всё вместе, со всеми репостами и картинками), у нас выпало часть весны, поэтому получилось ещё меньше чем в прошлом году, но в целом темп, по ощущениям, был такой же. Процесс ведения канала вошёл в привычку, что плохо и не плохо одновременно. За последние пару лет мы почти ушли от "мгновенных" новостей день в день и в основном, я думаю, говорим об актуальных и продолжительных темах. Поэтому большая часть ленты формируется в тихое, спокойное, околоночное время, на следующие пару-тройку суток. Навскидку, на всё про всё уходит часов 8-10 в неделю, не считая процесса накидывания новостей для последующего разбора. Да, это, в основном, моё субъективное мнение об интересном в данный момент и в данных обстоятельствах, то с чем мне приходится работать или может быть придётся работать и я на это смотрю, то с чем я работал. Говорить об одном и том же не хочется, и в целом я стараюсь не возвращаться (но всё равно возвращаюсь) к пройденным материалам, даже если это была ссылка на очень интересный блог по теме, я надеюсь, вы на него сами подписались, то же касается и телеграм-каналов.

Среднее количество просмотров ~930, медиана ~850. Посты на которые больше всего обратили внимание:
- Про стандарт пиринговых отношений от Qrator
- Про DMVPN без DMVPN
- Про стандарты IPv6 в домашних маршрутизаторх и про ISO/OSI как она есть

С нового года канал переехал на встроенные механизмы Телеграм, я про реакции, поэтому старый скрипт посчитал не всё до конца, а где спрятались реакции в новом формате я не нашёл (может быть соберусь и перепишу всё на API). Но посчитать всё равно получилось. Итого, палец вверх:
- Про мою домашнюю сеть, которая с тех пор ещё усложнилась
- Про тайны мадридского двора за кулисами tzdata
- И, конечно, всем нравится день сисадмина

Палец вниз:
- Про настоящий телеком, который начинается с уровня 0
- Про свой центр сертификации
- Ещё про модель OSI, Cisco пинги и пинание дохлых лошадей

Конечно, я напомню, что есть ещё https://host-correct.ru/ с DoH и DoT, и боты с BGP таблицами @FullViewBGPbot - данные с коллекторов RIPE NCC и @bgp_table_bot - данные из Twitter бота. Сейчас мне катастрофически перестало хватать мощностей на моей VPS поэтому в самое ближайшее время накину ещё, и должно стать полегче.

Если кто-то ещё задаётся вопросом про что же этот канал, то могу почти процитировать, то что мне не так давно написал наш читатель - "канал с выжимками статей блогов RIPE и APNIC и околосетевой тематикой". Лично мне хочется думать что этот канал про Интернет, тот который под капотом, про отдельные его детали. Спасибо всем кто читает, спасибо всем кто присылает что-то в ответ, двигаемся дальше.

Сразу ещё один момент про который я иногда задумываюсь. За всё время, вот реально, был только один прямой вопрос про чат канала года три или четыре назад, что надо бы его сделать. Друзья которые со мной работали знают, что одно время я делал миллион рабочих чатов, на каждую тему, какие-то взлетели, какие-то не очень, но это чаты людей которых ты видишь и знаешь лично, и в принципе понимаешь чего ожидать, как максимум ограничен рабочей субординацией.

В публичном пространстве, я сначала присутствовал много где, не сказать чтобы активно, но потом последовательно выходил и выходил. Один из моих друзей создал, на мой взгляд, весьма успешный публичный чат по обсуждению работы с оборудованием одного из вендоров, но потом сам его покинул, но чат продолжает жить. У меня такого опыта нет. Модерирование и организация живого сообщества людей, отдельная и очень сложная тема, практически никому и никогда не удаётся оставаться в рамках приличий и заданной специфики, баланса закручивания гаек и допустимого офтопа, в рамках одинакового профессионального уровня который со временем меняется (часто в сторону его понижения), в рамках актуальных обсуждений и перетирания одного и того же по кругу. Многие сообщества в этом году не справились, многие выдержали, некоторые на удивление. Поэтому я скорее против чтобы организовать и поддерживать работу ещё одного инструмента.

Сейчас, мне кажется, у нас нет круга общения людей про BGP и Интернет, тех кто в этом понимает. Скорее всего я не вижу какой-то чат на эту тему, тогда буду рад узнать про него и это был бы лучший вариант. Отсюда вопрос про чат этого канала, это именно опрос без явного намерения, без обещаний с моей стороны при любом исходе.

То что надо для таких песен https://www.youtube.com/watch?v=aPtr43KHBGk

Пока раннеутренние работы подведём итог. Я почему-то ждал другой результат, но с радостью обнаружил что тех кто разделяет моё мнение большинство. Спасибо за поддержку, возвращаемся к сетям.

Я думаю, что многим кто работал с L2 сетями достаточно долго приходилось применять физическую закольцовку патчем, чтобы сменить тэг у вилана: access или trunk native vlan с двух сторон и не забыть обезопасить себя от STP. Даже если и не физическое кольцо, то два коммутатора через такой патч только ради смены номера вилана. Да, некоторые коммутаторы умеют это делать логически на транковом порту менять один тэг на другой, но всё равно физический стык или кольцо сделать придётся. Способ так себе, но все про него знают.

Один из примеров зачем это бывает нужно, чтобы перенести все хосты из одного вилана в другой. Ещё пример, в зоопарке усройств не все виланы бывают одинаково рабочие и когда этот момент прощёлкали при дизайне сети приходится выходить через такой способ на транзитном участке, конечно, до момента пока не переделаешь как надо. Или надо смешать адресацию по какой-то причине, скорее всего тоже недочёты первоначального дизайна или нежелание/невозможность его изменить. В общем, это достаточно грязных хак, чтобы его применять, так делать не надо.

Самый скользкий момент из статьи, на самом деле, не вот этот патч, а смена шлюза на лету. На одном устройстве два одинаковых адреса одновременно сделать не получится, а на двух устройствах - будут разные ARP записи, что тоже приведёт к паузе. Поэтому величина простоя зависит от того как быстро удастся выключить один и включить другой интерфейс, идеально, вместе с виланом и адресацию менять. Когда это делаешь плавно, с новым циклом DHCP подтверждения адреса - старый отзывать, новый назначать, тогда внутри вилана будут существовать два SVI с разными адресами и одновременного простоя для всех устройств не будет. В статье кроме того что этот момент обозначен критическим, подробностей никаких про то как автор решил эту задачу.

Будущее за 50G PON если говорить про будущее PON. Технология PON ближе всего к классическому телекому, это и есть самый что ни на есть телеком, тот который был до Ethernet. Точнее до прямого применения Ethernet сетей в домашних провайдерах, которые собственно и сделали бум провайдеров и проникновения Интернет в крупных городах России.
Теперь многие смотрят на PON и применяют его с его плюсами, как минимум отсутствием активки в каждом втором подъезде в виде коммутатора. Но главный минус, то что нас возвращает на шаг назад, на мой взгляд, это привязка вас как абонента к провайдеру, а провайдера к конкретному вендору, есть нюансы, но часто это именно так. Уйти от одного к другому со своим ONT не получится, да и ONT больше не ваш, в магазине такое не купишь. В равной мере это касается и провайдеров, подружить одного вендора ONT с другим вендором OLT будет сложно. Ещё один разделяющий момент, это узкоспециализированная технология сильно отличающаяся в подходах и синтаксису в настройках у разных вендоров, как итог отсутствие универсальных обучающих материалов, прочитать такое в CCNA/CCNP/CCIE не удастся, а то что ищется сразу гуглом будет очень поверхностным.
PON решает в малоэтажной застройке, но в многоквартирных домах тоже этого много и скорее всего будет больше, спасибо, отчасти обслуживающим компаниям со своими требованиями по размещению активки провайдеров. Будущее у этой технологии точно есть, как минимум оно обозначено.

О, Телеграм вставил таки рекламу в канал (я её кстати не вижу), не знаю успех это или нет. Наверное, на какое-то ключевое общеупотребимое слово сработал, отличное от обычного потока терминов. Постараюсь больше сыпать терминами :) и подумаю надо подпиской, чтобы рекламу отключать.

Великий китайский файрволл подменяет ответы DNS и не только, это есть по ссылке внутри статьи, система так же работает и у нас только на уровне провайдера, что делает возможным определять какая доля запросов выходит за границу Китая, не находясь внутри построенный телеком-системы, но находясь внутри Китая. Исследование которое пытается разобраться в эффективности работы DNS root серверов, в частности F,- I-, J-, K-, L-root anycast ноды которых присутствуют в Китае. Делается обобщение насчёт того что запросы пришедшие без изменений соответствуют запросам внутри страны, а запросы с подменой выходят во вне. На самом деле мы видим что даже для серверов которые не представлены внутри страны, какая-то доля ответов всё равно приходит без изменений, т.е. тут накладываются и другие факторы и к такому обобщению стоит относиться аккуратно.

Что касается эффективности работы корневых серверов и к какому выводу приходят исследователи - наличие ноды в стране не гарантирует что ей будут пользоваться все в этой стране и вы получите оптимальный (минимальный) отклик. На мой взгляд очевидная вещь, потому что во многом Интернет это ещё не страны, а Автономные Системы, отношения между которыми могут быть не очень и в Китае. Но если запрос дошёл до локальной ноды, часто это ограничивается одной AS, то тут уж эффект будет точно.

В России: 1 - E-root, 6 - F-root, 1 - I-root, 2 - J-root, 3 - K-root, 5 - L-root - в основном столицах, в том числе сибирских и дальневосточных.

Про то как вообще строить и обслуживать большие системы, в частности DNS, есть RFC9199 - anycast и связность работают и работают хорошо.

Так понятно, на мой вкус конечно, как Chris Parker мало кто пишет и совсем не важно что на примерах Juniper. В этой статье про Route Distinguishers (RD), одно из ключевых понятий при построении MPLS L3VPN, от азов до практических примеров использования разных типов.

Не забывайте скептически относиться к тестами скорости Интернета и особенно к выводам кто лучше на их основе. У американских провайдеров есть особенность связанная с несимметричностью каналов, это прямо бросается в глаза, но общий подход касается и наших, вроде недавно кто-то хвалился что снова стал самым быстрым.

После маршрутизации на доступе и маршрутизации на хосте, можно переходить к MPLS на хосте. В видео много внимания уделено автоматизации как получать и раскидывать маршруты и настройки по хостам, а то что касается dataplane, вокруг чего всё строится это модули ядра Linux - fou, mpls_iptunnel, mpls_gso и что вы с ними сделаете ограничено только фантазией. В целом, дотащить полноценную, умную сеть, будь это просто маршрутизация на каком-нибудь протоколе или MPLS, до конечного приложения позволяет контролировать весь путь прохождения трафика не отвлекаясь на смены парадигм и протоколов. Здесь мы передаём привет фабрикам и всевозможным оверлеям, которые решают ту же задачу.

Крутой инструмент американского регулятора - интерактивная карта провайдеров, с поиском, с названиями. Для доступа пробуйте VPN или что-то такое из России не получится попасть.

У нашего РКН есть данные в многочисленных реестрах, но они не визуализированы, хотя при желании вытащить какую-то информацию оттуда можно. В виде карт есть "Карты покрытия GSM по регионам", скачиваем RAR внутри по областям и по операторам файлы KML (Google Earth) от 2012 года. Выглядит неплохо, но давно не актуально.

Про TCP теперь новый RFC9293 - всё что накопилось, включая первый RFC793, в одном месте.

Как включенная проверка DNSSEC влияет на производительность? По версии ISC и Bind 9.18.4 - никак не влияет, кроме того что памяти съедает на 10% больше.

Новый выпуск Internet Protocol Journal - про BGP шардинг, войну между уровнями OSI и история SIP который отметил в этом году своё двадцатилетие.