EVPN VXLAN HLD. #437

srj102 · 2019-08-14T09:39:06Z

Initial Version of the EVPN VXLAN HLD.

msftclas · 2019-08-14T09:39:20Z

All CLA requirements met.

marian-pritsak · 2019-10-16T18:51:11Z

doc/vxlan/EVPN/EVPN_VXLAN_HLD.md

+
+
+
+## 2.3 Scalability Requirements


What's the reason to put scale requirements into a design? Different platforms can support more than is listed here. I would rather have a CRM section which I didn't see in the document.

These are part of an overall requirements section. Scale is controlled by hardware as well as
FRR capabilities for the control plane.

I'm not sure how relevant those scale requirements are because I don't understand how they affect the design. Can you please provide the justification for each of them where the number was derived from and what implication it has on a design if any?

What about CRM? Any work expected to be done in this area?

On the Scaling - Agreed that different platforms can support different numbers. If the suggestion is to remove the numbers and mention that this will be specified in the platform specific documentation then this can be incorporated.

However I do see scalability numbers put in as part of the
https://github.com/Azure/SONiC/blob/master/doc/vxlan/Vxlan_hld.md

On CRM - no work is planned. The CRM depends on SAI Switch attributes to be defined for VXLAN which is not defined presently.

marian-pritsak · 2019-10-16T19:54:18Z

doc/vxlan/EVPN/EVPN_VXLAN_HLD.md

+- **sai_fdb_entry_type_t** - will be enhanced to have a new enum. 
+  - SAI_FDB_ENTRY_TYPE_STATIC_MACMOVE - This will be used when a MAC should not be aged out but a MAC move should be allowed. An example is remote MAC learnt by EVPN procedures which can be subjected to a MAC move from remote to local.
+- **sai_tunnel_attr_t** - It will be enhanced to have one new attribute
+  - SAI_TUNNEL_ATTR_ENCAP_DEST_IP - New tunnel attribute will be added to specify the tunnel destination IP address. This will be used to support warm reboot. Currently only the SIP is part of the tunnel attributes which does not allow for unique set of attributes when there are multiple tunnels with same SIP and different DIPs. The unique set of attributes is required for reconcilation during a warm reboot.  bridgeport associated with a tunnel also requires the tunnel id to be reconcilable post warm restart. Hence, it is required as part of the sai_tunnel_attr_t list.


VxLAN is P2MP tunnel. The DST IP is part of fdb encap entry or a tunnel route. What is the reason for creating multiple tunnels if we can implement P2MP already?

To handle the case of ingress replication for BUM we need P2P tunnels to be created and a bridge port
associated with them. These P2P tunnels are discovered in the EVPN case. To handle warm reboot we would need the DEST IP for these P2P tunnels.

marian-pritsak · 2019-10-16T19:57:13Z

doc/vxlan/EVPN/EVPN_VXLAN_HLD.md

+To support this feature, SAI will be extended as below:
+
+- **sai_fdb_entry_type_t** - will be enhanced to have a new enum. 
+  - SAI_FDB_ENTRY_TYPE_STATIC_MACMOVE - This will be used when a MAC should not be aged out but a MAC move should be allowed. An example is remote MAC learnt by EVPN procedures which can be subjected to a MAC move from remote to local.


How is the behavior different from SAI_FDB_ENTRY_TYPE_STATIC?

As mentioned these should NOT be aged out but could be subjected to a MACMOVE. We don't
want to delete and add this.

Now I understand. Thanks

Can this be renamed to SAI_FDB_ENTRY_TYPE_STICKY ?

The term sticky is specific to EVPN whereas the SAI definitions tend to be fairly generic and more reflective of the device functionality. Hence the term STATIC_MACMOVE was given. May be we could propose STATIC_WITH_MACMOVE. However the naming convention is finally to be decided by the SAI community.

marian-pritsak · 2019-10-16T20:06:43Z

doc/vxlan/EVPN/EVPN_VXLAN_HLD.md

