Querying routing table in a ClusterXL

[Matlu]

Hello, everyone.

I have a query.

What is the best way to query a specific route within a ClusterXL?

I have noticed differences when using the command "route -n", and "ip route get <IP Destination>", because when I query a route for example for the destination 10.120.1.77, if I do it with the command "route -n" it tells me that I reach it through the interface eth1-02.139 which is a VLAN, but if I query it with the command "ip route get <IP>", it tells me that I reach it through the interface eth1-02 (without vlan).

Can you clarify the doubt, please?

Thank you.

Which of the 2 commands is more "reliable" when I want to query the route for a destination?

[PhoneBoy]

What version/JHF?
And I’m not clear what you mean by query here.
The full CLI command entered might be helpful.

Also there are clish commands that may be more appropriate here.

[Matlu]

Hello, my friend.
Thanks for your prompt reply.

I understand, that the routes when working with a ClusterXL, must be identical in both members. Is this correct?

Based on this theory, is that I expose my doubt.
In the images that I share here, you can see that when I make the query to both members with the command "ip route get 10.120.1.77 the result I get is different.

However, when I query both members, using the command "route -n | grep 10.120.1.77", the result is the same in both members.

Is this behavior normal?
From the CLI expert mode of both Firewalls, which of the two commands is more "reliable" to query the route table?
route -n, or ip route get <IP DST>?

The SITEVPN2RENIEC unit has the JHF 102 and the SITEVPN1RENIEC unit has the JHF 161.

Thanks for any comments.

Regards.

[Bob_Zimmerman]

The routes don't need to be identical between members, no. Cluster members can have "non-monitored, private" interfaces which don't participate in clustering, and which can have unique configuration per member. This generally isn't a good idea, but it is possible.

'route -n' and 'ip route get' are asking the system two different questions.

'route -n' requests that it show you the routes in its FIB. This is showing you an input to the routing decision. If you want to predict the routing decision which would be made, you then must interpret the data and the other inputs to the routing decision.

'ip route get' asks the system to evaluate the FIB for a destination and tell you what interface and next hop it would use to reach it. This is showing you the output of the routing decision. Since this involves getting the result from the FIB, it is not subject to human misinterpretation. It doesn't tell you why it made a given decision, though.

[Chris_Atkinson]

In your screenshot we don't see the eth1-02 (without VLAN) output?

To help set a baseline, is this cluster running only with static routing or also dynamic (ospf / bgp / ecmp)?

Are all interfaces connected/up on both systems?

[Matlu]

Hello,

Sorry, the images did not load completely.
I am loading the image with respect to the other FW that is part of my ClusterXL.

In the image, you can see, that to reach the same IP, the FW has as reference only eth1-02 (No VLAN).

This behavior does not seem normal to me.

But when I make the query, using the command "route -n", the result I get in both FW is the same, it means that both FW reach that destination through the interface that is tagged with the VLAN 139.

Therefore, I want to know which of the two commands is the one that Checkpoint refers to as "reliable" to query the routing table from the CLI.

This problem is causing that the IP 10.120.1.77, can not consume a service that is within our network, and everything seems to indicate that it is due to routing problems.

Do you have any opinion that can help me?

Thanks

[Chris_Atkinson]

@Bob_Zimmerman Provided an answer above, further insights require additional information such as the version/JHF level, routing protocols used and interface status on each member as requested above.

[Matlu]

Hello, Chris.

Thanks for your reply.

Currently we are only working with static routes (we do not work with dynamic routing).

The status of the interfaces, I think you mean the output of "cphaprob -a if" command on each cluster member, right?

I share with you some images regarding the output of this command in each GW.

The problem exists when Member1 (SITEVPN1RENIEC), works as ACTIVE within the Cluster.

Currently Member2 (SITEVPN2RENIEC) is working as ACTIVE as a corrective measure we have taken.

I think that the communication problem, from IP 10.120.1.77 to Real IP 151.101.180.146 (which has a NAT IP 192.168.100.37), when we try to work with MEMBER1, is due to a routing problem, but I am not sure of my theory.

Thanks for your help and participation.

[Chris_Atkinson]

Check & compare the configuration/outputs between the nodes.

If the outputs match and forwarding is contrary to what's configure please consult TAC further who can provide guidance based on your specific version/JHF level. (Maybe also try removing and adding again the route on the standby/problematic gateway).

• show configuration static-route
• show route static all

[Matlu]

Hello, Chris.

After having reviewed my case in depth once again.
We found the following problem.

Firewall Policies -> OK
NAT -> OK
Routing -> OK

The problem is apparently focused on the SecureXL of MEMBER 1 of my Cluster.

When the SecureXL is left by default (Active) in the GW, the IP 10.120.177, it cannot get to open the port 1414 of the 192.168.100.37 (This IP is actually a NAT IP, which translates to an IP 151.X.X.X.X).

So, when I disable SecureXL on the GW completely, the traffic works fine.

Is it normal that SecureXL is giving me problems for a single traffic flow, on 1 single member of my Cluster?

On MEMBER 2, everything works fine, I have no need to disable SecureXL.

What solutions can I have in this case?

Thanks for your support

[Chris_Atkinson]

No this generally wouldn't be considered normal, which version & JHF is used on the gateway?

To expedite resolution please investigate it further with TAC.

[PhoneBoy]

If disabling SecureXL solves a problem, then it generally points to a bug.
That requires a TAC case.

[Matlu]

Hello,
Currently the GW are as follows.

Member 1 -> Take 161
Member 2 -> Take 102

Indeed, a TAC staff, has recommended us, to align both GW to the JHF Take 173, to check if this behavior improves.

We are going to perform the activity in a window, and I will be reporting the results.

Thanks for your support.

[Chris_Atkinson]

Sorry I hadn't noticed that you had already supplied the JHF level info above else would have asked why they were different...

Please update us with the results. 🙂

[Matlu]

Hello, Chris.

Initially, the 2 members had the JHF 102, but the problem of communication between IP -> 10.120.x.x to IP -> 192.168.x.x.x started to show up.
The case was reported to TAC at that time, and the Engineer who helped us told us at that time that we should upgrade the JHF to Take 161.
Our customer out of fear only decided to upgrade the Take of Member 1, because when we did it the communication problem persisted (that is the reason why now both members are now uneven).

We had to reopen a case with the TAC recently, and we found out that the problem is because of the SecureXL of member 1.
TAC has again asked us to update the Hotfix package to version 173.

This is how our scenario looks like.
I will update the packages, and I will be notifying the news.

Thanks for the help.

[Matlu · Accepted solution]

Hello, everyone.

Our reported problem with the SecureXL atypical pulling connections from a source to a destination has been fixed for the moment by upgrading the JHF package to version 173 of R80.40.

Thanks to all for the support.