Date: Wed, 11 Feb 2009 21:01:38 +1000 From: Da Rock <rock_on_the_web@comcen.com.au> To: freebsd-questions@freebsd.org Subject: Re: Bridge setup at boot Message-ID: <1234350098.13067.26.camel@laptop1.herveybayaustralia.com.au> In-Reply-To: <1234326877.13067.18.camel@laptop1.herveybayaustralia.com.au> References: <1234314560.6351.25.camel@laptop1.herveybayaustralia.com.au> <49924FB0.4090705@ibctech.ca> <1234326877.13067.18.camel@laptop1.herveybayaustralia.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2009-02-11 at 14:34 +1000, Da Rock wrote: > On Tue, 2009-02-10 at 23:10 -0500, Steve Bertrand wrote: > > Da Rock wrote: > > > I feel like a real newbie asking this one, but the answer is still > > > eluding me :( > > > > > > I have a system where I'm separating my servers for distinction so I'm > > > running qemu. > > > > > > I have a bridge setup which works occasionally, but I need it to work > > > 100% of the time. I also need this to run at boot time, which is where > > > it seems to fall short (not to mention that on occasion even the re > > > driver fails to load- not sure if its hardware or software yet, but > > > appears to have no bearing on the bridge problem; I could still get an > > > ip address via dhcp when the bridge is not working). > > > > > > My loader.conf looks like this: > > > > > > snd_hda_load=YES > > > if_bridge_load=YES > > > if_tap_load=YES > > > > > > My rc.conf looks like this: > > > > > > cloned_interfaces="bridge0 tap0" > > > autobridge_interface="bridge0" > > > autbridge_bridge0="re0 tap0" > > > ifconfig_re0="up" > > > ifconfig_tap0="up" > > > ifconfig_bridge0="DHCP" > > > > > > If I tell re0 to use DHCP as well, I can access the host, but not the > > > guest. If I run qemu in a script, the guest cannot get a DHCP address. > > > > > > This seems to happen intermittently- one problem then the other. If the > > > bridge fails to get an ip from dhcp, I find re going down just after > > > bridge0 starts looking for an ip- re comes up again after that starts. > > > If bridge0 does get an ip, the tap0 will go down and qemu guest can't > > > get an ip. > > > > > > I feel like I'm going round in circles now. Using rc.conf nothing > > > appears to be happening in order- things seem to be going up and down > > > when they feel like instead of when they should. I need this to be > > > stable, not a "cross your fingers and toes, we're going in" scenario- > > > which is what bridging appears to be like at startup. Manually I can get > > > it working off the bat, but I'm trying to get this working within the > > > framework provided. > > > > > > For reference the sysctl.conf settings mentioned in some circles are > > > useless in 7.1- net.link.ether.bridge_cfg and > > > net.link.ether.bridge.enable aren't recognized. > > > > Can you stabilize the bridge at boot, without any other software > > starting up? > > > > The short answer is no. The usual problem here is re0 goes down just > after bridge0 goes looking for an ip. The other times are a mix of tap0 > going down or some other gremlin I haven't been able to find yet. > > > If not, does re0 get set up consistently with the same config with a > > basic setup? > > > > It can, but that would depend on whether the driver picks it up during > boot. If the driver comes back with an error then re0 doesn't exist for > the rc.conf, if re0 does exist it usually sets up and runs ok during the > entire system up time (as far as I'm aware- I'm accessing the system > usually through ssh, I haven't seen anything strange in the logs, so ?). > > > I had similar issues a while back (pre 7.1) in which sometimes 're' > > devices didn't start up at the proper speed/duplex. Every once in a > > while, it would show up at 10 or 100 half, when it should have been auto > > set at full 100 or 1000. If I forced proper speed/duplex, other outside > > programs began to work properly. > > > > However, I haven't witnessed those issues since 7.1 > > I didn't know about that, but given the problems I'm having I'm starting > to wonder if they could be a root cause of the problem here. I think I'm starting to get a clearer picture here: based on my observation on a test system tap0 appears to go down as soon as a program connects to it and uses it. Ergo, IF this is the case then that solves the second part of my problem. So could this be a composite issue from this and a hidden issue with my re0 device (driver or whatever)?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1234350098.13067.26.camel>