Sorry to ask a stupid question. Whose implementation?
The reason I ask is that as far as I can tell, since the tenant does not
have any control access to the VTEP, there is no reason for the VTEP to
have a MAC address in the tenant space. Yes, the device has a physical
MAC address. But the tenant could well be using that MAC address. Yes,
they would be violating the Ethernet spec. But the whole point of
segregation is not to care about such issues.
On the other hand, if you tell me that the VMWare implementation has an
Ethernet address that is part of the tenant space, well, they made up
this particular game.
Yours,
Joel
On 7/31/2019 1:44 PM, Santosh P K wrote:
I have checked with implementation in data path. When we receive a
packet with valid VNI then lookup for MAC will happen and it is VTEP own
MAC then it will be trapped to control plane for processing. I think we
can have following options
1. Optional managment VNI
2. Mandatory inner MAC set to VTEP mac
3. Inner IP TTL set to 1 to avoid forwarding of packet via inner IP
address.
Thoughts?
Thansk
Santosh P K
On Wed, Jul 31, 2019 at 9:20 AM Greg Mirsky <[email protected]
<mailto:[email protected]>> wrote:
Hi Dinesh,
thank you for your consideration of the proposal and questions. What
would you see as the scope of testing the connectivity for the
specific VNI? If it is tenant-to-tenant, then VTEPs will treat these
packets as regular user frames. More likely, these could be Layer 2
OAM, e.g. CCM frames. The reason to use 127/8 for IPv4, and
0:0:0:0:0:FFFF:7F00:0/104 for IPv6 is to safeguard from leaking
Ethernet frames with BFD Control packet to a tenant.
You've suggested using a MAC address to trap the control packet at
VTEP. What that address could be? We had proposed using the
dedicated MAC and VTEP's MAC and both raised concerns among VXLAN
experts. The idea of using Management VNI may be more acceptable
based on its similarity to the practice of using Management VLAN.
Regards,
Greg
On Wed, Jul 31, 2019 at 12:03 PM Dinesh Dutt <[email protected]
<mailto:[email protected]>> wrote:
Hi Greg,
As long as the inner MAC address is such that the packet is
trapped to the CPU, it should be fine for use as an inner MAC is
it not? Stating that is better than trying to force a management
VNI. What if someone wants to test connectivity on a specific
VNI? I would not pick a loopback IP address for this since that
address range is host/node local only. Is there a reason you're
not using the VTEP IP as the inner IP address ?
Dinesh
On Wed, Jul 31, 2019 at 5:48 AM Greg Mirsky
<[email protected] <mailto:[email protected]>> wrote:
Dear All,
thank you for your comments, suggestions on this issue,
probably the most challenging for this specification. In the
course of our discussions, we've agreed to abandon the
request to allocate the dedicated MAC address to be used as
the destination MAC address in the inner Ethernet frame.
Also, earlier using VNI 0 was changed from mandatory to one
of the options an implementation may offer to an operator.
The most recent discussion was whether VTEP's MAC address
might be used as the destination MAC address in the inner
Ethernet frame. As I recall it, the comments from VXLAN
experts equally split with one for it and one against. Hence
I would like to propose a new text to resolve the issue. The
idea is to let an operator select Management VNI and use
that VNI in VXLAN encapsulation of BFD Control packets:
NEW TEXT:
An operator MUST select a VNI number to be used as
Management VNI. VXLAN packet for Management VNI MUST NOT
be sent to a tenant. VNI number 1 is RECOMMENDED as the
default for Management VNI.
With that new text, what can be the value of the destination
MAC in the inner Ethernet? I tend to believe that it can be
anything and ignored by the reciever VTEP. Also, if the
trapping is based on VNI number, the destination IP address
of the inner IP packet can from the range 127/8 for IPv4,
and for IPv6 from the range 0:0:0:0:0:FFFF:7F00:0/104. And
lastly, the TTL to be set to 1 (no change here).
Much appreciate your comments, questions, and suggestions.
Best regards,
Greg
