MS350 and vrrp

[pharkins]

I have a customer who needs to stretch a vlan between sites and this vlan(only this vlan) needs to have vrrp HA configured on it for Vm servers to be able to failover and use the same gw address. The problem I have is that the meraki can only do the Warm Standby feature that would put one whole switch as master and the other as standby, so all vlans are effected and I only need one to be in HA mode. I have a Cisco 3560 running hsrp for this vlan on both sites so there is a work around but I would like to have this configured on the Mearki as it means I am using the ciscos as a one armed router to make this work.

Will this feature/setup be available on Meraki soon?

[BrechtSchamp]

I doubt you'll get a response to that question here.

If I were you I'd get in contact with my Meraki rep and see if I can get any roadmap information that way. I suppose you've already sent in a make-a-wish as well?

[pharkins]

Thanks for the response. I have reached out to my rep and hope to here something soon. If its relevant I will post it here.

regards.

[PhilipDAth]

I would be extremely surprised if support was added to let you configure the VRRP master per VLAN.  I would assume that support for this will never be added.

[GreenMan]

On its own VRRP is rarely a fix for this kind of requirement;   e.g. VRRP can't advise remote locations which site is 'hosting' the subnet at any time.  Unless you have high levels of bandwidth between your sites, you run the risk of large amounts of inbound traffic hitting one DC, only to need to immediately to head for the other. (LISP was developed, in wider Cisco, to cater for this effect).
Personally I think pushing the need to retain IP config, when moving VMs, is a kind of laziness in the server area somewhere; an IP subnet is there to represent a site. If the site where a device is located changes, then change the subnet. Isn't this what dynamic DNS systems were invented for?

[PhilipDAth]

I disagree with you there @GreenMan.  Failover using DNS is slow.  You have to wait for internal DNS to replicate and client caches to timeout.

Somethings just wont handle a dynamic DNS update for failover - such as the DNS server on an AD controller.  Ever notice when configuring the DNS servers to use on a NIC you can only specify it by IP address?

At least AD/DNS lets you have multiple servers configured to remedy this situation, but some other services (notably legacy services) don't.

Layer 2 extension allows for very fast failover.  Clients don't observe any changes happening.  Often failover can be done at the virtulisation layer.

Personally, I choose layer 2 LAN extension for most of my high availability DC deployments - because it is straight forward, fast to deploy, and you don't have to worry about the zillions of applications the customer might have working or not (because they will work because they can't tell if there is any change).

I have always been tempted to try LISP as well.  It uses the concept of a "location ID", and subnets can be spread over multiple DCs.  The LISP routing protocol associates a host with a location ID instead of a subnet.  So the subnet stops having any location attribute.  LISP also can use layer 3 links (aka a traditional WAN) to join the sites.

https://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Data_Center/DCI/5-0/LISPmobility/DCI_LISP...

LISP is also availble on the smallest of Cisco routers, as well as the high end switches.  So it scales to fit many different customer sizes.

But I haven't been brave enough to use it on a real customer yet.  We have only used it in our lab.  It has been around for quite a long time now.

[GreenMan]

In so many respects, you're absolutely right!   But it is 'failings' elsewhere being pushed at the network guys to fix, as usual...   🙂

[pharkins]

Thanks for the replies all and I've noted your ideas. It seems however I'm stuck with this solution of having to use the cisco routers as I guess LISP is not supported in Meraki and my goal here is to remove the cisco and only use the Meraki L3 switches.

regards

Paul.