Sorry for the long delay in replies.
We will have a non RFC1918 IP address at the hub and the spokes will get a dynamic IP from the provider through ADSl 2+.
I haven't had to deal with dynamic IPs on SRX ipsec tunnel endpoints as I've been fortunate that we can maintain enough control of the links to require statics. That said, I *believe* this should just change your IKE gateway configs on the hub to reference a dynamic gateway for each customer site rather than using a static destination gateway IP, e.g.:
security {
ike {
gateway spoke1 {
ike-policy spoke1-policy;
dynamic hostname spoke1.example.org;
external-interface <ike-ext-interface>;
}
}
}
Be sure to use aggressive mode in your IKE policy.
the spokes should have a 4G as backup for the ADSL2+. How the backup link should be configured. I assume at the hub st0.x multipoint will be configured.
There are a few different ways to slice it. Multipoint at the hub is one option. I haven't run a multiple routed IPSEC setup on Junos, so I'm extrapolating a bit here and hopefully somebody will tell me I'm being an idiot if I veer to far off course.
If you're doing backup links, running a protocol, I would set up 2x multipoint VPN interfaces at the hub, banked off of different IPs (could be the same external interface with multiple IPs bound; use "local-address a.b.c.d" and "local-identity inet a.b.c.d" under the IKE gateway definitions on the hub to distinguish the two). Point the primary link from the branches to the first multipoint st0.x interface at the hub, and the secondary branch links at the second multipoint st0.x interface at the hub. Set your protocol interface metrics/costs so that the second multipoint st0.x at the hub has a higher cost. If you were to use just one multipoint st0.x at the hub, the hub would not have a way to distinguish route preferences between the primary and secondary links.
In terms of backup paths / failover:Will you route *all* spoke site traffic through the hub? Or just inter-site traffic, with e.g. regular public internet traffic going out the spoke's local provider's gateway?
If the former:Create static /32 routes for the hub's IKE gateway IPs for the primary and secondary st0.x multipoint interfaces there (I'll just call them st0.0 (primary) and st0.1 (secondary) from here on). The /32 route for st0.0's IKE gateway IP should go via your default gateway on the ADSL interface, with /32 route for st0.1's IKE gateway IP via the HSPA backup default gateway. Actually; given that we're talking about DHCP on the ADSL, consider putting the ADSL and HSPA interfaces in their own discrete virtual-router routing-instances so that the 0/0 route picked up from DHCP on the ADSL gets installed in that VR, and the static 0/0 route for the HSPA can be isolated into its own VR.
Failover between primary and secondary are then handled by whatever protocol you run within the st0.x tunnels. If the latter (VPN tunnels for inter-site traffic only; public internet traffic egress locally at the branches), you'll still want static routes config'd on the branches for the 2x different IKE gateway IPs on the hub, but now you also need to handle failover locally. My guess is your best bet for that would be RPM to monitor connectivity across your ADSL connection and pull that route in case of RPM failure. I haven't done that either on a DHCP setup, so YMMV on the details of that implementation.
Hope that helps; I'd be curious to hear how this turns out. -- Hugo h...@slabnet.com: email, xmpp/jabber PGP fingerprint (B178313E): CF18 15FA 9FE4 0CD1 2319 1D77 9AB1 0FFD B178 313E (also on textsecure & redphone) On Sat 2015-Jun-13 11:39:11 +0300, Nc Aji <aji14...@gmail.com> wrote:
Appreciated your inputs. To make it bit more clear. We will have a non RFC1918 IP address at the hub and the spokes will get a dynamic IP from the provider through ADSl 2+. the spokes should have a 4G as backup for the ADSL2+. How the backup link should be configured. I assume at the hub st0.x multipoint will be configured. do you have any suggestions regarding the configurations. Thx
signature.asc
Description: Digital signature
_______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
