Re: [j-nsp] rpm / ip-monitoring
Hi Mattias, It is still possible to bend it to your will ; ) I may be misunderstanding your topology, but essentially you have a Primary link via a WAN circuit that receives a BGP-sourced default, and a backup ADSL connection that receives a default via DHCP/PPP, and has an IPSEC tunnel back to your head office. Are you trying to move the default route to your IPSEC tunnel interface, or the underlying cheap line? You could try the following: Set up a static default with a high metric (so that it will lose to both DHCP and BGP) via your IPSEC tunnel/underlying link. If the underlying link is not point-to-point (eg: you will need to know the far-side IP), you can point it down your IPSEC tunnel, or anywhere else - it should never actually get used): set routing-options static route 0.0.0.0/0 next-hop at-1/0/0.0 set routing-options static route 0.0.0.0/0 preference 190 Then in your ip-monitoring policy, you can override this dummy route with a better metric than both BGP and DHCP: set services ip-monitoring policy Local-Internet-Test match rpm-probe Internet set services ip-monitoring policy Local-Internet-Test then preferred-route route 0.0.0.0/0 next-hop at-1/0/0.0 set services ip-monitoring policy Local-Internet-Test then preferred-route route 0.0.0.0/0 preferred-metric 1 Now when your test fails (even if BGP does not): inet.0: 49 destinations, 51 routes (49 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[Static/1] 00:13:15, metric2 0 via at-1/0/0.0 [Access-Internal/12] 00:21:45 to 192.168.1.2 via at-1/0/0.0 [BGP/170] 2d 21:51:10, localpref 100 AS path: 65500 I, validation-state: unverified to 172.30.3.2 via ge-0/0/3.0 Cheers, Ben On 29 Aug 2014, at 3:30 am, Mattias Gyllenvarg matt...@gyllenvarg.semailto:matt...@gyllenvarg.se wrote: Even is the default routes are both from dynamic protocols (BGP and DHCP). For a regular static this is perfect. No such luck in this sollution. //Mattias On Thu, Aug 28, 2014 at 4:17 PM, Ben Dale bd...@comlinx.com.aumailto:bd...@comlinx.com.au wrote: Rather than making configuration changes, if you're running recent code (12.1) on branch SRX, have a look at the preferred-route option in ip-monitoring. You can override your default route dynamically based on the RPM failing, without having to override config. The day this is feature (and ip-monitoring in general) is merged back down to mainline Junos will be a glorious one... Cheers, Ben On 28 Aug 2014, at 9:00 pm, Mattias Gyllenvarg matt...@gyllenvarg.semailto:matt...@gyllenvarg.se wrote: I have looked over these and they are the basis of the configuration I am using. The setup is advanced in some senses. The Primary link is a to an IP-VPN running BGP to the mpls cloud of a global operator. So, from there I get a default that I override with a static OR dynamic default to a local Internet connection that also serves as backup via IPsec (BGP on top of that too but peers with a HUB node and not the cloud). As the local internet is just a cheap line, I do not have the luxury of BGP and so must use some other metod like this one. What I would have want is to have the ip-monitor not actually disable the interface and just set the admin-distance for it to the worst level. That way the test would still work as it requests the packet be sent by the exact interface, but no other traffic would take this route unless all other options are down. //Mattias On Thu, Aug 28, 2014 at 10:50 AM, Darren O'Connor darre...@outlook.commailto:darre...@outlook.com wrote: A small topology diagram would help so we could figure out exactly what this interface points to. Not sure if its in the path or not. If it is, then the below comments already state what the problem is. Thanks Darren http://www.mellowd.co.uk/ccie Date: Wed, 27 Aug 2014 17:52:02 -0700 From: gonna...@gmail.commailto:gonna...@gmail.com To: juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net Subject: Re: [j-nsp] rpm / ip-monitoring Instead of disabling the interface, can you just alter routing to avoid that path, but RPM could still test since that interface would still be up? -Mike Gonnason On Wed, Aug 27, 2014 at 5:37 PM, Tyler Christiansen ty...@adap.tvmailto:ty...@adap.tv wrote: Good point. I glossed over that a bit. In that case, you won't even be able to test if it's working or not as you have disabled it (as Andrew points out). I suppose you could write a script that re-enables the interface every hour or twenty four hours or whatever interval, then the RPM probe would just shut it back down if it's not fixing, but that seems a bit of a hassle. --tc On Wed, Aug 27, 2014 at 4:35 PM, Andrew Jones a...@jonesy.com.aumailto:a...@jonesy.com.au wrote: Surely the test will never recover without
Re: [j-nsp] rpm / ip-monitoring
Ben Close but no cigar. The IPsec also receives a default via BGP so that works like a charm. No need for interface routing. The thing is that we use the local line for Internet use, so the primary default route goes out that way. The IPsec is there if the Native VPN line fails. So, what I want this ip-monitor/rpm to do is fail over the local internet to the Native VPN in case the local line is broken some how. Regards Mattias On Fri, Aug 29, 2014 at 12:59 PM, Ben Dale bd...@comlinx.com.au wrote: Hi Mattias, It is still possible to bend it to your will ; ) I may be misunderstanding your topology, but essentially you have a Primary link via a WAN circuit that receives a BGP-sourced default, and a backup ADSL connection that receives a default via DHCP/PPP, and has an IPSEC tunnel back to your head office. Are you trying to move the default route to your IPSEC tunnel interface, or the underlying cheap line? You could try the following: Set up a static default with a high metric (so that it will lose to both DHCP and BGP) via your IPSEC tunnel/underlying link. If the underlying link is not point-to-point (eg: you will need to know the far-side IP), you can point it down your IPSEC tunnel, or anywhere else - it should never actually get used): set routing-options static route 0.0.0.0/0 next-hop at-1/0/0.0 set routing-options static route 0.0.0.0/0 preference 190 Then in your ip-monitoring policy, you can override this dummy route with a better metric than both BGP and DHCP: set services ip-monitoring policy Local-Internet-Test match rpm-probe Internet set services ip-monitoring policy Local-Internet-Test then preferred-route route 0.0.0.0/0 next-hop at-1/0/0.0 set services ip-monitoring policy Local-Internet-Test then preferred-route route 0.0.0.0/0 preferred-metric 1 Now when your test fails (even if BGP does not): inet.0: 49 destinations, 51 routes (49 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[Static/1] 00:13:15, metric2 0 via at-1/0/0.0 [Access-Internal/12] 00:21:45 to 192.168.1.2 via at-1/0/0.0 [BGP/170] 2d 21:51:10, localpref 100 AS path: 65500 I, validation-state: unverified to 172.30.3.2 via ge-0/0/3.0 Cheers, Ben On 29 Aug 2014, at 3:30 am, Mattias Gyllenvarg matt...@gyllenvarg.se wrote: Even is the default routes are both from dynamic protocols (BGP and DHCP). For a regular static this is perfect. No such luck in this sollution. //Mattias On Thu, Aug 28, 2014 at 4:17 PM, Ben Dale bd...@comlinx.com.au wrote: Rather than making configuration changes, if you're running recent code (12.1) on branch SRX, have a look at the preferred-route option in ip-monitoring. You can override your default route dynamically based on the RPM failing, without having to override config. The day this is feature (and ip-monitoring in general) is merged back down to mainline Junos will be a glorious one... Cheers, Ben On 28 Aug 2014, at 9:00 pm, Mattias Gyllenvarg matt...@gyllenvarg.se wrote: I have looked over these and they are the basis of the configuration I am using. The setup is advanced in some senses. The Primary link is a to an IP-VPN running BGP to the mpls cloud of a global operator. So, from there I get a default that I override with a static OR dynamic default to a local Internet connection that also serves as backup via IPsec (BGP on top of that too but peers with a HUB node and not the cloud). As the local internet is just a cheap line, I do not have the luxury of BGP and so must use some other metod like this one. What I would have want is to have the ip-monitor not actually disable the interface and just set the admin-distance for it to the worst level. That way the test would still work as it requests the packet be sent by the exact interface, but no other traffic would take this route unless all other options are down. //Mattias On Thu, Aug 28, 2014 at 10:50 AM, Darren O'Connor darre...@outlook.com wrote: A small topology diagram would help so we could figure out exactly what this interface points to. Not sure if its in the path or not. If it is, then the below comments already state what the problem is. Thanks Darren http://www.mellowd.co.uk/ccie Date: Wed, 27 Aug 2014 17:52:02 -0700 From: gonna...@gmail.com To: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] rpm / ip-monitoring Instead of disabling the interface, can you just alter routing to avoid that path, but RPM could still test since that interface would still be up? -Mike Gonnason On Wed, Aug 27, 2014 at 5:37 PM, Tyler Christiansen ty...@adap.tv wrote: Good point. I glossed over that a bit. In that case, you won't even be able to test if it's working
Re: [j-nsp] rpm / ip-monitoring
Okay, I'm still sure this can be made to work ; ) I'm still a little hazy on your setup though - based on your email: You have a local line which gets an address via DHCP and a default gateway with a preference of 12 You then also receive another default via BGP over an IPSEC tunnel over this same local line interface with a preference of 170 You then have an MPLS service/Native VPN which receives another BGP-sourced default route, presumably also with a preference of 170 If that is the case, configure a static with high preference (170) pointing to your MPLS service/Native VPN, and override this with the lower preference route via your ip-monitoring policy on local-line/Internet failure - it should still work exactly as described, unless I'm missing something else? Ben On 29 Aug 2014, at 7:42 pm, Mattias Gyllenvarg matt...@gyllenvarg.semailto:matt...@gyllenvarg.se wrote: Ben Close but no cigar. The IPsec also receives a default via BGP so that works like a charm. No need for interface routing. The thing is that we use the local line for Internet use, so the primary default route goes out that way. The IPsec is there if the Native VPN line fails. So, what I want this ip-monitor/rpm to do is fail over the local internet to the Native VPN in case the local line is broken some how. Regards Mattias On Fri, Aug 29, 2014 at 12:59 PM, Ben Dale bd...@comlinx.com.aumailto:bd...@comlinx.com.au wrote: Hi Mattias, It is still possible to bend it to your will ; ) I may be misunderstanding your topology, but essentially you have a Primary link via a WAN circuit that receives a BGP-sourced default, and a backup ADSL connection that receives a default via DHCP/PPP, and has an IPSEC tunnel back to your head office. Are you trying to move the default route to your IPSEC tunnel interface, or the underlying cheap line? You could try the following: Set up a static default with a high metric (so that it will lose to both DHCP and BGP) via your IPSEC tunnel/underlying link. If the underlying link is not point-to-point (eg: you will need to know the far-side IP), you can point it down your IPSEC tunnel, or anywhere else - it should never actually get used): set routing-options static route 0.0.0.0/0http://0.0.0.0/0 next-hop at-1/0/0.0 set routing-options static route 0.0.0.0/0http://0.0.0.0/0 preference 190 Then in your ip-monitoring policy, you can override this dummy route with a better metric than both BGP and DHCP: set services ip-monitoring policy Local-Internet-Test match rpm-probe Internet set services ip-monitoring policy Local-Internet-Test then preferred-route route 0.0.0.0/0http://0.0.0.0/0 next-hop at-1/0/0.0 set services ip-monitoring policy Local-Internet-Test then preferred-route route 0.0.0.0/0http://0.0.0.0/0 preferred-metric 1 Now when your test fails (even if BGP does not): inet.0: 49 destinations, 51 routes (49 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0http://0.0.0.0/0 *[Static/1] 00:13:15, metric2 0 via at-1/0/0.0 [Access-Internal/12] 00:21:45 to 192.168.1.2 via at-1/0/0.0 [BGP/170] 2d 21:51:10, localpref 100 AS path: 65500 I, validation-state: unverified to 172.30.3.2 via ge-0/0/3.0 Cheers, Ben On 29 Aug 2014, at 3:30 am, Mattias Gyllenvarg matt...@gyllenvarg.semailto:matt...@gyllenvarg.se wrote: Even is the default routes are both from dynamic protocols (BGP and DHCP). For a regular static this is perfect. No such luck in this sollution. //Mattias On Thu, Aug 28, 2014 at 4:17 PM, Ben Dale bd...@comlinx.com.aumailto:bd...@comlinx.com.au wrote: Rather than making configuration changes, if you're running recent code (12.1) on branch SRX, have a look at the preferred-route option in ip-monitoring. You can override your default route dynamically based on the RPM failing, without having to override config. The day this is feature (and ip-monitoring in general) is merged back down to mainline Junos will be a glorious one... Cheers, Ben On 28 Aug 2014, at 9:00 pm, Mattias Gyllenvarg matt...@gyllenvarg.semailto:matt...@gyllenvarg.se wrote: I have looked over these and they are the basis of the configuration I am using. The setup is advanced in some senses. The Primary link is a to an IP-VPN running BGP to the mpls cloud of a global operator. So, from there I get a default that I override with a static OR dynamic default to a local Internet connection that also serves as backup via IPsec (BGP on top of that too but peers with a HUB node and not the cloud). As the local internet is just a cheap line, I do not have the luxury of BGP and so must use some other metod like this one. What I would have want is to have the ip-monitor not actually disable the interface and just set the admin-distance for it to the worst level. That way the test would still work as it
Re: [j-nsp] rpm / ip-monitoring
Ben, The BGP selects native over IPsec via local-pref (just a note in this context). That may work. I will try to describe your idea in my own words. Add a lurking static default to the MPLS-VPN, put it on steroids when ip-monitor fails? Sounds workable and not to ugly eighter. Will look intt this. //Mattias On Fri, Aug 29, 2014 at 2:05 PM, Ben Dale bd...@comlinx.com.au wrote: Okay, I'm still sure this can be made to work ; ) I'm still a little hazy on your setup though - based on your email: You have a local line which gets an address via DHCP and a default gateway with a preference of 12 You then also receive another default via BGP over an IPSEC tunnel over this same local line interface with a preference of 170 You then have an MPLS service/Native VPN which receives another BGP-sourced default route, presumably also with a preference of 170 If that is the case, configure a static with high preference (170) pointing to your MPLS service/Native VPN, and override this with the lower preference route via your ip-monitoring policy on local-line/Internet failure - it should still work exactly as described, unless I'm missing something else? Ben On 29 Aug 2014, at 7:42 pm, Mattias Gyllenvarg matt...@gyllenvarg.se wrote: Ben Close but no cigar. The IPsec also receives a default via BGP so that works like a charm. No need for interface routing. The thing is that we use the local line for Internet use, so the primary default route goes out that way. The IPsec is there if the Native VPN line fails. So, what I want this ip-monitor/rpm to do is fail over the local internet to the Native VPN in case the local line is broken some how. Regards Mattias On Fri, Aug 29, 2014 at 12:59 PM, Ben Dale bd...@comlinx.com.au wrote: Hi Mattias, It is still possible to bend it to your will ; ) I may be misunderstanding your topology, but essentially you have a Primary link via a WAN circuit that receives a BGP-sourced default, and a backup ADSL connection that receives a default via DHCP/PPP, and has an IPSEC tunnel back to your head office. Are you trying to move the default route to your IPSEC tunnel interface, or the underlying cheap line? You could try the following: Set up a static default with a high metric (so that it will lose to both DHCP and BGP) via your IPSEC tunnel/underlying link. If the underlying link is not point-to-point (eg: you will need to know the far-side IP), you can point it down your IPSEC tunnel, or anywhere else - it should never actually get used): set routing-options static route 0.0.0.0/0 next-hop at-1/0/0.0 set routing-options static route 0.0.0.0/0 preference 190 Then in your ip-monitoring policy, you can override this dummy route with a better metric than both BGP and DHCP: set services ip-monitoring policy Local-Internet-Test match rpm-probe Internet set services ip-monitoring policy Local-Internet-Test then preferred-route route 0.0.0.0/0 next-hop at-1/0/0.0 set services ip-monitoring policy Local-Internet-Test then preferred-route route 0.0.0.0/0 preferred-metric 1 Now when your test fails (even if BGP does not): inet.0: 49 destinations, 51 routes (49 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[Static/1] 00:13:15, metric2 0 via at-1/0/0.0 [Access-Internal/12] 00:21:45 to 192.168.1.2 via at-1/0/0.0 [BGP/170] 2d 21:51:10, localpref 100 AS path: 65500 I, validation-state: unverified to 172.30.3.2 via ge-0/0/3.0 Cheers, Ben On 29 Aug 2014, at 3:30 am, Mattias Gyllenvarg matt...@gyllenvarg.se wrote: Even is the default routes are both from dynamic protocols (BGP and DHCP). For a regular static this is perfect. No such luck in this sollution. //Mattias On Thu, Aug 28, 2014 at 4:17 PM, Ben Dale bd...@comlinx.com.au wrote: Rather than making configuration changes, if you're running recent code (12.1) on branch SRX, have a look at the preferred-route option in ip-monitoring. You can override your default route dynamically based on the RPM failing, without having to override config. The day this is feature (and ip-monitoring in general) is merged back down to mainline Junos will be a glorious one... Cheers, Ben On 28 Aug 2014, at 9:00 pm, Mattias Gyllenvarg matt...@gyllenvarg.se wrote: I have looked over these and they are the basis of the configuration I am using. The setup is advanced in some senses. The Primary link is a to an IP-VPN running BGP to the mpls cloud of a global operator. So, from there I get a default that I override with a static OR dynamic default to a local Internet connection that also serves as backup via IPsec (BGP on top of that too but peers with a HUB node and not the cloud). As the local internet is just a cheap line, I do not
Re: [j-nsp] rpm / ip-monitoring
Typical, looks like it will work fine with a DHCP but not a static as I can not have 2 defaults with different pref. I can probably make that work but a solution that works on both would be preferred. :P Anyway, thank you for pointing this out. //Mattias On Fri, Aug 29, 2014 at 2:46 PM, Mattias Gyllenvarg matt...@gyllenvarg.se wrote: Ben, The BGP selects native over IPsec via local-pref (just a note in this context). That may work. I will try to describe your idea in my own words. Add a lurking static default to the MPLS-VPN, put it on steroids when ip-monitor fails? Sounds workable and not to ugly eighter. Will look intt this. //Mattias On Fri, Aug 29, 2014 at 2:05 PM, Ben Dale bd...@comlinx.com.au wrote: Okay, I'm still sure this can be made to work ; ) I'm still a little hazy on your setup though - based on your email: You have a local line which gets an address via DHCP and a default gateway with a preference of 12 You then also receive another default via BGP over an IPSEC tunnel over this same local line interface with a preference of 170 You then have an MPLS service/Native VPN which receives another BGP-sourced default route, presumably also with a preference of 170 If that is the case, configure a static with high preference (170) pointing to your MPLS service/Native VPN, and override this with the lower preference route via your ip-monitoring policy on local-line/Internet failure - it should still work exactly as described, unless I'm missing something else? Ben On 29 Aug 2014, at 7:42 pm, Mattias Gyllenvarg matt...@gyllenvarg.se wrote: Ben Close but no cigar. The IPsec also receives a default via BGP so that works like a charm. No need for interface routing. The thing is that we use the local line for Internet use, so the primary default route goes out that way. The IPsec is there if the Native VPN line fails. So, what I want this ip-monitor/rpm to do is fail over the local internet to the Native VPN in case the local line is broken some how. Regards Mattias On Fri, Aug 29, 2014 at 12:59 PM, Ben Dale bd...@comlinx.com.au wrote: Hi Mattias, It is still possible to bend it to your will ; ) I may be misunderstanding your topology, but essentially you have a Primary link via a WAN circuit that receives a BGP-sourced default, and a backup ADSL connection that receives a default via DHCP/PPP, and has an IPSEC tunnel back to your head office. Are you trying to move the default route to your IPSEC tunnel interface, or the underlying cheap line? You could try the following: Set up a static default with a high metric (so that it will lose to both DHCP and BGP) via your IPSEC tunnel/underlying link. If the underlying link is not point-to-point (eg: you will need to know the far-side IP), you can point it down your IPSEC tunnel, or anywhere else - it should never actually get used): set routing-options static route 0.0.0.0/0 next-hop at-1/0/0.0 set routing-options static route 0.0.0.0/0 preference 190 Then in your ip-monitoring policy, you can override this dummy route with a better metric than both BGP and DHCP: set services ip-monitoring policy Local-Internet-Test match rpm-probe Internet set services ip-monitoring policy Local-Internet-Test then preferred-route route 0.0.0.0/0 next-hop at-1/0/0.0 set services ip-monitoring policy Local-Internet-Test then preferred-route route 0.0.0.0/0 preferred-metric 1 Now when your test fails (even if BGP does not): inet.0: 49 destinations, 51 routes (49 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[Static/1] 00:13:15, metric2 0 via at-1/0/0.0 [Access-Internal/12] 00:21:45 to 192.168.1.2 via at-1/0/0.0 [BGP/170] 2d 21:51:10, localpref 100 AS path: 65500 I, validation-state: unverified to 172.30.3.2 via ge-0/0/3.0 Cheers, Ben On 29 Aug 2014, at 3:30 am, Mattias Gyllenvarg matt...@gyllenvarg.se wrote: Even is the default routes are both from dynamic protocols (BGP and DHCP). For a regular static this is perfect. No such luck in this sollution. //Mattias On Thu, Aug 28, 2014 at 4:17 PM, Ben Dale bd...@comlinx.com.au wrote: Rather than making configuration changes, if you're running recent code (12.1) on branch SRX, have a look at the preferred-route option in ip-monitoring. You can override your default route dynamically based on the RPM failing, without having to override config. The day this is feature (and ip-monitoring in general) is merged back down to mainline Junos will be a glorious one... Cheers, Ben On 28 Aug 2014, at 9:00 pm, Mattias Gyllenvarg matt...@gyllenvarg.se wrote: I have looked over these and they are the basis of the configuration I am using. The setup is advanced in some senses. The Primary link
Re: [j-nsp] rpm / ip-monitoring
Even with a qualified next-hop? http://www.juniper.net/documentation/en_US/junos12.3/topics/reference/configuration-statement/qualified-next-hop-edit-routing-options.html On Fri, Aug 29, 2014 at 03:03:07PM +0200, Mattias Gyllenvarg wrote: Typical, looks like it will work fine with a DHCP but not a static as I can not have 2 defaults with different pref. I can probably make that work but a solution that works on both would be preferred. :P Anyway, thank you for pointing this out. //Mattias On Fri, Aug 29, 2014 at 2:46 PM, Mattias Gyllenvarg matt...@gyllenvarg.se wrote: Ben, The BGP selects native over IPsec via local-pref (just a note in this context). That may work. I will try to describe your idea in my own words. Add a lurking static default to the MPLS-VPN, put it on steroids when ip-monitor fails? Sounds workable and not to ugly eighter. Will look intt this. //Mattias On Fri, Aug 29, 2014 at 2:05 PM, Ben Dale bd...@comlinx.com.au wrote: Okay, I'm still sure this can be made to work ; ) I'm still a little hazy on your setup though - based on your email: You have a local line which gets an address via DHCP and a default gateway with a preference of 12 You then also receive another default via BGP over an IPSEC tunnel over this same local line interface with a preference of 170 You then have an MPLS service/Native VPN which receives another BGP-sourced default route, presumably also with a preference of 170 If that is the case, configure a static with high preference (170) pointing to your MPLS service/Native VPN, and override this with the lower preference route via your ip-monitoring policy on local-line/Internet failure - it should still work exactly as described, unless I'm missing something else? Ben On 29 Aug 2014, at 7:42 pm, Mattias Gyllenvarg matt...@gyllenvarg.se wrote: Ben Close but no cigar. The IPsec also receives a default via BGP so that works like a charm. No need for interface routing. The thing is that we use the local line for Internet use, so the primary default route goes out that way. The IPsec is there if the Native VPN line fails. So, what I want this ip-monitor/rpm to do is fail over the local internet to the Native VPN in case the local line is broken some how. Regards Mattias On Fri, Aug 29, 2014 at 12:59 PM, Ben Dale bd...@comlinx.com.au wrote: Hi Mattias, It is still possible to bend it to your will ; ) I may be misunderstanding your topology, but essentially you have a Primary link via a WAN circuit that receives a BGP-sourced default, and a backup ADSL connection that receives a default via DHCP/PPP, and has an IPSEC tunnel back to your head office. Are you trying to move the default route to your IPSEC tunnel interface, or the underlying cheap line? You could try the following: Set up a static default with a high metric (so that it will lose to both DHCP and BGP) via your IPSEC tunnel/underlying link. If the underlying link is not point-to-point (eg: you will need to know the far-side IP), you can point it down your IPSEC tunnel, or anywhere else - it should never actually get used): set routing-options static route 0.0.0.0/0 next-hop at-1/0/0.0 set routing-options static route 0.0.0.0/0 preference 190 Then in your ip-monitoring policy, you can override this dummy route with a better metric than both BGP and DHCP: set services ip-monitoring policy Local-Internet-Test match rpm-probe Internet set services ip-monitoring policy Local-Internet-Test then preferred-route route 0.0.0.0/0 next-hop at-1/0/0.0 set services ip-monitoring policy Local-Internet-Test then preferred-route route 0.0.0.0/0 preferred-metric 1 Now when your test fails (even if BGP does not): inet.0: 49 destinations, 51 routes (49 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[Static/1] 00:13:15, metric2 0 via at-1/0/0.0 [Access-Internal/12] 00:21:45 to 192.168.1.2 via at-1/0/0.0 [BGP/170] 2d 21:51:10, localpref 100 AS path: 65500 I, validation-state: unverified to 172.30.3.2 via ge-0/0/3.0 Cheers, Ben On 29 Aug 2014, at 3:30 am, Mattias Gyllenvarg matt...@gyllenvarg.se wrote: Even is the default routes are both from dynamic protocols (BGP and DHCP). For a regular static this is perfect. No such luck in this sollution. //Mattias On Thu, Aug 28, 2014 at 4:17 PM, Ben Dale bd...@comlinx.com.au wrote: Rather than making configuration changes, if you're running recent code (12.1) on branch SRX, have a look at the preferred-route option in ip-monitoring. You can override your default route dynamically based on the RPM failing, without having
