Блог сетевого инженера. Новости телеком, IT и околоIT.
DNS, есть RFC9199 - anycast и связность работают и работают хорошо.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 - в основном столицах, в том числе сибирских и дальневосточных.PON. Технология PON ближе всего к классическому телекому, это и есть самый что ни на есть телеком, тот который был до Ethernet. Точнее до прямого применения Ethernet сетей в домашних провайдерах, которые собственно и сделали бум провайдеров и проникновения Интернет в крупных городах России.
Теперь многие смотрят на PON и применяют его с его плюсами, как минимум отсутствием активки в каждом втором подъезде в виде коммутатора. Но главный минус, то что нас возвращает на шаг назад, на мой взгляд, это привязка вас как абонента к провайдеру, а провайдера к конкретному вендору, есть нюансы, но часто это именно так. Уйти от одного к другому со своим ONT не получится, да и ONT больше не ваш, в магазине такое не купишь. В равной мере это касается и провайдеров, подружить одного вендора ONT с другим вендором OLT будет сложно. Ещё один разделяющий момент, это узкоспециализированная технология сильно отличающаяся в подходах и синтаксису в настройках у разных вендоров, как итог отсутствие универсальных обучающих материалов, прочитать такое в CCNA/CCNP/CCIE не удастся, а то что ищется сразу гуглом будет очень поверхностным.
PON решает в малоэтажной застройке, но в многоквартирных домах тоже этого много и скорее всего будет больше, спасибо, отчасти обслуживающим компаниям со своими требованиями по размещению активки провайдеров. Будущее у этой технологии точно есть, как минимум оно обозначено.L2 сетями достаточно долго приходилось применять физическую закольцовку патчем, чтобы сменить тэг у вилана: access или trunk native vlan с двух сторон и не забыть обезопасить себя от STP. Даже если и не физическое кольцо, то два коммутатора через такой патч только ради смены номера вилана. Да, некоторые коммутаторы умеют это делать логически на транковом порту менять один тэг на другой, но всё равно физический стык или кольцо сделать придётся. Способ так себе, но все про него знают.
Один из примеров зачем это бывает нужно, чтобы перенести все хосты из одного вилана в другой. Ещё пример, в зоопарке усройств не все виланы бывают одинаково рабочие и когда этот момент прощёлкали при дизайне сети приходится выходить через такой способ на транзитном участке, конечно, до момента пока не переделаешь как надо. Или надо смешать адресацию по какой-то причине, скорее всего тоже недочёты первоначального дизайна или нежелание/невозможность его изменить. В общем, это достаточно грязных хак, чтобы его применять, так делать не надо.
Самый скользкий момент из статьи, на самом деле, не вот этот патч, а смена шлюза на лету. На одном устройстве два одинаковых адреса одновременно сделать не получится, а на двух устройствах - будут разные ARP записи, что тоже приведёт к паузе. Поэтому величина простоя зависит от того как быстро удастся выключить один и включить другой интерфейс, идеально, вместе с виланом и адресацию менять. Когда это делаешь плавно, с новым циклом DHCP подтверждения адреса - старый отзывать, новый назначать, тогда внутри вилана будут существовать два SVI с разными адресами и одновременного простоя для всех устройств не будет. В статье кроме того что этот момент обозначен критическим, подробностей никаких про то как автор решил эту задачу.API). Но посчитать всё равно получилось. Итого, палец вверх:
- Про мою домашнюю сеть, которая с тех пор ещё усложнилась
- Про тайны мадридского двора за кулисами tzdata
- И, конечно, всем нравится день сисадмина
Палец вниз:
- Про настоящий телеком, который начинается с уровня 0
- Про свой центр сертификации
- Ещё про модель OSI, Cisco пинги и пинание дохлых лошадей
Конечно, я напомню, что есть ещё https://host-correct.ru/ с DoH и DoT, и боты с BGP таблицами @FullViewBGPbot - данные с коллекторов RIPE NCC и @bgp_table_bot - данные из Twitter бота. Сейчас мне катастрофически перестало хватать мощностей на моей VPS поэтому в самое ближайшее время накину ещё, и должно стать полегче.
Если кто-то ещё задаётся вопросом про что же этот канал, то могу почти процитировать, то что мне не так давно написал наш читатель - "канал с выжимками статей блогов RIPE и APNIC и околосетевой тематикой". Лично мне хочется думать что этот канал про Интернет, тот который под капотом, про отдельные его детали. Спасибо всем кто читает, спасибо всем кто присылает что-то в ответ, двигаемся дальше.system router resources, а потом Foundry BigIron когда я так переигрался с max-параметрами, что ему не хватило памяти для загрузки. В нём же была возможность агрегировать записи FIB: ip net-aggregate и dr-aggregate.
В BGP FullView можно начать с 0.0.0.0/0 даже в случае больше двух аплинк-провайдеров и добавлять только то что нужно, в большинстве случаев, если вы находитесь на границе Интернета, разницы от "неоптимальной" маршрутизации будет незаметно.sed и egrep, у меня есть встроенный в FAR редактор и Notepad++ где есть регулярные выражения и не проходит дня чтобы я что-то не написал. Ещё я часто встречаю мнение что это слишком сложно и непонятно. К сожалению, я потерял в памяти точный момент когда я стал использовать регулярные выражения на постоянной основе, поэтому не могу посоветовать как начать их использовать, но я точно знаю что не читал никаких учебников и никакой теории, всё на практике. Я не считаю себя мастером, но это не мешает мне, пусть может не оптимально, но решать свои задачи.
Две крайности которые стоит избегать - матана с грамматиками Хомского, это очень увлекательно и вообще надо бы конечно знать, хотя бы в общих чертах, но точно не брать это в расчёт начиная работать с регулярными выражениями на практике. Вторая крайность готовые регулярки и всякие генераторы регулярок, не понимая что это значит как минимум можно словить редко воспроизводимую ошибку, как максимум нарваться на откровенное вредительство. Возьмите любой удобный инструмент и пробуйте, не стоит оптимизировать сразу да и потом в большинстве случаев это не нужно, пишите понятно для себя.hijack, как в этом случае, поможет подписать свои префиксы и чтобы большинство начало фильтровать недействительные префиксы, к этому мы движемся достаточно бодро. В ситуациях сложнее должен помочь ASPA и некоторые другие механизмы, Qrator спасибо за популяризацию и продвижение. И MANRS тоже, берите политики и внедряйте, там не так сложно как может показаться.ACL, то у Google есть capirca. Есть много всего, популярные точно, периодически что-то обновляется, желающим можно пускать из Docker.