[KotikBSd]

Данную тему создал для двух пунктов:

1) Узнать мнение тех.поддержки.

2) Предостиречь других покупателей :)

 

Собственно проблема в том что в SNR не до конца реализован VRRP, он работает, как нужно, но протокол не реализован до конца :)

VRRP предусматривает возможность в рамках одной группы указывать несколько виртуальных IP адресов. Этому можно найти подтверждение тут - http://ru.wikipedia.org/wiki/VRRP#.D0.A4.D0.BE.D1.80.D0.BC.D0.B0.D1.82_.D0.BF.D0.B0.D0.BA.D0.B5.D1.82.D0.B0_VRRP

где есть поля "количетсво IP адресов" и собственно сам список адресов.

В SNR нельзя указать более одного адреса, что накладывает в моем случае ограничения на его использование... в той же Cisco, vrrp поддерживает больше одного адреса, просто путем указания опции secondary в команде, как и обычно :) А SNR - фиг :(

 

Внимание, вопрос на миллион долларов, в течении какова времени можно ожидать исправление этого бага в прошивке? :) т.к. я не могу в полной мере сделать отказоустойчивость...

 

Пример попыток выбить эту функцию:

SNR#conf t

SNR(config)#router vrrp 1

SNR(config-router)#virtual-ip 10.0.123.1 ?

<cr>

 

SNR(config-router)#virtual-ip 10.0.123.1

SNR(config-router)#virtual-ip 10.0.123.1 10.0.125.1

^

% Invalid input detected at '^' marker.

 

SNR(config-router)#virtual-ip 10.0.125.1 secondary

^

% Invalid input detected at '^' marker.

 

SNR(config-router)#virtual-ip 10.0.123.1

SNR(config-router)#virtual-ip 10.0.125.1

SNR(config-router)#exit

SNR(config)#exit

SNR#show vrrp 1

VrId 1

State is Initialize

Virtual IP is 10.0.125.1 (Not IP owner)

Interface is unset

Priority is unset

Advertisement interval is unset

Preempt mode is TRUE

 

SNR#

 

Изменено 28 марта, 2013 пользователем KotikBSd

[Andrey Savenkov]

Добрый день.

 

Действительно на данный момент функционал VRRP реализован не полностью. Информация о необходимости доработки функционала VRRP передана в работу R&D.

[stalker86]

А было ли оно реализовано или так и осталоcь в планах?

[filin911]

чтобы не плодить тем, спрошу здесь: коммутатор SNR-3750-24S-E необходимо настроить PIM-DM, у кого-то получилось? на какой прошивке?

при вводе команды ip pim dense-mode, вот такой ответ:

 

S3750G(config)#interface Vlan701

S3750G(config-if-vlan701)# ip pim dense-mode

%Protocol cooperation is not supported

 

это он проглатыват на ура:

S3750G(config-if-vlan701)#ip pim sparse-mode

Изменено 7 апреля, 2015 пользователем filin911

[filin911]

отвечу сам себе: прописать удалось PIM-DM после сброса к заводским, завтра проверим работоспособность в боевых условиях.

[xOr]

Тоже столкнулся с этим вопросом.

 

Методом тыка оказалось, что можно два router vrrp с разными ID привязать к одному и тому же int vlan. 

И это работает, даже если приоритеты по разному поставить (для одного адреса мастером будет один, а для другого - другой роутер).

Однако, номеров групп vrrp всего 255, что вносит некоторые ограничения. Ну и неудобно, когда номера не совпадают с вланами.

[xOr]

Добрый день!

 

Уже три года не можем решить проблему с 3750. Обращения в техподдержку так и не помогли. 
Из-за этого уже было много аварий для клиентов и получили ущерб.

А именно, при включении VRRP между двумя 3750, в количестве пары десятков вланов и VRRP-ID,
периодически происходит флаппинг.
В процессе флаппига кратковременно падает связь до клиентов, у которых шлюзы по VRRP (довольно сильно кратковременно - до минуты!)

 

