Патчкорд
2.41K subscribers
203 photos
18 videos
59 files
2.97K links
Блог сетевого инженера. Новости телеком, IT и около IT. Связь - @UrgentPirate
Download Telegram
26-27 апреля где-то под Москвой прошла конференция Мультисервис 2018. Давно не был, но в своё время данное мероприятие (ещё под Екатеринбургом) произвело на меня впечатление горой подарков от телеканалов :)
Собственно с моей колокольни эта конференция про операторов связи с уклоном в телевидение и орг.вопросы вокруг этого, но всякие вопросы касаемо работы интернет само собой затрагиваются, потому что чистых кабельных ТВ операторов наверное уже и нет. И часто это выглядит как давно известные откровения. Но на злободневные темы бывают интересные разговоры, как и на любой другой конференции где собираются живые люди.
Текстовый репортаж на Кабельщике, можно читать пропустив нулевой день и в целом он даёт хорошее представление о происходящем.
Никогда не забывайте о файрволе. Включаем и с чистой совестью отправляемся на выходные.
Коммуникационные навыки которые необходимы каждому IT профессионалу, свежий обзор от CIO.com. Очевидно что когда делаешь что-то для людей и среди людей, то надо как-то с этими людьми общаться. Некоторые правда читерят и сразу становятся гуманитариями :) но навыки вполне себе правильные.

Часто случается что некоторые из них перегибают делая официальными, скажем заставляя впрямую свою техническую идею продавать неподготовленным людям, которым от неё ни тепло ни холодно. Или с тем же жаргоном, который по факту является терминологией, которая и существует для того чтобы однозначно и точно описывать конкретную ситуацию.

Но в общем, да, если наладить эффективную и понятную коммуникацию внутри компании или с клиентом и вывести это всё на неформальный уровень, то становится сильно проще работать. Но на это надо тратить усилия, несомненно.
Whitebox это значит надо потратиться и на аппаратное и на программное обеспечение, а ещё и на тех.поддержку в двойном размере ;)
Когда-то давно в 1995 сделали Zebr'у, в коммерческом варианте ZebOS. Сейчас опять все смотрят на софтовые решения и поэтому сделали OcNOS, которая может MPLS, SDN, EVPN, TRILL, VxLAN, обычные вещи тоже вроде может - RIPv2. И в большой степени основана на достижениях ZebOS.

Продукт коммерческий, посмотреть что к чему можно на видео презентации 2017 года. Если вдруг решили подбирать систему под свои желания, я думаю стоит обратить внимание как на кандидата.
DDoS большая проблема для провайдеров, не говоря уже о других игроках, даже небольших. И может быть особенно небольших. При внешних каналах 10-20Гбит/c получить DDoS на полосу даже 5Гбит/c (что обыденность), чаще 10-15Гбит/c - большая проблема. В зависимости от года и времени года такие всплески могут повторяться каждый день, по несколько часов.
При этом не всегда DDoS именно в этом выражается. Перебор адресов в динамическом пуле NAT, при не совсем аккуратной настройке этого самого NAT, может спровоцировать исчерпание пула - адреса удерживаются даже если абоненту фактически они не нужны. На такую атаку (хотя скорее это побочный эффект) не требуется много ресурсов и она может продолжаться сутками.

Понятно, что постоянно ведётся работа по борьбе как минимум с проявлениями подобных атак. У многих магистральных провайдеров есть blackhole BGP community. Уже есть, так как совсем недавно даже этого не было.

Одна из проблем это, как и во многих других случаях, оповещение и взаимодействие между получателем DDoS и тем кто этот DDoS может отразить или как-то на него повлиять. Различные технические механизмы, впринципе существуют, например, BGP Flowspec, как дополнение к просто community. Но это не говорит о том что эти механизмы используются и запрещается придумывать новые механизмы, формировать способы взаимодействия, определять участников и системы, сценарии применения - как в черновике стандарта DDoS Open Threat Signaling.
Сегодня вроде как день рождения спама, 40 лет. Менеджер DEC решивший сэкономить на рекламе, использовал Arpanet для отправки этого самого спама 400 получателям или 393 по другим источникам.

Никакой вменяемой сегодняшней ссылки не нашлось (хотелось почитать что же там всё таки было в том письме), поэтому вот так - на wired.com немного подробностей из прошлого во всех смыслах, то же на русском у securitylab.ru.

Как таковой спам в классическом понимании лично меня не сильно мучает, фильтры сервера потом Thunderbird почти всё срезают. А вот всякие abuse с автоматическими реакциями в основном на копирайт в торрент сетях с IP наших клиентов, в день по 100 сообщений приходит.
Мегаполезная табличка с типами NAT.
Сначала привыкаешь к терминологии вендоров железа, а потом тебя кто-то спрашивает что такое Symmetric NAT, а ответить нечего - откуда Wikipedia эти термины взяла я так и не понял.
По ссылке стоит обязательно сходить - там серия статей про NAT с подробными и понятными объяснениями.
👍1
Сегодня День Радио, тот самый праздник настоящих связистов олдфагов, ну и всякие теле- радиоведущие тоже отмечают зачем-то.

Для интернет связистов, так-то свой праздник есть - 17 мая Всемирный день электросвязи и информационного сообщества.

С праздником!
👍1
RETN тоже хвалится. Направление Европа-Азия (или Азия-Европа?) теперь ёмкостью 100Гбит/c. Через Транстелеком Казахстан зашли.
Если вам интересна статистика BGP, то никак нельзя пройти мимо вот этого проекта https://www.routeviews.org/, который ведёт архив таблиц интернет маршрутизации с девяностых. Там же есть возможность получить CLI доступ на их коллекторы, публичные route серверы.

