[jira] [Created] (CLOUDSTACK-9759) VPC VR not obtaining ip address

["Michael (JIRA)" <ji...@apache.org>]

Michael created CLOUDSTACK-9759:
-----------------------------------

             Summary: VPC VR not obtaining ip address
                 Key: CLOUDSTACK-9759
                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9759
             Project: CloudStack
          Issue Type: Bug
      Security Level: Public (Anyone can view this level - this is the default.)
          Components: Virtual Router
    Affects Versions: 4.9.2.0
         Environment: Centos 6.8, CloudStack 4.9.2.0 advanced networking vlans for guest and public
            Reporter: Michael
         Attachments: cloud.log

Cloudstack deployment with advanced networking.

My VPC VR is incorrectly be assigned ethNone inside (/etc/cloudstack/ips.json) for my eth1 public network interface.  If I edit /etc/cloudstack/ips.json and change both occurrences of ethNone to eth1 and restart the VPC then the network works for isolated guest networks attached to the VPC VR and the VR itself.  (note: this issue only occurs with the VPC VR not with guest network or guest shared networks).

Here is the contents of /etc/cloudstack/ips.json

root@r31-VM# cat /etc/cloudstack/ips.json
{
    "eth0": [
        {
            "add": true,
            "broadcast": "169.254.255.255",
            "cidr": "169.254.1.203/16",
            "device": "eth0",
            "gateway": "None",
            "netmask": "255.255.0.0",
            "network": "169.254.0.0/16",
            "nic_dev_id": "0",
            "nw_type": "control",
            "one_to_one_nat": false,
            "public_ip": "169.254.1.203",
            "size": "16",
            "source_nat": false
        }
    ],
    "eth2": [
        {
            "add": true,
            "broadcast": "10.1.1.255",
            "cidr": "10.1.1.1/24",
            "device": "eth2",
            "gateway": "10.1.1.1",
            "netmask": "255.255.255.0",
            "network": "10.1.1.0/24",
            "nic_dev_id": "2",
            "nw_type": "guest",
            "one_to_one_nat": false,
            "public_ip": "10.1.1.1",
            "size": "24",
            "source_nat": false
        }
    ],
    "ethNone": [
        {
            "add": true,
            "broadcast": "10.100.71.255",
            "cidr": "10.100.66.3/21",
            "device": "ethNone",
            "first_i_p": false,
            "gateway": "10.100.71.254",
            "netmask": "255.255.248.0",
            "network": "10.100.64.0/21",
            "new_nic": false,
            "nw_type": "public",
            "one_to_one_nat": false,
            "public_ip": "10.100.66.3",
            "size": "21",
            "source_nat": true,
            "vif_mac_address": "06:56:74:00:06:2c"
        }
    ],
    "id": "ips"
}

After modifying the file ethNone to eth1 then the VPC VR has internet via Public network vlan 165 trunked that bridges to cloudbr1.

    "eth1": [
        {
            "add": true,
            "broadcast": "10.100.71.255",
            "cidr": "10.100.66.3/21",
            "device": "eth1",
            "first_i_p": false,
            "gateway": "10.100.71.254",
            "netmask": "255.255.248.0",
            "network": "10.100.64.0/21",
            "new_nic": false,
            "nw_type": "public",
            "one_to_one_nat": false,
            "public_ip": "10.100.66.3",
            "size": "21",
            "source_nat": true,
            "vif_mac_address": "06:56:74:00:06:2c"
        }
    ],


Public network details:
gateway 10.100.71.254 
ip range: 10.100.66.1 - 10.100.67.254
Netmask: 255.255.248.0 /21

eth1 on VPC VR is the Public network interface

Guest network uses vlan's 300-500 that are trunked into cloudbr1 on the host computer.

I'm also attaching the /var/log/cloud.log from the VPC VR

Note: I restarted the VR several times attempting other /etc/network/interfaces changes before I read on how the VPC VR runs scripts to configure the nics, but the final restart had the reflected changes that causes things to work.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)