IPsec shutdown and re-up the external-interface ,routing missing

[stan.pao]

[openstack version kilo]
lan1 192.168.252.0/24
   |
   | 192.168.252.1
   | 172.77.3.39 floatingip
 qrouter
   | 172.88.1.39
   |
   |
internet
   |
   |
   | 172.88.1.38
 qrouter
   | 172.77.3.38 floatingip
   | 192.168.253.1
   |
  lan2 192.168.253.0/24
After setting up ipsec-tunnel successfully,lan1 can ping lan2.Then shut down qrouter external gateway v-interface and re-up,ipsec-site-connection keep alive and ipsec whack checking is normal,but lan1 can't ping lan2 this time.Using 'ip netns exec route -n' to check,some important routing entry missing leading communication-failure,just like the below sample.Although the defaulting-routing entry exists,communication is failed:
[before re-uping]
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 172.88.1.254 0.0.0.0 UG 0 0 0 qg-8889b596-a5
172.77.3.0 0.0.0.0 255.255.255.0 U 0 0 0 qg-8889b596-a5
172.77.3.38 0.0.0.0 255.255.255.255 UH 0 0 0 *
172.88.1.0 0.0.0.0 255.255.255.0 U 0 0 0 qg-8889b596-a5
192.168.252.0 172.88.1.254 255.255.255.0 UG 0 0 0 qg-8889b596-a5 ⭐-->will missing
192.168.253.0 0.0.0.0 255.255.255.0 U 0 0 0 qr-799ac9c5-58

[after re-uping]
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 172.88.1.254 0.0.0.0 UG 0 0 0 qg-8889b596-a5
172.77.3.0 0.0.0.0 255.255.255.0 U 0 0 0 qg-8889b596-a5
172.77.3.38 0.0.0.0 255.255.255.255 UH 0 0 0 *
172.88.1.0 0.0.0.0 255.255.255.0 U 0 0 0 qg-8889b596-a5
192.168.253.0 0.0.0.0 255.255.255.0 U 0 0 0 qr-799ac9c5-58

[Bernard Cafarelli (bcafarel)]

Thanks for the report. I guess the ipsec tunnel is configured via vpnaas extension, can you confirm that? Also relevant logs can help (L3 agent for example)

[Bernard Cafarelli (bcafarel)]

Also, just seeing the first line, Kilo is a really old release and unsupported. Does this also happen in a supported version?

[Akihiro Motoki (amotoki)]

In addition to Bernard's question, I have another question.

Who shut down qrouter external interface? If you shut down it manually for testing, it is not a normal case. Does it usually happen in normal operations?

[stan.pao (cough.syrup)]

Thks,sir.
Firstly reply to Bernard.Using vpnaas actually and the log of libreswan is keeping established just like normally set up tunnel.As official docs said,vpnass is supported from version icehouse.
Secondly reply to Akihiro.As you said,vif's operation is not in the range of product-specification?

[Lajos Katona (lajos-katona)]

I think Bernard wanted to say that please reproduce the issue on some supported version (master, stable/queens, stable/pike, etc...), as kilo is not supported now, and actually nobody from the community have time to reproduce your issue.

If the issues your reported can be reproduced on any of the stable branches or on master, you or somebody from the community will possibly solve it (there is some triaging, and other things to decide the severity and similar things)

If the bug solved on one of the stable branches (or on master) the bugfix can be backported to older stable branches (I think it is written here: https://docs.openstack.org/project-team-guide/stable-branches.html).

But nobody can fix this for you from the community on kilo, as there is no stable/kilo branch to land the fix (no support for kilo)

[Lajos Katona (lajos-katona)]

Actually I think I reproduced the issue on stable/queens.
I am not an expert of vpn, so perhaps not every step was perfect, but finally I have missing routes, which lead to traffic loss.

But I agree with Akihiro that this is not a valid usecase, instead an attack or a disaster for the infrastructure and I don't think that neutron (or any openstack project) should defend.

[stan.pao (cough.syrup)]

Thks,all.I think this is resolved.