likeabus channel

Всем привет! У нас тут шестой митап намечается, на этот раз снова в Питере. Если вы никогда не были и сомневаетесь, то просто приходите и посмотрите вживую. А если уже не в первый раз, то берите коллег и будем рады вас видеть! А ещё в этот раз с квизом нам помогает Ира Маркова из подкаста «До нас дошло»! Их каналы: https://t.me/donasdoshlo и https://vk.ru/donasdoshlo Когда: 17 сентября, сбор с 18:30 Где: Санкт-Петербург, Арсенальная улица 2, лофт Agava Программа, спикеры и регистрация: https://likeabar.ru Отдельное спасибо ребятам из Бифорком Тек за поддержку! Репостим, лайкаем, регистрируемся на сайте, ну и вступайте в чатик, где будут новости и прочее — @likeabar

https://store.steampowered.com/app/4986050/Network__Cyber_Security_Simulator/ пятничное ☁️

Коллеги тут статейку написали на тему работы нашего оверлея со всякими подробностями https://habr.com/ru/companies/mws/articles/1051982/ Первый раз вижу, чтобы виртуальным машинам давали имена и тем более называли их Серёгами 🤪 Но статья правда интересная, раскрывает некоторые детали, которые я не успел осветить в своём докладе Почитайте на досуге :)

https://clocks.brianmoore.com/ 15 разных моделей генерят обычные часы с отображением текущего времени Каждая модель может использовать только 2000 токенов После 20 минутного наблюдения, в косяках, разной степени тяжести, были замечены вообще все из предложенных моделей 🫡

в соседнем чатике поделились прошлогодней статейкой про IPv6, любопытная https://www.indata.org.ru/stradaniya-po-ipv6-ili-30-let-ipv6/ казалось бы, есть технология - берите и используйте, но увы, люди склонны находить "любимчиков" даже в протоколах :) и ооооооооооочень не любят что-то менять, понимаю... видел неоднократно инфраструктуры на IPv4, где уже количество хостов и машин явно превышало изначально запланированное и где идёт борьба за каждую /24, где стараются экономить буквально на всём, начиная от p2p адресов, до подсетей на сервера и даже переиспользуют текущие подсети в изолированных друг от друга сегментах это всё конечно не есть хорошо, и очевидно в тот или иной момент времени может приводить к разным последствиям, изолированные сегменты внезапно должны быть смешаны по какому-то невероятному стечению обстоятельств и вот вы уже ставите на границе NAT, или запланированные /26 на сегмент, внезапно начинают мигрировать в K8s и там получается расход сильно выше, ну и многое другое. в общем, это я всё к чему, если у вас небольшая сетевая инфра, ну не знаю, пара офисов, несколько стоек в машзале, то конечно не нужен вам никакой IPv6, или допустим уже эксплуатируете одну и ту же сеть 15 лет, она устоявшаяся, не растёт как грибы и оставшегося запаса адресов вам достаточно, то не надо ничего ломать ради какого-то непонятного профита, оставляйте всё как есть, без шуток но, если вы строите гринфилд и у вас изначально планируется несколько машзалов или ЦОДов и расход адресов на этапе стройки уже видится как десятки, а то и сотни тысяч префиксов, то кажется стоит сразу думать про IPv6, хотя бы просто посчитайте и сравните, может и не подойдёт он вам, но вы будете точно понимать, а не просто делать как привыкли ну и вот в качестве примера наш underlay, весь на IPv6 и в GRT нет IPv4 вообще xxx#sh ip route ... IP Route Table for VRF "default" C 127.0.0.0/8 is directly connected Gateway of last resort is not set xxx# так что, не бойтесь вы этих протоколов, они оба, что IPv4, что IPv6 всего лишь инструменты в наших с вами руках P.S. а ещё относительно недавно был зафиксирован случай, когда использование IPv6 по всему миру превысило 50% - https://habr.com/ru/news/1024624/

А вот и запись подъехала https://vkvideo.ru/video-18872388_456239928?t=11m

