Re: [c-nsp] FHRP selection within Nexus
Hi, On Wed, Nov 13, 2013 at 02:28:05PM -0500, Oliver Garraux wrote: > HSRP is only active/active if you're using VPC on Nexus. If VPC is being > used both VPC peers will route traffic with a destination MAC of the HSRP > virtual MAC (as well as their local MAC's). OK, thanks. This was not so clear to me from the quote provided. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgpHT8QJXsZHC.pgp Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] FHRP selection within Nexus
On 13/11/2013 19:03, Gert Doering wrote: If an ARP request coming from a server arrives on the secondary HSRP device, it is forwarded to the active HSRP device through the peer link. "forwarding to the active HSRP device" and "only the active HSRP interface answers ARP request" doesn't particularily sound "active-active" to me :-) *This* is what happens on any 6500 that does HSRP on a SVI... Dual-active HSRP on Nexus is where both devices will forward traffic destined to the HSRP vMAC. To actually make traffic for one vMAC reach both devices, it needs to come in via a vPC - what normal people call multi-chassis link-agg. IIRC (rather weirdly) the master still does the all the ARP replies... So yes, Nexus will do dual-active HSRP, but only with vPC I think, and as per my original email, vPC comes with a list of caveats that may, or may not, be acceptable in any given environment. [For myself, the Nexus vPC implementation seems a bit fragile and hyper-specific about matching a lot parameters at both ends *just* right. If that's necessary, the box should do it for you, not make you do yet more typing] It might be worth noting that, AIUI, Nexus will also do "local" forwarding of the HSRP vMAC on OTV (which seems to be VPLS with all the config hidden) using a similar mechanisms but OTV has even more caveats, and I know of people for whom it's gone rather wrong... Local forwarding of FHRP is really not magic - just make all routers process IP traffic to the vMAC. I don't see why it fundamentally has to rely on vPC - and maybe it doesn't - since you could jiggle STP costs to make one Nexus forwarding for 1/2 switches and one for the other 1/2. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] FHRP selection within Nexus
At 11:03 AM 11/13/2013 Wednesday, Gert Doering pronounced: Hi, On Thu, Nov 14, 2013 at 05:51:15AM +1100, Andrew Miehs wrote: > > How does that work? > > > > Have a read of > http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9670/C07-572835-00_NX-OS_vPC_DG.pdf > The bottom of page 24... > > HSRP > The use of HSRP in the context of vPC does not require any special > configuration. With vPC, only the active HSRP > interface answers ARP requests, but both HSRP interfaces (active and > standby) can forward traffic. > If an ARP request coming from a server arrives on the secondary HSRP > device, it is forwarded to the active HSRP > device through the peer link. "forwarding to the active HSRP device" and "only the active HSRP interface answers ARP request" doesn't particularily sound "active-active" to me :-) You're confusing "ARP" and "data packets". ARP is handled by the control plane active; data packets are handled by either VPC peer. Tim *This* is what happens on any 6500 that does HSRP on a SVI... GLBP is active-active in that both L3 routers will accept packets to the world, instead of L2-forwarding them to the other one inside the SVI. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ Tim Stevenson, tstev...@cisco.com Routing & Switching CCIE #5561 Distinguished Technical Marketing Engineer, Cisco Nexus 7000 Cisco - http://www.cisco.com IP Phone: 408-526-6759 The contents of this message may be *Cisco Confidential* and are intended for the specified recipients only. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] FHRP selection within Nexus
HSRP is only active/active if you're using VPC on Nexus. If VPC is being used both VPC peers will route traffic with a destination MAC of the HSRP virtual MAC (as well as their local MAC's). There is also a "peer gateway" feature with VPC, that allows both VPC peers to route traffic going to the HSRP vMAC, its on local MAC, or the local MAC of the VPC peer. L3 traffic that one of the Nexus boxes forwards on to the subnet has the router's local MAC for the SVI as the source. Some poorly behaved devices just reply straight to that local MAC rather than doing an ARP to find the MAC of the default gateway. The peer gateway feature is needed to allow these broken devices to work when VPC is being used. If you're not using VPC, HSRP on Nexus works just like it does on anything else. Oliver - Oliver Garraux Check out my blog: blog.garraux.net Follow me on Twitter: twitter.com/olivergarraux On Wed, Nov 13, 2013 at 2:12 PM, Andrew Miehs wrote: > On Thu, Nov 14, 2013 at 6:03 AM, Gert Doering wrote: > > > > > "forwarding to the active HSRP device" and "only the active HSRP > interface > > answers ARP request" doesn't particularily sound "active-active" to me > :-) > > > > *This* is what happens on any 6500 that does HSRP on a SVI... > > > > GLBP is active-active in that both L3 routers will accept packets to the > > world, instead of L2-forwarding them to the other one inside the SVI. > > > > > > > Maybe I am missing something, but I understand the below text to indicate > that both the primary and secondary HSRP peers will accept the packet to > their "local" svi - rather than pushing it across the link... (Continued > on page 25) > > > > The most significant difference between the HSRP implementation of a > non-vPC configuration compared with a vPC > configuration is that the HSRP MAC addresses of a vPC configuration are > programmed with the G (gateway) flag on > both systems, compared with a non-vPC configuration where only the active > HSRP interface can program the MAC > address with the G flag. > > Given this fact, routable traffic can be forwarded by both the vPC primary > device (where HSRP is primary) and the > vPC secondary device (where HSRP is secondary), with no need to send this > traffic to the HSRP primary device. > Without this flag, traffic sent to the MAC address would not be routed. > > > ___ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] FHRP selection within Nexus
On Thu, Nov 14, 2013 at 6:03 AM, Gert Doering wrote: > > "forwarding to the active HSRP device" and "only the active HSRP interface > answers ARP request" doesn't particularily sound "active-active" to me :-) > > *This* is what happens on any 6500 that does HSRP on a SVI... > > GLBP is active-active in that both L3 routers will accept packets to the > world, instead of L2-forwarding them to the other one inside the SVI. > > > Maybe I am missing something, but I understand the below text to indicate that both the primary and secondary HSRP peers will accept the packet to their "local" svi - rather than pushing it across the link... (Continued on page 25) The most significant difference between the HSRP implementation of a non-vPC configuration compared with a vPC configuration is that the HSRP MAC addresses of a vPC configuration are programmed with the G (gateway) flag on both systems, compared with a non-vPC configuration where only the active HSRP interface can program the MAC address with the G flag. Given this fact, routable traffic can be forwarded by both the vPC primary device (where HSRP is primary) and the vPC secondary device (where HSRP is secondary), with no need to send this traffic to the HSRP primary device. Without this flag, traffic sent to the MAC address would not be routed. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] FHRP selection within Nexus
Hi, On Thu, Nov 14, 2013 at 05:51:15AM +1100, Andrew Miehs wrote: > > How does that work? > > > > Have a read of > http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9670/C07-572835-00_NX-OS_vPC_DG.pdf > The bottom of page 24... > > HSRP > The use of HSRP in the context of vPC does not require any special > configuration. With vPC, only the active HSRP > interface answers ARP requests, but both HSRP interfaces (active and > standby) can forward traffic. > If an ARP request coming from a server arrives on the secondary HSRP > device, it is forwarded to the active HSRP > device through the peer link. "forwarding to the active HSRP device" and "only the active HSRP interface answers ARP request" doesn't particularily sound "active-active" to me :-) *This* is what happens on any 6500 that does HSRP on a SVI... GLBP is active-active in that both L3 routers will accept packets to the world, instead of L2-forwarding them to the other one inside the SVI. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgpSiJ97Nek4O.pgp Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] FHRP selection within Nexus
On Thu, Nov 14, 2013 at 5:41 AM, Gert Doering wrote: > Hi, > > On Thu, Nov 14, 2013 at 05:16:15AM +1100, Andrew Miehs wrote: > > HSRP is dual active on the Nexus, so I would just go with that. > > How does that work? > > Have a read of http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9670/C07-572835-00_NX-OS_vPC_DG.pdf The bottom of page 24... HSRP The use of HSRP in the context of vPC does not require any special configuration. With vPC, only the active HSRP interface answers ARP requests, but both HSRP interfaces (active and standby) can forward traffic. If an ARP request coming from a server arrives on the secondary HSRP device, it is forwarded to the active HSRP device through the peer link. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] FHRP selection within Nexus
Hi, On Thu, Nov 14, 2013 at 05:16:15AM +1100, Andrew Miehs wrote: > HSRP is dual active on the Nexus, so I would just go with that. How does that work? gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgptlnat7X_Fk.pgp Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] FHRP selection within Nexus
On Thu, Nov 14, 2013 at 4:22 AM, Phil Mayers wrote: > On 13/11/13 17:07, Blake Pfankuch - Mailing List wrote: > > I am weighing options between HSRP and GLBP knowing that GLBP is >> Cisco only. This environment will be Cisco only for the foreseeable >> > > If you need the performance, use GLBP. Otherwise use HSRP, because it's > marginally simpler and more common (therefore better tested). > HSRP is dual active on the Nexus, so I would just go with that. Should you ever decide to buy another hardware platform, I would then possibly reconsider the decision at that stage. This is really not that hard to change. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] FHRP selection within Nexus
On 13/11/13 17:07, Blake Pfankuch - Mailing List wrote: I am weighing options between HSRP and GLBP knowing that GLBP is Cisco only. This environment will be Cisco only for the foreseeable HSRP is Cisco-proprietary as well. Only VRRP is actually cross-platform. [Personally I feel your vendor loyalty is misguided; you should evaluate all purchases on merit, not "It has Cisco written on it". But that's your call...] on it. Any issues or know bugs that have been hit related to GLBP? On NX-OS 5.2 GLBP is IPv4-only, which is an annoyance. If you need IPv6 (and you should be doing IPv6) you should check into this. They might have fixed it in 6.2 - not sure. With that in mind, would you as peers favor GLBP or HSRP? I am looking at host dependent load balancing specifically to allow better traffic distribution cross sides of the datacenter, with times configured for 1 second hello and 4 second hold timers. We use HSRP by preference. I like knowing which router is the active at any given time - it aids troubleshooting, and we don't need the performance of having both devices active. If you need the performance, use GLBP. Otherwise use HSRP, because it's marginally simpler and more common (therefore better tested). Finally, since you're on NX-OS, you should also check into vPC and dual-active HSRP. Personally I dislike vPC - it has too many moving parts, and a list of caveats a mile long - but it might suit your needs. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] FHRP selection within Nexus
Howdy, I am going through the preliminary design and rough configuration migrating from legacy 6500's to our new Nexus 7000 core and am trying to alleviate existing design flaws through the infrastructure. I did not build the original network, I have only been maintaining it for a short period of time. Currently my L3 core has a large number of vlan interfaces. There is no properly configured FHRP, just an equal split of defined gateways (vlan 1 through 2000 vlan interfaces live on 6500-01 and 2001 through 4000 live on 6500-02) and a failure of an HSRP deployment. I have it narrowed down to 2 deployment options and I am hoping some of my educated peers might have some suggestions. I also have some questions as it has been a while since I did this... I am weighing options between HSRP and GLBP knowing that GLBP is Cisco only. This environment will be Cisco only for the foreseeable future (always if I have my say). The entire network infrastructure (meaning anything speaking a routing protocol or passing traffic) will be Cisco. The devices holding L3 routing will be Nexus 7004 with redundant Sup2's and M2 10GBE line cards and running NX-OS 6.2 (2a). My Cisco team stated that either were accepted solutions, but he did not favor one way or the other as he did not have reviews on GLBP deployments. I am looking for someone who has deployed GLBP on 6.x and impressions on it. Any issues or know bugs that have been hit related to GLBP? One of our big initiatives for next year is redundancy and seamless failover. With this in mind, we are in the process of implementing N+N redundancy splitting our datacenter North/South with a distributed edge load balancing implementation. We are trying to decrease the traffic flow across north and south sides of that datacenter so I am favoring GLBP in my mind with some of the traffic distribution options. With that in mind, would you as peers favor GLBP or HSRP? I am looking at host dependent load balancing specifically to allow better traffic distribution cross sides of the datacenter, with times configured for 1 second hello and 4 second hold timers. Thanks! Blake ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
