проблема с запуском HSRP на двух CSR 1000v

[zhiqiang.yan]

Все выглядит очень просто. Два CSR 1000v установлены на разных серверах C240, очень простая настройка HSRP. CSR могут пинговать друг друга, статус HSRP выглядит нормально. Другие устройства в Vlan могут пинговать оба интерфейса CSR, но НЕ VIP HSRP. Активный CSR HSRP может пинговать себя и VIP, но резервный CSR HSRP НЕ может пинговать VIP. Есть ли идеи, в чем может быть проблема? Спасибо, Райан

[Steve Fuller]

Привет, Райан, Прочитайте сообщение
«VMware установил CSR1000v, вызывающий дублирование ответов ping от хостов Linux
в локальной сети» на форуме. Сообщение довольно длинное, но может оказаться вам полезным в ближайшем будущем. Думаю, ваш вопрос — первый, на который я отвечаю. Предполагая, что вы используете VMware ESX, вам необходимо изменить политику безопасности на виртуальном коммутаторе VMware (VSS или VDS) на «Promiscuous — Accept» (Промискуитетный — Принять) и «Forged Transmit — Accept» (Поддельная передача — Принять). Цитата из этого поста: Первое, что нужно понять, это то, что ни VMware VSS (Virtual Standard Switch), ни VDS (vSphere Distributed Switch) не реализуют обучение MAC, как традиционный сетевой коммутатор. Это связано с тем, что vSphere уже знает, какой MAC-адрес назначен виртуальной машине и, следовательно, MAC, связанный с портом виртуального коммутатора.
Далее помните, что HSRP изменяет используемые MAC-адреса. Активный маршрутизатор генерирует пакеты приветствия со своего настроенного IP-адреса и виртуального MAC-адреса HSRP. Активный маршрутизатор генерирует кадры с виртуального MAC-адреса, чтобы обычные коммутаторы/мосты обучения знали, к какому порту или сегменту подключен активный маршрутизатор. Резервный маршрутизатор генерирует пакеты приветствия со своего настроенного IP-адреса и встроенного MAC-адреса (BIA).
Если мы не изменим Forged Transmit на Accept, то пакеты hello, отправленные с активного маршрутизатора HSRP с виртуальным MAC-адресом HSRP, будут отброшены виртуальным коммутатором. Таким образом, изменение Forged Transmit на Accept по сути позволяет двум маршрутизаторам HSRP обнаруживать друг друга. Без этого вы увидите, что оба маршрутизатора отображаются как «активные» в качестве локальных и «резервные» в качестве неизвестных. [snip] Что касается режима promiscuous, то если не изменить его на «Accept», виртуальный коммутатор будет пересылать только кадры с MAC-адресом назначения, назначенным виртуальной машине. В случае HSRP виртуальный коммутатор также должен пересылать кадры с MAC-адресом назначения HSRP активному маршрутизатору HSRP. С уважением

[gaudixit]

Привет, Чжицян, Проблема связана с платформой CSR, пожалуйста, ознакомьтесь с моими комментариями по этому поводу. By default, all of switch/vmnic is running as NOT promiscuous mode. In another word, promiscuous mode is configured to be Reject. For HSRP deployment, all of ICMP request message destination address is set to VIP/VMAC Address.
If vswitch promiscuous mode is not opened, all of packets are dropped. It's expected.
So, solution is simple that 1) Configure vswitch in promiscuous mode. 2) Another alternative to configuring the vswitch in promiscuous mode is to use the "standby use-bia" IOS interface configuration command

[taoli]

赞！

[Dilyan Dimov]

Хочу только упомянуть, что «standby use-bia» решает проблему для CSR, работающих в GNS3!

[PavelChjen7118]

Да... это решает проблему для CRSv, работающих в VMWare vCenter 6.x.

[marianarlt]

Это может быть старая информация, но я хочу подтвердить для будущего использования, что
режим ожидания use-bia
мгновенно решил эту проблему для меня при использовании HSRP в Hyper-V 10.0.22621.1, где никакое другое (и гораздо более сложное) решение не помогло. Резервный маршрутизатор с более низким приоритетом и без прерывания всегда возвращался в активное состояние, несмотря на точные настройки.