Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
I've got a network in a single range of IP address (192.168.3.0/24) and I will create 5 vlan (I've got switches 3Com 4400).
Every PC use my gw (192.168.3.1) to reach the Internet.
How can my gw become the Vlan manager, to route traffic between different vlans?
Has anybody an experience in this domain?
For interested people, this link seems to be helpfull http://marc.theaimsgroup.com/?m=105098558615614
I read that I have to patch the kernel and use vconfig, but it seems that the module is experimental.
Last question : is it possible that one of the both network card can make troubles (unable to read tagged ip traffic for example)?
my experience with vconfig and 2.4.14 -> 2.6.x kernels has been all good and highly stable, and looks like the 3Com 4400's support port based 802.1q so you should have no problems setting this up - infact it's almost too easy
when you'll configure vlans, they will be considered by Linux as logical interfaces. Then enabling forwarding (echo 1 > /proc/sys/net/ipv4/ip_forward) will automatically enable routing between vlans. Last step using iptables to limit the different access.
Hi angrybeaver & fr_laz,
thx for u answers.
I will recompile my kernel and install these vlans.
I will create virtual interfaces for each vlan on my gw, but which IP@ have I to give to my eth0? (an IP @ of the vlan servers in which is gw?)
Has anybody info about this :
Is it possible that a network card can make troubles (unable to read tagged ip traffic for example)? Or : Can any network card be uncompatible with 8021Q?
as for eth0 config, you can do a ifconfig eth0 0.0.0.0, which will set up eth0 without giving it an IP... that's ok in your case since you'll use only the virtual interfaces.
as for hardaware that wouldn't support 802.1Q, I just don't know
Some questions :
eth0 0.0.0.0 with which netmask?
Can it be a hole of security?
I use slackware 10.0 (unofficial version because Serial ATA is supported on it) with kernel 2.4.26.
The last slackware is based on 2.4.29.
Do you think I should recompile my kernel (2.4.26), compile with 2.4.29 or compile with the last kernel from kernel.org (220.127.116.11)?
I've had a play with this and it works fine (on SUSE 9.0 at least).
Remember that 802.1q has what is known as a "native vlan" which is _not_ tagged. So basically your eth0 ip address represents the untagged or native vlan and anything that you shove into a sub-interface comes out tagged with the .x number.
Also don't forget that as the native vlan is untagged each device will be configured locally for what it thinks is the native vlan. By default they will all probably be vlan 0 but if you change one device remember to change em all or you will get very confused at a later date
I use kernel 2.4.26 and I saw that 8021Q was compiled as a module.
I just have to download vconfig with :
- export CVSROOT=server:firstname.lastname@example.org:/home/cvs/vlan
- cvs login (PASSWORD: anonymous)
- mkdir vlan; cd vlan; cvs -z3 checkout vlan
ifconfig eth0 0.0.0.0 will just deconfigure the IP on eth0, it doesn't need a netmask.
This wont disable you to use the eth0 on the network (but not eth0.x of course).
I think you did all things that you needed...
You're right if only the Linux box manages Vlans... but if they're defined on a switch, then the ethernet frames are tagged when they enter one of the switch's interfaces, and so one doesn't have to know in which vlan his workstation is.
I use 3COM 4400 on which I assign Vlan/port.
Ports of Vlan are untagged except for port on which my gw is connected to (one tag per vlan on the same port)
So traffic is tagged when it comes in gw, but not tagged for PCs on the same vlan.
I download, thx to cvs, last candelatech package for vlan, I just type 'make' and I get an error when trying to compile macvlan_config.c. It comes from the if_macvlan.h which is not found (on /root/linux/include by default, and with 'locate' no more if_macvlan.h was found)
Does anybody get this error? I found nothing interesting on google.
It's not really a pbl because vconfig is now OK, but I don't like get errors when compiling...
fr_laz , what you are talking about is implicit tagging associated with a member port, which is not what you want here.
If you are running tagged interfaces on your linux box then the switch interface you connect to must be configured to be an 802.1q trunk.
If you leave it as a member port then any tagged packets you send the port will be discarded as errors and only the native untagged traffic you send will be accepted and then implicitly tagged by the switch as being in the vlan the port is a member of.