yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #96283
[Bug 2120316] [NEW] Dalmatian: Second IPsec site connection on same VPN service/router stays PENDING_CREATE; no agent-side rendering (works on Zed L3 agent)
Public bug reported:
Summary:
On OpenStack Dalmatian, creating a second IPsec site connection on the same VPN service / router remains in PENDING_CREATE indefinitely. The L3 agent (with VPNaas extension) is alive, hosting the router as master, but produces no logs for the second connection and renders no config updates. Repeating the same steps with only the L3 agent switched to a Zed image makes the second connection render immediately (a new conn in ipsec.conf and PSK in ipsec.secrets), and the tunnel comes up. This looks like a Dalmatian regression in the L3/VPNaas handling of multiple connections under one VPN service.
Environment:
Deployment: OpenStack services running in Kubernetes (OpenStack-Helm style)
Neutron L3 agent with VPNaas extension, driver: strongSwan
What works:
One IPsec site connection (conn #1) on the VPN service is rendered and active.
On Zed L3 agent (same environment), adding conn #2 on the same VPN service/router renders correctly and comes up.
What fails (Dalmatian):
Adding conn #2 on the same VPN service/router:
API status: PENDING_CREATE (no progress).
No new lines in neutron L3/VPNaas pod logs for the event; no strongSwan (charon.log) activity.
No changes to files:
/var/lib/neutron/ipsec/<router_uuid>/etc/ipsec.conf (still only the first conn stanza)
/var/lib/neutron/ipsec/<router_uuid>/etc/ipsec.secrets (no second secret)
Steps to Reproduce:
Create router with external gateway; create VPN service on that router.
Create IKE and IPsec policies (strongSwan driver).
Create first IPsec site connection (conn #1) on the VPN service.
→ Result: ACTIVE; files and SAs are rendered.
Create second IPsec site connection (conn #2) on the same VPN service/router (different peer).
→ Dalmatian result: PENDING_CREATE; no agent logs; no file changes under /var/lib/neutron/ipsec/<router>/etc.
Repeat (3)-(4) with only the neutron-l3-agent running a Zed image.
→ Zed result: second conn and secret are rendered; tunnel comes up.
Expected Result:
Creating conn #2 adds another conn <uuid> stanza to ipsec.conf, appends the secret, and brings up an additional IKE/CHILD SA (supported multi-connection “hub-and-spoke” on one router).
Actual Result (Dalmatian):
conn #2 stuck in PENDING_CREATE, no L3/VPNaas processing, no config rendering, no logs.
** Affects: neutron
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/2120316
Title:
Dalmatian: Second IPsec site connection on same VPN service/router
stays PENDING_CREATE; no agent-side rendering (works on Zed L3 agent)
Status in neutron:
New
Bug description:
Summary:
On OpenStack Dalmatian, creating a second IPsec site connection on the same VPN service / router remains in PENDING_CREATE indefinitely. The L3 agent (with VPNaas extension) is alive, hosting the router as master, but produces no logs for the second connection and renders no config updates. Repeating the same steps with only the L3 agent switched to a Zed image makes the second connection render immediately (a new conn in ipsec.conf and PSK in ipsec.secrets), and the tunnel comes up. This looks like a Dalmatian regression in the L3/VPNaas handling of multiple connections under one VPN service.
Environment:
Deployment: OpenStack services running in Kubernetes (OpenStack-Helm style)
Neutron L3 agent with VPNaas extension, driver: strongSwan
What works:
One IPsec site connection (conn #1) on the VPN service is rendered and active.
On Zed L3 agent (same environment), adding conn #2 on the same VPN service/router renders correctly and comes up.
What fails (Dalmatian):
Adding conn #2 on the same VPN service/router:
API status: PENDING_CREATE (no progress).
No new lines in neutron L3/VPNaas pod logs for the event; no strongSwan (charon.log) activity.
No changes to files:
/var/lib/neutron/ipsec/<router_uuid>/etc/ipsec.conf (still only the first conn stanza)
/var/lib/neutron/ipsec/<router_uuid>/etc/ipsec.secrets (no second secret)
Steps to Reproduce:
Create router with external gateway; create VPN service on that
router.
Create IKE and IPsec policies (strongSwan driver).
Create first IPsec site connection (conn #1) on the VPN service.
→ Result: ACTIVE; files and SAs are rendered.
Create second IPsec site connection (conn #2) on the same VPN service/router (different peer).
→ Dalmatian result: PENDING_CREATE; no agent logs; no file changes under /var/lib/neutron/ipsec/<router>/etc.
Repeat (3)-(4) with only the neutron-l3-agent running a Zed image.
→ Zed result: second conn and secret are rendered; tunnel comes up.
Expected Result:
Creating conn #2 adds another conn <uuid> stanza to ipsec.conf, appends the secret, and brings up an additional IKE/CHILD SA (supported multi-connection “hub-and-spoke” on one router).
Actual Result (Dalmatian):
conn #2 stuck in PENDING_CREATE, no L3/VPNaas processing, no config rendering, no logs.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/2120316/+subscriptions