[PC-BSD Testing] BIND problem in jail
Jeff
dejamuse at yahoo.com
Sun May 9 08:21:05 PDT 2010
OK, to reiterate, the server in the jail works but is very slow to access (normally just a few seconds but now more like 15 seconds or more) and it cannot talk to the internet. This seems to happen every time I make some change to the network, like switching from DHCP to static, if I remember correctly. The weird thing is very occasionally the server responds quickly for a few seconds it seems and then is slow again.
Sorry, it's all a bit Greek to me, but here is some additional info:
# ifconfig
re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=389b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_UCAST,WOL_MCAST,WOL_MAGIC>
ether 00:24:8c:a1:b3:f7
inet6 fe80::224:8cff:fea1:b3f7%re0 prefixlen 64 scopeid 0x1
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
options=3<RXCSUM,TXCSUM>
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
pflog0: flags=0<> metric 0 mtu 33152
pfsync0: flags=0<> metric 0 mtu 1460
syncpeer: 224.0.0.240 maxupd: 128
lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=389b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_UCAST,WOL_MCAST,WOL_MAGIC>
ether 00:24:8c:a1:b3:f7
inet 192.168.1.10 netmask 0xffffff00 broadcast 192.168.1.255
inet6 fe80::224:8cff:fea1:b3f7%lagg0 prefixlen 64 scopeid 0x5
inet 192.168.1.12 netmask 0xffffffff broadcast 192.168.1.12
media: Ethernet autoselect
status: active
laggproto failover
laggport: re0 flags=5<MASTER,ACTIVE>
lo1: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
options=3<RXCSUM,TXCSUM>
inet 10.1.1.1 netmask 0xffffff00
-------------------------------------------------
# netstat -rn
Routing tables
Internet:
Destination Gateway Flags Refs Use Netif Expire
default 192.168.1.2 UGS 6 196389 lagg0
10.1.1.1 link#6 UH 0 154 lo1
127.0.0.1 link#2 UH 0 89 lo0
192.168.1.0/24 link#5 U 0 19518 lagg0
192.168.1.10 link#5 UHS 0 0 lo0
192.168.1.12 link#5 UHS 0 8908 lo0 =>
192.168.1.12/32 link#5 U 0 0 lagg0
AppleTalk:
Destination Gateway Flags Netif Expire
Internet6:
Destination Gateway Flags Netif Expire
::/96 ::1 UGRS lo0
::1 ::1 UH lo0
::ffff:0.0.0.0/96 ::1 UGRS lo0
fe80::/10 ::1 UGRS lo0
fe80::%re0/64 link#1 U re0
fe80::224:8cff:fea1:b3f7%re0 link#1 UHS lo0
fe80::%lo0/64 link#2 U lo0
fe80::1%lo0 link#2 UHS lo0
fe80::%lagg0/64 link#5 U lagg0
fe80::224:8cff:fea1:b3f7%lagg0 link#5 UHS lo0
ff01:1::/32 fe80::224:8cff:fea1:b3f7%re0 U re0
ff01:2::/32 ::1 U lo0
ff01:5::/32 fe80::224:8cff:fea1:b3f7%lagg0 U lagg0
ff02::/16 ::1 UGRS lo0
ff02::%re0/32 fe80::224:8cff:fea1:b3f7%re0 U re0
ff02::%lo0/32 ::1 U lo0
ff02::%lagg0/32 fe80::224:8cff:fea1:b3f7%lagg0 U lagg0
--- On Fri, 5/7/10, Brodey Dover <doverosx at gmail.com> wrote:
From: Brodey Dover <doverosx at gmail.com>
Subject: Re: [PC-BSD Testing] BIND problem in jail
To: "PC-BSD Testing list" <testing at lists.pcbsd.org>
Date: Friday, May 7, 2010, 5:58 PM
Kris,
for lagg do you set the default to fail-over? If not, I've had this issue with round-robin and load-balancing options. As far as I know load-balancing is known and documented to cause "issues" because of the non-standard packet sequencing.
Brodey
On Fri, May 7, 2010 at 7:36 AM, Kris Moore <kris at pcbsd.org> wrote:
On 05/07/2010 14:09, Jeff wrote:
Well, this has come back to bite me
again.
I was living in Thailand when it I fixed it, using a Dlink ADSL router
and used DHCP for the PCBSD box. Then I moved back to the US and set
up my old network using a Linksys router and a Linksys wireless bridge
to connect my PCBSD box to the router and the internet.
I'm using lagg0 for the jail but set up the box with a static IP. So
now the original problem is back - slow server response in the jail and
Drupal cannot talk to the internet for updates and such. Set it up
with DHCP and same problem.
Oddly enough, when I had it setup with a static IP, Firefox was really
slow accessing the server site, like 10 seconds lag, but Opera was the
normal 1 or 2 seconds. When I changed to DHCP both were slow, taking
nearly 20 seconds to respond - it's all lag time - the page loads very
fast after that.
I noticed at boot there is a message something to the effect of re0
busy. Also noticed in Webmin, the network interface is reported as:
Name
Type
IP
Address
Netmask
Status
lagg0
Unknown
192.168.1.101
255.255.255.0
Up
lagg0:0
Unknown (Virtual)
192.168.1.12
255.255.255.255
Up
lo0
Loopback
127.0.0.1
255.0.0.0
Up
192.168.1.12 is the IP for the jail and .101 is the network interface
card on DHCP.
I have had similar problems with PCBSD going way back and never
resolved them. I just keep fiddling and rebooting and somehow it
magically gets fixed but I never know why. Now however, I can't get it
to work properly no matter what I try.
What in the world causes this behavior and how do I fix it?
...Jeff
Well, I'm unsure which is causing the failure here. Maybe a good thing
to try is taking the "lagg0" device out of the loop and see if the
problem goes away. You'll need to edit /etc/rc.conf manually, remove
the ifconfig_lagg0 line, and setup ifconfig_re0 to DHCP. Switch your
jail to running on re0 as well, and test, does it work better?
If that doesn't solve it, then you may be uncovering some other
networking bug :( I would recommend reporting it over to the
freebsd-net mailing lists:
http://lists.freebsd.org/mailman/listinfo/freebsd-net
Some of the folks over there could probably track it down relatively
quickly :)
--
Kris Moore
PC-BSD Software
iXsystems
_______________________________________________
Testing mailing list
Testing at lists.pcbsd.org
http://lists.pcbsd.org/mailman/listinfo/testing
-----Inline Attachment Follows-----
_______________________________________________
Testing mailing list
Testing at lists.pcbsd.org
http://lists.pcbsd.org/mailman/listinfo/testing
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pcbsd.org/pipermail/testing/attachments/20100509/a6785a78/attachment-0001.html>
More information about the Testing
mailing list