{"id":219,"date":"2018-02-28T01:52:29","date_gmt":"2018-02-28T01:52:29","guid":{"rendered":"https:\/\/www.kuncar.net\/blog\/?p=219"},"modified":"2018-11-01T00:05:50","modified_gmt":"2018-11-01T00:05:50","slug":"sla-probe-ip-monitoring-default-route-withdrawal","status":"publish","type":"post","link":"https:\/\/www.kuncar.net\/blog\/2018\/sla-probe-ip-monitoring-default-route-withdrawal\/","title":{"rendered":"SLA probe IP-monitoring with a default route withdrawal"},"content":{"rendered":"<p style=\"text-align: justify;\"><span style=\"font-size: 14px; font-family: arial, helvetica, sans-serif;\"><img loading=\"lazy\" decoding=\"async\" class=\"alignleft size-thumbnail wp-image-213\" src=\"https:\/\/www.kuncar.net\/blog\/wp-content\/uploads\/2018\/02\/juniper_logo2-150x150.png\" alt=\"\" width=\"150\" height=\"150\" srcset=\"https:\/\/www.kuncar.net\/blog\/wp-content\/uploads\/2018\/02\/juniper_logo2-150x150.png 150w, https:\/\/www.kuncar.net\/blog\/wp-content\/uploads\/2018\/02\/juniper_logo2-100x100.png 100w, https:\/\/www.kuncar.net\/blog\/wp-content\/uploads\/2018\/02\/juniper_logo2.png 195w\" sizes=\"auto, (max-width: 150px) 100vw, 150px\" \/>When an SRX is your wan facing router\/firewall you might want to continuously test your connectivity. That is when the RPM probes do come in handy. The RPM probes are very similar to ip-sla from cisco but way more limited. On their own they just provide statistics which is nice but not very helpful.\u00a0<\/span><span style=\"font-size: 14px; font-family: arial, helvetica, sans-serif;\">Juniper also has a feature called ip-monitoring that works in conjunction with the rpm probes and can take a result of an rpm probe and take some action on it.<\/span><\/p>\n<p style=\"text-align: justify;\"><span style=\"font-size: 14px; font-family: arial, helvetica, sans-serif;\"> Unfortunately the actions it can do are extremely limited. <\/span><\/p>\n<ul class=\"ili-indent\">\n<li style=\"text-align: justify;\"><span style=\"font-size: 14px; font-family: arial, helvetica, sans-serif;\">The first is to down an interface which depends on implementation might or might not recover. e.g. if you down a lo0 and you rpm is on a physical interface it will autorecover if it is on physical interface you use for wan it will break the probe. <\/span><\/li>\n<li style=\"text-align: justify;\"><span style=\"font-size: 14px; font-family: arial, helvetica, sans-serif;\">The second action it can take is to insert a new route in a specific routing table. This is bit more useful but has fairly limited use. The typical example would be to add default route to a secondary srx as described <a href=\"https:\/\/kb.juniper.net\/InfoCenter\/index?page=content&amp;id=KB25052\" target=\"_blank\" rel=\"nofollow noopener\">here<\/a>. <\/span><\/li>\n<li style=\"text-align: justify;\"><span style=\"font-size: 14px; font-family: arial, helvetica, sans-serif;\">The last option is to set metric to a newly added route but that never worked for me. As you can see the ip-monitoring is very limited and not very flexible.<\/span><\/li>\n<\/ul>\n<p style=\"text-align: justify;\"><span style=\"font-family: arial, helvetica, sans-serif; font-size: 14px;\">The issue is if you start using routing instances for the wan interfaces. Your internet routing instance would have only 3 routes &#8211; the interface \/32 the \/31 p2p and the static default to your ISP. You would import the (usually) static route into your internal routing instance. The import would fail if you have a direct failure on the p2p link but if you have indirect failure scenario then the import would always work and your router will start blackholing traffic. The obvious solution would be to withdraw the route before it is being even imported to the internal routing instance but that is not possible due to limitations of ip-monitoring function.\u00a0<\/span><\/p>\n<h4><span style=\"font-family: arial, helvetica, sans-serif; font-size: 14px;\">There are three possible solutions in this situation.<\/span><\/h4>\n<ul class=\"ili-indent\">\n<li style=\"text-align: justify;\"><span style=\"font-family: arial, helvetica, sans-serif; font-size: 14px;\">The first one it so bring the wan interface down &#8211; this will make the default route unavailable removing it from the routing table and consequently removing it from the route importing. The main issue is that this situation will never autorecover.<\/span><\/li>\n<li style=\"text-align: justify;\"><span style=\"font-family: arial, helvetica, sans-serif; font-size: 14px;\">The first one is to install a bogus interface route in the internal routing instance and write a routing policy that would filter the default route from the routing table. This is bit cumbersome and introduces a non-existent route into the routing which might have unforeseen consequences.<\/span><\/li>\n<li><span style=\"font-size: 14px; font-family: arial, helvetica, sans-serif;\">The last and cleanest solution is introduction of a prefered route with a different metric and use a routing policy on import between the routing instances and deny the import if the specific metric is being matched.<\/span><\/li>\n<\/ul>\n<h4><span style=\"font-family: arial, helvetica, sans-serif; font-size: 14px;\">Topology<\/span><\/h4>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignleft size-full wp-image-224\" src=\"https:\/\/www.kuncar.net\/blog\/wp-content\/uploads\/2018\/02\/failover.png\" alt=\"\" width=\"808\" height=\"523\" srcset=\"https:\/\/www.kuncar.net\/blog\/wp-content\/uploads\/2018\/02\/failover.png 808w, https:\/\/www.kuncar.net\/blog\/wp-content\/uploads\/2018\/02\/failover-150x97.png 150w, https:\/\/www.kuncar.net\/blog\/wp-content\/uploads\/2018\/02\/failover-300x194.png 300w, https:\/\/www.kuncar.net\/blog\/wp-content\/uploads\/2018\/02\/failover-768x497.png 768w\" sizes=\"auto, (max-width: 767px) 89vw, (max-width: 1000px) 54vw, (max-width: 1071px) 543px, 580px\" \/><\/p>\n<h4><span style=\"font-family: arial, helvetica, sans-serif; font-size: 14px;\">Configuration<\/span><\/h4>\n<ul class=\"ili-indent\">\n<li><span style=\"font-family: arial, helvetica, sans-serif; font-size: 14px;\">Configure the RPM probe and IP monitoring<\/span><\/li>\n<\/ul>\n<p style=\"text-align: justify;\"><span style=\"font-family: arial, helvetica, sans-serif; font-size: 14px;\">The RPM probe is pretty much box standard and is not very aggressive so the fail-over is rather slow. The timers and other parameters of the probe should be tweaked to better values. Also for the test purpose I am pinging the opposite interface of the p2p link to the provider which is obviously not a good place to test against in real life scenario as it kinda beats the purpose of the whole setup &#8211; but in lab environment this is sufficient.<\/span><\/p>\n<pre>set services rpm probe wan_test test uplink_test target address 1.1.1.1\r\nset services rpm probe wan_test test uplink_test probe-count 3\r\nset services rpm probe wan_test test uplink_test probe-interval 10\r\nset services rpm probe wan_test test uplink_test test-interval 5\r\nset services rpm probe wan_test test uplink_test source-address 1.1.1.2\r\nset services rpm probe wan_test test uplink_test routing-instance ri_internet\r\nset services rpm probe wan_test test uplink_test thresholds successive-loss 3\r\nset services rpm probe wan_test test uplink_test thresholds total-loss 3\r\nset services rpm probe wan_test test uplink_test destination-interface ge-0\/0\/0.0\r\nset services rpm probe wan_test test uplink_test next-hop 1.1.1.1\r\nset services ip-monitoring policy uplink_failure_detection match rpm-probe wan_test set services ip-monitoring policy uplink_failure_detection then preferred-route routing-instances ri_internet route 0.0.0.0\/0 next-hop 1.1.1.1\r\n<\/pre>\n<ul class=\"ili-indent\">\n<li><span style=\"font-family: arial, helvetica, sans-serif; font-size: 14px;\">resulting config<\/span><\/li>\n<\/ul>\n<pre>rpm {\r\n probe wan_test {\r\n   test uplink_test {\r\n     target address 1.1.1.1;\r\n     probe-count 3;\r\n     probe-interval 10;\r\n     test-interval 5;\r\n     source-address 1.1.1.2;\r\n     routing-instance ri_internet;\r\n     thresholds {\r\n       successive-loss 3;\r\n       total-loss 3;\r\n      }\r\n     destination-interface ge-0\/0\/5.0;\r\n     next-hop 1.1.1.1;\r\n    }\r\n  }\r\n}\r\nip-monitoring {\r\n policy uplink_failure_detection {\r\n   match {\r\n     rpm-probe wan_test;\r\n   }\r\n   then {\r\n     preferred-route {\r\n       routing-instances ri_internet {\r\n         route 0.0.0.0\/0 {\r\n         next-hop 1.1.1.1;\r\n       }\r\n      }\r\n     }\r\n    }\r\n  }\r\n}<\/pre>\n<p style=\"text-align: justify;\"><span style=\"font-size: 14px; font-family: arial, helvetica, sans-serif;\">The action taken by the ip monitoring is to inject a preferred default route in the routing instance ri_internet\u00a0 with the same next-hop. The ip-monitoring action will do this on rpm probe failure the difference from the normal static route is that this new route has metric2 with a value of 0 normal routes do no use this metric so it is great thing to match on with the routing policy.<\/span><\/p>\n<ul class=\"ili-indent\">\n<li><span style=\"font-family: arial, helvetica, sans-serif; font-size: 14px;\">Checking the status<\/span><\/li>\n<\/ul>\n<pre>root@kw-core-wan1&gt; show services ip-monitoring status\r\n\r\nPolicy - uplink_failure_detection (Status: PASS)\r\n RPM Probes:\r\n Probe name Test Name Address Status\r\n ---------------------- --------------- ---------------- ---------\r\n wan_test               uplink_test     1.1.1.1          PASS\r\n Route-Action:\r\n route-instance route next-hop state\r\n ----------------- ----------------- ---------------- -------------\r\n ri_internet       0.0.0.0\/0         1.1.1.1          NOT-APPLIED<\/pre>\n<ul class=\"ili-indent\">\n<li><span style=\"font-family: arial, helvetica, sans-serif; font-size: 14px;\">The routing table in ri_internet<\/span><\/li>\n<\/ul>\n<pre>root@srx&gt; show route table ri_internet.inet.0\r\n\r\nri_internet.inet.0: 3 destinations, 4 routes (3 active, 0 holddown, 0 hidden)\r\n+ = Active Route, - = Last Active, * = Both\r\n\r\n0.0.0.0\/0  *[Static\/5] 00:03:26, metric 5\r\n            &gt; to 1.1.1.1 via ge-0\/0\/5.0\r\n1.1.1.1\/30 *[Direct\/0] 01:23:12\r\n            &gt; via ge-0\/0\/5.0\r\n1.1.1.2\/32 *[Local\/0] 01:23:12\r\n            Local via ge-0\/0\/5.0<\/pre>\n<ul class=\"ili-indent\">\n<li><span style=\"font-family: arial, helvetica, sans-serif; font-size: 14px;\">write the import policy<\/span><\/li>\n<\/ul>\n<p style=\"text-align: justify;\"><span style=\"font-size: 14px; font-family: arial, helvetica, sans-serif;\">For the import between the ri_internet and ri_internal I an using the instance import function which allows to import routes between instances through policy. This allows for flexibility on what to import an how without the need to use RIB groups or running a routing protocol in the ri_internet.<\/span><\/p>\n<pre>term t_reject_metric2 {\r\n   from {\r\n         instance ri_internet;\r\n         protocol static;\r\n         metric2 0;\r\n         route-filter 0.0.0.0\/0 exact;\r\n        }\r\n   then reject;\r\n }\r\nterm t_a_metric_5 {\r\n   from {\r\n         instance ri_internet;\r\n         protocol static;\r\n         metric 5;\r\n         route-filter 0.0.0.0\/0 exact;\r\n        }\r\n   then accept;\r\n}<\/pre>\n<p><span style=\"font-family: arial, helvetica, sans-serif; font-size: 14px;\">Here I should explain the policy a bit as it is crucial to the whole setup. <\/span><\/p>\n<p style=\"text-align: justify;\"><span style=\"font-family: arial, helvetica, sans-serif; font-size: 14px;\">The first term is matching the default route to the same next-hop but with metric2 and action of &#8220;reject&#8221; so if the preferred default appears in the routing table and has metric2 value 0 this term will match and no route will be imported into the ri_inside.inet0 routing table. If this route doesn&#8217;t exist the second term will be evaluated and that will only match the live static default route to the ISP.\u00a0<\/span><span style=\"font-family: arial, helvetica, sans-serif; font-size: 14px;\">This scenario will auto-recover and in effect withdraws the default from the routing instance in case of uplink failure.<\/span><\/p>\n<h4><span style=\"font-family: arial, helvetica, sans-serif; font-size: 14px;\">Failure\u00a0<\/span><\/h4>\n<pre>root@srx&gt; show services ip-monitoring status\r\n\r\nPolicy - uplink_failure_detection (Status: FAIL)\r\n RPM Probes:\r\n Probe name Test Name Address Status\r\n ---------------------- --------------- ---------------- ---------\r\n wan_test               uplink_test     1.1.1.1          FAIL\r\n Route-Action:\r\n route-instance route next-hop state\r\n ----------------- ----------------- ---------------- -------------\r\n ri_internet       0.0.0.0\/0         1.1.1.1          APPLIED<\/pre>\n<p><span style=\"font-family: arial, helvetica, sans-serif; font-size: 14px;\">The routing table in ri_internet<\/span><\/p>\n<pre>root@srx&gt; show route table ri_internet.inet.0\r\n\r\nri_internet.inet.0: 3 destinations, 4 routes (3 active, 0 holddown, 0 hidden)\r\n+ = Active Route, - = Last Active, * = Both\r\n\r\n0.0.0.0\/0  *[Static\/1] 00:03:26, metric2 0\r\n            &gt; to 1.1.1.1 via ge-0\/0\/5.0\r\n            [Static\/5] 01:23:12, metric 5\r\n            &gt; to 1.1.1.1 via ge-0\/0\/5.0\r\n1.1.1.1\/30 *[Direct\/0] 01:23:12\r\n            &gt; via ge-0\/0\/5.0\r\n1.1.1.2\/32 *[Local\/0] 01:23:12\r\n            Local via ge-0\/0\/5.0<\/pre>\n","protected":false},"excerpt":{"rendered":"<p>When an SRX is your wan facing router\/firewall you might want to continuously test your connectivity. That is when the RPM probes do come in handy. The RPM probes are very similar to ip-sla from cisco but way more limited. On their own they just provide statistics which is nice but not very helpful.\u00a0Juniper also &hellip; <\/p>\n<p class=\"link-more\"><a href=\"https:\/\/www.kuncar.net\/blog\/2018\/sla-probe-ip-monitoring-default-route-withdrawal\/\" class=\"more-link\">Continue reading<span class=\"screen-reader-text\"> &#8220;SLA probe IP-monitoring with a default route withdrawal&#8221;<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7,5],"tags":[],"class_list":["post-219","post","type-post","status-publish","format-standard","hentry","category-juniper","category-networks"],"_links":{"self":[{"href":"https:\/\/www.kuncar.net\/blog\/wp-json\/wp\/v2\/posts\/219","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kuncar.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kuncar.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kuncar.net\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kuncar.net\/blog\/wp-json\/wp\/v2\/comments?post=219"}],"version-history":[{"count":10,"href":"https:\/\/www.kuncar.net\/blog\/wp-json\/wp\/v2\/posts\/219\/revisions"}],"predecessor-version":[{"id":376,"href":"https:\/\/www.kuncar.net\/blog\/wp-json\/wp\/v2\/posts\/219\/revisions\/376"}],"wp:attachment":[{"href":"https:\/\/www.kuncar.net\/blog\/wp-json\/wp\/v2\/media?parent=219"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kuncar.net\/blog\/wp-json\/wp\/v2\/categories?post=219"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kuncar.net\/blog\/wp-json\/wp\/v2\/tags?post=219"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}