[PC-BSD Testing] Network problem

Jeff dejamuse at yahoo.com
Sun May 16 15:26:18 PDT 2010


You can disregard the last email I sent re this crazy issue referring to
 the Drupal update script - I was actually on the other server. Oops.  
Both are using the same IP though I never run them at the same time.

How can I change the IP of an 
existing jail?

The Warden server on my old machine running PCBSD 
7.1.1 works fine with this configuration in rc.conf:

ifconfig_bge0="inet
 192.168.1.11 netmask 255.255.255.0"

and the Warden 
(192.168.1.12) also set to bge0.

So on the new machine, I 
disabled lagg0, setup the NIC to use re0, and switched the Warden to 
re0:

# 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
        inet 192.168.1.10 netmask 0xffffff00
 broadcast
 192.168.1.255
        inet6 fe80::224:8cff:fea1:b3f7%re0 prefixlen 
64 scopeid 0x1
        inet 192.168.1.12 netmask 0xffffffff broadcast
 192.168.1.12
        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
lo1:
 flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
       
 options=3<RXCSUM,TXCSUM>
        inet 10.1.1.1 netmask 
0xffffff00
---------------

But the problems persist.  Arggghhh!

Here are the parameters for the other machine running 7.1.1 with essentially the same jail (I exported it into the new machine running 8.0):

# ifconfig
bge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST>
 metric 0 mtu 1500
        options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
       
 ether 00:11:11:c3:7a:e2
        inet 192.168.1.11 netmask 0xffffff00
 broadcast 192.168.1.255

        media: Ethernet autoselect (100baseTX <full-duplex>)
       
 status: active
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 0x3
        inet6 ::1 
prefixlen 128
        inet 127.0.0.1 netmask 0xff000000
pfsync0: 
flags=0<> metric 0 mtu 1460
        syncpeer: 224.0.0.240 
maxupd: 128

pflog0: flags=0<> metric 0 mtu 33204
----------------------------------
#
 netstat -rn
Routing tables

Internet:
Destination        
Gateway            Flags    Refs      Use  Netif Expire
default           
 192.168.1.2        UGS         0     3323   bge0

127.0.0.1          127.0.0.1          UH          0       22    lo0
192.168.1.0/24     
link#1             UC          0        0   bge0
192.168.1.2        
00:21:29:e4:34:e4  UHLW        2      447   bge0   1176

192.168.1.255      ff:ff:ff:ff:ff:ff  UHLWb       1       59   bge0

Internet6:
Destination                      
 Gateway                       Flags      Netif Expire
::1                              
 ::1                           UHL         lo0

fe80::%lo0/64                     fe80::1%lo0                   
U           lo0
fe80::1%lo0                       
link#3                        UHL         lo0
ff01:3::/32                      
 fe80::1%lo0                   UC          lo0

ff02::%lo0/32                     fe80::1%lo0                   
UC          lo0
-----------------------------------------
Some
 parameter gets changed inadvertently that slows down access to the 
server and prevents Drupal from accessing the internet (it may in fact 
be timing out for the same reasons the server is slow to respond).

I
 had fixed this problem before by issuing:

pbreg set 
/PC-BSD/TheWarden/NIC lagg0  and rebooting.

But nothing is 
working now, nor do I know why it reverted to not working - any time I 
muck with changing from DHCP to static it seems to happen.

I can fix the server response time problem by assigning 192.168.1.10 to the NIC and 192.168.1.12 (the jail IP) to lagg0 and oddly, NOT restarting the jail, but Drupal still cannot talk to the internet.  Not sure what they are using for that, Curl perhaps.

I pinged the BSD guys and one response so far suggested looking at resolv.conf in the jail.  That file contained only this line: nameserver 192.168.1.1.  That was the gateway address of the previous router.  The new one is 192.168.1.2.  I changed to that and rebooted but it had no effect.

--- On Sun, 5/16/10, Kris Moore <kris at pcbsd.org> wrote:

From: Kris Moore <kris at pcbsd.org>
Subject: Re: [PC-BSD Testing] Network problem
To: testing at lists.pcbsd.org
Date: Sunday, May 16, 2010, 2:44 PM





  
On 05/14/2010 13:55, Jeff wrote:

  
    
      
        I still have this weird problem with a server running in
a jail.  

        

I reloaded a database into MySQL and noted that suddenly the server
response was back to normal and Drupal could talk to the internet
again.  Then I ran the DB update script because I had updated a module,
and it broke again.  So this is more complicated than I thought. Not
sure how changing network parameters triggers this.

        

But I did notice a difference between two machines.  Both are running
Drupal with the Warden, and the one with this problem shows the static
IP for the box (192.168.1.10) associated with lagg0 (along with the
jail, 192.168.1.12), not the NIC, re0.  Whereas the other machine is
the opposite.  Does this indicate a problem?

        

# 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

------------------------

Other machine:

        

# ifconfig

bge0: flags=8843<UP,BROADCAST,
         RUNNING,SIMPLEX,MULTICAST>
metric 0 mtu 1500

        options=9b<RXCSUM,TXCSUM,VLAN_ MTU,VLAN_HWTAGGING,VLAN_ HWCSUM>

        ether 00:11:11:c3:7a:e2

        inet 192.168.1.11 netmask 0xffffff00 broadcast 192.168.1.255

        media: Ethernet autoselect (100baseTX <full-duplex>)

        status: active

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 0x3

        inet6 ::1 prefixlen 128        inet 127.0.0.1 netmask 0xff000000

pfsync0: flags=0<> metric 0 mtu 1460

        syncpeer: 224.0.0.240 maxupd: 128

pflog0: flags=0<> metric 0 mtu 33204
        

        
      
    
  
  




Taking lagg0 out of the equation would be the first thing to try. If
that fixes the issue, then we can isolate it to a lagg problem, and let
freebsd mantainers know. Also, what does your "db update script" do? Is
it changing some drupal / sql setting and causing this? That makes it
sound like its not a network configuration problem. 



-- 
Kris Moore
PC-BSD Software
iXsystems
 

-----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/20100516/fbdef73e/attachment-0001.html>


More information about the Testing mailing list