TGViewer
Channel Public Channel
Будни сетевика

Будни сетевика

@life_of_network_engineer

Блог про сети, CDN, менеджмент, интересные наблюдения, рабочие задачи и немного о том, как живут сетевики. Для связи - @ipatov_ds.
Subscribers
1.17K
Photos
102
Videos
9
Links
143

Showing posts older than #262 · Back to latest

Older Posts 14 shown
Post #261 1.36K
Кто я такой, чтобы отучившись 5 лет по специальности «Сети связи» не написать про профессиональный праздник работников отрасли связи - День радио!

В честь праздника рекомендую прочитать труд от «До нас дошло» про историю телеграфа.

https://habr.com/ru/articles/1031792/
  • 🎉 34
  • 🔥 8
  • 👍 3
Post #260 1.37K
Juniper MX SNMP DDoS protection configuration

В Junos OS Release 22.3R1 уменьшили значение дефолтного полисера для SNMP в 200 раз:
Enhanced bandwidth and burst policer value (MX Series and EX9200 Series)—We've updated the default bandwidth value from 20000 to 100 pps and burst policer value from 20000 to 100 packets for SNMP traffic.


Намерения вроде были благие:
This enhancement avoids the CPU usage of eventd and snmpd reaching more than 100%. Earlier to this release, when the system receives a violated traffic for SNMP along with other protocols traffic, the CPU usage of eventd and snmpd was reaching more than 100% with an error.


Мы такого поведения не замечали, видимо нам везло 🤷

После обновления закономерно можно начать ловить различные ошибки, связанные с SNMP - провалы на графиках по некоторым item и таймауты в логах системы мониторинга.

Проверяем счетчики:
> show ddos-protection protocols snmp

Protocol Group: SNMP

Aggregate policer configuration:
Bandwidth: 100 pps
Burst: 100 packets


System-wide information:
Received: 5964285 Arrival rate: 0 pps
Dropped: 723 Max arrival rate: 100 pps


Видно, что упираемся в полисер 100 pps и есть Dropped: 723.
Max arrival rate, кстати, не будет показывать значение выше установленного полисера, т.е. 100 в нашем случае.

Вернуть все взад можно командами:

set system ddos-protection protocols snmp aggregate bandwidth 2000

set system ddos-protection protocols snmp aggregate burst 2000


Проверка
> show ddos-protection protocols snmp

* = User configured value

Protocol Group: SNMP

Aggregate policer configuration:
Bandwidth: 2000 pps*
Burst: 2000 packets*



Максимальный pps, который видел у нас - Max arrival rate: 1022 pps, поэтому 20K, которые раньше были по дефолту возможно и многовато.

Да и 1022 pss так-то много для одной системы мониторинга, но в нашем случае по факту их было три - Zabbix, Observium (побаловаться) и доп внутренняя система.

P.S. Если Juniper надоел, вы скажите - напишу про … Eltex? 🙂

🎤 Будни сетевика 😊
  • 👍 19
  • 🔥 6
  • 😁 2
Post #259 1.48K
«Универсальный солдат» в команде это хорошо или плохо?

Мне кажется не все так однозначно и да/нет тут не ответить, но почитать рассуждения коллег было интересно.

Читать в такой последовательности:

Почему “универсальный солдат” убивает команду

«Универсальный солдат»: взгляд снизу

Про "универсальных солдат" и команду.


🎤 Будни сетевика 😊
  • 👍 16
  • 🔥 2
  • 🤡 1
Post #258 1.5K
Как сломать Juniper MX204

Инструкция простая:

1. Обновляемся до версии 24.4R2

2. Настраиваем сбор DDoS-статистики через телеметрию (пример для Telegraf)
# [inputs.gnmi.aliases]
# ddos-protection = "/ddos-stats"

# [[inputs.gnmi.subscription]]
# name = "ddos-protection"
# origin = "openconfig"
# path = "/junos/system/linecard/ddos/"
# subscription_mode = "sample"
# sample_interval = "10s"


3. А собственно и все. При опросе сенсора junos/system/linecard/ddos FPC тут же отваливается, выключаются все порты. Не верите? Видео-доказательства прилагаются.

▎Почему это происходит?

Вообще, как бы то ни было этого не должно происходить!
Но попробуем разобраться.

В одном из доков Juniper:
For advanced, real-time monitoring and integration with network monitoring systems, Junos provides streaming telemetry sensors. The sensor for exposing DDoS protection data is:
/junos/system/linecard/ddos


Отлично, но в другой доке есть доп инфа:
/junos/system/linecard/ddos/ This PFE sensor exports the statistics of DDOS from MPC1, MPC2,
MPC3, MPC5, MPC6, MPC7, MPC8, and MPC9 line cards.


Значит ли это, что этот сенсор доступен только на модульных железках, а на mx204, где только buildin-MPC не доступен?
Возможно, но явного подтверждения не нашел.

