Traffic shaper, should I see my rules in 'ipfw -a list'?

[iMx]

So, followed a few of the FQ_Codel guides on here, I believe I had it working on an earlier 17.7 release - on the current, 17.7.7_1 I don't seem to be able to.

Something I'd just like to clarify, presumably I should see the Rules/ueues that I configure in the Traffic Shaper section, in 'ipfw -a list'?  I don't, if I should I can't for the life of me work out why.  ipfw rules below:

Code: [Select]

root@fw00:~ # ipfw -a list
00100       0          0 allow pfsync from any to any
00110       0          0 allow carp from any to any
00120       0          0 allow ip from any to any layer2 mac-type 0x0806,0x8035
00130       0          0 allow ip from any to any layer2 mac-type 0x888e,0x88c7
00140       0          0 allow ip from any to any layer2 mac-type 0x8863,0x8864
00150       0          0 deny ip from any to any layer2 not mac-type 0x0800,0x86dd
00200       0          0 skipto 60000 ip6 from ::1 to any
00201      44       9156 skipto 60000 ip4 from 127.0.0.0/8 to any
00202       0          0 skipto 60000 ip6 from any to ::1
00203       0          0 skipto 60000 ip4 from any to 127.0.0.0/8
01002      36       3560 skipto 60000 udp from any to 10.8.6.254 dst-port 53 keep-state
01002     117      13994 skipto 60000 ip from any to { 255.255.255.255 or 10.8.6.254 } in
01002     160      21192 skipto 60000 ip from { 255.255.255.255 or 10.8.6.254 } to any out
01002       0          0 skipto 60000 icmp from { 255.255.255.255 or 10.8.6.254 } to any out icmptypes 0
01002       0          0 skipto 60000 icmp from any to { 255.255.255.255 or 10.8.6.254 } in icmptypes 8
01003       0          0 skipto 60000 udp from any to 192.168.3.254 dst-port 53 keep-state
01003       0          0 skipto 60000 ip from any to { 255.255.255.255 or 192.168.3.254 } in
01003       0          0 skipto 60000 ip from { 255.255.255.255 or 192.168.3.254 } to any out
01003       0          0 skipto 60000 icmp from { 255.255.255.255 or 192.168.3.254 } to any out icmptypes 0
01003       0          0 skipto 60000 icmp from any to { 255.255.255.255 or 192.168.3.254 } in icmptypes 8
65535 9056022 8639833830 allow ip from any to any
I've follow the RickNY guide, below, multiple times, line for line, but I don't actually see any reduction in bufferbloat, nor in the downstream bandwidth (even if I set it to something stupidly low) suggesting something isn't matching.

https://forum.opnsense.org/index.php?topic=3758.0

Screenshot in the below post shows 'queue' rules in ipfw:

https://forum.opnsense.org/index.php?topic=4665.msg18072#msg18072

I don't seem to have these in my 'ipfw -a list' above, no matter what 'Rules' I configure in Firewall -> Traffic Shaper -> Settings -> Rules:

   

Code: [Select]

11 WAN ip 10.8.6.0/24 any DownQueue
21 WAN ip any 10.8.6.0/24 UpQueue

[iMx]

Just in case it makes any difference, I have 4 physical interfaces, all grouped into an LACP lagg, VLANs then over the top for WAN, LAN, etc.

I guess I'll spin up a VM and see on a basic setup if the ipfw rules are populated, as I believe they should be.

[iMx]

Seems to populate the correct ipfw rules in a VM, with basic interfaces, time to test LAGG/VLANs...

[iMx]

Removed a physical interface from the LAGG, patched the freed-up physical interface directly into the cable modem, reassigned the WAN interface, tried to enable traffic shaping.... still no rules!

Guess the next thing is to remove the LAGG completely from the box.

[iMx]

LAGG removed, all VLANs removed, everything on physical interfaces.  Delete all traffic shaping pipes/queues/rules, rebooted, added it back again...still no rules in 'ipfw -a list'

Time to give up for now....

[iMx]

So, fresh this morning, it looks like it borks due to the l2tp tunnel - it has an incorrect interface name:

Code: [Select]

root@fw00:~ # ipfw /usr/local/etc/ipfw.rules
Are you sure? [yn] y

Flushed all rules.
00100 allow pfsync from any to any
00110 allow carp from any to any
00120 allow ip from any to any layer2 mac-type 0x0806,0x8035
00130 allow ip from any to any layer2 mac-type 0x888e,0x88c7
00140 allow ip from any to any layer2 mac-type 0x8863,0x8864
00150 deny ip from any to any layer2 not mac-type 0x0800,0x86dd
00200 skipto 60000 ip6 from ::1 to any
00201 skipto 60000 ip4 from 127.0.0.0/8 to any
00202 skipto 60000 ip6 from any to ::1
00203 skipto 60000 ip4 from any to 127.0.0.0/8
01002 skipto 60000 udp from any to 10.8.6.254 dst-port 53 keep-state
01002 skipto 60000 ip from any to { 255.255.255.255 or 10.8.6.254 } in
01002 skipto 60000 ip from { 255.255.255.255 or 10.8.6.254 } to any out
01002 skipto 60000 icmp from { 255.255.255.255 or 10.8.6.254 } to any out icmptypes 0
01002 skipto 60000 icmp from any to { 255.255.255.255 or 10.8.6.254 } in icmptypes 8
01003 skipto 60000 udp from any to 192.168.3.254 dst-port 53 keep-state
01003 skipto 60000 ip from any to { 255.255.255.255 or 192.168.3.254 } in
01003 skipto 60000 ip from { 255.255.255.255 or 192.168.3.254 } to any out
01003 skipto 60000 icmp from { 255.255.255.255 or 192.168.3.254 } to any out icmptypes 0
01003 skipto 60000 icmp from any to { 255.255.255.255 or 192.168.3.254 } in icmptypes 8
Line 53: hostname ``l2tp'' unknown
Last line that is loaded is 1003:

Code: [Select]

add 1003 skipto 60000 icmp from any to { 255.255.255.255 or 192.168.3.254 } in icmptypes 8
add 1005 skipto 60000 udp from any to l2tp dst-port 53 keep-state
add 1005 skipto 60000 ip from any to { 255.255.255.255 or l2tp } in
add 1005 skipto 60000 ip from { 255.255.255.255 or l2tp } to any out
add 1005 skipto 60000 icmp from { 255.255.255.255 or l2tp } to any out icmptypes 0
add 1005 skipto 60000 icmp from any to { 255.255.255.255 or l2tp } in icmptypes 8
Presumably 'l2tp' should be a macro for the l2tp1 interface IP address (however this is done in ipfw, am more pf familiar), or perhaps a via statement for the interface?

I've just deleted the l2tp rules for now and reloaded the ipfw ruleset, NOW I see the shaping rules in 'ipfw -a list'.  Presumably when I had it working on an earlier 17.7 release, was prior to setting up the L2TP tunnel.

[iMx]

Bug report raised:

https://github.com/opnsense/core/issues/1907