Date: Thu, 30 May 2013 16:25:04 +0000 From: "Teske, Devin" <Devin.Teske@fisglobal.com> To: Pietro Paolini <pulsarpietro@aol.com> Cc: "<freebsd-questions@freebsd.org>" <freebsd-questions@freebsd.org> Subject: Re: VIMAGE Message-ID: <13CA24D6AB415D428143D44749F57D7201F68CBD@ltcfiswmsgmb21> In-Reply-To: <DB90C1DC-66E4-4429-A888-44F4F9E4B98B@aol.com> References: <DB90C1DC-66E4-4429-A888-44F4F9E4B98B@aol.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On May 30, 2013, at 3:35 AM, Pietro Paolini wrote: Hello all, I am a new bye on the FreeBSD and I am looking at the VIMAGE features exper= iencing some problems. I added the options : VIMAGE if_bridge and I removed STCP then I recompiled my kernel and install it. After that, following this tutorial http://imunes.tel.fer.hr/virtnet/eurobs= dcon07_tutorial.pdf I tried the "Exercise 2" which consist on the following commands: vimage -c n1 vimage -c n2 ngctl mkpeer efface ether ether ngctl mkpeer efface ether ether Don't you just love autocorrect? (does the same thing to me=85 turns "eifac= e" into "efface") ngctl mkpeer em0: bridge lower link0 Looks good. ngctl name em0:lower bridge0 I usually do my "connect" before the "name"=85 but shouldn't matter. Should= work all the same. ngctl connect em0: bridge0: upper link1 This looks wrong to me. I'd expect: ngctl connect em0: bridge0:lower upper link1 # The way I see most people using vimage=85 it seems like almost always a m= istake to not hook the upper (unless you have very good reason to make the = base machine inaccessible from the jails and vice-versa). Some missing points=85 # Make sure the bridged-interface is active ifconfig em0 up # Set promiscous mode and # don't override src addr ngctl msg em0: setpromisc 1 ngctl msg em0: setautosrc 0 ngctl connect ngeth0: bridge0: ether link2 ngctl connect ngeth1: bridge0: ether link3 Let's re-work this. Earlier you did 2x "mkpeer" to pre-create your eiface nodes. I don't do thi= s, as it later requires a "connect" for each created peer. What you can do instead is _not_ perform those earlier commands (shown belo= w): ngctl mkpeer eiface ether ether ngctl mkpeer eiface ether ether (followed by the above "connect" statements) But *instead*, you can actually do a contextual "mkpeer" that connects the = nodes as they are created. For example=85 instead of this: ngctl mkpeer eiface ether ether ngctl mkpeer eiface ether ether ngctl connect ngeth0: bridge0: ether link2 ngctl connect ngeth0: bridge0: ether link3 (which doesn't look right to me, because I'm used to creating an ether edge= between bridge:lower and the eiface) You can instead do: ngctl mkpeer em0:lower eiface link2 ether ngctl mkpeer em0:lower eiface link3 ether This simplifies 4 statements into 2. NOTE: I can't remember if "em0:lower" can be replaced with the new name of = "bridge0" (that you created with "ngctl name em0:lower bridge0"). My script= s continue to use the raw name in the mkpeer statements even after a rename= of the lower-link. You *may* be able to instead say "ngctl mkpeer bridge0:= eiface link2 ether" etc.) vimage -i n1 ngeth0 e0 But my virtual interface on the n1 vimage does not receive any packet from = the external network while I can see the packet go out from it. Try hooking changing your PHY->bridge hook to the lower and hooking your PH= Y upper into the bridge. For instance using DHCP, e0 on n1 sends DHCP packets but it does not receiv= e the answers (which are send, I verified it from wireshark), in adding the ARP request for his IP address (if I try to add it statically) are not = received then it can not answer. At the end of the line the question is: how can I make this "virtual networ= k" and the external real network be able to communicate ? Thanks in advance. Wondering if you've given my solution a try=85 http://druidbsd.sf.net/vimage.shtml -- Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?13CA24D6AB415D428143D44749F57D7201F68CBD>