** Description changed:
- [Impact]
+ [Impact]
A change included ipset 6.37 as a performance regression as all ip set rule
incur a getprotocolbyname lookup, irrespective of whether the name of the
protocol or the actual port number is specified in the set configuration. For
large sets this can double the speed of applying changes to ipset tables.
[Test Plan]
-
- * detailed instructions how to reproduce the bug
-
- * these should allow someone who is not familiar with the affected
- package to reproduce the bug and verify that the updated package fixes
- the problem.
-
- * if other testing is appropriate to perform before landing this update,
- this should also be described here.
+ sudo ipset destroy test
+ sudo ipset create test hash:net,port,net hashsize 4096 maxelem 786432
+ for y in `seq 1 7`; do for x in `seq 1 254`; do for i in `seq 1 254`; do echo
"add test 10.1.1.0/21,80,150.$y.$x.$i/32" >> whitelist-ipv4 ;done; done; done
+ time sudo ipset restore < ./whitelist-ipv4
[Where problems could occur]
The original patch to resolve this issue did introduce another bug which as
subsequently been fixed as well (and is included in the updated packages).
If the fix introduces issues its likely that iptable rules making use of
ipset groups will start to fail in some way - probably rejecting traffic
or suchlike.
[Other Info]
-
[Original Bug Report]
Hi,
Do you think we could get
https://git.netfilter.org/ipset/commit/?id=dbeb20a667e82e4efb8b26b24a0ec641dab5c857
SRUed to 20.04 ?
This divides our ipset loading time by ~2 (from ~60s to ~25s).
Thanks
** Changed in: ipset (Ubuntu Impish)
Importance: Undecided => High
** Changed in: ipset (Ubuntu Hirsute)
Importance: Undecided => High
** Changed in: ipset (Ubuntu Focal)
Importance: Undecided => High
** Changed in: ipset (Ubuntu Focal)
Assignee: (unassigned) => James Page (james-page)
** Changed in: ipset (Ubuntu Hirsute)
Assignee: (unassigned) => James Page (james-page)
** Changed in: ipset (Ubuntu Impish)
Assignee: (unassigned) => James Page (james-page)
** Description changed:
[Impact]
A change included ipset 6.37 as a performance regression as all ip set rule
incur a getprotocolbyname lookup, irrespective of whether the name of the
protocol or the actual port number is specified in the set configuration. For
large sets this can double the speed of applying changes to ipset tables.
[Test Plan]
sudo ipset destroy test
sudo ipset create test hash:net,port,net hashsize 4096 maxelem 786432
- for y in `seq 1 7`; do for x in `seq 1 254`; do for i in `seq 1 254`; do echo
"add test 10.1.1.0/21,80,150.$y.$x.$i/32" >> whitelist-ipv4 ;done; done; done
- time sudo ipset restore < ./whitelist-ipv4
+ for x in `seq 1 7`; do for y in `seq 1 254`; do for z in `seq 1 254`; do echo
"add test 10.1.1.0/21,80,150.$x.$y.$z/32" >> whitelist-ipv4 ;done; done; done
+ time sudo ipset restore < ./whitelist-ipv4
[Where problems could occur]
The original patch to resolve this issue did introduce another bug which as
subsequently been fixed as well (and is included in the updated packages).
If the fix introduces issues its likely that iptable rules making use of
ipset groups will start to fail in some way - probably rejecting traffic
or suchlike.
[Other Info]
[Original Bug Report]
Hi,
Do you think we could get
https://git.netfilter.org/ipset/commit/?id=dbeb20a667e82e4efb8b26b24a0ec641dab5c857
SRUed to 20.04 ?
This divides our ipset loading time by ~2 (from ~60s to ~25s).
Thanks
** Description changed:
[Impact]
A change included ipset 6.37 as a performance regression as all ip set rule
incur a getprotocolbyname lookup, irrespective of whether the name of the
protocol or the actual port number is specified in the set configuration. For
large sets this can double the speed of applying changes to ipset tables.
[Test Plan]
+ # Create a suitable large set of data to restore to the ipset
+ for x in `seq 1 7`; do for y in `seq 1 254`; do for z in `seq 1 254`; do echo
"add test 10.1.1.0/21,80,150.$x.$y.$z/32" >> whitelist-ipv4 ;done; done; done
+
+ # Destroy,create, restore
sudo ipset destroy test
sudo ipset create test hash:net,port,net hashsize 4096 maxelem 786432
- for x in `seq 1 7`; do for y in `seq 1 254`; do for z in `seq 1 254`; do echo
"add test 10.1.1.0/21,80,150.$x.$y.$z/32" >> whitelist-ipv4 ;done; done; done
time sudo ipset restore < ./whitelist-ipv4
+
+ Large reduction in time taken to restore the ipset (32s-> 5s on an 8
+ core machine).
[Where problems could occur]
The original patch to resolve this issue did introduce another bug which as
subsequently been fixed as well (and is included in the updated packages).
If the fix introduces issues its likely that iptable rules making use of
ipset groups will start to fail in some way - probably rejecting traffic
or suchlike.
[Other Info]
[Original Bug Report]
Hi,
Do you think we could get
https://git.netfilter.org/ipset/commit/?id=dbeb20a667e82e4efb8b26b24a0ec641dab5c857
SRUed to 20.04 ?
This divides our ipset loading time by ~2 (from ~60s to ~25s).
Thanks
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1918936
Title:
ipset does NSS lookups even if ports are numeric
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ipset/+bug/1918936/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
