Патчкорд

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

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

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

2022-08-17 16:03:00 Не забывайте скептически относиться к тестами скорости Интернета и особенно к выводам кто лучше на их основе. У американских провайдеров есть особенность связанная с несимметричностью каналов, это прямо бросается в глаза, но общий подход касается и наших, вроде недавно кто-то хвалился что снова стал самым быстрым. Открыть/Комментировать

2022-08-17 12:01:35 Так понятно, на мой вкус конечно, как Chris Parker мало кто пишет и совсем не важно что на примерах Juniper. В этой статье про Route Distinguishers (RD), одно из ключевых понятий при построении MPLS L3VPN, от азов до практических примеров использования разных типов. Открыть/Комментировать

2022-08-16 15:32:00 Про то как вообще строить и обслуживать большие системы, в частности DNS, есть RFC9199 - anycast и связность работают и работают хорошо. Открыть/Комментировать

2022-08-16 11:10:59 Великий китайский файрволл подменяет ответы 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 - в основном столицах, в том числе сибирских и дальневосточных. Открыть/Комментировать

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

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

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

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

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

2022-08-09 06:58:38 Пока раннеутренние работы подведём итог. Я почему-то ждал другой результат, но с радостью обнаружил что тех кто разделяет моё мнение большинство. Спасибо за поддержку, возвращаемся к сетям. Открыть/Комментировать