+- **sai_tunnel_attr_t** - It will be enhanced to have one new attribute
+  - SAI_TUNNEL_ATTR_ENCAP_DEST_IP - New tunnel attribute will be added to specify the tunnel destination IP address. This will be used to support warm reboot. Currently only the SIP is part of the tunnel attributes which does not allow for unique set of attributes when there are multiple tunnels with same SIP and different DIPs. The unique set of attributes is required for reconcilation during a warm reboot.  bridgeport associated with a tunnel also requires the tunnel id to be reconcilable post warm restart. Hence, it is required as part of the sai_tunnel_attr_t list.
+- **sai_vlan_attr_t** - It will be enhanced to have one new attribute
+  - SAI_VLAN_ATTR_NEIGH_SUPP_MODE - By default this value will be FALSE. Reason for this new attribute is due to recent changes in ARP behaviour. The default arp behavior in copp file is changed from trap to copy(as part of commit -5e4b71d4). But for ARP Suppression, we need Pkt to get trapped instead of copy to avoid flooding of packets over vxlan tunnel.So a differentiated tcam rule for these arp suppressed vlans will redirect the ARP pkts to cpu instead of copy.


By defining this kind of attribute, the ARP flooding will be disabled for locally connected hosts on that VLAN, which seems not the best solution. I think it is possible to control flooding per port. Instead of disabling flood completely, it should be restricted to the local ports only.

The Local connected hosts will always get the Arp Requests flooding.
When Arp Suppression is turned on that Vlan, the new trap action in hw ensures that hw doesn't flood the packet over tunnel for that specified vlan.
When the Kernel IP Stack receives the packet, it floods the arp requests to local connected hosts even when it acts as proxy for tunnel neighbour.
Here we try to only stop the Hw flooding of Arp pkts over tunnel as the copp file is recently modified from trap to copy.
If we have had the old copp file (before the commit mentioned above), the SAI change is not required.
So here the flooding of arp pkts to local connected hosts happens by IP stack, instead of hw.

Agree. Isn't the host interface a better place for defining such attribute? It's all about traps, and not the VLAN, VLAN has nothing to do with traps.

Still this is per vlan attribute. For example , Vlan-x can be a configured with arp suppression enabled. But Vlan-y can be configured with arp suppression disabled.
Hence we have made this attribute configurable per vlan.

Since the cpu is going to act as ARP & ND proxy for the configured vlans, the cpu load might be little extra when compared to normal ARP/ND programming. Hence on top of the sai vlan attribute, we are also going to introduce the two new HOSTIF trap types in copp file. This will help us to set adjust the cir/cbs values when required.
Lets us name it as"
i) SAI_HOSTIF_TRAP_TYPE_ARP_SUPPRESS
ii)SAI_HOSTIF_TRAP_TYPE_ND_SUPPRESS

marian-pritsak · 2019-10-16T20:11:57Z

doc/vxlan/EVPN/EVPN_VXLAN_HLD.md