Но это если есть желание выводить и отслеживать зависимости самостоятельно. Очень много уже готовой статистики можно найти на https://www.cidr-report.org. По умолчанию для AS2, но можно переключиться и в режим AS6447 (архив по которой ведётся routeviews.org).
Quad9 расширила границы своей DNS структуры (9.9.9.9), при этом у них получилась весьма интересная карта - карта распространения глобального интернета. Это совсем не значит, что там где нет Quad9 нет интернета. С учётом того, что проект молодой и некоммерческий, то карта на мой взгляд отражает те места где проект либо не интересен, либо его туда не пустили, т.е. оказанные усилия (если они были) по проникновению в некоторые территории ещё не успели принести результаты.
Для России скорее не интересен, все разговоры про отделение от мирового Интернета по сути не имеют смысла, нам очень мало надо от мирового Интернета в нетехнической части. У нас есть свой Интернет и большинство именно его и используют.
Точка разграничения ответственности между провайдером и абонентом очень сложный вопрос. Даже с компаниями где в штате есть свой админ и порой не один есть проблемы, а что говорить о домашних подключениях. В частности банально: "Провайдер оставляет себе доступ к роутеру абонента?", если оставляет "Абоненту тоже нужен туда доступ?", а как же пароли? А ещё помним про Wi-Fi с его паролями.
Обычно это выливается в какой-то один пароль который не знает абонент, но который он может поменять для себя, тогда тех.поддержка теряет доступ. Или какой-то генерируемый пароль. С уникальными паролями вообще всё сложно :(
В любом случае какой-то пароль лучше чем вообще без него, не стоит делать как в Бразилии. У роутеров такого класса достаточно своих уязвимостей (хватило 10 дней после огласки, чтобы построить как минимум 5 заметных ботнетов), не стоит добавлять ещё.
Если вдруг решили что-то отметить сегодня, помимо второй пятницы на неделе. То сегодня день рождения у Дейкстры и Феймана. Наши с вами современники, которые поменяли этот мир.
За все годы своей работы в провайдерах, ни разу ни один маркетолог, или PR, или сотрудник абонентского отдела, или кто-то ещё, кроме сугубо технических служб, не выказывал никакого интереса к статистике на основе DPI или другого технического анализа абонентского трафика.
Вот так чтобы прийти и спросить, или как-то отреагировать когда показываешь что у тебя есть возможность получать такие-то данные, или задать вопрос который можно было бы из этих данных получить - ни разу.
А ведь так интересно следить за флуктуациями и движениями живых людей, а не просто отсчитывать занимаемую полосу и момент когда придётся купить новых мегабитов.
У нас есть DPI, но по большому счёту у нас его нет, потому что его функциями никто не пользуется, даже для блокировок. Но и без DPI можно рисовать красивые глубокие картинки (которые, к сожалению, никому не нужны), например, количество абонентов по тарифам в течение суток:

- сиреневый, 50Мбит/c
- зелёный, 25Мбит/c
- бледнорозовый, 75Мбит/c
- яркорозовый, 4,5Мбит/c
- коричневый, должники

И конечно в деньгах (активных договорах) всё почти не так, кроме первого места. Мои знания маркетинга ограничиваются вот этим видео, наверное, для типичного маркетолога в вакууме технические знания ограничиваются подобным видео про то как работает интернет. И как в этом случае найти взаимопонимание тот ещё вопрос.
Если не делать прямо откровенных ляпов, то при написании программ в современных условиях практически на любом языке, очень сложно получить неработающую вещь. Даже в таком сложном варианте как многопоточное программирование. Неявные блокировки, умные обёртки и современные скорости очень редко приводят к ощутимым багам. Если совсем уж не забираться в highload на сотни тысяч запросов в секунду, что в большинстве случаев для целей управления сетевой инфраструктурой запредельные значения, космические.
Но внезапно, в очередной итерации переписывания скрипта дружбы биллинга и BRAS (ах как хотелось бы больше заниматься придумыванием топологий и решать задачки проектирования сетей), обнаружился пик, раз в сутки, в несколько тысяч вызовов в секунду, при том что железной части наверное и 100 вызовов в секунду хватит чтобы умереть.
Решение - построить очередь, но так не хочется переписывать всё с shell, да и пик вроде небольшой, надо-то одну явную блокировочку и пусть система сама разберётся что зачем.
И конечно такое решение есть - flock. Статья про то, как это можно реализовать, фактически очень подробно раскрывается 3-й вариант из man flock. Ещё есть вариант, по-простецки, захватываем или выходим если встречаем блокировку:

mkdir LOCK_DIR || exit
trap "rmdir LOCK_DIR" exit

# тут критическая секция

Хорошо когда твоя институтская база позволяет такое делать, но повод задуматься почему сетевик решает классические задачки про обедающих философов всё же есть.
За всё время осознанного использования компьютера так и не нашёл кому писать шифрованные послания и даже подпись на текущий момент в моём мире скорее понты.
Про Efail от автора GnuPG - с протоколом всё хорошо, с реализацией протокола то же. А вот с почтовыми клиентами не очень, как и с HTML (по своей природе), в том числе и HTML письмами. Согласен с автором: "Зачем они? Чтобы их ещё и шифровать".
Ну вот, сравнение почти классики и Intent-based networking коммутатора. Корректнее было бы сравнивать с 37 серией, но я так понимаю младших с младшими сравнили. Обзор 9300 на cisco.com.