[doc] Adding floating NIC packet flow and SAI API design. #665
Conversation
|
/azp run |
|
Commenter does not have sufficient privileges for PR 665 in repo sonic-net/DASH |
|
/azp run |
|
Commenter does not have sufficient privileges for PR 665 in repo sonic-net/DASH |
|
/azp run |
|
Commenter does not have sufficient privileges for PR 665 in repo sonic-net/DASH |
Referring to sonic-net/SONiC#1911 and #665, to support FNIC pipeline, this PR adds the followings: - ENI mode VM, FNIC - ENI drop counter `eni_trusted_vni_entry_miss_drop` - Action `set_inbound_direction` is not defaultonly at table `direction_lookup` - table `global_trusted_vni` and `eni_trusted_vni` --------- Signed-off-by: Junhua Zhai <junhua.zhai@outlook.com>
|
hi @r12f - we had talked about waiting 1 week to merge this one. Is it ok to merge? K~ |
|
hi guys, do we want to merge this one? TY, Kristina |
|
Per @r12f till keep open. Needs to be updated. |
| 1. If ENI is not found, we drop the packet and increase the drop counters. | ||
| 2. Otherwise, the packet needs to always land inbound pipeline first. This is done by setting the VNI lookup table entries. | ||
| - In the case above, both initial packet (from VM) and return packet (from PLS) are both going into the inbound pipeline. | ||
| 3. In the inbound pipeline: |
There was a problem hiding this comment.
Since fnic is designed to be a hairpinning eni, it shouldn't handle process packets where the Destination Address is the CA (private address) of the fnic. The fnic ENI should be dropping such packets, and increment relevant drop-packet counters, else it opens up some avoidable corner-cases
| - ENI mode: A single ENI can be either a VM NIC or a floating NIC. A ENI mode is introduced to differentiate the two types of ENI and must be provided during the ENI creation. Once set, the mode cannot be changed anymore. | ||
| - Mixed-pipeline support: For supporting flexible deployment, each DPU can hold multiple ENIs, some of which are VM DASH pipeline, and some of which are floating NIC. | ||
|
|
||
| With this, at high-level, the ENIs in a single DPU will be represented as below: |
There was a problem hiding this comment.
The implementation should not assume that the fnic will be in the path for the return packet as well.
The user has the ability to setup a topology with asymmetric routing, which might have the fnic in the path in the forward (SYN) direction, but not in the reverse (SYNACK) direction.
This might have implications in the connection-tracking behavior.
| 3. Create the outbound side flow in the same way DASH VM pipeline. | ||
| 4. Applying any packet transformations that is specified during the pipeline. | ||
| 6. Route the packet out based on the underlay IP to the right port. | ||
| 7. The packet leaves the DASH pipeline through the port. |
There was a problem hiding this comment.
We also support chaining of floating nics, so the destination can be another fnic (or a VM ENI) that's hosted on the same DPU. So the implementation should make no assumptions that block this scenario
|
|
||
| The floating NIC pipeline should have support the same scaling requirement as the regular VM pipeline. Please refer to the [SONiC-DASH scaling requirements](https://github.com/sonic-net/SONiC/blob/master/doc/dash/dash-sonic-hld.md#14-scaling-requirements) for more details. | ||
|
|
||
| ### 4.3. Reliability requirements |
There was a problem hiding this comment.
FloatingNic should also support LB-Fastpath. This will help bypass the lb hop for PE traffic after connection establishment.
|
|
||
| The floating NIC pipeline should have support the same scaling requirement as the regular VM pipeline. Please refer to the [SONiC-DASH scaling requirements](https://github.com/sonic-net/SONiC/blob/master/doc/dash/dash-sonic-hld.md#14-scaling-requirements) for more details. | ||
|
|
||
| ### 4.3. Reliability requirements |
There was a problem hiding this comment.
One feature that we don't want fnic to support is the load-balencer service. In that, the packets forwarded by the LB tents to be DNAT'ted to the ENI's CA (private address). And since we're operating in the hairpinning mode, this feature is irrelevant.
|
|
||
| Appliances are frequently used for applying SDN policies for inter-VM traffic, such as ACLs, or to provide SDN functionality for machines that do not have the SDN stack running, such as On-Prem networks or bare metal. | ||
|
|
||
| To support these scenarios, we propose the floating NIC (FNIC) pipeline in DASH which helps us model the SDN behavior in the context of appliances. |
There was a problem hiding this comment.
Just to add why we're calling this floatingNic and to disambiguate from FloatingIp.
Traditionally in cloud environments, a NIC is always attached to a compute instance or VM. With the Floating NIC concept, the NIC itself becomes a first‑class, fully functional, standalone entity that does not need to be attached to a VM. Because the NIC exists independently of compute, we refer to it as a Floating NIC.
4 participants
Adding design doc for describing the floating NIC packet flow and SAI API design.