draft-ietf-bess-evpn-inter-subnet-forwarding describes two ways of
assigning the default GW MAC address in section 4.1:
<snip>
1. All the PEs for a given tenant subnet use the same anycast
default gateway IP and MAC addresses. On each PE, this default
gateway IP and MAC addresses correspond to the IRB interface
connecting the BT associated with the tenant's VLAN to the
corresponding tenant's IP-VRF.
2. Each PE for a given tenant subnet uses the same anycast default
gateway IP address but its own MAC address.
</snip>
It says that option-1 is recommended because of the ease of anycast MAC
address provisioning. However, option-2 is not prohibited. I think using a
non-anycast default GW MAC address has certain implications on the mobility
procedures (section 7) that is not well described in the draft:
Section 7.1 says the following:
<snip>
The source NVE upon receiving this MAC/IP Advertisement route,
realizes that the MAC has moved to the target NVE. It updates its
MAC-VRF and IP-VRF table accordingly with the adjacency information
of the target NVE. In the case of the asymmetric IRB, the source NVE
also updates its ARP table with the received adjacency information
and in the case of the symmetric IRB, the source NVE removes the
entry associated with the received (MAC, IP) from its local ARP
table. It then withdraws its EVPN MAC/IP Advertisement route.
* Furthermore, it sends an ARP probe locally to ensure that the MAC is
gone. If an ARP response is received, the source NVE updates its ARP
entry for that (IP, MAC) and re-advertises an EVPN MAC/IP Advertisement
route for that (IP, MAC) along with MAC Mobility Extended Community with
the sequence number incremented by one.* The
source NVE also exercises the MAC duplication detection procedure in
section 15.1 of [RFC7432].
</snip>
Now, if the source NVE uses a non-anycast default GW MAC address, then it
will receive an ARP response for its ARP probe since the ARP response will
be sent back to the non-anycast MAC address. This may cause the source NVE
to think that the TS has moved back, resulting in re-advertisement of the
EVPN MAC/IP route for that (IP, MAC) along with the MAC mobility EC with
the seq. number incremented by one.
To avoid this problem, source NVE needs to understand that the ARP response
was received over the MPLS/IP core instead of over the access-facing IRB
interface and discard it.
In section 7.2 the draft says the following:
<snip>
o The target NVE passes the ARP request to its locally attached TSes
and *when it receives the ARP response*, it updates its IP-VRF and
ARP table with the host (MAC, IP) information. It also sends an
EVPN MAC/IP Advertisement route with both the MAC and IP addresses
filled in along with MAC Mobility Extended Community with the
sequence number set to the same value as the one for MAC-only
advertisement route it sent previously.
</snip>
In the above, the ARP request is originated by the source NVE. Hence, if
the source NVE uses a non-anycast default gateway MAC address, then the ARP
response will be sent back to the source NVE, instead of being locally
consumed by the target NVE and causing it to perform the procedures
described above.
In section 7.3, the draft says the following:
<snip>
The target NVE passes the ARP request to its locally attached TSes
and *when it receives the ARP response*, it updates its MAC-VRF, IP-
VRF, and ARP table with the host (MAC, IP) and local adjacency
information (e.g., local interface). It also sends an EVPN MAC/IP
advertisement route with both the MAC and IP address fields filled in
along with MAC Mobility Extended Community with the sequence number
incremented by one.
</snip>
The problem here is the same if the source NVE uses a non-anycast default
GW MAC address..
Should there be a better description in the draft on the implications of
using non-anycast default GW MAC address?
Are there IRB deployments using non-anycast default GW MAC address for
hosts/servers (other than the one used only for OAM)?
Regards,
Muthu
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
