I do not believe this should be a problem - however I would like to mention - STP and the path traffic will take to their default gateway, you may want to understand how it will work first before implementing.
All traffic from servers off of the 4507 will go via 4507 to 6509 (whichever is the active GW in HSRP) and then back. Ensure there is redundancy of links/port-channels from the 4507 to the 6500's.
If you are comfortable with this then I do not see any problems adding another HSRP member for added resilience.
Please rate useful posts & remember to mark any solved questions as answered. Thank you.
As Bilal says you can add another member to the HSRP group but it would help if we understood the topology a bit more because it may not be the best solution.
You say if anything goes wrong with the 6500s then the servers still have a default gateway but what would they be able to route to ie. what other devices are in your network eg. routers/firewalls and how are they connected to the switches you mention.
In addition it would help if you could answer -
1) is the 4500 dual connected to both 6500s
2) are the servers only connected to the 4500 or do they have dual connections, one to the 4500 and one to another switch ?
3) are the vlans used for the servers only needed on the 4500 or do you have ports allocated into those vlans on other switches.
It would help if you could provide some more details and clarify exactly what you are trying to do.
If all the important devices are connected to the 4500 and you use dual uplinks to the 6500s then one of those links will need to block (assuming the 6500 interconnect doesn't block).
So it depends on how much traffic goes to and from the servers/firewall/routers etc. but i would have thought you would want both links forwarding.
You could of course use etherchannels to both 6500s from the 4500 to get more throughput.
Ideally because all the main devices live on the 4500 it would be better to use L3 uplinks to the 6500s and then route to and from the 4500 but you can't do that if you also want to dual connect the servers to the 4500 and one of the 6500s.
Your initial post suggested you were trying to protect against the failure of the 6500s but i'm not clear as to why you have connected all the important devices to a single 4500 in that case ie. you have one big single point of failure. Usually the firewall/routers would be dual connected to both 6500s.
I'm not saying it is wrong, just trying to to understand exactly what it is you are trying to protect against.
Are all your other access switches connected to the 6500s ?
Okay, personally i wouldn't do it this way because it sounds like you have not only the important network devices but now also critical users connected to the 4500.
You don't say whether the access switches are only connected to the 4500 or whether they are also connected to one of the 6500s or another switch.
Even if the access switches are dual connected if the 4500 goes down then from the sounds of it you have lost connectivity to the firewall and routers which is far from ideal.
It's not clear why if you have a pair of 6500s you are connecting everything that is important to a single 4500 but it may be that there are very good reasons as to why it is being done this way.
Because you want the servers dual connected to both the 4500 and one of the 6500s then you have no option really but to extend HSRP to the 4500. As i mentioned before one link will block so if you need the throughput to the servers you may well want to consider using etherchannels. If you do bear in mind you probably want to make sure that the interconnect between the 6500 is not blocked and it is one of the etherchannel uplinks from the 4500 that does.
You may also want to make the 4500 HSRP active for the server vlan to save server to server traffic having to go to the 6500 and then back again as Bilal mentioned.
Like i said before, i am not suggesting what you have done is wrong but from what you have described the setup does not seem as redundant as it could be.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...