HSRP between 2 access switches and 2 core switches

[soni.sunil]

Hi I am looking for running HSRP between 2 access switches and 2 core switches for client PC and Server network’s next-hop redundancy as per attached setup.

As you can see I have used one /29 network for connecting CORE & ACCESS switches & configure Interface VLAN10 (Layer 3 SVI) with shown IPs and standby IP (VIP).G0/1 on Access Switches & G2/1 on Core Switches are access ports for VLAN10.

There is a L2 Trunk interconnecting Core-Main/Backup & as well as Access-Main/Backup Switches allowing VLAN10 to allow VLAN10’s HSRP packets to pass through (apart from other HSRP instances).

Below are the HRSP & Trunk configuration on Core and Access Switches please have a look and suggest if they are correct in term of HSRP implementation, as I can see on both side HSRP master & standby status are fine as desired, but I can’t ping VIP of ACCESS Switch from CORE switch, but the VIP of CORE switch I can ping from ACCESS switch.

Access-Main

interface GigabitEthernet0/1

 description ***Connected to CR-SW-01 PORT G2/1***

 switchport access vlan 10

 switchport mode access

 load-interval 30

!

interface GigabitEthernet0/2

 description ***Connected to AC-SW-01 & AC-SW-02 for HRSP***

 switchport trunk encapsulation dot1q

 switchport trunk allowed vlan 10,40

 switchport mode trunk

 load-interval 30

!

interface Vlan10

 description ***Connected to CR-SW-01 PORT G2/1***

 ip address 10.10.11.1 255.255.255.248

 standby 1 ip 10.10.11.2

 standby 1 timers msec 200 msec 750

 standby 1 preempt delay minimum 180

 standby 1 authentication accvlan10

Access-Backup

interface GigabitEthernet0/1

 description ***Connected to CR-SW-02 PORT G2/1***

 switchport access vlan 10

 switchport mode access

 load-interval 30

!

interface GigabitEthernet0/2

 description ***Connected to AC-SW-01 & AC-SW-02 for HRSP***

 switchport trunk encapsulation dot1q

 switchport trunk allowed vlan 10,40

 switchport mode trunk

 load-interval 30

!

interface Vlan10

 description ***Connected to CR-SW-02 PORT G2/1***

 ip address 10.10.11.3 255.255.255.248

 standby 1 ip 10.10.11.2

 standby 1 priority 10

 standby 1 timers msec 200 msec 750

 standby 1 preempt delay minimum 180

 standby 1 authentication accvlan10

Core-Main

interface GigabitEthernet2/1

 description ***Connected to AC-SW-01 PORT G0/1***

 switchport access vlan 10

 switchport mode access

 load-interval 30

!

interface GigabitEthernet2/2

 description ***Connected to CR-SW-01 & CR-SW-02 for HRSP***

 switchport trunk encapsulation dot1q

 switchport trunk allowed vlan 10,20

 switchport mode trunk

 load-interval 30

!

interface Vlan10

 description ***Connected to AC-SW-01 PORT G0/1***

 ip address 10.10.11.4 255.255.255.248

 standby 1 ip 10.10.11.5

 standby 1 timers msec 200 msec 750

 standby 1 preempt delay minimum 180

 standby 1 authentication crvlan10

Core-Backup

interface GigabitEthernet2/1

 description ***Connected to AC-SW-02 PORT G0/1***

 switchport access vlan 10

 switchport mode access

 load-interval 30

!

interface GigabitEthernet2/2

 description ***Connected to CR-SW-01 & CR-SW-02 for HRSP***

 switchport trunk encapsulation dot1q

 switchport trunk allowed vlan 10,20

 switchport mode trunk

 load-interval 30

!

interface Vlan10

 description ***Connected to AC-SW-02 PORT G0/1***

 ip address 10.10.11.6 255.255.255.248

 standby 1 ip 10.10.11.5

 standby 1 priority 10

 standby 1 timers msec 200 msec 750

 standby 1 preempt delay minimum 180

 standby 1 authentication crvlan10

[Richard Burts]

I am not clear what you are attempting to achieve with this. HSRP is generally implemented to provide first hop redundancy for client PCs and servers. With this /29 subnet there is no room for client PCs or servers.

But the main question here was whether this was a correct implementation of HSRP and the answer is that it is not correct. You have configured one HSRP group but you have provided two different virtual IPs. You have configured a single standby group so there will be a single active router for the group. Based on the symptoms that you describe it sounds like the core main switch has become the active router for the group. So the shared MAC for group one is associated with the virtual IP of .5 and the virtual IP of .2 is not associated with the the shared MAC.

