VPNaas:service ipsec status gives incorrect status of the ipsec tunnel.

[Neeti Munshi]

In the devstack setup with VPNaas enabled:

1. Establish a IPsec site connection between 2 devstack clouds.
2. Verify that the connection is active from both ends.
3. Now run "service ipsec status" on either of the cloud.

$ service ipsec status
IPsec running - pluto pid: 8489
pluto pid 8489
No tunnels up

4. ipsec status shows that there is no tunnel up, though there is a active and working IPsec site connection established.

[Paul Michali (pcm)]

The ipsec process is run in a namespace for each service. To see the underlying connection status command and output, you need to run the status command from within the namespace (see screen-q-vpn.log for examples of status checking). Rather than parsing the output of the OpenSwan though, you can use "neutron ipsec-site-connection-list" to see the status for the connection.

However, I AM seeing a related bug. It appears that the commit to set status for invalid peer address via FQDN (Bug 1405413) is not correctly setting the status for the connection as a result.

We can probably use this bug to fix that issue, as it is a status reporting issue.

[Paul Michali (pcm)]

Aniruddha, are you actively working on this? If not, I can apply the fix.

[Wei Hu (huwei-xtu)]

Hi @Paul Michali, I need your patch. I have a requirement to fix this issue.
@Aniruddha do you still working on this issue?

[Paul Michali (pcm)]

I changed assignment to me and will work on fixing this.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/183724

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/183724
Committed: https://git.openstack.org/cgit/openstack/neutron-vpnaas/commit/?id=462a1165d8f347ff5afa08aa502436ee7d4dc9dd
Submitter: Jenkins
Branch: master

commit 462a1165d8f347ff5afa08aa502436ee7d4dc9dd
Author: Paul Michali <email address hidden>
Date: Fri May 15 17:27:26 2015 -0400

    VPNaaS: Fix breakage in status reporting

    In the plugin, the status for the VPN service and its connections
    are only updated if there is a change in the status or if the
    pending_status_update flag is set. This flag is supposed to be
    set when the status changes and the database has the resource in
    PENDING_* state.

    In the failure case, when the connection is created, the service
    and connection are in PENDING_CREATE state in the plugin. In the
    device driver, because of the create the service is set to ACTIVE
    and its pending_status_update flag is set. The connection will be
    in either DOWN or ACTIVE state and the pending_status_update_flag
    is set. This is as expected.

    When the device driver is about to report, it reads the latest
    status and updates it, before reporting. This is where the bug
    occurred.

    Because of the recent change for translating the FQDN of peer to
    IP address, if that fails, it attempts to set the status to ERROR
    and force an update by setting updated_pending_status (so that it
    updates, even if in pending state). However, the implementation
    is set the updated_pending_status flag based on this "force" flag,
    which is by default, false.

    As a result, the flag gets cleared before the first report is sent
    and the connection is never updated from then on (because it never
    checks again to see if in PENDING_* state).

    The fix is to simply only update the pending_status_update, when
    the forced flag is set, otherwise leave it alone so that the flag
    is not cleared on the first report.

    In the future, this shoudl be reworked to a simpler mechanism that
    just checks previous vs current status and reports any change, and
    the plugin unconditionally updates the status.

    Change-Id: Id49e54c49f3c72f676b6f2513288c0eae2c6db7b
    Closes-Bug: #1440655

[Wei Hu (huwei-xtu)]

@Paul Michali should we cherry pick this patch to kilo? Kilo also has this issue.

[Paul Michali (pcm)]

Yeah, I'll do a quick patch.

On Mon, Jun 1, 2015 at 10:11 PM Wei Hu <email address hidden> wrote:

> @Paul Michali should we cherry pick this patch to kilo? Kilo also has
> this issue.
>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/1440655
>
> Title:
> VPNaas:service ipsec status gives incorrect status of the ipsec
> tunnel.
>
> Status in OpenStack Neutron (virtual network service):
> Fix Committed
>
> Bug description:
> In the devstack setup with VPNaas enabled:
>
> 1. Establish a IPsec site connection between 2 devstack clouds.
> 2. Verify that the connection is active from both ends.
> 3. Now run "service ipsec status" on either of the cloud.
>
> $ service ipsec status
> IPsec running - pluto pid: 8489
> pluto pid 8489
> No tunnels up
>
> 4. ipsec status shows that there is no tunnel up, though there is a
> active and working IPsec site connection established.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/neutron/+bug/1440655/+subscriptions
>

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/kilo
Review: https://review.openstack.org/187542

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/187542
Committed: https://git.openstack.org/cgit/openstack/neutron-vpnaas/commit/?id=053fd30cbc1f71c7854150beab5f81292e222afe
Submitter: Jenkins
Branch: stable/kilo

commit 053fd30cbc1f71c7854150beab5f81292e222afe
Author: Paul Michali <email address hidden>
Date: Fri May 15 17:27:26 2015 -0400

    VPNaaS: Fix breakage in status reporting

    In the plugin, the status for the VPN service and its connections
    are only updated if there is a change in the status or if the
    pending_status_update flag is set. This flag is supposed to be
    set when the status changes and the database has the resource in
    PENDING_* state.

    In the failure case, when the connection is created, the service
    and connection are in PENDING_CREATE state in the plugin. In the
    device driver, because of the create the service is set to ACTIVE
    and its pending_status_update flag is set. The connection will be
    in either DOWN or ACTIVE state and the pending_status_update_flag
    is set. This is as expected.

    When the device driver is about to report, it reads the latest
    status and updates it, before reporting. This is where the bug
    occurred.

    Because of the recent change for translating the FQDN of peer to
    IP address, if that fails, it attempts to set the status to ERROR
    and force an update by setting updated_pending_status (so that it
    updates, even if in pending state). However, the implementation
    is set the updated_pending_status flag based on this "force" flag,
    which is by default, false.

    As a result, the flag gets cleared before the first report is sent
    and the connection is never updated from then on (because it never
    checks again to see if in PENDING_* state).

    The fix is to simply only update the pending_status_update, when
    the forced flag is set, otherwise leave it alone so that the flag
    is not cleared on the first report.

    In the future, this shoudl be reworked to a simpler mechanism that
    just checks previous vs current status and reports any change, and
    the plugin unconditionally updates the status.

    Change-Id: Id49e54c49f3c72f676b6f2513288c0eae2c6db7b
    Closes-Bug: #1440655
    (cherry picked from commit 462a1165d8f347ff5afa08aa502436ee7d4dc9dd)