24 – Enabling FHRP filter

 Isolating Active HSRP on both sites.

You have been several to ask about details on the HSRP filtering configuration as discussed in the LISP IP Mobility article (23 – LISP Mobility in a virtualized environment), so here below is a short description of the configuration. And thanks to Patrice and Max for they help validating this configuration.

FHRP isolation is required only with LAN extension. It comes with two flavours:

  1. It works in conjunction with any Ingress path optimisation techniques such as LISP IP Mobility or LISP IGP Assist or intelligent DNS (GSLB) or SLB Route Health Injection tools or even a manual setting (e.g. changing the metric for a specific route). Whatever solution is used to redirect the traffic from the end-user to the location supporting the active application, in order to be really efficient and to eliminate the “tromboning” workflows, the egress traffic must be controlled to use the same WAN edge gateway as the Ingress traffic  as described in this note 15 – Server to Client traffic.
  2. Although it depends on the distance between remote DC’s, usually it is recommended to move the whole software framework when migrating an application from one site to another, still to reduce as much as possible the “tromboning” workflow impacting the performances. In short do migrate the Web-tier with its Application and Data-base tiers, all together. As the server to server (tier to tier) traffic imposes that the same default gateway is used wherever it is located, the way to  prevent the traffic to return to hit the original Default gateway is to duplicate the same gateway on each site. This is also described here 14 – Server to Server Traffic. However due to the VLAN extended between site for the it is mandatory to filter the handshake protocol (HSRP Multicast and vMAC) between gateways belonging to the same HSRP group.

HSRP Setup

In our previous example with LISP IP mobility we used CSR 1000v as default gateway inside each tenant container.

Both CSR 1000v distributed on each site offer the same Default Gateway to the server resources; hence to be both active on each site it is mandatory to filter out HSRP Multicasts and vMAC between the two locations.

This filtering setup is initiated on the OTV VDC

  1. Create and apply the policies to filter out HSRP messages (both v1 and v2). This config concerns VLAN 1300 and VLAN 1300 for the following test with LISP, however additional VLAN (or range) can be added there for other purposes.    
  2. Configure ARP filtering to ensure ARP replies (or Gratuitous ARP) are not received from the remote site
  3. Apply a route-map on the OTV control plane to avoid communicating vMAC info to remote OTV edge devices. Indeed OTV uses a control plane to populate with its Layer 2 local MAC table, each remote OTV edge devices. This MAC table being built from its regular MAC learning, it is important that  OTV doesn’t inform any remote OTV Edge device about the existence of this HSRP vMAC addresses as it exists on each site.HSRP and Nexus 1000v

By default the Nexus1000v implements a loop detection mechanism based on the source and destination MAC addresses. Any duplicate MAC addresses between the vEthernet interface and uplink ports will be dropped.

Thus in case of redundant Layer protocol such as HSRP enabled on the upstream virtual routers (e.g. CSR 1000V), it is critical to disable the loop detection on the vethernet interfaces supporting the redundant protocol.

For more details please visit :

http://www.cisco.com/en/US/docs/switches/datacenter/nexus1000/sw/4_2_1_s_v_2_1_1/Layer_2_Switching/configuration/guide/b_Cisco_Nexus_1000V_Layer_2_Configuration_Guide_5_2_chapter_01000.html

HSRP filtering – Quick check

App1 (10.17.0.14) is currently located in DC-1 sitting on top of VLAN 1300 where CSR-106 is its local default gateway

App1 pings continually a loopback address located somewhere to the outside of the world. The show command of the outbound interface on the local CSR-106 shows the rate of 1 packet per second as expected while the CSR-103 on remote site doesn’t treat any packet.

Live Migration happens through OTV, moving App1 to DC-2 using vCenter.

Counters show the new local CSR-103 on DC-2 taking over the default gateway for the App1 on VLAN 1300

 

 


 

This entry was posted in DCI, DR&DA. Bookmark the permalink.

6 Responses to 24 – Enabling FHRP filter

  1. plgingembre says:

    Hi Yves,

    Nice post, as ususal!

    Just would like to bring a precision about loop detection mechanism for FHRP on Nexus 1000V, it seems that Nexus 1000V does not support CSR 1000V running HSRPv2 (I’ve just tried it on my lab). You have to go back to HSRPv1 to get it working. Sounds strange, maybe a Nexus 1000V upgrade would solve this issue.

    • Yves says:

      Good catch Pierre-Louis,

      Let me investigate, I’m not sure about a new release implementing the loop detection for hsrp_v2 and I don’t have access to my lab as of now to double-check 🙁
      In the meantime can you try to workaround this limitation by disabling the loop config for the hsrpv2 mcast group, explicitly:

      # disable-loop-detection custom-rp dest-ip 224.0.0.102

      And please let me know,

      thank you, yves

  2. Alberto says:

    Hi Yves

    Is it neccesary to configure HSRP isolation, even if one of the data center has HSRP redundant and the other data center with a single nexus 700o ?

    • Yves says:

      Hi,

      I will probably not enable FHRP localisation with a single device in one site.
      In case of failure of that device, you will loose the default gateway for all local endpoints.
      It is certainly better to keep usage of traditional redundancy deployment: Active/Standby in one site, and keep the third remote N7k in a listen state.

      Does that make sense or did I missed your question?

      Kind regards,

      yves

  3. gridguo says:

    Hi,
    There are two datacenters, connected with a pair of 10 gig dark fiber connections. There are a handful of VLANs riding across the DCI links in a stretched L2 configuration for the purposes of vMotion and a handful of proprietary “stretched-cluster” apps.We have configured A-VPLS over GRE on the both side Core Switch,there are the following questions:
    1. We can not manage another data center ESXI host from the deployment of vCenter’s datacenter.Nexus 1000V Deployment with stretched model on one DC.
    2.We need to configure the FHRP filter on the both core switches?

    Thank you very much!
    James

Leave a Reply