Hi Filip, I have tried to use extra vrf for routing the nat packets in my nat traffic scenario, it worked good, just caused a little bit of a problem and could be circumvented. I also tried the other way to add network prefix member in struct snat_address_t, it worked well too, and this method will simplify the traffic model and reduce vpp configuration in my scenario. I'll take it all into consideration, and chose the better one for me.
Best 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 > <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 >>> >>> >>> >>> >>> >>> >>> >> >> >> >> >> > > > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#22104): https://lists.fd.io/g/vpp-dev/message/22104 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] -=-=-=-=-=-=-=-=-=-=-=-