И тут накладывается множество косяков данной платформы

1) переключение VRRP не логируется! Понять, что происходит, можно только косвенными методами по логам mac-flap промежуточных свитчей.

2) На процессор данной платформы (как и промежуточных свитчей 2990) почему-то попадают все пакеты из транзитных вланов - т.е. вланов, где нет даже IP адреса, как то ARP, даже DNS, и какой-то неведомый NORMAL, про который даже техподдержка не смогла четко ответить.  Все это видно по sh cpu-rx protocol all.  Это транзитные пакеты грузят CPU, из-за чего, видимо падают многие протоколы, как то VRRP,  ERPS (!) и прочее, отвечающее за надежность.
ERPS также не логируется на SNR!!! Что происходит на сети понять не возможно.

Из-за такого безобразия проходилось 1) отключать VRRP на одной ноде, оставляя ручной резерв.   2) размыкать кольца ERPS, который также флапал.
В результате ловили аварии.

Сейчас вопросы:
1) Как настроить VRRP, что бы он не флапал.
2) Как настраивать dead-interval в VRRP на 3750 (хотел поставить, например, 10 повторов при периоде 1 (ниже оно не умеет..), что бы, В случае загрузки CPU не сразу был флаппинг)
2) кто компенсирует наши убытки и изначальные вложения в это г....  и в его бета-тестирование (мы тестируем свитчи SNR с 2012 года, в течение чего были потрачены сотни часов на переписку с поддержкой и тесты и испробованы многие прошивки - все это есть в истории TAC)

P.S. Исследовать сетевую среду нечего - прямо за (через) эти SNR стоят Cisco 3560 с HSRP а периодом 300мс, которые прекрасно работают и не флапают.

Конфиги сети проверяли десятки раз, многие люди.
Кстати, один Cisco также куплен в NAG. И у него оказался сгоревшим первый Ge порт. К сожалению, два года прошло с покупки до установки, сразу определить не успели.

Изменено 11 ноября, 2023 пользователем xOr

[Vladimir Efimtsev]

Здравствуйте.

Примеры и порядок настройки VRRP описаны в данных гайдах для данной модели:

https://data.nag.wiki/SNR Switches/Configuration Guide/SNR-S3750G-24S-E/11-Reliability Configuration.pdf

https://data.nag.wiki/SNR Switches/Command Guide/SNR-S3750G-24S-E/11-Commands for Reliability.pdf

 

Если у вас возникла проблема с работой протокола, надо в любом случае, проводить какую-то диагностику и разбираться. Если вы ее проводили (говорите, что обращались когда-то на support), и полагаете, что VRRP флапает (под этим опять же не совсем понятно, что имеется в виду) из-за высокой утилизации CPU (из-за высокой утилизации CPU пакет от VRRP master не успевает дойти до VRRP Backup и поэтому, VRRP backup коммутатор тоже становится master, и также вероятно сообщает об этом всем с помощью GARP пакета).

Если так, то необходимо разбираться в причинах высокой утилизации CPU. Смотреть логи, утилизацию портов, снимать дамп трафика и т.д (т.е. смотреть, что летит в мозг коммутатору).

Можно также попробовать как-то уменьшить утилизацию CPU, отключив обработку ipv6 пакетов ('no ipv6 enable'), а также отключить обработку транзитных ARP-пакетов CPU коммутатора командой ('local-arp enable') (если такая команда там есть, сейчас нет этой модели под рукой, чтобы проверить).

 

Если нет возможности разобраться с утилизацией CPU, или все также наблюдается проблема в работе функционала (при этом настроено все согласно мануала), то, возможно, есть баг в работе ПО.

В таком случае, исправить проблему не удастся, т.к. коммутатор уже более 5 лет является EoS, и его поддержка уже давно прекращена.