cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <>
Subject [jira] [Commented] (CLOUDSTACK-6485) [vpc] new private gateway network is registered wrong in network table
Date Sat, 16 Jan 2016 18:55:40 GMT


ASF subversion and git services commented on CLOUDSTACK-6485:

Commit 75b68c68298dab270782be68f8f9f28e551fc5d0 in cloudstack's branch refs/heads/master from
[;h=75b68c6 ]

Merge release branch 4.7 to master

* 4.7:
  Fix unable to setup more than one Site2Site VPN Connection
  FIX S2S VPN rVPC: Check only redundant routers in state MASTER
  PEP8 of integration/smoke/test_vpc_vpn
  Add S2S VPN test for Redundant VPC
  Make integration/smoke/test_vpc_vpn Hypervisor independant
  FIX VPN: non-working ipsec commands
  [DB] Add force_encap field to s2s_customer_gateway table
  [ROUTER] Add forceencaps field to python router ipsec config method
  [TEST] unittest needs rework
  [MARVIN] Add forceencap field to VpnCustomerGateway class in marvin base
  [CORE] Add Force UDP Encapsulation option to Site2Site VPN
  CLOUDSTACK-9186: Root admin cannot see VPC created by Domain admin user
  CLOUDSTACK-9192: UpdateVpnCustomerGateway is failing
  CLOUDSTACK-6485 prevent ip asignment of private gw iface
  CLOUDSTACK-9204 Do not error when staticroute is already gone
  make both check lines consistent
  CLOUDSTACK-9181 Prevent syntax error in
  CLOUDSTACK-9202 Bump ssh timeout

> [vpc] new private gateway network is registered wrong in network table
> ----------------------------------------------------------------------
>                 Key: CLOUDSTACK-6485
>                 URL:
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: Virtual Router
>    Affects Versions: 4.2.1, 4.3.0, 4.4.0, 4.3.1
>            Reporter: Anton Opgenoort
>            Assignee: Daan Hoogland
> When creating a private gateway for a VPC router on a network not yet known to Cloudstack,
Cloudstack ‘documents’ this network in the networks table.
> For normal guest networks, which should be associated with a single VPC, Cloudstack includes
the VPC_ID in the database. The VPC_ID field is used to provision all networks and nics on
a VPC router when it is created. Since this table is all about network provisioning it makes
sense to ‘document’ the network cidr and gateway present in that nework. For guest tiers
this usually is the VPC router itself, so the interface IP’s on a VPC router are the gateway
IP’s found in the networks table.
> Unfortunately the VPC_ID is also recorded for the private gateway network when it is
first created. So the first VPC to be plugged on the private gateway network also has that
same network associated as a guest network tier, instead of just a private gateway network.
> This by itself will not quickly become a problem, because private gateways are first
plugged on a running vpc router which is not likely to be recreated any time soon after that.
> But as soon as this first ever VPC router on the private gateway network is recreated
due to a destroy of the VPC Router, all associated networks are looked up in the networks
> Because the private gateway network is ‘documented’ with the actual upstream gateway
used by the VPC router defintion, the VPC router provisions a NIC on the private gateway network
using the IP address of the actual upstream gateway creating an IP conflict on the private
gateway network, effectively breaking down the upstream gateway functionality for all attached
private gateways of other vpc's.

This message was sent by Atlassian JIRA

View raw message