Вот пишу я тут пишу и периодически случаются такие вещи, что понимаешь - все это не зря. Про одну из таких хочу рассказать. Где-то в середине февраля, ко мне обратился подписчик (далее Андрей), с вопросом о том, есть ли у какие-то знакомые среди сетевиков, которые преподавали в официальной программе Cisco Academy. Ну я естественно поинтересовался зачем и в чем собственно суть вопроса и выяснилось, что он сам преподаватель в одном техническом вузе, ведёт "компьютерные сети" и у него есть студент (далее Илья), незрячий. И вот все его преподавательское окружение вынесло вердикт - незрячих сетевиков не бывает, забудь! Но он решил все-таки попробовать и начал изучать различные материалы, а так как у них часть сетевой программы проходят в Cisco Packet Tracer, то отсюда и вопрос про преподавателей возник. Признаться честно, я никогда с подобным не сталкивался, но пройти мимо не мог. Пообщались с Андреем и определили чем я тут вообще могу помочь, в итоге я себе взял небольшой список в работу. На первом месте, в нем был пункт “изучить возможности CPT”. Оказывается, каждая уважающая себя компания, к своему софту публикует VPAT (Voluntary Product Accessibility Template) — стандартный документ, который описывает, насколько тот или иной софт доступен людям с ограниченными возможностями. Packet Tracer не является исключением и такой документ к нему тоже есть. В общем поизучав структуру, стало понятно, что сам документ предназначен в первую очередь для обучающихся, чтобы они изучая его совместно с преподавателем, могли понять насколько данный софт адаптирован под их конкретные ограничения. Передал это все Андрею и он дальше пошел совместно с Ильей выяснять что и как. Следующим пунктом в моем списке была попытка найти кого-то из программы Cisco Academy и выяснить, есть ли какие-то нюансы, возможно дополнительные плагины или что-то такое. Идея эта возникла потому что в VPAT явно указано - обратитесь к вашему тренеру за дополнительной информацией. Ок, пошел искать. Поговорив с несколькими ребятами, выяснил следующее: а) никакого доп. софта нет; б) сертификационный центр может помочь на экзамене с какой-то частью, но для нас это было не актуально, т.к. речи об экзаменах в Cisco не шло. Поделившись этой инфой, пошел выяснять детали по заключительному пункту. Есть такая поговорка - человека учит человек. Очень она мне нравится. Так вот третий пункт возник именно из-за нее. У меня есть друг, у которого есть знакомый, который незрячий и работает инженером в одном бигтехе. Не сетевым, а всякие линуксы крутит, да сервера админит. И вот я подумал, хорошо ведь если он поделится своей мудростью с начинающим. Пошел к нему с вопросами, что и как, а можно ли, а как вообще работать и т.д. В итоге оказалось, что они с Ильёй уже знакомы и где-то то ли пересекались, то ли переписывались. Ну в общем переопыление произошло! Пообщавшись обо всем этом с Андреем, смогли наметить какой-то вектор работы. Он в свою очередь выяснил совместно с Ильёй условия VPAT, оказалось что вполне себе рабочая история. Дальше они уже пошли заниматься по лабам и готовиться к экзамену на летнюю сессию. И вот, спустя несколько месяцев мне приходит от него сообщение: «Доброго вечера! Илья сегодня сдал контрольное испытание (демонстрационный экзамен)! Мало того сдал первым из 12 сдающих с ним!». Охохохо! Вот так новости! 🔥 Ну сказать что я обрадовался, ничего не сказать конечно :), то какую работу провели они оба - это заслуживает уважения. Андрею буквально за один день, когда он загорелся этой идеей, сказало несколько человек «это невозможно» и вот результат. Илья же вообще пример сильнейшего упорства и целеустремленности, чего в наше время порой так мало. Ну а я, а что я :) толком ничем не помог, разве что поддержал ребят добрым словом в трудную минуту, но иногда кажется это тоже чего-то да стоит. Кстати, тот инженер, который из бигтеха - это Женя Некрасов, много лет работает в VK, очень крутой специалист, недавно выступал с докладом на CodeFest. Пишет всякое у себя на канале и активно старается помогать людям, столкнувшимся с похожей проблемой ❤️

сходил вчера на сетевое лето, рассказал про наше облако, ну вроде неплохо прошло, всем спасибо! чуть позже обещали запись, как будет - обязательно сюда закину 👍