В документации Junos Telemetry User Guide в явном виде пишут только про:

Starting in Junos OS Release 22.1R1 EX4650, QFX5110,
QFX5120-48Y, QFX5200 and QFX5210 switches are supported.
Starting in Junos OS Evolved Release 22.3R1, PTX10001-36MR,
PTX10003, PTX10004, PTX10008, PTX10016 routers are
supported.


Про MX инфы нет…

Идем в Explore Data Model Attributes by Product, посмотрим что доступно для mx204 и mx304:

• MX304 — директория ddos-stats есть ✅
• MX204 — ddos-stats нет ни в одной версии ❌

При этом,
• На MX204 на 23 версии статистика собирается без проблем
• На MX204 на 24 версии крашится FPC
• На MX304 и на 23 и 24 версиях статистика собирается

Сравнивать напрямую MX204 и MX304 наверно неправильно, потому что это совсем разные платформы, но тем не менее.

▎Вывод

Похоже, на MX204 работа сенсора /junos/system/linecard/ddos/ не предполагалась в принципе. До 24-й версии он как-то работал «по случайности», а в 24-й что-то пошло не так, и теперь опрос выключает FPC.

Похожих багов не нашел.

В защину Juniper можно сказать, что Suggested Release для MX204 - это Junos 23.4R2-Sx, то есть формально на 24-ю лезть в принципе не стоило. Но вопросы всё равно остаются 😊

Будни сетевика
  • 👍 22
  • 🔥 9
  • 🗿 3
  • ❤ 2
Post #257 1.6K
Коллега рассказывает, как они уже несколько лет живут в автодоме и как он устроен. Если будут вопросы, то призовем Рому в комментарии. У ребят есть свой канал.

Интересный был эксперимент - я про то, что мы его решили взять на работу 😂
До данного момента желания уволить не возникло, так что считаем эксперимент удачным.

https://youtu.be/S6xnnwEJR3s?si=08pdWOW7nmx6YV__
YouTube ОДИН ИЗ СПОСОБОВ ПУТЕШЕСТВОВАТЬ 24/7 | VW Crafter Campervan 🏕️ Хроники Автора 👇 📽️ Профиль в Boosty https://boosty.to/dobreebydy 💃 Соц Сети Элизы👇 📽️ Youtube 👉 @elisekrink 🌻 TikTok 👉 https://www.tiktok.com/@elise.krink 🌻 Запрещенограмм Elise.Krink 💌 Telegram канал 👉 https://t.me/elisekrink 😎 Соц сети Ромы…
  • 🔥 11
  • 👍 3
  • 👎 3
  • 👏 1
Post #256 1.82K
Ephemeral Leaks and Automated BGP Route Leak Detection

Автор объясняет феномен BGP Ephemeral Leaks (кратковременные аномалии маршрутизации) и приводит доказательство того, что большинство срабатываний автоматических систем обнаружения утечек (включая Cloudflare Radar) не говорят о реальных атаках или сбоях, а являются естественным побочным эффектом процесса схождения протокола BGP.

В качестве решения предлагается более широкая поддержка ASPA (Autonomous System Provider Authorization) и RFC 9234.

На сегодняшний день, если верить https://bgp.he.net/report/rpki_and_aspa - 1.69% автономных систем имеет ASPA-запись.

Для истории зафиксируем процент по RPKI
IPv4 58.99%
IPv6 61.87%

В ближайшем будущем планируем поучаствовать в увеличении доли IPv4 🙂

🎤 Будни сетевика 😊
  • 👍 8
  • 🔥 2
Post #254 1.85K
⚠️⚠️⚠️⚠️⚠️

Вакансия сетевой инженер в группу сопровождения офисной инфраструктуры.

Офисы: 1 в СПб и 3 в Москве. Гибрид, потому что периодически в этих офисах потребутся бывать. Перед просто поддержкой инфры, будет большой и интересный проект по миграции.

Сетевые железки: Cisco Nexus, Juniper EX, SRX, коммутаторы Dell, Wifi-контроллер + точки.

Архитектура: примерно стандартная для офисов, каналы в Интернет и между офисами, VPN, стыки с ЦОДами Okko и т.д.

На HH вакансия будет опубликована позже, кому актуально пишите в личку - @ipatov_ds

🎤 Будни сетевика 😊
  • 👍 14
  • ❤ 2
  • 🔥 2
Post #252 1.51K
RiscV.pdf284.1 KB
Как работает трансляция виртуальных адресов в физические в RISC-V.

Но если реально пришлось дебажить на этом уровне - вам, наверное, можно только посочуствовать.

🎤 Будни сетевика 😊
  • 👍 7
  • 🔥 2
Post #249 1.34K
Задача: настроить шилдинг в CDN без выделенных железных серверов.

