SRX

Hello Guys,

I configured floating static entry for virtual interface as below:

set routing-option static route 10.44.199.54/32 next-hop st0.16 preference 5
set routing-option static route 10.44.199.54/32 qualified-next-hop st0.36 preference 7

commit

However, when primary route (confiugred with preference 5) is not accessible, route does not use other entry with preference 7. Could somebady explain me what have I missed?

I tested both routes - when configured separately, they both work fine. 

set routing-option static route 10.44.199.54/32 next-hop st0.16
set routing-option static route 10.44.199.54/32 next-hop st0.36

Just for information - I use virtual intraface for vpn configuration so I can point to the specific MTU sized interface.

Can you check that when primary route (configured with preference 5) is not accessible that the secondary route is available in the routing table ? 

> show route 10.44.199.54/32

If not check if the secondary interface is up ?

>show interfaces terse | match st0.36

#this is a state at the beging:

run show configuration routing-options static | match 10.44.199.54
route 10.44.199.54/32 next-hop st0.16;

run show route 10.44.199.54/32

inet.0: 353 destinations, 372 routes (353 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.44.199.54/32    *[Static/5] 3d 22:44:35
                    > via st0.16

#after floating static route addition:


set routing-options static route 10.44.199.54/32 qualified-next-hop st0.36 preference 7


run show configuration routing-options static | find 10.44.199.54
route 10.44.199.54/32 {
    next-hop st0.16;
    qualified-next-hop st0.36 {
        preference 7;


run show route 10.44.199.54/32

inet.0: 353 destinations, 373 routes (353 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.44.199.54/32    *[Static/5] 3d 22:48:24
                    > via st0.16
                    [Static/7] 00:00:35
                    > via st0.36

#so far so good - no network issues
#now - I breake via st0.16 by modyfing gateway

set security ike gateway eNB101034_Mplane_gateway version v1-only

#connectivity via primary tunnel(st0.16) fail, so it should swap to use route via st0.36
#tunnel is swapped but routing still use primary route

lteadm@srx1400# run show route 10.44.199.54/32

inet.0: 353 destinations, 373 routes (353 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.44.199.54/32    *[Static/5] 3d 22:56:49  <---------------
                    > via st0.16
                    [Static/7] 00:09:00
                    > via st0.36

#interface st0.36 is up

lteadm@srx1400# run show interfaces terse | match st0.36
st0.36                  up    up   inet

[edit]

#however interface st0.16 is up as well, so to simulate tunnel failer, I also disable st0.16 interface

set interfaces st0 unit 16 disable

run show interfaces terse | match st0.16
st0.16                  down  up   inet


run show route 10.44.199.54/32

inet.0: 353 destinations, 372 routes (353 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.44.199.54/32    *[Static/7] 00:18:30
                    > via st0.36

[edit]

#and routing works!

#then I want to switch back to previouse routing and porevious tunnel

set security ike gateway eNB101034_Mplane_gateway version v2-only
delete interfaces st0 unit 16 disable

#and ... routing is back to normal

 run show route 10.44.199.54/32

inet.0: 353 destinations, 373 routes (353 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.44.199.54/32    *[Static/5] 00:01:06
                    > via st0.16
                    [Static/7] 00:24:00
                    > via st0.36



#so - to summarise - to test tunnel failower, I should also disable virtual(st0.16) inetrface


Thanks elkadiki - I put my head into correct direction 🙂

You're welcome Cas-CCNP

Glad you found the answer in the end and that you shared it with us. I actually face your issue alot ( hanging tunnel interfaces )  as I have a similar setup with a lot of route based VPNs. Rule of thumb I give to my engineers is never trust the output of show security ike/ipsec sa or show interfaces st0.x terse after a simple commit. If the change isn't major it usually won't delete the SA so it will look as if the tunnel is up unless you have vpn-monitor.

Always ping across the tunnel while troubleshooting or do a "commit full" if you can afford disruption to firewall operations.

Hi Hisham,

---

@elkadiki wrote:

Rule of thumb I give to my engineers is never trust the output of show security ike/ipsec sa or show interfaces st0.x terse after a simple commit. If the change isn't major it usually won't delete the SA so it will look as if the tunnel is up unless you have vpn-monitor.

 

 

Always ping across the tunnel while troubleshooting or do a "commit full" if you can afford disruption to firewall operations.

---

Yes,that true. Many times, I faced situation when tunnels were established in show sec associations but other end could not negotiate to set up a tunne 🙂 I also noticed that SRX sometimes do not accept "commit". it might be one of the bugs.

Another interesting issue I noticed recently was that when you add to vpn policy: " establish tunnel imadiately " - and you configure that for one of several tunnels pointing to one devise ot all tunnels (for example subinterfaces) - tunels do not establish. My collegue had that problem and  to solve that - we had to delete that command from all polices and recreate vpn polices from scratch as SRX could not negoitiate tunnel any more( no proposal choosen error).

In my opinion - delete problematic commands shoud be enouth to solve the issue - so Juniper TAC should look into that as well. Now we are looking to upgrade Junos  - it is possible thta current one contains some bugs which might be fixed in higher release.