Hi, sorry for not replying to this sooner. On Thu, Jan 05, 2006 at 03:01:07PM -0500, Eric Maynard wrote: > Ok, > > I am going to warn you all up front although I am comfortable at > the Linux command line, I am by no means an expert and I am even > more of a newbie to VLANs and any networking more complicated than > layer 2 and Windows. Having said that, I consider myself a fast > learner and I'm willing to research what I need to know to > accomplish this. Goodie! > Here's the setup. I have just purchased a ProCurve 2626 to help me > manage my LAN a little better. Congratulations! I think this is by far the best switch in that segment. It does plenty VLANs and even ssh2 with public key auth! > What I want is to have a handful of VLANs and to utilize the switch > to control priority queuing of traffic (via 802.1Q) into and out of > these VLANs. My network setup is not much different than Peter > Stuge's diagram, but I do have extra layer I guess in my Firewall. > I also desire to use setup "1b" which Peter refers to as the "dirty > way" with only a single subnet behind the router. > > http://marc.theaimsgroup.com/?m=105098558615614. Maybe worded a bit harsh. I didn't like bridges much back then. > I currently use Shorewall to config the FW, but if need be I can > dig into iptables and learn it better if it would make things any > easier to setup VLAN support. Not VLAN support per se, but certainly to have the real deal control of your firewall rules. For home or testing I'd say shorewall is fine if you want to trust it, for production I would recommend learning iptables. It's not really difficult. You can pick up the basics from my suggested configuration, also I want to recommend the connection-tracking modules if you want to have stateful matching capabilities in your firewall. > What I am hoping the community can help me with is to confirm what > I need to be researching in order to make this work. I'm not > afraid to read documentation, but I just want to make sure I am > reading the correct ones. Suggested reading is the 802.1Q specification. It's not horribly long and pretty understandable with basic networking knowledge. http://standards.ieee.org/getieee802/download/802.1Q-2003.pdf As for prioritizing traffic in the Linux system based on the incoming user_priority field in the tagged traffic I can't give much advice since I haven't done this myself. > So, in order to make this work, my understanding is I need to have > tagged VLANs and a device that can route these tagged packets from > tagged VLAN to VLAN without losing the 802.1Q information. From > my research so far, it appears that the RH firewall I have should > be able to do this, assuming my NICs (Intel and 3Com) don't fumble > it in some way. Quite right. For the Intel NIC you can use the e100 or e1000 driver as appropriate to handle oversized packets on the VLAN trunk automatically and if you make this your internal NIC no further action is required. If you want 3Com as the internal NIC you have to patch the driver if the card is 100Mb/s and possibly also if the card is 1Gb/s but I don't know for certain in the latter case. > Questions I have not found answers to include: > > 1) How does a VLAN on the Linux FW translate to a VLAN on the switch? By using VIDs, VLAN IDs. You create virtual VLAN interfaces on the Linux system using vconfig and tell it which VID (1-4096) to have. The name of the virtual interface will be on the form of vlan0002, vlan2, eth0.0002 or eth0.2 depending on the vconfig set_name_type setting. When you create VLANs on the switch you also specify a VID between 1 and 4096. No translation occurs between these two domains of VIDs. Note however that you can have different VID domains in two networks connecting to different network ports in the Linux system which is why the eth0.xx virtual interface names are available. > 2) Will the Linux FW (box a) and the switch even "know" about each > other. Sort of, but not really. You have to configure the switch to send tagged packets on the port where the Linux box is connected. The tags are what 802.1Q standardizes and they contain the VID and priority information. On ProCurves this is configured per VLAN, for each you specify which ports will be members and speak untagged traffic (PCs, anything other than Linux and other VLAN-capable switches) and which ports are members and should have tagged traffic. (Linux system and other VLAN-capable switches) A port with only untagged traffic can of course only be a member of one VLAN. If something isn't working as you expect, check that you haven't reassigned the port by mistake. The Linux system doesn't have to be configured explicitly to support tagged traffic, this is done implicitly by creating the virtual VLAN interfaces. After running vconfig add eth0 2, Linux knows that eth0 will receive tagged packets and these packets will go through the 8021q code. > 3) Is Peter's bridging example at the link above enough for > inter-VLAN traffic or do I still need some routing commands on top > of this. It's more than enough. The commands include some access control for inter-VLAN-traffic that you may or may not want. Bridging eliminates need for routing per definition, so unless you want to make a brouter (system that bridges sometimes and routes sometimes) you don't need special routing at all. Depending on your IP addresses you may want some NAT to be done on traffic to internet, but if you have and want public IP address on all internal systems then that isn't needed either. The ip_forward setting is all that is needed to make Linux route packets between the connected networks. Now I'd suggest using the sysctl tool to do that setting instead, though: sysctl net.ipv4.ip_forward=1 > Sorry for such a long post and thanks for all your help in advance. No problems. :) On Thu, Jan 05, 2006 at 04:20:36PM -0500, Duane Mulder wrote: > Some HP procurves only support 30 VLANS tagged from 0-30. Silly but > true. We have a procurve that is like that. So when you setting up > your Vlan interfaces you will need to keep the VLAN tag number > below that. Just to confirm, some ProCurve switches do only support 30 VLANs but I can't say if they only support tags 1-30. According to the "Advanced Traffic Management Guide" for 2600, 2600-PWR, 2800, 4100 and 6108 ProCurve the 4100gl and 6108 support up to 30 VLANs, 2600 and 2600-PWR up to 253 VLANs and 2800 up to 256 VLANs. On the 2626 switches I've dealt with creating VLAN 1000 works just fine. Note that the ProCurve switches are configured to a maximum of eight VLANs by default. Increase that with the max-vlans CLI command. On Thu, Jan 05, 2006 at 11:31:05PM +0100, Roy-Magne Mo wrote: > The 2626 can have 255 vlans and use the full vlan-range. 253 according to my docs, but I guess they can be outdated. On Fri, Jan 06, 2006 at 08:01:01AM +0000, George Ross wrote: > Some switches limit you to 30 VLANs, but anything vaguely recent > will allow the full range of tags to be used. At the very least this is true for the 2626. On Fri, Jan 06, 2006 at 10:32:07AM -0500, Eric Maynard wrote: > Thanks to all of those who have replied. > > I have gathered quite a bit of research info and now I just need to > decide what I'm goging to do moving forward. > > I will try to post my notes here on this list once I do begin > implementation. Please! I'd be interested in more info about the prioritizing of traffic and how/if you configured the switch for that. //Peter
