nx.os.and.cisco.nexus.switching.2nd.edition.1587143046

(GLBP). In a spanned Layer 2 environment, it is important to retain the same defaultgateway
IP and MAC address at each site to allow for seamless live migrations of virtual
resources between sites. With HSRP deployed as the FHRP, the vMAC is derived from the
HSRP group number. So, if data center 1 has HSRP group number x between the two routers
and data center 2 has the same HSRP group number of X, both data center, will have the
same vMAC programmed locally. With a server cluster that fails over or when a virtual
machine moves from one data center to another (assuming all of the back-end storage is in
place for this to happen), the mac-address of its default gateway is cached. There will not
be any traffic disruption as the end host will have the same gateway vMAC address.
Note
HSRP and VRRP assign gateway virtual MAC addresses in a deterministic fashion.
GLBP, by default, assigns virtual MAC addresses to the various gateways via the
active virtual gateway (AVG). Because of this difference in behavior, FHRP
localization currently requires that either HSRP or VRRP be deployed.
This functionality causes the OTV AEDs to filter FHRP messages across the overlay
network to enable the co-existence of the default gateway VIP at each OTV site. Without
filtering enabled, FHRP messages would be sent across the overlay leading to the election
of a single active device to serve as the default gateway. This behavior would then force
any traffic destined for the default gateway to the site where the Active node was elected—
leading to suboptimal traffic flow and also a high amount of data traversing the inter-DC
links creating unnecessary use of those links. However, with filtering enabled, FHRP
messages are dropped at the AED, and the gateway VIP can be considered active-active at
each OTV site—thus eliminating hair-pinning of traffic destined for the default gateway
between sites. In addition, with the HSRP filtering only the local routers in each data center
will know about each other; the routers in the other data centers do not know anything about
the others. This can result in active or active HSRP (with vPC in this sample topology)
configuration and cannot have HSRP “listeners” as you filter all the HSRP Multicast hellos.
FHRP filtering functionality should be deployed with an equivalent method to optimize
inbound traffic flows to avoid asymmetric traffic behavior. (This would be unwanted
especially in deployments leveraging stateful services such as firewalls or load balancers
across data centers.) The next section covers several methods for ingress routing
optimization.
Example 11-21 shows how to prevent HSRP messages to perform HSRP localization.
Example 11-21. Define HSRPv1 and HSRPv2 to Block HSRP Hello Messages Between
the OTV Edge Devices
Click here to view code image
ip access-list ALL_IPs
10 permit ip any any