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 for the firewaill
credentials ? ARP request (MAC_F) should to sent to the local vtep, which
should act as a DF.
The hairpinning of ARP request to remote DF (over WAN), should be avoided.
That's the reason it would be good to have two DFs for the {ESI, Bridge-domain}
in this scenario.
>>>> In the implementations that I know, the local static MAC will be preferred
>>>> over the EVPN MAC/IP route with the static bit, hence again you will have
>>>> the behavior you want
The static-mac approach has an issue, when the local firewall goes down, there
is no organic way to prefer/plumb the MAC_F published by remote vtep.
Thanks
Saumya.
From: Rabadan, Jorge (Nokia - US/Mountain View) [mailto:[email protected]]
Sent: Thursday, August 19, 2021 7:47 PM
To: Dikshit, Saumya <[email protected]>;
[email protected];
[email protected]
Cc: [email protected]
Subject: Re: Query to authors of draft-ietf-bess-evpn-fast-df-recovery and rfc
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 your
use-case resolved in two ways:
a) FW1 and FW2 can be attached to the same all-active ES, I assume local-bias
behavior as in RFC8365 (seems you are using VXLAN as data plane). Host-1 will
send unicast and BUM to FW-1. Host-2 will send unicast and BUM to FW-2. In case
of failure, the behavior will be as per your description. Note that a third
leaf with a local host will do aliasing to both, but since it seems you only
have directly connected leaf nodes, you are fine.
b) instead of attaching FW-1 and FW-2 to the same ES, EVPN allows 'static' MACs
that are advertised with the sticky bit set. You can configure MAC F as static
in the two leaf nodes. There is no mobility procedures for static MACs, hence
forwarding comes down to the local selection on each node. In the
implementations that I know, the local static MAC will be preferred over the
EVPN MAC/IP route with the static bit, hence again you will have the behavior
you want.. and again, only in your example with two directly connected leaf
nodes.
My 2 cents.
Thx
Jorge
From: Dikshit, Saumya <[email protected]<mailto:[email protected]>>
Date: Thursday, August 19, 2021 at 4:51 AM
To:
[email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>,
[email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>
Subject: Query to authors of draft-ietf-bess-evpn-fast-df-recovery and rfc
Hello Authors of
https://datatracker.ietf.org/doc/rfc8584/<https://datatracker.ietf.org/doc/rfc8584/>
and
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-fast-df-recovery<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 below example) routers attached to same ES and both
act as DF.
This is a typical case of distributed firewall (active/active) across fabrics
(sites),
Where in, the preferred firewall is the one local to the site, whereas, upon
failure,
packets need to be redirected (over WAN, via DCI/VPN) towards the remote site
firewall.
The firewall-device is connected to it's first-hop vtep over the same
bridge-domain and same ESI.
All in all, it's an emulated multi-homing scenario.
This is scenario of distributed firewall devices host same MAC credentials.
Simplistic example :
There are two sites, SITE-1 and SITE-2 in the below diagram.
Traffic (including BUM) generated by Host1 (in SITE-1) (for a bridge-domain)
should run through site-local firewall instance (firewall_1) preferably.
Only in case of local-outage, the traffic should be send across over WAN to the
remote firewall (firewall_2).
Same should apply to traffic generated by Host2 (in SITE-2), wherein,
it should preferably run through the local firewall (firewall_2) and over a
failure should go over the WAN towards firewall_1.
Vtep1/2 learn the firewall MAC (MAC_F) as local learning and also from the
remote Vtep2/1.
But since both the learnings are over the same ESI, it should not lead to MAC
move.
Cometh the local firewall failure, Vteps (1 or 2) should start redirecting the
traffic to remote SITE.
Any ARP request (BUM traffic) for firewall credentials landing at either Vtep1
or Vtep2 should be flooded to network towards the local firewall.
SITE-1 | SITE-2
------------------------------------------------------
Host1 | Host2
| | |
Vtep1 == ==WAN====== Vtep2
| | |
Firewall _1 | Firewall_2
(MAC_F) (MAC_F)
Please let me know if there is a way out (with out) using existing standards.
Thanks
Saumya.
-----Original Message-----
From: BESS [mailto:[email protected]] On Behalf Of
[email protected]<mailto:[email protected]>
Sent: Tuesday, July 6, 2021 8:31 PM
To: [email protected]<mailto:[email protected]>
Cc: [email protected]<mailto:[email protected]>
Subject: [bess] I-D Action: draft-ietf-bess-evpn-fast-df-recovery-02.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the BGP Enabled ServiceS WG of the IETF.
Title : Fast Recovery for EVPN DF Election
Authors : Patrice Brissette
Ali Sajassi
Luc Andre Burdet
John Drake
Jorge Rabadan
Filename : draft-ietf-bess-evpn-fast-df-recovery-02.txt
Pages : 11
Date : 2021-07-06
Abstract:
Ethernet Virtual Private Network (EVPN) solution provides Designated
Forwarder election procedures for multi-homing Ethernet Segments.
These procedures have been enhanced further by applying Highest
Random Weight (HRW) Algorithm for Designated Forwarded election in
order to avoid unnecessary DF status changes upon a failure. This
draft improves these procedures by providing a fast Designated
Forwarder (DF) election upon recovery of the failed link or node
associated with the multi-homing Ethernet Segment. The solution is
independent of number of EVIs associated with that Ethernet Segment
and it is performed via a simple signaling between the recovered PE
and each PEs in the multi-homing group.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-fast-df-recovery/<https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-fast-df-recovery/>
There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-fast-df-recovery-02<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-fast-df-recovery-02>
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-fast-df-recovery-02<https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-fast-df-recovery-02>
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/<ftp://ftp.ietf.org/internet-drafts/>
_______________________________________________
BESS mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/bess<https://www.ietf.org/mailman/listinfo/bess>
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
