DASH Community Weekly, 8 Mar 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: SONiC DASH Workgroup Community Meeting Mar 8 2023

Description

PR289 - Still needs volunteer - Dockerfile.saithrift-client has a static tag in the FROM instruction

PR348 NAT Scenario with 2 use cases: ClarkLee @ Alibaba
Packet Processing Pipeline in NAT Scenario (SNAT and DNAT)

Yanzhao - plans to upstream into SONiC Repo (to cover next week)

Save 30 min next week for more discussion & updates to PR348

A

Reading together, and so we just kind of covered what we talked about last week, while we were on the call and this week, I believe Alibaba had a use case they wanted to present, and if anyone else has something please let me know their PR's. They want to cover Etc Alibaba. Were you ready to go.

B

um Okay, uh I'm ready, yeah; okay, let's just share my screen. Please.

A

Do yeah is that fine with everyone else on the call.

C

Yeah sure, okay.

A

Great okay: go ahead.

B

A

Are you presenting Clark.

C

We may have lost him, we.

A

May have lost him. Okay, maybe.

C

When he went to share this when he pressed the wrong button, yeah.

A

Possible: okay, with.

D

A

Okay, all right in the meantime did we have other PRS. We wanted to cover from anyone else's side, uh Prince or anyone else on the call I have a list if we want to look at them share my screen.

B

A

A

All right, I'll stop presenting.

E

B

Okay, this one.

B

A

Oh, you found it good.

B

Yeah yeah I um I, don't know how to um how to show this uh markdown in in my browser, so I used a vs code just get started. Okay. um Today we are sharing uh our scenario of net, which we have two use cases.

B

Actually one is snet for uh cloud cloud user to access, internet service and dnet forum, uh hosting some surveys for uh internet users, and we are trying to, and we um we are sure net is a pretty uh normal use case and it also a cup include a routing service for the underlay Network and also have the building service for um for totaling reason for totally so we set up this hld is for the testing purpose for um for net Behavior. Uh We, uh the critic, uh the several key.

B

Component several key we we are checking is CPS that that's connection setup rate per second and data processing, bandwidth, BPS and PPS, and also we are testing uh flow scale. Here we can see our topology here. We are in this hld. We are using uh Appliance for Dash, um we which we have a switch and some smart Nick here in the appliance.

B

So we can see um v-net v-net one. We have a vm1 uh when vm1 is assessing the internet. We are using s-net service and, if and uh so uh use case, two is dnet. For example, we host service in v-net2 uh in vm2, reside in vnet2 and internet user. Just assess the this service in the cloud. So thinner is used.

B

um So far, so good for the topology.

A

I think so from my end, anyone else have question on the descriptive part.

B

Okay, I guess we keep going okay yeah, so we present the first first use case. That is as net scenario.

B

um First of all, when VM sent traffic to the Appliance we uh late, we will determine the direction of the packet. uh If the vxlan header is present, you think it's an outbound packet. So the first thing we do is to look up the flow table, uh the outbound flow table.

B

If we found that we go through the fast path, just just take the action of replacing the source, IP and Source port and do the decapsulation of the Via Clan header and then use the inner header to do the routing lookup and do metering and Counting and then send to the the packet in to the internet and Counting and metering is optional.

B

If we uh at this point, if the outbound flow lookup is failed, uh we start the slow path.

B

uh First, we look up the ethnet rules table and find a nuke a new pair of source, ipn source port, and then we do a vdap lookup to find the vtap IP for the responding packet to set up the inbound flow table and then the next. We use the information we fetch in the slow path and set up a new entry in outbound flow table and inbound flow table, and then the the rest of the the rest of the action is the same as the fast path.

B

But it's, but it's done in soft in software, usually the fast path we have a hardware table here. uh It's not necessary to be a hardware table, but usually it is a hardware flow table.

B

um Any feedback just.

C

As a comment, we don't generally view fast path and slow path as one being in Hardware one being in software. In fact, we always view everything being an offload that slow path shouldn't be much slower and it can still be a hardware offload. We don't we don't say slow path. Is software or fast? Math is Hardware. It's supposed to be in dash everything's supposed to be a hardware envelope, so we Define the functions, and then we allow the suppliers to figure out how to do those functions as a hardware upload.

