So, I've had this conversation several times recently. I've filled up a few whiteboards, in a few different states, so, I thought it's time to put it out on ye olde blog.
Let's consider the following "simplified" network diagram.
In this simple environment, We have 2x Core routers and 2x Switches which are dual homed – one link to each of the core routers.
I've got several different ways this conversation can go, but for tonight, let's focus on two things:
- We want gateway redundancy
- We want to simultaneously utilize BOTH links from the Switches (and thus BOTH Core routers)
Here's a few simple config snippets for the conversation.
Core1
hostname Core1
!
<Only putting in relevant STUB Configuration>
!
spanning-tree mode rapid-pvst
spanning-tree extend system-id
spanning-tree vlan 5,101,201,999 priority 4096
spanning-tree vlan 10,102,202 priority 8192
!
vlan internal allocation policy ascending
!
interface GigabitEthernet1/0/1
description Uplink Switch1 gig0/27
switchport trunk encapsulation dot1q
switchport trunk native vlan 999
switchport trunk allowed vlan 5,10,101,201
switchport mode trunk
spanning-tree bpdufilter enable
!
interface GigabitEthernet1/0/2
description Uplink Switch2 gig0/27
switchport trunk encapsulation dot1q
switchport trunk native vlan 999
switchport trunk allowed vlan 5,10,102,202
switchport mode trunk
spanning-tree bpdufilter enable
!
interface Vlan1
no ip address
shutdown
!
interface Vlan5
ip address 10.128.5.252 255.255.255.0
standby 5 ip 10.128.5.254
standby 5 priority 200
standby 5 preempt
!
interface Vlan10
ip address 10.128.10.252 255.255.255.0
standby 10 ip 10.128.10.254
!
interface Vlan101
ip address 10.128.101.252 255.255.255.0
ip helper-address 10.128.10.101
standby 101 ip 10.128.101.254
standby 101 priority 200
standby 101 preempt
!
interface Vlan102
ip address 10.128.102.252 255.255.255.0
ip helper-address 10.128.10.101
standby 102 ip 10.128.102.254
!
interface Vlan201
ip address 10.128.201.252 255.255.255.0
ip helper-address 10.128.10.101
standby 201 ip 10.128.201.254
standby 201 priority 200
standby 201 preempt
!
interface Vlan202
ip address 10.128.202.252 255.255.255.0
ip helper-address 10.128.10.101
standby 202 ip 10.128.202.254
!
interface Vlan999
no ip address
!
ip classless
ip route 0.0.0.0 0.0.0.0 10.128.5.1 (IP address of the firewall cluster)
!
<SNIP>
Core2
hostname Core2
!
<Only putting in relevant STUB Configuration>
!
spanning-tree mode rapid-pvst
spanning-tree extend system-id
spanning-tree vlan 10,102,202 priority 4096
spanning-tree vlan 5,101,201,999 priority 8192
!
vlan internal allocation policy ascending
!
interface GigabitEthernet1/0/1
description Uplink Switch1 gig0/28
switchport trunk encapsulation dot1q
switchport trunk native vlan 999
switchport trunk allowed vlan 5,10,101,201
switchport mode trunk
spanning-tree bpdufilter enable
!
interface GigabitEthernet1/0/2
description Uplink Switch2 gig0/28
switchport trunk encapsulation dot1q
switchport trunk native vlan 999
switchport trunk allowed vlan 5,10,102,202
switchport mode trunk
spanning-tree bpdufilter enable
!
interface Vlan1
no ip address
shutdown
!
interface Vlan5
ip address 10.128.5.253 255.255.255.0
standby 5 ip 10.128.5.254
!
interface Vlan10
ip address 10.128.10.253 255.255.255.0
standby 10 ip 10.128.10.254
standby 10 priority 200
standby 10 preempt
!
interface Vlan101
ip address 10.128.101.253 255.255.255.0
ip helper-address 10.128.10.101
standby 101 ip 10.128.101.254
!
interface Vlan102
ip address 10.128.102.253 255.255.255.0
ip helper-address 10.128.10.101
standby 102 ip 10.128.102.254
standby 102 priority 200
standby 102 preempt
!
interface Vlan201
ip address 10.128.201.253 255.255.255.0
ip helper-address 10.128.10.101
standby 201 ip 10.128.201.254
!
interface Vlan202
ip address 10.128.202.253 255.255.255.0
ip helper-address 10.128.10.101
standby 202 ip 10.128.202.254
standby 202 priority 200
standby 202 preempt
!
interface Vlan999
no ip address
!
ip classless
ip route 0.0.0.0 0.0.0.0 10.128.5.1 (IP address of the firewall cluster)
!
<SNIP>
Switch1
hostname Switch1
!
<Only putting in relevant STUB Configuration>
!
spanning-tree mode rapid-pvst
spanning-tree extend system-id
!
vlan internal allocation policy ascending
!
interface GigabitEthernet0/1
description Workstation With Phone
switchport trunk encapsulation dot1q
switchport trunk native vlan 101
switchport trunk allowed vlan 101,201
switchport mode trunk
switchport voice vlan 201
no ip address
spanning-tree portfast trunk
!
interface GigabitEthernet0/2
description Server
switchport mode access
switchport access vlan 10
spanning-tree portfast
!
interface GigabitEthernet0/27
description Uplink Core1 gig1/0/1
switchport trunk encapsulation dot1q
switchport trunk native vlan 999
switchport trunk allowed vlan 5,10,101,201
switchport mode trunk
!
interface GigabitEthernet0/28
description Uplink Core2 gig1/0/1
switchport trunk encapsulation dot1q
switchport trunk native vlan 999
switchport trunk allowed vlan 5,10,101,201
switchport mode trunk
!
interface Vlan1
no ip address
shutdown
!
interface Vlan5
ip address 10.128.5.101 255.255.255.0
!
ip classless
ip route 0.0.0.0 0.0.0.0 10.128.5.254 (IP address of the vlan5 HSRP Virtual IP)
!
<SNIP>
Gateway Redundancy
I've blogged before about HSRP – so I won't bore you. You can see how the VLANs have individual IP addresses and then share a Virtual / Standby IP address. We simply point the various VLAN traffic to the Virtual / Standby IP for its gateway, and bingo bango – you win.
What I'm doing here is specifying the "even" VLANs to be primary on one core, and the "odd" VLANs to be primary on the other core.
Utilizing Both Links
In a normal setup, with 2x links, Spanning-Tree will choose one link to "forward" and the other link to "block" but that's not what we want. We want to utilize both links.
Notice how I adjusted the spanning-tree priorities here? I've got the "even" set as root/priority 4096 on one core and 8192 on the other. And then, vice versa, I've got the "odd" set as root/priority 4096 on the other core and 8192 on the first.
This allows the odd VLAN traffic to flow down one link while the even VLAN traffic flows down the other link – at the same time. So, both links are in "forward" status for their appropriate VLANs and in "block" status for the others.
And, because this is spanning-tree, if one fails, the other will take over.
That's enough for today. I just wanted to start the conversation.
Is anyone else doing this? Are you doing it differently? Am I missing an obvious issue/error here?
Might of lost my comment signing in to twitter….
Anyway, you are pruning VLANs though? Have you tested failover, because I suspect that the 802.1q trunk will block the VLANs that try to use the “backup” link. This would undo your PVSTP+ config…. 🙂
I think this is a great topic. There are a ton of ways to do this. Obviously, multi-chassis Etherchannel with HSRP or L2/L3 load balancing configured. Also, OSPF could do this too…
This is what makes the network design world so fascinating to me. There’s never a right or wrong way. 🙂
Thanks John!
I’ve not run into any sort of trunk/block issue in the past when I’ve done this with Cisco “native” networking. When you add multiple vendors into the mix, and have to adjust your STP topology, then things can get complex for sure.
I totally agree with your design statement – MANY ways to get there. I hope others come in to add to the conversation!
–DW
amazing Article!