[openstack-dev] [Neutron][os-vif] Expanding vif capability for wiring trunk ports

Kevin Benton kevin at benton.pub
Wed Jun 15 21:30:56 UTC 2016


>I wouldn't say linux bridges are totally outside of its domain because it
relies on them for security groups.

It relies on a side effect of their existence - iptables rules being
applied to the veth interface. It does nothing to the actual linux bridge
itself. If there was a way to plug a veth directly between the VM and OVS
and have iptables be applied, there would be *no* code changes on the OVS
agent because it doesn't do anything with the bridge.

>then use the equivalent of "ovs-vsctl iface-to-br <peer name>" to get the
name of the bridge.

So then we have to have logic to guess which bridges connected by patch
ports 'belong' to trunk ports because we weren't explicit anywhere.

On Wed, Jun 15, 2016 at 11:01 AM, Peters, Rawlin <rawlin.peters at hpe.com>
wrote:

> On Tuesday, June 14, 2016 6:27 PM, Kevin Benton (kevin at benton.pub) wrote:
> > >which generates an arbitrary name
> >
> > I'm not a fan of this approach because it requires coordinated
> assumptions.
> > With the OVS hybrid plug strategy we have to make guesses on the agent
> side
> > about the presence of bridges with specific names that we never
> explicitly
> > requested and that we were never explicitly told about. So we end up
> with code
> > like [1] that is looking for a particular end of a veth pair it just
> hopes is
> > there so the rules have an effect.
>
> I don't think this should be viewed as a downside of Strategy 1 because, at
> least when we use patch port pairs, we can easily get the peer name from
> the
> port on br-int, then use the equivalent of "ovs-vsctl iface-to-br <peer
> name>"
> to get the name of the bridge. If we allow supporting veth pairs to
> implement
> the subports, then getting the arbitrary trunk bridge/veth names isn't as
> trivial.
>
> This also brings up the question: do we even need to support veth pairs
> over
> patch port pairs anymore? Are there any distros out there that support
> openstack but not OVS patch ports?
>
> >
> > >it seems that the LinuxBridge implementation can simply use an L2 agent
> > >extension for creating the vlan interfaces for the subports
> >
> > LinuxBridge implementation is the same regardless of the strategy for
> OVS. The
> > whole reason we have to come up with these alternative approaches for
> OVS is
> > because we can't use the obvious architecture of letting it plug into the
> > integration bridge due to VLANs already being used for network
> isolation. I'm
> > not sure pushing complexity out to os-vif to deal with this is a great
> > long-term strategy.
>
> The complexity we'd be pushing out to os-vif is not much worse than the
> current
> complexity of the hybrid_ovs strategy already in place today.
>
> >
> > >Also, we didn’t make the OVS agent monitor for new linux bridges in the
> > >hybrid_ovs strategy so that Neutron could be responsible for creating
> the veth
> > >pair.
> >
> > Linux Bridges are outside of the domain of OVS and even its agent. The
> L2 agent
> > doesn't actually do anything with the bridge itself, it just needs a veth
> > device it can put iptables rules on. That's in contrast to these new OVS
> > bridges that we will be managing rules for, creating additional patch
> ports,
> > etc.
>
> I wouldn't say linux bridges are totally outside of its domain because it
> relies
> on them for security groups. Rather than relying on an arbitrary naming
> convention between Neutron and Nova, we could've implemented monitoring
> for new
> linux bridges to create veth pairs and firewall rules on. I'm glad we
> didn't,
> because that logic is specific to that particular firewall driver, similar
> to
> how this trunk bridge monitoring would be specific to only vlan-aware-vms.
> I
> think the logic lives best within an L2 agent extension, outside of the
> core
> of the OVS agent.
>
> >
> > >Why shouldn't we use the tools that are already available to us?
> >
> > Because we're trying to build a house and all we have are paint brushes.
> :)
>
> To me it seems like we already have a house that just needs a little paint
> :)
>
> >
> >
> > 1.
> >
> https://github.com/openstack/neutron/blob/f78e5b4ec812cfcf5ab8b50fca62d1ae0dd7741d/neutron/agent/linux/iptables_firewall.py#L919-L923
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160615/3a4de2dc/attachment.html>


More information about the OpenStack-dev mailing list