My answers below are from the perspective of normal (non-routed)
networks implemented in ML2. The support for routed networks should
build on this without breaking it.
On 3/29/16 3:38 PM, Miguel Lavalle wrote:
Hi,
I am writing a patchset to build a mapping between hosts and network
segments. The goal of this mapping is to be able to say whether a host
has access to a given network segment. I am building this mapping
assuming that if a host A has a bridges mapping containing 'physnet 1'
and a segment has 'physnet 1' in its 'physical_network' attribute,
then the host has access to that segment.
1) Is this assumption correct? Looking at method
check_segment_for_agent in
http://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/ml2/drivers/mech_agent.py#n180
seems to me to suggest that my assumption is correct?
This is true for certain agent-based mechanism drivers, but cannot be
assumed to be the case for all mechanism drivers (even all those that
use agents. Any use of mapping info (i.e. from agents_db or elsewhere)
is specific to an individual mechanism driver. I'd strongly recommend
that any functionality trying to make decisions based on connectivity do
so by calling into the registered mechanism drivers, so they can decide
whether whatever they manage has connectivity.
Also note that connectivity may involve hierarchical port binding, in
which case you really need to try to bind a port to determine if you
have connectivity. I'm not suggesting that there is a requirement to mix
HPB and routed networks, but please try not to build assumptions into
ML2 plugin code that don't work with HPB or that are only valid for a
subset of mechanism drivers.
2) Furthermore, when a segment is mapped to a physical network, is
there a one to one relationship between segments and physical nets?
Certainly different virtual networks can map to different segments (i.e.
VLANs) on the same physical network. It is even possible for the same
virtual network to have multiple segments on the same physical network.
-Bob
Thanks
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