листал хабр, а там оказывается вчера @eucariot статью написал и молчит, скромный что ли? вторая часть про нейросети эти ваши, про RoCE и RDMA, NVLink и GPUDirect и многое другое не пожалел буков, чуть более 78 тыщ символов, такое мы уважаем больше хвалить смысла нет, там всё по классике, идите и читайте о, а ещё из любопытного, среди благодарностей, 6 спасиб (или спасибов?) в пользу людей и целых 7 в пользу нейронок напрашивается размышление в духе ящера.жпг "кто же пишет текст, Марат пользуясь нейронками, или нейронки пользуясь Маратом?" 🤣 https://habr.com/ru/companies/yandex/articles/1047072

чет разбирал всякое на компе, попались под руку вот две книжки, обе не новые, но обе хорошие, не важно на каком вендоре вы строите evpn-vxlan, почитать стоит, хотя бы просто полистайте и посмотрите какие-то конфигурации, дизайны

чет разбирал всякое на компе, попались под руку вот две книжки, обе не новые, но обе хорошие, не важно на каком вендоре вы строите evpn-vxlan, почитать стоит, хотя бы просто полистайте и посмотрите какие-то конфигурации, дизайны

Под капотом облачной сети: overlay, underlay и полный путь трафика Во второй половине дня на сцене «Люди и сети» Сетевого лета будет встреча с Сергеем Бочарниковым, техлидом MWS Cloud Platform. Сергей расскажет о том, как устроена сетевая архитектура современного облака: ☁️ Разберём подходы к построению underlay- и overlay-сетей, используемые технологии и архитектурные решения. ☁️ Рассмотрим реализацию сервисов, сетевых функций и особенности обеспечения связности, масштабируемости и надёжности облачной инфраструктуры. Встречаемся в 17 часов. Регистрация открыта, будем вас ждать! 🦀 А ещё больше о сетевых технологиях и около Сергей рассказывает в своём канале 😏

позвали тут рассказать про облако наше, ну я и согласился), приходите, пообщаемся!)

Был недавно неделю в Китае, конкретно в Чэнду. Это столица Сычуани. Ну не могу сказать, что это прям будущее, но работа уже там была проделана огромная, и продолжается до сих пор. Из любопытного, поиск водителя в такси занимает от 4 до 6 секунд. По крайней мере вот мы заказывали около 10 раз и в этот диапазон уложились все. То есть сюда входит анализ вашей локации, выбранного тарифа, водителей вокруг и наверняка что-то ещё. Нажали кнопку вызвать - через 5 секунд вам приложение показывает номер и марку машины водителя, он же примерно в течении 5 минут будет на месте. Доставку по отелю нам осуществлял робот. Выглядит как робот-пылесос, только большой. Стоит на зарядке на ресепшене и когда курьер доставляет что-то в отель (еду, медикаменты, одежду, хз что там ещё), то администратор просто кладёт это в приёмник робота, жмёт ему нужный номер и всё. Дальше он сам уже вызывает лифт, доезжает до необходимого этажа, привозит к номеру и через вызов по местной телефонии сообщает вам о том, что он ждёт за дверью. Ну и выходишь забираешь у него из приёмника на башке. Естественно все операции, такие как вызов лифта, выбор этажа, уведомление о доставке этот парень выполняет без всяких нажатий. Про 5G нечего особо сказать, ловит почти везде, а где не ловит, то там 4G. Никаких проблем со скоростью или стабильностью я тоже не заметил. Причем мы были не только в самом городе, но и ездили по пригородам, и немного в горы уезжали. Везде ок. Фаервол работает. Гугл, инстаграм и даже телега не алё, но т.к. у меня был eSIM из Гонконга, то всё работало, роуминг знаете ли 👍 Ещё из интересных приколов. Так как вокруг практически все автомобили - это электрички, то можно спокойно идти рядом с проспектом в несколько полос и спокойно общаться. Ну и везде панды, стритфуд, китайцы. Это то самое место, где ты по-настоящему понимаешь, что такое языковой барьер. Где-то в 2018 я уже был в Шанхае, и тогда это ощутил впервые, так вот спустя годы стало сильно лучше за счет всяких сервисов, которые позволяют переводить голос, текст и т.д., но всё равно английский знают редкие единицы и стоит тебе лишиться связи, к примеру батарейка села в телефоне или что-то с тарифом, то всё, считай, что ты немой и слепой одновременно. Ты не поймёшь ни чисел, ни букв (буквы ахаха), ни кого-то вообще. Простой выбор еды превращается в какой-то рандом. Но стоит конечно отметить, что китайцы очень добродушные и гостеприимные, они прям рады, всячески помогают и стараются проявить радушие. В общем вот, захотелось снова начать учить китайский, уже была попытка 2 года назад, потратил примерно 3-4 месяца и забросил. Может быть стоит попробовать ещё раз и в этот раз что-то получится.. 😁

