HSRP Instances for VRF redundance in a Core L3 Switch

[Hannibal]

Hi Community, the best of internet !!

Please Let me to open a new issue to hear the experiencie 

Let's open a new topic about a core that we're re-architecting to make some VRFs highly available.

We have an L3 Core made up of two stacks of Catalyst 9300 switches installed in two different Data Centers, connected to each other through a 40 GB port-channel.

We have a total of 4 VRF's (virtual routing table), each one made up of 5 vlans (different subnets).

We want to implement HSRP between the two catalyst 9300 switch stacks to offer high availability to the 4 VRFs.

As I mentioned, each VRF consists of 5 different subnets. Each VRF will be configured in each of the two Switch Stacks that make up the Core.

This means that for each VRF we must have 5 different instances of HSRP, right?

For example, VRF 1 has the following network segments:

- Subnet 1, VRF 1, 10.10.10.0/24

- Subnet 2, VRF 1, 10.10.20.0/24

- Subnet 3, VRF 1, 10.10.30.0/24

- Subnet 4, VRF 1, 10.10.40.0/24

- Subnet 1, VRF 1, 10.10.50.0/24

For this case of VRF 1, we must have 5 HSRP instances, one for each subnet; which means that we are going to have 5 default gateways for each subnet within the same VRF 1.

Is this correct???

In total, we will need 5 default gateways for each VRF, which is the same as 25 default gateways.

Do any of you have experience in this type of implementation of multiple HSRP instances for a VRF??

Thanks a lot for sharing your experience...

Hann

[Flavio Miranda]

Hi

 You are going to have one HRSP per vlan, not per VRF.

"This means that for each VRF we must have 5 different instances of HSRP, right?"

yeah, that correct if you are going to have 5 vlan on this VRF.

As you correctly define, VRF stands for Virtual routing table. Take care to does not mess up VRF and VLAN concept because they are different.

Ex:

- Subnet 1, VRF 1, 10.10.10.0/24

- Subnet 2, VRF 1, 10.10.20.0/24

- Subnet 3, VRF 1, 10.10.30.0/24

- Subnet 4, VRF 1, 10.10.40.0/24

- Subnet 1, VRF 1, 10.10.50.0/24

Those network, inside VRF 1, will share the same routing table.  They are not communicating with, for example:

- Subnet 1, VRF 2, 10.10.10.0/24

- Subnet 2, VRF 2, 10.10.20.0/24

- Subnet 3, VRF 2, 10.10.30.0/24

- Subnet 4, VRF 2, 10.10.40.0/24

- Subnet 1, VRF 2, 10.10.50.0/24

Now, you have two routing table.

The HSRP is related to the interface vlan.  And the interface vlan will be, or not, inside a vrf.

Switch 1

int vlan 10

ip vrf forwarding 1

ip add 10.10.10.253  255.255.255.0

standby 1 ip  10.10.10.1

Switch 2

int vlan 10

ip vrf forwarding 1

ip add 10.10.10.254  255.255.255.0

standby 1 ip 10.10.10.1

If you do not add the command ip vrf forwarding on the interface vlan, it will belong to the global vrf.

[Hannibal]

Hi Flavio, Exactly, you have understood me perfectly

For each VRF we are going to have 5 Vlans or what is the same, 5 segments or IP networks, in the case of VRF 1, we are going to have the networks:

10.0.10.0/24
10.0.20.0/24
10.0.30.0/24
10.0.40.0/24
10.0.50.0/24

The problem is that I need all the Vlans or subnets within the same VRF or Virtual Routing Table to be able to communicate with each other.

We are not interested in there being communication between the VRFs, we are only interested in the fact that the IP subnets that belong to the same VRF can communicate. That is our big question.

Thanks in advance
Hann

[Flavio Miranda]

Thats exactly what is going to happen. 

 And for each  vrf you can also define a default gateway for that routing table 

ip route vrf X 0.0.0 0 0 0 0.0 gateway

[Hannibal]

Hi Flavio,

Really? I can define an unique default gateway for the entire VRF and it can serve to all Subnets or vlans that belong to the same VRF ?

Sorry if I do not understand you..

Thank you

Hann

[Flavio Miranda · Accepted solution]

.

[paul driver]

Hello

---

@Flavio Miranda wrote:

you can have one default gateway per VRF.

---

Can you elaborate on how this can be accomplished, the only way would be to cidr down all 5 subnets into a single /18  which would then become one large broadcast domain-  correct?

