# OneConnect source-mask explainer > Paste a one-connect profile for the full option audit with the man page's own semantics and defaults, or simulate a mask against real client IPs and watch the reuse groups form. The marquee demonstration: SNAT translates first, so a single SNAT address collapses every client into one reuse group no matter how narrow the mask. - Tool: https://ronutz.com/en/tools/f5-oneconnect-source-mask - Family: Networking --- # OneConnect source-mask explainer OneConnect keeps server-side connections alive and hands them to the next eligible request, and the whole word doing the work in that sentence is eligible. The source mask decides eligibility, and the man page states its two poles plainly: 0.0.0.0, the default, shares reused connections across all clients; a host mask shares only among connections from the same client IP. Everything between behaves like a subnet mask, grouping clients by the bits it keeps. Paste an `ltm profile one-connect` stanza and every option renders with the v17 reference's own semantics, defaults filled in explicitly rather than assumed: max-age 86400, max-reuse 1000, max-size 10000, limit-type none. The strict limit carries the manual's own warning, that idle connections will block new ones until they expire even when they could have been reused, a configuration the page itself calls not recommended outside special cases. share-pools gets its cross-virtual semantics; the idle-timeout-override option gets an honest flag for the man page's own quirk, declared as disabled or enabled but described as a number of seconds. The simulation is the marquee. Give it a mask, a list of client IPs, and optionally a SNAT address, and the reuse groups render. With the SNAT present you watch the ordering both K7208 and K5911 state do its work: translation happens first, the mask applies to the translated address, so a single SNAT address collapses every client into one reuse group no matter how narrow the mask. That collapse is the production surprise this tool exists to make visible before it happens to you. Two pieces of statistics honesty from F5's own lab article close the audit: max-size divides across TMM instances rather than forming one global pool, and the Current Idle counter includes every idle server-side connection whether or not the mask makes it eligible. Read `tmsh show` output with both in mind. Everything runs locally; nothing you paste leaves the page. ## Standards and references - [F5 TMSH Reference v17: ltm profile one-connect (grammar, every default, the 0.0.0.0 and host-mask semantics, all three limit-type behaviors including strict's own not-recommended warning, share-pools)](https://clouddocs.f5.com/cli/tmsh-reference/latest/modules/ltm/ltm_profile_one-connect.html) - the option table, defaults, and limit-type observations - [F5 K7208: Overview of the OneConnect profile (SNAT translation happens first; the source mask applies to the translated address)](https://my.f5.com/manage/s/article/K7208) - the SNAT-then-mask ordering observation - [F5 K5911 (states the same SNAT-before-mask ordering; the two articles corroborate each other)](https://my.f5.com/manage/s/article/K5911) - corroboration of the ordering - [F5 DevCentral: How OneConnect Profile's max-size works (the reuse pool divides per TMM; Current Idle counts every idle server-side connection, eligible or not)](https://community.f5.com/kb/technicalarticles/how-oneconnect-profiles-max-size-works/280848) - the per-TMM and statistics-honesty observations ## Related reading - [OneConnect: Reuse Is a Grouping Problem, and SNAT Rewrites the Groups](https://ronutz.com/en/learn/bigip-oneconnect-connection-reuse.md): OneConnect parks idle server-side connections and hands them to the next eligible request. The source mask defines eligible, from 0.0.0.0 sharing across all clients to a host mask keeping reuse per client. The catch both K articles state: SNAT translates first, the mask sees only the translated address, so one SNAT address means one group.