having problem running HSRP on two CSR 1000v

[zhiqiang.yan]

Things seem very simple.

Two CSR 1000v installed on different C240 Server, very simple HSRP configure. CSR can PING each other, HSRP status looking good. other devices in the Vlan can PING both CSR Interface, but NOT the HSRP VIP. HSRP active CSR can PING itself and the VIP, but HSRP standby CSR can NOT PING VIP.

any idea what could be the problem?

Thanks,

Ryan

[Steve Fuller · Accepted solution]

Hi Ryan,

Take a read of the post VMware installed CSR1000v Causes DUP Ping Response from Linux Hosts in the LAN forum. The post is fairly long, though may also be relevant for you in the near future, but I think your question is the first one I answer.

Assuming VMware ESX, essentially you need to change the security policy on the VMware virtual switch (VSS or VDS) to Promiscuous - Accept, and Forged Transmit - Accept.

To quote from that post:

The first thing to understand is that neither VMware VSS (Virtual Standard Switch) nor VDS (vSphere Distributed Switch) implement MAC learning like a traditional network switch. This is because vSphere already knows which MAC address is assigned to a VM and therefore the MAC that's associated with a virtual switch port.
 
Next remember that HSRP changes the MAC addresses that are used. The active router sources hello packets from its configured IP address and the HSRP virtual MAC address. The active router sources frames from the virtual MAC such that normal learning switches/bridges know which port or segment the active router is connected to. The standby router sources its hellos with its configured IP address and burned-in MAC address (BIA).
 
If we don't change Forged Transmit to Accept, then the hello packets sent from the HSRP active router sourced with the HSRP virtual MAC will be dropped by the virtual switch. So changing Forged Transmit to Accept essentially allows the two HSRP routers to discover each other. Without this you'll see both routers showing "active" as local and "standby" as unknown.

[snip]

As for promiscuous mode, if you don't change promiscuous mode to "Accept", then the virtual switch will only forward frames with the destination MAC address assigned to the VM. In the case of HSRP the virtual switch also needs to forward frames with a destination of the HSRP virtual MAC address to the HSRP active router.

Regards

[gaudixit]

Hi Zhiqiang, 

The problem is with CSR Platform, please see my comments for the same. 

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]

Just want to mention that "standby use-bia" solves the problem for the CSRs running in GNS3!

[PavelChjen7118]

Yep.. its resolves problem for CRSv's running in VMWare vCenter 6.x

[marianarlt]

This may be old, but I want to confirm for future reference that standby use-bia instantly solved this issue for me using HSRP in Hyper-V 10.0.22621.1, where no other (and way more complicated) solution did.

The standby router with lower priority and no preempt would always change state back to active despite accurate configs.