OSPF with ipsec VTI interface goes down before dead timer.

[paul amaral]

I have a strange issue that OSPF will initially start working, hellos are exchanged both ways but then after about 3 – 6 hellos one of the sides stops getting them and the ipsec VTI tunnel drops on router A even before the dead timer reaches 0. Is this default behavior, when OSPF is over a VTI interface if it doesn’t receive hellos is drops the tunnel?

I’m at a loss as to what is going on since it looks like only one neighbor stops receiving hellos, router A, for a brief period of time. This VTI tunnel is going over another provider’s FW and they have assured me the tunnel destination/source ips are wide open they also sent me the ACL and I can verify this. The weird thing is if I enable EIGRP it works great with no issues. On router B I am using the same source/ip unnumbered  interface on multiple VTI tunnels to to other destinations but this shouldn’t cause any issues I don’t think. I have never had an issue like this and from what I can tell the router A just stops briefly getting hellos after 3 – 6 initial hellos and drops the protocol on the VTI interface. If I set the dead timer on router A long enough it will stop receiving hellos but stay up and then after a while you get “LOADING to FULL” as the hellos start coming in again.  Again the tunnel goes over a cisco 800 which I have no control over it and a potential FW before that but I saw the ACL and ip is being allowed. I was thinking this could be a trolling issue on the FW but it doesn’t explain why EIGRP works.  FYI I was having a recursive routing issue before but I have since fixed that and the issue still continues.

********  it turns out that i was using the same source ip on multiple tunnels. IPsec would get confused with packets coming in and would deliver packets to the wrong tunnel interface. This was solved but using the key command with a different key number on each set of tunnels with the shared profile command

"If more than one mGRE tunnel is configured on a router that use the same tunnel source address, the shared keyword must be added to the tunnel protection command on all such tunnel interfaces. Each mGRE tunnel interface still requires a unique tunnel key, NHRP network-ID, and IP subnet address. This is common on a branch router when a dual DMVPN cloud topology is deployed. "

Router A:

router ospf 1

router-id 10.213.22.2

passive-interface default

network x.x.97.26 0.0.0.0 area 0

interface Tunnel1

ip unnumbered GigabitEthernet0/1

ip virtual-reassembly in

ip tcp adjust-mss 1398

ip ospf network point-to-point

load-interval 30

tunnel source GigabitEthernet0/1

tunnel mode ipsec ipv4

tunnel destination x.x.173.109

tunnel path-mtu-discovery

tunnel protection ipsec profile VTI-to-NB

router B:

router ospf 1

router-id 172.17.2.6

priority 1

redistribute static subnets route-map Lan-static-RM

passive-interface default

no passive-interface Tunnel1

no passive-interface Tunnel4

no passive-interface Tunnel5

network x.x.173.109 0.0.0.0 area 0

network 172.17.2.6 0.0.0.0 area 0

network 192.168.1.47 0.0.0.0 area 0

interface Tunnel4

ip unnumbered GigabitEthernet0/2

ip virtual-reassembly in

ip tcp adjust-mss 1398

ip ospf network point-to-point

load-interval 30

tunnel source GigabitEthernet0/2

tunnel mode ipsec ipv4

tunnel destination x.x.97.26

tunnel path-mtu-discovery

tunnel protection ipsec profile VTI_NB_to_dorrance_prv

end

thanks P

[Vasilii Mikhailovskii]

Hello.

What IOS version do you run (on both sides)?

Do you observe the same issue if you run continuous ping over the tunnel?

Could you try to configure static ip mtu on tunnel interfaces and remove path-mtu-discovery?

Could you provide debug ip ospf hello and debug ip ospf adj output from both peers?

Please provide "show ip ospf int tu4" and "show ip ospf traffic tu4".

Thanks.

PS: what ACLs are you talking about?

[paul amaral]

Vasilii, thanks for your reply.

for now i have used static routing I am observing the tunnel drop at least a few times a day and have notice packet loss, although its not very significant loss between the tunnel endpoints.

11614 packets transmitted, 11585 received, 0% packet loss, time 11612418ms

Not sure if this is the reason that OSPF wont stay up, seems weird that the side having issues will initially get hellos then just drop after receiving 3/4 hellos initial hellos. there is a FW between the tunnels that i dont control so not sure if its that. Im in the process of moving the tunnels through another path and will post what i find once thats done. the new path for the tunnels will bypass tjhe FW in question. Also EIGRP while initially was working did give me issues where routes would disappear from the topology table although the tunnel was always up and so where eigrp neighbors.

thanks, P

[Vasilii Mikhailovskii]

Hello.

Looks like you are not investigating the issue any more.

But I would say, that EIGRP is a really good protocol, so whatever issue you had in the past might had any kind of root cause.

So, if you migrate, I would suggest to review EIGRP option as well.

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

I haven't studied your config, but I can tell you I have production environment using OSPF across VTI  (and GRE, and GRE/IPSec and DMVPN) tunnels without issue.  I.e. so OSPF can be okay with VTI tunnels.

[paul amaral]

 it turns out that i was using the same source ip on multiple tunnels. IPsec would get confused with packets coming in and would deliver packets to the wrong tunnel interface. This was solved but using the key command with a different key number on each set of tunnels with the shared profile command

"If more than one mGRE tunnel is configured on a router that use the same tunnel source address, the shared keyword must be added to the tunnel protection command on all such tunnel interfaces. Each mGRE tunnel interface still requires a unique tunnel key, NHRP network-ID, and IP subnet address. This is common on a branch router when a dual DMVPN cloud topology is deployed. "