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 > <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 (#22106): https://lists.fd.io/g/vpp-dev/message/22106 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] -=-=-=-=-=-=-=-=-=-=-=-