5 Replies Latest reply: Aug 13, 2019 4:02 AM by Martin RSS

    NXOS HSRP issues - traffic not forwarded


      Hi all,


      While trying to work on a LISP setup that makes use of HSRP, I notice that when using HSRP VIP as default gateway for another device that is simulating a host, traffic is not forwarded by the HSRP router. In comparison, everything works fine when not using HSRP.


      My client is configured with a default route pointing to the NXOS router: "ip route". On the NXOS I have:


      • - working setup, without HSRP:

      interface Vlan101

        no shutdown

        ip address

        ip proxy-arp


      • - non-working setup, without HSRP:

      interface Vlan101

        no shutdown

        ip address

        ip proxy-arp

        hsrp 17

          preempt delay minimum 300

          priority 200



      HSRP state looks ok (I am not using a standby router):


      XTR-1# sho hsrp

      Vlan101 - Group 17 (HSRP-V1) (IPv4)

        Local state is Active, priority 200 (Cfged 200), may preempt

          Forwarding threshold(for vPC), lower: 1 upper: 200

        Preemption Delay (Seconds) Minimum:300

        Hellotime 3 sec, holdtime 10 sec

        Next hello sent in 2.337000 sec(s)

        Virtual IP address is (Cfged)

        Active router is local

        Standby router is unknown

        Authentication text "cisco"

        Virtual mac address is 0000.0c07.ac11 (Default MAC)

        2 state changes, last state change 00:00:26

        IP redundancy name is hsrp-Vlan101-17 (default)



      In the HSRP setup, I also cannot ping the VIP from the host although ARP table is properly populated.


      Any ideas what could be the issue?

        • 1. Re: NXOS HSRP issues - traffic not forwarded

          Even though this reply would be probably useless for you after such a long time, perhaps someone in similar situation could use this (like I did yesterday).


          My situation was almost exactly the same - NXOSv, hsrp, mac/arp issues... Though I did not use ip proxy-arp, I personally don't think the proxy-arp would provide you with the results you are looking for since proxy arp is used in environments where host A believes host B is on the same subnet (due to the subnet mask configured) although they are separated by a router into two different subnets. (Proxy ARP - Cisco )


          Packet capture was a real help in this scenario. Packet capture revealed that after initial startup while trying to ping the hsrp ip, there was an arp request (logically) and the hsrp replied with default virtual mac, much like the one in the question (show.. output).
          After the ping-initiating device got the reply, it used that mac in the icmp packets, packets arrived at the target device yet the device did not respond at all - hence the request timed out.

          Knowing this, I performed a ping from hsrp ip (the other way around) only to find out that the hsrp device is using a different source mac address than the virtual default mac provided from the show command output. It actually used a VLAN interface mac address.


          Taking a step back here to explain what is going on here. The HSRP for that VLAN is a standalone interface in the routing table with it's own mac address. It makes sense that the arp reply contained a HSRP default virtual mac for that group. Problem is, this HSRP is behind the VLAN interface (which has a different mac) so an icmp frame header is rewritten at VLAN interface, changing the source mac address to the VLAN interface (that's how routing works).
          After this change, the icmp reached it's destination and the destination sent a reply to the hsrp IP with a mac address from the initial arp reply it got - the default virtual mac for that hsrp group. This is the problem we have.
          The packet arrives at the VLAN interface and the looks at the L2 information first - identifies the target of this packet and finds out the target mac address is not the VLAN interface mac so it discards the packets (L3 logic)


          After finding out I used a command while in interface (vlan) configuration mode     ----     hsrp use-bia

          The command mirrors vlan interface's mac address so these issues with discarding packets int vlan interface never happen and the ping works like magic.


          Long story short, use HSRP USE-BIA command.


          Hopefully you or anyone else will find this useful

          • 2. Re: NXOS HSRP issues - traffic not forwarded

            Awesome, thanks Martin. This was exactly what I was looking for - been racking my brain for hours on this one!

            • 3. Re: NXOS HSRP issues - traffic not forwarded

              I'm glad I could be of help to you. I went through a lot of struggle with topologies in VIRL. You are not the first one, nor the last one

              • 4. Re: NXOS HSRP issues - traffic not forwarded
                Eric Day

                Are you guys successfully able to get HSRP talking between (2) NXOSv devices using SVI's?


                I am running into the issue of them not seeing each other with a trunk between the 2 NXOSv switches.

                • 5. Re: NXOS HSRP issues - traffic not forwarded

                  Hi Eric,

                  I'm not 100% confident about the reply I'll give you since I wrote my former solution a long time ago.


                  As for your question, yes, I have been able to get them to talk with each other and HSRP between 2 NXOSv systems worked like a charm (although my solution was only a workaround to bug in the NXOSv image - the problem with MAC not being recognized, since the NXOS "to my knowledge" should have some form of forwarding table where you should see the hsrp macs and what-not - i don't remember the command but I know I've dug into troubleshooting this using real nexuses and compare the results with NXOSv and it looked like a bug in the NXOSv.. the table didnt contain all the info it should have).


                  I believe you're experiencing the same problem as we were. Did you try the solution from my former comment? As long as you have your configuration of trunks, etc. correct, you should be good to go with that solution I stated.