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.

Sign up for GitHub

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: update to allow recording for p2mp remote vteps #1897

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open

EVPN_VXLAN_HLD: update to allow recording for p2mp remote vteps #1897

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
5d97b9f
EVPN_VXLAN_HLD: update to allow recording for p2mp remote vteps
bradh352 Jan 22, 2025
56a7e7d
update revision
bradh352 Jan 22, 2025
b94962f
clarify SIP == P2MP and DIP == P2P
bradh352 Jan 23, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 10 additions & 10 deletions doc/vxlan/EVPN/EVPN_VXLAN_HLD.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@

# EVPN VXLAN HLD

#### Rev 1.0
#### Rev 1.2

# Table of Contents

Expand Down Expand Up @@ -76,6 +76,7 @@
| 0.9 | | Nikhil Kelhapure | Warm Reboot Section added |
| 1.0 | | Sudharsan D.G | Using P2MP Tunnel for Layer2 functionality |
| 1.1 | | Adam Yeung | Update Fastboot limitation |
| 1.2 | 2025-01-22 | Brad House | Record p2mp vxlan remote vteps in state table |


# Definition/Abbreviation
Expand Down Expand Up @@ -521,7 +522,7 @@ key = VXLAN_TUNNEL:name ; tunnel name
SRC_IP = ipv4 ; tunnel sip
DST_IP = ipv4 ; tunnel dip
tnl_src = "CLI"/"EVPN"
operstatus = "oper_up"/"oper_down"
operstatus = "oper_up"/"oper_down"/"oper_p2mp"
```

### 4.2.4 COUNTER_DB changes
Expand Down Expand Up @@ -635,7 +636,7 @@ SAI object type as TUNNEL. This SAI object is P2MP.
Some vendors support P2P Tunnels to handle Layer2 extension and fdb learning while some vendors support using existing P2MP for handling Layer2 scenarios. The difference between the two approaches is the way in which the remote end point flooding is done. In P2P tunnel based approach, for every end point discovered from IMET a P2P tunnel object is created in the hardware and the bridge port created with this tunnel object is added as a VLAN member to the VLAN. In P2MP tunnel based approach, when an IMET route is received the remote end point along with local P2MP tunnel bridge port is added as L2MC group member along for the L2MC group associated with the VLAN. In order to handle both scenarios, evpn_remote_vni orch which currently handles remote VNI is split into two types - evpn_remote_vni_p2p to handle the flow involving the P2P tunnel creation and evpn_remote_vni_p2mp to handle the flow for using the existing P2MP tunnel. The decision to chose which orch to use is dependent on the SAI enum query capability for the attribute SAI_TUNNEL_ATTR_PEER_MODE. If the vendors have SAI_TUNNEL_PEER_MODE_P2P listed, then evpn_remote_vni_p2p orch will be used, else evpn_remote_vni_p2mp will be used. These enhancements abstract the two different modes that can be used to program the SAI. For an external user, there will be no changes from usability perspective since the schema is unchanged.

#### 4.3.1.1 P2P Tunnel creation
In this feature enhancement, the following events result in remote VTEP discovery and trigger tunnel creation. These tunnels are referred to as dynamic tunnels and are P2P.
In this feature enhancement, the following events result in remote VTEP discovery and trigger tunnel creation. These tunnels are referred to as dynamic tunnels or DIP tunnels and are P2P.

- IMET route rx
- IP Prefix route handled by VRF construct.
Expand All @@ -658,7 +659,7 @@ The creation sequence assuming only IMET rx is depicted in the diagram below.
__Figure 5.1: EVPN P2P Tunnel Creation__

#### 4.3.1.2 P2MP Tunnel Creation
In the current implementation P2MP tunnel creation flow exist with the exception of a bridgeport not created for P2MP tunnel. To support using P2MP tunnel for L2 purposes a bridge port is created for the P2MP tunnel object.
In the current implementation P2MP tunnel creation flow exist with the exception of a bridgeport not created for P2MP tunnel. These tunnels are also referred to as SIP tunnels. To support using P2MP tunnel for L2 purposes a bridge port is created for the P2MP tunnel object.
![P2MP Tunnel Creation](images/p2mptunnelcreate.jpg "Figure : P2MP Tunnel Creation")
__Figure 5.2: EVPN P2MP Tunnel Creation__

Expand Down Expand Up @@ -690,19 +691,19 @@ VxlanOrch will be enhanced to support the above two requirements.

### 4.3.4 VXLAN State DB changes

In the current implementation there is an entry for every tunnel in the STATE_VXLAN_TABLE. This is populated by the vxlanmgr when the necessary kernel programming is completed. This occurs when CFG_VNET_TABLE is populated with an entry. This entry reflects the kernel programming status and is typically associated with the VTEP (SIP only tunnel).
In the current implementation there is an entry for every tunnel in the STATE_VXLAN_TABLE. This is populated by the vxlanmgr when the necessary kernel programming is completed. This occurs when CFG_VNET_TABLE is populated with an entry. This entry reflects the kernel programming status and is typically associated with the VTEP.

Since BGP EVPN tunnels are auto-discovered there needs to be a mechanism available to list all the auto-discovered tunnels. Multiple BGP EVPN tunnels are associated with the same VTEP (SIP only tunnel) which is not reflected in the current table.
Since BGP EVPN tunnels are auto-discovered there needs to be a mechanism available to list all the auto-discovered tunnels.

In addition there is a need to display the operstatus of the tunnel. The operstatus is reflective of the dataplane forwarding status of the tunnel. The operstatus can toggle depending on the dataplane state.
In addition there is a need to display the operstatus of the tunnel. The operstatus is reflective of the dataplane forwarding status of the tunnel. The operstatus can toggle depending on the dataplane state. For P2MP tunnels, the state is always `p2mp`. Otherwise `up` and `down` are used on P2P tunnels.

A new table STATE_VXLAN_TUNNEL_TABLE is used for the above purposes.

A new field "tunnel source" - EVPN or CLI will be added to indicate the source of tunnel creation.

The tunnel source (EVPN, CLI), SIP, DIP can be filled in during creation time.

The operstatus of a tunnel will be updated based on notification from SAI through a notification channel similar to port oper status.
The operstatus of a tunnel will be updated based on notification from SAI through a notification channel similar to port oper status for p2p tunnels.

Applications within orchagent can subscribe to the operstatus changes of the tunnel through a subject/observer class model.

Expand Down Expand Up @@ -1120,8 +1121,7 @@ Linux kernel version 4.9.x used in SONiC requires backport of a few patches to s
5. show vxlan remotevtep
- lists all the discovered tunnels.
- SIP, DIP, Creation Source, OperStatus are the columns.
- Since P2P tunnels are not created in the hardware on the flow where P2MP tunnel itself is used flooding using L2MC group, this table will not be populated.

- OperStatus is `up` or `down` for P2P, or `p2mp` for P2MP tunnels.
+---------+---------+-------------------+--------------+
| SIP | DIP | Creation Source | OperStatus |
+=========+=========+===================+==============+
Expand Down