Open Stack

I think you will want to write an ML2 mechanism driver for your appliance
so it can receive all port/network/subnet information that you can forward
onto your appliance.

To automatically have Neutron's l2pop mechanism setup tunnels on the agent
to point to your appliance, you need to register the appliance in the
Neutron db as an agent with the IP address of the appliance and a unique
hostname to identify it. Then whenever you create a neutron port with the
hostname of your appliance, the other L2 agents in Neutron will be informed
by L2pop of the IP address of your appliance to setup a forwarding entry to
it.


On Mon, Feb 1, 2016 at 10:00 AM, Vijay Venkatachalam <
Vijay.Venkatachalam at citrix.com> wrote:

>
>
> L2GW seems like a good option for bridging/linking /integrating physical
> appliances which does not support overlay technology (say VXLAN) natively.
>
>
>
> In my case the physical appliance supports VXLAN natively, meaning it can
> act as a VTEP. The appliance is capable of decapsulating packets that are
> received and encapsulating packets that are sent (looking at the forwarding
> table).
>
>
>
> Now we want to add the capability in the  middleware/controller so that
> forwarding tables in the appliance can be populated and also let the rest
> of infrastructure know about the physical appliance (VTEP) and its L2 info?
>
>
>
> Is it possible to achieve this?
>
>
>
> Thanks,
>
> Vijay V.
>
>
>
>
>
>
>
> *From:* Gal Sagie [mailto:gal.sagie at gmail.com]
> *Sent:* 01 February 2016 19:38
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev at lists.openstack.org>
> *Subject:* Re: [openstack-dev] [Neutron] Integrating physical appliance
> into virtual infrastructure
>
>
>
> There is a project that aims at solving your use cases (at least from a
> general view)
>
> Its called L2GW and uses OVSDB Hardware VTEP schema (which is supported by
> many physical appliances for switching capabilities)
>
>
>
> Some information: https://wiki.openstack.org/wiki/Neutron/L2-GW
>
>
>
> There are also other possible solutions, depending what you are trying to
> do and what is the physical applicance job.
>
>
>
>
>
>
>
> On Mon, Feb 1, 2016 at 3:44 PM, Vijay Venkatachalam <
> Vijay.Venkatachalam at citrix.com> wrote:
>
> Hi ,
>
>
>
> How to integrate a physical appliance into the virtual OpenStack
> infrastructure (with L2 population)? Can you please point me to any
> relevant material.
>
>
>
> We want to add the capability to “properly” schedule the port on the
> physical appliance, so that the rest of the virtual infrastructure knows
> that a new port is scheduled in the physical appliance.  How to do this?
>
>
>
> We manage the appliance through a middleware. Today, when it creates a
> neutron port, that is to be hosted on the physical appliance, the port is
> dangling.  Meaning, the virtual infrastructure does not know where this
> port is hosted/implemented. How to fix this?
>
>
>
> Also, we want the physical appliance plugged into L2 population mechanism.
> Looks like the L2 population driver is distributing L2 info to all virtual
> infrastructure nodes where a neutron agent is running. Can we leverage this
> framework? We don’t want to run the neutron agent in the physical
> appliance, can it run in the middle ware?
>
>
>
> Thanks,
>
> Vijay V.
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
>
> --
>
> Best Regards ,
>
> The G.
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160203/7dca9f21/attachment.html>