Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EVPN VXLAN HLD. #437

Merged
merged 18 commits into from Jan 11, 2021
Merged

EVPN VXLAN HLD. #437

merged 18 commits into from Jan 11, 2021

Conversation

srj102
Copy link
Contributor

@srj102 srj102 commented Aug 14, 2019

Initial Version of the EVPN VXLAN HLD.

@msftclas
Copy link

msftclas commented Aug 14, 2019

CLA assistant check
All CLA requirements met.

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



## 2.3 Scalability Requirements
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

- **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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How is the behavior different from SAI_FDB_ENTRY_TYPE_STATIC?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now I understand. Thanks

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can this be renamed to SAI_FDB_ENTRY_TYPE_STICKY ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

- **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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


```

**VRF_TABLE**
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

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__
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will do.

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__
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment for here and rest below

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

#### 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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will do.

doc/vxlan/EVPN/EVPN_VXLAN_HLD.md Show resolved Hide resolved
doc/vxlan/EVPN/EVPN_VXLAN_HLD.md Show resolved Hide resolved
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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

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)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this for EVPN use-case or generic?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generic. vni_label can be vni or mpls label in future

a-barboza pushed a commit to project-arlo/sonic-mgmt-framework that referenced this pull request Oct 31, 2019
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
__Figure 10: Remote MAC handling__


#### 4.3.7.3 MAC Move handling
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


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.
Copy link
Collaborator

@prvattem prvattem Nov 13, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. Will do.

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
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes. One VNI per VRF.


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.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

- 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.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

distributed Anycast Gateway will be supported.


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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will correct.

;Status: stable

key = VRF_TABLE:VRF_NAME ;
fallback = "true"/"false" ; default false
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is intended behavior with fallback option?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


```
; New table
; specifies the VLAN to be extended over a tunnel
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

; field = value
SRC_IP = ipv4 ; tunnel sip
DST_IP = ipv4 ; tunnel dip
tnl_src = "CLI"/"EVPN"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

- 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
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


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

- Configure L3VNI-VLAN mapping for the given NVO.
Copy link
Collaborator

@prvattem prvattem Nov 27, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes.



3. show vxlan vrfvnimap
- Displays all the VRF VNI mappings.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please provide the sample o/p for this?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

updated the document.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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



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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

srj102 added a commit to srj102/sonic-swss-common that referenced this pull request Apr 8, 2020
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.
tapashdas added a commit to tapashdas/sonic-swss that referenced this pull request Apr 21, 2020
@prsunny
Copy link
Contributor

prsunny commented Oct 23, 2020

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

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

@nkelapur
Copy link
Contributor

nkelapur commented Oct 30, 2020

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

  1. No EVPN configuration
  2. 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

  1. 500 L2 VNIs : 50 seconds
  2. 500 L3 VNIs : 240 seconds
  3. 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)

kishorekunal01 added a commit to kishorekunal01/sonic-swss that referenced this pull request Nov 14, 2020
srj102 added a commit to srj102/sonic-utilities that referenced this pull request Dec 11, 2020
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.
prsunny pushed a commit to sonic-net/sonic-swss that referenced this pull request Dec 11, 2020
…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
arlakshm pushed a commit to arlakshm/sonic-swss that referenced this pull request Dec 15, 2020
…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>
stephenxs added a commit to stephenxs/sonic-buildimage that referenced this pull request Dec 16, 2020
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>
prsunny pushed a commit to sonic-net/sonic-swss that referenced this pull request Dec 18, 2020
…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.
prsunny pushed a commit to sonic-net/sonic-utilities that referenced this pull request Dec 19, 2020
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>
Sabareesh-Kumar-Anandan pushed a commit to Sabareesh-Kumar-Anandan/sonic-buildimage that referenced this pull request Dec 20, 2020
[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>
Sabareesh-Kumar-Anandan pushed a commit to Sabareesh-Kumar-Anandan/sonic-buildimage that referenced this pull request Dec 20, 2020
[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>
jleveque added a commit to sonic-net/sonic-buildimage that referenced this pull request Dec 24, 2020
* 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)
@prsunny prsunny merged commit 47a2153 into sonic-net:master Jan 11, 2021
anand-kumar-subramanian pushed a commit to anand-kumar-subramanian/sonic-utilities that referenced this pull request Mar 2, 2021
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>
CharlieChenEC pushed a commit to CharlieChenEC/sonic-utilities that referenced this pull request May 14, 2021
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
Copy link

dprital commented Dec 6, 2022

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

malletvapid23 added a commit to malletvapid23/Sonic-Utility that referenced this pull request Aug 3, 2023
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet