Re: BFD over VXLAN: Trapping BFD Control packet at VTEP
Dinesh Dutt <didutt@gmail.com> Sat, 03 August 2019 00:56 UTC
Return-Path: <didutt@gmail.com>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20A87120024; Fri, 2 Aug 2019 17:56:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cnXjCt0TzLuI; Fri, 2 Aug 2019 17:55:58 -0700 (PDT)
Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com [IPv6:2a00:1450:4864:20::343]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AFCB120046; Fri, 2 Aug 2019 17:55:58 -0700 (PDT)
Received: by mail-wm1-x343.google.com with SMTP id v15so69527509wml.0; Fri, 02 Aug 2019 17:55:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AazQVK2oBD2iGIYFuwnqy/eZwdLjgYzTEf4mh7cTqnw=; b=n6ed7w9lmipyA5T8y/jfzhyoAkm35FLsJvaU3hya4tLQcgZ7OhYcbWPEgOq0SeDrVQ zUhwfZIii4TMowqSI5lvWouCvQ0hL4t3p+Usfpif0Vt9v4pbZBlMzq3r5yKSzZM9rE7T QNAwZ8c84KOd8Y/fdBNxbLMpYgbhJM+pL3/V+ceDzXnRxo9b3E4FQ1supTFnB1fY5Ewx zPSTqEpkmBbFbKzBkMgF5aWnaZOT+pq2lBO/Y+VkPaWoO3RRzHVVc1GtZvDVOuAxidzV hynaPGNRdWA1xIApGSK8ts8oQpead+PSMVr+aCpbDCLjRQnZmMbOS9QkfhTEbFVtwje5 sO4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AazQVK2oBD2iGIYFuwnqy/eZwdLjgYzTEf4mh7cTqnw=; b=kdRFwkeaPUoTO3a6kv7WjjC2BuQjTCe1F79cWrVKLHjrXuII4diHKRmF1QLpNeTsoy 2JbSxoo/E0nKUDrf5dseFVWrMx0GVF9CWI1F59Pn22Kjqg+Qkh3qzoy16uS0YeGnv7Jf KeZ0x0cee2StzOujQfYu434UE+UoL8P4BOctGufNFnhaRKTOrQGCDa/O++dWuBl9Hrd6 +STAKGpE3Qug6PuEYHvtNTeUlD+Sv9RpYtjzOybBSOti/txM3B7/Eq3abLwQgu6hkgBc ++kz2YiZahIdIX1WlV5UUPdAAkdg7TFbUyQS7NwboP7BiKC6+Uf0/dARlEqnS30bVcaE y7qg==
X-Gm-Message-State: APjAAAVgKOgwVeQ3HTvnVvoY+GoWSMY7lBAl9So9MWif7qNCu4SlkkWl jHHMU+hfCZszc/XkbPw/9eYPrLkmUavhXoy9msUlZ9fh
X-Google-Smtp-Source: APXvYqzkkya5ckjn9z6wrkzg8dGkrBNuCdCgm8a5d047KDROY+VOTyBMnTz3nZodJydaEwd8dHEGNJenM5lVDwiEouY=
X-Received: by 2002:a1c:a5c2:: with SMTP id o185mr6081096wme.172.1564792239256; Fri, 02 Aug 2019 17:30:39 -0700 (PDT)
MIME-Version: 1.0
References: <CA+RyBmW=byLBNfVQSdaEoMf-QnJtj13k788XhbZ9tqH4bcgqNQ@mail.gmail.com> <CAOPNUTBJztjmNgrDyHgMo8-nRazAaXACGJJZ6Lx8z8aRVBM+GA@mail.gmail.com> <CA+RyBmWrM3v37BO8O_VOGG-NJ+UbrtSVQ_2GwW0R+vLkxbtvHw@mail.gmail.com> <CACi9rdvKTLwBQn9mcJksGTW79QTFj0d45DOpDT1Jee4QpGnv3Q@mail.gmail.com> <c57a3cf3-ab77-99df-0f78-104edef3275c@joelhalpern.com> <CACi9rdubTnzgCVZK0syRf3fsrpTU45SpQV57n2rNcNCqk+3+7Q@mail.gmail.com> <CACi9rdsmP8SFwP+Her45XKFwQZ3SQgwLpr62kAY-kP4vZtnFnQ@mail.gmail.com> <CAOPNUTD4nQ4YROxUA9hxdTFOtv4XpmazA=apm2ceuCxt3yM=XA@mail.gmail.com> <bf019ac6-2580-7f9e-66c4-5a24c1b2eb2b@joelhalpern.com> <CAOPNUTC=q4O=QUhFFiuv8UnU1uuCjHYkJV-Oha07NTJ_X7SODQ@mail.gmail.com> <7437a61e-133c-c53e-fd1d-c3a31e4e90a9@joelhalpern.com> <CAOPNUTB+fNXmB8jctUrVh5aAYd-R=CC6cv=1QpzMoYcVs0EUtw@mail.gmail.com> <df39e2b9-598a-5121-525c-f435d72e2184@joelhalpern.com>
In-Reply-To: <df39e2b9-598a-5121-525c-f435d72e2184@joelhalpern.com>
From: Dinesh Dutt <didutt@gmail.com>
Date: Fri, 02 Aug 2019 17:30:27 -0700
Message-ID: <CAOPNUTDHu2Ywy2=1eNzM-1jAmSOxOrHXGC2uZ3x7jVb7+vhoig@mail.gmail.com>
Subject: Re: BFD over VXLAN: Trapping BFD Control packet at VTEP
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Cc: Santosh P K <santosh.pallagatti@gmail.com>, Greg Mirsky <gregimirsky@gmail.com>, rtg-bfd WG <rtg-bfd@ietf.org>, "T. Sridhar" <tsridhar@vmware.com>, bfd-chairs@ietf.org, Martin Vigoureux <martin.vigoureux@nokia.com>, draft-ietf-bfd-vxlan@ietf.org
Content-Type: multipart/alternative; boundary="000000000000917b65058f2b95f8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/a2IAW19Lay0Lt6lX2ad-P2rndro>
X-Mailman-Approved-At: Sat, 03 Aug 2019 10:13:29 -0700
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Aug 2019 00:56:03 -0000
What is the stated purpose of this BFD session? The VTEP reachability is determined by the underlay, I don't need VXLAN-encaped packet for that. Do we agree? If I want to test the VXLAN encap/decap functionality alone, picking any single VNI maybe fine. But is this all any network operator wants? Why? In what situations has this been a problem? I suspect operators also want to verify path continuity over a specific VNI. If you say this is not defined by the document, I disagree because the current version talks about controlling the number of BFD sessions between the VTEPs (see section 3). More importantly, this is a real problem that operators like to verify. Dinesh On Fri, Aug 2, 2019 at 5:08 PM Joel M. Halpern <jmh@joelhalpern.com> wrote: > What is special about the management VNI is precisely that it is NOT a > tenant VNI. The VxLAN administration does know how it allocates VNI to > tenants, and which VNI it has allocated. In contrast, it does not know > which IP addresses or MAC adddresses teh tenant is using or may plan to > use. > > Yours, > Joel > > On 8/2/2019 6:41 PM, Dinesh Dutt wrote: > > The assumption of an IP address within any VNI is suspect that way. > > What's special about a single VNI, the management VNI? The VTEP IP > > address does not belong in reality in any VNI. > > > > Dinesh > > > > On Fri, Aug 2, 2019 at 3:17 PM Joel M. Halpern <jmh@joelhalpern.com > > <mailto:jmh@joelhalpern.com>> wrote: > > > > Your response seems to miss two points: > > > > First, the problem you describe is not what the document says it is > > solving. To the degree it discusses it at all, the document says " > > In > > most cases, a single BFD session is sufficient for the given VTEP to > > monitor the reachability of a remote VTEP, regardless of the number > of > > VNIs in common. " > > > > Second, you assume the existence of an IP address for a VTEP within a > > VNI. As with the MAC address, the VTEP does not have an IP address > > within the VNI. Some implementations may have created such a thing, > > but > > the general construct, as defined to date, does not support such. > > > > In short, you are requiring a behavior that violates the > architectural > > structure of overlay / underlay separation, and common usage. And > you > > are doing so to support a use case that the working group has not > > indicated in the document as important. > > > > Yours, > > Joel > > > > On 8/2/2019 5:01 PM, Dinesh Dutt wrote: > > > Joel, > > > > > > You understood correctly. > > > > > > The VNIs may not share fate due to misconfiguration. And I > strongly > > > suspect someone will want to use BFD for that because its about > > checking > > > path continuity as stated by the draft. As long as there's a > > valid IP > > > (because it's BFD) owned by the VTEP in that VNI, you can use BFD > in > > > that VNI. Thats all that you need to dictate. That IP address > > has a MAC > > > address and you can use that on the inner frame. That is all > normal > > > VXLAN processing. The outer IP is always that of the VTEP. > > > > > > Dinesh > > > > > > On Fri, Aug 2, 2019 at 11:03 AM Joel M. Halpern > > <jmh@joelhalpern.com <mailto:jmh@joelhalpern.com> > > > <mailto:jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>>> wrote: > > > > > > 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 > > > > <santosh.pallagatti@gmail.com > > <mailto:santosh.pallagatti@gmail.com> > > > <mailto:santosh.pallagatti@gmail.com > > <mailto:santosh.pallagatti@gmail.com>> > > > <mailto:santosh.pallagatti@gmail.com > > <mailto:santosh.pallagatti@gmail.com> > > > <mailto:santosh.pallagatti@gmail.com > > <mailto:santosh.pallagatti@gmail.com>>>> 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 > > > > <santosh.pallagatti@gmail.com > > <mailto:santosh.pallagatti@gmail.com> > > > <mailto:santosh.pallagatti@gmail.com > > <mailto:santosh.pallagatti@gmail.com>> > > > <mailto:santosh.pallagatti@gmail.com > > <mailto:santosh.pallagatti@gmail.com> > > > <mailto:santosh.pallagatti@gmail.com > > <mailto:santosh.pallagatti@gmail.com>>>> > > > > 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 > > > > <jmh@joelhalpern.com <mailto:jmh@joelhalpern.com> > > <mailto:jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>> > > > <mailto:jmh@joelhalpern.com <mailto:jmh@joelhalpern.com> > > <mailto:jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>>>> 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 > > > > <gregimirsky@gmail.com > > <mailto:gregimirsky@gmail.com> <mailto:gregimirsky@gmail.com > > <mailto:gregimirsky@gmail.com>> > > > <mailto:gregimirsky@gmail.com <mailto:gregimirsky@gmail.com> > > <mailto:gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>>> > > > > > <mailto:gregimirsky@gmail.com > > <mailto:gregimirsky@gmail.com> > > > <mailto:gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>> > > > > <mailto:gregimirsky@gmail.com > > <mailto:gregimirsky@gmail.com> > > > <mailto:gregimirsky@gmail.com > > <mailto:gregimirsky@gmail.com>>>>> 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 > > > > <didutt@gmail.com <mailto:didutt@gmail.com> > > <mailto:didutt@gmail.com <mailto:didutt@gmail.com>> > > > <mailto:didutt@gmail.com <mailto:didutt@gmail.com> > > <mailto:didutt@gmail.com <mailto:didutt@gmail.com>>> > > > > > <mailto:didutt@gmail.com > > <mailto:didutt@gmail.com> > > > <mailto:didutt@gmail.com <mailto:didutt@gmail.com>> > > <mailto:didutt@gmail.com <mailto:didutt@gmail.com> > > > <mailto:didutt@gmail.com <mailto:didutt@gmail.com>>>>> > > > > 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 > > > > > <gregimirsky@gmail.com > > <mailto:gregimirsky@gmail.com> > > > <mailto:gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>> > > > > <mailto:gregimirsky@gmail.com > > <mailto:gregimirsky@gmail.com> > > > <mailto:gregimirsky@gmail.com > > <mailto:gregimirsky@gmail.com>>> <mailto:gregimirsky@gmail.com > > <mailto:gregimirsky@gmail.com> > > > <mailto:gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>> > > > > <mailto:gregimirsky@gmail.com > > <mailto:gregimirsky@gmail.com> > > > <mailto:gregimirsky@gmail.com > > <mailto:gregimirsky@gmail.com>>>>> 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 > > > > > > > > > > > > > > >
- BFD over VXLAN: Trapping BFD Control packet at VT… Greg Mirsky
- Re: BFD over VXLAN: Trapping BFD Control packet a… Greg Mirsky
- Re: BFD over VXLAN: Trapping BFD Control packet a… Dinesh Dutt
- Re: BFD over VXLAN: Trapping BFD Control packet a… Santosh P K
- Re: BFD over VXLAN: Trapping BFD Control packet a… Joel M. Halpern
- Re: BFD over VXLAN: Trapping BFD Control packet a… Santosh P K
- Re: BFD over VXLAN: Trapping BFD Control packet a… Joel M. Halpern
- Re: BFD over VXLAN: Trapping BFD Control packet a… Dinesh Dutt
- Re: BFD over VXLAN: Trapping BFD Control packet a… Greg Mirsky
- Re: BFD over VXLAN: Trapping BFD Control packet a… Greg Mirsky
- Re: BFD over VXLAN: Trapping BFD Control packet a… Dinesh Dutt
- Re: BFD over VXLAN: Trapping BFD Control packet a… Dinesh Dutt
- Re: BFD over VXLAN: Trapping BFD Control packet a… Santosh P K
- Re: BFD over VXLAN: Trapping BFD Control packet a… Dinesh Dutt
- Re: BFD over VXLAN: Trapping BFD Control packet a… Joel M. Halpern
- Re: BFD over VXLAN: Trapping BFD Control packet a… Joel M. Halpern
- Re: BFD over VXLAN: Trapping BFD Control packet a… Dinesh Dutt
- Re: BFD over VXLAN: Trapping BFD Control packet a… Dinesh Dutt
- Re: BFD over VXLAN: Trapping BFD Control packet a… Joel M. Halpern
- Re: BFD over VXLAN: Trapping BFD Control packet a… Joel M. Halpern
- Re: BFD over VXLAN: Trapping BFD Control packet a… Dinesh Dutt
- Re: BFD over VXLAN: Trapping BFD Control packet a… Dinesh Dutt
- Re: BFD over VXLAN: Trapping BFD Control packet a… Dinesh Dutt
- Re: BFD over VXLAN: Trapping BFD Control packet a… Greg Mirsky
- Re: BFD over VXLAN: Trapping BFD Control packet a… Dinesh Dutt
- Re: BFD over VXLAN: Trapping BFD Control packet a… Greg Mirsky
- Re: BFD over VXLAN: Trapping BFD Control packet a… Dinesh Dutt
- Re: BFD over VXLAN: Trapping BFD Control packet a… Greg Mirsky
- Re: BFD over VXLAN: Trapping BFD Control packet a… Dinesh Dutt
- Re: BFD over VXLAN: Trapping BFD Control packet a… Greg Mirsky
- Re: BFD over VXLAN: Trapping BFD Control packet a… Dinesh Dutt
- Re: BFD over VXLAN: Trapping BFD Control packet a… Greg Mirsky
- Re: BFD over VXLAN: Trapping BFD Control packet a… T. Sridhar
- Re: BFD over VXLAN: Trapping BFD Control packet a… Santosh P K
- Re: BFD over VXLAN: Trapping BFD Control packet a… Greg Mirsky
- Re: BFD over VXLAN: Trapping BFD Control packet a… Santosh P K
- Re: BFD over VXLAN: Trapping BFD Control packet a… Santosh P K
- Re:BFD over VXLAN: Trapping BFD Control packet at… xiao.min2
- Re: BFD over VXLAN: Trapping BFD Control packet a… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re:[nvo3] BFD over VXLAN: Trapping BFD Control pa… xiao.min2
- Re:[nvo3] BFD over VXLAN: Trapping BFD Control pa… xiao.min2
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re:[nvo3] BFD over VXLAN: Trapping BFD Control pa… xiao.min2
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: BFD over VXLAN: Trapping BFD Control packet a… Santosh P K
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Santosh P K
- Re:[nvo3] BFD over VXLAN: Trapping BFD Control pa… xiao.min2
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re:BFD over VXLAN: Trapping BFD Control packet at… xiao.min2
- Re:[nvo3] BFD over VXLAN: Trapping BFD Control pa… xiao.min2
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel M. Halpern
- Re:[nvo3] BFD over VXLAN: Trapping BFD Control pa… xiao.min2
- Re:[nvo3] BFD over VXLAN: Trapping BFD Control pa… xiao.min2
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re:[nvo3] BFD over VXLAN: Trapping BFD Control pa… xiao.min2
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re:[nvo3] BFD over VXLAN: Trapping BFD Control pa… xiao.min2
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re:[nvo3] BFD over VXLAN: Trapping BFD Control pa… xiao.min2
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re:[nvo3] BFD over VXLAN: Trapping BFD Control pa… xiao.min2
- Re: BFD over VXLAN: Trapping BFD Control packet a… Jeffrey Haas
- Re: BFD over VXLAN: Trapping BFD Control packet a… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Greg Mirsky
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel M. Halpern
- RE: [nvo3] BFD over VXLAN: Trapping BFD Control p… John E Drake
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Greg Mirsky
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Greg Mirsky
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel Halpern Direct
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Dinesh Dutt
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Dinesh Dutt
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Dinesh Dutt
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Greg Mirsky
- Re:[nvo3] BFD over VXLAN: Trapping BFD Control pa… xiao.min2
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Dinesh Dutt
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Santosh P K
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Santosh P K
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Greg Mirsky
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Dinesh Dutt
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Greg Mirsky
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Dinesh Dutt
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Santosh P K
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Santosh P K
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Jeffrey Haas
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Dinesh Dutt
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Dinesh Dutt
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Dinesh Dutt
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Jeffrey Haas
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Dinesh Dutt
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Greg Mirsky
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Jeffrey Haas
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Selvakumar Sivaraj
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Greg Mirsky
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Greg Mirsky
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Jeffrey Haas
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Selvakumar Sivaraj
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Greg Mirsky
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Jeffrey Haas
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Greg Mirsky
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Santosh P K