ngctl list ?

[Joe]

When I issue "ngctl list" command on the host it only shows the socket
for ngctl.

I thought it would also show the real NIC interface device names.

Am I wrong in thinking that?

_______________________________________________
freebsd-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questi...@freebsd.org"

[Teske, Devin]

On May 19, 2013, at 1:47 PM, Joe wrote:

When I issue "ngctl list" command on the host it only shows the socket for ngctl.

I thought it would also show the real NIC interface device names.

Am I wrong in thinking that?

No, you're not wrong, however one wrinkle is that ng_ether(4) has to be compiled-in to get the netgraph subsystem to attach to your real NIC interfaces.

On the system where you're executing "ngctl list" (same thing as "ngctl ls"), can you execute:

config -x `sysctl -n kern.bootfile` | grep NETGRAPH_ETHER

and get back something like the following (which I get back from my system):

options NETGRAPH_ETHER # ng_ether(4)

(and on that system, I get the following for "ngctl ls")

ro...@folsom.vicor.com<mailto:ro...@folsom.vicor.com> ~ # ngctl ls
There are 16 total nodes:
Name: em0 Type: ether ID: 00000003 Num hooks: 0
Name: em1 Type: ether ID: 00000004 Num hooks: 0
Name: em2 Type: ether ID: 00000005 Num hooks: 0
Name: ng0_beefcake Type: eiface ID: 00000018 Num hooks: 1
Name: ng0_stats Type: eiface ID: 0000000f Num hooks: 1
Name: ngctl21992 Type: socket ID: 0000005f Num hooks: 0
Name: ng0_cfg0_vlbxri Type: eiface ID: 00000024 Num hooks: 1
Name: igb0bridge Type: bridge ID: 00000008 Num hooks: 4
Name: ng0_ipu0a_vlbxr Type: eiface ID: 00000037 Num hooks: 1
Name: ng0_ipm0_vlbxri Type: eiface ID: 0000002d Num hooks: 1
Name: igb1bridge Type: bridge ID: 0000001d Num hooks: 8
Name: ng0_oos0a_vlbxr Type: eiface ID: 00000042 Num hooks: 1
Name: ng0_opm0_vlbxri Type: eiface ID: 0000004e Num hooks: 1
Name: ng0_wss0a_vlbxr Type: eiface ID: 0000005b Num hooks: 1
Name: igb0 Type: ether ID: 00000001 Num hooks: 2
Name: igb1 Type: ether ID: 00000002 Num hooks: 2


NOTE: Alternatively… if you don't get a response back from config(8) similar to the above,… does "kldstat" show an "ng_ether" entry? I think last time I tried to load ng_ether(4) as a module (versus compiled-in), it didn't list any of my ether devices ("Type: ether" in above "ngctl ls" output).
--
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.

[Joe]

Teske

Here is my results

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.

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

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${jid}

Does the mkpeer syntax allow doing this?

Thanks

Joe

[Teske, Devin]

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.