Re: ngctl list ?

2013-05-20 Thread 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  ".

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 

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  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]"


Re: ngctl list ?

2013-05-20 Thread 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


___
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[email protected]"


Re: ngctl list ?

2013-05-19 Thread 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")

[email protected] ~ # ngctl ls
There are 16 total nodes:
  Name: em0 Type: ether   ID: 0003   Num hooks: 0
  Name: em1 Type: ether   ID: 0004   Num hooks: 0
  Name: em2 Type: ether   ID: 0005   Num hooks: 0
  Name: ng0_beefcakeType: eiface  ID: 0018   Num hooks: 1
  Name: ng0_stats   Type: eiface  ID: 000f   Num hooks: 1
  Name: ngctl21992  Type: socket  ID: 005f   Num hooks: 0
  Name: ng0_cfg0_vlbxri Type: eiface  ID: 0024   Num hooks: 1
  Name: igb0bridge  Type: bridge  ID: 0008   Num hooks: 4
  Name: ng0_ipu0a_vlbxr Type: eiface  ID: 0037   Num hooks: 1
  Name: ng0_ipm0_vlbxri Type: eiface  ID: 002d   Num hooks: 1
  Name: igb1bridge  Type: bridge  ID: 001d   Num hooks: 8
  Name: ng0_oos0a_vlbxr Type: eiface  ID: 0042   Num hooks: 1
  Name: ng0_opm0_vlbxri Type: eiface  ID: 004e   Num hooks: 1
  Name: ng0_wss0a_vlbxr Type: eiface  ID: 005b   Num hooks: 1
  Name: igb0Type: ether   ID: 0001   Num hooks: 2
  Name: igb1Type: ether   ID: 0002   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.
___
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[email protected]"