On May 20, 2013, at 4:28 PM, Joe wrote:
[…]
> Without netgraph compiled into the kernel, issuing "ngctl list" command on
> the host only shows the socket for ngctl.
>
> After I issue the kldload command on the host for netgraph ng_bridge
> ng_eiface ng_ether ng_socket, then issuing "ngctl list" command now shows the
> real NIC interface device names.
>
> Thanks for you insight.
>
Cool… glad module-based ng_ether is working. (in 8.1 the ng_* modules all
worked, but for ng_ether, it wasn't producing the expected results as a module
-- glad that's been fixed).
> I have another problem.
>
> To standardize my bridge and eiface names I want to use the JID number as a
> suffix.
>
> jid=`jls -j ${jailname} jid`
>
> bridge_name="bridge${jid}
> When creating the bridge it gets assigned bridge_name just like I want.
>
> I want to assign the ${jid} to the ieface peer name and can not figure out
> the syntax. This is the command I am using now
>
> ngctl mkpeer eiface ether ether
>
The syntax for renaming anything in netgraph with ngctl (non-interactively) is
"ngctl name <node> <new_name>".
First you create the node and then you rename it.
As an aside...
It looks like you're creating the eiface separately from connecting it to the
bridge. You can combine the mkpeer and the (not shown) later "connect" by doing
a contextual mpeer (which will result in a peer being created that is already
connected to the bridge).
For example:
ngctl mkpeer rl0:lower eiface link# ether
You're creating a new eiface peer off the rl0:lower ether device and assigning
the link all in one go.
"rl0" is your ng_ether device and rl0:lower is (presumably) your ng_bridge
device. "link#" is the new link to create. To find the "#" value in "link#", I
run a loop that starts from "2" (because rl0:upper is "link0", and rl0:lower is
"link1") and counts upward until it finds an unused link#.
How I test for the existence of a link is by issuing:
ngctl info rl0:lower getstats #
Where # is the link# you're interested in. So here's the loop I run to find
link#
LINKNUM=2
while ngctl msg rl0:bridge getstats $LINKNUM > /dev/null 2>&1; do
LINKNUM=$(($LINKNUM+1))
done
At that point, I've calculated LINKNUM and can then issue the above command
with:
ngctl mkpeer rl0:lower eiface link$LINKNUM ether
NOTE: Again, assuming your ng_ether device is "rl0" (a Realtek NIC; replace
with "em0", "bge0", or whatever as needed).
Resulting in a new eiface that is already connected to the bridge (previously
connected to rl0:lower).
Now… to rename that interface…
ngctl name rl0:lower:link$LINKNUM <desired_name>
But once you've done that, you're not finished yet. You now need to rename the
interface using ifconfig.
The syntax for renaming interfaces visible to ifconfig(8) is:
ifconfig <old_name> name <new_name>
The old name is obtainable with the following ngctl syntax:
ngctl show -n rl0:lower:link$LINKNUM
NOTE: It's the second word, so "| awk '{print $2}'" is handy here
Once you've got that value, you can then do your ifconfig re-naming. This is
the safe way to do the renaming (interrogate netgraph for the ifconfig name
using the above method).
NOTE: The netgraph renaming is entirely optional (should have mentioned that
earlier); all that is really needed is the ifconfig renaming (using the ngctl
show syntax to parse out the current ifconfig name for a peer). However, one of
the things that the netgraph-based naming buys you is that when you dump the
current config (using "ngctl dot"), you have a good mapping of eifaces-to-JIDs;
in my case… with the vimage script I developed… this is why I actually tend to
favor the jail-name truncated to fit into the interface name… it's much more
useful than staring at a graphviz rendering holding nothing but JIDs).
> This creates a default name of ngeth0
> I would be ok with ngeth${jid}
> But would really like to assign my own peer name vetjail${kid}
All you really need is the above recipe and you should be on your way. Let me
know if you need additional help.
> Does the mkpeer syntax allow doing this?
>
Well… not really. The "name" syntax of ngctl allows this.
> Thanks
>
Cheers.
--
Devin
_____________
The information contained in this message is proprietary and/or confidential.
If you are not the intended recipient, please: (i) delete the message and all
copies; (ii) do not disclose, distribute or use the message in any manner; and
(iii) notify the sender immediately. In addition, please be aware that any
message addressed to our domain is subject to archiving and review by persons
other than the intended recipient. Thank you.
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[email protected]"
