If the router-ID of R2 is changed, while keeping the lo0.0 interface IP as 10.19.1.1 itself, please note the changes.
If I convert R2 as a ASBR by redistributing some external routes, notice the changes as highlighted below.
[SS] Yes, the above protocol will show all the OSPF routes in the routing table.
Original Message:
Sent: 09-03-2023 16:46
From: WILSON CHENG
Subject: Why qualified next hop command is not working for active redundancy scenario?
[SS]The path to destination 10.19.1.1 will be through the static route and not through the GRE interface. Please check "show route forwarding-table destination 10.19.1.1/32". In all probability, it will show the ge-0/0/6.0 interface as the exit interface.
W: You are correct. It is taken the Static Route path.
Destination Type RtRef Next hop Type Index NhRef Netif
10.19.1.1/32 user 1 10.1.22.2 ucst 1442 16 ge-0/0/6.0
[SS] Is 10.19.1.1 configured as the router-ID of the remote OSPF router?
[SS] If more clarity is needed on this point, please share the GRE and OSPF configuration from both ends. Also, share the outputs of "show configuration routing-options".
W: Will have to check once again and provide you with all the above answers.
Thanks for showing the difference under the "Prefix" column of the "show ospf route" outputs. Honestly, I was stuck in understanding the output, especially the "Route Type" column. Because if look into the Route type explanation from the Juniper link: https://www.juniper.net/documentation/us/en/software/junos/ospf/topics/ref/command/show-ospf-ospf3-route.html, it contradicts your explanation. Under Table 1 show ospf route output fields, Route type: Network-Network router & Router-Route to a router that is neither an Area BR nor an AS BR.
Before further discussion, need some help confirming between these 2 show commands:
Show route protocol ospf: Displays the route entries in the routing table that were learnt from OSPF?
Show ospf route: Display the OSPF routing table, which also means kind of related to the OSPF database?
So if "show ospf route" output is related to the OSPF database, then the Route Type "Router" means OSPF Type 1 LSA, which you mentioned is the Router's ID. The neighbor 10.19.1.1 did learn from OSPF. And for Route Type "Network" will be the Type 2 LSA, generated by the DR. This LSA shows who the DRs, and the DR interface prefix AND mask is connected to that segment of the multiaccess network.
[SS] a) 10.19.1.1 only exists in the OSPF database as it is the router-ID of the OSPF neighbour, not in the RIB or routing-table. As explained in my previous post, in the "show ospf route output", you only see 10.19.1.1 not 10.19.1.1/32 as this is just an indicative of the router-ID of the OSPF neighbor. Had the route been learnt actually through OSPF you would have seen an output similar to the following (with GRE gr- interfaces in your case, as compared to ge- in my lab scen ario).
W: Will the "show route protocol ospf" output show the actual learnt OSPF routes inside the routing table?
[SS] Notice the difference with the addition of the second route with /32 in the below output.
W: What/how does your configuration look like to have the /32 included in the output?
------------------------------
WILSON CHENG
Original Message:
Sent: 09-01-2023 09:48
From: Sheetanshu
Subject: Why qualified next hop command is not working for active redundancy scenario?
Q: Based on the above, which interface does network 10.19.1.1 take, GRE or Static? Shouldn't it be through the GRE tunnel because OSPF's default internal preference is 10? Should I look into the routing engine's forwarding table instead to discover the actual path?
[SS] The path to destination 10.19.1.1 will be through the static route and not through the GRE interface. Please check "show route forwarding-table destination 10.19.1.1/32". In all probability, it will show the ge-0/0/6.0 interface as the exit interface.
Because of the following two reasons GRE interface will not be selected:-
a) 10.19.1.1 only exists in the OSPF database as it is the router-ID of the OSPF neighbour, not in the RIB or routing-table. As explained in my previous post, in the "show ospf route output", you only see 10.19.1.1 not 10.19.1.1/32 as this is just an indicative of the router-ID of the OSPF neighbor. Had the route been learnt actually through OSPF you would have seen an output similar to the following (with GRE gr- interfaces in your case, as compared to ge- in my lab scen ario). Notice the difference with the addition of the second route with /32 in the below output.
jcluser@R1> show ospf route 10.19.1.1 Topology default Route Table:Prefix Path Route NH Metric NextHop Nexthop Type Type Type Interface Address/LSP10.19.1.1 Intra Router IP 1 ge-0/0/0.0 10.10.13.2 ge-0/0/2.0 10.10.23.210.19.1.1/32 Intra Network IP 1 ge-0/0/0.0 10.10.13.2 ge-0/0/2.0 10.10.23.2
If more clarity is needed on this point, please share the GRE and OSPF configuration from both ends. Also, share the outputs of "show configuration routing-options".
b) Even if you had a valid 10.19.1.1/32 OSPF route pointing to the GRE tunnels, the destination path to 10.19.1.1 would still have been through static. Prefernce of static route (5) wins over the preference of the internal OSPF route (10)
"Q: If it is taking through the GRE tunnel, why only the static route shown in the routing table? Shouldn't all routes show in the routing table?"
[SS] It is not being routed through GRE. As explained in the previous post and in the previous point, you do not have an OSPF route to 10.19.1.1/32 and thus it is not visible in the routing-table. 10.19.1.1 (and not 10.19.1.1/32) exists only in the OSPF database (and not in the routing-table) on account of it being the router-ID of the remote OSPF peer.
"Q; The OSPF metric for the GRE interface is configured with 10. And our static routes with qualified next-hop with metric 100 & 1000. (None of the IP within the static routes are in OSPF interfaces) I believe these 2 metrics won't affect each other when doing route selection, correct?"
[SS] The OSPF metric of the GRE interface is immaterial here, as you don't have an OSPF route to 10.19.1.1/32 via the gr- interfaces. Even if you had, before metric, the preferences of the routes (OSPF and static) would have been compared first. Static route with preference 5 would have been selected. As you have two static routes of the same preference 5 but of different metric, the static route with the metric of 100 will be selected.
------------------------------
Sheetanshu Shekhar
Original Message:
Sent: 08-31-2023 06:12
From: WILSON CHENG
Subject: Why qualified next hop command is not working for active redundancy scenario?
Sheetanshu,
Basically, my questions are related to our configured qualified next hop. Our existing network setup is as follows: OSPF---GRE---SRX(A)---router---SRX(B)---GRE---OSPF.
The planned data traffic is supposed to travel through the GRE tunnel using OSPF. 10.19.1.1 is a loopback address.
- Qualified next hop is configured for outbound interface redundancy purposes:
set routing-options static route 10.19.1.1/32 qualified-next-hop 10.1.22.2 metric 100
set routing-options static route 10.19.1.1/32 qualified-next-hop 10.1.22.6 metric 1000
- And metric 10 is configured for GRE:
set protocols ospf area 0.0.0.0 interface gr-0/0/0.1109 metric 10
set protocols ospf area 0.0.0.0 interface gr-0/0/0.1109 metric 10
- Output from the SRX(A):
node0> show ospf route 10.19.1.1
Topology default Route Table:
Prefix Path Route NH Metric NextHop Nexthop
Type Type Type Interface Address/LSP
10.19.1.1 Intra Router IP 10 gr-0/0/0.1109
gr-0/0/0.1119
node0> show route 10.19.1.1
inet.0: 776 destinations, 812 routes (776 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.19.1.1/32 *[Static/5] 5w6d 03:53:38, metric 100
> to 10.1.22.2 via ge-0/0/6.0
[Static/5] 5w6d 03:47:35, metric 1000
> to 10.1.22.6 via ge-5/0/6.0
Q: Based on the above, which interface does network 10.19.1.1 take, GRE or Static? Shouldn't it be through the GRE tunnel because OSPF's default internal preference is 10? Should I look into the routing engine's forwarding table instead to discover the actual path?
Q: If it is taking through the GRE tunnel, why only the static route shown in the routing table? Shouldn't all routes show in the routing table?
Q; The OSPF metric for the GRE interface is configured with 10. And our static routes with qualified next-hop with metric 100 & 1000. (None of the IP within the static routes are in OSPF interfaces) I believe these 2 metrics won't affect each other when doing route selection, correct?
------------------------------
WILSON CHENG
Original Message:
Sent: 08-31-2023 05:23
From: Sheetanshu
Subject: Why qualified next hop command is not working for active redundancy scenario?
Thanks. Corrected the IPs.
------------------------------
Sheetanshu Shekhar
Original Message:
Sent: 08-31-2023 04:37
From: WILSON CHENG
Subject: Why qualified next hop command is not working for active redundancy scenario?
If the CLI output is from R1, based on the 1st output:
jcluser@CE# run show route 1.1.1.1 inet.0: 8 destinations, 10 routes (8 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both1.1.1.1/32 *[Static/5] 00:20:29 > to 10.10.1.1 via ge-0/0/1.0 [Static/7] 00:20:29 > to 10.10.3.1 via ge-0/0/3.0
Destination network: 1.1.1.1/32
Next-hop: 10.10.1.1 thru local interface ge-0/0/1.0
From the diagram, 10.10.1.1 is R1 local interface ge-0/0/1 IP. And 10.10.3.1 is R1 interface ge-0/0/2 local interface IP. Correct?
------------------------------
WILSON CHENG
Original Message:
Sent: 08-31-2023 03:58
From: Sheetanshu
Subject: Why qualified next hop command is not working for active redundancy scenario?
"Thanks for your quick response. Based on your detailed explanation, I believe you need to swap the R1 & R2 positions for the connectivity diagram"
[SS] The positions of R1 and R2 are correct. R1 has static route for 1.1.1.1/32 with R2 interface IPs as the next-hop. FOR CLARITY, the CLI outputs should have shown the router name as R1, not CE.
"But I don't completely understand what Juniper means by "active redundancy" within the sentence"
[SS] I think that it simply means that the qualified next-hop option alone is insufficient to meet all the redundancy scenarios automatically.
"But also look at the metric is 2. So is it the chosen route because of the preference first, or the metric first? and what is the sequence of choosing the route to put in the forwarding table?"
[SS] The lowest route-preference will always be preferred first for two similar route-prefixes. E.g. if 10.10.1.0/24 is learnt via RIP (default preference of 100) and also has a static route (default preference of 5), static route will be preferred. If there are two routes of the same preference (let's say two static routes), then the one with a lower metric will be preferred if configured.
However, the more appropriate use case of metric with static routes is to associate the metric of the route when it is redistributed into OSPF. By default, all type 1 routes are redistributed with type 1 metric, and all other routes are redistributed with type 2 metic in OSPF. The metric value configured on the static route will override these behaviors and will redistribute the static route into OSPF with the metric value configured with the static route or the qualified next-hop, as applicable.
------------------------------
Sheetanshu Shekhar
Original Message:
Sent: 08-31-2023 03:01
From: WILSON CHENG
Subject: Why qualified next hop command is not working for active redundancy scenario?
Sheetanshu,
Thanks for your quick response. Based on your detailed explanation, I believe you need to swap the R1 & R2 positions for the connectivity diagram.
I do understand the above scenario. That's why RPM should be used to detect the remote network connectivity. But I don't completely understand what Juniper means by "active redundancy" within the sentence "The normal next qualified hop method is not feasible for active redundancy, hence RPM probes are used." [SRX] Example: Configuring IP monitoring using RPM Probes for failover between multiple ISPs (juniper.net)
Also, within the example shown below took the first route. Yes, because the preference of 1 is less than 5, that's understandable. But also look at the metric is 2. So is it the chosen route because of the preference first, or the metric first? and what is the sequence of choosing the route to put in the forwarding table? Thanks
[edit]root@SRX-Firewall# run show route 0.0.0.0 inet.0: 28 destinations, 29 routes (28 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[Static/1] 00:00:12, metric2 0 > to 2.1.1.6 via ge-0/0/0.1 <<<<<<<<<<<<<< Applied route [Static/5] 08:57:43 > to 2.1.1.2 via ge-0/0/0.0
------------------------------
WILSON CHENG
Original Message:
Sent: 08-30-2023 03:00
From: Sheetanshu
Subject: Why qualified next hop command is not working for active redundancy scenario?
Hi,
"What i understand is if using qualified next hop command, and if the static route directly connected next hop is not reachable, then the static route will be inactive"
This is not entirely true. It will just check whether the interface connected towards the next-hop is up, that is the interface status. The interface that resolves towards the next hop can be up, even if the next-hop IP is not reachable.
Consider an example below, as shown below:
- R1 and R2 are connected in the subnet 10.10.1.0/30 via an L2 switch.
- R1 and R2 are also directly connected in the subnet 10.10.3.0/30.
- R1 has a static route to 1.1.1.1/32 with next-hop as 10.10.1.2 and qualified next-hop as 10.10.3.2 (preference 7)
R1 (ge-0/0/1 - 10.10.1.1/30 ) ----------(ge-0/0/1 - VLAN 10) SW (ge-0/0/2 - VLAN 10) --------------(ge-0/0/1 - 10.10.1.2/30) R2
| |
| (ge-0/0/2 - 10.10.3.1/30)--------------------------------------------------------------------------------------(ge-0/0/2 - 10.10.3.2/30) |
jcluser@CE# show routing-options static route 1.1.1.1/32 next-hop 10.10.1.1;qualified-next-hop 10.10.3.1 { preference 7;}[edit]jcluser@CE# run show route 1.1.1.1 inet.0: 8 destinations, 10 routes (8 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both1.1.1.1/32 *[Static/5] 00:15:16 > to 10.10.1.1 via ge-0/0/1.0 [Static/7] 00:15:16 > to 10.10.3.1 via ge-0/0/3.0jcluser@CE# run ping 10.10.1.1 rapid PING 10.10.1.1 (10.10.1.1): 56 data bytes!!!!!--- 10.10.1.1 ping statistics ---5 packets transmitted, 5 packets received, 0% packet lossround-trip min/avg/max/stddev = 1.953/7.556/29.120/10.783 ms[edit]jcluser@CE# run ping 1.1.1.1 rapid PING 1.1.1.1 (1.1.1.1): 56 data bytes!!!!!--- 1.1.1.1 ping statistics ---5 packets transmitted, 5 packets received, 0% packet lossround-trip min/avg/max/stddev = 1.863/2.139/2.650/0.288 ms
Now lets imagine a failure scenario, where the physical link between the switch SW and the R2 router goes down. This will keep the interface ge-0/0/1 on R1 up, but the next-hop 10.10.1.1 would not be reachable in this case. However, as the local interface is up, the routing table will still point to 10.10.1.1, and the pings to 1.1.1.1 will fail, even though we have a working qualified-next hop.
jcluser@CE# run show interfaces ge-0/0/1 terse Interface Admin Link Proto Local Remotege-0/0/1 up upge-0/0/1.0 up up inet 10.10.1.2/30 multiservice[edit]jcluser@CE# [edit]jcluser@CE# run show route 1.1.1.1 inet.0: 8 destinations, 10 routes (8 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both1.1.1.1/32 *[Static/5] 00:20:29 > to 10.10.1.1 via ge-0/0/1.0 [Static/7] 00:20:29 > to 10.10.3.1 via ge-0/0/3.0[edit]jcluser@CE# run ping 10.10.1.1 rapid PING 10.10.1.1 (10.10.1.1): 56 data bytes.....--- 10.10.1.1 ping statistics ---5 packets transmitted, 0 packets received, 100% packet loss[edit]jcluser@CE# run ping 1.1.1.1 rapid PING 1.1.1.1 (1.1.1.1): 56 data bytes.....--- 1.1.1.1 ping statistics ---5 packets transmitted, 0 packets received, 100% packet loss
If the interface ge-0/0/1 on R1 is physically down, then the qualified-next-hop will kick in.
jcluser@CE# run show interfaces ge-0/0/1 terse Interface Admin Link Proto Local Remotege-0/0/1 down downge-0/0/1.0 up down inet 10.10.1.2/30 multiservice[edit]jcluser@CE# run show route 1.1.1.1 inet.0: 7 destinations, 8 routes (7 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both1.1.1.1/32 *[Static/7] 00:43:06 > to 10.10.3.1 via ge-0/0/3.0[edit]jcluser@CE# run ping 1.1.1.1 rapid PING 1.1.1.1 (1.1.1.1): 56 data bytes!!!!!--- 1.1.1.1 ping statistics ---5 packets transmitted, 5 packets received, 0% packet lossround-trip min/avg/max/stddev = 2.984/84.482/339.299/128.178 ms
Regards
------------------------------
Sheetanshu Shekhar
Original Message:
Sent: 08-29-2023 05:51
From: WILSON CHENG
Subject: Why qualified next hop command is not working for active redundancy scenario?
Within the Juniper: [SRX] Example: Configuring IP monitoring using RPM Probes for failover between multiple ISPs (juniper.net)
The Solution section said:
- The normal next qualified hop method is not feasible for active redundancy, hence RPM probes are used.
What i understand is if using qualified next hop command, and if the static route directly connected next hop is not reachable, then the static route will be inactive. Then the next qualified next hop will take over. If that is the case, then it should work with qualified next hop command.
Can anyone explain why the qualified next hop might not work in more detail, please? Thanks
------------------------------
WILSON CHENG
------------------------------