Open Stack

Hi Gonzalo, 
from having a look, at the configuration reference [1], I see that the
bridge_mappings is only required in the [ovs] section [2] and not in the
ml2 configuration for vlan [3]. 


And also the code says, that the bridge_mappings attribute needs to be
in the [ovs] section.


You're talking about two configuration files. I guess the question is,
which config file is used by your services (neutron-openvswitch-agent
and  neutron-server)? You can find out via

# ps -ax | grep neutron- 


Maybe one of your files is not even used? Or maybe the neutron server
takes one and the openvswitch agent the other file. The relevant file is
the one that is used by openvswitch The attribute should be in there!

Just have a try! Change it in your config file, restart the neutron
services and check if it is still working.


When is it required? Always for vlan and flat networking in the data or
in the external network. But it's not  required for tunneling in the
datanetwork. I'm not sure about tunneling in the external network!! I'll
give you an example: 

Datanetwork = gre, External network=flat --> bridge_mappings specifies
the bridge for the external flat network. 

Datanetwork =vxlan, external network = vxlan --> I don't know! 

Datanetwork vlan, external network flat --> Bridges for both network
need to be specified



Hope this helps!


[1]
http://docs.openstack.org/juno/config-reference/content/section_networking-options-reference.html

[2]
http://docs.openstack.org/juno/config-reference/content/networking-plugin-openvswitch_agent.html

[3]
http://docs.openstack.org/juno/config-reference/content/networking-plugin-ml2_vlan.html
-- 
Andreas 
(irc: scheuran)


On Sun, 2014-12-14 at 22:39 +0100, Gonzalo Aguilar Delgado wrote:
> Hi again Uwe, 
> 
> 
> It makes sense for me. Since external networks are not used on
> compute-nodes. I must say that even configuring this without physical
> interface the VM on that machine has network access to the external
> network. 
> 
> 
> So I can suppose that in case this is for external network mapping,
> then it should only have effect in the neutron node. 
> 
> 
> But as said. Any light will be great.
> 
> 
> 
> 
> El dom, 14 de dic 2014 a las 9:25 , Uwe Sauter
> <uwe.sauter.de at gmail.com> escribió:
> > As far as I know, bridge_mapping is used to let neutron know which
> > bridge should be uses for the (possibly more than one) external
> > network(s). If someone else could jump in and give a bit more
> > detail, I'd appreciate that, too. Regards, Uwe Am 14.12.2014 um
> > 20:55 schrieb Gonzalo Aguilar Delgado: 
> >         Hi Uwe, really I started directly with neutron. Never gone
> >         with legacy. But I suppose there's old config laying around.
> >         I still think that bridge_mapping is needed for VLAN config
> >         I use. Every paper describes GRE config, but I still feel
> >         more confortable using VLANs. Any other help about this
> >         issue? Can someone confirm if I can get rid of the
> >         directives in both configs? I suppose I cannot because they
> >         get in effect when started the ovs plugin. Thank you in
> >         advance. El dom, 14 de dic 2014 a las 8:40 , Uwe Sauter
> >         <uwe.sauter.de at gmail.com> escribió: 
> >                 Hi, I presume that you upgraded from an older
> >                 version that used nova-network (now called legacy
> >                 networking). Using neutron means that VMs aren't
> >                 connected to br0 directly any more as there is a
> >                 whole virtual networking infrastructure in place. To
> >                 give a small overview: On a compute node a VM
> >                 connects to br-int (integration bridge). This bridge
> >                 itself is connected through a virtual cable to
> >                 br-tun (tunneling bridge). That bridge has also
> >                 assigned a physical interface that allows traffic to
> >                 flow to the network node On the network node there
> >                 also exists a br-tun that has a physical interface
> >                 attached. Through this inferface traffic enters the
> >                 node. br-tun is virtually connected to br-ex that
> >                 has a separate physical interface attached that
> >                 connects to "the outside", meaning the networking
> >                 infrastructure outside your cloud. I cannot help you
> >                 with the configuration issue but recommend that you
> >                 familiarize yourself with neutron. Regards, Uwe Am
> >                 14.12.2014 um 19:36 schrieb Gonzalo Aguilar Delgado:
> >                 Hi all, I'm installing a new compute node from
> >                 scratch and reviewing all old config. I've found two
> >                 setting that seems equal, one in ml2 plugin and one
> >                 in openvswitch. But I don't really understand why
> >                 they are. ovs_neutron_plugin.ini: bridge_mappings =
> >                 default:br0,extnet1:br-ex ml2/ml2_conf.ini: [ovs]
> >                 bridge_mappings = default:br0,extnet1:br-ex For me
> >                 it's strange the settings are in both places. I
> >                 think this is a result of upgrading without taking
> >                 much care of removing old config. But also it's
> >                 strange that everything works with the bridges br0
> >                 and br-ex without physical interface. I mean, seems
> >                 to do nothing but it needs to be there. Also I
> >                 should expect VM be attached to br0 (Default) but
> >                 it's not, they are attached to the br-int
> >                 (integration bridge), for me this is correct. Since
> >                 it's described here like this:
> >                 https://openstack.redhat.com/Networking_in_too_much_detail And works ok. So what's the purporse of these bridges? Here is: neutron 2.3.4 nova 2.17.0 Best regards, _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack at 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 at 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 at lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack