Re: Questions about HWVTEP
|
Kenchappa, Ravindra <ravindra.kenchappa@...>
Hi Vishal,
For question (1), as SAM mentioned hw-vtep netvirt provider should make sure that a barematel mac (ucast_mac_local) learnt on one device (running hardware_vtep) is added to ucast_macs_remote table of all the VTEP’s (physical device, compute nodes) which are part of same logical network (VNI).
For question (2), Ravi Shankar had explained correctly. Same MAC address are not a part of same logical network. Here is Ucast_Macs_Local table and other table entries looks like:
Ucast_Macs_Local table MAC _uuid ipaddr locator logical_switch ------------------- ------------------------------------ ------ ------------------------------------ ------------------------------------ "2c:41:38:88:0b:37" c6f79c66-ca8a-4ef4-8af4-b60a2c456f5a "" bb8a1122-6dca-4e8d-b8b4-2a8c7dfd236a a2749813-3ccf-4a78-8a9e-f3c810b6e6ec "2c:41:38:88:0b:67" 6758cef3-1367-4a79-8f55-ff15b1099a1f "" bb8a1122-6dca-4e8d-b8b4-2a8c7dfd236a a2749813-3ccf-4a78-8a9e-f3c810b6e6ec
Physical_Locator table _uuid dst_ip encapsulation_type ------------------------------------ --------------- ------------------ bb8a1122-6dca-4e8d-b8b4-2a8c7dfd236a "105.30.12.103" "vxlan_over_ipv4" 09826895-5d14-4395-9cfd-2ef3eac9dafa "105.30.12.23" "vxlan_over_ipv4"
Logical_Switch table _uuid description name tunnel_key ------------------------------------ ----------- -------------------------------------- ---------- a2749813-3ccf-4a78-8a9e-f3c810b6e6ec "LS1" "c9fec413-5a65-461d-a261-197ad3cbc9e4" 100
Thanks, Raveek
From: Ravi_Sabapathy@... [mailto:Ravi_Sabapathy@...]
Sent: Friday, August 21, 2015 1:35 AM To: sumit@...; dayavanti.gopal.kamath@...; shague@...; vishal.thapar@... Cc: ovsdb-dev@...; Kenchappa, Ravindra Subject: RE: [ovsdb-dev] Questions about HWVTEP
Hi,
Added inline comments
Regards, Ravi
From: Sumit Garg [mailto:sumit@...]
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.
|