D

C

Don't even really talk about software versus Hardware, because the implementation is is uh specific to devices on the market. They're all different. But my point is we? Don't we don't say pass path? Is Hardware slow path to software? In fact, they're both Hardware offloads in in our minds, yeah.

B

Yeah, sorry um uh that that's true, uh because slow path uh can also be done in the hardware, uh but it's uh it takes more steps than the fast path. Only you're right.

C

We view it as being more slow path to us. It means just it's more complex and there's more stages, there's more things to do than in past path, but that's all we mean by slow path it just it it's more complex for sure, but yeah. We don't associate it with software Hardware uploads, it's just more complex work.

B

Yeah I got I, got you yeah, that's true. uh Slow paths only take several more steps.

F

C

E

Do we also do the eni lookup vni lookup, that is defined in dash before the first outbound flow lookup.

B

um Here we don't.

E

Don't do any local care.

B

About the directions.

E

Sorry, what about Direction, please.

B

uh The direction only uh takes in the first step, for example, we treat uh we explain, encapsulated packet as outbound packet for uh for ethnic case.

E

I think so um inbound will not have vxline end cap.

B

Yes, it's backward, it's a responding packet.

E

Okay, the flow lookup happens before the S natural lookup.

B

E

B

First, uh for example, if if the first packet comes, we uh look up, uh outbound flow table, lookup, May Fail, it must fail, and then we do. The ethnet look up to is to obtain some information to create to create the outbound float table and then the second flow belongs to the same flow uh arrive, and we we uh look up into the outbound flow table and we we may get a hit and then do the first path. Processing.

E

Yeah I I thought that does not lookup might come before the first outbound flow lookup as well. That's what I had thought: okay.

B

D

B

This way, we only look up as net rule once.

B

And then we we always want the fast path right, but but first packet comes, it must fail and then we go through the slow path and then and establish everything.

D

That the prime uh regimen, the background deployment scenario will be different because we put at the Gateway so the between the crowd and the public internet. That's why I like say we were using the vxlan incapad packet at the decision to say it's.

E

Mm-Hmm: okay, okay,.

B

Sorry, I I missed something in the in this in this uh topology yeah uh here. Actually we are, we are uh the the appliance is taking the role as a Gateway, so yeah I missed this part. Sorry.

B

So that's why the um ethnet pipeline uh can.

G

You go back to the to the topology.

B

G

I think it may be helpful if you draw the dash device.

G

um You know um somewhere right, so you know this. You know your Appliance is different from the dash plans. Right. So therefore, you'll enjoy your net plans here and then then there is a VM that can go to the dash Appliance and then go to your net plans right. So I think that that is the topology. Maybe you know enjoy it. So then we have a clear uh connection. You know how this is related to the dash or right. So maybe that firefights.

B

Yeah, yeah, okay, so uh this this topology is, uh is simplified, so uh I I can add another more comprehensive topology here in the as the as the architect, uh as as the network architecture.

D

This appliances is a dash appliances, which is a Smart Switch. That's why he uh I.

G

Did that but the usage is uh it's different right, so the physical entity, uh you know, is different right. So yes,.

D

The entity is different yeah, so this one we were the time it's different from the current Dash use case.

D

B

Maybe another picture showing the role of the uh the dash Appliance, maybe uh more clear, well,.

C

First of all, if you want to call it a switch, then just call it a Smart Switch, not an appliance, because they're slightly different.

B

And actually, this guy will have multiple, uh multiple, dpu or uh or.

C

B

Hardware reside on this Appliance, it has a switch and it also has uh multiple cards.

C

Yeah, that's uh it doesn't matter how many Rus that's our definition of a smart switch. It has multiple dpus on a switch, so think of it. As me, in terms of switching layers, the tier one 400 gig um switch uh 12.8 t with multiple dpus on it. That's what we call a Smart Switch, it's not called an appliance gun. Appliance is really a server that holds multiple dpus. So that's an appliance and a Smart Switch is a switch which holds multiple dpus.

D

