04-19-2012 09:29 AM - edited 04-19-2012 09:48 AM
I'm working the conf in a lab environment, before putting this into production.
Scenario: 2 offices, 2 redundant ISPs at each.
Desire: Run 1 VPN primary, 2nd VPN as failover. Use OSPF to watch for VPN down, then switch to failover VPN.
In the lab I have setup two SRX220's. I have used mock public IPs to simulate actual static IPs from providers. I have also put a RFC1918 on each interface to use for next-hop in routing.
ge-0/0/0 - 220.127.116.11/24 & 192.168.14.2
ge-0/0/1 - 18.104.22.168/24 & 192.168.15.2
ge-0/0/0 - 22.214.171.124/24 & 192.168.14.1
ge-0/0/1 - 126.96.36.199/24 & 192.168.15.1
Static Routes SRX#1
- reach 188.8.131.52/24 with next-hop 192.168.14.1
- reach 184.108.40.206/24 with next-hop 192.168.15.1
Static Routes SRX#2
- reach 220.127.116.11/24 with next-hop 192.168.14.2
- reach 18.104.22.168/24 with next-hop 192.168.15.2
I created 2 VPN tunnels on each SRX:
- Using ge-0/0/0 -- via st0.1
- Using ge-0/0/1 -- via st0.2
(NOTE: I have tried with, and without, the loopback interface in the OSPF area.)
Both VPNs work. I can pass traffic back and forth. (One side of the VPN is 10.100.0.0/24, the other is 10.100.1.0/24)
If I physically pull the plug from interface ge-0/0/0 (breaking VPN over st0.1) after about 60 seconds traffic will pick up automatically over ge-0/0/1 (st0.2). And vice versa.
PROBLEM-- I have not been able to get OSPF working. When I drop to the cli and issue "show ospf neighbor" there is an empty result. When I issue "show ospf interface" both st0.1 and st0.2 appear.
Advice please, on where I am going wrong.
Configs from both SRX devices are attached as text docs to this post.
Solved! Go to Solution.
04-20-2012 05:53 PM - edited 04-20-2012 05:54 PM
Figured it out, with a couple good hints from J-TAC. Hopefully this helps anyone else who might be suffering the same problem.
1) The st0.1 and st0.2 interfaces could not be unnumbered. I used a /30 of 1918 space at each end of the tunnel, on both tunnels. That brought up the OSPF session and routes were learned, but they were NOT being imported to the routing table.
2) I had the 2 tunnels in the OSPF area, but not the physical interface the LAN is plugged into. Once I added ge-0/0/2 to the OSPF area as a passive interface ("don't run OSPF but advertise it") the routes learned by OSPF were added to the routing table and everything worked as expected.
Finally, I was stumped by slow failover. If I pulled the cable on ge-0/0/0 which brought down the primary VPN on tunnel st0.1, it took about 45 seconds before the failover route was put in place. I discovered the VPN dead-peer-detection was set to 15 second intervals with 3 failures required to declare the tunnel dead. I set that to 10 seconds (the minimum permitted) and 1 failure, and now the failover route hits the routing table within 10 seconds. Failback to primary, when it comes back up, is seamless.
04-10-2013 06:21 AM
Can anyone confirm the ADDENDUM.TXT attached is the solution supplied by Rebus ?
And a little question: is it necessary to permit OSPF from the WAN or it is enough trough the tunnel interfaces ?