+
+```
+
+**VRF_TABLE**


There is already a L3 VxLAN implementation already in SONiC called VNET. Why not integrate with it?

EVPN L3VNI design here is already integrated with VXLAN design/implementation done as part of VNET. Most of the work is being leveraged. However, since VNET is not VRF, and VRF support was added later into SONiC, it makes more sense to provide L3VNI solution with VRF.
VNET will continue to co-exist with VRF-L3VNI.

Can both VNET based tunnel and VRF based tunnel be created simultaneously on a switch? If not, any warning message when a user does so (mostly by mistake, say when migrating from VNET to VRF)?

VNET co-exist with VRF-L3VNI. Currently no such checks.

prsunny · 2019-10-30T15:40:54Z

doc/vxlan/EVPN/EVPN_VXLAN_HLD.md

+Traffic received from VXLAN tunnels are mapped to a VLAN based on the received VNI and the VNI-VLAN lookup. The received traffic can be L2 unicast or BUM depending on the inner MAC lookup. Traffic received from VXLAN tunnels are never forwarded onto another VXLAN tunnels. 
+
+![L2 forwarding over VXLAN ](images/pktflowL2.PNG "Figure 1 : L2 Flow")
+__Figure 1: L2 forwarding Use Case__


The figure is not a use case diagram. May be rename it to packet flow.

prsunny · 2019-10-30T15:41:39Z

doc/vxlan/EVPN/EVPN_VXLAN_HLD.md

+The egress VTEP removes the VXLAN header and forwards the packet onto the local Layer 2 domain based on the VNI to VLAN mapping. The same thing happens on the return path, with the packet routed by the ingress router and then overlay switched by the egress router. The overlay routing action occurs on a different router on the reverse path vs. the forward path, hence the term asymmetric IRB.
+
+![Asymmetric IRB Use Case](images/pktflowAsymmIRB.PNG "Figure 2 : Asymm IRB Flow")
+__Figure 2: Asymmetric IRB Use Case__


Same comment for here and rest below

prsunny · 2019-10-30T15:42:26Z

doc/vxlan/EVPN/EVPN_VXLAN_HLD.md

+#### L2 forwarding over VXLAN
+
+Traffic received from the access ports are L2 forwarded over VXLAN tunnels if the DMAC lookup result does not match the switch MAC. The frame format is as described in RFC 7348. The VNI is based on the configured global VLAN-VNI map. BUM traffic is ingress replicated to all the tunnels  which are part of the VLAN. The DIP of the BUM packets is the IP address of the remote VTEP. L2 unicast traffic is forwarded to the tunnel to which the MAC points to. 
+Traffic received from VXLAN tunnels are mapped to a VLAN based on the received VNI and the VNI-VLAN lookup. The received traffic can be L2 unicast or BUM depending on the inner MAC lookup. Traffic received from VXLAN tunnels are never forwarded onto another VXLAN tunnels. 


Can you have a flow diagram for BUM packet flow as well?

doc/vxlan/EVPN/EVPN_VXLAN_HLD.md

prsunny · 2019-10-30T15:47:47Z

doc/vxlan/EVPN/EVPN_VXLAN_HLD.md

+key = ROUTE_TABLE:VRF_NAME:prefix ;
+nexthop = prefix,              ; IP addresses separated ',' (empty indicates no gateway). May indicate VXLAN endpoint if vni_label is non zero.
+intf = ifindex? PORT_TABLE.key ; zero or more separated by ',' (zero indicates no interface)
+vni_label = VRF.vni            ; New Field. zero or more separated by ',' (empty value for non-vxlan next-hops). May carry MPLS label in future.


What is the use-case of multiple vni's for a route entry?

New fields added are part of Nexthop tuple {Nexthop IP, VNI, RMAC}. In case of Overlay ECMP, we will have Overlay Nexthops seperated by ',' . Nexthop IP and RMAC will be different. Encap VNI can be same or different.

prsunny · 2019-10-30T15:48:11Z

doc/vxlan/EVPN/EVPN_VXLAN_HLD.md

+intf = ifindex? PORT_TABLE.key ; zero or more separated by ',' (zero indicates no interface)
+vni_label = VRF.vni            ; New Field. zero or more separated by ',' (empty value for non-vxlan next-hops). May carry MPLS label in future.
+router_mac = mac_address       ; New Field. zero or more remote router MAC address separated by ',' (empty value for non-vxlan next-hops)
+blackhole = BIT                ; Set to 1 if this route is a blackhole (or null0)


Is this for EVPN use-case or generic?

Generic. vni_label can be vni or mpls label in future

KLISH Cli changes for supporting Arp & ND Suppress over Vxlan Tunnel. Below link has more details of this feature & ongoing discussions with community. sonic-net/SONiC#437 Change-Id: Iefe006ad7803f34bb56730e0779076d67d40ffae

prvattem · 2019-11-13T07:55:59Z

doc/vxlan/EVPN/EVPN_VXLAN_HLD.md

+__Figure 10: Remote MAC handling__
+
+
+#### 4.3.7.3 MAC Move handling


Is there a limit on how many times a mac can be moved between 2 VTEPs?

By default, 5 MAC Moves in a 180 sec period according to RFC 7432 sec 15.1. Will update on FRR behavior.

prvattem · 2019-11-13T08:17:22Z

doc/vxlan/EVPN/EVPN_VXLAN_HLD.md

+
+1. Support configuration of Source IP address of the VTEP. 
+2. Support configuration of a global VLAN-VNI map.
+3. Support configuration of L3VNI association with VRF. 


Is it worth mentioning that, L3VNI can only be associated with non-default VRF (Symmetric IRB - case) ?

Yes. Will do.

prvattem · 2019-11-13T08:21:53Z

doc/vxlan/EVPN/EVPN_VXLAN_HLD.md

+2. Total Remote VTEPs (VXLAN destination tunnels) - 512.
+3. Total L2 VNI per switch- 4K.
+4. Total VNI per tunnel - 4K.
+5. Total EVPN participating VRF per switch - 512


If all the VRFs support Symmetric IRB, those many extra VNIs(L3) will be consumed.

yes. One VNI per VRF.

prvattem · 2019-11-13T08:23:08Z

doc/vxlan/EVPN/EVPN_VXLAN_HLD.md

+
+In contrast to the above, VRF routes are programmed in ROUTE_TABLE:{{vrf_name}} table including local (connected, static) and remote (BGP, IGP) VRF-lite prefixes.
+
+In order to program VRF routes imported from EVPN Type-5 prefix routes, <endpoint, router-MAC, and VNI> values are required along with the prefix in the route entry.


Please describe a little more about how router-mac is derived.

Interface MAC of IRB router interface is used as router-mac.
L3 VNI will be associated with a Vlan interface (IRB router interface), Vlan interface MAC of that associated IRB interface is used as router-mac.

What happens in-case of MCLAG use case? How is the router-mac derived?

Vlan Interface (IRB Router interface) MAC is always used. If the Vlan is part of MCLAG, then as defined in MCLAG design, both Active and Standby node uses same MAC (Active node's MAC). Both MLAG nodes in this case will advertise same Router MAC for that specific L3 VNI.

Note : This HLD is for Single VTEP use case. MCLAG and Logical VTEP uses cases are not in the scope of this HLD.

prvattem · 2019-11-13T08:25:10Z

doc/vxlan/EVPN/EVPN_VXLAN_HLD.md

+- EVPN Type 5 route support based on VRF construct.
+- Routing of L3 (IPv4 and IPv6) traffic in and out of the VXLAN tunnel.
+- Overlay ECMP support.
+- EVPN ARP and ND suppression.


Is distributed Anycast Gateway support, not a requirement?
What would be the default Gateway for a host in a given subnet?

distributed Anycast Gateway will be supported.

prvattem · 2019-11-13T08:47:05Z

doc/vxlan/EVPN/EVPN_VXLAN_HLD.md

+
+```
+;New table
+;holds the VTEP source IP used for BGP-EVPN discovered tunnels


