summaryrefslogtreecommitdiffstats
path: root/zebra/zebra_vxlan_private.h
diff options
context:
space:
mode:
authorvivek <vivek@cumulusnetworks.com>2018-08-20 21:20:06 +0200
committervivek <vivek@cumulusnetworks.com>2018-08-20 21:20:06 +0200
commitf07e1c99d68907188adc66a674eb566febd00031 (patch)
tree68c7c3fc7bd0e6c73667d52a53fac3be55831347 /zebra/zebra_vxlan_private.h
parentzebra: Update neighbor state correctly upon move (diff)
downloadfrr-f07e1c99d68907188adc66a674eb566febd00031.tar.xz
frr-f07e1c99d68907188adc66a674eb566febd00031.zip
bgpd, zebra: EVPN extended mobility support
Implement procedures similar to what is specified in https://tools.ietf.org/html/draft-malhotra-bess-evpn-irb-extended-mobility in order to support extended mobility scenarios in EVPN. These are scenarios where a host/VM move results in a different (MAC,IP) binding from earlier. For example, a host with an address assignment (IP1, MAC1) moves behind a different PE (VTEP) and has an address assignment of (IP1, MAC2) or a host with an address assignment (IP5, MAC5) has a different assignment of (IP6, MAC5) after the move. Note that while these are described as "move" scenarios, they also cover the situation when a VM is shut down and a new VM is spun up at a different location that reuses the IP address or MAC address of the earlier instance, but not both. Yet another scenario is a MAC change for an attached host/VM i.e., when the MAC of an attached host changes from MAC1 to MAC2. This is necessary because there may already be a non-zero sequence number associated with MAC2. Also, even though (IP, MAC1) is withdrawn before (IP, MAC2) is advertised, they may propagate through the network differently. The procedures continue to rely on the MAC mobility extended community specified in RFC 7432 and already supported by the implementation, but augment it with a inheritance mechanism that understands the relationship of the host MACIP (ARP/neighbor table entry) to the underlying MAC (MAC forwarding database entry). In FRR, this relationship is understood by the zebra component which doubles as the "host mobility manager", so the MAC mobility sequence numbers are determined through interaction between bgpd and zebra. Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com> Reviewed-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Diffstat (limited to 'zebra/zebra_vxlan_private.h')
-rw-r--r--zebra/zebra_vxlan_private.h14
1 files changed, 14 insertions, 0 deletions
diff --git a/zebra/zebra_vxlan_private.h b/zebra/zebra_vxlan_private.h
index e86967041..44163eb33 100644
--- a/zebra/zebra_vxlan_private.h
+++ b/zebra/zebra_vxlan_private.h
@@ -260,6 +260,10 @@ struct zebra_mac_t_ {
struct in_addr r_vtep_ip;
} fwd_info;
+ /* Mobility sequence numbers associated with this entry. */
+ uint32_t rem_seq;
+ uint32_t loc_seq;
+
/* List of neigh associated with this mac */
struct list *neigh_list;
@@ -338,6 +342,16 @@ struct zebra_neigh_t_ {
/* Remote VTEP IP - applicable only for remote neighbors. */
struct in_addr r_vtep_ip;
+ /*
+ * Mobility sequence numbers associated with this entry. The rem_seq
+ * represents the sequence number from the client (BGP) for the most
+ * recent add or update of this entry while the loc_seq represents
+ * the sequence number informed (or to be informed) by zebra to BGP
+ * for this entry.
+ */
+ uint32_t rem_seq;
+ uint32_t loc_seq;
+
/* list of hosts pointing to this remote NH entry */
struct host_rb_tree_entry host_rb;
};