Hi Filip, Thanks for your suggestion, I will take into account all these.
Best regards, Huawei LI > 2022年11月1日 01:26，filvarga <filipvarg...@gmail.com> 写道： > > 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 > <mailto: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 >> <mailto: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 >> <mailto: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 >>> <mailto: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 >>> <mailto: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 >>>> <mailto: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 >>>> <mailto: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 >>>>> <mailto:filipvarg...@gmail.com>> 写道： >>>>> >>>>> Hi Li, >>>>> >>>>> Yes, try to search one of my mail accounts (current/previous) for example >>>>> fiva...@cisco.com <mailto:fiva...@cisco.com>, filipvarg...@gmail.com >>>>> <mailto: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 >>>>> <mailto: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 >>>>>> <mailto: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 >>>>>> <mailto: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 >>>>>>> <mailto: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 <mailto:lihuawei_...@163.com>> >>>>>>> Sent: Sunday, October 16, 2022 11:30 PM >>>>>>> To: o...@cisco.com <mailto:o...@cisco.com>; fiva...@cisco.com >>>>>>> <mailto:fiva...@cisco.com>; klement.sek...@gmail.com >>>>>>> <mailto:klement.sek...@gmail.com>; Neale Ranns <ne...@graphiant.com >>>>>>> <mailto:ne...@graphiant.com>>; lojultra2...@outlook.com >>>>>>> <mailto:lojultra2...@outlook.com>; slu...@cisco.com >>>>>>> <mailto:slu...@cisco.com>; vpp-dev@lists.fd.io >>>>>>> <mailto: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 (#22109): https://lists.fd.io/g/vpp-dev/message/22109 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] -=-=-=-=-=-=-=-=-=-=-=-
