Будни сетевика в деревне!
Задача: запустить бортовой УАЗик 3303 после годового простоя.
Инструкция в 22 шага.
1. Заряжаем аккумулятор, тут все просто - берем акум, берем зарядное устройство, соединяем их вместе и оставляем наедине часа на три.
2. Проверяем уровень масла в двигателе.
3. Доливаем тосол.
4. Меняем свечи зажигания, лучше поставить новые, но если их нет, то можно прокалить и почистить имеющиеся. Тут я подготовился и привез новые.
5. Устанавливаем аккумулятор, а на его место сразу ставим на зарядку запасной, будьте уверены - он пригодится.
6. Установлен штатный топливный насос ручной подкачки, поэтому перед первым пуском помогаем ему руками накачать бензин в карбюратор.
Можно запускать двигатель!
7. Пробуем и видим дым под приборкой, прям нормально так дыма! Быстро снимаем клемму аккумулятора и пытаемся вытолкать его из деревянного гаража, чтобы не спалить все вокруг.
9. Снимаем крышку приборной панели, находим обуглившиеся провода, дальше изолента делает свое дело.
10. Разряжаем аккумулятор в безуспешных попытках запустить двигатель, что в принципе, ожидаемо - см. п.5.
11. Берем с зарядки запасной аккумулятор, устанавливаем.
12. Можно пробовать снова, но в этот раз откручиваем крышку воздушного фильтра, чтобы был доступ к карбюратору и немножко подливаем напрямую в него бензина, почти как впрыск закиси азота в форсаже 😅
13. На 3-4 секунды мотор возвращается к жизни, но из-за плохо качающего топливного насоса(но это я так думаю) надо повторить предудущий пункт 3-4 раза.
14. При условии, что еще не залили свечи к этому моменту двигатель должен запуститься.
15. Мотор тарахтит (или работает как часы) пару минут, обнаруживаем протекающий топливный шланг, запасного нет.
16. Но к счастью, протечка у самого места присоединения к топливному фильтру, поэтому можно его обрезать на 2см и вернуть на место, длины все еще хватает!
17. Ну все, поехали! Включаем первую передачу, а она не включается и вторая не включается и вообще никакая не включается. При этом в гараж год назад он заехал сам!
18. Просим шестилетнего сына понажимать на педаль сцепления, а сами лезем под УАЗик посмотреть на цилиндр сцепления и убедиться, что его надо снять и выкинуть на помойку, потому что он вообще не шевелится. 2-3 удара молотком приводят его в чувство, но только на два выжима сцепления.
19. Снимаем цилиндр сцепления, ставим новый (был в запасе).
20. Ищем, а где же у УАЗика находится бачок жидкости цилидра сцепления. Выясняем, что он прям «под носом».
21. Заливаем тормозную жидкость в бачок, ищем кого-то постарше - нужно прокачать систему.
22. Пока кто-то жмет на педаль спепления, лезем под УАЗик и спускаем воздух из системы.
Ну теперь-то можно ехать, да? Да!
Инструкция не универсальна и может отличаться от одного экземпляра к другому.
P.S. Но это не вся история, потому что без проблем он ездил только 7 дней, дальше приключения продолжились. Если тут такое интересно, то будет вторая часть, а также история про мотоцикл Восход 3М.
#Задача
Задача: запустить бортовой УАЗик 3303 после годового простоя.
Инструкция в 22 шага.
1. Заряжаем аккумулятор, тут все просто - берем акум, берем зарядное устройство, соединяем их вместе и оставляем наедине часа на три.
2. Проверяем уровень масла в двигателе.
3. Доливаем тосол.
4. Меняем свечи зажигания, лучше поставить новые, но если их нет, то можно прокалить и почистить имеющиеся. Тут я подготовился и привез новые.
5. Устанавливаем аккумулятор, а на его место сразу ставим на зарядку запасной, будьте уверены - он пригодится.
6. Установлен штатный топливный насос ручной подкачки, поэтому перед первым пуском помогаем ему руками накачать бензин в карбюратор.
Можно запускать двигатель!
7. Пробуем и видим дым под приборкой, прям нормально так дыма! Быстро снимаем клемму аккумулятора и пытаемся вытолкать его из деревянного гаража, чтобы не спалить все вокруг.
9. Снимаем крышку приборной панели, находим обуглившиеся провода, дальше изолента делает свое дело.
10. Разряжаем аккумулятор в безуспешных попытках запустить двигатель, что в принципе, ожидаемо - см. п.5.
11. Берем с зарядки запасной аккумулятор, устанавливаем.
12. Можно пробовать снова, но в этот раз откручиваем крышку воздушного фильтра, чтобы был доступ к карбюратору и немножко подливаем напрямую в него бензина, почти как впрыск закиси азота в форсаже 😅
13. На 3-4 секунды мотор возвращается к жизни, но из-за плохо качающего топливного насоса(но это я так думаю) надо повторить предудущий пункт 3-4 раза.
14. При условии, что еще не залили свечи к этому моменту двигатель должен запуститься.
15. Мотор тарахтит (или работает как часы) пару минут, обнаруживаем протекающий топливный шланг, запасного нет.
16. Но к счастью, протечка у самого места присоединения к топливному фильтру, поэтому можно его обрезать на 2см и вернуть на место, длины все еще хватает!
17. Ну все, поехали! Включаем первую передачу, а она не включается и вторая не включается и вообще никакая не включается. При этом в гараж год назад он заехал сам!
18. Просим шестилетнего сына понажимать на педаль сцепления, а сами лезем под УАЗик посмотреть на цилиндр сцепления и убедиться, что его надо снять и выкинуть на помойку, потому что он вообще не шевелится. 2-3 удара молотком приводят его в чувство, но только на два выжима сцепления.
19. Снимаем цилиндр сцепления, ставим новый (был в запасе).
20. Ищем, а где же у УАЗика находится бачок жидкости цилидра сцепления. Выясняем, что он прям «под носом».
21. Заливаем тормозную жидкость в бачок, ищем кого-то постарше - нужно прокачать систему.
22. Пока кто-то жмет на педаль спепления, лезем под УАЗик и спускаем воздух из системы.
Ну теперь-то можно ехать, да? Да!
Инструкция не универсальна и может отличаться от одного экземпляра к другому.
P.S. Но это не вся история, потому что без проблем он ездил только 7 дней, дальше приключения продолжились. Если тут такое интересно, то будет вторая часть, а также история про мотоцикл Восход 3М.
#Задача
🔥47❤3🤣1
This media is not supported in your browser
VIEW IN TELEGRAM
Будни сетевика. Летний режим.
Есть много интересного, чем хочется поделиться, но пока не могу собраться и написать. Почему?
Потому что купил в деревне ендуро и теперь, к сожалению или к счастью, ничем другим в свободное время не занимаюсь, но все будет 🙂
Сейчас еду в Минск на B.E.E.R — Best Engineering Event in Republic ,где расскажу про наш OkkoCDN. Конференция через неделю, но было решено ее совместить с небольшим отпуском, чтобы посмотреть окрестности.
Кто будет на конфе - рад буду пообщаться!
Есть много интересного, чем хочется поделиться, но пока не могу собраться и написать. Почему?
Потому что купил в деревне ендуро и теперь, к сожалению или к счастью, ничем другим в свободное время не занимаюсь, но все будет 🙂
Сейчас еду в Минск на B.E.E.R — Best Engineering Event in Republic ,где расскажу про наш OkkoCDN. Конференция через неделю, но было решено ее совместить с небольшим отпуском, чтобы посмотреть окрестности.
Кто будет на конфе - рад буду пообщаться!
🔥25👏2💋1
Сегодня побывал на подкасте у Андрея Соколова! 🎙️
Обсудили множество IT-тем, но спойлерить не буду — ждите выпуск на его YouTube-канале! 🔥
Для меня это был первый подобный опыт, и, думаю, для дебюта вышло неплохо. Мне даже понравилось.
Обсудили множество IT-тем, но спойлерить не буду — ждите выпуск на его YouTube-канале! 🔥
Для меня это был первый подобный опыт, и, думаю, для дебюта вышло неплохо. Мне даже понравилось.
🔥25👍6👏5
Сегодня на BEER в Минске я рассказывал о нашем OkkoCDN и о том, как мы достигли раздачи в 6 Tb/s. Записи не будет, так что придется поверить на слово.
Что касается организации, мероприятие, конечно, уступает конференциям и митапам в СПб и Москве, но коллеги старались, и я благодарен за возможность выступить.
Несколько нюансов: перед моим выступлением сломался кликер, на презентации у части текста слетела кодировка, и шрифты «поехали». Аудитория не была целевой для тематики CDN, и ровно посередине доклада один из слушателей (он же следующий спикер) решил уточнить, не собираюсь ли я учить его, как правильно оптимизировать серверы под высокие нагрузки. 🤷♂️
Эх, знать бы, как всё правильно настраивается, и как взять и сразу всё сделать верно! 😅
Все мои выступления направлены на то, чтобы поделиться нашей историей развития. Я понимаю, что можно было бы сделать всё более оптимально и надежно, но мне нравится обсуждать с коллегами их решения до или после выступления, брать идеи для реализации или просто вступать с кем-то в дискуссию (в хорошем смысле этого слова).
P.S. Если кто-то точно знает, как сделать что-то правильно (неважно что), напишите мне! 😅
Что касается организации, мероприятие, конечно, уступает конференциям и митапам в СПб и Москве, но коллеги старались, и я благодарен за возможность выступить.
Несколько нюансов: перед моим выступлением сломался кликер, на презентации у части текста слетела кодировка, и шрифты «поехали». Аудитория не была целевой для тематики CDN, и ровно посередине доклада один из слушателей (он же следующий спикер) решил уточнить, не собираюсь ли я учить его, как правильно оптимизировать серверы под высокие нагрузки. 🤷♂️
Эх, знать бы, как всё правильно настраивается, и как взять и сразу всё сделать верно! 😅
Все мои выступления направлены на то, чтобы поделиться нашей историей развития. Я понимаю, что можно было бы сделать всё более оптимально и надежно, но мне нравится обсуждать с коллегами их решения до или после выступления, брать идеи для реализации или просто вступать с кем-то в дискуссию (в хорошем смысле этого слова).
P.S. Если кто-то точно знает, как сделать что-то правильно (неважно что), напишите мне! 😅
🔥15👍7🗿4🤯1
Пишет мне тут HR из одной компании X, название которой не имеет никакого значения. Пишет, конечно, с предложением пройти собеседование на должность Y.
HR оказался настойчивый, стандартные ответы вроде «спасибо, но сейчас для меня не актуально» не сработали. У меня было время, поэтому еще немного пообщались.
По описанию вакансии все звучало просто великолепно: налаженные процессы, автоматизация, много свободы в выборе архитектурных решений, вся команда профессионалы и тд. В общем, казалось, что стоит только прийти и получать деньги, ведь должность пустует.
Но вспомнил про теорию Жоп:
Чем все закончилось? Ничем особенным. Я немного расспросил о процессах найма, чтобы, возможно, что-то перенять для себя. Но, к сожалению, HR не знает, как на самом деле все работает внутри компании(оно и понятно), а тратить дальше время не хотелось.
А про теорию Жоп рекомендую почитать, периодически возвращаюсь к этому размышлению.
P.S. Я не HR, но пользуясь случаем напишу, что наш CDN растет и мы ищем инженера растить его дальше. Кому интересно - пишете в личку или откликайтесь на сайте.
HR оказался настойчивый, стандартные ответы вроде «спасибо, но сейчас для меня не актуально» не сработали. У меня было время, поэтому еще немного пообщались.
По описанию вакансии все звучало просто великолепно: налаженные процессы, автоматизация, много свободы в выборе архитектурных решений, вся команда профессионалы и тд. В общем, казалось, что стоит только прийти и получать деньги, ведь должность пустует.
Но вспомнил про теорию Жоп:
Если Вам предлагают возглавить новый проект, либо занять какую то должность, да что угодно - знайте, там Вас ждет Жопа. Иначе не предложили бы, а сами бы справились. Равно как и если Вы ожидаете избавиться от надоевшей Вам сейчас деятельности, надеясь вырваться из "этого ада" и заняться "чем то новеньким" - будьте готовы встретиться с Большой Жопой.
Чем все закончилось? Ничем особенным. Я немного расспросил о процессах найма, чтобы, возможно, что-то перенять для себя. Но, к сожалению, HR не знает, как на самом деле все работает внутри компании(оно и понятно), а тратить дальше время не хотелось.
А про теорию Жоп рекомендую почитать, периодически возвращаюсь к этому размышлению.
P.S. Я не HR, но пользуясь случаем напишу, что наш CDN растет и мы ищем инженера растить его дальше. Кому интересно - пишете в личку или откликайтесь на сайте.
Хабр
[Пятничное] Теория Жоп
Эту полу-шуточную теорию о проектном управлении я излагал коллегам по ИТ цеху лет 15 назад, и тогда же неоднократно слышал советы загрузить этот текст на Хабр, но руки не дошли. На днях, разгребая...
👍16❤3🦄3😁1
Отличный доклад о том, что происходит с HTTP-запросом до того, как он доберется до вашего бэкенда.
Автор разбирает весь жизненный цикл HTTP-запроса — от отправки клиентом до обработки сервером, но с акцентом на то, что происходит до выполнения бизнес-логики.
Основные этапы:
1. TCP handshake
2. TLS handshake
3. Отправка запроса на клиенте
4. Обработка запроса на сервере
В конце — несколько практических советов по оптимизации.
Да, темы базовые, но, как верно замечает автор, фундаментальные знания — ключ к реальной производительности.
Автор разбирает весь жизненный цикл HTTP-запроса — от отправки клиентом до обработки сервером, но с акцентом на то, что происходит до выполнения бизнес-логики.
Основные этапы:
1. TCP handshake
2. TLS handshake
3. Отправка запроса на клиенте
4. Обработка запроса на сервере
В конце — несколько практических советов по оптимизации.
Да, темы базовые, но, как верно замечает автор, фундаментальные знания — ключ к реальной производительности.
HAProxy Technologies
Anatomy of a Request: Beyond backend processing
The request journey: TCP handshakes, TLS encryption, user/kernel space interaction, decryption, parsing, decoding, processing, and their associated hardware resource costs.
👍15🔥5
Распределение HTTP-запросов по версиям протокола
(данные по России за последние 6 месяцев, источник: radar.cloudflare.com)
🟢 HTTP/1: 32% (▼4%)
🟢 HTTP/2: 45% (▲4%)
🟢 HTTP/3: 23% (без изменений)
Рост доли HTTP/2 свидетельствует о постепенном отказе от HTTP/1. Однако HTTP/3 пока не показывает динамики, несмотря на его казалось бы «очевидные» преимущества.
Порассуждаем, почему в РФ не растет доля HTTP/3:
1️⃣ Ограниченная поддержка клиентов: не все старые устройства и браузеры поддерживают HTTP/3.
2️⃣ Инфраструктурные сложности: требуется обновление серверного ПО (например, модуль HTTP/3 для Nginx/Apache), необходима настройка TLS 1.3 и проверка корректной работы UDP-трафика. Некоторые провайдеры блокируют UDP на порту 443 (включая домашние сети и даже публичный Wi-Fi, например, в «Сапсане»).
3️⃣ Вопрос целесообразности: затраты на внедрение могут не окупаться, особенно если текущие решения (HTTP/2) работают стабильно
4️⃣ Блокировки РКН
Мое мнение: кто хотел уже внедрили, остальные не сильно торопятся по причинам выше.
P.S. Только начинаю погружаться в HTTP/3, буду рад услышать про ваш опыт.
(данные по России за последние 6 месяцев, источник: radar.cloudflare.com)
Рост доли HTTP/2 свидетельствует о постепенном отказе от HTTP/1. Однако HTTP/3 пока не показывает динамики, несмотря на его казалось бы «очевидные» преимущества.
Порассуждаем, почему в РФ не растет доля HTTP/3:
Мое мнение: кто хотел уже внедрили, остальные не сильно торопятся по причинам выше.
P.S. Только начинаю погружаться в HTTP/3, буду рад услышать про ваш опыт.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍13🔥3
NETWORK_ENGINEER_MOST_ASKED_INTERVIEW_QUESTIONS_WITH_DETAILED_ANSWERS.pdf
6.2 MB
Нашёл в сети крутой файлик - NETWORK ENGINEER MOST ASKED INTERVIEW QUESTIONS.
Пригодится и тем, кто ищет работу, и тем, кто её предлагает. Также работает как сжатый справочник по ключевым темам (TCP/IP, L2, L3, протоколы маршрутизации, DHCP, DNS, безопасность и др).
Рекомендую к сохранению.
Пригодится и тем, кто ищет работу, и тем, кто её предлагает. Также работает как сжатый справочник по ключевым темам (TCP/IP, L2, L3, протоколы маршрутизации, DHCP, DNS, безопасность и др).
Рекомендую к сохранению.
🔥21
В блоге HAProxy рассказывают, как их балансировщик нагрузки впервые обработал более 2 миллионов HTTP-запросов в секунду на одном сервере!
Что использовали для теста:
🟢 AWS инстанс c6gn.16xlarge (64 ядра, 100 Gb/s сеть)
🟢 HAProxy версии 2.4
🟢 Процессор ARM (Graviton2)
Ключевые результаты:
🟢 2,08 млн запросов/сек без шифрования
🟢 2,01 млн запросов/сек с TLSv3-шифрованием
🟢 Добавочная задержка от Haproxy — менее 0,4 мс
Отдельно отмечу про привязку сетевых прерываний (IRQ) к отдельным ядрам, чтобы они не мешали обработке запросов самим HAProxy. Мы к этому тоже пришли в свое время на кэш-серверах CDN, когда пытались разогнать производительность на максимум.
Что использовали для теста:
Ключевые результаты:
Отдельно отмечу про привязку сетевых прерываний (IRQ) к отдельным ядрам, чтобы они не мешали обработке запросов самим HAProxy. Мы к этому тоже пришли в свое время на кэш-серверах CDN, когда пытались разогнать производительность на максимум.
Please open Telegram to view this post
VIEW IN TELEGRAM
HAProxy Technologies
HAProxy Exceeds 2 Million RPS on a Single Arm Instance
First ever software load balancer exceeds 2 million RPS on a single Arm instance! We're near an era where you get the world’s fastest load balancer for free.
👍11🔥4
В марте 2026 года Cisco запускает новый трек экзаменов в области беспроводных технологий - Wireless (CCNP + CCIE).
В рамках нового трека будут проверяться знания по Wi-Fi 6/7, Meraki и др., а из CCNP Enterprise уберут все, что связано с Wi-Fi.
Если кто-то этого ждал, возможно, это хорошие новости, но я таких не знаю🤷
Лично я никогда не любил ни экзамены Cisco, ни Wi-Fi, хотя пару контроллеров и десяток точек доступа настроил (домашний не в счет) - этой участи редко удается избежать сетевику.
P.S. Актуально для кого? 😅
https://www.networkworld.com/article/4046928/cisco-launches-dedicated-wireless-certification-track.html
В рамках нового трека будут проверяться знания по Wi-Fi 6/7, Meraki и др., а из CCNP Enterprise уберут все, что связано с Wi-Fi.
Если кто-то этого ждал, возможно, это хорошие новости, но я таких не знаю
Лично я никогда не любил ни экзамены Cisco, ни Wi-Fi, хотя пару контроллеров и десяток точек доступа настроил (домашний не в счет) - этой участи редко удается избежать сетевику.
P.S. Актуально для кого? 😅
https://www.networkworld.com/article/4046928/cisco-launches-dedicated-wireless-certification-track.html
Please open Telegram to view this post
VIEW IN TELEGRAM
Network World
Cisco launches dedicated wireless certification track
The new track introduces CCNP and CCIE Wireless certifications, with updated exams focused on Wi-Fi 6/7, Meraki, and advanced wireless design.
👍13🔥5😐5
Отчет curator: DDoS, боты и BGP-инциденты во 2 квартале 2025 года
Основные моменты:
🟢 Максимальный битрейт атаки UDP flood - 965 Гбит/с, SYN flood - 229 Гбит/с, IP flood - 214 Гбит/с и TCP flood - 169 Гбит/с.
🟢 Самая продолжительная DDoS-атака длилась 65.5 часов
🟢 Установлен рекорд по размеру DDoS-ботнета - 4.6 млн устройств
🟢 Самая популярная L7-атака - Request Rate Patterns
🟢 Инциденты BGP: 4 hijack, 10 route leaks
🟢 Лидеры среди источников атак: Россия, США, Бразилия
Основные моменты:
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7❤1
На одном из наших проектов используется VMware NSX-T, но с нашей стороны есть доступ только к Cloud Director, т.е. все «кишки» недоступны. Тем не менее, чтобы общаться с поддержкой на одном языке, нам пришлось разобраться в архитектуре: что такое DR, SR, T0/T1 и т.д.
Ниже приведены ссылки, где можно ознакомиться с основами NSX-T. Для общего понимания его работы этого будет достаточно:
🟢 Что такое NSX-T
🟢 NSX-T Component Overview
🟢 NSX-T Series Part 1-16
Ниже приведены ссылки, где можно ознакомиться с основами NSX-T. Для общего понимания его работы этого будет достаточно:
Please open Telegram to view this post
VIEW IN TELEGRAM
👍17🥰2
Пока готовился к внутреннему рассказу о сетевой инфраструктуре, вспомнил про доклад Сереги Овинцовского о том, как мы в 2021 году переехали с классической трехуровневой модели сети на IP Fabric.
Пересмотрел и ностальгия накрыла! 🥲
Пересмотрел и ностальгия накрыла! 🥲
YouTube
Rambler&Okko DevOps Meetup
25 ноября 2021 года состоялся первый совместный митап двух гигантов – Rambler&Okko DevOps Meetup. Топовые технические специалисты медиахолдинга Rambler&Co и мультимедийного сервиса Okko рассказали о собственных файерволах, потравили байки про PostgreSQL,…
👍7🔥5
Kubernetes - 100 Questions and Answers.pdf
247.6 KB
Kubernetes: 100 Questions and Answers
Довольно специфичный документ без какой-либо структуры, который точно не даст полного понимания работы K8s, но может быть полезен в качестве справочника.
Довольно специфичный документ без какой-либо структуры, который точно не даст полного понимания работы K8s, но может быть полезен в качестве справочника.
👍16🔥5
250 Linux Questions and Answers.pdf
502 KB
Linux Scenario Based Interview 250 Questions and Answers.
Ничего не могу с собой поделать - нравятся мне такие файлики. В этот раз этот раз попался по Linux.
Матерые Linux-админы точно могут проходить мимо, а для остальных в целом может быть полезен.
Ничего не могу с собой поделать - нравятся мне такие файлики. В этот раз этот раз попался по Linux.
Матерые Linux-админы точно могут проходить мимо, а для остальных в целом может быть полезен.
👍21🔥6
В Junos существуют различные типы Next-hop:
🟢 broadcast (bcst)—Broadcast.
🟢 deny—Deny.
🟢 discard (dscd) —Discard.
🟢 hold—Next hop is waiting to be resolved into a unicast or multicast type.
🟢 indexed (idxd)—Indexed next hop.
🟢 indirect (indr)—Indirect next hop.
🟢 local (locl)—Local address on an interface.
🟢 routed multicast (mcrt)—Regular multicast next hop.
🟢 multicast (mcst)—Wire multicast next hop (limited to the LAN).
🟢 multicast discard (mdsc)—Multicast discard.
🟢 multicast group (mgrp)—Multicast group member.
🟢 receive (recv)—Receive.
🟢 reject (rjct)—Discard. An ICMP unreachable message was sent.
🟢 resolve (rslv)—Resolving the next hop.
🟢 unicast (ucst)—Unicast.
🟢 unilist (ulst)—List of unicast next hops. A packet sent to this next hop goes to any next hop in the list.
🟢 VxLAN Local—EVPN Type 5 route in kernel.
Также можно встретить тип dead.
Пример вывода команды:
▎Инструкция чтобы увидеть dead своими глазами:
1. Необходим маршрутизатор Juniper MX.
2. Должен быть установлен софт 20.4R2.7. Да, он довольно старый.
3. Необходимо изменить MTU глобально на irb-интерфейсе: set interfaces irb mtu 9000.
Это приведет к флапу BGP-сессий и, как следствие, к неверно запрограммированным маршрутам на PFE с Next-hop "dead". Проблема воспроизводится 100%.
▎Что с этим делать:
1. Обновиться до более свежей версии, например, до 23.4R2-S3.9 - в этой версии проблема точно устранена.
2. Перед глобальным изменением MTU на irb-интерфейсе явно задать IP MTU для BGP-пиров, тогда также будет все в порядке.
В интернете можно найти примеры похожих багов, но точного совпадения найти не удалось.
Также можно встретить тип dead.
Пример вывода команды:
show route forwarding-table vpn internet destination 42.119.54.0/24 extensive
Routing table: internet.inet [Index 17]
Internet:
Destination: 42.119.54.0/24
Route type: user
Route reference: 0 Route interface-index: 0
Multicast RPF nh index: 0
P2mpidx: 0
Flags: sent to PFE, rt nh decoupled
Next-hop type: dead Index: 1102 Reference: 21
▎Инструкция чтобы увидеть dead своими глазами:
1. Необходим маршрутизатор Juniper MX.
2. Должен быть установлен софт 20.4R2.7. Да, он довольно старый.
3. Необходимо изменить MTU глобально на irb-интерфейсе: set interfaces irb mtu 9000.
Это приведет к флапу BGP-сессий и, как следствие, к неверно запрограммированным маршрутам на PFE с Next-hop "dead". Проблема воспроизводится 100%.
▎Что с этим делать:
1. Обновиться до более свежей версии, например, до 23.4R2-S3.9 - в этой версии проблема точно устранена.
2. Перед глобальным изменением MTU на irb-интерфейсе явно задать IP MTU для BGP-пиров, тогда также будет все в порядке.
В интернете можно найти примеры похожих багов, но точного совпадения найти не удалось.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥12👍8
Еще про next-hop’ы.
В EVNP для префикса можно увидеть такую картину по next-hop - ulst и два comp:
Есть посмотреть детальней, то выглядит вообще страшно:
Зачем нужен каждый из них?
▎Unicast next-hop
"Обычный" next hop, который указывает на физический интерфейс, через который доступен префикс. Для каждого префикса создается отдельная запись.
▎Unilist next-hop
"Список" из next hop.'ов Появляется, когда до префикса есть несколько альтернативных путей (ECMP), т.е. просто перечисление next-hop.
▎Indirect next-hop
Indirect next-hop позволяет для всех next-hop, которые доступны через один protocol next-hop(в нашей случае это лупбеки соседних лифов), использовать один indirect next-hop, который будет ссылаться на unicast next-hop.
▎Chained-composite next-hop
Дополнительный уровень над indirect next-hop, который объединяет в себе нижестоящие next-hop. Chained-composite next-hop обязателен для EVPN и начиная с версии Junos 14.1R4 включается автоматически. Он нужен для сокращения количества next-hop. В доках пишут просто: Chained composite next hops are required for EVPN and allow the ingress PE to take multiple actions before forwarding.
Подробней про next-hop можно почитать в нестареющей классике на Хабре.
В EVNP для префикса можно увидеть такую картину по next-hop - ulst и два comp:
# run show route forwarding-table destination 10.14.89.0
-- часть вывода опущена --
Routing table: prod-infrastructure.inet
Internet:
Destination Type RtRef Next hop Type Index NhRef Netif
10.14.89.0/24 user 0 ulst 524311 6
comp 1833 6
comp 1822 6
Есть посмотреть детальней, то выглядит вообще страшно:
# run show pfe route ip prefix 10.14.89.0/24 detail
-- часть вывод опущена --
IPv4 Route Table 6, prod-infrastructure.6, 0x41000:
Destination NH IP Addr Type NH ID Interface
--------------------------------- --------------- -------- ----- ---------
10.14.89/24 Unilist 524311 RT-ifl 0
Nexthop details:
524311(Unilist, IPv4, ifl:0:-, pfe-id:0)
1833(Compst, IPv4, ifl:0:-, pfe-id:0, comp-fn:Tunnel)
524286(Indirect, IPv4, ifl:544:ae1.0, pfe-id:0, i-ifl:0:-)
524383(Unilist, IPv4, ifl:0:-, pfe-id:0)
1957(Unicast, IPv4, ifl:544:ae1.0, pfe-id:0)
1951(Unicast, IPv4, ifl:545:ae2.0, pfe-id:0)
1822(Compst, IPv4, ifl:0:-, pfe-id:0, comp-fn:Tunnel)
524304(Indirect, IPv4, ifl:544:ae1.0, pfe-id:0, i-ifl:0:-)
524383(Unilist, IPv4, ifl:0:-, pfe-id:0)
1957(Unicast, IPv4, ifl:544:ae1.0, pfe-id:0)
1951(Unicast, IPv4, ifl:545:ae2.0, pfe-id:0)
RT flags: 0x00008000, Ignore: 0x00000000, COS index: 0
DCU id: 0, SCU id: 0, RPF ifl list id: 0, SGID:0, Flow Id: 0
Cookie: 0x00000000
Зачем нужен каждый из них?
▎Unicast next-hop
"Обычный" next hop, который указывает на физический интерфейс, через который доступен префикс. Для каждого префикса создается отдельная запись.
▎Unilist next-hop
"Список" из next hop.'ов Появляется, когда до префикса есть несколько альтернативных путей (ECMP), т.е. просто перечисление next-hop.
▎Indirect next-hop
Indirect next-hop позволяет для всех next-hop, которые доступны через один protocol next-hop(в нашей случае это лупбеки соседних лифов), использовать один indirect next-hop, который будет ссылаться на unicast next-hop.
▎Chained-composite next-hop
Дополнительный уровень над indirect next-hop, который объединяет в себе нижестоящие next-hop. Chained-composite next-hop обязателен для EVPN и начиная с версии Junos 14.1R4 включается автоматически. Он нужен для сокращения количества next-hop. В доках пишут просто: Chained composite next hops are required for EVPN and allow the ingress PE to take multiple actions before forwarding.
Подробней про next-hop можно почитать в нестареющей классике на Хабре.
👍10❤4🔥4
Задача: на виртульной машине с Ubuntu 24 изолировать два сетевых интерфейса между собой.
Мы боролись с ассиметрией в виртуальной среде NSX-T, где distributed firewall к ней совсем нетерпим, необходимо было разнести маршруты 0/0 и 10/8 по разным интерфейсам, при это было важно, чтобы они не были в одной таблице маршрутизации.
И когда сетевик слышит, что нужно что-то «изолировать» - он идет натягивать VRF. По официальной документации netplan поддерживает VRF - то, что надо, берем.
Адаптируем под себя:
Интерфейсы разнесены по VRF, всё выглядит корректно:
Проверяем доступ извне до IP-адреса внутри VRF - ping работает! А для сетевика полученный ICMP-ответ - это как документ с печатью, подтверждающий наличие доступа. Проверяем SSH, получаем «connection refused», перезагружаем VM(на всякий), доступа нет, интересно. Отключаем iptables(в любой непонятной ситуации), но и это не помогает. Любые дальнейшие эксперименты показывают, что и другие сервисы, привязанные к IP-адресу eth0 (который внутри VRF) также недоступны 🤷
Я не знал, что все сервисы работают в контексте VRF по умолчанию, т.е. процессы используют таблицу маршрутизации по умолчанию и имеют доступ к прослушиваемым IP-адресам только в этом дефолтном VRF, если не указано иное.
Если для ping внутри VRF мы можем использовать опцию -I, которая указывает src-интерфейс внутри VRF и ping начинает работать, то сервису SSH необходимо явно указать - используй контекст vrf-mgmt! Это будет касаться и других сервисов, которые должны работать с IP-адресами внутри VRF.
Решение для SSH: в systemd для юнита sshd изменить ExecStart с указанием использования VRF. Пока идет отладка изменим сразу /lib/systemd/system/ssh.service. (Напрямую лучше не изменять системные файлы, потому что любое обновление перезатрет изменения, нужно использовать override)
Команда ip vrf exec запускает процесс sshd в контексте vrf-mgmt.
После изменения файла службы нужно перезагрузить конфигурацию systemd и службу SSH, чтобы изменения вступили в силу:
Проверяем SSH извне на IP внутри VRF - доступ есть!
Если цель вынести только управление VM в отдельный VRF, то в принципе, на этом можно остановиться. Но в нашем случае были и другие сервисы, которым нужен доступ к VRF.
Идем дальше.
Есть решение, в котором все сервисы будут работать со всеми VRF в системе - L3 Master Device, известный как l3mdev:
Проверим наличие модуля CONFIG_NET_L3_MASTER_DEV в конфигурационном файле ядра:
Если видим CONFIG_NET_L3_MASTER_DEV=y, значит модуль встроен в ядро.
Включаем для tcp/udp:
Проверяем, убеждаемся что все сервисы начинают работать внутри VRF. Успех😮💨
По документации, l3mdev ухудшает производительность на 2-3%. Попробую разобраться как он работает.
#Задача
Мы боролись с ассиметрией в виртуальной среде NSX-T, где distributed firewall к ней совсем нетерпим, необходимо было разнести маршруты 0/0 и 10/8 по разным интерфейсам, при это было важно, чтобы они не были в одной таблице маршрутизации.
И когда сетевик слышит, что нужно что-то «изолировать» - он идет натягивать VRF. По официальной документации netplan поддерживает VRF - то, что надо, берем.
Адаптируем под себя:
network:
version: 2
renderer: networkd
ethernets:
eth0: # -> vrf-mgmt
addresses:
- 10.10.8.101/23
routes:
- to: 10.0.0.0/8
via: 10.10.8.1
routing-policy:
- from: 10.10.8.101/23
eth1: # -> main
addresses:
- 10.11.8.3/29
gateway4: 10.11.8.1
vrfs:
vrf-mgmt:
table: 101
interfaces: [eth0]
Интерфейсы разнесены по VRF, всё выглядит корректно:
# ip route
default via 10.11.8.1 dev eth1 proto static
10.11.8.0/29 dev eth1 proto kernel scope link src 10.11.8.3
# ip route show vrf vrf-mgmt
10.0.0.0/8 via 10.10.8.1 dev eth0 proto static
10.10.8.0/23 dev eth0 proto kernel scope link src 10.10.8.101
Проверяем доступ извне до IP-адреса внутри VRF - ping работает! А для сетевика полученный ICMP-ответ - это как документ с печатью, подтверждающий наличие доступа. Проверяем SSH, получаем «connection refused», перезагружаем VM(на всякий), доступа нет, интересно. Отключаем iptables(в любой непонятной ситуации), но и это не помогает. Любые дальнейшие эксперименты показывают, что и другие сервисы, привязанные к IP-адресу eth0 (который внутри VRF) также недоступны 🤷
Я не знал, что все сервисы работают в контексте VRF по умолчанию, т.е. процессы используют таблицу маршрутизации по умолчанию и имеют доступ к прослушиваемым IP-адресам только в этом дефолтном VRF, если не указано иное.
Если для ping внутри VRF мы можем использовать опцию -I, которая указывает src-интерфейс внутри VRF и ping начинает работать, то сервису SSH необходимо явно указать - используй контекст vrf-mgmt! Это будет касаться и других сервисов, которые должны работать с IP-адресами внутри VRF.
Решение для SSH: в systemd для юнита sshd изменить ExecStart с указанием использования VRF. Пока идет отладка изменим сразу /lib/systemd/system/ssh.service. (Напрямую лучше не изменять системные файлы, потому что любое обновление перезатрет изменения, нужно использовать override)
Было
ExecStart=/usr/sbin/sshd -D $SSHD_OPTS
Стало
ExecStart=/bin/ip vrf exec vrf-mgmt /usr/sbin/sshd -D $SSHD_OPTS
Команда ip vrf exec запускает процесс sshd в контексте vrf-mgmt.
После изменения файла службы нужно перезагрузить конфигурацию systemd и службу SSH, чтобы изменения вступили в силу:
systemctl daemon-reload
systemctl restart ssh
Проверяем SSH извне на IP внутри VRF - доступ есть!
Если цель вынести только управление VM в отдельный VRF, то в принципе, на этом можно остановиться. Но в нашем случае были и другие сервисы, которым нужен доступ к VRF.
Идем дальше.
Есть решение, в котором все сервисы будут работать со всеми VRF в системе - L3 Master Device, известный как l3mdev:
Official reference
Enables child sockets to inherit the L3 master device index. Enabling this option allows a “global” listen socket to work across L3 master domains (e.g.,VRFs) with connected sockets derived from the listen socket to be bound to the L3 domain in which the packets originated. Only valid when the kernel was compiled with CONFIG_NET_L3_MASTER_DEV
Проверим наличие модуля CONFIG_NET_L3_MASTER_DEV в конфигурационном файле ядра:
grep CONFIG_NET_L3_MASTER_DEV /boot/config-$(uname -r)
Если видим CONFIG_NET_L3_MASTER_DEV=y, значит модуль встроен в ядро.
Включаем для tcp/udp:
sysctl -w net.ipv4.tcp_l3mdev_accept=1
sysctl -w net.ipv4.udp_l3mdev_accept=1
Проверяем, убеждаемся что все сервисы начинают работать внутри VRF. Успех
По документации, l3mdev ухудшает производительность на 2-3%. Попробую разобраться как он работает.
#Задача
Please open Telegram to view this post
VIEW IN TELEGRAM
👍28🔥12❤3🫡2✍1
Forwarded from Патчкорд
Стоит напомнить, спасибо за подсказку нашему подписчику, что когда сетевик слышит про сетевую изоляцию он думает про
VRF, а когда линуксоид про неё слышит, то он думает про NETNS. Имейте ввиду эту опцию то же, там изоляция поизолированней.👍9🔥3