If I am reading your various emails correctly Dinesh (and I may have
missed something) you are trying to use the MAC address because you want
to be able to send these BFD packets over arbitrary VNI to monitor the
VNI. That is not a requirement identified in the document. It is not
even a problem I understand, since all the VNI between an ingress and
egress VTEP share fate.
Yours,
Joel
On 8/2/2019 1:44 PM, Dinesh Dutt wrote:
Thanks for verifying this. On Linux and hardware routers that I'm aware
of (Cisco circa 2012 and Cumulus), the physical MAC address is reused
across the VNIs on the VTEP. Did you check on a non-VMW device? This is
more for my own curiosity.
To address the general case, can we not define a well-known (or reserve
one) unicast MAC address for use with VTEP? If the MAC address is
configurable in BFD command, this can be moot.
Dinesh
On Fri, Aug 2, 2019 at 10:27 AM Santosh P K
<[email protected] <mailto:[email protected]>> wrote:
I have cross checked point raised about MAC address usage. It is
possible that tenant could be using physical MAC address and when a
packet comes with valid VNI with a MAC address that is being used by
tenant then packet will be sent to that tenant. This rules out the
fact that we could use physical MAC address as inner MAC to ensure
packets get terminated at VTEP itself.
Thanks
Santosh P K
On Wed, Jul 31, 2019 at 11:00 AM Santosh P K
<[email protected] <mailto:[email protected]>>
wrote:
Joel,
Thanks for your inputs. I checked implementation within
Vmware. Perhaps I should have been more clear about MAC address
space while checking internally. I will cross check again for
the same and get back on this list.
Thanks
Santosh P K
On Wed, Jul 31, 2019 at 10:54 AM Joel M. Halpern
<[email protected] <mailto:[email protected]>> wrote:
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]>
> <mailto:[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]>
> <mailto:[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]> <mailto:[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
>
