Hi Ross, > * can I share the br-ex interface or do I need to use a separate physical > interface on the network node? Neutron complains loudly when I try to do > this, so I suspect the answer is an emphatic NO.
If you already have a flat network associated with a provider bridge, you will be unable to associate another to that bridge. You would need a separate bridge configured on the host, along with a corresponding label in the Neutron config, before you could create this second flat network. > * is a GRE tunnel still used for a simple flat network between the compute > nodes and the network node? You can still leverage GRE for tenant networks, connect them to a router, and have the external router interface connected to the new flat network (as long as external=true). This works in Icehouse and beyond. > when I bring up a separate external interface (call this br-ex2) and try to > create the simple flat network using this physical interface, then when I try > to boot an instance it fails with a “No available host” found”, with errors > also in the nova-conductor log regarding vif interface mapping problems. If you are attempting to connect instances directly to this flat network, rather than a GRE network, you would need to create the bridge on every compute node. The bridge label must be consistent among the hosts, but the bridge interface mapped to the label can vary. You can get creative with how these flat bridges are created. Typically, one might expect a bridge to contain a physical interface (ie. eth2) and allow Neutron to tag traffic (vlan) or not tag traffic (flat). The latter requires the use of a native vlan on the trunk. I have seen folks create multiple bridges and add host-level vlan interfaces to them so that they could create multiple “flat” networks in Neutron. To me, this defeats the purpose of having Neutron manage tagging and I don’t recommend it. Let me know if this didn’t address your questions. James > On Jan 13, 2015, at 8:14 PM, Ross Lillie <ross.lil...@motorolasolutions.com> > wrote: > > All, > > I’ve just upgraded our cloud from Havana to Juno. > > I’ve succeeded in configuring Neutron with a flat, external network and > individual tenants can attach to it via a virtual router and floating > address, using GRE tunnels. However, I also need to configure a simple flat > network for a given tenant that maps directly to our campus network (i.e. > WAN). > > I’m having problems getting this configured correctly. Neutron is configured > entirely on its own node, with multiple interfaces: eth0 is attached to our > campus network and serves as the management interface, br-ex (eth2) is > attached to our campus backbone and is used to create the “external" flat > network, br-data (eth1) is attached to the cloud’s data network. Compute > nodes are configured with a single interface br-data (eth0). > > Now to create a simple flat network: > > * can I share the br-ex interface or do I need to use a separate physical > interface on the network node? Neutron complains loudly when I try to do > this, so I suspect the answer is an emphatic NO. > * when I bring up a separate external interface (call this br-ex2) and try > to create the simple flat network using this physical interface, then when I > try to boot an instance it fails with a “No available host” found”, with > errors also in the nova-conductor log regarding vif interface mapping > problems. > > I had this working in Havana using VLAN networks, but can’t seem to get > things working with GRE tunnels. > > Any tips/pointers would be appreciated > — > Ross Lillie, Motorola Solutions > CTO, SST, Applications & Services Research > > > > _______________________________________________ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
