Stack redundancy using 2 routers, HSRP and port-channels

[Timothy Patrick]

Hello, I have a wan site that has 2 routers with 2 wan links(separate carriers) and 2 switch stacks(1 stack of 5 and 1 stack of 4).

In the pictured diagram each router is configured with a port-channel connected to the stack below. This connection will bring up the port-channel(Po1) and allow the sub-interface to come up. Port-channel 10 allows the 2 routers to communicate the HSRP keep alives as well as allow traffic to pass to the active router in case of a router/carrier failure. My question is if we loose router1/carrier1 and stack2, stack1 would not have a path out of the network. Also if the switches that have the Po10 configured go down, both routers would become active.

Is there a way, still using port-channels to allow connections between router1/stack2 and router2/stack1

That way each stack has a direct path to each router?

The routers are ISR4431

The Switches are 3650s

[Francesco Molino]

Hi

What model of routers are you using? Do you have free ports available?
You won't be able to split the port-channel across both stacks but you can create another port-channel facing the other stack (the stack where the router isn't connected yet) and assign a new subnet point to point. Are you using dynamic or static route? If dynamic, you need to make sure your primary isp is always preferred from stack 1 and 2. If static, you can use tracking with ip sla and make sure you always route the traffic to isp1 and/or through the other stack to reach still isp1.
If you share your configs i can help you with the configs when I'll have time tomorrow or Friday

[Timothy Patrick]

The routers are ISR4431 - 4 interfaces - 1 for wan, 2 for port-channel to stack, i free port

The Switches are 3650s

[Francesco Molino]

Which means you won't be able to a port-channel of 2 interfaces.
But as you'll connect them in a full mesh mode, you don't need a port Channel facing the switch

[Timothy Patrick]

So the port-channel solution may not work. I have used a similar config but using VLAN interfaces rather than Port-channels. The problem that i would  have is that if router 1 and stack 2 are down, stack 2 would still be unable to communicate out even with the point to point due the all of the ips being on the port-channel sub-interfaces, which in this case would be down.

[Jon Marshall · Accepted solution]

If the switches are L3 capable, which they are, you could just not use port channels, move the L3 interfaces for the vlans to the switches and then just connect using L3 links so each stack has a L3 link to each router. 

Then use static routes or routing protocol between the switches and the routers. 

That said you may be trying to over engineer this as you already have redundancy in your solution. 

The chances of router 1/carrier 1 failing at the same time as the entire switch stack 2 is minimal and as long as the ports for po10 are spread across physical switches in the stack again that is what etherchannel is really for ie. redundancy. 

There comes a point where it is the law of diminishing returns in terms of trying to account for every single failure scenario. 

Jon

[Timothy Patrick]

Jon, thanks for the reply. I agree on the over engineering part. Funny thing is the original design had both carriers going into stack 1 and then using Po10  to feed stack 2. We had some type of event that cause the top and bottoms switches to reload(Top and bottom switch are where the port members for Po10 resided). We are not sure what caused the reloads (switches have redundant power supply Street/UPS) and unfortunately the stack had been prepped for a code upgrade but had not been reloaded. Once the top and bottom switches came back up it would not join the stack due to a version mismatch there by cutting off connectivity to stack 2. So the redesign was the diagram included in the post. By moving the carriers between routers we would have least kept half of the site up.   Just wanted to see how much redundancy could be put in with out changing to much configuration. Had the code upgrade been completed we would have just seen a blip and this would not have been issues as well.