Re: Networking issues with 7.0-Release?
- From: Jason Bourne <j_bourne_treadstone@xxxxxxxxxxx>
- Date: Sat, 22 Mar 2008 03:36:43 GMT
Cox.Jason@xxxxxxxxx wrote:
I have a brand new 7.0 install setup as a router for my home network,
but I am seeing:
- High levels of packet loss
- Poor external DNS performance (websites, etc.)
- Poor data throughput
Don't know how much help any of this may be, but I'll take a stab and poke
out some general observations. I have a 7-Release gateway/pf/caching DNS
server and do not see these problems. It was a fresh install, there are no
compat options of any kind in the kernel (everything was to be built
against 7.x libs), and the kernel included nooption KSE. I am using libthr
and the ULE scheduler and so far have had no difficulties, however, this is
only a 768kb/s DSL line so it's not really being heavily loaded. I also do
not have IPv6 in the kernel as my ISP does not currently support it.
It's very possible that I have set up something incorrectly as this is
my first FreeBSD installation (been using Linux as a router for
awhile). I DEFINITELY saw a large slowdown switching from my store-
bought router to FreeBSD 7.0 though. Sites take longer to resolve and
load than they had with the store-bought router.
More than likely you have more than one thing contributing to your problem.
Whenever I see "slow DNS" complaints I expect to see DNS resolution looking
for IPv6 and AAAA records and then going to IPv4 when that times out. A
tcpdump on your WAN interface can confirm.
I have seen a few people here and there complaining about network
performance in 7.0 (I even saw some bug reports submitted
http://www.freebsd.org/cgi/query-pr.cgi?pr=misc/117255), but I want to
make sure it's not something in my setup.
I doubt this PR has much to do with the current situation. Look at the age
of that PR. These things were, for the most part, examined and dispatched
prior to the final release of 7.0.
Does anyone have any ideas?
Here's my network setup:
Internet
|
nfe0
However, with regard to the above, I have seen complaints on and off
concerning nfe. You might look into the state of the nfe driver for more
details.
------------ ath0 (wireless)
|
Can't speak to the ath0 because I don't have one. What I would recommend is
to take it out of the equation temporarily. Set up a gateway that functions
correctly first, then add it into the mix after the basics are done
correctly. You'll probably need to add a line or two to the firewall/NAT
config and maybe a static route, but do this _after_ you have a basic
gateway that performs the way it should.
------------ rl0 (hooked into switch - unused)
The rl card will only give about 50% of the throughput as compared with
something more expensive at full network load. This generally does not come
into play on a home connection because the load never really rises to
levels where this becomes an issue. I had one on my DSL connection for
quite a while and when I changed it out for a better card saw no change.
While probably one of the lowest performing NICs on the planet, it is still
perfectly useable for a low bandwidth environment such as home gateway box.
cat /etc/rc.conf^^^^^^^^^^^^^^^^^^^^
# -- sysinstall generated deltas -- # Sun Mar 2 20:43:38 2008
# Created: Sun Mar 2 20:43:38 2008
# Enable network daemons for user convenience.
# Please make all changes to this file, not to /etc/defaults/rc.conf.
# This file now contains just the overrides from /etc/defaults/
rc.conf.
hostname="tenchi.local"
# Services
linux_enable="YES"
sshd_enable="YES"
sendmail_enable="NO"
dnsmasq_enable="YES"
Me, I would toss this as superfluous. Set up the Bind 9 that is built into
the operating system as a caching server and it'll work just fine. I doubt
you have enough machines on your home LAN to really require you running a
DHCP server. Just use static IP. DHCP really only becomes a requirement
when you reach large numbers of boxen where maintaining static IPs becomes
inefficient. If you have only a handful of computers don't waste your time.
# Interfaces^^^^^^^^^^^^^^^^^^
ifconfig_nfe0="DHCP"
ifconfig_ath0="inet 10.0.0.1 netmask 255.255.255.0 ssid foo channel 11
mediaopt hostap"
ifconfig_rl0="inet 10.0.1.1 netmask 255.255.255.0"
# Firewall
ipfilter_enable="YES"
ipfilter_rules="/etc/ipf.rules"
# NAT
gateway_enable="YES"
router_enable="YES"
Take this out. This is for when you have routers on your network with which
you are required to communicate routing tables via the RIP protocol. I
doubt very seriously that you need this.
ipnat_enable="YES"
ipnat_rules="/etc/ipnat.rules"
cat /etc/resolv.conf
# OpenDNS nameservers - just to be sure. Tried ISP's as well.
nameserver 208.67.222.222
nameserver 208.67.220.220.
I have used both of these as well as those of my ISP. No trouble found here.
I am using dnsmasq to serve dhcp and dns queries.
cat /usr/local/etc/dnsmasq.conf |grep ^[^#]
Like I said before - I would dump this in favor of the Bind 9 already
present in the OS as a caching server.
domain-needed
bogus-priv
filterwin2k
local=/local/
except-interface=nfe0
bind-interfaces
expand-hosts
domain=local
dhcp-range=10.0.0.50,10.0.0.254,255.255.255.0,infinite
dhcp-range=10.0.1.0,10.0.1.254,255.255.255.0,infinite
dhcp-host=washu
dhcp-host=ryoko
dhcp-host=bubbles
dhcp-host=win-washu
And if you don't have a pressing need for IPv6 kill it too. Unless your ISP
actively provides support for it or you are using a tunnel to a provider
you have no use for it. Having it around probably entices your DNS to query
for AAAA and IPv6 DNS before timing out. YMMV.
netstat -i
Name Mtu Network Address Ipkts Ierrs Opkts
Oerrs Coll
nfe0 1500 <Link#1> 00:0c:76:09:06:94 2743104 0
55150 0 0
nfe0 1500 (public ip)/2 (public address) 32387 - 27209
- -
rl0* 1500 <Link#2> 00:08:a1:57:90:3e 1697 0
2891 0 0
rl0* 1500 10.0.1.0 10.0.1.1 5 -
6 - -
ath0 1500 <Link#3> 00:0f:b5:f9:ea:29 32088 10401 59139
63 0
ath0 1500 10.0.0.0 tenchi 3503 -
1947 - -
plip0 1500 <Link#4> 0 0
0 0 0
lo0 16384 <Link#5> 103 0
103 0 0
lo0 16384 fe80:5::1 fe80:5::1 0 -
0 - -
lo0 16384 ::1 ::1 0 -
0 - -
lo0 16384 your-net localhost 79 -
79 - -
ifconfig:
nfe0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu
1500
options=8<VLAN_MTU>
ether 00:0c:76:09:06:94
inet (public IP) netmask 0xfffffc00 broadcast 255.255.255.255
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
rl0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=8<VLAN_MTU>
ether 00:08:a1:57:90:3e
inet 10.0.1.1 netmask 0xffffff00 broadcast 10.0.1.255
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
ath0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu
1500
ether 00:0f:b5:f9:ea:29
inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255
media: IEEE 802.11 Wireless Ethernet autoselect <hostap>
(autoselect <hostap>)
status: associated
ssid cox channel 11 (2462 Mhz 11g) bssid 00:0f:b5:f9:ea:29
authmode OPEN privacy OFF txpower 31.5 scanvalid 60 bgscan
bgscanintvl 300 bgscanidle 250 roam:rssi11g 7 roam:rate11g 5
protmode CTS burst dtimperiod 1
plip0: flags=108810<POINTOPOINT,SIMPLEX,MULTICAST,NEEDSGIANT> metric 0
mtu 1500
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
inet6 ::1 prefixlen 128
inet 127.0.0.1 netmask 0xff000000
cat /etc/ipf.rules (ipfilter rules):
# Unrestricted internal access
pass out quick on rl0 all
pass in quick on rl0 all
pass out quick on ath0 all
pass in quick on ath0 all
pass out quick on lo0 all
pass in quick on lo0 all
# Allow ssh in
pass in quick on nfe0 proto tcp from any to any port = 22 flags S keep
state
# Allow anything out
pass out quick on nfe0 proto tcp all flags S keep state
pass out quick on nfe0 proto udp all keep state
pass out quick on nfe0 proto icmp all keep state
# Block all by default
block in log first quick on nfe0 all
cat /etc/ipnat.rules (ipnat rules):
map nfe0 10.0.0.1/24 -> 0/32
map nfe0 10.0.1.1/24 -> 0/32
It's been so long since I used ipfilter I'd have to go dig up my notes and
configs from backups. Generally speaking, my guess would be if you have
connectivity it is most likely not the source of poor performance.
My thoughts are the nfe driver performance and the DNS/IPv6 stuff. A
solution to the nfe if it is the source is to simply disable it and use a
different card. As far as the other stuff, get rid of it is what I'd do.
But then again - YMMV.
-Jason
.
- Follow-Ups:
- Re: Networking issues with 7.0-Release?
- From: Cox . Jason
- Re: Networking issues with 7.0-Release?
- References:
- Networking issues with 7.0-Release?
- From: Cox . Jason
- Networking issues with 7.0-Release?
- Prev by Date: Re: pkg_add pkg_delete tripping over each other on 7.0?
- Next by Date: Re: Cisco VPN
- Previous by thread: Networking issues with 7.0-Release?
- Next by thread: Re: Networking issues with 7.0-Release?
- Index(es):
Relevant Pages
|