Yeah, we were changing the names and we don't. We should not call the appliances, we should call it a Smart Switch.

C

Yeah and also you know from uh from a hierarchy of software and stuff, you know the switches running Sonic and, and it has multiple dpus and neural, running Sonic and Dad. So I think it is a Smart Switch, but you're talking about most and it could you know as reference it could sit at a 201 or it could sit anywhere in the data center button, because we tunnel all those VMS kind of tunnel to it, anyways using VH1 or something and sometimes.

A

And I, just a small piece, I put a little piece of artwork in the chat window and you could attach it to your switch to denote that it's Dash like we do in our hlds, okay or whatever you want to do just a suggestion.

B

Yeah, no, no it it's a good suggestion, uh and that may be more clear for people to understand the the usage or the role of this device, and this is actually a smart smart switch. As as previous uh we we're talking about the name. We may change it to uh make it more clear. It's okay, yeah and.

C

Hey, maybe they can use some of the pictures that we already have in documentation for Smart Switch Christina. Maybe you could just I'll, put a link and find that that way. People know that is just a I think you're talking about a standard, Smart Switch. So it's not something new there and then that will just make it more easy for people to understand.

A

C

It'll be easier for them to scope out and show all the containers and where they are later on. When you get more deep into this.

A

C

It sounds to me that they're talking about doing the regular, you know kind of trying to do the regular past path, but adding they're, adding this map functionality to when you don't find a fast path, entry and and they're. Just the slow path is what they're trying to Define I. Don't think it changes anything in the architecture at all. It's just what are those steps in the slow path that need to get done that are different than what we talk about today?

C

I think, that's where the uniqueness is and I think we all understand that and I'm doing that, it's not. We haven't defined that so they can so I. Think that's! That's fine, I'm, not sure that the fast path actually needs to change much. It's a slow path that needs to change or at least add, add this functionality.

D

The first part part of the part of it it will be because here we don't need the midnight it should look up. So that's. Why, like we want to, like, probably have a separate like a model for that purpose, because that's why that we specified to say hey, there's we using the in capital and determination for say this is the album, the traffic so because normally you do the B9 lookup. First, then, policies applied on the pervian line, but this is the global policy. So that's the main difference. Yeah.

H

Yeah so I think I see that it is slightly different from the the other model like what we have in the the other Sony casually. So in this there is no eni lookups right like and, and these tables are not associated to enlar right. It's the it's part of the v-net okay, so I'm, just trying to uh understand like how you associate this VM packet to a to a v-net.

B

uh Actually, we use the vni to as part of the key to determine uh what we need. This packet belongs.

D

Maybe you can continue on the inbound finishes and then we can see the the more detail on the flow yeah.

B

Okay, so um let's take a look at the inbound packet processing um when the responding packet comes from the internet. We determine this uh is the inbound inbound practice.

F

B

And we first uh first thing: we do is to look up the flow table and then uh because the the table engine is created in the previous slow path and then we we may have this look up hit and do the re, uh the replacing the destination ipn port and do the vxn encapsulation, the VXL encapsulation uh data is actually fetched from this from this guy we type lookup to to obtain the destination IP of the VXL header, and then we use the encapsulated packet to do the routing lookup and then send the packet back to the VM.

B

This is this is the reverse path uh packet processing.

B

So one thing I want to say is that here the vdap lookup is to create the table entry in this in this guy. In this inbound flow table,.

A

B

Okay, so uh any questions.

H

So so in the inbound there is no um slow.

B

Path, uh yes, because and if we, if a packet uh look up in inbound flow table, lookup field, it's dropped for the ethernet as net processing as net processing. Oh we'll drop that packet.

G

But you have dnats right.

B

Yes, yes, it's another application right.

G

This scenario should have the exception, pass right.

B

Yes, dnet is uh a reverse another story. So, okay, if this this is fine, we can go, uh go over the dnet and then we we may discuss later.

B

Okay, go ahead.

G

Hey yeah yeah, but but I think. If, ultimately, you will combine this snap and dnat into one single pipeline right, so you will not have two pipeline. Yes,.

B

Yes, yes, because we just separate them uh in into use case. So so we can uh describe the logic separately. So I think that may be more uh clear for for each.

