Link monitoring characteristics?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Link monitoring characteristics?

L4 Transporter

Hi Folks,

 

We have configured HA recently and trying to understand the features of Link monitoring.

 

We are considering Link monitoring only first since we want to consider our local firewall port health first.

 

We configured a Link monitoring group on interfaces 1/1 and 1/2 set to any.

Does this mean that the hardware port (1/1,1/2) has to go down to trigger a failover?

If I unplug the network cable from 1/1, is that a valid test to initate a failover?

 

We are trying to avoid a problem on the other end of connections triggering a failover on our firewall.

We are not considering Path monitoring yet for that reason, until we understand.

 

Any suggestions?

 

1 accepted solution

Accepted Solutions

Hi @OMatlock

Link Monitoring monitors the physical aspect of the connection, so if you unplug the cable or shutdown the appliance a failover event will triggered "ANY" or "ALL". In other words, Link Group is defined to monitor the critical links that make up the either one of your physical links.

 

On the other hand, Path monitoring should be used when link monitoring alone is not sufficient and you want to monitor the link(s) beyond the firewall’s physical interface. The Path Monitoring monitor a specific destination IP addresses using ICMP pings. Path Groups allow you to set up multiple paths to monitor simultaneously and failover can happen on "ANY" or "ALL" conditions.

 

My suggestion if you want to monitor the other end of the connection is to use the path monitoring instead.

Example:  If our partner company has a problem on their end logical of physical, the device IP address will stop responding, hence, the path monitorin can be configured to trigger a failover event; however, i this scenario, the failover is only relevant if you have two connections to your 3rd party. In other words, it does not make sense to trigger a failover to a secondary device, if your third party only has one connection.

 

For the ISP connection e1/1, I typically use Link and Path Monitoring together, and I alway monitor my default gateway IP address.

 

I hope it makes sense.

 

 

View solution in original post

8 REPLIES 8

Hi @OMatlock

 

As you already know, the failover action can be based on failure of ANY link or path, or ALL failures of the links or paths defined within the group. In the link monitoring example shown below, a Link Group is defined to monitor the critical links that make up the WAN, data center, and critical end user networks.

 

In your example, with both interfaces e1/1 and 1/2 belonging to the same Link monitoring group, and the condition set to "ANY", it means the either one of the links that fails, will trigger a failover condition. Now if you set the condition to "ALL", a failover condition will only be triggered if both e1/1 and e1/2 fail concurrently.

 

 

 

A quick question for you: What are e1/1 and e1/2 used for respectively? i.e e1/1 --> Untrust and e1/2 --> Trust?

 

There is also a design question to be analyzed such as: Do you have single or multiple ISPs in place?

 

https://live.paloaltonetworks.com/twzvq79624/attachments/twzvq79624/documentation_tkb/543/2/HA_Failo...

 

I'll wait for your answer to my question below, then I can elaborate a little bit more from a logical design perspective.

 

Thank you

 

Willian

 

Thank you!

 

Reading through this helpful document, I notice it mentioned to use Path monitoring when Link alone is not sufficient.

For our discussion, I am focusing on Link monitoring to understand that first.

 

We have 4 Layer 3 connections:

1/1 - ISP connection - static public IP.

1/2 - Internal IP - used for DMZ.  10.1.4.252

1/3 - Partner company direct connection - static public IP.

1/4 - Internal IP for internal subnet.  10.1.2.252

 

From what I read so far, Link monitoring looks for a hardware port failure on the PA device, correct?

I am trying to determine what the test case is for simulating a Link group failure and initiate a test failover?  Pull cable or down the port from console?

Will Link monitoring avoid problems on other end from initiating a failover on our firewall?

Example:  If our partner company has a problem on their end of our 1/3 connection, it should not cause our firewall to failover, correct?

 

Thanks again, still learning.  🙂

Hi @OMatlock

Link Monitoring monitors the physical aspect of the connection, so if you unplug the cable or shutdown the appliance a failover event will triggered "ANY" or "ALL". In other words, Link Group is defined to monitor the critical links that make up the either one of your physical links.

 

On the other hand, Path monitoring should be used when link monitoring alone is not sufficient and you want to monitor the link(s) beyond the firewall’s physical interface. The Path Monitoring monitor a specific destination IP addresses using ICMP pings. Path Groups allow you to set up multiple paths to monitor simultaneously and failover can happen on "ANY" or "ALL" conditions.

 

