DSL throughput slow. Is it the firewall?

[thefronny]

Actually, I think it's my machine's NIC (re0) but is there any kind of "common" pf rule mistake that can slow down throughput to any substantial degree?

thanks,

tf

I dragged this old post up because, a few days after release, I upgraded my firewall to 5.1 and there has been a substantial improvement in throughput. The wireless access point has stopped dropping connections as well (the hostap work in 5.1 was actually why I upgraded).

Tip 'o the hat to all the OpenBSD folks for their work on 5.1; it has made a BIG difference for my network.

tf

[jggimi]

No, nothing common. There are packet normalizations rules or timing rules or prioritizations that if you use them (having blindly copied and pasted from somewhere without knowing what they do or why) that may cause problems.

More likely, there is something else going on. See what netstat -in shows regarding errors, or what netstat -ss shows about all statistics.

[BSDfan666]

It could be a userland PPPoE vs kernel PPPoE issue, which do you use in your configuration?

[thefronny]

Originally Posted by jggimi

No, nothing common. There are packet normalizations rules or timing rules or prioritizations that if you use them (having blindly copied and pasted from somewhere without knowing what they do or why) that may cause problems.

More likely, there is something else going on. See what netstat -in shows regarding errors, or what netstat -ss shows about all statistics.

Thanks for the write-back jggimi. Here's what they look like, these are from the firewall. I'll check any prioritization entries in pf.conf.

# netstat -in  
Name    Mtu   Network     Address              Ipkts Ierrs    Opkts Oerrs Colls
lo0     33200 <Link>                              86     0       86     0     0
lo0     33200 127/8       127.0.0.1               86     0       86     0     0
lo0     33200 ::1/128     ::1                     86     0       86     0     0
lo0     33200 fe80::%lo0/ fe80::1%lo0             86     0       86     0     0
fxp0    1500  <Link>      00:02:a5:55:66:77  1002678     0   908002     0     0
fxp0    1500  10.0.0/24   10.0.0.2           1002678     0   908002     0     0
fxp0    1500  fe80::%fxp0 fe80::202:a5ff:fe  1002678     0   908002     0     0
xl0     1500  <Link>      00:60:08:a0:b3:07   985137     0  1138591     0   274
xl0     1500  192.168.238 192.168.238.1       985137     0  1138591     0   274
xl0     1500  fe80::%xl0/ fe80::260:8ff:fea   985137     0  1138591     0   274
ral0    1500  <Link>      00:16:b6:57:7a:64        0     0        2     0     0
ral0    1500  fe80::%ral0 fe80::216:b6ff:fe        0     0        2     0     0
ral0    1500  172.22/16   172.22.22.1              0     0        2     0     0
enc0*   0     <Link>                               0     0        0     0     0
pflog0  33200 <Link>                               0     0       48     0     0

# netstat -ss 
ip:
        1987416 total packets received
        80278 packets for this host
        1905411 packets forwarded
        1565 packets not forwardable
        141389 packets sent from this host
        1117 multicast packets which we don't join
icmp:
        554 calls to icmp_error
        Output packet histogram:
                destination unreachable: 554
        Input packet histogram:
                echo reply: 21
igmp:
ipencap:
tcp:
        137499 packets sent
                137270 data packets (21070256 bytes)
                204 ack-only packets (5225 delayed)
                25 control packets
        75273 packets received
                71878 acks (for 21070260 bytes)
                22 duplicate acks
                5297 packets (279416 bytes) received in-sequence
                18 completely duplicate packets (0 bytes)
                4 out-of-order packets (0 bytes)
                242 window update packets
        8 connection requests
        11 connection accepts
        19 connections established (including accepts)
        76 connections closed (including 1 drop)
        71886 segments updated rtt (of 71675 attempts)
        11495 correct ACK header predictions
        2752 correct data packet header predictions
        22 PCB cache misses
        11 SYN cache entries added
                11 completed
        4 SYN,ACKs retransmitted
udp:
        4989 datagrams received
        1900 broadcast/multicast datagrams dropped due to no socket
        3089 delivered
        3318 datagrams output
        620 missed PCB cache
esp:
ah:
etherip:
ipcomp:
carp:
pfsync:
divert:
pflow:
ip6:
        201 total packets received
        17 packets sent from this host
        201 multicast packets which we don't join
        Input packet histogram:
                hop by hop: 32
                UDP: 110
                ICMP6: 59
        Mbuf statistics:
                201 one ext mbufs
divert6:
icmp6:
        Output packet histogram:
                multicast listener report: 14
                neighbor solicitation: 3
        Histogram of error messages to be generated:
pim6:
rip6:

[thefronny]

Originally Posted by BSDfan666

It could be a userland PPPoE vs kernel PPPoE issue, which do you use in your configuration?

If you mean on the router, it came pre-provisioned. I just went in and changed its internal network IP address. But this is off the web config page:

VPI/VCI 	VLAN Mux 	Con. ID 	Category 	Service 	Interface 	Protocol 	Igmp 	Nat 	Firewall 	QoS 	State 	Remove 	Edit
0/32 	Off 	1 	UBR 	pppoa_0_0_32_1 	ppp_0_0_32_1 	PPPoA 	Disabled 	Enabled 	Disabled 	Disabled 	Enabled

If you mean the firewall, it's just a default install. I've changed nothing except interface names and the packet forwarding sysctl. Does this help?

thanks,
tf

[jggimi]

Nothing jumps out at me from netstat as an obvious problem.

I found a pf.conf you posted here a year ago. I don't know how much of this is still configured this way:

set optimization normal

This optimization is the default setting, so the line is not necessary. It affects state timeouts.

match log on $ext_if all scrub (random-id min-ttl 254 set-tos lowdelay reassemble t
cp max-mss 1460)

In your scrub settings:

• I don't understand why you set a high minimum IP TTL, though I don't think this, by itself, will have a performance effect. Do you need this because of the impact of your TOS enforcement?
• The Type-Of-Service enforcement you are setting might be affecting performance, as routers upstream of you will handle packets with TOS bits set differently than "normal" packets. In this case, you are requesting packets be routed via the lowest-latency routes, but such routes may not be the most direct.

Have you looked at pfctl interface statistics?