A

So two use cases to describe the logic. But ultimately converge. Yes, the pipelines. Yes,.

B

And an ethnet lookup and dnet lookup, they have different uh IP addresses, so we can distinguish them right.

B

For example, uh okay,.

I

B

Talk uh talk about DNA first, and then we may know how to do how to distinguish this. uh These two kind of packet, okay,.

G

B

Okay, so when, uh in Tina scenario, the inbound packet is from the internet we've, we uh we determine this. uh If, if the packet income from the internet has no vxline header, we think is actually net our inbound packet. We first do the lookup in the inbound flow table. If we do find it just replace the test, ipn port and do we extend encapsulation and do the routing and then send the packet to the VM.

B

If it's, if the packet missed, you do the dnet rule lookup and then do the vtap lookup um and then use the information obtained from the previous step and set up the new flow table of inbound flow table and open Flow table here.

B

um And when the VM is sending the dnet outbound packet, sending the packet out, we.

B

First, we look up, uh we we see, we see the big send encapsulated packet, we do the outbound packet look up and then because this entry is already set up, uh we may we must hit and replace the source IP uh import and do the Vixen keycap to the routing uh using the decapit decapsulated packet and then do metering and Counting optionally and then finally, we send the packet into the internet so um in the outbound flow processing here and the outbound flow.

B

In no sorry here in this two picture we can see uh you can see the packet incoming from the internet right so for the ethnet lookup for retina lookup. We first look look up in the inbound flow table.

B

The inbound flow table, the the IP addresses if we host, if we host the service in the uh in in this VM right sorry, okay,.

I

B

For example, we host the service in the vm2 we may. uh We may uh configure our set of ips.

B

Instead of IP addresses in the to the public internet right, so we may have a list of IP addresses for DNA local.

B

So when the packet comes from the internet, we we may first, we may miss, have a Miss on the inbound flow table, and then we do the DNA lookup and the DNA lookup may do May. um We created the table in uh made, create a table entry in the inbound flow table.

B

So if an internet packet comes- and it does not match and the dnet inbound flow and does not meet uh hit the inbound flow table as net inbound flow table lookup it, the packet is strong.

F

Hey I have a quick question. You know how do you decide whether you should go to the slow path or should stay on the fast path in the in this inbound DNX scenario.

B

Okay, uh we, if we uh we look up in inbound flow table and get an it, does not hit.

A

B

There's no entry in the lookup table, Yeah Yeah, so sorry, I, I, I I'm, trying to make it more clear uh if the packet comes from the internet and we look up in the inbound flow table of dnet and we don't find anything hit, we may trigger this package yeah.

B

And then the slow path will do a set of several step, for example, to look up the dnet match, uh ipn the port, and then we we may uh then do the vtap lookup for the uh encapsulation destination IP. And then we use this information to create the inbound flow table first.

B

So if that so then, the next packet, the second packet or later, comes to assess the same service hosted in the v-net 2 vm2. We may hit this inbound flow table, look up and do and go through the fast path.

J

Actually, we determine the v-net using vni how.

D

J

We determine the v-net in the dnat inbound case.

B

uh Because we we have this guy right, the vtap lookup. Actually, the this dnet rule contains the the host the the vni for the for for certain surveys. For example, we have service a running in v-net, one in v-net2 vm2. So this the network table may contain this information. Oh.

B

Yeah maybe contain information to to make this lookup happen and get it correct. uh Vip.

J

Lookup will later will give us the VNA. That's what you are.

B

Oh! No! No! No! Sorry this one! Only this one and the the tip.

J

Okay, I'm using.

B

F

So um I'm still trying to understand something. Basically here is that if, if there was inbound flow, lookup were to fail, would you not basically draw? Would you not basically drop this thing? Because if you, if you look at the outbound scenario, I mean I, would think that you're outbound.

B

F

So the outbound part would create an inbound uh reverse flow. Isn't it.

B

uh In t-net case, the inbound flow triggered the creation of inbound and outbound flow table and in ethnet case is, is.

F

F

Okay and then, how do we I mean in the case of let's say, DNA you're, showing this inbound scenario? How do you determine the direction? How do you know that it has come from the internet versus from the VM.