HTH

Rick

[soni.sunil]

Hi Rick, thanks for your prompt response....my intention is to have the PC(192.168.20.0/24) and SERVER (192.168.40.0/24)networks should be having reachability & redundancy without involving LAYER3 protocol for redundant next-hop IP, so that PC to SERVERS & vice a versa should have reachability redundancy incase link to main switch or main switch itself fails, something like below if I am pointing next-hop as a VIP or floating IP.

On Core Switches :-

ip route 192.168.40.0 255.255.255.0 10.10.11.2 <<< VIP

On Access Switches :-

ip route 192.168.20.0 255.255.255.0 10.10.11.5 <<< VIP

[Richard Burts]

Thank you for the explanation. It does help me understand what you are trying to accomplish. In this case I believe that the solution is pretty simple. You should leave one pair (perhaps the core) using standby group1 and you should change the other pair (the access switches) to a different standby group (perhaps group 2). With two different groups there will be two different VIPs and your proposed static routes should work.

HTH

Rick

[soni.sunil]

Hi Rick thanks once again, so I am assuming I should use to configure as below and still one /29 subnet I can use to connect these Switches with the above static routings.

Access Switch-Main

interface Vlan10

 description ***Connected to CR-SW-01 PORT G2/1***

 ip address 10.10.11.1 255.255.255.248

 standby 2 ip 10.10.11.2

 standby 2 timers msec 200 msec 750

 standby 2 preempt delay minimum 180

 standby 2 authentication accvlan10

!

ip route 192.168.20.0 255.255.255.0 10.10.11.5

Access Switch-Backup

interface Vlan10

 description ***Connected to CR-SW-02 PORT G2/1***

 ip address 10.10.11.3 255.255.255.248

 standby 2 ip 10.10.11.2

 standby 2 priority 10

 standby 2 timers msec 200 msec 750

 standby 2 preempt delay minimum 180

 standby 2 authentication accvlan10

!

ip route 192.168.20.0 255.255.255.0 10.10.11.5

Core Switch -Main

interface Vlan10

 description ***Connected to AC-SW-01 PORT G0/1***

 ip address 10.10.11.4 255.255.255.248

 standby 1 ip 10.10.11.5

 standby 1 timers msec 200 msec 750

 standby 1 preempt delay minimum 180

 standby 1 authentication crvlan10

!

ip route 192.168.40.0 255.255.255.0 10.10.11.2

Core Switch -Backup

interface Vlan10

 description ***Connected to AC-SW-02 PORT G0/1***

 ip address 10.10.11.6 255.255.255.248

 standby 1 ip 10.10.11.5

 standby 1 priority 10

 standby 1 timers msec 200 msec 750

 standby 1 preempt delay minimum 180

 standby 1 authentication crvlan10

!

ip route 192.168.40.0 255.255.255.0 10.10.11.2

[Richard Burts]

Yes I believe that this configuration will work and will accomplish your goal of having redundancy in forwarding between access switches and core switches.

HTH

Rick

[soni.sunil]

Many thanks indeed , I will check ..just one more query...so do you prefer to have HSRP VLAN 10 packets to pass through these switches individual interconnecting trunks, or its good to have the VLAN10 to be allowed in trunk between both the Core Switches and block it on interconnect trunk between Access Switches ....So even Access switch HSRP packets will use the Core Switch Trunk to avoid any loop and thus maintaining HSRP main & Standby status...Just a thought.

[Richard Burts]

I do not understand this question. Are you talking about spanning tree blocking or some other type of blocking?

HTH

Rick

[soni.sunil]

Hi my question was in this setup as you can see I have one interconnecting trunk between Access Switches and allowing VLAN10 & second interconnecting trunk between Core Switches also allowing VLAN10, so it may create some STP loop may result in abnormal behavior in blocking/forwarding of HRSP packets, am I right ?

So I was thinking of allowing VLAN10 on inter-trunk between either Core Switches or Access Switches ONLY not on both sides inter-trunks, is it correct ?

[Richard Burts]

I believe that there are several points to consider:

- both core switches need to communicate with each other on vlan 10 for HSRP to work.

- both access switches need to communicate with each other on vlan 10 for HSRP to work.

- having trunks between access switches and between core switches provides redundancy in case a link between access switch and core switch develops a problem.

- if you remove vlan 10 from one of those trunks you limit the amount of redundancy.

Based on these points I would not suggest that you remove vlan 10 from any of the trunk ports.

HTH

Rick

[soni.sunil]

hi rick, many thanks I will check and get back to you in case any issue ;).