topic Re: Routers are not able to ping shared subinterfaces using OSPF in Routing and SD-WAN

Routers are not able to ping shared subinterfaces using OSPF

TylerByrd6153 — Thu, 26 Nov 2020 17:22:07 GMT

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!

Re: Routers are not able to ping shared subinterfaces using OSPF

Georg Pauwen — Thu, 26 Nov 2020 18:13:04 GMT

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.

Re: Routers are not able to ping shared subinterfaces using OSPF

TylerByrd6153 — Thu, 26 Nov 2020 18:50:15 GMT

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?

Re: Routers are not able to ping shared subinterfaces using OSPF

Georg Pauwen — Thu, 26 Nov 2020 21:48:17 GMT

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.

Re: Routers are not able to ping shared subinterfaces using OSPF

TylerByrd6153 — Fri, 27 Nov 2020 02:57:39 GMT

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!

Re: Routers are not able to ping shared subinterfaces using OSPF

TylerByrd6153 — Fri, 27 Nov 2020 03:23:49 GMT

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.

Re: Routers are not able to ping shared subinterfaces using OSPF

Giuseppe Larosa — Fri, 27 Nov 2020 08:00:38 GMT

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

Re: Routers are not able to ping shared subinterfaces using OSPF

Georg Pauwen — Fri, 27 Nov 2020 08:08:50 GMT

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)

Re: Routers are not able to ping shared subinterfaces using OSPF

Richard Burts — Fri, 27 Nov 2020 08:15:05 GMT

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).

Re: Routers are not able to ping shared subinterfaces using OSPF

paul driver — Fri, 27 Nov 2020 15:03:26 GMT

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.

Re: Routers are not able to ping shared subinterfaces using OSPF

TylerByrd6153 — Fri, 27 Nov 2020 17:07:23 GMT

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!

Re: Routers are not able to ping shared subinterfaces using OSPF

TylerByrd6153 — Fri, 27 Nov 2020 17:09:08 GMT

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.

Re: Routers are not able to ping shared subinterfaces using OSPF

TylerByrd6153 — Fri, 27 Nov 2020 17:13:03 GMT

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.

Re: Routers are not able to ping shared subinterfaces using OSPF

TylerByrd6153 — Fri, 27 Nov 2020 17:15:13 GMT

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?

Re: Routers are not able to ping shared subinterfaces using OSPF

paul driver — Sat, 28 Nov 2020 00:45:41 GMT

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.

Re: Routers are not able to ping shared subinterfaces using OSPF

Richard Burts — Fri, 27 Nov 2020 22:14:43 GMT

I am glad that we are making progress and that the concepts are becoming more clear. There are a couple of things that I want to address:

- OSPF vs HSRP.

OSPF is a protocol for routing between different subnets and different networks. OSPF looks for all the paths toward a destination network. When there is more than one path toward a destination network OSPF evaluates the alternatives and chooses the best path. And once it has chosen that best path OSPF watches to make sure that that best path is still valid. And if the chosen best path becomes not available then OSPF dynamically looks for an alternate path to the destination.

HSRP is a protocol to provide first hop redundancy (how does a host in the network get to its default gateway - first hop toward the destination) in a network or subnet. To understand this let us think about a network that has 2 layer 3 devices (might be routers or might be L3 switches with routing enabled) that are capable of forwarding traffic toward remote destinations. Remember that if 2 devices are in the same broadcast domain (which means in the same vlan/same subnet) then they can just arp for each other and communicate directly. But if the devices are in different broadcast domains then they need a gateway to forward their traffic toward the destination. Most IP stacks specify a single gateway (some IP stacks allow definition of multiple gateways but most do not). So each host in this vlan/subnet are configured with R1 as their gateway. As long as R1 is running things work well and traffic is forwarded. But what happens if R1 goes down? All of a sudden the hosts do not have a working gateway and can no longer reach remote subnets. How can we get the hosts to use an alternate gateway? That is what HSRP was designed to do. Each of the routers has its own IP address and HSRP uses a third IP address in the subnet that either router can use. One of the routers has the shared IP address and is the active router. If the active router fails then automatically the standby router becomes active and takes over the shared address. This provides first hop redundancy for the hosts in the subnet.

- preempt

Sometimes we do not care which of the routers is the active gateway. But sometimes we do care which of the routers is the active gateway and to accomplish this HSRP uses priority. If there are 2 routers and one has a higher priority then we expect that this router will be the active gateway. If the active gateway router fails then the standby router takes over the shared IP address and now the hosts in the subnet are still using an active gateway. But let us think a bit more carefully about how this will work. In a diagram in one of your posts the routers had priority of 150 and of 110. So when the network got started R1 with priority of 150 becomes active. And things work for a while. But then R1 goes down. When R1 is no longer working then R2 automatically becomes the active gateway with the shared address. Then R1 comes back into service. Now R1 has the higher priority but R2 is still the active gateway. But we want R1 to be active when it is available. So we need a mechanism that will allow R1 to take over as active router when it comes back into service. And that is what preempt does it allows that if a router joins the HSRP group and it has a higher priority then it will take over as the active router.

- Let me also point out that whether you want preempt on both routers or on just one depends on whether you are using track within HSRP. With track enabled the router can monitor its other interfaces (especially the outbound interface toward remote destinations) and if an interface goes down then the router lowers its operating priority which allows the standby router to take over. If you are using track then you want preempt on both of the routers. If you are not using track then you need preempt only on the router with higher priority.

Re: Routers are not able to ping shared subinterfaces using OSPF

TylerByrd6153 — Sat, 28 Nov 2020 08:05:17 GMT

Rick this is awesome! Thank you for all of this. I really appreciate you taking the time to write all of this out and explain all of this, it is very helpful! I will most definitely refer back to this in the future 😄

@paul driver @Georg Pauwen @Giuseppe Larosa and Rick, Here is the update that I promised.

Part of the issue is using a virtual platform. For the last few hours I could not get HSRP to work no matter what I did until I realized that it may not be anything that I am doing and may actually be the virtual platform. Well after saving everything and restarting CML I was able to get HSRP to work properly and it is configured and running as it should!

Now here is the next hurdle I am facing is getting the distro switch below to be able to ping the 172.0.0.1/2 ip addresses on the routers. I'm attempting to use OSPF to perform the routing however I am not doing something correctly. How would I go about getting the VLAN 10 network out to another subnet using OSPF? Or must I use static routes? I have added files with the outputs.

Thank you all for all your help, its been really insightful!

Re: Routers are not able to ping shared subinterfaces using OSPF

paul driver — Sat, 28 Nov 2020 10:43:52 GMT

Hello
You can run static routing between the core and distribution with a default route on the distribution pointing to the hsrp virtual address of the cores and have static routes on the cores pointing to the distribution for the fiancé and marking subnets, but why not just enable ospf on the distribution switches if they support it so to advertise the lan subnets, Then advertise a default route from the ospf cores into the distribution then you wouldn't require the HSRP.

Re: Routers are not able to ping shared subinterfaces using OSPF

TylerByrd6153 — Sat, 28 Nov 2020 17:32:37 GMT

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. I am aiming for a method that would allow me full redundancy while using OSPF. But yes, I do want to use OSPF on the distro switches as well, I just wanted to get one thing working first so I could understand how to configure it in the future.

Please let me know if I am not understanding.

Re: Routers are not able to ping shared subinterfaces using OSPF

paul driver — Sat, 28 Nov 2020 18:13:56 GMT

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.