I provided the example "2 host 2 switch" configuration awhile ago. I'm
not sure I can reproduce your problem in my environment as my VMs are
probably not running the same OS, etc. as yours.
For what it is worth, with that configuration in my VM setup I find that
at startup the vigil1 VM gets an IP address on the interface connected
to the "host" computer via DHCP, but the vigil2 VM does not. I've not
investigated deeply why this is, but suspect it has to do with the
default way the OS in my VMs attempt to bring up interfaces. It's also
been suggested this may be a VDE issue, but I haven't had time to
investigate further.
In any case, I have to manually bring up the interface to the "host" on
vigil2. The only thing that is tricky about this is identifying the
correct interface since vigil2 has multiple interfaces. To determine
the correct interface, look at the output printed when the VMs are
started. I've selected the two important lines for my situation:
...
slirpvde -daemon -socket /home/keith/vm/vde/ctls2 -dhcp
...
screen -c /home/keith/vm/vigil2.screenrc -dm -S vigil2 -e ^Oo vdeq kvm --mod
700 -m 32 \
-hda hda.dsk -kernel kernel.bin -append 'root=/dev/hda1 console=ttyS0
apm=power-off noapic ' -nographic \
-net nic,model=rtl8139,vlan=1,macaddr=50:54:00:00:00:04 -net
vde,vlan=1,sock=/home/keith/vm/vde/ctls2 \
-net nic,model=rtl8139,vlan=2,macaddr=50:54:00:00:00:05 -net
vde,vlan=2,sock=/home/keith/vm/vde/ctls3 \
-net nic,model=rtl8139,vlan=4,macaddr=50:54:00:00:00:06 -net
vde,vlan=4,sock=/home/keith/vm/vde/ctls5 \
-snapshot
...
In the first line shown, slirpvde was supposed to run DHCP
on /home/keith/vm/vde/ctls2. This was what should have given vigil2 an
IP by DHCP but didn't work. In the second line, notice
that /home/keith/vm/vde/ctls2 is associated with the nic with macaddr
50:54:00:00:00:04. With this information, you can identify the
interface on vigil2 by looking at the output of 'ifconfig -a' run within
that VM:
...
eth1 Link encap:Ethernet HWaddr 50:54:00:00:00:04
...
Since the HWaddr of eth1 matches, that must be the one connected to the
"host". The network that is created for the connections to the "host"
is 10.0.2.0 with the host on 10.0.2.2. I manually give an address to
the eth1 interface in the vigil2 VM with the command:
ifconfig eth1 10.0.2.16 netmask 255.255.255.0
After this, I can ping the host computer, and I can connect secchan to a
controller running on the host using the 10.0.2.2 address. As I said,
I'm not sure whether you are experiencing the same issues as I am.
Hopefully this account at least gives you some hints for where to look
to resolve your issues.
--- Keith
On Wed, 2009-04-08 at 14:43 -0500, Zheng Cai wrote:
> Hi,
>
> I have tried both "ifconfig of0 10.0.0.5" and "secchan nl:0
> tcp:10.0.2.2:975" on vigil2 too, but the behavior is still the same.
> I.e., after 45 seconds, the switch tables start to contain active flows
> and forward end host traffic, but still with error messages "Could not
> connect to controller, failing open".
>
> However, I found out that, on the nox_core side, warning messages "(dhcp
> parse) warning DHCP packet data too short to parse header: data len 86"
> keep popping up. Was this the reason for such behavior? If so, any
> suggestions on how to solve this issue?
>
> (BTW I used the latest NOX version, downloaded the kernel.bin and
> openflow_mod.so and secchan from noxrepo.org. I used in-band control,
> ran nox_core with the "pyswitch" application. I added the nl:0 dp, and
> all eth interfaces to the dp except the one connecting the host, on both
> vigil1 and vigil2)
>
> Thanks a million,
>
_______________________________________________
nox-dev mailing list
[email protected]
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
