Nice explanation - can I ask what firewall you use with this setup? I've got
a SonicWall Pro 2040 and looking at the ProCurve 2810's to do a similar
setup.

 - Andy O.

>-----Original Message-----
>From: Ben Scott [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, December 09, 2008 7:39 PM
>To: NT System Admin Issues
>Subject: VLAN concepts and applications
>
>  Someone asked me off-list for an explanation of some VLAN stuff.
>They agreed to let me post my response to the list, for discussion,
>review, etc.  If anyone has corrections/additions/etc., please
>contribute.
>
>PROTOCOL CONCEPTS
>
>  We have regular "untagged" Ethernet frames.  ("Frame" is the
>data-link (layer 2) term for what some protocols calls a "packet" or
>"datagram".)  These are the same Ethernet frames from before VLANs
>were invented.
>
>  Then we have "tagged" frames.  These take a regular Ethernet frame
>and add a marker -- the "tag".  The tag itself contains the VLAN
>number (along with a priority code).  Thus, a tagged frame is
>associated with a particular VLAN number.
>
>    Inside the frame, the tag is basically just a reserved Ethernet
>frame type, followed by the tag information, followed by the rest of
>the original frame (complete with its original frame type).  So to
>network nodes which are *not* VLAN aware, a tagged frame looks just
>like a regular Ethernet frame, but with an "unknown" frame type.
>
>  For computers, a VLAN-aware network stack will usually turn each
>VLAN into a separate network interface, as if each VLAN was a
>different network card with a different cable.  The "stock" network
>stack included with Win 2000/XP does *not* include VLAN capability, so
>they can only handle untagged frames.  Tagged frames will generally be
>silently ignored.  Third-party software (often included with high-end
>network cards) can add VLAN capability.  I'm not sure about
>2003/Vista/2008.
>
>    Switches which are not VLAN-aware, along with any repeaters, will
>treat tagged frames exactly like they do any other frame.
>
>SWITCH CONCEPTS
>
>  Switches which are VLAN-aware generally let you control which ports
>are associated with which VLAN(s).  The terminology, commands, etc.,
>will vary with manufacturer.  I'm most familiar with the HP ProCruve
>managed witches, so I'll speak mostly to that.  The concepts should
>carry over to other manufacturers.  Hopefully others can chime in with
>specifics.
>
>  With HP, you can tell the switch that each VLAN is tagged, untagged,
>or not available for each port.  Internally, frames are *always*
>associated a VLAN number.  The configuration just tells the switch
>which VLANs go with which ports, and which VLAN number to use for
>untagged frames.
>
>  When the switch receives an untagged frame, it needs to know what
>VLAN to associate it with.  If the port has an untagged VLAN
>associated it, the fame will go to that VLAN.  If there is no untagged
>VLAN associated with the port, the frame is dropped.  This is why a
>port can have (at most) one untagged VLAN associated with it -- how
>could the switch know which one to use otherwise?
>
>  When the switch receives a tagged frame, it simply checks to see if
>that VLAN is associated with the port.  If so, it accepts it; if not,
>it drops it.  This is basically just an access control mechanism.
>
>  When the switch has a frame to *transmit*, it only considers ports
>which are associated with the frame's VLAN.  If a port is configured
>as tagged for the frame's VLAN, it transmits the frame with the VLAN
>tag.  If a port is configured as untagged for the VLAN, the frame is
>transmitted on that port without a VLAN tag.
>
>APPLICATIONS
>
>  Okay, enough conceptual stuff, how do we use it?
>
>  At %DAYJOB%, we've got VLANs as follows:
>
>1 - Reserved
>2 - Main company private network
>3 - Guest network
>4 - ISP uplink
>5 - IP telephony
>
>  We don't use VLAN 1 because that's the default on most things, and
>to avoid confusion we avoid it.
>
>  VLAN 2 is where most traffic is.  Most ports are configured as
>untagged for VLAN 2.  The computers, printers, etc., plugged into
>those ports aren't even aware they are on a VLAN.  All the employee
>workstations are like this, as are most servers.  The syntax to
>configure this is easy.  For example, if I want port 1 to be untagged
>for VLAN 2 like this:
>
>       vlan 2 untagged 1
>
>  VLAN 3 is for guests (visitors).  For obvious reasons, we don't let
>them plug in to our main network.  They get a separate IP subnet, a
>separate DHCP server, and bypass much of our network filtering.  This
>is also where our wireless access points connect (employees use
>VPN-over-wireless).  Again, all untagged, and connected nodes are not
>aware of the VLAN.
>
>  VLAN 4 exists because we've got a cable Internet feed we use for
>employee web browsing.  Circumstances meant the cable modem had to go
>in a different building from the main server/network room.  (We have
>another feed for important stuff; that terminates in the server room.)
> So the cable modem plugs into a particular switch port, which uses
>VLAN 4 to carry it to our firewall in a different building.  Again,
>untagged, unaware.
>
>  VLAN 5 is for premises voice-over-IP, a project which I'm still in
>the middle of.  My plan is to let the phones be VLAN-aware and tagged
>everywhere, so they operate "outside" the regular network.  In theory,
>it should be possible to have a phone tagged on VLAN 5 and a computer
>untagged on VLAN 2, both on the same port, as follows (example uses
>port 7):
>
>       vlan 2 untagged 7
>       vlan 5 tagged 7
>
>  I am using separate VLANs for security, manageability, and
>robustness.  I don't want guests to be able to probe/sniff/screw-up
>the corporate network.  They can't.  I don't want the cable modem link
>(which is full of garbage traffic from other subscribers) on the main
>LAN.  It isn't.  I want the phones to have higher priority over
>regular data, and to have their own DHCP server.  Haven't got that far
>yet on that one.  :)
>
>  For links between switches, each VLAN is configured as *tagged* for
>those ports, with *no* untagged VLAN.  Those ports are only used to
>carry traffic between VLAN-aware switches.  (Cisco would call this a
>"trunk port", IIRC.)  The HP syntax for (e.g.) port 24 as a switch
>link would be:
>
>       vlan 2 tagged 24
>       vlan 3 tagged 24
>       vlan 4 tagged 24
>       vlan 5 tagged 24
>
>  Finally, our firewall, which *is* VLAN-aware, is configured as
>tagged for all VLANs on its port, with no untagged VLAN.  Virtual
>network interfaces are configured in the firewall OS, and all the IP
>configuration and filtering rules are done with those virtual
>interfaces, not the physical interface.  This also means our firewall
>only has one network cable plugged into it.  Configures the same as a
>switch link, really.
>
>  Hope this helps someone!
>
>~ Finally, powerful endpoint security that ISN'T a resource hog! ~
>~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~


~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

Reply via email to