[Flavio Miranda]

Sorry, I meant default route not gateway.

R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#ip vrf
R1(config)#ip vrf ?
WORD VPN Routing/Forwarding instance name

R1(config)#ip vrf DG
R1(config-vrf)#
R1(config-vrf)#?
IP VPN Routing/Forwarding instance configuration commands:
bgp Commands pertaining to BGP
context Associate SNMP context with this vrf
default Set a command to its defaults
description VRF specific description
exit Exit from VRF configuration mode
export VRF export
import VRF import
maximum Set a limit
mdt Backbone Multicast Distribution Tree
no Negate a command or set its defaults
rd Specify Route Distinguisher
route-target Specify Target VPN Extended Communities
vpn Configure VPN ID as specified in rfc2685

R1(config-vrf)#exit

R1(config)#ip route ?
A.B.C.D Destination prefix
profile Enable IP routing table profile
static Allow static routes
vrf Configure static route for a VPN Routing/Forwarding instance

R1(config)#ip route vr
R1(config)#ip route vrf ?
WORD VPN Routing/Forwarding instance name

R1(config)#ip route vrf DG ?
A.B.C.D Destination prefix

R1(config)#ip route vrf DG 0.0.0.0 0.0.0.0 ?
A.B.C.D Forwarding router's address
Async Async interface
BVI Bridge-Group Virtual Interface
CDMA-Ix CDMA Ix interface
CTunnel CTunnel interface
DHCP Default Gateway obtained from DHCP
Dialer Dialer interface
FastEthernet FastEthernet IEEE 802.3
Lex Lex interface
Loopback Loopback interface
MFR Multilink Frame Relay bundle interface
Multilink Multilink-group interface
Null Null interface
Port-channel Ethernet Channel of interfaces
Serial Serial
Tunnel Tunnel interface
Vif PGM Multicast Host interface
Virtual-PPP Virtual PPP interface
Virtual-TokenRing Virtual TokenRing
Vlan Catalyst Vlans

[paul driver]

Hello

---

@Hannibal wrote:
We are not interested in there being communication between the VRFs, we are only interested in the fact that the IP subnets that belong to the same VRF can communicate. That is our big question.

---

As your are extending the L2 access layer across two cores then as long as the L3 interface on each core switch is in the same vrf then they will be able to communicate fine.

[paul driver]

Hello
It is indeed viable also you could go one step further and that is to implement load sharing (MHSRP) meaning each core switch can be active and standby for the same groups.

example:

Core 1
standby 1 ip 10.10.10.254
standby 2 ip 10.10.20.254
standby 3 ip 10.10.30.254
standby 4 ip 10.10.40.254
standby 5 ip 10.10.50.254

standby 1 priority 110
standby 2 priority 95
standby 3 priority 110
standby 4 priority 95
standby 5 priority 110

standby 1 preempt
standby 2 preempt
standby 3 preempt
standby 4 preempt
standby 5 preempt

Core 2
standby 1 ip 10.10.10.254
standby 2 ip 10.10.20.254
standby 3 ip 10.10.30.254
standby 4 ip 10.10.40.254
standby 5 ip 10.10.50.254

standby 1 priority 95
standby 2 priority 110
standby 3 priority 95
standby 4 priority 110
standby 5 priority 95

standby 1 preempt
standby 2 preempt
standby 3 preempt
standby 4 preempt
standby 5 preempt

[Hannibal]

Hi Paul

Excellent your Reply

You and Flavio, have understood me perfectly

For each VRF we are going to have 5 Vlans or what is the same, 5 segments or IP networks, in the case of VRF 1, we are going to have the networks:

10.0.10.0/24
10.0.20.0/24
10.0.30.0/24
10.0.40.0/24
10.0.50.0/24

The problem is that I need all the Vlans or subnets within the same VRF or Virtual Routing Table to be able to communicate with each other.

We are not interested in there being communication between the VRFs, we are only interested in the fact that the IP subnets that belong to the same VRF can communicate. That is our big question.

Load sharing is a big plus…

Thanks in advance
Hann

[MHM Cisco World · Accepted solution]

""We are not interested in there being communication between the VRFs, we are only interested in the fact that the IP subnets that belong to the same VRF can communicate. That is our big question.""

since the five SVI have IP and config under same VRF then they can connect to each other via InterVLAN.

look to VRF as virtual SW, here you have 
Core1 have five virtual SW in each virtual SW there are five SVI can connect to each other.