B

Yeah, we only uh look at this one if we have a vehicle and error is not from uh it's not from the internet for for Indina case uh sorry, in Tina scenario, we only determines the direction based on the uh absence of vxline header. If the package.

H

I think this should be based on a VNA value, not based on the vxline header or not right. If it matches the vni, then you determine the direction because.

D

The direction is always the based on the vxline header is present or not, because we are, this is the Gateway, so it's even coming from the internet, it'll always be a album.

H

I mean my point is like it's the same thing right like if you can look at the vni and determine the direction.

B

The V and I actually look up happens here. You know rules yeah because uh when, when for, for example, I if I host the service, uh finally, we I, we will have a IP for that. We actually hear called via virtual IP. The virtual IP is is for for that. Some kind of service.

G

I think they, assuming that from the internet, there is no VX and package right. So.

H

Then therefore, they just use that yes, yeah but I think that's what I'm little concerned about like. Typically, we can use the vni to determine uh the direction right if it matches the one in the rules, then you can determine the direction based on that here.

D

We are putting Gateway right and the Gateway is a constant event towards the internet. The traffic come from internet is no no Vietnam at all right. This is the Gateway use case. Yes,.

B

G

But it could be that either that from internet, if the customer want to you know doing some very exciting encapsulation, then you could send the packet with vxline right. So.

H

Yeah I mean why we have to restrict for that.

D

That's a good point right now, I think in Alibaba we never see that kind of package.

D

J

D

We assume negative VX management should be like within the inside the cloud.

B

I think this should be uh our use case, uh limitation or or some some kind of assumption here, because here from the internet to this net Gateway is not directly connected, and here in in this point and and in this Gateway we can uh in our Network we can. uh We can assume that any packet incoming from this device, yeah.

G

No I I will I I. Think that's fine right, so you know we we can just uh get some. You know, classification rule, you know if some users need to use a VI to do the classifically, we can have some additional. You know people blocks to do that clarification and doing some enable disabled right. So then you know you want to meet the Alibaba use case as well as other certificates. I, don't I, don't think! That's a you know this. You don't need to close those details later right.

G

So but let's try to finish the overall picture, but I think that that is definitely addressable right. So press.

A

G

If someone want to use a vni, we can add additional block and to enable disabled things right so I mean you.

B

Know yeah yeah only put it in the first step.

B

Hld is determine the direction of the.

G

Process yeah, that's fine.

B

Okay and okay: it's.

B

um That's all that's all for the pipeline and then uh do we have any more or more question or we can go. uh We can continue.

G

Oh, maybe I think on the pipeline that maybe we should add some graph to see. Okay, you know how do we, how do we, you know, differentiate the English, sorry DNA and S Nat right, so those kind of things because you you put them separately but ultimately, when you put the 1p4 you, you will get uh them converge right. So there's some classification to determine whether it is 16 Nano. Is that right, so yeah.

B

A

So, like a high level at the top of the document, seeing what we're attempting to describe as s-snap versus dnat and what we use. Something like that. Gohan.

G

I mean there must be some classification first, knowing that this is the United States.

B

Yes, you're right and actually we um the uh will I.

D

Think we mentioned it is nowhere here and I. Remember like.

A

D

Basically, we determine is that we do the DNA rule lookup or we do the as a natural recover, because after the the inbound flow table, Miss.

D

B

uh You can combine these two together right, for example. First we do the in dnet in Buffalo, table lookup and do all of this, and if here dnet rule lookup fail, we can do another thing right because in in here we we may just just uh assume that the t-net will look up. Maybe uh all is successful right and then we can do the creation of the flow entry. If this lookup fail, we can also to the sky. Oh.

G

They they don't understand, because when you do the dinner, you look up. You already moved to your exception path and you are coming back to the fast pass right. So I saw you will do the kind of fast pass first for all the flows, and then you know right so.

J

F

Don't want to fail.

G

And then go back to the fast pass to do another. You know a snap flow lookup right so.

B

I think they can chain together, because the slow path is uh is related to, for example, in this, in this case, is DNA scenarios low path, but the the first path of uh the s net inbound.

