[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