11-26-2020 09:22 AM
Hi all,
What I am trying to do is create a topology where Rtr 1 can ping Rtr 2 using OSPF then set up VRRP (or HSRP if possible but read that OSPF and HSRP cannot be used together) between them using the sub interfaces.
If the Rtr's do not share the same sub interfaces then OSPF reacts normally and the routes appear in the routing table and one side can ping over to the other. However if they both have the same sub interfaces then they can no longer communicate with the sub interfaces. The connection between the two routers, which is on a 172.0.0.x /24 subnet, communicates just fine.
I'm sure it's something simple that I am missing or not understand.
Rtr1 and Rtr2 both use interface gig 0/0 to connect to each other.
Rtr1 and Rtr2 both use interface gig 0/2 for their sub interfaces.
The format when pasting into the post wasn't very easy to read so, I've attached the outputs for show ip ospf data base, show ip ospf int, show ip ospf nei, show run | s ospf, show run | s interface.
I've included a separate document for the routing tables of each router. One is with one router's g0/2 shut down and the other is with both having the same interfaces/subinterfaces up.
I have also included a screen shot of the lab.
Thank you for your help in advance!
Solved! Go to Solution.
11-28-2020 10:13 AM
Hello
@TylerByrd6153 wrote:
Pual,
This is true, however the default route's IP address would belong to one device (Rtr) and if that router would go down then that connection would be lost. If I am not misunderstanding.
You can advertise a default from both core rtrs with preference being primary core rtr and if that does go down then the default from the secondary core will take preference.
This can be accomplished with a very simple ipsla object tracking statement with ospf.
11-26-2020 10:13 AM
Hello,
you have identical subnets on the subinterfaces on both routers. They will never be able to communicate because each router thinks that they are locally connected.
11-26-2020 10:50 AM
Hi Georg,
Thank you for your response. So, if this is the case then how is VRRP implemented in this scenario? Wouldn't both routers require identical subnets?
11-26-2020 01:48 PM
Hello,
exactly. VRRP (and HSRP/GLBP) require the same subnet, but they would be directly connected. In your case, there is another subnet (172.0.0.0/24) separating the subinterfaces, that is why it does not work.
11-26-2020 06:57 PM
Okay, so this is where I start to get confused about all of this.
In the topologies that I look up for VRRP (HSRP/GLBP) they show:
------------------Internet/router-------------------
^------Rtr1 <HSRP----> SW1 <----HSRP> Rtr2------^
There are only four connections with the switch having both routers connected to it and then the routers each having a connection to the internet/other router. On the routers' interface that connects to the switch HSRP/VRRP is configured on that port. Routers 1 and 2 do not connect to each. They are on the same subnet but are not directly connected. We also have a similar configuration on our corporate network to what I've explained but on our network we are using subinterfaces as I have in my lab.
I have also configured my lab with the interfaces being directly connected but this would not allow me to route to the rest of my network.
I'm really scratching my head with this one. I appreciate your help so far by the way!
11-26-2020 07:23 PM
So, I just looked at our corporate routers and I'm seeing the same thing that I'm seeing in my lab where the active router is local and the standby is unknown. However, I don't understand this either.
Here is a topology that I was explaining in the above post:
How is HSRP supposed to function proper in the above topology and in each video I have seen if the active and standby routers are unknown from each other and how is routing going to work properly if there are identical subnets on each router but they wont talk to each other because of this?
I'm sorry, I'm just really confused at this point.
11-27-2020 12:00 AM
Hello @TylerByrd6153 ,
you need a switch in the middle between interfaces with subinterfaces that use trunk ports to router interfaces and have defined the same set of VLANs as those used in the router subinterfaces.
HSRP or VRRP require the two routers to share a common logical broadcast domain to be able to receive each other hello messages.
In your lab the R1:gi0/2 and R2:gi=0/2 have to be connected to a LAN switch with defined the VLANs used by subinterfaces other switch ports can be access ports to clients or can lead to access layer switch where clients for each VLAN connect to.
Hope to help
Giuseppe
11-27-2020 09:07 AM
I think I'm understanding the issue now. I wasn't able to make sure the switch between the routers was configured properly but I will update later today with what I find.
In any case, thank you and I will update you soon!
11-27-2020 12:08 AM - edited 11-27-2020 12:08 AM
Hello,
the only reason the active/standby routers are unknown is a misconfiguration. Check if the configs on RTR-01 and RTR-02 look like this:
RTR-01
interface GigabitEthernet0/1
ip address 10.1.1.2 255.255.255.248
standby 1 ip 10.1.1.1
standby 1 priority 150
standby 1 preempt
RTR-02
interface GigabitEthernet0/1
ip address 10.1.1.3 255.255.255.248
standby 1 ip 10.1.1.1
standby 1 priority 110
In any case, all IP addresses (virtual and physical) should be reachable from both routers. The output of 'sh standby' should look like below:
RTR-01#sh standby
GigabitEthernet0/1 - Group 1
State is Active
5 state changes, last state change 00:06:20
Virtual IP address is 10.1.1.1
Active virtual MAC address is 0000.0c07.ac01
Local virtual MAC address is 0000.0c07.ac01 (v1 default)
Hello time 3 sec, hold time 10 sec
Next hello sent in 1.728 secs
Preemption enabled
Active router is local
Standby router is 10.1.1.3, priority 110 (expires in 8.000 sec)
Priority 150 (configured 150)
Group name is "hsrp-Gi0/0-1" (default)
RTR-02#sh standby
GigabitEthernet0/1 - Group 1
State is Standby
1 state change, last state change 00:00:13
Virtual IP address is 10.1.1.1
Active virtual MAC address is 0000.0c07.ac01
Local virtual MAC address is 0000.0c07.ac01 (v1 default)
Hello time 3 sec, hold time 10 sec
Next hello sent in 0.624 secs
Preemption disabled
Active router is 10.1.1.2, priority 150 (expires in 9.184 sec)
Standby router is local
Priority 110 (configured 110)
Group name is "hsrp-Gi0/0-1" (default)
11-27-2020 09:09 AM
I think you are correct and I will update the thread later today after I can get back to my lab.
Thank you for sticking with me on this and I am finally having it click on the over all issue.
11-27-2020 12:15 AM
The diagram in your most recent post makes sense. In that diagram both routers are connected to a switch in the same vlan on the switch, and also on the vlan where the host is connected. It is important in this that both routers are connected in the same broadcast domain. This means that they see each other as locally connected, that they can arp for the peer address and get a response and therefore communicate directly. In this environment OSPF plays no role.
I am confused about your original post and the questions it asks. How does OSPF become an element in this? HSRP is for communication within a common subnet/common vlan while OSPF is for communication between different subnets. Your original diagram seems to show each router connected to a subnet with the same addressing but that does not have a layer 2 connection between them. That is contrary to the requirement that both routers in HSRP see each other as locally connected (in the same broadcast domain).
11-27-2020 09:13 AM
Hi Rick,
I'm understanding now and like I said in my response above I will update the thread when I can get back to my lab later today.
In regards to OSPF I was misunderstanding the use of HSRP and OSPF. I do need ospf to connect the broadcast domains and I do want to implement HSRP or VRRP for redundancy but OSPF can't route HSRP because both routers would have the subnet on each router. So, OSPF wasn't the issue, it was my misunderstanding.
11-27-2020 02:56 AM - edited 11-27-2020 07:03 AM
Hello
When you use sub-interfaces on a rtr then you are basically putting the physical interface into trunk and any sub-interface into a vlan( just like you would do on a switch)
So if two rtrs connect to each other via switch using sub-interfaces then as with switch to switch interconnects require a trunk then you need to connect the physical ports of each rtr to the switch as a trunk.
It seems your hsrp isn’t working as each rtr is sending hsrp hello "on its vlan interface" towards a multicast address of 224.0.0.2 but either rtr isnt receiving any response to their sent hello packets possibliy due to what i have explained above.
RTRx
int x/x < trunk
no shut
int x/x.10
encapsulation dot1q 123 < vlan 123
switch
vlan 123
exit
int x/x
description rtr1
switchport trunk encap dot1q
switchport mode trunk
int x/x
description rtr2
switchport trunk encap dot1q
switchport mode trunk
On a side note HSRPv1 premption is disabled by default so you need to enable it on both rtrs, i can see you dont have that applied.
11-27-2020 09:15 AM
Hi Paul,
Thank you, I'm going to make sure my lab is configured properly later today when I can get back to it and I will update you.
But, I'm not sure as to why I want preempt on both routers? I would only want one to remain the active when the connection was reestablished, right?
11-27-2020 01:21 PM - edited 11-27-2020 04:45 PM
Hello
@TylerByrd6153 wrote:
But, I'm not sure as to why I want preempt on both routers? I would only want one to remain the active when the connection was reestablished, right?
My understanding is that all FHRP protocols apart from than VRRP have preemption disabled by default, If you don't have this enabled and you specify a rtr with a high FHRP priority to become the preferred gateway then if/when that router fails and then reestablishes it wont preempt to become the active rtr even though it has the highest priority, The reason for that is no FHRP coup message isnt generated without preemption being enabled, So I would say its best to apply this feature to both rtrs running any FHRP for a more deterministic failover/load balancing approach.
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