FS#15661 - [netcfg] Vlan-Config
Attached to Project:
Arch Linux
Opened by Oluf Lorenzen (Finkregh) - Thursday, 23 July 2009, 22:26 GMT
Last edited by Ionut Biru (wonder) - Saturday, 12 February 2011, 13:35 GMT
Opened by Oluf Lorenzen (Finkregh) - Thursday, 23 July 2009, 22:26 GMT
Last edited by Ionut Biru (wonder) - Saturday, 12 February 2011, 13:35 GMT
|
Details
Description:
Support of VLANs in netcfg would be quite nice patch is attatched 
0108-added-complete-VLAN-setu...
(5.8 KiB)
|
This task depends upon
Closed by Ionut Biru (wonder)
Saturday, 12 February 2011, 13:35 GMT
Reason for closing: Implemented
Additional comments about closing: http://projects.archlinux.org/netcfg.git /commit/?id=a9d39a075bed12243e6571f475dd f1c2ee0b078b
Saturday, 12 February 2011, 13:35 GMT
Reason for closing: Implemented
Additional comments about closing: http://projects.archlinux.org/netcfg.git /commit/?id=a9d39a075bed12243e6571f475dd f1c2ee0b078b
examples/ethernet-iproute-vlan | 10 ++
src/connections/ethernet-iproute-vlan | 134 ++++++++++++++++++++++++++++++++++
src/network | 18 +++-
3 files changed, 159 insertions(+), 3 deletions(-)
On thing needs to be added/configurable: vconfig set_egress_map VLANINTERFACE 2 6
Without this parameter vlans don't work for me.
I dont really get why you have to set skb_priority/vlan_qos o.O
Sorry for that.
Is there a chance that the feature request will be implemented?
And yes, i think i might implement that sometime...
oh, i still have to test my patch with the newer version of netcfg...
I'll give your patch a try.
This ticket is not closed, so: is VLAN support going to be implemented in netcfg? It would be convenient to use standard tools to manage VLANs instead of writing script by hands. Thank you.
i sadly still have had no time to test the patch...
<https://github.com/Finkregh/netcfg/commit/df4e0684ca5ee8a41ce646888b1b07847f82624a>
On a first glance, I think this is redundant. Isn't it possible to just add the vlan-specific configuration and then call the ethernet profile (like wireless does)? Right now, you are duplicating the whole IP configuration bits, like dhcp or static. If it isn't possible to re-use that, it should maybe be factored out so it can be called from both ethernet and vlan. (I know, I probably could have said all this before, when this was first submitted, sorry for all the slowness on my end.)
Subject: [PATCH] Fix some issues with VLAN configuration ...
- Re-use ethernet_up / ethernet_down
- Fix interface references in /var/run/network/ by requiring INTERFACE definition in profile
- Load required variables in network 'load_profile()' function
CONNECTION="ethernet-iproute-vlan"
DESCRIPTION="A more versatile static ethernet connection using iproute and VLAN"
PHYS_INTERFACE="eth0"
INTERFACE="eth0.10"
VLAN="10"
FLAG="false"
IP="static"
ADDR="10.0.1.120"
And results:
# netcfg -u Test
:: Test up [BUSY] Added VLAN with VID == 10 to IF -:eth0:-
Set flag on device -:eth0.10:- Should be visible in /proc/net/vlan/eth0.10
[DONE]
# ifconfig eth0.10
eth0.10 Link encap:Ethernet HWaddr 00:1D:60:C2:F2:8F
inet addr:10.0.1.120 Bcast:10.0.1.255 Mask:255.255.255.0
inet6 addr: ...
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:418 (418.0 b)
# arp -n 10.0.1.122
Address HWtype HWaddress Flags Mask Iface
10.0.1.122 ether 00:09:0f:88:da:76 C eth0.10
# netcfg -d Test
:: Test down [BUSY] Removed VLAN -:eth0.10:-
It could be refactored out, or setup like the wireless profile, which just calls ethernet. Long term, I suppose refactoring would be better for both wireless, ethernet and this - however for now, just calling ethernet (like wireless) would do fine.
If nobody else picks this up, I might merge another wave of patches in Jan/Feb sometime.
If this (as Thomas says) is possible with iproute and without vconfig, I'd prefer that.
James, how is it looking with the review? If you want me to pull a new batch of patches, please send me a request.
I needed to modify the vconfig plugin to allow for named vlan interfaces and a little more flexibility, and I have been using that for my production systems. I have only done some basic preliminary tests with this one, but if we can do it without vconfig, and if we can include interface naming I think that the vlan support would be much better overall. Here is a link to the vlan file:
http://enterprise-archlinux.googlecode.com/hg/netcfg-vlan/vlan
Like I said, I would like to test this more extensively, and I would like to clean up a few things, but I think that the two concepts I am working towards should shine through in the code.
1) Don't use ifconfig here, use ip.
2) The error message is copied from the bridge code, maybe fix it so it fits better.
I will have those changes done in a few days and give it ample testing, thanks for the feedback
I have tested this out on some of my qa servers, and it... works!
This should only require iproute, no vconfig and no ifconfig
We could talk about the following:
1) Could we provide a useful 'status' function?
2) Does the link checking work automatically (i.e., a link on the physical interface will show a link on the vlan)?
3) It probably needs a check whether VLAN_RAW_DEV and VLAN_ID are set. I am also thinking about naming: should VLAN_RAW_DEV be rather names VLAN_PHYSDEV, or VLAN_PHYS_DEV or so (not important, just a thought)?
3) VLAN_PHYSDEV / VLAN_PHYS_DEV would be better, as you can still have an IP on the phys-dev (making it a not-raw-dev). "Raw" should only be used if the underlying interface cannot be used itself anymore (which might never (vlan/briding/ppp...) happen, as far as i know)
the examples should look like that:
INTERFACE="eth0.11"
as this is the default notation. naming interfaces completely different should be upt to the user
if [ -e /sys/class/net/${INTERFACE_FROM_PROFILE} ]; then
echo "profile '${PROFILE}' active"
ip link show ${INTERFACE_FROM_PROFILE}
else
echo "profile '${PROFILE}' inactive"
fi
i should eventually open a new bug for that and let you pack that what we have into the next version ;)
The status function is intended as an internal function (as far as I can see) - a human-readable output should be generated by the frontend.
The only other thing to do is: you could prepare it as a patch using git, so you will be listed as author in the log.
Let me know if there is anything else I can to get this into netcfg