G

It's not that efficiency, if you're, seeing all the traffic, for instance, we'll go through the fast pass first and then go to a slow pass to do a dinner look up and then go back to the fast pass for the inbound. Ss stand for lookup and that's not efficient right. So for all this is that uh package will go through the snow pass, which is now efficient right and.

D

um No, no, no. Basically, it's like an inbound flow table. Lookup. First then, based on email look as a hit. If it's a Miss for the S9 case, we also trigger the dnet lookup, but then it will be also failed. Then it will be dropped so yeah we probably need to add, like I say, for the throw pass, because normally this should be always wrong and so on. We didn't draw that diagram, but once these two combined, then you have the Deep net lookup for the fail case anyway.

B

I

B

Is which is more reasonable right.

G

So so, and I I think the you know it's somehow. You know why that has to be on the slow pass.

D

Because that's uh because we consider the flow lookup at the fast pass right, then then, if the Miss.

G

But when you say slow pass is that down by P4 now or down by the acid go down by the arm core.

B

Yeah uh previously we don't, we think all of them may uh can be. Hardware uh can be accelerated in Hardware on the path.

D

It's great depend on the the hardware devices we we got right. That could be like purely the throw path. What we have here could be purely in the software or could purely also be in the hardware. It really depends.

H

I think this is the exception path right. It can.

D

Be yeah yeah. This is exception.

G

But you you in the P4 program, you will describe all this right so in the P4 yeah. The um the reference pipeline will display describe all this right.

D

G

B

Yeah, do we do be combined together.

J

Well, one quick suggestion: basically I don't know, maybe, as in the denatural look up right, maybe we can say what is the key? What will be the output and I think if you put that right, that will be more clear at what is the exact outcomes yeah.

B

uh Yeah, actually we have this uh in in the rest of the this hld later.

J

Okay: okay, okay,.

A

J

A

We doing on um time Clark with sound okay, we've got about 10 minutes left. So how.

B

Are we looking here, okay, so.

A

B

Examples, okay, yeah, yeah yeah, so continue so do some uh table definition. For example, we have some uh 2D 2vnet being at one and and moving at two and we defined the v-net. Encapsulation is uh static, vxline and then we describe some uh overlay routing table here. Running type is encapsulate this Vixen inverter and this one is um yeah another rule, and then we have dash s net Rule table, for example, The Source IP. Is uh it this subnet and then we go to the destination?

B

Is all and then we have a list of uh usable IPS here and then this one is uh similar, but for different uh for different Source, uh some that okay and then we just we may um we just have a overall concept here. Only and then we have a vcap table like this. It's a list so uh so we we see uh an example of the ethnet first packet as net first packet also refers to the the uh as net in s-net album slow path right. Oh no! No! Sorry!

B

The fast pair and slope describe here so when vm1 with IP uh 10, 1 0 10 and go to the Internet it first. uh If we, uh because it is the first packet, it must go to the go through the slow path right, so we uh look up to the s-net root table and we have a v-net and uh Source some net and we got this to any dip. We have this this list of IP usable and then we do the over uh overlay routing table to look up uh uh when the the dip is.

B

uh The dip is 30, 000 22 and then we we have this table look up and then we use this tip. We use these two information to create the outbound slope uh table. First, we have the inner IP and usable and select one of the.

B

I

Select one of the.

B

Source IP, that is.

B

111.1.1.2337 and and then ask part and do the vxline decapsulation. This is the action of the this. Is the outbound flow table. Okay,.

H

So how did we choose the export.

B

Which one the export as Port is.

H

Port yeah, like okay.

F

Yeah, since you are rewriting your sport, so I think the question is: how did we get that yeah.

I

B

I will go through this okay.

D

You should be in the configure, I think empowering we didn't put in the company.

B

Yeah yeah we we did not show this configuration right. It should.

J

B

It should be a configuration because the source IP list and the the soft spot list is. It should be in some some table.

B

Table lookup yeah and then the the.

B

uh Okay and then the this is the reverse uh inbound flow table, and we put this uh dip uh 101.1.1.237 and Export to to map to a D part example- and this is the protocol- and this is the action action- is rewrite: IP and uh Divi, and I and vsi incap for some the NDC information.

