Hi Li, I would suggest looking into session logic implementation of NAT44-ED and also into ACLs in VPP. The way to go would be to create a plugin that has late limiting nodes. Now you have two options on how to rate limit:
1) based on interface(s) - the more straightforward and easy to implement solution. - enable nodes with vnet_feature_enable_disable on specific interfaces - hold a hash / pool that defines interface / interface combination that should be rate limited - hold counters - consider how to effectively share values between threads (atomic operations etc.) 2) based on network(s) - the same enable nodes as mentioned in 1) - now decide if the precedence is interface or ACL, or just use two different types of rate limiting that shouldn't be used together - use VPP ACL implementation to create rules that need to be checked - again some pool that holds the data and ACL / hash returns an index to the pool with the data. As rate limiting rules are configuration options and not sessions like in nat you wouldn't need to have per thread data. Creating hash records or whatever you decide to use would be done only through API/CLI which are thread safe operations. Then just stick with atomics on the values. The last part is for you to decide / implement some type of algo that decides if the packet should be passed or dropped. This can be a little bit tricky because of the VPPs batch processing or in other words how the vector of packets is processed instead of per packet. I would really advise you not to try to extend NAT with this functionality. Separate plugin is a better solution. I could look into this in my free time - if I have enough of it. Feel free to pass any notes / ideas. Best regards, Filip Varga po 31. 10. 2022 o 16:56 lihuawei <lihuawei_...@163.com> napísal(a): > Hi Filip & community, > > About the rate limiting with NAT session, does anyone have recommended > reference? > > Best regards, > Huawei LI > > 2022年10月29日 04:14，filvarga <filipvarg...@gmail.com> 写道： > > Hi, Li > > There is no such goal. It would’t be good idea to put rate limiting > directly into NAT. For many good reasons. > > Much better solution would be to implement a new rate limiting plugin. > > If you need such a functionality feel free to contribute. > > Best regards > > On Fri, 28 Oct 2022 at 18:35, lihuawei <lihuawei_...@163.com> wrote: > >> Hi Filip, >> >> Yes, it’s "session rate limiting" what I mean. >> >> Does community have any plan about "session rate limiting" in the >> classical flavours of nat? >> >> >> Thanks & Regards, >> Huawei LI >> >> 2022年10月28日 21:20，filvarga <filipvarg...@gmail.com> 写道： >> >> Hi Li, >> >> What exactly do you mean by "new nat session rate limit" ? There is no >> session rate limiting in the classical flavours of nat >> (nat44-ed,nat44-ei,det44,nat64,nat66) >> >> Best regards, >> Filip Varga >> >> >> pi 28. 10. 2022 o 3:09 lihuawei <lihuawei_...@163.com> napísal(a): >> >>> Hi Filip, >>> >>> Thanks very much for your detailed instructions and configuration >>> examples. I will try this method later on. >>> >>> Another question about nat, is there any support for new nat session >>> rate limit in vpp? >>> >>> >>> Thanks & Regards, >>> Huawei LI >>> >>> 2022年10月28日 01:22，filvarga <filipvarg...@gmail.com> 写道： >>> >>> Hi Li, >>> >>> NAT44-ED doesn't support ACL. There are other NAT plugins in VPP. For >>> example PNAT uses ACL rules. You should go through all of the options there >>> are and pick the correct NAT flavor that will suffice. >>> >>> Well your option is to do following: >>> >>> 1) >>> >>> # lan1 interface belongs to vrf1 >>> # lan2 interface belongs to vrf2 >>> # wan0 interface belongs to default fib 0 >>> >>> set interface nat44 in lan1 >>> set interface nat44 in lan2 >>> set interface nat44 out wan0 >>> >>> nat44 add address <...address..> tenant-vrf 1 >>> nat44 add address <...address..> tenant-vrf 2 >>> >>> 2) >>> >>> # lan1 and wan0 interfaces belong to default fib 0 >>> # lan2 interface belongs to vrf1 >>> >>> --||-- >>> >>> nat44 add address <...address...> >>> nat44 add address <...address..> tenant-vrf 1 >>> >>> This is how you simply force the inside interface to use a specific NAT >>> pool address. >>> >>> Best regards, >>> Filip Varga >>> >>> >>> št 27. 10. 2022 o 18:58 lihuawei <lihuawei_...@163.com> napísal(a): >>> >>>> Hi Filip, >>>> >>>> I have searched your mail accounts, and didn’t find any acl >>>> configuration used with nat44. Do you mean use acl with nat44 address to >>>> achive to my target creating nat sessions based packet’s source ip's >>>> network? >>>> >>>> How about multi nat addresses respectively used for multi-subnets in a >>>> vrf? >>>> >>>> Thanks & Regards, >>>> Huawei LI >>>> >>>> 2022年10月27日 22:06，filvarga <filipvarg...@gmail.com> 写道： >>>> >>>> Hi Li, >>>> >>>> Yes, try to search one of my mail accounts (current/previous) for >>>> example fiva...@cisco.com, filipvarg...@gmail.com or my name. >>>> If you are looking for a feature that does ACL matching based on source >>>> address you should try to look in different implementations of nat44, there >>>> are more then one in vpp (one even supports acl matching). >>>> >>>> Yes, the support for matching based on source subnet is not part of >>>> nat44-ed and It would greatly change the current state for it. I wouldn't >>>> suggest doing such a radical change. You can ofc. use as I mentioned >>>> previously VRF logic. The only thing you need is 1 extra vrf to put one of >>>> the inside interfaces into in conjunction with nat44 add address ... >>>> tenant-vrf <inside-vrf>. >>>> >>>> Regarding your problem with the bridge in VPP. You can go about using a >>>> bridge in linux and connecting both interfaces in VPP to it. You would even >>>> be able to have both VPP interfaces in the same subnet. >>>> >>>> Best regards, >>>> Filip Varga >>>> >>>> >>>> št 27. 10. 2022 o 15:04 lihuawei <lihuawei_...@163.com> napísal(a): >>>> >>>>> Hi Filip, >>>>> >>>>> Sorry, I didn’t state the demands clearly. My demand is to let a nat >>>>> ip address just only work for specific src network prefix in a vpc, the >>>>> nat >>>>> sessions using the nat ip address will be created only when the i2o >>>>> packets’s src ip matches the specific network prefix in the vpc. >>>>> 1) I saw the snat_address_t’s member net is used only for matching the >>>>> packets’s dst ip in nat_ed_alloc_addr_and_port. >>>>> 2) using multiple vrfs to isolate the network is a method, but will >>>>> use more other configures, and makes the traffic model more complex. >>>>> >>>>> By view the codes about nat44-ed, I don’t think there is any >>>>> configuration examples about the demand I mentioned above. Do you have any >>>>> keywords about the configuration examples? I want to try a search in >>>>> mailing list with them. >>>>> >>>>> Do I understand this right? Looking forward to hearing any further >>>>> ideas or suggestions from you. >>>>> >>>>> Thanks & Regards, >>>>> Huawei LI >>>>> >>>>> 2022年10月27日 16:52，filvarga <filipvarg...@gmail.com> 写道： >>>>> >>>>> Hi Li, >>>>> >>>>> There are few errors in your statement. >>>>> >>>>> 1) SNAT - is an obsolete name for the old nat plugin. >>>>> 2) NAT is split among multiple plugins >>>>> 3) one of the plugins - nat44-ed (the most used and preferred) does >>>>> support all of the things you have mentioned >>>>> >>>>> Please feel free to search in the community mailing list for >>>>> configuration examples. There is also .rst file in the nat44-ed plugin >>>>> directory (may not contain all of the supported configuration). Also check >>>>> the api.c and cli.c for all available configuration options. >>>>> >>>>> After you have done above mentioned feel free to ask regarding >>>>> specific configuration issue. >>>>> >>>>> Best regards, >>>>> Filip Varga >>>>> >>>>> >>>>> pi 21. 10. 2022 o 4:01 lihuawei <lihuawei_...@163.com> napísal(a): >>>>> >>>>>> Hi John & Everyone & Community, >>>>>> >>>>>> In my scene, it is the demand to put multiple subnets in one BD. A >>>>>> few days ago, I have found the other proper idea to implement the demand >>>>>> mentioned >>>>>> in the mail subject and original mail. >>>>>> >>>>>> This problem and mail can be close now. >>>>>> >>>>>> Have a nice day, everybody! >>>>>> >>>>>> >>>>>> Thanks & Regards, >>>>>> Huawei LI >>>>>> >>>>>> 2022年10月21日 00:45，John Lo <lojultra2...@outlook.com> 写道： >>>>>> >>>>>> Hi Huawei, >>>>>> >>>>>> Some comments on supporting multiple BVIs in a BD: >>>>>> >>>>>> 1. There are assumptions in the bridging code including only 1 BVI >>>>>> per BD and it will be the last interface of a BD's flood list. To >>>>>> support >>>>>> multiple BVIs per BD will make the code more complicated and less >>>>>> efficient >>>>>> from performance point of view. >>>>>> >>>>>> 2. All interfaces, including BVI, in a BD can talk to each other via >>>>>> MAC address learning. There is no concept of L3 IP address nor awareness >>>>>> of IPs in separate VRFs. Thus, the concept of multiple BVIs in a BD each >>>>>> in >>>>>> different VRFs does not match the L2 bridging concept. While it may be >>>>>> possible to enhance BD support to understand IP and VRF at L3, it will >>>>>> again make the code more complicated and affect performance. >>>>>> >>>>>> My question would be, isn't it more natural to put each subnet in a >>>>>> separate BD with its BVI in the desired VRF? >>>>>> >>>>>> Regards, >>>>>> John >>>>>> >>>>>> -----Original Message----- >>>>>> From: lihuawei <lihuawei_...@163.com> >>>>>> Sent: Sunday, October 16, 2022 11:30 PM >>>>>> To: o...@cisco.com; fiva...@cisco.com; klement.sek...@gmail.com; Neale >>>>>> Ranns <ne...@graphiant.com>; lojultra2...@outlook.com; >>>>>> slu...@cisco.com; vpp-dev@lists.fd.io >>>>>> Subject: snat support bind to specific subnets >>>>>> >>>>>> Hi Ole, Filip, Klement, Neale, John, Steven, &Community, >>>>>> >>>>>> I have a demand about snat. With in a vpc, different subnets need >>>>>> use different snat ip to the internet, but the vpp snat feature now do >>>>>> not >>>>>> support snat ip bind to specific subnets. I have two ideas to resolve >>>>>> this: >>>>>> 1. modify and develop snat feature to support snat ip bind to >>>>>> specific subnets. >>>>>> 2. use multiple vrfs to isolate subnets, one vrf’s subnets use one >>>>>> snat ip, but the bd bvi now only support one in one bd, the non-bvi loop >>>>>> does not forward L3. So modify and develop bd bvi to support multiple bvi >>>>>> interfaces in one bd may be one better idea. >>>>>> >>>>>> Do I understand right and the idea 2 is the better? Anybody who has >>>>>> better idea, please help. >>>>>> >>>>>> Thanks and Regards, >>>>>> Huawei LI >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>> >> >> >> >> >> -- > Best regards, > Filip Varga > > > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#22108): https://lists.fd.io/g/vpp-dev/message/22108 Mute This Topic: https://lists.fd.io/mt/94377538/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
