Re: [vpp-dev] NAT44 UDP sessions are not clearing
Transitory means that the session has not been fully established. Transitory (wait-closed) means the session has been established and then closed and it’s in transitory timeout, after which it will move to transitory (closed). Sessions in this state are not eligible for freeing. Transitory (closed) means the session has been fully closed and timed out and it’s now ready to be freed when needed. > On 3 Jun 2020, at 07:42, Carlito Nueno wrote: > > Testing with 30 ip addresses (users) opening around 300 sessions each. > > When using vpp-20.01 + fixes by you and Filip (before the port overloading > patches), total sessions and total transitory sessions were much smaller > (around 15062). > > on vpp-20.05 with port overloading > > NAT44 pool addresses: > 130.44.9.8 > tenant VRF independent > 0 busy other ports > 32 busy udp ports > 63071 busy tcp ports > 1 busy icmp ports > NAT44 twice-nat pool addresses: > max translations: 400 > max translations per user: 500 > established tcp LRU min session timeout 7792 (now 352) > transitory tcp LRU min session timeout 294 (now 352) > udp LRU min session timeout 312 (now 352) > total timed out sessions: 119312 > total sessions: 128639 > total tcp sessions: 128607 > total tcp established sessions: 9300 > total tcp transitory sessions: 119307 > total tcp transitory (WAIT-CLOSED) sessions: 0 > total tcp transitory (CLOSED) sessions: 0 > total udp sessions: 32 > total icmp sessions: 0 > > On Tue, Jun 2, 2020 at 8:42 PM carlito nueno via > lists.fd.io wrote: > Hi Klement, > > Got it. > > Sorry one more question :) > > I did another test and I noticed that tcp transitory sessions increase > rapidly when I create new sessions from new internal ip address really fast > (without delay). for example: > tcp sessions are never stopped, so tcp transitory sessions should be 0 at all > times. > > from ip address 192.168.1.2 > > NAT44 pool addresses: > 130.44.9.8 > tenant VRF independent > 0 busy other ports > 36 busy udp ports > 7694 busy tcp ports > 0 busy icmp ports > NAT44 twice-nat pool addresses: > max translations: 400 > max translations per user: 500 > established tcp LRU min session timeout 7842 (now 402) > udp LRU min session timeout 670 (now 402) > total timed out sessions: 0 > total sessions: 1203 > total tcp sessions: 1200 > total tcp established sessions: 1200 > total tcp transitory sessions: 0 > total tcp transitory (WAIT-CLOSED) sessions: 0 > total tcp transitory (CLOSED) sessions: 0 > total udp sessions: 3 > total icmp sessions: 0 > > added 600 sessions from ip address 192.168.1.3 > > NAT44 pool addresses: > 130.44.9.8 > tenant VRF independent > 0 busy other ports > 36 busy udp ports > 9395 busy tcp ports > 0 busy icmp ports > NAT44 twice-nat pool addresses: > max translations: 400 > max translations per user: 500 > established tcp LRU min session timeout 7845 (now 405) > transitory tcp LRU min session timeout 644 (now 405) > udp LRU min session timeout 670 (now 405) > total timed out sessions: 0 > total sessions: 2904 > total tcp sessions: 2901 > total tcp established sessions: 1800 > total tcp transitory sessions: 1101 > total tcp transitory (WAIT-CLOSED) sessions: 0 > total tcp transitory (CLOSED) sessions: 0 > total udp sessions: 3 > total icmp sessions: 0 > > Thanks! > > On Tue, Jun 2, 2020 at 11:47 AM Klement Sekera -X (ksekera - PANTHEON TECH > SRO at Cisco) wrote: > Hi Carlito, > > For ED NAT it doesn’t, as ED NAT no longer has any “user” concept. The code > for different flavours of NAT needs to be split and polished anyway. Idea is > to have data/code/APIs separate where appropriate. > > Thanks, > Klement > > > On 2 Jun 2020, at 20:31, Carlito Nueno wrote: > > > > Hi Klement, > > > > Really appreciate the detailed explanation! That makes sense and I could > > see that behavior from my tests. > > > > Last question: does "max translations per user" matter any more because the > > concept of user doesn't exist with new NAT? > > max translations: 400 > > max translations per user: 500 > > > > From my tests, each ip address can form as many sessions as needed as long > > as the overall/total sessions stay under "max translations". > > > > Thanks! > > > > On Mon, Jun 1, 2020 at 12:47 AM Klement Sekera -X (ksekera - PANTHEON TECH > > SRO at Cisco) wrote: > > Hi, > > > > as you can see almost all of NAT sessions are timed out. NAT will > > automatically free and reuse them when needed again. > > > > this line: > > > udp LRU min session timeout 5175 (now 161589) > > hints whether immediate reuse is possible. Minimum session timeout in the > > LRU list for UDP sessions is 5175, while current vpp internal time is > > 161589. This means the first element in LRU list for UDP session is ready > > to be reaped. > > > > To avoid fluctuations in performance due to running periodic cleanup > > processes, NAT instead attempts to free one session anytime there is a > > request to
Re: [vpp-dev] NAT44 UDP sessions are not clearing
Testing with 30 ip addresses (users) opening around 300 sessions each. When using vpp-20.01 + fixes by you and Filip (before the port overloading patches), total sessions and total transitory sessions were much smaller (around 15062). on vpp-20.05 with port overloading NAT44 pool addresses: 130.44.9.8 tenant VRF independent 0 busy other ports 32 busy udp ports *63071* busy tcp ports 1 busy icmp ports NAT44 twice-nat pool addresses: max translations: 400 max translations per user: 500 established tcp LRU min session timeout 7792 (now 352) transitory tcp LRU min session timeout 294 (now 352) udp LRU min session timeout 312 (now 352) total timed out sessions: 119312 total sessions: *128639* total tcp sessions: 128607 total tcp established sessions: 9300 total tcp transitory sessions: *119307* total tcp transitory (WAIT-CLOSED) sessions: 0 total tcp transitory (CLOSED) sessions: 0 total udp sessions: 32 total icmp sessions: 0 On Tue, Jun 2, 2020 at 8:42 PM carlito nueno via lists.fd.io wrote: > Hi Klement, > > Got it. > > Sorry one more question :) > > I did another test and I noticed that tcp transitory sessions increase > rapidly when I create new sessions from new internal ip address really fast > (without delay). for example: > tcp sessions are never stopped, so tcp transitory sessions should be 0 at > all times. > > from ip address 192.168.1.2 > > NAT44 pool addresses: > 130.44.9.8 > tenant VRF independent > 0 busy other ports > 36 busy udp ports > 7694 busy tcp ports > 0 busy icmp ports > NAT44 twice-nat pool addresses: > max translations: 400 > max translations per user: 500 > established tcp LRU min session timeout 7842 (now 402) > udp LRU min session timeout 670 (now 402) > total timed out sessions: 0 > total sessions: 1203 > total tcp sessions: 1200 > total tcp established sessions: 1200 > total tcp transitory sessions: 0 > total tcp transitory (WAIT-CLOSED) sessions: 0 > total tcp transitory (CLOSED) sessions: 0 > total udp sessions: 3 > total icmp sessions: 0 > > *added 600 sessions *from ip address 192.168.1.3 > > NAT44 pool addresses: > 130.44.9.8 > tenant VRF independent > 0 busy other ports > 36 busy udp ports > 9395 busy tcp ports > 0 busy icmp ports > NAT44 twice-nat pool addresses: > max translations: 400 > max translations per user: 500 > established tcp LRU min session timeout 7845 (now 405) > transitory tcp LRU min session timeout 644 (now 405) > udp LRU min session timeout 670 (now 405) > total timed out sessions: 0 > total sessions: 2904 > total tcp sessions: 2901 > total tcp established sessions: 1800 > total tcp transitory sessions: *1101* > total tcp transitory (WAIT-CLOSED) sessions: 0 > total tcp transitory (CLOSED) sessions: 0 > total udp sessions: 3 > total icmp sessions: 0 > > Thanks! > > On Tue, Jun 2, 2020 at 11:47 AM Klement Sekera -X (ksekera - PANTHEON TECH > SRO at Cisco) wrote: > >> Hi Carlito, >> >> For ED NAT it doesn’t, as ED NAT no longer has any “user” concept. The >> code for different flavours of NAT needs to be split and polished anyway. >> Idea is to have data/code/APIs separate where appropriate. >> >> Thanks, >> Klement >> >> > On 2 Jun 2020, at 20:31, Carlito Nueno wrote: >> > >> > Hi Klement, >> > >> > Really appreciate the detailed explanation! That makes sense and I >> could see that behavior from my tests. >> > >> > Last question: does "max translations per user" matter any more because >> the concept of user doesn't exist with new NAT? >> > max translations: 400 >> > max translations per user: 500 >> > >> > From my tests, each ip address can form as many sessions as needed as >> long as the overall/total sessions stay under "max translations". >> > >> > Thanks! >> > >> > On Mon, Jun 1, 2020 at 12:47 AM Klement Sekera -X (ksekera - PANTHEON >> TECH SRO at Cisco) wrote: >> > Hi, >> > >> > as you can see almost all of NAT sessions are timed out. NAT will >> automatically free and reuse them when needed again. >> > >> > this line: >> > > udp LRU min session timeout 5175 (now 161589) >> > hints whether immediate reuse is possible. Minimum session timeout in >> the LRU list for UDP sessions is 5175, while current vpp internal time is >> 161589. This means the first element in LRU list for UDP session is ready >> to be reaped. >> > >> > To avoid fluctuations in performance due to running periodic cleanup >> processes, NAT instead attempts to free one session anytime there is a >> request to create a new session. This means that at low steady rate, >> maximum number of sessions will peak at some point. E.g. with UDP timeout >> of 30 seconds and 100 sessions/second, after 30 seconds there will be >> around 3000 sessions and new sessions will also start to force cleanups. >> This will then cause the total sessions to remain at around 3000. If you >> stop creating new traffic, all of these eventually time out (without >> spending any CPU on these timeouts). If again after some time you start >> traffic,
Re: [vpp-dev] NAT44 UDP sessions are not clearing
Hi Klement, Got it. Sorry one more question :) I did another test and I noticed that tcp transitory sessions increase rapidly when I create new sessions from new internal ip address really fast (without delay). for example: tcp sessions are never stopped, so tcp transitory sessions should be 0 at all times. from ip address 192.168.1.2 NAT44 pool addresses: 130.44.9.8 tenant VRF independent 0 busy other ports 36 busy udp ports 7694 busy tcp ports 0 busy icmp ports NAT44 twice-nat pool addresses: max translations: 400 max translations per user: 500 established tcp LRU min session timeout 7842 (now 402) udp LRU min session timeout 670 (now 402) total timed out sessions: 0 total sessions: 1203 total tcp sessions: 1200 total tcp established sessions: 1200 total tcp transitory sessions: 0 total tcp transitory (WAIT-CLOSED) sessions: 0 total tcp transitory (CLOSED) sessions: 0 total udp sessions: 3 total icmp sessions: 0 *added 600 sessions *from ip address 192.168.1.3 NAT44 pool addresses: 130.44.9.8 tenant VRF independent 0 busy other ports 36 busy udp ports 9395 busy tcp ports 0 busy icmp ports NAT44 twice-nat pool addresses: max translations: 400 max translations per user: 500 established tcp LRU min session timeout 7845 (now 405) transitory tcp LRU min session timeout 644 (now 405) udp LRU min session timeout 670 (now 405) total timed out sessions: 0 total sessions: 2904 total tcp sessions: 2901 total tcp established sessions: 1800 total tcp transitory sessions: *1101* total tcp transitory (WAIT-CLOSED) sessions: 0 total tcp transitory (CLOSED) sessions: 0 total udp sessions: 3 total icmp sessions: 0 Thanks! On Tue, Jun 2, 2020 at 11:47 AM Klement Sekera -X (ksekera - PANTHEON TECH SRO at Cisco) wrote: > Hi Carlito, > > For ED NAT it doesn’t, as ED NAT no longer has any “user” concept. The > code for different flavours of NAT needs to be split and polished anyway. > Idea is to have data/code/APIs separate where appropriate. > > Thanks, > Klement > > > On 2 Jun 2020, at 20:31, Carlito Nueno wrote: > > > > Hi Klement, > > > > Really appreciate the detailed explanation! That makes sense and I could > see that behavior from my tests. > > > > Last question: does "max translations per user" matter any more because > the concept of user doesn't exist with new NAT? > > max translations: 400 > > max translations per user: 500 > > > > From my tests, each ip address can form as many sessions as needed as > long as the overall/total sessions stay under "max translations". > > > > Thanks! > > > > On Mon, Jun 1, 2020 at 12:47 AM Klement Sekera -X (ksekera - PANTHEON > TECH SRO at Cisco) wrote: > > Hi, > > > > as you can see almost all of NAT sessions are timed out. NAT will > automatically free and reuse them when needed again. > > > > this line: > > > udp LRU min session timeout 5175 (now 161589) > > hints whether immediate reuse is possible. Minimum session timeout in > the LRU list for UDP sessions is 5175, while current vpp internal time is > 161589. This means the first element in LRU list for UDP session is ready > to be reaped. > > > > To avoid fluctuations in performance due to running periodic cleanup > processes, NAT instead attempts to free one session anytime there is a > request to create a new session. This means that at low steady rate, > maximum number of sessions will peak at some point. E.g. with UDP timeout > of 30 seconds and 100 sessions/second, after 30 seconds there will be > around 3000 sessions and new sessions will also start to force cleanups. > This will then cause the total sessions to remain at around 3000. If you > stop creating new traffic, all of these eventually time out (without > spending any CPU on these timeouts). If again after some time you start > traffic, sessions will be freed and reused as required. > > > > Regards, > > Klement > > > > > On 31 May 2020, at 22:07, carlito nueno > wrote: > > > > > > Hi all, > > > > > > I am using vpp v20.05 and running NAT44 in end-point dependent mode. > > > > > > To test NAT, I created 50k tcp and udp sessions and ran packets for 5 > mins. Then I stopped the test. > > > > > > As soon as the test is stopped, tcp established sessions is 0, tcp > transitory sessions increase and all of the tcp sessions become 0 after > about 7440 seconds. > > > But UDP sessions are still "open", as the count is still high even > after 24 hours. As you can see below, udp LRU session timeout is around > 161589 and total udp sessions is around 29k > > > > > > Any advice? Let me know if I am missing anything. > > > > > > NAT44 pool addresses: > > > 130.44.9.8 > > > tenant VRF independent > > > 0 busy other ports > > > 29058 busy udp ports > > > 0 busy tcp ports > > > 0 busy icmp ports > > > NAT44 twice-nat pool addresses: > > > max translations: 400 > > > max translations per user: 1000 > > > udp LRU min session timeout 5175 (now 161589) > > > total timed out sessions: 29025 > > > total sessions: 29058 > > >
Re: [vpp-dev] NAT44 UDP sessions are not clearing
Hi Carlito, For ED NAT it doesn’t, as ED NAT no longer has any “user” concept. The code for different flavours of NAT needs to be split and polished anyway. Idea is to have data/code/APIs separate where appropriate. Thanks, Klement > On 2 Jun 2020, at 20:31, Carlito Nueno wrote: > > Hi Klement, > > Really appreciate the detailed explanation! That makes sense and I could see > that behavior from my tests. > > Last question: does "max translations per user" matter any more because the > concept of user doesn't exist with new NAT? > max translations: 400 > max translations per user: 500 > > From my tests, each ip address can form as many sessions as needed as long as > the overall/total sessions stay under "max translations". > > Thanks! > > On Mon, Jun 1, 2020 at 12:47 AM Klement Sekera -X (ksekera - PANTHEON TECH > SRO at Cisco) wrote: > Hi, > > as you can see almost all of NAT sessions are timed out. NAT will > automatically free and reuse them when needed again. > > this line: > > udp LRU min session timeout 5175 (now 161589) > hints whether immediate reuse is possible. Minimum session timeout in the LRU > list for UDP sessions is 5175, while current vpp internal time is 161589. > This means the first element in LRU list for UDP session is ready to be > reaped. > > To avoid fluctuations in performance due to running periodic cleanup > processes, NAT instead attempts to free one session anytime there is a > request to create a new session. This means that at low steady rate, maximum > number of sessions will peak at some point. E.g. with UDP timeout of 30 > seconds and 100 sessions/second, after 30 seconds there will be around 3000 > sessions and new sessions will also start to force cleanups. This will then > cause the total sessions to remain at around 3000. If you stop creating new > traffic, all of these eventually time out (without spending any CPU on these > timeouts). If again after some time you start traffic, sessions will be freed > and reused as required. > > Regards, > Klement > > > On 31 May 2020, at 22:07, carlito nueno wrote: > > > > Hi all, > > > > I am using vpp v20.05 and running NAT44 in end-point dependent mode. > > > > To test NAT, I created 50k tcp and udp sessions and ran packets for 5 mins. > > Then I stopped the test. > > > > As soon as the test is stopped, tcp established sessions is 0, tcp > > transitory sessions increase and all of the tcp sessions become 0 after > > about 7440 seconds. > > But UDP sessions are still "open", as the count is still high even after 24 > > hours. As you can see below, udp LRU session timeout is around 161589 and > > total udp sessions is around 29k > > > > Any advice? Let me know if I am missing anything. > > > > NAT44 pool addresses: > > 130.44.9.8 > > tenant VRF independent > > 0 busy other ports > > 29058 busy udp ports > > 0 busy tcp ports > > 0 busy icmp ports > > NAT44 twice-nat pool addresses: > > max translations: 400 > > max translations per user: 1000 > > udp LRU min session timeout 5175 (now 161589) > > total timed out sessions: 29025 > > total sessions: 29058 > > total tcp sessions: 0 > > total tcp established sessions: 0 > > total tcp transitory sessions: 0 > > total tcp transitory (WAIT-CLOSED) sessions: 0 > > total tcp transitory (CLOSED) sessions: 0 > > total udp sessions: 29058 > > total icmp sessions: 0 > > > > Thanks! > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16623): https://lists.fd.io/g/vpp-dev/message/16623 Mute This Topic: https://lists.fd.io/mt/74589316/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] NAT44 UDP sessions are not clearing
Hi Klement, Really appreciate the detailed explanation! That makes sense and I could see that behavior from my tests. Last question: does "max translations per user" matter any more because the concept of user doesn't exist with new NAT? max translations: 400 max translations per user: 500 >From my tests, each ip address can form as many sessions as needed as long as the overall/total sessions stay under "max translations". Thanks! On Mon, Jun 1, 2020 at 12:47 AM Klement Sekera -X (ksekera - PANTHEON TECH SRO at Cisco) wrote: > Hi, > > as you can see almost all of NAT sessions are timed out. NAT will > automatically free and reuse them when needed again. > > this line: > > udp LRU min session timeout 5175 (now 161589) > hints whether immediate reuse is possible. Minimum session timeout in the > LRU list for UDP sessions is 5175, while current vpp internal time is > 161589. This means the first element in LRU list for UDP session is ready > to be reaped. > > To avoid fluctuations in performance due to running periodic cleanup > processes, NAT instead attempts to free one session anytime there is a > request to create a new session. This means that at low steady rate, > maximum number of sessions will peak at some point. E.g. with UDP timeout > of 30 seconds and 100 sessions/second, after 30 seconds there will be > around 3000 sessions and new sessions will also start to force cleanups. > This will then cause the total sessions to remain at around 3000. If you > stop creating new traffic, all of these eventually time out (without > spending any CPU on these timeouts). If again after some time you start > traffic, sessions will be freed and reused as required. > > Regards, > Klement > > > On 31 May 2020, at 22:07, carlito nueno wrote: > > > > Hi all, > > > > I am using vpp v20.05 and running NAT44 in end-point dependent mode. > > > > To test NAT, I created 50k tcp and udp sessions and ran packets for 5 > mins. Then I stopped the test. > > > > As soon as the test is stopped, tcp established sessions is 0, tcp > transitory sessions increase and all of the tcp sessions become 0 after > about 7440 seconds. > > But UDP sessions are still "open", as the count is still high even after > 24 hours. As you can see below, udp LRU session timeout is around 161589 > and total udp sessions is around 29k > > > > Any advice? Let me know if I am missing anything. > > > > NAT44 pool addresses: > > 130.44.9.8 > > tenant VRF independent > > 0 busy other ports > > 29058 busy udp ports > > 0 busy tcp ports > > 0 busy icmp ports > > NAT44 twice-nat pool addresses: > > max translations: 400 > > max translations per user: 1000 > > udp LRU min session timeout 5175 (now 161589) > > total timed out sessions: 29025 > > total sessions: 29058 > > total tcp sessions: 0 > > total tcp established sessions: 0 > > total tcp transitory sessions: 0 > > total tcp transitory (WAIT-CLOSED) sessions: 0 > > total tcp transitory (CLOSED) sessions: 0 > > total udp sessions: 29058 > > total icmp sessions: 0 > > > > Thanks! > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16622): https://lists.fd.io/g/vpp-dev/message/16622 Mute This Topic: https://lists.fd.io/mt/74589316/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] NAT44 UDP sessions are not clearing
Hi, as you can see almost all of NAT sessions are timed out. NAT will automatically free and reuse them when needed again. this line: > udp LRU min session timeout 5175 (now 161589) hints whether immediate reuse is possible. Minimum session timeout in the LRU list for UDP sessions is 5175, while current vpp internal time is 161589. This means the first element in LRU list for UDP session is ready to be reaped. To avoid fluctuations in performance due to running periodic cleanup processes, NAT instead attempts to free one session anytime there is a request to create a new session. This means that at low steady rate, maximum number of sessions will peak at some point. E.g. with UDP timeout of 30 seconds and 100 sessions/second, after 30 seconds there will be around 3000 sessions and new sessions will also start to force cleanups. This will then cause the total sessions to remain at around 3000. If you stop creating new traffic, all of these eventually time out (without spending any CPU on these timeouts). If again after some time you start traffic, sessions will be freed and reused as required. Regards, Klement > On 31 May 2020, at 22:07, carlito nueno wrote: > > Hi all, > > I am using vpp v20.05 and running NAT44 in end-point dependent mode. > > To test NAT, I created 50k tcp and udp sessions and ran packets for 5 mins. > Then I stopped the test. > > As soon as the test is stopped, tcp established sessions is 0, tcp transitory > sessions increase and all of the tcp sessions become 0 after about 7440 > seconds. > But UDP sessions are still "open", as the count is still high even after 24 > hours. As you can see below, udp LRU session timeout is around 161589 and > total udp sessions is around 29k > > Any advice? Let me know if I am missing anything. > > NAT44 pool addresses: > 130.44.9.8 > tenant VRF independent > 0 busy other ports > 29058 busy udp ports > 0 busy tcp ports > 0 busy icmp ports > NAT44 twice-nat pool addresses: > max translations: 400 > max translations per user: 1000 > udp LRU min session timeout 5175 (now 161589) > total timed out sessions: 29025 > total sessions: 29058 > total tcp sessions: 0 > total tcp established sessions: 0 > total tcp transitory sessions: 0 > total tcp transitory (WAIT-CLOSED) sessions: 0 > total tcp transitory (CLOSED) sessions: 0 > total udp sessions: 29058 > total icmp sessions: 0 > > Thanks! > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16593): https://lists.fd.io/g/vpp-dev/message/16593 Mute This Topic: https://lists.fd.io/mt/74589316/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] NAT44 UDP sessions are not clearing
Hi all, I am using vpp v20.05 and running NAT44 in end-point dependent mode. To test NAT, I created 50k tcp and udp sessions and ran packets for 5 mins. Then I stopped the test. As soon as the test is stopped, tcp established sessions is 0, tcp transitory sessions increase and all of the tcp sessions become 0 after about 7440 seconds. But UDP sessions are still "open", as the count is still high even after 24 hours. *As you can see below, udp LRU session timeout is around 161589 and total udp sessions is around 29k* Any advice? Let me know if I am missing anything. NAT44 pool addresses: 130.44.9.8 tenant VRF independent 0 busy other ports 29058 busy udp ports 0 busy tcp ports 0 busy icmp ports NAT44 twice-nat pool addresses: max translations: 400 max translations per user: 1000 udp LRU min session timeout 5175 (now 161589) total timed out sessions: 29025 total sessions: 29058 total tcp sessions: 0 total tcp established sessions: 0 total tcp transitory sessions: 0 total tcp transitory (WAIT-CLOSED) sessions: 0 total tcp transitory (CLOSED) sessions: 0 total udp sessions: 29058 total icmp sessions: 0 Thanks! -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16588): https://lists.fd.io/g/vpp-dev/message/16588 Mute This Topic: https://lists.fd.io/mt/74589316/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