Is the description misleading here? We dont store the VTEP source IP here.. rather the Name of the Tunnel, which has the IP associated with.

Will correct.

prvattem · 2019-11-13T08:52:23Z

doc/vxlan/EVPN/EVPN_VXLAN_HLD.md

+;Status: stable
+
+key = VRF_TABLE:VRF_NAME ;
+fallback = "true"/"false"             ; default false


What is intended behavior with fallback option?

This is existing field in VRF Table. Please refer Following VRF HLD for detail.
https://github.com/Azure/SONiC/blob/master/doc/vrf/sonic-vrf-hld.md

prvattem · 2019-11-13T09:01:37Z

doc/vxlan/EVPN/EVPN_VXLAN_HLD.md

+
+```
+; New table
+; specifies the VLAN to be extended over a tunnel


This table is confusing. For a given local VLAN the VNI is mapped. If an IMET route is received with a matching VNI, we can build a mapping of VLAN,VNI to list of remote VTEPs.
But the current schema allows a combination of <V1,RIP1>, <V2,RIP1> map to same VNI.

This is to handle the case of downstream assigned VNI in DCI cases in future. The VNI in the table specifies the VNI carried in the IMET route. This VNI will be used during encap. The remote will advertise unique VNI values per VLAN. In the DCI case the remote VNI will be different from the local VNI for a VLAN whereas in a global VNI case it will be the same.

prvattem · 2019-11-13T09:04:39Z

doc/vxlan/EVPN/EVPN_VXLAN_HLD.md

+; field         = value
+SRC_IP          = ipv4                 ; tunnel sip
+DST_IP          = ipv4                 ; tunnel dip 
+tnl_src         = "CLI"/"EVPN"  


the option "CLI" is for static VXLAN case? There is a mention of not supporting static VXLAN in this document.

Yes for the static case or could be extended for orchestrator configured tunnels like NSX. This is purely informational. With the current feature only EVPN will be filled in. Static tunnels configured through VXLAN_TUNNEL table with a DIP could fill this with the tnl_src field as static.

prvattem · 2019-11-27T05:37:53Z

doc/vxlan/EVPN/EVPN_VXLAN_HLD.md

+  - SAI_FDB_ENTRY_TYPE_STATIC_MACMOVE - This will be used when a MAC should not be aged out but a MAC move should be allowed. An example is remote MAC learnt by EVPN procedures which can be subjected to a MAC move from remote to local.
+- **sai_tunnel_attr_t** - It will be enhanced to have one new attribute
+  - SAI_TUNNEL_ATTR_ENCAP_DEST_IP - New tunnel attribute will be added to specify the tunnel destination IP address. This will be used to support warm reboot. Currently only the SIP is part of the tunnel attributes which does not allow for unique set of attributes when there are multiple tunnels with same SIP and different DIPs. The unique set of attributes is required for reconcilation during a warm reboot.  bridgeport associated with a tunnel also requires the tunnel id to be reconcilable post warm restart. Hence, it is required as part of the sai_tunnel_attr_t list.
+- **sai_vlan_attr_t** - It will be enhanced to have one new attribute


We should also have the ability to enable the ARP suppression system wide.
Higher the number of VLANs, higher will be the configuration.

Same review comment is given to us during EVPN work group meeting.
We have accepted to implement this enhancement.
Few hardware platforms which cannot scale will continue to use the individual per vlan setting.

prvattem · 2019-11-27T07:10:49Z

doc/vxlan/EVPN/EVPN_VXLAN_HLD.md

+
+Following configurations are required for enabling EVPN L3 service on SONiC device:
+
+- Configure L3VNI-VLAN mapping for the given NVO.


This probably is the MAC-VRF VNI(L2VNI), which is different from L3VNI.
VLAN<--> MAC-VRF VNI and IP-VRF <-->L3VNI.

Added CLI details. Updated the L2 packet flows.

prvattem · 2020-01-08T17:19:58Z

doc/vxlan/EVPN/EVPN_VXLAN_HLD.md

+
+
+3. show vxlan vrfvnimap 
+   - Displays all the VRF VNI mappings.


Please provide the sample o/p for this?

updated the document.

prvattem · 2020-01-08T17:22:18Z

doc/vxlan/EVPN/EVPN_VXLAN_HLD.md

+   +---------+-------------------+--------------+-------+--------+
+   | VLAN    | MAC               | RemoteVTEP   |   VNI | Type   |
+   +=========+===================+==============+=======+========+
+   | Vlan101 | 00:00:00:00:00:01 | 4.4.4.4      |  1001 | static |


Here the remote MAC type "static" conveys a meaning that, the learnt MAC is static on the Remote VTEP. This needs to be changed??

prvattem · 2020-01-08T17:23:58Z

doc/vxlan/EVPN/EVPN_VXLAN_HLD.md

+
+
+6. show vxlan remote_vni <remoteip/all> 
+   - lists all the VLANs learnt from the specified remote ip or all the remotes.  (APP DB view) 


This needs to be rephrased to say "lists all the VNIs learnt from" ?? VLAN is local and mapped to a VNI

This is in accordance with the HLD as part of the following PR. sonic-net/SONiC#437 CONFIG DB 1. EVPN_NVO Table. APP DB 1. EVPN_REMOTE_VNI Table. 2. VXLAN_FDB Table. STATE DB 1. VXLAN_TUNNEL Table.

…C#437

prsunny · 2020-10-23T16:28:29Z

WG request for timing sequence during warmboot for the following scenarios:

No EVPN configuration
EVPN configuration with only Layer 3
Broadcom shall provide these numbers using the optimized image

nkelapur · 2020-10-30T14:30:01Z

WG request for timing sequence during warmboot for the following scenarios:

No EVPN configuration

EVPN configuration with only Layer 3
Broadcom shall provide these numbers using the optimized image

Time required for BGP/fpmsynd to start replay/reconciliation when the systems comes up after warm-reboot

500 L2 VNIs : 50 seconds
500 L3 VNIs : 240 seconds
500 L3 and 500 L2 VNIs : 245 seconds

Without EVPN config
4) 1K ipv4 routes, 200 Vrfs : 47 seconds
Without dependency wait for BGP/fpmsyncd
5) 1K ipv4 routes, 200 Vrfs : 28 seconds

Please note that the these tests were done of broadcom build which uses netlink interface for kernel programming. The time required for L3VNIs is more and is attributed to over all more config ( 500 Vrf , 1000 Vlans and corresponding BGP instances and the corresponding increase in reconciliation of Vlanmgr, VrfMgr, orchagent etc)

sonic-net/SONiC#437

Config and show commands added to click infra for VXLAN objects. Please refer to sonic-net/SONiC#437 for the commands. The fast-reboot script is changed to not clear VXLAN tunnel state table during a warm reboot.

…NiC#437 (#1276) * [FPMSYNCD] EVPN Type5 prefix handling in FPMSYNCD. This Change set is to support EVPN MAC/IMET routes from Kernel to DB and DB to Kernel: New demon is added to sync MAC from Kernel to DB and vise versa. Add remote IMET route learned via EVPN to EVPN_REMOTE_VNI_TABLE in APP_DB. Add remote MAC route learned via EVPN to VXLAN_FDB_TABLE. Add State DB FDB_TABLE for local learned MAC to Kernel Signed-off-by: Kishore Kunal kishore.kunal@broadcom.com

…NiC#437 (sonic-net#1276) * [FPMSYNCD] EVPN Type5 prefix handling in FPMSYNCD. This Change set is to support EVPN MAC/IMET routes from Kernel to DB and DB to Kernel: New demon is added to sync MAC from Kernel to DB and vise versa. Add remote IMET route learned via EVPN to EVPN_REMOTE_VNI_TABLE in APP_DB. Add remote MAC route learned via EVPN to VXLAN_FDB_TABLE. Add State DB FDB_TABLE for local learned MAC to Kernel Signed-off-by: Kishore Kunal kishore.kunal@broadcom.com Signed-off-by: Arvindsrinivasan Lakshmi Narasimhan <arlakshm@microsoft.com>

sonic-swss: [Dynamic buffer calc] Support dynamic buffer calculation (sonic-net#1338) [dvs] Clean-up dvs_database and dvs_common (sonic-net#1541) [VxlanMgr] changes for EVPN VXLAN (sonic-net#1266) Statistics support for Tx and Rx counters of different frame sizes (sonic-net#1536) [orchagent/phy]: Add firmware info propagation (sonic-net#1540) [vxlanorch] Use PRI instead of %l to avoid warnings in 32-bit arch (sonic-net#1539) [FDBSYNCD] Added support for EVPN as described in the PR sonic-net/SONiC#437 (sonic-net#1276) [everflow] Add retry mechanism for mirror sessions and policers (sonic-net#1486) Enable ACL table type mirror_v6 for Innovium Platform (sonic-net#1527) [fgnhgorch] Change format specifier %lu to %zu for size_t (sonic-net#1529) [dvs] Fix issue where concurrent netns operations cause test setup to fail (sonic-net#1535) Add support for headroom pool watermark (sonic-net#1453) Change gAsicInstance to type string with max length limit (sonic-net#1526) sonic-utilities: [Dynamic buffer calc] Support dynamic buffer calculation (sonic-net#973) show tech with platform dump option (sonic-net#1158) [kdump]: Parse sonic_platform kernel command line parameter to read the platform identifier string (sonic-net#1291) [pcieutil] Remove 'pcie-' prefix from arguments (sonic-net#1297) Added 'detailed' option for 'show interface counters' command (sonic-net#1299) Fix show ip route summary on pizzabox platforms (sonic-net#1302) [acl_loader] Fix default DENY rule for V6 dataplane ACLs (sonic-net#1281) Add show and clear commands for headroom pool watermark (sonic-net#1144) [unit test][CLI][pfcwd] Added pfcwd config tests for single and multi ASIC platform. (sonic-net#1248) [sflow] Fix traceback seen for show sflow interface (sonic-net#1282) [config/console][consutil] Support enable/disable console switch (sonic-net#1275) [fast-reboot] Fix fast-reboot when NDP entries are present (sonic-net#1295) Fast-reboot: add a new flag to ignore ASIC config checksum verification failures (sonic-net#1292) Kdump improvements (sonic-net#1284) Signed-off-by: Stephen Sun <stephens@nvidia.com>

…C#437 (#1267) VRFMgr Changes to update VRF VNI Map information and notify VRFOrch. Neighbor Orch changes to Add and Remove Tunnel Nexthops. Nexthop Key changes to accommodate VNI and Router MAC. Route Orch changes to Add and Remove Overlay routes, Create and Delete Overlay Nexthops. Port Orch changes to bring Up / Down Router Interface (IRB Vlan interface) on VRF - VNI Bind / Unbind.

Added support for VXLAN config and commands as described in the PR sonic-net/SONiC#437 config vxlan add/del and config vxlan evpn_nvo add/del config vxlan map/map_range add show vxlan remote vni/show vxlan remote mac show vxlan tunnel Co-authored-by: Tapash Das <tapash.das@broadcom.com> Co-authored-by: Karthikeyan Ananthakrishnan <karthikeyan.ananthakrishnan@broadcom.com> Co-authored-by: Tapash Das <48195098+tapashdas@users.noreply.github.com>

[vxlanorch] Use PRI instead of %l to avoid warnings in 32-bit arch (sonic-net#1539) [FDBSYNCD] Added support for EVPN as described in the PR sonic-net/SONiC#437 (sonic-net#1276) [everflow] Add retry mechanism for mirror sessions and policers (sonic-net#1486) Enable ACL table type mirror_v6 for Innovium Platform (sonic-net#1527) Signed-off-by: Sabareesh Kumar Anandan <sanandan@marvell.com>

[buffermgmt] more build error fixes when compiling for armhf (32-bit) (sonic-net#1559) Sflow fix to avoid NULL in field. (sonic-net#1531) [fgnhgorch] Fg Nhg link handling (sonic-net#1537) [dpb]: make sure port is in admin down state before remove port. (sonic-net#1513) [FPMSYNCD/FDBSYNCD] EVPN Type-5 route removing prefix-len for host route and removing junk character present in the mac (sonic-net#1553) Added support for EVPN L3 VXLAN as described in the PR sonic-net/SONiC#437 (sonic-net#1267) Signed-off-by: Sabareesh Kumar Anandan <sanandan@marvell.com>

* src/sonic-swss c7ee75f...cadf28f (24): > Revert "Add support for headroom pool watermark (#1453)" > [VxlanOrch] pytest for EVPN VXLAN (#1318) > [restore_neighbors] python3 support for restore_neighbors.py (#1542) > [buffermgmt] more build error fixes when compiling for armhf (32-bit) (#1559) > Sflow fix to avoid NULL in field. (#1531) > [fgnhgorch] Fg Nhg link handling (#1537) > [dpb]: make sure port is in admin down state before remove port. (#1513) > [FPMSYNCD/FDBSYNCD] EVPN Type-5 route removing prefix-len for host route and removing junk character present in the mac (#1553) > Added support for EVPN L3 VXLAN as described in the PR sonic-net/SONiC#437 (#1267) > [crm]: Typecast to unit64_t to avoid divide by 0 during overflow (#1550) > [vxlanmgr] Fix build error when compiling for armhf (32-bit) (#1552) > [Dynamic buffer calc] Support dynamic buffer calculation (#1338) > [dvs] Clean-up dvs_database and dvs_common (#1541) > [VxlanMgr] changes for EVPN VXLAN (#1266) > Statistics support for Tx and Rx counters of different frame sizes (#1536) > [orchagent/phy]: Add firmware info propagation (#1540) > [vxlanorch] Use PRI instead of %l to avoid warnings in 32-bit arch (#1539) > [FDBSYNCD] Added support for EVPN as described in the PR sonic-net/SONiC#437 (#1276) > [everflow] Add retry mechanism for mirror sessions and policers (#1486) > Enable ACL table type mirror_v6 for Innovium Platform (#1527) > [fgnhgorch] Change format specifier %lu to %zu for size_t (#1529) > [dvs] Fix issue where concurrent netns operations cause test setup to fail (#1535) > Add support for headroom pool watermark (#1453) > Change gAsicInstance to type string with max length limit (#1526)

Added support for VXLAN config and commands as described in the PR sonic-net/SONiC#437 config vxlan add/del and config vxlan evpn_nvo add/del config vxlan map/map_range add show vxlan remote vni/show vxlan remote mac show vxlan tunnel Co-authored-by: Tapash Das <tapash.das@broadcom.com> Co-authored-by: Karthikeyan Ananthakrishnan <karthikeyan.ananthakrishnan@broadcom.com> Co-authored-by: Tapash Das <48195098+tapashdas@users.noreply.github.com>

cherry-pick from ec201911 branch bb054420 kh_shi, JIRA-SONIC-720: [EVPN] fix typo and ip valid function for sync EVPN community PRs 1f248d84 Tapash Das, LTGM Warning Fix b8b50794 Tapash Das, Added VRF VNI Map CLI and Neighbor Suppression CLI. 807a0553 Rajesh Sankaran, Fixed LGTM Warnings 847bd9f7 Rajesh Sankaran, Changed the same for REMOTE_VNI Table. 53027878 Rajesh Sankaran, Changes to support EVPN VXLAN Please refer to sonic-net/SONiC#437 Change-Id: I9bbc2d56bb413bf3dc9c5d0efbd72c92eb351eb5

dprital · 2022-12-06T16:51:23Z

@srj102 , @adyeung
What about the requirement from fast boot on switch running EVPN ?

Added support for VXLAN config and commands as described in the PR sonic-net/SONiC#437 config vxlan add/del and config vxlan evpn_nvo add/del config vxlan map/map_range add show vxlan remote vni/show vxlan remote mac show vxlan tunnel Co-authored-by: Tapash Das <tapash.das@broadcom.com> Co-authored-by: Karthikeyan Ananthakrishnan <karthikeyan.ananthakrishnan@broadcom.com> Co-authored-by: Tapash Das <48195098+tapashdas@users.noreply.github.com>

Initial Version of the EVPN VXLAN HLD.

99375a9

srj102 changed the title ~~Initial Version of the EVPN VXLAN HLD.~~ EVPN VXLAN HLD. Aug 14, 2019

marian-pritsak reviewed Oct 16, 2019

View reviewed changes

prsunny reviewed Oct 30, 2019

View reviewed changes

prvattem reviewed Nov 13, 2019

View reviewed changes

prvattem reviewed Nov 27, 2019

View reviewed changes

srj102 added 2 commits December 10, 2019 07:45

Updates after the WG meetings.

8064951

Added CLI details. Updated the L2 packet flows.

Updated to point to the SAI PRs filed.

be803da

prvattem reviewed Jan 8, 2020

View reviewed changes

This was referenced Apr 8, 2020

VXLAN config and show utilities sonic-net/sonic-utilities#870

Merged

EVPN VXLAN DB support sonic-net/sonic-swss-common#339

Merged

tapashdas added a commit to tapashdas/sonic-swss that referenced this pull request Apr 21, 2020

Added support for EVPN L3 VXLAN as described in the PR sonic-net/SONi…

16c7f0a

…C#437

tapashdas mentioned this pull request Apr 21, 2020

Added support for EVPN L3 VXLAN as described in the PR Azure/SONiC#437 sonic-net/sonic-swss#1267

Merged

Updated review comment.

c2a72d6

kishorekunal01 added a commit to kishorekunal01/sonic-swss that referenced this pull request Nov 14, 2020

[FDBSYNCD] Added support for FDBSYNCD as described in the PR

b90c15e

sonic-net/SONiC#437

This was referenced Nov 19, 2020

Add support to start fdbsyncd when swss docker starts sonic-net/sonic-buildimage#5979

Merged

Table to store fdb restore table for fdbsyncd sonic-net/sonic-swss-common#417

Closed

Sabareesh-Kumar-Anandan mentioned this pull request Dec 15, 2020

[sonic-swss] submodule update sonic-net/sonic-buildimage#6191

Closed

3 tasks

kishorekunal01 mentioned this pull request Dec 16, 2020

[FDBSYNCD] Some Junk character are present in the mac and port name while config MAC in the kernel. sonic-net/sonic-swss#1549

Closed

stephenxs mentioned this pull request Dec 16, 2020

[submodule] Advance submodule head for sonic-swss and sonic-utilities stephenxs/sonic-buildimage#47

Closed

3 tasks

kishorekunal01 mentioned this pull request Dec 16, 2020

[FPMSYNCD/FDBSYNCD] EVPN Type-5 route removing prefix-len for host route and removing junk character present in the mac sonic-net/sonic-swss#1553

Merged

Updated the fdbsyncd unit test case

8645a6a

nkelapur mentioned this pull request Dec 17, 2020

Added changes to handle dependency check in FdbSyncd and FpmSyncd for warm-boot sonic-net/sonic-swss#1556

Merged

jleveque mentioned this pull request Dec 22, 2020

[sonic-swss] Update submodule sonic-net/sonic-buildimage#6270

Merged

prsunny approved these changes Jan 11, 2021

View reviewed changes

prsunny merged commit 47a2153 into sonic-net:master Jan 11, 2021

		__Figure 10: Remote MAC handling__


		#### 4.3.7.3 MAC Move handling


		In contrast to the above, VRF routes are programmed in ROUTE_TABLE:{{vrf_name}} table including local (connected, static) and remote (BGP, IGP) VRF-lite prefixes.

		In order to program VRF routes imported from EVPN Type-5 prefix routes, <endpoint, router-MAC, and VNI> values are required along with the prefix in the route entry.


		Following configurations are required for enabling EVPN L3 service on SONiC device:

		- Configure L3VNI-VLAN mapping for the given NVO.



		6. show vxlan remote_vni <remoteip/all>
		- lists all the VLANs learnt from the specified remote ip or all the remotes. (APP DB view)


		```

		VRF_TABLE

EVPN VXLAN HLD. #437

EVPN VXLAN HLD. #437

Conversation

srj102 commented Aug 14, 2019

msftclas commented Aug 14, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

prvattem Nov 13, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

prvattem Nov 27, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

prsunny commented Oct 23, 2020

nkelapur commented Oct 30, 2020 • edited Loading

dprital commented Dec 6, 2022

msftclas commented Aug 14, 2019 •

edited

Loading

prvattem Nov 13, 2019 •

edited

Loading

prvattem Nov 27, 2019 •

edited

Loading

nkelapur commented Oct 30, 2020 •

edited

Loading