B

uh This is the first packet and then the the second packet uh of the s net. We go the slow path, uh the fast path, sorry, it will go through the fast path because the lookup hit and find the action and it to the Decap action and Route the packet out to the internet and then the the reverse path. When the internet packet with the.

B

Ip11.1.1.237, it will find the entry heat here and do the uh action at the encapsulation and then send the packet to the and Route the packet out to the vm1.

B

B

Okay, this is the s net processing with a table and then for the dnet.

B

The first packet is for Inc, the internet comes in packet to uh to the Gateway and we go through first, we we must have missed, and then we we go through the snow path and we look up the dnet Rule table to find the uh yeah to find the test iPad and part, and then we have our route here and we have a overlay, Round Table look up and we find that the uh the IP oh and found that we should encap this packet with this information and then we first uh to we first create this inbound flow table for the dip and the part.

B

And then we do the action in this slow path and then run the packet to the VM and the the next packet. uh This thing is the same service will uh got this inbound flow table hit and do the fast path, processing.

J

A clock one question: on the previous one: okay: this will go. Oh.

D

B

uh We we without vxn header packaged.

J

Okay, so how means is it possible that that same interface can be used for multiple v-net.

B

uh The same interface, foreign.

B

Here we have, one, VIP is unique, so we don't uh for in this case we it should be. The the VIP is public. It's it's.

J

Global right so you mean to say it I mean my question is how will we determine the VNA from this because we have to determine the v-net so Vena just to determine from either from VLAN or physical interface.

D

No, it will be based on the the VIP look in the VIP lookup, because uh this is this is a public VIP right and then let me determine the service and services also have the associated with the B9.

J

Oh okay, so basically either from The Source, API or destination AP. Yes,.

D

I believe it should be. Yes, it's a definition, IP right.

J

Because this is in.

B

J

Okay, okay, yeah.

B

It's destination IP, it's and it's Global, IP, it's not associated with any uh any tenant or something.

J

So we have one more table which will actually determine this map. Table will be there, which will say that this National p2vnet or oh, it will be part of this okay, okay,.

D

I think it will keep put in the configure it should be also put in here just showing like the BNI it's uh after the the net lookuper should be providing the v9 also right now.

H

I think we need the clarification in the document like how do you map this 111 to 190 195, to win at one I? Think that's not uh clear from the document. So it's.

D

In the config, I believe yeah.

H

But, but to win it one, the point is: how do you map this destination IP to v-net? One right this this rule is part of unit one right, but in order to look up into the win at one, you need to identify a.

D

Is a result from them so based on the IP lookup, it's v-net one, because this that's the IP, the vi. It's a VIP.

H

Yeah but which table will tell you: okay, I think we that that clarification is missing. Yeah.

A

To break in guys it's ten o'clock, do we want to keep going or does everyone have 10 o'clock meetings yeah, um because I would love to pick this up next week for a half hour? If we want to keep going through it or what do you guys think.

H

A

H

F

Next week next week,.

A

So what I'm going to do real, quick, real quick, is just share my screen so that you guys, can you see my screen?

A

So this is PR 348 um it's right here and be pretty easy to go ahead and go in and make some comments or suggestions. But I've I've been looking through it. While we've been talking here and um you know just go here: do a viewfire yeah do a view file and take a look at it and see. You know see where you think these little pieces might help in understanding and make changes and put it in a PR or I guess: send it to Clark and the guys from Alibaba.

A

What do you guys think, good and and I put it in the chat window.

I

Yeah, so one comma is Clark. So what's your plan to Upstream this one to the Sonic Community? Well, this is just keeping the dash I. Think that's one question you can I mean it's not uh you.

A

Can talk about that um next time, then I'll write that as a note in down um submit why don't we carve out you guys 20 minutes, 30 minutes from the next session. Is that, okay, with you, um Clark and Eddie yeah,.

A

Okay, but thank you guys for this enormous contribution. It's amazing and a lot of work, I appreciate it a lot. I'm gonna go ahead and stop the recording and I'll post it to the channel and um hope you all have a.