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 >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>> >>> >>> >> >> >> >> >> > > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#22090): https://lists.fd.io/g/vpp-dev/message/22090 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] -=-=-=-=-=-=-=-=-=-=-=-
