Re: [vpp-dev] NAT ED empty users dump #nat #nat44
Ole, OK, nat44_user_dump is not going to return anything in NAT ED. nat44_user_session_dump has required fields ( ip_address and vrf_id) that don't allow you to dump all the sessions. If make those fields optional, that should work. Addition of sort and limit optional fields is a good idea and might be helpful. Thanks, Alexander -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16356): https://lists.fd.io/g/vpp-dev/message/16356 Mute This Topic: https://lists.fd.io/mt/74156168/21656 Mute #nat44: https://lists.fd.io/mk?hashtag=nat44=1480452 Mute #nat: https://lists.fd.io/mk?hashtag=nat=1480452 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] NAT ED empty users dump #nat #nat44
Hi Alexander, Let me try to restart. ;-) nat44_user_dump gives you a list of inside ip addresses that have sessions. That makes sense when you track sessions by inside ip address (user). E.g. in a traditional NAT where in endpoint independent mode you use up an outside port per-session and you need to limit the number of sessions created by a single inside ip address. Endpoint dependent NAT with port overloading removes that limitation. An outside port can be reused as many times as you like for different DA/DP pairs. Maintaining the per-user list has a cost so I didn't want to do that for NAT ED. Now, nat44_user_session_dump lists the sessions for a given inside IP address. That you could do although it would require you to iterate the whole session database. My suggestion was that since the IP address is just a filter in this case, we could other things into the filter too. Up to the complete 5/6-tuple of a session. Or dump sessions that are in TCP transitory state, 100 most recently used sessions, whatever... For session table utilisation you should use the stat segment. Currently we have /nat44/total-sessions and you have error counters for other cases, e.g. port allocation fails. I'm looking at adding more counters for NAT to the stat segment. Input sought. Best regards, Ole > On 13 May 2020, at 09:02, Alexander Chernavin via lists.fd.io > wrote: > > Hello Ole, > > I'm not sure I get your question right. > > The use case is being able to see NAT pool utilization and debug NAT > sessions. I think it's not a specific use case. > > NAT44 ED sessions: > thread 0 vpp_main: 3 sessions > i2o 10.255.10.100 proto icmp port 1593 fib 0 > o2i 10.100.200.14 proto icmp port 16253 fib 0 >external host 10.255.30.100:0 >index 0 >last heard 27.67 >total pkts 8, total bytes 728 >dynamic translation > > i2o 10.255.10.100 proto udp port 45177 fib 0 > o2i 10.100.200.14 proto udp port 18995 fib 0 >external host 10.255.30.100:8161 >index 1 >last heard 32.66 >total pkts 2, total bytes 106 >dynamic translation > > i2o 10.255.10.100 proto tcp port 59664 fib 0 > o2i 10.100.200.14 proto tcp port 53893 fib 0 >external host 10.255.30.100:22 >index 2 >last heard 36.64 >total pkts 9, total bytes 635 >dynamic translation > > > The way I see it is that there was API that worked for ED and non ED NAT > modes (except for deterministic). ED mode logic has changed but API remains > the same. It still works for non ED NAT modes and has stopped working for ED > mode. I think it's not consistent. > > Thanks, > Alexander -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16354): https://lists.fd.io/g/vpp-dev/message/16354 Mute This Topic: https://lists.fd.io/mt/74156168/21656 Mute #nat44: https://lists.fd.io/mk?hashtag=nat44=1480452 Mute #nat: https://lists.fd.io/mk?hashtag=nat=1480452 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] NAT ED empty users dump #nat #nat44
Hello Ole, I'm not sure I get your question right. The use case is being able to see NAT pool utilization and debug NAT sessions. I think it's not a specific use case. NAT44 ED sessions: thread 0 vpp_main: 3 sessions i2o 10.255.10.100 proto icmp port 1593 fib 0 o2i 10.100.200.14 proto icmp port 16253 fib 0 external host 10.255.30.100:0 index 0 last heard 27.67 total pkts 8, total bytes 728 dynamic translation i2o 10.255.10.100 proto udp port 45177 fib 0 o2i 10.100.200.14 proto udp port 18995 fib 0 external host 10.255.30.100:8161 index 1 last heard 32.66 total pkts 2, total bytes 106 dynamic translation i2o 10.255.10.100 proto tcp port 59664 fib 0 o2i 10.100.200.14 proto tcp port 53893 fib 0 external host 10.255.30.100:22 index 2 last heard 36.64 total pkts 9, total bytes 635 dynamic translation The way I see it is that there was API that worked for ED and non ED NAT modes (except for deterministic). ED mode logic has changed but API remains the same. It still works for non ED NAT modes and has stopped working for ED mode. I think it's not consistent. Thanks, Alexander -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16352): https://lists.fd.io/g/vpp-dev/message/16352 Mute This Topic: https://lists.fd.io/mt/74156168/21656 Mute #nat44: https://lists.fd.io/mk?hashtag=nat44=1480452 Mute #nat: https://lists.fd.io/mk?hashtag=nat=1480452 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] NAT ED empty users dump #nat #nat44
Alexander, Is your use case list all sessions matching x rather than list all sessions with sa==n? Cheers Ole > On 12 May 2020, at 16:28, Klement Sekera via lists.fd.io > wrote: > > ED NAT no longer has “user” concept and it doesn’t differentiate one session > from another. (So technically the API works just fine). Even if we wanted to > recreate that information it means to build a hash of “users” on the fly for > API purpose, do the dump and then throw it away. I don’t see any other way to > guarantee that there are no duplicates in the dump even if we didn’t care for > numbers like number of sessions or so… > > Thanks, > Klement > >> On 12 May 2020, at 15:56, Alexander Chernavin via lists.fd.io >> wrote: >> >> Klement, >> >> I would prefer the existing API working. >> >> I expect millions of sessions and it's clear that dumping them all is a >> blocker but during debug, there are not so many of them. >> >> Thanks, >> Alexander > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16346): https://lists.fd.io/g/vpp-dev/message/16346 Mute This Topic: https://lists.fd.io/mt/74156168/21656 Mute #nat44: https://lists.fd.io/mk?hashtag=nat44=1480452 Mute #nat: https://lists.fd.io/mk?hashtag=nat=1480452 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] NAT ED empty users dump #nat #nat44
ED NAT no longer has “user” concept and it doesn’t differentiate one session from another. (So technically the API works just fine). Even if we wanted to recreate that information it means to build a hash of “users” on the fly for API purpose, do the dump and then throw it away. I don’t see any other way to guarantee that there are no duplicates in the dump even if we didn’t care for numbers like number of sessions or so… Thanks, Klement > On 12 May 2020, at 15:56, Alexander Chernavin via lists.fd.io > wrote: > > Klement, > > I would prefer the existing API working. > > I expect millions of sessions and it's clear that dumping them all is a > blocker but during debug, there are not so many of them. > > Thanks, > Alexander -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16345): https://lists.fd.io/g/vpp-dev/message/16345 Mute This Topic: https://lists.fd.io/mt/74156168/21656 Mute #nat44: https://lists.fd.io/mk?hashtag=nat44=1480452 Mute #nat: https://lists.fd.io/mk?hashtag=nat=1480452 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] NAT ED empty users dump #nat #nat44
Klement, I would prefer the existing API working. I expect millions of sessions and it's clear that dumping them all is a blocker but during debug, there are not so many of them. Thanks, Alexander -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16342): https://lists.fd.io/g/vpp-dev/message/16342 Mute This Topic: https://lists.fd.io/mt/74156168/21656 Mute #nat44: https://lists.fd.io/mk?hashtag=nat44=1480452 Mute #nat: https://lists.fd.io/mk?hashtag=nat=1480452 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] NAT ED empty users dump #nat #nat44
Alexander, It seems that fixing existing API is a huge pain. What we could do is implement an API which dumps all the sessions and the client app could sort it out. How many sessions do you typically have? As by default APIs run in a stop-the-world state, having millions of sessions will stop all the forwarding until the dump is complete. Writing it in a thread-safe way is a more complicated effort… Thanks, Klement > On 12 May 2020, at 14:10, Alexander Chernavin via lists.fd.io > wrote: > > Klement, > > Basically print statistics and debug info: number of users, what user > consumes what number of sessions, what session created for what communication. > > Thanks, > Alexander -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16340): https://lists.fd.io/g/vpp-dev/message/16340 Mute This Topic: https://lists.fd.io/mt/74156168/21656 Mute #nat44: https://lists.fd.io/mk?hashtag=nat44=1480452 Mute #nat: https://lists.fd.io/mk?hashtag=nat=1480452 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] NAT ED empty users dump #nat #nat44
Klement, Basically print statistics and debug info: number of users, what user consumes what number of sessions, what session created for what communication. Thanks, Alexander -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16334): https://lists.fd.io/g/vpp-dev/message/16334 Mute This Topic: https://lists.fd.io/mt/74156168/21656 Mute #nat44: https://lists.fd.io/mk?hashtag=nat44=1480452 Mute #nat: https://lists.fd.io/mk?hashtag=nat=1480452 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] NAT ED empty users dump #nat #nat44
Hi Alexander, Understood. So when you get those sessions, what do you do with them? Thanks, Klement > On 12 May 2020, at 13:45, Alexander Chernavin via lists.fd.io > wrote: > > Hello Klement, > > I want to list all NAT sessions. In order to do that I used to call > VL_API_NAT44_USER_DUMP. After that, I had all users, and I could call > VL_API_NAT44_USER_SESSION_DUMP to get sessions for every user. > > Now VL_API_NAT44_USER_DUMP returns nothing in ED mode and I don't know what > users are. At the same time, VL_API_NAT44_USER_SESSION_DUMP requires > ip_address and vrf_id arguments. So if you don't know users, you cannot get > sessions. > > Thanks, > Alexander -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16332): https://lists.fd.io/g/vpp-dev/message/16332 Mute This Topic: https://lists.fd.io/mt/74156168/21656 Mute #nat44: https://lists.fd.io/mk?hashtag=nat44=1480452 Mute #nat: https://lists.fd.io/mk?hashtag=nat=1480452 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] NAT ED empty users dump #nat #nat44
Hello Klement, I want to list all NAT sessions. In order to do that I used to call VL_API_NAT44_USER_DUMP. After that, I had all users, and I could call VL_API_NAT44_USER_SESSION_DUMP to get sessions for every user. Now VL_API_NAT44_USER_DUMP returns nothing in ED mode and I don't know what users are. At the same time, VL_API_NAT44_USER_SESSION_DUMP requires ip_address and vrf_id arguments. So if you don't know users, you cannot get sessions. Thanks, Alexander -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16330): https://lists.fd.io/g/vpp-dev/message/16330 Mute This Topic: https://lists.fd.io/mt/74156168/21656 Mute #nat44: https://lists.fd.io/mk?hashtag=nat44=1480452 Mute #nat: https://lists.fd.io/mk?hashtag=nat=1480452 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] NAT ED empty users dump #nat #nat44
Hi Alexander, thanks for your feedback. The concept of user was really used for quickly re-using existing sessions in NAT. With port-overloading, ports are no longer a precious resource and dropping “users” means not having to maintain an extra hash table. To better understand your problem, can you please state your use case for dumping these sessions? Thanks, Klement > On 12 May 2020, at 13:18, Alexander Chernavin via lists.fd.io > wrote: > > Hello, > > As I understand the "users" concept has been removed from NAT ED and now > vl_api_nat44_user_dump_t returns nothing in ED mode. > vl_api_nat44_user_session_dump_t returns sessions only if you know the user > you are requesting sessions for. But you can't get the user list. Therefore > this chain no longer works: dump all users, then dump all sessions of those > users. > > I think the user dump code could build the user list based on the sessions, > but we need to collect these fields: IP address, VRF id, number of static and > dynamic sessions. For a big number of sessions it might be time-consuming > before the first user could be sent. Probably, maintaining a user list would > be cheaper. > > How do you think vl_api_nat44_user_dump_t can be fixed for NAT ED? > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16329): https://lists.fd.io/g/vpp-dev/message/16329 Mute This Topic: https://lists.fd.io/mt/74156168/21656 Mute #nat44: https://lists.fd.io/mk?hashtag=nat44=1480452 Mute #nat: https://lists.fd.io/mk?hashtag=nat=1480452 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] NAT ED empty users dump #nat #nat44
Hello, As I understand the "users" concept has been removed from NAT ED and now vl_api_nat44_user_dump_t returns nothing in ED mode. vl_api_nat44_user_session_dump_t returns sessions only if you know the user you are requesting sessions for. But you can't get the user list. Therefore this chain no longer works: dump all users, then dump all sessions of those users. I think the user dump code could build the user list based on the sessions, but we need to collect these fields: IP address, VRF id, number of static and dynamic sessions. For a big number of sessions it might be time-consuming before the first user could be sent. Probably, maintaining a user list would be cheaper. How do you think vl_api_nat44_user_dump_t can be fixed for NAT ED? -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16327): https://lists.fd.io/g/vpp-dev/message/16327 Mute This Topic: https://lists.fd.io/mt/74156168/21656 Mute #nat: https://lists.fd.io/mk?hashtag=nat=1480452 Mute #nat44: https://lists.fd.io/mk?hashtag=nat44=1480452 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
