I’m having a bit of a dilemma.
We’re upgrading our datacenter infrastructure with a couple of Nexus 9Ks, which will take on multiple roles - L2/L3
I have a VPC configuration set up. We’ll be acting as ISP for multiple clients, each getting a /30 subnet assigned.
My question is, how can I ensure we have routing redundancy in my case? VRRP or HSRP won’t work as far as I can tell, since I need a /29 at least. Is there any other way to have a common routing table? I know that some L3 switches do have that when stacked.
I’ve seen workarounds using secondary IPs, but can anyone confirm if that actually works?
Indeed using a first hop redundancy protocol is difficult to do employ when you’re using a /30 subnet. There are a couple of redundancy scenarios that come to mind, since you’re using Nexus devices.
The first has to do with the use of virtual port-channel or vPC. This is a feature of Nexus devices that allow you to create a port-channel across two nexus devices. It’s similar to VSS for IOS devices.
This way you can create a layer 3 port-channel with a single IP address that is composed of two physical links, one from each of the Nexus devices. With the appropriate load balancing, you can ensure that the bandwidth of both physical links is being used, while ensuring redundancy in the event that one of the Nexus devices or one of the links fails. More on vPCs can be found here:
The other option is to keep the Nexus devices as separate entities and introduce redundancy via equal-cost load balancing using EIGRP or OSPF. However, this would not be ideal since the redundancy wouldn’t be found at the specific subnet’s gateway, but somewhere upstream… So if you were to do this, you’d need some additional L2 infrastructure between your clients and the nexus devices to keep L2 redundancy as well.
Thanks for your feedback. I get your L3 VPC suggestion though I don’t think it would work in my case, for the simple reason that I have multiple downstream switches and not the client directly connected.
We assign subnets per VLAN. Assigning our IP on the SVI would still result in just one of the two switches doing the work, so not redundant at all. Any ideas at this point?
The vPCs on Nexus devices are not limited to connecting to hosts or servers, but can be connected to downstream switches as well in a redundant as well as load-balancing manner. In the documentation I posted from Cisco, you’ll notice that there are scenarios where there are downstream switches connected to the pair of Nexus devices.
In addition, these L3 vPC links are assigned a single IP address across both Nexus devices. When you configure two nexus devices in this way, they function almost as a single virtual switch so you won’t be “wasting” IP addresses.
I suggest you take a deeper look into these solutions and examine the possibility of making them work for you. As always, we’re here if you need any further help!
Unfortunately I don’t see any mention of L3 functionality on a VPC interface level in that article. All my VPC ports will be connected to downstream switches, to which clients will connect, for their internet connection. Each client gets a /30 in a separate VLAN. How can I configure something like that on a VPC port? I know of 2 ways to configure an IP is to either to make ik a routed port or to use SVIs (interface vlan). I don’t know of any way to configure one logical SVI for both switches…
Am I missing something?
It is possible to configure a Layer 3 vPC port-channel on two nexus devices. You must use the peer-gateway command on the vPC domain configuration. More info can be found here:
In addition, the following document details the various options available to create an L3 portchannel across two nexus devices:
Thanks for the feedback. That scenario is valid if you have an external router, as far as I can tell. In my case, I want to use the Nexus 9K switches as the router.
I had also opened a case with Cisco support and got the following response:
“I have reviewed cisco VPC design guides, and it seems there is a limitation when it comes to create redundancy for such small subnets,
Sadly I was unable to find any documented or approved way by cisco”
We’ll most likely use separate L3 routers, for redundancy.
Thanks anyway!