Re: Questions about HWVTEP
|
Ravi Shankar S
Hi,
Added inline comments
Regards, Ravi
From: Sumit Garg [mailto:sumit@...]
Sent: Thursday, August 20, 2015 8:48 PM To: Sabapathy, Ravi <Ravi_Sabapathy@...>; dayavanti.gopal.kamath@...; shague@...; vishal.thapar@... Cc: ovsdb-dev@...; ravindra.kenchappa@... Subject: Re: [ovsdb-dev] Questions about HWVTEP
I'm confused.
Why is the MAC of the TEP (tunnel end point) IP needed for creating the VXLAN tunnel?
<Ravi>Consider the below example
There is vxlan between 2 hardware VTEP’s which is controlled by ODL. In the hardware gateway 1, resolving (ARP/MAC resolution) 10.0.0.2 is the functionality of underlay network and that is understood.
Suppose the link between the 2 hardware gateway is down. The OVSDB connection between hardware gateway 1 and controller is up (Similarly for hardware gateway 2). Now if the controller tries to configure vxlan in the hardware gateway, it will be successful since it is an overlay connection. My previous understanding was that , the vxlan creation itself will fail because underlay connection was down which wasn’t correct. Thanks for giving clarity on this.
TEP-IP is published in the hardware_vtep schema (Physical_Switch table). It is also published in the LOCAL_MAC tables.
TEP-IP (and it's MAC) is part of the underlay network. IMO, overlay orchestration layer (openstack, ODL etc) doesn't configure & manage the underlay. That happens using some other means – e.g. CLI for hardware switches, GUI/Config files for hypervisors (ESX, linux hosts etc).
--
From: "Ravi_Sabapathy@..." <Ravi_Sabapathy@...>
Hi Daya,
I have a general query in Hardware VTEP use case in hardware switch,
Case 1 : The VxLAN tunnel should be created in the hardware switch only after the tunnel end point IP’s ARP is resolved. The modules that interacts with OVSDB server and program the hardware should take care of resolving the ARP.
Case 2: The hardware switch can use L3 protocol to advertise the tunnel end point IP to other end of the tunnel end point and vice versa.
For example, The tunnel IP can be a loopback IP and this IP can be advertised to other end of the tunnel end point (by using BGP/OSPF protocols) and vice versa. After this the MAC will be resolved and the VxLAN tunnel will be created.
Correct me if my wrong for the above use case. Regards, Ravi
From: Dayavanti Gopal Kamath [mailto:dayavanti.gopal.kamath@...]
We discussed this in a community meeting just after the summit. the schema I think basically assumes macs will be unique, (since it is keyed by mac addr). andre also suggested it would be ok to assume uniqueness for now, since one openstack instance typically does not re-use macs across the vm’s. long term, we all agreed we need to change the table such that the key is mac+logical switch, but for now, we are going ahead with this assumption to get something working.
Thanks, daya
From:Ravi_Sabapathy@... [mailto:Ravi_Sabapathy@...]
Added in line comments.
Regards, Ravi Shankar
From:ovsdb-dev-bounces@... [mailto:ovsdb-dev-bounces@...] On Behalf Of Sam Hague
On Thu, Aug 20, 2015 at 4:22 AM, Vishal Thapar <vishal.thapar@...> wrote:
I thought some of this would happen via ovsdb. The switch would learn it's local macs as normal and populate it's local ovsdb macs. Then these entries would get pushed as remote macs in the other ovsdb tables - via the hwvtep netvirt.
|
