[c-nsp] Anycast GW for L2 subnet
Adam Vitkovsky
Adam.Vitkovsky at gamma.co.uk
Fri Aug 7 04:25:41 EDT 2015
Hi Tim,
Thank you very much for your explanation, I really appreciate it.
> Tim Stevenson
> Sent: 05 August 2015 02:57
>
> Hi Adam, please see inline below:
>
> At 03:58 PM 8/4/2015 Tuesday, Adam Vitkovsky quipped:
> >Has anyone played with Anycast HSRP with fabric path please?
> >Just would like to confirm I understand it correctly.
> >So ISIS calculates best path to the anycast switch ID advertising the HSRP
> MAC
>
>
> There are no MAC advertisements in FP, routing is based on switch IDs (SID).
Aah yes, sure, must have thinking evpn :)
Right the MAC learning is done in data-plane.
> > and since I can manipulate metrics on links
> > between spine and leaf switches I should be
> > able to dictate which leaf switches should be using which GWs right?
>
>
> You could do that but the idea with anycast HSRP
> is that all participating HSRP routers equally
> distribute the L3 switching load.
>
Yes I agree but in my case the DC would span across two geographic locations and so would the VLANs.
So I was thinking I could enforce VMs in either location to primarily use local GWs as the closest exit from the VLAN.
So kind of L2 routing or anycasting of the GWs.
When I do the same in L3 i.e. anycast the VLAN prefix I should get a nice split and no tromboning of traffic between the locations.
> >Because only paths to anycast switch ID with
> >equal costs are considered for multipathing
> >right? (i.e. there’s no unequal cost load sharing correct?)
>
> Correct, it is ECMP only.
>
> The model is that all anycast HSRP routers have
> their own unique SID but also an emulated SID
> shared among them all. All advertise that ESID,
> and any FP switch with equal path cost to 2 or
> more of those will load balance traffic destined to the HSRP MAC among
> them.
>
> Typical topology is spine/leaf but any topology
> will work. Note that only the control-plane
> Active router is the one that responds to ARP &
> sources HSRP hellos with the HSRP MAC (using the
> ESID as the source SID in FP frames).
>
I see now, that's how everyone associates the HSRP MAC with the ESID and can start loadsharing.
Thank you very much.
> See section 10 here for a bit more:
> http://www.cisco.com/c/en/us/products/collateral/switches/nexus-7000-
> series-switches/white_paper_c11-687554.html
>
>
> Hope that helps,
> Tim
>
>
>
>
>
> Tim Stevenson, tstevens at cisco.com
> Routing & Switching CCIE #5561
> Distinguished Engineer, Technical Marketing
> Data Center Switching
> Cisco - http://www.cisco.com
> +1(408)526-6759
>
>
>
Adam Vitkovsky
IP Engineer
T: 0333 006 5936
E: Adam.Vitkovsky at gamma.co.uk
W: www.gamma.co.uk
This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of this email are confidential to the ordinary user of the email address to which it was addressed. This email is not intended to create any legal relationship. No one else may place any reliance upon it, or copy or forward all or any of it in any form (unless otherwise notified). If you receive this email in error, please accept our apologies, we would be obliged if you would telephone our postmaster on +44 (0) 808 178 9652 or email postmaster at gamma.co.uk
Gamma Telecom Limited, a company incorporated in England and Wales, with limited liability, with registered number 04340834, and whose registered office is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.
_______________________________________________
> cisco-nsp mailing list cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
adam
More information about the cisco-nsp
mailing list