10 Replies Latest reply: Sep 4, 2011 4:24 PM by sg4rb0sss RSS

    Layer 2 Redundancy




      I was wondering if redundancy at L3 level through routing protocols can also be ensured at Layer 2 ? STP ofcourse I think works for access switches which are connected to the same Distribution layer switch. But if there is a neccessity to ensure redundancy among  access switches connected to different distibution switches, then what are the possible solutions??


      Can any one help with this pl. !!

        • 1. Re: Layer 2 Redundancy
          Magnus Holmberg

          In L3 redundency you can use HSRP.


          If you have 2 L3 switches then each of them will have an IP, but they will also have a virtual IP that the active one respond on. Your clients will have the virtual IP as there default gateway.




          • 2. Re: Layer 2 Redundancy

            Hi, Shanthosh.rk


            Yes it can be done at L2 through Hot Standby Group protocol (HSRP) cisco proprietary, or Virtual Router Redundancy protocol (VRRP) standard.


            Configure your distribution layer switches with VLANs and assign them individual IP addresses. Then organise those 2 vlans into STANDBY GROUP, by doing that HSRP will generate a virtual IP address and a virtual MAC address.


            One of the distribution layer switches will be active and responding to requests, when the other one will be on standby waiting for the active to fail to become active.


            So the client computers will be configure with the generated HSRP Virtual IP address (VIP) as their default gateway, when the active link fails you do not have to do anything. The standby takes over and resume communication.


            VRRP is a bit different, but the concept is the same.




            B. Tambo

            • 3. Re: Layer 2 Redundancy

              Layer 2 and Layer 3 Etherchannels can also be used for Redudancy and load balancing purpose..

              • 4. Re: Layer 2 Redundancy

                I agree with you; Etherchannels is what you want

                • 5. Re: Layer 2 Redundancy

                  How would EtherChannels provide redundancy? They just provide extra bandwidth to the same end point. If there were bottleneck issues, EtherChannel would make sense. But not for redundancy.

                  • 6. Re: Layer 2 Redundancy
                    Chad Spears CCNP CCDA CCNAS

                    Etherchannels provide L2 redundancy.  They are a logical bundling of links, which does provide more bandwidth, but it also provides redundancy.  If 1 of the links in the bundle goes down, you never even notice, the only thing that happens is bandwidth is decreased.




                    • 7. Re: Layer 2 Redundancy

                      I think I put my point across incorrectly. You're right, it does provide redundancy in that sense. What I meant here was, it wouldn't provide be an alternate route to the distribution switches. As in, in case of both links in the EtherChannel failing, it is still STP that would provide an alternate path upwards.

                      • 8. Re: Layer 2 Redundancy

                        Is is possible to configure etherchannel between switches connected to different distribution switches?? in that case won't the switches face problem reaching the default-gateway, since switches under diferent distribution are configured with different gateways.?

                        • 9. Re: Layer 2 Redundancy

                          I think you are asking for MEC (Multi-chassis etherchannel) and to the best of what I know now this won't work unless your distribution switches are a VSS pair.




                          • 10. Re: Layer 2 Redundancy



                            Like many people have said, there are a variety of protocols such as HSRP, VRRP, GLBP that are designed to assist you with redundancy.   I just wanted to pop in an alternative design  for consideration.  If you had the layout below:


                            You may want to consider settings 4 default routes on R1 and using tracking on each one.  Each one pointing to the next hop of the opposite side's interface IP, and equally weighted.  That way, if  s1/3 went down, the tracking would remove this default route (one of the 4 you have configured) for this link in the routing table, and allow you to load balance between R2 and R3 with the remaining three links!  The tracking would also allow the link to return to the routing table when the issue is fixed, and again go back to being equally weighted across the 4 routes with no further configuration.


                            Hope this helps,