My suggestion if you want to monitor the other end of the connection is to use the path monitoring instead.

Example:  If our partner company has a problem on their end logical of physical, the device IP address will stop responding, hence, the path monitorin can be configured to trigger a failover event; however, i this scenario, the failover is only relevant if you have two connections to your 3rd party. In other words, it does not make sense to trigger a failover to a secondary device, if your third party only has one connection.

 

For the ISP connection e1/1, I typically use Link and Path Monitoring together, and I alway monitor my default gateway IP address.

 

I hope it makes sense.

 

 

Thank you!

 

Just to confirm, we do not want to monitor the other side of the connection at this point.

And we only have one connection for each interface.

And we do not want something that goes down at any 3rd party to cause us to failover.

 

Focusing on Link monitor for now.

 

So if our ISP (or other) has a problem, we would prefer to be notified, but not failover.

 

We only want a failover if one of our physical ports go down on our firewall.

 

Just talking about Link monitor, if I pull the network cable on an interface does it constitute a failover condition even if the physical port is ok?

 

Trying to communicate to my manager exactly how to test and what conditions will initiate a failover when using Link Monitor only.

 


@OMatlock wrote:

 

Focusing on Link monitor for now.

 

So if our ISP (or other) has a problem, we would prefer to be notified, but not failover.

 

We only want a failover if one of our physical ports go down on our firewall.

 

Just talking about Link monitor, if I pull the network cable on an interface does it constitute a failover condition even if the physical port is ok?

 

Trying to communicate to my manager exactly how to test and what conditions will initiate a failover when using Link Monitor only.

 


Link Monitor looks at the physical state of the interface, just as if you were looking at a network switch.  If the port is seen as up it's "Up," if it's down it's "down."

 

Link monitoring doesn't do a "hardware analysis" so to speak it merely says if the port is "up or down."  If you're not wanting ANY action to be taken; just merely alerting of the change, then your best bet is a NMS tool like Solarwinds.

 

If you configure a "link monitoring" condition it will trigger a failover of your firewall based upon the condition parameters you set.

 

To be clear when you "pull the cable from the port" it's not fine, it's down.  Now if a port being down on your firewall is fine maybe that works in your environment, but from a status perspective in the firewall most admins wouldn't consider that to not be "ok."

@OMatlock I agree with @Brandon_Wertz 's comment.

 

Unfortunately, you cannot configure the HA to only alert with no failover action, which in my opinion makes sense, because the whole idea of having an HA is to avoid traffic interruption in case one of the devices in the HA pair fails. The way you are describing what you intend to achieve, you want some sort of cold standby where a failover is performed manually if you understand it as necessary.

 

From a link monitoring perpsective if you only care about the physical connectivity such as cable being pulled or similar event, that's ok although most administrators would like to have physical and logial monitoring, in case either one of those go wrong.

 

From a monitoring perspective, as @Brandon_Wertz mentioned, your best bet is a NMS tool like Solarwinds, but it will only provide you the alert, and not take any action, which means that if you don't configure the HA to failover, your users will have no access until you manually perform a failover, so my recommendation is that you configure the HA for automatic failover between the pair and use link monitoring and and monitoring group.

 

Finally, in order to avoid unecessary failovers, I would include in the Link Monitoring and Monitoring Group only the physical interfaces and IP addresses that are critical to me. Meaning, only the components that I really care about having a failover event triggered. For example, if you don't want a failover to be triggered because your 3rd party is down, then I would suggest to not include the interface supporting them in any of the Link Monitoring or Monitoring Group.

 

I hope it makes sense. My two cents.

 

 

so to further this

 

if you monitored

link on your side and link on their side

then theoretically you would choose all

meaning both sides

 

path can include something further down the 'path'

ie monitor a printer in an office - if path 1 went down failure could occur

the thinking is the path triggers the fail over

 

but in the end you are really just watching your own link in your example

 

so fail or not

or additional scripting could monitor degradation also

Thanks for the feedback folks.  I probably did not explain my questions very well and made it confusing (for me).

 

I will digest all this info and close this thread.

 

Thanks again!

  • 1 accepted solution
  • 6541 Views
  • 8 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!