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]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to