[Sonic] PL on NSG and Inbound flows #341
Conversation
| @@ -915,6 +938,14 @@ For the example configuration above, the following is a brief explanation of loo | |||
| d. Packet gets transformed as: Overlay SIP fd00:108:0:d204:0:200::0a01:101, Overlay DIP 2603:10e1:100:2::3c01:201 | |||
| e. Second Action is Static NVGRE encap. | |||
| f. Since underlay sip/dip is specified in the LPM table, It shall use Dst IP (25.1.2.1), Src IP (30.1.2.1) | |||
| g. Thus the packet is send with two headers - One Inner IPv6 and another Outer IPv4 | |||
There was a problem hiding this comment.
Minor: "is send" ==> "is sent"
| @@ -915,6 +938,14 @@ For the example configuration above, the following is a brief explanation of loo | |||
| d. Packet gets transformed as: Overlay SIP fd00:108:0:d204:0:200::0a01:101, Overlay DIP 2603:10e1:100:2::3c01:201 | |||
| e. Second Action is Static NVGRE encap. | |||
| f. Since underlay sip/dip is specified in the LPM table, It shall use Dst IP (25.1.2.1), Src IP (30.1.2.1) | |||
| g. Thus the packet is send with two headers - One Inner IPv6 and another Outer IPv4 | |||
| h. Inbound packet for this flow: | |||
| h.1 The return packet for the above flow shall land on an SLB MUX (30.1.2.1) as NVGRE packet | |||
There was a problem hiding this comment.
h.1 through h.5 need to be indented for a better read.
| g. Thus the packet is send with two headers - One Inner IPv6 and another Outer IPv4 | ||
| h. Inbound packet for this flow: | ||
| h.1 The return packet for the above flow shall land on an SLB MUX (30.1.2.1) as NVGRE packet | ||
| h.2 SLB MUX (30.1.2.1) shall encapsulate this to another header with standard GRE key, say 100 and forwards to Appliance VIP |
There was a problem hiding this comment.
Please explain what is an appliance VIP. How does SLB MUX know the appliance VIP (from packet header information)? In this case, I believe the appliance VIP is 25.1.2.1? In my view, we can do a better job in explaining h1 through h5. Also, it is not clear at which point the flow fixup happens and what will be the inbound flow after the flow fixup (which means we will bypass SLB MUX). Appliance receives a packet with three headers (each one GRE encapsulated). What does it mean for the receiving appliance? How will the packet be different when it arrives through the fast path?
There was a problem hiding this comment.
Corrected the statement. SLB MUX knows the appliance IP based on the incoming packet header. Appliance VIP here is not 25.1.2.1 but the PA. As mentioned, fastpath and flow fixup shall come as a separate documentation.
| h.1 The return packet for the above flow shall land on an SLB MUX (30.1.2.1) as NVGRE packet | ||
| h.2 SLB MUX (30.1.2.1) shall encapsulate this to another header with standard GRE key, say 100 and forwards to Appliance VIP | ||
| h.3 Appliance shall first decapsulate the outer header and map it to a flow | ||
| h.4 Second header's dst mac shall correspond to ENI MAC, as overwritten by SLB MUX |
There was a problem hiding this comment.
Is it really true? I thought the SLB MUX drives the destination appliances' VIP from the inner DMAC? Why does it need to overwrite it? What am I missing?
There was a problem hiding this comment.
No, SLB MUX just overwrites the inner dst mac to the ENI mac. SLB mux drive the IP from the packet header (Dst IP, Port)
| @@ -1008,7 +1075,7 @@ For the example configuration above, the following is a brief explanation of loo | |||
| g. Underlay DIP shall be 50.1.2.3 (from mapping), Underlay SIP shall be 55.1.2.3 (from ENI) | |||
There was a problem hiding this comment.
On e.3 (3 lines above), since both src and dst are CA addresses, we should call out that it is a source CA
| g. Underlay DIP shall be 50.2.2.6 (from mapping), Underlay SIP shall be 55.1.2.3 (from ENI) | ||
| h. Third Action is Appliance Encap for id 22 | ||
| i. Packet shall be encapsulated with Outer DIP as 100.8.1.2 and SIP as VIP of this originating appliance card with VNI of 101. | ||
| j. Inbound flow shall be similar to PL and outer encap shall be of the SLB MUX and not of the NSG appliance. |
There was a problem hiding this comment.
We have not described inbound flow for a PL in any of the examples. Should we not describe it? Also, what happens when the flow fixup happens due to the ICMP redirect? What will be the resulting inbound flow look like when the packet comes through the fast-path?
There was a problem hiding this comment.
For PL, inbound flow is created based on outbound flow. I'll provide more details as a future commit. Also Fastpath will come as a separate section.
|
@reshmaintel to take a look, per DASH Behavioral Model call on 3/16/2023 |
|
@mhanif , @reshmaintel , let me know if you've outstanding comments/concerns. I can address it in my next PR. |
There was a problem hiding this comment.
Is Nvgre required for inbound towards VM as well ? Would the appliance add Nvgre outbound if the packet is ST/PL and on inbound add VxLAN encap back to the VM ?
Update Sonic HLD for: