> On 2020-09-14, Scott Reese <obs...@marianinc.com> wrote: >> Greetings: >> >> ----- Original Message ----- >>> From: "Uwe Werler" <u...@werler.is> >>> To: "misc" <misc@openbsd.org>, "Scott Reese" <obs...@marianinc.com>, "misc" >>> <misc@openbsd.org> >>> Sent: Monday, September 14, 2020 12:47:31 PM >>> Subject: [EXTERNAL] Re: Troubleshooting pf congestion >> >>> Without seeing a rule set what should one say? >>> >> >>>> >>>>If anyone could spare a couple of sentences or a share a link to a page >>>>detailing what >>>>state causes the system to consider itself contested, I would >>>>appreciate it. >> >> Thanks for your reply. The question that I can't find a good answer for is, >> "What is pf congestion?". I would like to solve the actual problem myself, >> I'm >> just looking >> for some information about what it means for pf to be congested. > > When enqueueing packets to an interface fails (queue is full), a > global congestion marker variable in the kernel is set to the current > timestamp. > > When PF tests an inbound packet against rules (i.e. when it has a packet > that doesn't match an existing state) it checks if that congestion timestamp > is recent. If it is, the packet is dropped and the PF stats congestion > counter is incremented. > > Look around if_congested/if_congestion in /sys/net and the mq_ functions > in /sys/kern/uipc_mbuf.c - the functions described in mq_init(9) as "If the > queue is full then XX will be dropped" trigger congestion. > > You might get some suggestions if you post a description of your > configuration (at least which interface types - physical or virtual - > are in use, what they're connected to, what if any VPNs it's running, > and it may help to see the ruleset). > > Output from these might help too: > > netstat -m > systat mbuf | cat > vmstat -i > vmstat -m
Greetings Stuart: Thank you for your reply. It was very helpful and pointed me in the right direction. The 1000+ windows workstations behind that firewall had been converted from 7 to 10. Most aren't allowed to access the internet, and the new OS is much more aggressive about trying to phone home. All of those dropped packets had to traverse all of the rules before being dropped, and that was the root cause of the issue. It didn't look like too much traffic because it was just SYN packets, but it was a lot of SYN packets. Again, thanks for your help. -Scott