Писал когда-то давно тут про радиацию в интернете. Так вот, наткнулся опять тут на ряд статей по одному из таких проектов, а именно по UCSD Network Telescope. UCSD Network Telescope - это один из крупнейших и старейших сетевых телескопов. Существует уже порядка 25 лет. На его основе написали чуть более 300 статей и продолжают. Сам телескоп - это конструкция из роутера, оптического сплиттера, виртуалок и хранилки. Анонсируют /9 и /10, дальше принимают на них трафик, часть из которого является валидным. На уровне сплиттера дублируют и копию перенаправляют в ВМки. Ну и в итоге уже анализируют. Очевидный вопрос - зачем он вообще нужен и какой от него толк? Короткий ответ - эта штука позволяет изучать интернет как некоторое явление, собирать о нём данные и анализировать. Если же смотреть чуть детальней, то вот некоторые полезности: - во-первых он показывает DDoS, который прилетает на ваши адреса в интернете, при этом вам не нужно получать эти данные от жертвы; - во-вторых, можно изучить сам "опасный" трафик и более осмысленно на него влиять; - в-третьих, показывает флуктуацию и тем самым сбои, блекауты, цензуру, т.е. был шум, а потом бац и нет. Сам проект держится исключительно на энтузиастах и в последнее время у ребят уже начинаются проблемы с финансированием и поддержкой, т.к. сам шум растёт, DDoS всё больше, а инфраструктура очень слабо развивается. Плюс они используют честные белые IPv4 адреса, которые на вес золота, что и привело к сокращению самого полезного пространства телескопа на 37%. Если интересуетесь, то вот тут все статьи по теме - https://catalog.caida.org/search?query=types=paper%20links=collection:ucsd_telescope_datasets

Нам тут нарезочку с митапа прошедшего смонтировали. Для тех кто не был - отличная возможность наглядно увидеть что и как происходит. И как обещал, записи докладов с презентациями. В этот раз постарался сделать получше, но пока что далеко от идеала. Доклад 1. Дмитрий Волков. B4COM. Дизайн SP фабрики и её интеграция с оптикой. Дмитрий поделится опытом и трендами в построении магистральных сетей, как они себе это сейчас представляют в плане архитектур и на что следует обратить внимание. Смотреть доклад Презентация Доклад 2. Владимир Романенко. Selectel. Чек лист выбора eBGP аплинка. Владимир за годы работы сетевиком собрал для себя некий набор правил, которые следует учитывать при выборе внешних пиров. Самое вкусное - все правила выстраданы на личном опыте, о чем нам и поведают! Смотреть доклад Презентация Доклад 3. Роман Епифанов. Ретикулум! да, это кажется заклинанием из ГП, но это такая хреновина, позволяющая строить параллельный Интернет без IP и будто бы достаточно актуальная в современном мире, ну и как минимум просто очень любопытно :) Смотреть доклад Презентация Ещё раз хочу сказать отдельное спасибо ребятам из B4COM за поддержку, MWS за предоставленный мерч, а также всем тем, кто помогал в подготовке, на площадке и т.д. И конечно же всем вам, читателям канала и участникам митапа ❤️