Представим, что у вас есть CDN, но нет необходимости/желания/денег ставить выделенные железные серверы под шилдинг(shielding). Шилдинг - это дополнительный уровень кэширования для защиты origin(источник контента), чтобы запросы от edge к origin шли через промежуточные серверы. Он необходим для снижения нагрузки на origin, так как edge-нод может быть очень много и если каждая будет обращаться к origin напрямую, то он начнет погибать под нагрузкой. С шилдингом на origin всегда будет обращаться только выделенная группа серверов.

Архитектура
Есть 3 раздающие edge-ноды и 2 origin-сервера:

🔍edge-ноды: edge1, edge2, edge3
🔍софт: Nginx
🔍origin: origin1, origin2

Будет использоваться директива split_clients на каждой edge-ноде. Она делит запросы на три равные части (по 33%):

🔍33% - остаются на текущей edge-ноде и уходят напрямую в origin
🔍33% - уходят на первую соседнюю edge-ноду
🔍33% - уходят на вторую соседнюю edge-ноду

При этом split_clients гарантирует идемпотентность(красиво звучит): один и тот же $request_uri всегда попадает в одну и ту же группу. Благодаря этому 99% запросов к кластеру стабильно распределяются по всем трём edge-нодам и далее на origin без «скачков».

Пример конфигурации для архитектуры из 3-х edge-нод.

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

Базовый апстрим для origin на каждой edge-ноду:
upstream origin{
server origin1;
server origin2;
}


Апстримы для шилдирования на соседние edge-ноды:
upstream edge1-shield {
server edge1;
server origin1 backup;
server origin2 backup;
}

upstream edge2-shield {
server edge2;
server origin1 backup;
server origin2 backup;
}

upstream edge3-shield {
server edge3;
server origin1 backup;
server origin2 backup;
}


Итого, каждый апстрим смотрит на соседа по кластеру и бекапом на origin.

Далее настраиваем распределение трафика через split_clients на каждой edge-ноде.

edge1
split_clients $request_uri $upstream_backend {
33% origin;
33% edge2-shield;
33% edge3-shield;
* origin;
}


edge2
split_clients $request_uri $upstream_backend {
33% edge1-shield;
33% origin;
33% edge3-shield;
* origin;
}

edge3
split_clients $request_uri $upstream_backend {
33% edge1-shield;
33% edge2-shield;
33% origin;
* origin;
}


Как это работает.
$request_uri - ключ, на основе которого происходит распределение/хэширование.
$upstream_backend - переменная, в которую будет сохранён выбранный upstream.

То есть для примера 33% origin - это если хэш попадает в первые 33% диапазона, то переменной $upstream_backend присваивается значение origin.
* - значение по умолчанию для оставшихся случаев (1%).

Далее в location эта переменная используется для указания апстрима, например:
location / {
proxy_pass http://$upstream_backend;
}


То есть в зависимости от того, в какой диапазон попал хэш $request_uri$, upstream_backend может принимать значения:
🔍origin
🔍edge1-shield
🔍edge2-shield
🔍edge3-shield

Это актуально, когда 50-100 edge-нод начнут идти за одним и тем же контентом на origin и ему станет тяжело, как минимум можно быстро упереться в емкость сетевых карт.

С использованием split_clients (один uri):
Клиент1 -> edge1 -> edge2 -> origin (edge2 кэширует)
Клиент2 -> edge1 -> edge2 -> из кэша edge2 (без origin!)
Клиент3 -> edge2 -> из кэша edge2 (без origin!)
Клиент4 -> edge2 -> из кэша edge2 (без origin!)
Клиент5 -> edge3 -> edge2 -> из кэша edge2 (без origin!)
Клиент6 -> edge3 -> edge2 -> из кэша edge2 (без origin!)


Работает только на уровне одного кластера edge и если их много (в разных городах), то каждый все равно будет обращаться на origin, но уже не каждая edge-нода!

Мы это использовали для определенного типа трафика, при котором origin-серверов было минимальное количество, была опасность их «положить».

🎤 Будни сетевика 😊 #Задача
  • 👍 13
  • ❤ 3
  • 🔥 2
Post #241 2.77K
BGP Segment Routing.pdf1.4 MB DHCP Server Failover.pdf1.3 MB BGP Link State.pdf1.8 MB Network Telemetry.pdf1.2 MB QOS.pdf4.1 MB BGP.pdf2.5 MB BGP FlowSpec.pdf1.8 MB Peering.pdf1.7 MB
Попался набор файликов на сетевую тематику от некоего Hugo Pena – IP Consulting Engineer.

🔍BGP Segment Routing Using the Prefix SID Attribute
🔍DHCP Server Failover in 7750 SR
🔍BGP Link State
🔍Network Telemetry
🔍Quality of Service
🔍Border Gateway Protocol
🔍BGP FlowSpec
🔍Peering – The Game of Relationships

Часть из них составлена по документации от Nokia, но есть и на общие темы. Может будет полезно.

🎤 Будни сетевика 😊
  • 👍 24
  • 🔥 3
Older posts →
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →