azhur

Просто у кого-то Вольты китайские, и мониторилка соответственно настроена! =)

@enginer Как я понял, вам нужен loopback-detection, игнорирующий vlan-ы, но похоже SNR такого не умеет? В качестве обходного решения RSTP+bpduguard не подойдёт?

Как я понял, нужно отфильтровать не просто анонс сети 123.123.123.0/24, а анонс сети от имени определённой AS. То есть не только по префиксу, но и по AS-PATH. Все ли железки такое умеют - хз.

Возможно, различие в поведении между центос и виндой объясняются разными таймерами/таймаутами между отправляемыми пакетами. По вашему скриншоту видно, что пинг реквесты с ттл=2...5 были отправлены до того, как был получен ответ на реквесты с ттл=1. Windows же, судя по моим экспериментам, ждёт ответов от первого хоста в трейсе прежде чем начинать проверять следующий. Если это так, то на центос можно попробовать "поиграться" с параметрами типа -z и, возможно, -w:

Притом, что если Ivan_83 прав в том как это работает: То арп-запросы идут и от сервера к клиенту.

А кто-то знает, как в сетевом стеке фряхи организовано хранение ARP-таблицы? А то мне это почему-то напомнило проблему с неизучением MAC-адресов коммутаторами некоторых моделей из-за коллизий хэша.

Может кто-то поделиться актуальным софтом для EX2200-C-12T-2G? Если верить этой странице, рекомендованная версия - 12.3R12.

То есть свитчи в стеке ребутаются строго по очереди. Чтобы клиент этого не заметил, он должен быть подключен LAG-ом из портов на разных свитчах из стека (например ge-0/0/0 + ge-1/0/0).

Чисто теоретически (так как не знаю возможности сабжевого устройства), что-нибудь типа VRF/инстансов и прочих средств одной железке прикинуться несколькими (и у каждой - свой процесс BGP) не поможет?

Сходу в голову приходят 2 варианта: 1. Попытаться уменьшить глубину истории конфигов и закоммитить это простое изменение. Если сработает - ждать пока автоматика подчистит лишнее и место освободится за счёт удаления старых версий конфигов. 2. Скопировать текущую конфигурацию "на внешнее хранилище" и сделать сброс на заводские, после чего перенастроить с нуля. И чтобы такое не повторилось, опять же уменьшить глубину истории.

Похоже на вот такую железяку напоролись: https://labs.withsecure.com/publications/the-fake-cisco/

Основной вариант по железке на которой это пробовать сделать - C9500-48Y4C. Для него актуально?

А без ВРФ разве удастся сделать другую-отдельную маршрутизацию для этого интерфейса?

Есть нестандартная ситуация: один особенный vlan в сети, который терминируется на отдельном устройстве, не умеющем dhcp relay. DHCP сервер есть, и он находится за этим "неумехой". Нужно как-то всё-таки сделать DHCP для этого vlan-а через этот DHCP сервер (принципиально, что нужно именно через него, и он находится в другой "юрисдикции", через другие части моей сети недоступен). Возникла вот такая идея: этот vlan проходит транзитом через один L3-свитч от Циско, что если на нем сделать отдельный vrf, в котором сделать единственный SVI для этого vlan-а, на котором и настроить DHCP relay, плюс единственный дефолтный маршрут, ведущий через этот же интерфейс к не умеющему релей шлюзу. В такой схеме DHCP-запрос в теории релеится далее через тот же интерфейс, через который был получен первоначальный запрос. Жизнеспособна ли такая схема хотя бы в теории, может у кого-то были попытки реализовать что-то подобное?

ИМХО, 192.168.1.xxx/24 - то же самое.