Hello Authors of https://datatracker.ietf.org/doc/rfc8584/ and
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-fast-df-recovery
I have a query regarding the following use-case which I could not find
supported with existing DF-election procedures.
Scenario:
All PE (Vtep1 and Vtep2 in belo
Hi Saumya,
To be clear, your query has nothing to do with the two documents you refer to.
In fact I don’t see any issue related to multihoming.
Given that in your example host-1 and FW-1 are directly connected to the same
leaf, and host-2 and FW-2 are connected to the same leaf too, I can see yo
Thanks a lot for a prompt reply Jorge.
Well I missed drawing the Host(s) behind the remote Vtep (PE) assuming that it
will not make any difference (except aliasing as you mentioned).
FW1 and FW2 can be attached to the same all-active ES
How to handle the broadcast packets like ARP request f
For the first case, again, for the local hosts, local bias makes sure the ARP
requests go only to the local FW, i.e. host-1 ARP Requests goes to FW-1 only,
irrespective of the DF state.
For the second case, I don’t understand. When the local FW goes down, the local
static MAC disappears and the
Thanks Again Rabadan and apology for the confusion.
As I mentioned I should have added first_hop vtep/PE for Host1/2 as well,
to reflect that reachability to firewall from the host(s) is across the Overlay
(EVPN fabric).
I have redone the topology to show host1 and host2 behind first hop vteps
About this:
the local static MAC disappears
As I have observed in few implementations that static MACs are admin-configured
(other than control-plane published with sticky-bit).
So will need a admin intervention to clean them up.
In the implementations I know, the static mac is configured
>>> the static mac is configured associated to an interface and conditionally
>>> active based on the oper-status of the interface
Ack on that and that's pretty organic (tying it to the interface/AC state).
But it may not solve the case where other hosts (other than firewall) are
behind the inter
I think you are saying that the FW can fail but it’s interface to the leaf is
oper-up. I don’t think the network can do anything to prevent traffic to that
interface then.
And of course, in your new diagram local bias does not play. As I said, local
bias works in the previous diagram.
Those new
If you still want to control the unicast and BUM flows to one FW or the
other depending on the leaf, you can still do it but that's implementation
specific since it relies on the route selection in vtep_host1 and
vtep_host2.
+1 on the implementation part. It's good to have f
