3:49 p.m.
I've fixed the semicolon issue and below are the
/etc/os-net-config/config.json files of the nodes
[heat-admin@overcloud-controller-0 ~]$ cat /etc/os-net-config/config.json |
python -m json.tool
{
"network_config": [
{
"addresses": [
{
"ip_netmask": "192.0.2.16/24"
}
],
"dns_servers": [
"192.168.60.100"
],
"name": "nic1",
"routes": [
{
"ip_netmask": "169.254.169.254/32",
"next_hop": "192.0.2.1"
}
],
"type": "interface",
"use_dhcp": false
},
{
"dns_servers": [
"192.168.60.100"
],
"members": [
{
"name": "nic2",
"primary": true,
"type": "interface"
},
{
"addresses": [
{
"ip_netmask": "172.16.0.10/24"
}
],
"type": "vlan",
"vlan_id": 201
},
{
"addresses": [
{
"ip_netmask": "172.18.0.14/24"
}
],
"type": "vlan",
"vlan_id": 202
},
{
"addresses": [
{
"ip_netmask": "172.19.0.12/24"
}
],
"type": "vlan",
"vlan_id": 203
},
{
"addresses": [
{
"ip_netmask": "172.17.0.11/24"
}
],
"type": "vlan",
"vlan_id": 204
}
],
"name": "br-mng",
"type": "ovs_bridge"
},
{
"addresses": [
{
"ip_netmask": "192.168.60.66/24"
}
],
"dns_servers": [
"192.168.60.100"
],
"members": [
{
"name": "nic3",
"primary": true,
"type": "interface"
}
],
"name": "br-ex",
"routes": [
{
"default": true,
"next_hop": "192.168.60.1"
}
],
"type": "ovs_bridge",
"use_dhcp": false
}
]
}
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-compute-0 ~]$ cat /etc/os-net-config/config.json |
python -m json.tool
{
"network_config": [
{
"addresses": [
{
"ip_netmask": "192.0.2.6/24"
}
],
"dns_servers": [
"192.168.60.100"
],
"name": "nic1",
"routes": [
{
"ip_netmask": "169.254.169.254/32",
"next_hop": "192.0.2.1"
},
{
"default": true,
"next_hop": "192.0.2.1"
}
],
"type": "interface",
"use_dhcp": false
},
{
"members": [
{
"name": "nic2",
"primary": true,
"type": "interface"
},
{
"addresses": [
{
"ip_netmask": "172.16.0.11/24"
}
],
"type": "vlan",
"vlan_id": 201
},
{
"addresses": [
{
"ip_netmask": "172.18.0.10/24"
}
],
"type": "vlan",
"vlan_id": 202
},
{
"addresses": [
{
"ip_netmask": "172.17.0.10/24"
}
],
"type": "vlan",
"vlan_id": 204
}
],
"name": "br-ex",
"type": "ovs_bridge"
},
{
"members": [
{
"mtu": 9000,
"name": "nic3",
"primary": true,
"type": "interface"
}
],
"mtu": 9000,
"name": "br-down",
"type": "ovs_bridge"
},
{
"members": [
{
"mtu": 9000,
"name": "nic4",
"primary": true,
"type": "interface"
}
],
"mtu": 9000,
"name": "br-up",
"type": "ovs_bridge"
}
]
}
[heat-admin@overcloud-compute-0 ~]$
On Mon, Apr 3, 2017 at 10:03 PM Dan Sneddon <dsneddon(a)redhat.com> wrote:
On 04/03/2017 06:03 AM, Samuel Monderer wrote:
> Hi Marius,
>
> Attached is the controller node template.
> I've also added below the ovs-vsct show results for both the compute and
> control node
> For some reason there is also a bridge called "undef" in both the
> controller and the compute
>
> [heat-admin@overcloud-controller-0 ~]$ sudo ovs-vsctl show
> 00ce4561-418d-4161-b907-3b2222930f35
> Manager "ptcp:6640:127.0.0.1"
> Bridge br-int
> Controller "tcp:127.0.0.1:6633 <http://127.0.0.1:6633>"
> fail_mode: secure
> Port br-int
> Interface br-int
> type: internal
> Bridge undef
> Port undef
> Interface undef
> type: internal
> Bridge br-mng
> fail_mode: standalone
> Port "vlan204"
> tag: 204
> Interface "vlan204"
> type: internal
> Port "vlan202"
> tag: 202
> Interface "vlan202"
> type: internal
> Port br-mng
> Interface br-mng
> type: internal
> Port "vlan203"
> tag: 203
> Interface "vlan203"
> type: internal
> Port "eno2"
> Interface "eno2"
> Port "vlan201"
> tag: 201
> Interface "vlan201"
> type: internal
> Bridge br-up
> Port br-up
> Interface br-up
> type: internal
> Bridge br-ex
> fail_mode: standalone
> Port br-ex
> Interface br-ex
> type: internal
> Port "eno3"
> Interface "eno3"
> ovs_version: "2.5.0"
> [heat-admin@overcloud-controller-0 ~]$
>
>
> [heat-admin@overcloud-compute-0 ~]$ sudo ovs-vsctl show
> 2f6bccd5-9653-42df-a1db-8cb5c3b0293a
> Manager "ptcp:6640:127.0.0.1"
> Bridge br-down
> fail_mode: standalone
> Port br-down
> Interface br-down
> type: internal
> Port "em3"
> Interface "em3"
> Bridge br-up
> fail_mode: standalone
> Port br-up
> Interface br-up
> type: internal
> Port "em4"
> Interface "em4"
> Bridge br-ex
> fail_mode: standalone
> Port "vlan204"
> tag: 204
> Interface "vlan204"
> type: internal
> Port "vlan202"
> tag: 202
> Interface "vlan202"
> type: internal
> Port "vlan201"
> tag: 201
> Interface "vlan201"
> type: internal
> Port br-ex
> Interface br-ex
> type: internal
> Port "em2"
> Interface "em2"
> Bridge br-int
> Controller "tcp:127.0.0.1:6633 <http://127.0.0.1:6633>"
> fail_mode: secure
> Port br-int
> Interface br-int
> type: internal
> Bridge undef
> Port undef
> Interface undef
> type: internal
> ovs_version: "2.5.0"
> [heat-admin@overcloud-compute-0 ~]$
>
>
>
>
> On Fri, Mar 31, 2017 at 1:01 PM Marius Cornea <marius(a)remote-lab.net
> <mailto:marius@remote-lab.net>> wrote:
>
> Hi Samuel,
>
> Could you please share the nic template used for the controller node?
> The bridges should be created according to the nic template so I
would
> like to see how it looks.
>
> Thanks!
>
> On Thu, Mar 30, 2017 at 4:59 PM, Samuel Monderer
> <smonderer(a)vasonanetworks.com
<mailto:smonderer@vasonanetworks.com>>
> wrote:
> > Hi,
> >
> > I would like to test my VNF on an openstack environment deployed
using
> > TripleO.
> > For that I need to setup flat provider networks that go only to
> the compute
> > node.
> > I tried deploying an overcoud with additional neutron bridge
> mappings as
> > following
> >
> > Added NeutronBridgeMappings: "
> > datacentre:br-ex,physdown;br-down,physup:br-up" to network
> environment file
> > Added following resources to compute.yaml file
> >
> > -
> > type: ovs_bridge
> > name: br-down
> > mtu: 9000
> > members:
> > -
> > type: interface
> > name: ens4f0
> > # force the MAC address of the bridge to this
> interface
> > primary: true
> > -
> > type: ovs_bridge
> > name: br-up
> > mtu: 9000
> > members:
> > -
> > type: interface
> > name: ens4f1
> > # force the MAC address of the bridge to this
> interface
> > primary: true
> >
> > This will create the intended OVS bridges on the the compute node
> with the
> > interfaces connected.
> >
> > The unwanted side effect it that ii also created the bridges on the
> > controller node without any interfaces connected to it
> >
> > Is there a way to have the undercloud create the bridges only on
> the compute
> > nodes and not on the controller nodes???
> >
> > Samuel
> >
> > _______________________________________________
> > rdo-list mailing list
> > rdo-list(a)redhat.com <mailto:rdo-list@redhat.com>
> > https://www.redhat.com/mailman/listinfo/rdo-list
> >
> > To unsubscribe: rdo-list-unsubscribe(a)redhat.com
> <mailto:rdo-list-unsubscribe@redhat.com>
>
>
>
> _______________________________________________
> rdo-list mailing list
> rdo-list(a)redhat.com
> https://www.redhat.com/mailman/listinfo/rdo-list
>
> To unsubscribe: rdo-list-unsubscribe(a)redhat.com
>
You've got a syntax error in your bridge_mappings (semicolon instead of
colon). This is causing your "undef" bridge.
Also, it is expected behavior that if you define a bridge in a bridge
mapping, but you don't include that bridge in the NIC template, that you
will end up with a bridge with no interfaces attached. It shouldn't hurt
anything.
--
Dan Sneddon | Senior Principal Software Engineer
dsneddon(a)redhat.com | redhat.com/openstack
dsneddon:irc | @dxs:twitter