cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
1128
Views
0
Helpful
4
Replies
Highlighted
Explorer

Failover(redundancy) options

Hi guys,

About to roll-out a new "mini" pop - 2 x 2960's + 2 x 2851's - The 2851 will be handling ~50+ ethernet tails for clients as dot1q subints (vlan for each tail handed off to us from carrier via trunk port to 2960, then 2960 has trunk up to 2851)...they will be doing a mix of vrf's+inet tails.

Hoping someone has some suggestions on how to best use the 2851's to provide automatic failover?

- hsrp would require a /29 per client tail, and a virtual IP per subint?

- ip sla + EEM - redundant 2851 has same config other than x-connect, redundant simply uses ip sla to check if primary is up/down...if down, use EEM to bring trunk interface up(Will be arp issues due to mac change), and then EEM to bring trunk link down again.....potential for both 2851's to have trunk link up if x-connect link is disconnected though

any other suggestions would be greatly appreciated.

Cheers.

Everyone's tags (6)
4 REPLIES 4
Enthusiast

Failover(redundancy) options

Hi John

From reading the above I understand below is the network setup physically and logically for the traffic requirement:

                                   ----Access-----2960-1----L2-Trunk------dot1q-----2851-1

                                                             !

                                                             !                                     

C1/C2/C3-Vlan1/2/3                      L2_Trunk_HSRP_Hellos                                        ---------------WAN/IP Backbone

                                                             !

                                                             !

                                   ----Access-----2960-2----L2-Trunk------dot1q-----2851-2

As I understand Customers would be connecting in Mutlihomed Way to the 2960s and we would have L2 trunk between 2960s to passHSRP Hellos. Even if the customer is single homed then the L2 Trunk between 2960s will provide us GW Level Redundancy using HSRP. X /29 is the min subnet needed for HSRP and will work, We can have bigger subnet depending upon the setup and customer requirements.

Where is the xconnect actually being configured in this setuo as the dot1q on 2851 are using HSRP L3 config. We wangt to configure IP SLA only on the redundant 2851 to track the reachability of HSRP-Master. I think we can make use of the Preempt and Tracking feature on both 2851-1 and 2851-2 with agressive timers to Switch Over HSRP fastly either in case of Downlink to 2960-Failure or Uplink fromm 2851 failure.

Hope this provides some insight into the traffic requirements for this setup. I am little confused on the xonnect part and their role in this setup and might need to rethink when its clarified.

Regards

Varma

Explorer

Failover(redundancy) options

Thanks for the reply Varma.

We receive vlans from carrier to 2960(so 2960 only does l2), then 2960 trunks these vlans to 2851(for l3 for each client tail)...our carriers only offer single hand-off, so L2 redundancy is manual(i.e. if 2960 dies, we need to swap cable to redundant 2960 and enable that trunk port)

2851 is going to be doing vrf's(mp-bgp/mpls to our other cores), and also inet tails.

Ive attached a diagram that I hope illustrates the setup better - It also shows how we (currently) would need to manually replicate config to "redundant" 2851 + 2960 and swap cables should we lose one of the primary devices.

Im hoping there is a more "automatic" solution available.

Enthusiast

Failover(redundancy) options

Hi John

If above is the setup then from my understanding what we are doing today to manually replicated config and swap cables and move ports is the only option available as the different carriers are just like LAN_Users connected to Access Switch where we do not have device level redundancy or link level redundancy from user side to access switch. The redundancy has a limitation on the user desktop/laptop connecting to the access switch and same is happening here unfortunately.We can think of putting another L2 Switch behind 2960 to provide 2960's device level redundancy but then the new L2 switch becomes SPOF.So what we are trying to achieve won't be possible untill unless the downstream career provides us two handoffs and I believe if the Downstream Career has redundancy in his priority list then two handoffs is a must.

What we can do here is to work and plan for the uplink redundancy from 2960 to 2851 and run HSRP in Uplink to provide 2851 Failure and that I think would be  good thing. I think we can preconfigure and keep a trunk link ready between the two 2960s and also the relevant uplink config. Same way we will need to have the backup 2851 ready with the HSRP configs and kept as HSRP Backup by manipulating the priority.We can make use of the Preempt and Tracking feature on both 2851-1 and 2851-2 with agressive timers to Switch Over HSRP fastly either in case of Downlink to 2960-Failure or Uplink fromm 2851 failure.This will definitely save us a lot of time and the only effort required would be to swap cables between the two 2960s.Unfortunately that can not be avoided till the downstream career provides us two handoffs.

Hoe this helps to provide some insight to the traffic requirements.

Regards

Varma

Rising star

Failover(redundancy) options

Hi John

What 2960's have you got?. If you got 2960S then maybe you can just stack them up and make it look like one virtual switch. No need for trunks etc between the switches. and plug the 2 X 2851 into them.and run HSRP between them.

In your current scenario the only thing we can automate failover is the 2 X 2851's . Can I suggest something here?

Have a trunk between between 2960A and 2851B.  So, if the link between 2851A and 2960A goes down you have redundancy via 2851B. Imagine you have to move onto switch 2 then a similar redundancy applied

In either case you always have L3 up and running.

HTH

Regards

Kishore

CreatePlease to create content
Content for Community-Ad
July's Community Spotlight Awards