Support Support Downloads Knowledge Base Service Request Manager My Juniper Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

[EX/QFX] How to change configuration in response to communication loss using event-options

0

0

Article ID: KB35245 KB Last Updated: 28 Nov 2019Version: 1.0
Summary:

This article describes how to change configuration on the switch in case of communication loss. To complete this task, two separate events must be configured:

  • One to move the static gateway from 192.10.10.1 to 10.50.8.1 during the communication loss (name "Move_To_Main_ISP")
  • One to revert the changes (name "Move_To_Second_ISP")

Please note that having both events active consecutively may consume excessive CPU, so only one should be enabled at the time.

Solution:
  1. The first step requires to set RPM as a mechanism to detect if pings to target IP "10.50.8.1" stop working. For this, a successive probe loss count of 5 was selected, using a ICMP traffic flow as the probe type:

    set services rpm probe MainLinkDown test Check1 probe-type icmp-ping
    set services rpm probe MainLinkDown test Check1 target address 10.50.8.1
    set services rpm probe MainLinkDown test Check1 probe-interval 5
    set services rpm probe MainLinkDown test Check1 thresholds successive-loss 5
  2. The second step is to indicate how the switch will react to the ICMP loss by matching attribute "ping_test_failed" with RPM "MainLinkDown" as the test owner. 

    set event-options policy Move_To_Second_ISP events ping_test_failed
    set event-options policy Move_To_Second_ISP within 30 trigger on
    set event-options policy Move_To_Second_ISP within 30 trigger 2
    set event-options policy Move_To_Second_ISP attributes-match ping_test_failed.test-owner matches MainLinkDown

    You then need to indicate the configuration changes needed in case the IP is no longer reachable. It also requires to disable this policy and its related RPM probe before enabling the second policy (which will monitor if connectivity with the target IP is reestablished):

    set event-options policy Move_To_Second_ISP then change-configuration commands "set routing-options static route 0.0.0.0/0 next-hop 192.10.10.1"
    set event-options policy Move_To_Second_ISP then change-configuration commands "delete routing-options static route 0.0.0.0/0 next-hop 10.50.8.1"
    set event-options policy Move_To_Second_ISP then change-configuration commands "deactivate event-options policy Move_To_Second_ISP"
    set event-options policy Move_To_Second_ISP then change-configuration commands "deactivate services rpm probe MainLinkDown"
    set event-options policy Move_To_Second_ISP then change-configuration commands "activate event-options policy Move_To_Main_ISP"
    set event-options policy Move_To_Second_ISP then change-configuration commands "activate services rpm probe MainLinkUP"
  3. The third step is to track once ICMP communication with 10.50.8.1 is working again. We increased the number of probes to 10 to ensure stability:

    set services rpm probe MainLinkUP test Check2 probe-type icmp-ping
    set services rpm probe MainLinkUP test Check2 target address 10.50.8.1
    set services rpm probe MainLinkUP test Check2 probe-count 10
    set services rpm probe MainLinkUP test Check2 probe-interval 5
  4. The last step is to indicate the actions taken by the switch once the target IP is reachable again by linking the new event policy with the second RPM using attribute "ping_test_completed". The original policy will be reactivated and the second group disable.

    set event-options policy Move_To_Main_ISP events ping_test_completed
    set event-options policy Move_To_Main_ISP within 120 trigger until
    set event-options policy Move_To_Main_ISP within 120 trigger 20
    set event-options policy Move_To_Main_ISP attributes-match ping_test_completed.test-owner matches MainLinkUP

    set event-options policy Move_To_Main_ISP then change-configuration commands "delete routing-options static route 0.0.0.0/0 next-hop 192.10.10.1"
    set event-options policy Move_To_Main_ISP then change-configuration commands "set routing-options static route 0.0.0.0/0 next-hop 10.50.8.1"
    set event-options policy Move_To_Main_ISP then change-configuration commands "deactivate event-options policy Move_To_Main_ISP"
    set event-options policy Move_To_Main_ISP then change-configuration commands "deactivate services rpm probe MainLinkUP"
    set event-options policy Move_To_Main_ISP then change-configuration commands "activate event-options policy Move_To_Second_ISP"
    set event-options policy Move_To_Main_ISP then change-configuration commands "activate services rpm probe MainLinkDown"

    To avoid high CPU, the second policy and RPM probe must be disabled since the first commit. They will be automatically enabled only if the target IP is unreachable:

    deactivate event-options policy Move_To_Main_ISP
    deactivate services rpm probe MainLinkUP

Full configuration: 

show configuration services
rpm {
    probe MainLinkDown {
        test Check1 {
            probe-type icmp-ping;
            target address 10.50.8.1;
            probe-interval 5;
            thresholds {
                successive-loss 5;
            }
        }
    }
    inactive: probe MainLinkUP {
        test Check2 {
            probe-type icmp-ping;
            target address 10.50.8.1;
            probe-count 10;
            probe-interval 5;
        }
    }
}

show configuration event-options
policy Move_To_Second_ISP {
    events ping_test_failed;
    within 30 {
        trigger on 2;
    }
    attributes-match {
        ping_test_failed.test-owner matches MainLinkDown;
    }
    then {
        change-configuration {
            commands {
                "set routing-options static route 0.0.0.0/0  next-hop 192.10.10.1";
                "delete routing-options static route 0.0.0.0/0  next-hop 10.50.8.1";
                "deactivate event-options policy Move_To_Second_ISP";
                "deactivate services rpm probe MainLinkDown";
                "activate event-options policy Move_To_Main_ISP";
                "activate services rpm probe MainLinkUP";
            }
        }
    }
}

inactive: policy Move_To_Main_ISP {
    events ping_test_completed;
    within 120 {
        trigger until 20;
    }
    attributes-match {
        ping_test_completed.test-owner matches MainLinkUP;
    }
    then {
        change-configuration {
            commands {
                "delete routing-options static route 0.0.0.0/0  next-hop 192.10.10.1";
                "set routing-options static route 0.0.0.0/0 next-hop 10.50.8.1";
                "deactivate event-options policy Move_To_Main_ISP";
                "deactivate services rpm probe MainLinkUP";
                "activate event-options policy Move_To_Second_ISP";
                "activate services rpm probe MainLinkDown";
            }
        }
    }
}

 

Results

 To check results, you can run "show services rpm probe-results" which will indicate if the probe fails overtime. If so, the configuration will change according to your specifications:


 show services rpm probe-results
    Owner: MainLinkDown, Test: Check1

    Results over current test:
      Probes sent: 1, Probes received: 1, Loss percentage: 0.000000
      Measurement: Round trip time
        Samples: 1, Minimum: 11159 usec, Maximum: 11159 usec,
        Average: 11159 usec, Peak to peak: 0 usec, Stddev: 0 usec,
        Sum: 11159 usec

show configuration routing-options
static {
    route 0.0.0.0/0 next-hop 10.50.8.1;
}

show services rpm probe-results
    Owner: MainLinkUP, Test: Check2
    Target address: 10.50.8.1, Probe type: icmp-ping, Icmp-id: 20, Test size: 10 probes
    Probe results:
      Request timed out, Wed Nov  6 17:13:55 2019
    Results over current test:
      Probes sent: 3, Probes received: 0, Loss percentage: 100.000000
    

show configuration routing-options
static {
    route 0.0.0.0/0 next-hop 192.10.10.1;
}

 
Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Security Alerts and Vulnerabilities

Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search