2nd Switch in a C9300 Stack as a hot spare

[DorianBannock]

I am replacing a single 9200CX switch with a 2 switch stack of 9300s.  The existing switch is aggregating a handful of point to point links to remote WAN sites that need access to a shared server.  These links are either dark fiber, layer 2 leased lines, Microwave, or LTE modem based, and are as such limited to single interface connections.  My goal is to have the second switch in the stack function as a hot spare, so that if there is a failure of the primary device, I would just have to move the physical connections from the top switch to the second switch.  These interfaces have layer3 addresses assigned and routes are propagated via EIGRP.  I considered grouping an interface in each switch with a channel-group, and moving the layer three address to that, but that seems like a wacky way of doing things, since I would never be able to establish a LAG over the single links to the far side.  Its further complicated by the fact that this switch also has to form a LAN side HSRP standby group with another switch at a geo-diverse location.  Do I just have to pound in the same config in both switches, remove the stacking cables, and run them as 2 identical stand alone switches?  I don't love that, since it doubles the management overhead, and increases the chance that the hot spare's config is out of synch with the primary.  Is there some magical mirroring option in the Stackwise protocol, and if so, how is failover managed?  

Here are the interface configs:

interface GigabitEthernet1/0/1
description to CPD-RTR-2
switchport mode trunk
!
interface GigabitEthernet1/0/2
!
interface GigabitEthernet1/0/3
description to PCSO via Firstnet
no switchport
ip address 10.0.0.137 255.255.255.248
bfd interval 300 min_rx 300 multiplier 3
!
interface GigabitEthernet1/0/4
!
interface GigabitEthernet1/0/5
description to CPD-RTR-2 syringa
no switchport
ip address 10.0.0.45 255.255.255.252
bfd interval 300 min_rx 300 multiplier 3
!
interface GigabitEthernet1/0/6
!
interface GigabitEthernet1/0/7
description to CCSO via Firstnet
no switchport
ip address 10.0.0.129 255.255.255.248
bfd interval 600 min_rx 600 multiplier 3
!
interface GigabitEthernet1/0/8
!
interface GigabitEthernet1/0/9
description to BICSO via Firstnet
no switchport
ip address 10.0.0.145 255.255.255.248
bfd interval 600 min_rx 600 multiplier 3
!
interface GigabitEthernet1/0/10
!
interface GigabitEthernet1/0/11
!
interface GigabitEthernet1/0/12
no switchport
ip address 10.0.0.125 255.255.255.252
!
interface GigabitEthernet1/1/1
description Vesta LAN
no switchport
ip address 10.119.97.252 255.255.255.0
standby version 2
standby 1 ip 10.119.97.254
standby 1 preempt
bfd interval 300 min_rx 300 multiplier 3
!
interface GigabitEthernet1/1/2
!
interface TenGigabitEthernet1/1/3
!
interface TenGigabitEthernet1/1/4
!
interface Vlan1
no ip address
!
interface Vlan910
ip address 10.0.0.6 255.255.255.252
bfd interval 600 min_rx 600 multiplier 3
!
!
router eigrp 100
bfd all-interfaces
network 0.0.0.0
network 10.0.0.4 0.0.0.3
network 10.0.0.44 0.0.0.3
network 10.0.0.128 0.0.0.7
network 10.0.0.136 0.0.0.7
network 10.0.0.144 0.0.0.7
network 10.119.97.0 0.0.0.255
network 10.120.231.0 0.0.0.255
network 172.30.29.0 0.0.0.255
redistribute static metric 100000 1000 255 1 1500
eigrp stub connected summary
!

[balaji.bandi]

My only suggestion is stacking. So all the configuration moved to secondary automatically (as you mentioned, you move the physical cables when there is an issue)

Make sure you maintain identical configuration - example 1/0/1  and 2/0/1 

You can also have EEM script bring up the interface - if primary failed.

[Joseph W. Doherty]

What I've done on stacks, in a situation like yours, I changed the ports to switch ports, with L3 using a SVI.  This allowed me to have, say, port 5 in the same VLAN on two switch members.  Either port 5 could support the connection.

However, I was running OSPF, not EIGRP, and wasn't using BFD.

BTW, would suggest having, for dual setup, half the connections each device.  That way, if a stack member fails, you don't lose all the connections and only need to repatch half.

As an alternate, you can have identical switch port configurations, on the two switches, but inactive needs to be shut.  If active switch fails, besides repatching, you need to no shut the interface.  Do keep in mind restoration of failed member has to be done very carefully.

Oh, also BTW, in my use case, the switch stack was remote and with only a single WAN connection, and no other remote access or on-site support.  However, we could talk a user through a repatch.

[Giuseppe Larosa]

Hello @DorianBannock ,

if all intefaces are L3 interfaces with single physical link the stack is likely not the best solution.

if the switches are in  a single stack , you cannot have two ports L3 with same IP address and subnet unless they are in different VRFs you can easily check this the second inteface that is configured the device will complain of overlapping IP address.

So in this specific scenario you can either use two VRFs and have a cable connecting them . You will have also two EIGRP processes one for each VRF or you can have two devices indipendent with same configuration eventually connected with a L3 link between them with EIGRP running over it.

Without the stack the configuration will be simpler as it will not need to use VRFs , not connected ports on one device will lead to missing connected routes and these routes can be learned from the other device via EIGRP.

A good strategy could be that of having half connections active on first switch and half on the second one.

Hope to help

Giuseppe

[DorianBannock]

---

@Giuseppe Larosa wrote:

if all intefaces are L3 interfaces with single physical link the stack is likely not the best solution.

if the switches are in  a single stack , you cannot have two ports L3 with same IP address and subnet unless they are in different VRFs you can easily check this the second inteface that is configured the device will complain of overlapping IP address.

This was definitely the sticking point, Layer 3 interface conflicts are a non starter.  And since this is a replacement that needs to slot into an existing production environment, I think that the prospect of re-engineering the whole topology to support 2 VRFs and EIGRP processes is a bit too daunting, but would likely be the solution if I could start from the ground up.  In a fast and dirty lab, I was successful in passing traffic over a link when I put the L3 interface in a LACP etherchannel interface, and it would swap from one switch to the second.  But I have no idea if the BFD would function correctly with it attached to a SVI instead of the directly attached interface.  

!
interface Port-channel36
description to PCSO via Firstnet
no switchport
ip address 10.0.0.137 255.255.255.248
bfd interval 300 min_rx 300 multiplier 3
!
interface GigabitEthernet1/0/3
no switchport
no ip address
channel-group 36 mode active

interface GigabitEthernet2/0/3
no switchport
no ip address
channel-group 36 mode active
!

[Joseph W. Doherty · Accepted solution]

If you have a lab, try the SVI solution too (which doesn't require a stack) and is much like your port-channel approach.  I.e. change channel-group 36 to a dedicated VLAN (possibly 36) for just those two ports and the PC interface to a SVI.  Of course, the physical edge ports will need to be switch ports in the specific dedicated VLAN.  (Also, of course, each link will need its own dedicated VLAN.)

I know OSPF worked just fine having one or both ends using a SVI.  Did configure SVI as OSPF p2p.  I would hope EIGRP wouldn't have an issue.  Less certain about BFD, but, in the past, BFD support was very platform dependent.  (Also, in the past, BFD wasn't always a critical need, for various reasons.)