Access layer redundancy

EildorEildor Member Posts: 444
Hi all,

Wondering what technologies are available for access layer redundancy. By access layer redundancy I mean devices that connect to multiple access layer switches for redundancy purposes. For example, a server connecting to two access layer switches, so that if one access layer switch were to fail the other would still be available (and load share if both are up?).

Wouldn't simply running a FHRP such as VRRP at both the access layer switches achieve this sort of redundancy?

Comments

  • nehalemnehalem Member Posts: 11 ■□□□□□□□□□
    Eildor wrote: »
    Wouldn't simply running a FHRP such as VRRP at both the access layer switches achieve this sort of redundancy?

    Yes, there are some operating systems which would allow you to configure network redundancy in this way.
  • MickQMickQ Member Posts: 628 ■■■■□□□□□□
    Assuming layer two access switches, you could hard code HS/VRRP for what you propose and load balance different VLANs. Usefulness of this in network loactions will vary.
    Alternatively, you could use GLBP which will actively load balance. Drawback - Cisco proprietary.

    Of course, we can pick door number 3. This is using layer 3 switches in the access layer. Bye bye (most) STP considerations and L2 redundancy problems. Routing takes over and things can run smoother, as long as your designs are right.
  • EildorEildor Member Posts: 444
    MickQ wrote: »
    Assuming layer two access switches, you could hard code HS/VRRP for what you propose and load balance different VLANs. Usefulness of this in network loactions will vary.
    Alternatively, you could use GLBP which will actively load balance. Drawback - Cisco proprietary.

    Of course, we can pick door number 3. This is using layer 3 switches in the access layer. Bye bye (most) STP considerations and L2 redundancy problems. Routing takes over and things can run smoother, as long as your designs are right.

    Even with layer 3 access switches you would still need to use a FHRP, no?
  • MickQMickQ Member Posts: 628 ■■■■□□□□□□
    Think about it. What does FHRP work off?
  • EildorEildor Member Posts: 444
    MickQ wrote: »
    Think about it. What does FHRP work off?

    But you'd still be using layer 2 from the access layer to end devices, no?
  • MickQMickQ Member Posts: 628 ■■■■□□□□□□
    Not if it's layer 3 all the way to the edge (end devices).
    That way your network links are starting at layer 3 and layer 2 is between only the end device and the switch port (which also have layer 3 connectivity!) and doesn't spread across to other switches.

    Yeah, a bit of a paradigm shift.
  • EildorEildor Member Posts: 444
    MickQ wrote: »
    Not if it's layer 3 all the way to the edge (end devices).
    That way your network links are starting at layer 3 and layer 2 is between only the end device and the switch port (which also have layer 3 connectivity!) and doesn't spread across to other switches.

    Yeah, a bit of a paradigm shift.

    I guess if you wanted to do it that way, and not use a FHRP, then you'd need some sort of config on the servers -- right? The servers would need to share load between the access switches, and detect a failure if there is one and act accordingly?
  • MickQMickQ Member Posts: 628 ■■■■□□□□□□
    What's the difference in the server doing it at L3 compared to L2?
    Besides, it's not the server that should be doing the job of the network. If there is a failure, the routing protocols kick in and deal with the failure (typically) faster than L2 technologies.

    Having said that, be aware that different server technologies might push you towards different network deployment methods.
  • EildorEildor Member Posts: 444
    MickQ wrote: »
    What's the difference in the server doing it at L3 compared to L2?
    Besides, it's not the server that should be doing the job of the network. If there is a failure, the routing protocols kick in and deal with the failure (typically) faster than L2 technologies.

    Having said that, be aware that different server technologies might push you towards different network deployment methods.

    I'm confused. I think I need to go look into how you configure addressing and gateways on a dual port NIC, because I don't understand how it works. Think that's why I'm confused.
  • MickQMickQ Member Posts: 628 ■■■■□□□□□□
    Most likely. You'll have a nice eurika moment when you see how it's used.
    Maybe you should take a look at the design cert material to give a clearer idea of what's going on.
  • EildorEildor Member Posts: 444
    MickQ wrote: »
    Most likely. You'll have a nice eurika moment when you see how it's used.
    Maybe you should take a look at the design cert material to give a clearer idea of what's going on.

    For sure, I need to start reading up on design and security at some stage... too much Uni work atm. I have been looking at some books on design, but I think they might be a bit dated.

    If you have L3 at the access layer, aren't you still going to configure SVI's on the L3 access switch? Which the server would be configured to use as the gateway?
  • MickQMickQ Member Posts: 628 ■■■■□□□□□□
    Excellent question.
    I'd still configure a management interface on the device for telnet/ssh access.
    Your gateway would depend on your network layout, but might be on the same switch or a number of hops away.

    Best of luck with your studies. Don't be afraid to delve more into network stuff that interests you.
  • EildorEildor Member Posts: 444
    MickQ wrote: »
    Excellent question.
    I'd still configure a management interface on the device for telnet/ssh access.
    Your gateway would depend on your network layout, but might be on the same switch or a number of hops away.

    Best of luck with your studies. Don't be afraid to delve more into network stuff that interests you.

    If you have L3 in the access layer, then I guess you would configure the access layer switch to act as the gateway (?). This is where I am confused. If that switch fails, then it can no longer act as the gateway; so the server would lose connectivity. I can't think of how you would get around this unless you have implemented a FHRP, so that when the server ARPs for its gateway, it will get the MAC address of the remaining switch that it is connected to.

    Thank you. There's a lot of things that interest me, but there's just too much to learn. It makes it difficult to get comfortable in any one area.
  • ZartanasaurusZartanasaurus Member Posts: 2,008 ■■■■■■■■□□
    If all you care about is redundancy of the access layer switches, just team the NICs on your server since they are connecting to different switches. If the servers are directly connected to the device that is their default gateway, then you'd need FHRP.
    Currently reading:
    IPSec VPN Design 44%
    Mastering VMWare vSphere 5​ 42.8%
  • phoeneousphoeneous Go ping yourself... Member Posts: 2,333 ■■■■■■■□□□
    Eildor wrote: »
    I'm confused. I think I need to go look into how you configure addressing and gateways on a dual port NIC, because I don't understand how it works. Think that's why I'm confused.

    You mean NIC teaming? If so, Broadcom BACS is your friend. I use it on my production boxes either for doubling throughput or link redundancy.

    Windows Management Applications | Broadcom
  • EildorEildor Member Posts: 444
    Thank you all. Sorry for disappearing, been very busy!
  • VAHokie56VAHokie56 Member Posts: 783
    When I setup ports for our server access switches they are typically in a port channel and trunking x amount of vlans...I don't dive into the server side much but from my understanding the NIC's are teamed one primary going to server access switch A and secondary going to server access B...the edge switches are L2 and the redundancy for the vlans is at the dist level with GLBP...pretty standard setup

    Edit: for any who gasped at that "old" of a topology/design for a server farm...I agree and I should mention I am excited to be working on a nexus VSS/vpc solution next year!
    .ιlι..ιlι.
    CISCO
    "A flute without holes, is not a flute. A donut without a hole, is a Danish" - Ty Webb
    Reading:NX-OS and Cisco Nexus Switching: Next-Generation Data Center Architectures
Sign In or Register to comment.