Knowledge Search


×
 

Firewall running NSRP is in the (I) Inoperable state. Check settings and fix condition.

  [KB11451] Show Article Properties


Summary:
"Track-ip" option is set and causing device to be Inoperable. Check track-ip status and settings to fix condition.
Symptoms:
Symptoms:
Solution:

The following commands are helpful to identify the NSRP monitoring settings and condition:

get nsrp
get nsrp monitor (also included in 'get nsrp' output)
get nsrp monitor interface
get nsrp monitor zone
get nsrp track-ip
get config | include nsrp

If you have already identified which NSRP monitor condition has failed, you can jump directly to troubleshooting the issue:

If not, here is a quick review on how the monitoring weights and thresholds work. Consider the following "get nsrp monitor" output example:

fw(I)-> get nsrp monitor
device based nsrp monitoring threshold: 255, weighted sum: 450, failed
device based nsrp monitor interface: ethernet3(weight 150, DOWN)
device based nsrp monitor zone: DMZ(weight 200, DOWN)
device based nsrp track ip: (weight: 100, enabled, failed)

The NSRP Inoperable condition is triggered when the overall NSRP monitoring "weighted sum" breaches the "NSRP monitoring threshold". The default threshold is 255.
The "weighted sum" (in this case, 450) is the total of the "NSRP monitor interface" failed weight (150), the "NSRP monitor zone" failed weight (200), and the Track-IP failed weight (100), which are derived from the following:

  • The Interface failed weight is made up of the total weights of the failed, monitored interfaces
  • The Zone failed weight is made up of the total weights of the failed, monitored zones (triggered when all interfaces belonging to a zone are DOWN).
  • The Track-IP weight is applied a little differently. The weight value is constant (but configurable) value and is only included when the sum of the failed track-ip weights breach the track-ip threshold. These are visible from the "get nsrp track-ip" output (below)..

ns208(I)-> get nsrp track-ip
ip address      interval threshold wei  interface  meth fail-count success-rate
1.1.1.1                1         3  60 auto        ping          0 49%
1.1.1.2                1         3  60 auto        ping          0 69%
1.1.1.3                1         3  60 auto        ping        214 0%
1.1.1.4                1         3  60 auto        ping         52 0%
failure weight: 100, threshold: 110, failed: 2 ip(s) failed, weighted sum = 120

 

To identify why the NSRP monitoring is in a failed state, look at the "get nsrp monitor" output. In the example output above, the top line shows the threshold (255), the weighted sum (450), and the state (failed). So you can see NSRP monitoring is failed because the weighted sum is greater than (or equal to) the threshold value. But why is this so?

Look at the individual weights to identify which are contributing to the total. In this case all three components (zones, interfaces, track-ip) are non-zero, so all three would need to be investigated. Are any of these unexpected results?

Monitoring interfaces? 

  • Run the command "get nsrp monitor interface" to see which specific interfaces are attributing to the problem.
    Should these interfaces UP?  If so, check cabling and check the connected device.
  • Are you monitoring interfaces that are not in use?  If so, remove the setting:  unset nsrp monitor interface <int name>
  • If the correct interfaces are monitored, and are Down for known reasons, is the weighting is too high?  If so, adjust the weights to suit your requirements.

For additional information on fixing NSRP Monitor Interface condition, see KB11327 - How do I fix if monitoring interfaces with NSRP.

Monitoring zones?

  • Run the command "get nsrp monitor zone" to see which zones are attributing to the problem.
  • Are you monitoring the wrong zone?
  • Are the zone weights incorrect?

For additional information on fixing NSRP Monitor Zone condition, see KB11331 - How do I fix if monitoring zone with NSRP.

Monitoring track-ip?

  • Run the command "get nsrp track-ip" (see above sample) to see which hosts are attributing to the problem.
  • Is the host expected to be reachable?  If yes, is the host is up?  
  • Can you ping the host from the firewall?
  • Is the firewall routing to the host correct?
  • Is the track-ip setting specifying the wrong interface?  If not, the host is unreachable (it is expected down in NSRP).
  • Is the weighting too high?


Other areas to check.

The Event Log should contain any NSRP tracking or interface events. Check the event log for recent NSRP history.

ns208(M)-> get event incl track
Date       Time     Module Level  Type Description
2008-04-12 02:30:17 system crit  00062 Track IP IP address 1.1.1.1 failed.
2008-04-12 02:30:16 system crit  00062 No interface/route enables the Track
                                       IP IP address 1.1.1.1 to be transmitted.

Check the NSRP monitoring status on both boxes. The NSRP settings are excluded from NSRP synchronization, so the monitoring and tracking configuration needs to be done on both devices. Generally these will be the same, but not always so. Check the configuration of both cluster members to verify the settings are correct.

"get config | include nsrp" output from both devices is a good way to verify the NSRP configuration

 

Related Links: