[SubnetDecap] Add subnet decap HLD #1657
Conversation
Signed-off-by: Longxiang Lyu <[email protected]>
|
community review recording https://zoom.us/rec/share/KaQiZpywL0GZJcWsvKU6VHAGqc3b4PZRrUd4Rx5oCEo8uW9r3_6w5mCa_gvHChjw.SXuFsVexIf3qfWNd |
doc/decap/subnet_decap_HLD.md
Outdated
|
|
||
| ### 6.6 CLI | ||
|
|
||
| TBD |
There was a problem hiding this comment.
Please capture the CLI for better clarity on how this feature is enabled?
|
|
||
| In Azure, Netscan probes the network paths/devices by sending IPinIP traffic. The IPinIP packet crafted by the Netscan sender has the outer DIP equals the destination device Loopback address, and the inner DIP equals the IP address of the Netscan sender. When the IPinIP packet is routed to/received by the destination device, they will be decapsulated and the inner packet will be routed back to the Netscan sender. | ||
| As of today, Netscan uses this IP-decap based probing to detect route blackholes in the Azure network. The limitation is that Netscan is only able to probe the networking switches without the capability to detect any route blackholes for host nodes, especially VLAN subnet IPs. Due to the fact that the host nodes don’t have native IP-decap functionality, it is more appropriate to implement the IP-decap functionality on T0 SONiC as SONiC supports IPinIP decapsulation, and T0 SONiC will respond to the Netscan probes on behalf of the host nodes to decapsulate the Netscan IPinIP probe packets with DIP as any VLAN subnet IPs. | ||
| In this design, subnet decap is introduced to enhance SONiC with the capability to generate the decap rules for the VLAN subnet so IPinIP packets from Netscan with DIP as either VLAN subnet IPs could be decapsulated and forwarded back to the Netscan sender to allow Netscan to have the awareness of any possible route blackholes to those destinations. |
There was a problem hiding this comment.
Could you please clarify, how the route blackholes are identified/detected?
doc/decap/subnet_decap_HLD.md
Outdated
| ``` | ||
| ### SUBNET_DECAP | ||
| ; Stores subnet based decapsulation configurations | ||
| key = SUBNET_DECAP|subnet_type ; SUBNET_DECAP|vlan |
There was a problem hiding this comment.
what is the significance of the subnet_type here?
With subnet_type being vlan, is it helping in programming HW table in anyway?
Instead, we can have VLANID as part of the key itself?
| ### TUNNEL_DECAP_TABLE | ||
| ; Stores a list of decap tunnels | ||
| key = TUNNEL_DECAP_TABLE:tunnel_name ; tunnel name as key | ||
| tunnel_type = "IPINIP" ; tunnel type |
There was a problem hiding this comment.
are you planning to have any other tynnel_types here other than IPINIP ?
There was a problem hiding this comment.
No, we only support IPINIP tunnel in this HLD.
| ``` | ||
| ### TUNNEL_DECAP_TABLE | ||
| ; Stores a list of decap tunnels | ||
| key = TUNNEL_DECAP_TABLE:tunnel_name ; tunnel name as key |
There was a problem hiding this comment.
How is the tunnel_name configured?
Please capture the CLI
There was a problem hiding this comment.
The tunnel name is statically templated, check the workflow.
doc/decap/subnet_decap_HLD.md
Outdated
| ``` | ||
| ### SUBNET_DECAP | ||
| ; Stores subnet based decapsulation configurations | ||
| key = SUBNET_DECAP|subnet_type ; SUBNET_DECAP|vlan |
There was a problem hiding this comment.
Is other subnet type or interface support? Example for Ethernet L3 interface?
There was a problem hiding this comment.
updated the db schema, the subnet type now is an attribute, could be either vlan or vip.
|
|
||
| ### 6.4 VLAN Subnet Decap | ||
|
|
||
| #### 6.4.1 VLAN Subnet Decap Rule Generation |
There was a problem hiding this comment.
since swssconfig is oneshot script, how to handle the change of vlan interface address after swssconfig playing?
There was a problem hiding this comment.
That is not supported/covered by this HLD
| #### 6.2.3 STATE_DB | ||
|
|
||
| ``` | ||
| ### TUNNEL_DECAP_TABLE |
There was a problem hiding this comment.
why add new state db? Its role is not indicated in the following workflow diagram
There was a problem hiding this comment.
updated the workflow diagram to indicated the state db.
|
@lolyu can you please add the code PRs to this HLD PR? Thanks. |
|
code PR is not ready, move to backlog for future release |
Updated, could you please move the feature in progress? |
|
@bingwang-ms @lolyu can you please help to address the comments? Thanks. |
1. Update DB schema 2. Update workflows with new DB schema 3. Add warm-reboot and CLI sections Signed-off-by: Longxiang Lyu <[email protected]>
|
Hi @prvattem @philo-micas, the PR is updated, and could you please help review again? Thanks! |
|
Target 202405 release. @bingwang-ms will take care |
Add the subnet decap feature HLD to support Netscan over VLAN.