You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cloudstack.apache.org by "Michael (JIRA)" <ji...@apache.org> on 2017/01/26 18:26:24 UTC
[jira] [Commented] (CLOUDSTACK-9759) VPC VR not obtaining ip
address
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15840173#comment-15840173 ]
Michael commented on CLOUDSTACK-9759:
-------------------------------------
Please let me know, if you need more logs. ip addr on the VR only shows the link-local without modifying (/etc/cloudstack/ips.json) and restarting the VR.
My understanding is the management server sends the json to the host and the host delivers the ips.json to the VR. Can I check something to see why ethNone is being passed instead of eth1 at some point?
> 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
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> 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.
> Cloudstack is using KVM hypervisor.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)