Вот тут писал уже про Jellyfish, как один из примеров топологий, построенных по принципу случайного графа. И спустя год, AWS заявляет, что разработали и уже 2 года используют внутри своих ДЦ архитектуру, под название RNG и базирующуюся на идеях того же Jellyfish, а именно на случайных коммутациях между узлами. Специально для вас, собрал всю инфу, прочитал и разобрал, вот получившийся небольшой саммари. Почему это вообще интересно? Всё из-за денег. Изначально разработчики Jellyfish утверждали, что их топология способна существенно снизить расходы , тем самым снизив и общую стоимость к построению и эксплуатации ДЦ. Собственно в AWS посчитали, и решили что игра стоит свеч. Почему так не делали раньше и в чем собственно проблема этих топологий? Проблема 1. Маршрутизация. Вы не можете взять и роутить всё с помощью дефолтного BGP или какого-то другого популярного протокола. Тут вам не CLOS и ровно суть топологии в том, что есть огромное количество альтернативных маршрутов, которые точно не будут выбраны как лучшие. Проблема 2. Кабель менеджмент. Ну здесь всё понятно. Вы коммутируете случайно - получаете хаос. Потом сами же и страдаете. Не понятно кто куда воткнут, да и не понятно куда втыкать дальше. Плюс ещё и проблемы с расстояниями могут возникать, если вдруг случайно окажется так, что нужно прокинуть коммутацию между рядами... Проблема 3. Предсказуемость производительности Тут суть в том, чтобы заранее посчитать переподписку и соответственно правильно масштабировать нагрузку. Если мы берём наш любымый fat-tree, то там всё просто - считаем downlink с uplink и дальше исходя из этого принимаем решение. Но тут ведь хаос, и подобный сценарий не работает. Как вы догадались, раз уж они перешли на эту странную архитектуру, то и проблемы были решены. Итак, как решили три вышеописанные проблемы? Начнём с первой - с маршрутизации. Собственно, всё просто, они разработали новый протокол - Spraypoint. Судя по всему, это тот же link-state, только с добавлением использования не лучший путей. Т.е. грубо говоря, каждый узел знает всё о всех, но для достижения какого-то хопа, маршрутизирует пакетики сразу во ВСЕ известные ему каналы. Если я правильно понял, то вот этот механизм распыления трафика (spraying) и был причиной такого названия протокола! Следующая проблемка - кабель менеджмент. Тут ребята тоже не стали искать лёгких путей и разработали штуку, под названием ShuffleBox. Это в общем поделка, а точнее пассивное оптическое устройство, которые перемешивает (shuffle как в winampe, ага), все соединения между хостами. Т.е. получается будто бы случайно, но при этом и контролируемо... И заключительная боль - это производительность и её предсказание. Если вот всё что выше, я в целом догадывался как можно сделать, то тут кажется всё слишком сложно, но как оказалось, что случайные графы в своей совокупности дают крайне предсказуемые результаты. Исходя из этого, ребята просто вывели формулу, которая позволяет им спрогнозировать тот самый скейлинг. Вот такую: The oversubscription ratio is approximated by (𝜇2 + 𝜇3 + 𝜇4 + 𝜇5) −¹, где 𝜇2 = 𝑑/𝑛 𝜇3 = 𝜙3𝜅3 𝜇4 = [1 − (𝑝 + 1)𝑑/𝑛 − exp(−𝑝𝑑²/𝑛)] · (1 − [1 − (1 − 2𝑑/𝑛) (1 − (4𝑑/𝑛)ʰ)]ʰ) · (1 − 𝜇2 − 2𝜇3)/4 𝜇5 = exp(−𝑝𝑑²/𝑛) (1 − 𝜇2 − 2𝜇3 − 3𝜇4)/5 А дальше оттестировали её в симуляциях, где подтвердили верность расчета. В итоге теперь просто берут вводные данные (число свичей, количество аплинков, всякое из spraypoint) и получают нужный результат. И это работает уже? Да, утверждают, что с 2024 года перевели ДЦ в Ирландии на RNG, дальше в 2025 Испания и Германия, и планируют в 2026 внедрить повсеместно. В итоге, им удалось сократить расход коммутаторов от 9 до 45% и повысить пропускную способность на некоторых участках до 30%. Опять же, если верить числам в документе. Немного ссылок по теме: https://arxiv.org/pdf/2604.15261 https://www.amazon.science/blog/how-flat-is-replacing-fat-in-aws-data-center-networks https://www.aboutamazon.com/stories/aws-random-graph-theory-data-center-network-design И отличный ролик от создателей: https://youtu.be/yDoRYRRPOA0

А есть тут кто-то из Теле2? Кажется у вас обрыв… К слову это уже больше месяца так :)