05-30-2022 12:40 PM
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
Solved! Go to Solution.
05-30-2022 02:28 PM - edited 05-30-2022 02:29 PM
""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.
05-30-2022 02:45 PM - edited 05-30-2022 03:23 PM
05-30-2022 12:52 PM - edited 05-30-2022 12:54 PM
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.
05-30-2022 01:53 PM
05-30-2022 01:57 PM
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
05-30-2022 02:11 PM
05-30-2022 02:45 PM - edited 05-30-2022 03:23 PM
.
05-30-2022 02:56 PM
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?
05-30-2022 03:03 PM
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
05-30-2022 01:59 PM
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.
05-30-2022 01:32 PM - edited 05-30-2022 01:35 PM
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
05-30-2022 02:01 PM
05-30-2022 02:28 PM - edited 05-30-2022 02:29 PM
""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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide