how I realize a redundancy with 2 Switchen?I have 2 catalyst 3550 (EMI) and would like to append other Switche to it.
It isn't always Cisco switche but also 3 Com and others.
I would like to produce with each of the other Switche with a one cable each into one of the Catalysts without a Loop.
Can anybody help me?
Does anybody have an example?
Many thanks in advance.
Redundancy is always a trade-off between availability and cost. The more availability, the more expensive. Define your minimal demands before you start. Then try to find the correct balance between benefit and budget.
Sorry to disappoint you but you cannot have a redundant solution without redundant links. The whole idea behind a redundant network is that the backup link takes over when the active link fails. This is mostly achieved with the application of spanning tree. A cheaper solution could be the application of so-called manual redundancy, this consists of YOU plugging over the cables in case of a failure ;-). Find the balance!
To make your network fully redundant, set it up as follows: connect all your servers to both 3550's, (yes, two netcards each)
then for the client-switches you can either connect each switch to both 3550's also or you can interconnect two switches and link them to a different 3550 each.
It is very important that the 3550's are STP- root and its primary backup. When one of the client-switches becomes root, you will get stp-blocked links on your 3550's. This is undesirable.
Let me see if I understand correctly. You have two 3550s with EMI software. You want some redundancy in your network. You want to connect a Cisco or 3Com or other switch to both of the 3550s. But you do not want to create a Layer 2 loop that will require Spanning Tree Protocol (STP) to block a port, in order to protect you from broadcast storms, excessive traffic etc.
If IP is the only protocol that you are routing or Layer 3 switching, then I think you are looking for Hot Standby Router Protocol (HSRP). EMI software permits you to configure this on the 3550s. You still need a link between the two 3550s, but this can be configured as a separate VLAN and IP subnet, that allows only these two switches to communicate with each other.
Without HSRP, each "interface VLAN xxx" on a 3550 can be a default gateway for the IP subnet on that interface. If you connect a switch to both 3550s, then you have access to two default gateways. Which gateway are you going to use on your computer? You could assign half your computers to use the first 3550, and the other half to use the second 3550. But wouldn't it be easier if you could just give all computers on that VLAN the same IP address to use as their default gateway?
With HSRP, you can. Each "interface VLAN" still needs its own unique IP address. But you can also configure a common IP address that is by both switches shared and monitored. This is the address that you use as the default gateway for your computers. Only one of the "interface VLAN" actually forwards IP traffic that is received at this shared IP address; the other interface VLAN watches and waits, ready to take over if the first switch stops working. Cutover time is about 10 seconds from the moment of failure. The computers on the VLAN do not need to change which IP address they send their IP gateway traffic to; rather, the switches themselves determine which of them will actually forward the IP traffic.
An extension of this concept is called Multi HSRP Groups, or Multigroup HSRP (MHSRP). If it makes sense in your network design, you can configure a second HSRP shared IP address on the same interface VLAN. Then configure the first switch to actively forward traffic for the first HSRP IP address, and the second switch to actively forward traffic for the second HSRP IP address. This way, both switches can forward traffic from that VLAN at the same time; and each will backup the other if the other fails. Then, assign half your computers to use the first HSRP IP address, and the other half to use the second HSRP IP address.
The connections from your Cisco/3Com/other switch to the two 3550s can be plugged into single VLAN access switchports, if theres only one VLAN configured on the Cisco/3Com/other switch. Or, they can be plugged into 802.1Q-tagged VLAN trunk ports, if you have multiple VLANs on the Cisco/3Com/other switch. Similarly, you can configure the link between the two 3550s as a single VLAN access connection, with its own IP subnet; or if you want to create Layer 2 loops and use STP also, then you can make the connection an 802.1Q-tagged VLAN trunk. (CAUTION: If you choose to make it a VLAN trunk, be sure to prune off any VLANs that you do NOT want to have a Layer 2 loop.)
Also beware of creating Layer 2 loops using Cisco and non-Cisco switches. Many manufacturers, for example 3Com, have only one instance of Spanning Tree per switch. Ciscos approach is more detailed, in that it has one instance of Spanning Tree per VLAN. Integrating multiple VLANs and different Spanning Tree approaches can be a very complicated task in a multivendor environment, and may have unpredictable results. Probably best to avoid the issue completely, if you can; I think HSRP lets you do that.
Heres a link to HSRP on Ciscos website:
Cisco Catalyst 3550 Series Switches Configuring HSRP
Hope this helps.
first thanks for the answer.
I think I have the construct with HSRP understood.
However, what does happen if I configure a VLAN on the two Catalysten with 5 ports per VLAN and one of these ports is cancelled?
At this port could be another switch on which could connected several hosts.
The VLAN is then still active, however, and no Takeover takes place.
You bring up a very good point!
You are correct, with multiple ports in one VLAN on one switch, and multiple ports in the same VLAN on the other switch, HSRP takeover will not happen if one port fails on the first switch because the other ports on that switch will keep the VLAN alive there.
A Layer 2 loop for that VLAN, between the two 3550s, would take care of getting the access switch's computers back to their HSRP default gateway; but from earlier discussion, I would recommend doing this only if the access switch is a Cisco, to ensure PVST reliability.
If you don't have the Layer 2 loop on the direct 3550-to-3550 link, but you do have other non-Cisco switches that still have connections to both switches, and those connections can carry the affected VLAN's traffic, then the traffic from the switch that lost one of its two connections should still be able to find its way to its HSRP default gateway address. It will travel via the 2nd 3550, and over the pathway provided by the other non-Cisco switch. But wait -- that would mean that a Layer 2 loop existed previously, and without Spanning Tree active. That would be a disaster!
A way to avoid implementing the Layer 2 loop, but making sure that HSRP will take over as intended, is to make sure that the VLANs on the access switch exist on one and only one VLAN trunk or access port on each 3550. (Think of them more like physical router ports here.)
whenever the access switch's VLANs show up on more than one port in the same 3550 switch, then you are using the 3550 more like a switch than a router. In this case you have to:
1. create a Layer 2 loop across the 3550-to-3550 direct connection with STP enabled; or
2. be sure that another pathway exists, via another switch with the same VLANs configured and STP enabled; or
It is not an easy configuration, but it can be done if you keep those restrictions in mind.
In summary: Configure STP enabled and loop for Cisco dual-connected switches; and either single-connect the other manufacturers' switches, or dual-connect them but make sure their VLANs are unique to one and only one physical port per 3550, in order to take advantage of HSRP.
Hoffentlich wird auch das Obige Ihnen behilflich sein!
I have a few questions to your recommendation.
How shall the ports be configured for no-Cisco switche?
What does happen if a port of the vlan fails?
Does the first switch send some information at the second,
over the trunk?
I think so, but how does non-cisco switch reacting?
The catalyst does know, that the port on the other catalyst
is now activ, but how should the non-Cisco Switch does this know?
Know you whether there is an example on the ciscosites?
Vielen Dank für Deine Hilfe.
Going back through my posts, I realized I had not responded to your latest one here. I apologize for the delay.
If your objective is to avoid STP, which is Layer 2 redundancy, you can implement HSRP for Layer 3 IP redundancy with your two 3550s.
>>"How shall the ports be configured for non-Cisco switches?"
You must make sure that you do not create an Ethernet loop on any VLAN by first making sure that the link between the two 3550s is its own unique VLAN and subnet. That VLAN must be pruned off any VLAN trunks that leave either 3550.
If you have an access switch (Cisco or non-Cisco), and all ports on that switch are going to be in one VLAN, you don't need to configure VLANs on the access switch. Just plug the access switch into a port on one of the 3550s, and assign the port on the 3550 as an access port for a VLAN. Make sure that the VLAN is not assigned to any other access ports on the switch (to facilitate HSRP cutover when VLAN interface goes down), and make sure it is pruned from any VLAN trunk ports on the switch. Create an interface VLAN, assign a unique IP address and subnet to it; also, set up a shared IP address for HSRP on that same subnet. When you're done on the first switch, connect your access switch to the second 3550, following the same guidelines.
Uniqueness of the VLAN existing on one and only one port of the 3550 is crucial. If you have a second access switch configured to use the same VLAN as the first one, you will have redundant Layer 2 paths between your 3550s. You will need to enable STP for that VLAN to avoid the resulting loop. But STP is what we're trying to avoid here! Also, you need to be unique about the VLAN assignment because you are using the 3550's as multiport IP routers here; if you use them as Layer 2 switches, then you run the risk of having HSRP not cutover properly.
If you want to have multiple VLANs on an access switch, you can do so provided all those VLANs are unique to the VLAN trunk port they connect to on each 3550. (These would be the VLAN trunk ports that are having other VLANs pruned off in the preceding paragraphs.) On the non-Cisco switch, create the VLANs, match their 802.1Q tagging numbers with the ones you use on the 3550s, and make sure all VLANs on the access switch are present on the port which connects to each 3550's corresponding VLAN trunk port. On the 3550s, you will configure multiple VLAN interfaces, following the guidelines above.
>>"What does happen if a port of the vlan fails?"
If one physical port of the 3550 fails, it must take down any and all VLANs associated with that port on that switch, so that the interface VLAN(s) will also fail and HSRP can cutover properly. In earlier postings we talked about how multiple ports in the same VLAN on a 3550 would keep a VLAN interface up if one port failed, as long as there was another port on the switch belonging to the same VLAN.
>>"Does the first switch send some information at the second, over the trunk?"
>>"I think so, but how does non-Cisco switch react?"
With regard to HSRP, there are hello packets sent back and forth between the 3550s on each VLAN where HSRP is enabled. Each of the two switches figures out that the other one is there, and they work out who will be active and who will be standby IP address for Layer 3 redundancy. When the one running as standby doesn't hear three hello packets in a row, it assumes the active one has failed and takes over the active role. The HSRP hello packets cross both Cisco and non-Cisco switches transparently.
>>"The Catalyst does know, that the port on the other Catalyst is now active, but how should the non-Cisco switch know?"
The HSRP hello packets cross both Cisco and non-Cisco switches transparently. These access switches need to know nothing about the shared IP address, because they are not operating at Layer 3. The magic of HSRP is that in addition to sharing an IP address, the 3550s also share a MAC address. Both the shared IP address and shared MAC address show up only on the active HSRP switch. So when there is a failure of the active HSRP switch, the standby switch goes active. By going active, the shared MAC address now shows up on another, different, switch port of the access switch, which updates its MAC address tables accordingly. (Just like what happens if you unplug a computer from one switch port, and then plug it into a different switch port on the same switch. The switch adjusts which port it should send the traffic to when it receives frames destined for that MAC address.)
Because the computers have ARP cache entries for the default gateway as the shared IP address, and that IP address is mapped to the shared MAC address, the HSRP cutover requires no changes at the computer. The Layer 2 switches simply update where the MAC address is now showing up; and traffic flows again after cutover is complete. (Elapsed time from when the hello packets stopped being received until the standby goes active: about 10 seconds.)
>>"Know you whether there is an example on the Cisco sites?"
There are numerous references on Cisco's website for HSRP. I believe the key to taking advantage of HSRP while avoiding STP, in your situation, is to think of the Layer 3 switches as multiport IP routers. A Cisco router normally won't let you configure two LAN interfaces to be on the same IP subnet (exception is EtherChannel). When using the Layer 3 switches as IP routers, you have to manually configure things so that this is also the case. It can be a tedious and exacting process; often, the problems that crop up usually are the result of forgetting to prune certain VLANs from the Cisco VLAN trunk ports. But it can be done.
P.S. That all being said, I have had three customers who started down this road; then decided it was too much work to integrate multiple vendors' products. They are all in various stages of phasing out the non-Cisco switches, replacing them with Cisco and/or concentrating the non-Ciscos in one location. I'm not sure what your situation is, but you also may want to move toward a single-vendor (Cisco) solution.