в сети штормило …

Иногда некоторые сервисы, использующие мультикаст, могут порождать массовую генерацию мультикаст-траффика.

мультикастовый шторм 2gbps

Вот эти два пика — случившийся в одном из сегментов сети мультикаст-шторм мощностью примерно в 1,5 — 2 гбит/сек, предположительно порожденный сглючившими процессами corosync. От такой херни весь сегмент сети начинает очень сурово колбасить, потери пакетов достигают 80%, любое сетевое взаимодействие становится крайне медленным и нестабильным, всё становится очень нехорошо.
Чтобы такой херни не происходило, необходимо включать такую вещь, как Storm Control.

На джунипере оно для мультикаста по умолчанию _выключено_.
Конфигурим:

Amin@EX3300> show configuration ethernet-switching-options storm-control
interface xe-0/1/0.0 {
bandwidth 65536;
multicast;
}
interface all {
bandwidth 16384;
multicast;
}

Можно задать максимально допустимое количество принимаемого в порт широковещательного траффика как в процентах от толщины канала (level), так и в абсолютных значениях (bandwidth), в килобитах/сек. Задаваемые значения зависят от используемых приложений, в штатном режиме в логах не должно быть ругани на срабатывание storm control.

Пара подводных камней:
1). Есть ELS и не-ELS версии. Для els версий настройка немного иная (forwarding-options storm-control-profiles):
https://www.juniper.net/documentation/en_US/junos/topics/example/rate-limiting-storm-control-configuring-els.html

2). Для broadcast и unknown-unicast траффика ограничения storm control могут применяться по умолчанию, но им может быть разрешено съедать до 80% полосы.

Такая простая настройка дополнительно убережёт вашу сеть от опасно сглючивших девайсов.

🖧 модульное свинство

Есть такая вещь, как приёмно-передающие модули с разъёмами SFP/SFP+/XFP.

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

Разбор QinQ на Juniper MX и изящный бриджинг 🖧

Всем привет !
Я очень давно хотел поразбираться с двойным тегированием на домашнем роутере Juniper MX-серий, и вот этот момент настал. В отличие от EX, где настройки QinQ относительно немногочисленны, МХ-серия обладает просто огромным количеством настроек свитчинга, а поддержка виртуализованных инстансов и целой пачки технологий позволяет городить очень сложные конфигурации.
Задача этой заметки — разобрать средствами самого МХ-80 дважды тегированный траффик, пришедший в общем аплинке вместе с другими одиночно тегированными вланами и нетегированным траффиком, и после снятия верхнего тега сбриджить эти вланы с уже существующими вланами на МХ. Не забыть про native само собой. Если интересно — просим под кат.

Как забэкапить конфиги с обоих Routing-Engine на Juniper через SSH.

Если вы читали мой блог, то возможно, видели статейку про бэкапы и их копирование по SSH. Там был пример, как с помощью одной строчки вытащить конфиг джунипера себе на комп.

Однако есть железки, у которых управляющих модулей внутри может быть больше одного. Например, в Juniper MX960

может быть несколько (чаще всего два) так называемых routing-engine (RE, вертикальные модули в середине железки), представляющих из себя полностью независимые управляющие компьютеры со своими процами / памятью / дисками. В каждый момент времени работает только один такой комп, второй находится в горячем резерве и готов взять на себя все функции при отказе первого. Особенность в том, что заходя на такой джун по SSH, вы всегда будете попадать на Master-RE, и команда show config будет показывать именно текущий рабочий конфиг с мастера.

И хотя в штатных случаях конфиги и версии прошивок должны быть одинаковы (первое задается через set system commit synchronize в конфиге или ручками при commit synchronize, второе вопрос организационный), могут возникнуть ситуации, когда конфиги не совпадают. В этом случае лучше в бэкап записать конфиги с обоих устройств. Однако просто так по SSH зайти на Backup-RE нельзя — он не управляет никакими интерфейсами, и на нём даже не запущен роутинг. Также мы не можем заранее 100% знать, какой из RE сейчас мастер — это может менять в процессе использования / ребутов / обновлений прошивок и прочего.

Решение есть в самой джунос и оно прекрасно:

#!/bin/sh

# My backup script on backup-storage server; login over read-only class user to junipers

# Бэкапим текущий мастер-RE как обычно:
ssh {IP} "show configuration | display xml" > mx960-Master-RE.xml 2>/dev/null

# Бэкапим текущий резервный-RE более хитрой командой:
ssh {IP} "request routing-engine execute routing-engine other command \"cli show configuration | display xml\"" > mx960-Backup-RE.conf 2>/dev/null

# Бэкапим конфиг именно первого RE, независимо от его роли
ssh {IP} "request routing-engine execute routing-engine re0 command \"cli show configuration | display xml\"" > mx960-RE0.conf 2>/dev/null


То есть мы заходим таки сперва на текущий мастер, и говорим ему выполнить заданную команду (важный момент — под командой тут понимается команда FreeBSD-шелла, а не команда JunOS-консоли cli !), в данном случае — вызвать консоль JunOS, а ей уже передать команду отображения конфига на соседнем ядре. Вывод ловит уже наш SSH. Действо простое, понятное и безопасное. Не забываем заэкранировать кавычки для JunOS-команды.