Re: [vpp-dev] snat support bind to specific subnets

[lihuawei]

Hi Filip,

how about using token bucket to create a feature that has late limiting nodes?

Best regards,
Huawei LI

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

Re: [vpp-dev] snat support bind to specific subnets

[lihuawei]

Hi Filip,

Thanks for your suggestion, I will take into account all these.

Best regards,
Huawei LI

> 2022年11月1日 01:26，filvarga  写道：
> 
> 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  > 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 > > 写道：
>> 
>> 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 > > 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 >> > 写道：
>>> 
>>> 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 >> > 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 >>> > 写道：
 
 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 >>> > 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 

Re: [vpp-dev] snat support bind to specific subnets

[filvarga]

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  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  写道：
>
> 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  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  写道：
>>
>> 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  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  写道：
>>>
>>> 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  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  写道：

 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 

Re: [vpp-dev] snat support bind to specific subnets

[lihuawei]

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  写道：
> 
> 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  > 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 > > 写道：
>> 
>> 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 > > 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 >> > 写道：
>>> 
>>> 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 >> > 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 >>> > 写道：
 
 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 . 
 
 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 >>> > 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 
 

Re: [vpp-dev] snat support bind to specific subnets

[filvarga]

Hi Li,

Glad to help.

Best regards,

Filip

On Mon, 31 Oct 2022 at 16:52, lihuawei  wrote:

> 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  写道：
>
> 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  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  写道：
>>
>> 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 .
>>
>> 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  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  写道：
>>>
>>> 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  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 

Re: [vpp-dev] snat support bind to specific subnets

[lihuawei]

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  写道：
> 
> 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  > 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 > > 写道：
>> 
>> 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 
>> . 
>> 
>> 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 > > 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 >> > 写道：
>>> 
>>> 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 >> > napísal(a):
>>> Hi John & Everyone & 

Re: [vpp-dev] snat support bind to specific subnets

[filvarga]

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  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  写道：
>
> 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  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  写道：
>>
>> 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  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  写道：
>>>
>>> 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 .
>>>
>>> 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  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  写道：

 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 

Re: [vpp-dev] snat support bind to specific subnets

[lihuawei]

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  写道：
> 
> 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  > 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 > > 写道：
>> 
>> 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 > > 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 >> > 写道：
>>> 
>>> 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 . 
>>> 
>>> 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 >> > 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 >>> > 写道：
 
 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 
 

Re: [vpp-dev] snat support bind to specific subnets

[filvarga]

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  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  写道：
>
> 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  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  写道：
>>
>> 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 .
>>
>> 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  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  写道：
>>>
>>> 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  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 

Re: [vpp-dev] snat support bind to specific subnets

[lihuawei]

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  写道：
> 
> 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  > 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 > > 写道：
>> 
>> 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 
>> . 
>> 
>> 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 > > 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 >> > 写道：
>>> 
>>> 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 >> > 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 

Re: [vpp-dev] snat support bind to specific subnets

[filvarga]

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  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  写道：
>
> 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 .
>
> 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  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  写道：
>>
>> 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  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  写道：
>>>
>>> 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 

Re: [vpp-dev] snat support bind to specific subnets

[lihuawei]

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  写道：
> 
> 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 
> . 
> 
> 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  > 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 > > 写道：
>> 
>> 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 > > 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 >> > 写道：
>>> 
>>> 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 mailto:lihuawei_...@163.com>> 
>>> Sent: Sunday, October 16, 2022 11:30 PM
>>> To: o...@cisco.com ; fiva...@cisco.com 
>>> ; klement.sek...@gmail.com 
>>> 

Re: [vpp-dev] snat support bind to specific subnets

[filvarga]

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 .

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  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  写道：
>
> 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  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  写道：
>>
>> 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 
>> Sent: Sunday, October 16, 2022 11:30 PM
>> To: o...@cisco.com; fiva...@cisco.com; klement.sek...@gmail.com; Neale
>> Ranns ; 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, ,
>>
>> 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 

Re: [vpp-dev] snat support bind to specific subnets

[lihuawei]

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  写道：
> 
> 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  > 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 > > 写道：
>> 
>> 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 mailto:lihuawei_...@163.com>> 
>> Sent: Sunday, October 16, 2022 11:30 PM
>> To: o...@cisco.com ; fiva...@cisco.com 
>> ; klement.sek...@gmail.com 
>> ; Neale Ranns > >; 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, ,
>> 
>> 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 (#22082): https://lists.fd.io/g/vpp-dev/message/22082
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]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] snat support bind to specific subnets

[filvarga]

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  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  写道：
>
> 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 
> Sent: Sunday, October 16, 2022 11:30 PM
> To: o...@cisco.com; fiva...@cisco.com; klement.sek...@gmail.com; Neale
> Ranns ; 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, ,
>
> 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 (#22079): https://lists.fd.io/g/vpp-dev/message/22079
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]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] snat support bind to specific subnets

[lihuawei]

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  写道：
> 
> 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  
> Sent: Sunday, October 16, 2022 11:30 PM
> To: o...@cisco.com; fiva...@cisco.com; klement.sek...@gmail.com; Neale Ranns 
> ; 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, ,
> 
> 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 (#22061): https://lists.fd.io/g/vpp-dev/message/22061
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]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] snat support bind to specific subnets

[lihuawei]

Hi Ole, Filip, Klement, Neale, John, Steven, ,

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