Technical wiki updates
Debian installation notes
ins.insert { background-color: #AFA; color: #080; text-decoration: inherit; }
del.delete { background-color: #F88; color: #800; text-decoration: inherit; }
...aptitude install acct apt-show-versions at bc bind9-host bzip2 deborphan \
debsums file ftp isag less logwatch lsof lsscsi ltrace make openssl patch \
... psmisc rsync screen ssh strace... subversion sysvconfig telnet \
time
telnet time vim
Purge exim config:
aptitude purge exim4 exim4-base exim4-config exim4-daemon-light
debsums file ftp isag less logwatch lsof lsscsi ltrace make openssl patch \
... psmisc rsync screen ssh strace... subversion sysvconfig telnet \
time
telnet time vim
Purge exim config:
aptitude purge exim4 exim4-base exim4-config exim4-daemon-light
Major distributions
ins.insert { background-color: #AFA; color: #080; text-decoration: inherit; }
del.delete { background-color: #F88; color: #800; text-decoration: inherit; }
...If you have an existing investment in Novell NetWare that you want to preserve or integrate with, one of SUSE's distributions should be your first choice.
If you have experience with Red Hat products that you want to utilise, you should use one of their distributions.
... Server (SLES) 10.10). These "Enterprise"
Debian over OpenSUSE
OpenSUSE over SLES
...Linux distribution chooser
Steven J. Vaughan-Nichols on choosing a distribution
The Register's distribution guide
If you have experience with Red Hat products that you want to utilise, you should use one of their distributions.
... Server (SLES) 10.10). These "Enterprise"
Debian over OpenSUSE
OpenSUSE over SLES
...Linux distribution chooser
Steven J. Vaughan-Nichols on choosing a distribution
The Register's distribution guide
device-based VLANs
ins.insert { background-color: #AFA; color: #080; text-decoration: inherit; }
del.delete { background-color: #F88; color: #800; text-decoration: inherit; }
...ip igmp
exit
DHCP server
Here's an example snippet from /etc/dhcpd.conf for VLAN 1003 using the ISC DHCP server:
subnet 10.10.3.0 netmask 255.255.255.0 {
option routers 10.10.3.1;
option broadcast-address 10.10.3.255;
range 10.10.3.32 10.10.3.254;
option subnet-mask 255.255.255.0;
}
Procedures
Adding a new edge VLAN
exit
DHCP server
Here's an example snippet from /etc/dhcpd.conf for VLAN 1003 using the ISC DHCP server:
subnet 10.10.3.0 netmask 255.255.255.0 {
option routers 10.10.3.1;
option broadcast-address 10.10.3.255;
range 10.10.3.32 10.10.3.254;
option subnet-mask 255.255.255.0;
}
Procedures
Adding a new edge VLAN
device-based VLANs
ins.insert { background-color: #AFA; color: #080; text-decoration: inherit; }
del.delete { background-color: #F88; color: #800; text-decoration: inherit; }
...Create VLAN in edge switch; assign relevant ports (commonly, this is all except one uplink port)
Restart PCs & printers in edge switch to get new IP addresses
Adjust print server and restart printer agent (if necessary) to reflect new printer IP address
Restart PCs & printers in edge switch to get new IP addresses
Adjust print server and restart printer agent (if necessary) to reflect new printer IP address
device-based VLANs
ins.insert { background-color: #AFA; color: #080; text-decoration: inherit; }
del.delete { background-color: #F88; color: #800; text-decoration: inherit; }
...ip igmp
exit
Procedures
Adding a new edge VLAN
Ensure printers in edge switch are set to DHCP
Create VLAN in core switch
Create VLAN in DHCP server; restart DHCP server
Create VLAN in edge switch; assign relevant ports (commonly, this is all except one uplink port)
Restart PCs & printers in edge switch to get new IP addresses
exit
Procedures
Adding a new edge VLAN
Ensure printers in edge switch are set to DHCP
Create VLAN in core switch
Create VLAN in DHCP server; restart DHCP server
Create VLAN in edge switch; assign relevant ports (commonly, this is all except one uplink port)
Restart PCs & printers in edge switch to get new IP addresses
device-based VLANs
ins.insert { background-color: #AFA; color: #080; text-decoration: inherit; }
del.delete { background-color: #F88; color: #800; text-decoration: inherit; }
...name "your VLAN name here"
untagged 1-20 # edge VLAN ports
tagged 21-2423-24 # uplink/downlink ports (to managed switches)
ip address 10.10.3.9 255.255.255.0 10.10.3.9/24
ip igmp
exit
Here's an example of a couple of port-based edge VLANs for the same edge switch:
vlan 1101
name "your VLAN name here"
untagged 21 # downlink to the unmanaged switch
ip address 10.11.1.9/24
ip igmp
exit
vlan 1125
name "your VLAN name here"
untagged 22 # downlink to the unmanaged switch
ip address 10.11.25.9/24
ip igmp
exit
untagged 1-20 # edge VLAN ports
tagged 21-2423-24 # uplink/downlink ports (to managed switches)
ip address 10.10.3.9 255.255.255.0 10.10.3.9/24
ip igmp
exit
Here's an example of a couple of port-based edge VLANs for the same edge switch:
vlan 1101
name "your VLAN name here"
untagged 21 # downlink to the unmanaged switch
ip address 10.11.1.9/24
ip igmp
exit
vlan 1125
name "your VLAN name here"
untagged 22 # downlink to the unmanaged switch
ip address 10.11.25.9/24
ip igmp
exit
device-based VLANs
ins.insert { background-color: #AFA; color: #080; text-decoration: inherit; }
del.delete { background-color: #F88; color: #800; text-decoration: inherit; }
...IP ranges within the switch VLAN subnet are:
10.10.xx.1: core switch
... IP addresses (when(if VRRP is... switches, .1 will becomeshould be the floating IP gateway address,... core switch willshould have its own individual address in
10.10.xx.9: edge switch
10.10.xx.10-31: reserved for fixed IP address devices (sometimes called DHCP reservations) which may need to be present on each switch. Printers in the edge VLAN are allocated starting at .31 and working down towards .10. (Unless you have an unusually high ratio of printers to PCs, it's unlikely you'll even reach .20 using this scheme.)
10.10.xx.1: core switch
... IP addresses (when(if VRRP is... switches, .1 will becomeshould be the floating IP gateway address,... core switch willshould have its own individual address in
10.10.xx.9: edge switch
10.10.xx.10-31: reserved for fixed IP address devices (sometimes called DHCP reservations) which may need to be present on each switch. Printers in the edge VLAN are allocated starting at .31 and working down towards .10. (Unless you have an unusually high ratio of printers to PCs, it's unlikely you'll even reach .20 using this scheme.)
device-based VLANs
ins.insert { background-color: #AFA; color: #080; text-decoration: inherit; }
del.delete { background-color: #F88; color: #800; text-decoration: inherit; }
...This document explains some of my recent experience in rolling out device-based (or location-based) VLANs.
Environment
... medium-sized educational institution.institution with approximately 70 ProCurve managed switches. Many of thethese guidelines will
Goal
The goal of using device-based VLANs is to ensure that all client devices (desktop PCs, wireless laptops, printers, or whatever) are isolated from the VLAN which contains servers, switches, and other core network infrastructure.
...Port membership
Uplink ports for edge switches are untagged on the default VLAN.
Every non-uplink port in an edge switch is untagged in that switch's edge VLAN.
GVRP is used to manage edge VLAN tagging on all managed switch uplink ports.
Every non-uplink port in an edge switch is untagged in that switch's VLAN.
AreasAreas which are still allocated onconnected via unmanaged switches... own dedicated VLAN range, and theedge VLAN. The uplink of... is untagged in thaton the edge VLAN in... managed switch to which it connects to.connects.
Numbering standards
The edge VLAN IDs used are all infor managed switches use the range 10xx. This(This means that... adhere to the samesimilar numbering standards.standards.)
The edge VLAN IDs for unmanaged switches use the range 11xx. Numbering of port-based VLANs follows a similar scheme to that of device-based VLANs. However, there is no edge switch management IP in this case (because a managed switch could have multiple edge VLANs for unmanaged switches), so VLAN IDs are simply allocated starting from 1.
Each switch has a management IP address on the default VLAN which corresponds to the final 2 digits of its VLAN number. It also has an IP address on its own VLAN, ending in .9.
The core switch IP address in each VLAN ends in .1.
The IP address range used by end-user devices on the VLAN corresponds to the VLAN ID.
... example of thethese numbering standards
VLAN ID: 1039
Management IP of edge switch: 10.0.10.39
...VLAN IP address of core switch: 10.10.39.1
(Note that this VLAN numbering scheme means that each VLAN is limited to 254 devices. In most cases this is desirable from a performance perspective anyway.)
Numbering of port-based VLANs follows a similar scheme to that of device-based VLANs. In this configuration, the VLAN ID range is 11xx, and all other aspects of the numbering scheme follow suit. There is no edge switch management IP in this case, so VLAN IDs are simply allocated starting from 1.
The 0 and 255 subnet ids are avoided normally, although there is no technical reason why they should not be used.
IP ranges within the switch VLAN subnet are:
10.10.xx.1: core switch
... IP addresses (when VRRP is implemented in the core switches, .1 will become the gateway address, and each core switch will have its own address in the range .2-8)
10.10.xx.9: edge switch
10.10.xx.10-63:10.10.xx.10-31: reserved for core networkfixed IP address devices (sometimes called DHCP reservations) which may... on each switch
10.10.xx.64-127: fixed IP address allocations in the switch VLAN; printersswitch. Printers in the... starting at .127.31 and working down towards .64. (Unless.10. (Unless you have... even reach .100.20 using this scheme.)
10.10.xx.128-254:
10.10.xx.32-254: dynamic IP... the switch VLANVLAN.
Miscellaneous notes
The edge switch's IP address in the VLAN is not used for normal operational running; all routing is done through the core switch, and it is the default gateway for all the PCs. However, it is configured to provide a troubleshooting reference point: if that address is pingable, then GVRP configuration of all uplink ports has succeeded.
...ip helper-address 10.0.0.yy
ip helper-address 10.0.0.zz
... 5151 # this is to forward UDP... Control from the edge VLAN 1003 to the
ip address 10.10.3.1 255.255.255.0
tagged Trk3Trk1 # this is the main trunk to the other core infrastructureswitch
# it... used as a tagan indicator to show
ip igmp
exit
...vlan 1003
name "your VLAN name here"
untagged 1-20 # edge VLAN ports
tagged 21-24 # uplink/downlink ports
ip address 10.10.3.9 255.255.255.0
ip igmp
Environment
... medium-sized educational institution.institution with approximately 70 ProCurve managed switches. Many of thethese guidelines will
Goal
The goal of using device-based VLANs is to ensure that all client devices (desktop PCs, wireless laptops, printers, or whatever) are isolated from the VLAN which contains servers, switches, and other core network infrastructure.
...Port membership
Uplink ports for edge switches are untagged on the default VLAN.
Every non-uplink port in an edge switch is untagged in that switch's edge VLAN.
GVRP is used to manage edge VLAN tagging on all managed switch uplink ports.
Every non-uplink port in an edge switch is untagged in that switch's VLAN.
AreasAreas which are still allocated onconnected via unmanaged switches... own dedicated VLAN range, and theedge VLAN. The uplink of... is untagged in thaton the edge VLAN in... managed switch to which it connects to.connects.
Numbering standards
The edge VLAN IDs used are all infor managed switches use the range 10xx. This(This means that... adhere to the samesimilar numbering standards.standards.)
The edge VLAN IDs for unmanaged switches use the range 11xx. Numbering of port-based VLANs follows a similar scheme to that of device-based VLANs. However, there is no edge switch management IP in this case (because a managed switch could have multiple edge VLANs for unmanaged switches), so VLAN IDs are simply allocated starting from 1.
Each switch has a management IP address on the default VLAN which corresponds to the final 2 digits of its VLAN number. It also has an IP address on its own VLAN, ending in .9.
The core switch IP address in each VLAN ends in .1.
The IP address range used by end-user devices on the VLAN corresponds to the VLAN ID.
... example of thethese numbering standards
VLAN ID: 1039
Management IP of edge switch: 10.0.10.39
...VLAN IP address of core switch: 10.10.39.1
(Note that this VLAN numbering scheme means that each VLAN is limited to 254 devices. In most cases this is desirable from a performance perspective anyway.)
Numbering of port-based VLANs follows a similar scheme to that of device-based VLANs. In this configuration, the VLAN ID range is 11xx, and all other aspects of the numbering scheme follow suit. There is no edge switch management IP in this case, so VLAN IDs are simply allocated starting from 1.
The 0 and 255 subnet ids are avoided normally, although there is no technical reason why they should not be used.
IP ranges within the switch VLAN subnet are:
10.10.xx.1: core switch
... IP addresses (when VRRP is implemented in the core switches, .1 will become the gateway address, and each core switch will have its own address in the range .2-8)
10.10.xx.9: edge switch
10.10.xx.10-63:10.10.xx.10-31: reserved for core networkfixed IP address devices (sometimes called DHCP reservations) which may... on each switch
10.10.xx.64-127: fixed IP address allocations in the switch VLAN; printersswitch. Printers in the... starting at .127.31 and working down towards .64. (Unless.10. (Unless you have... even reach .100.20 using this scheme.)
10.10.xx.128-254:
10.10.xx.32-254: dynamic IP... the switch VLANVLAN.
Miscellaneous notes
The edge switch's IP address in the VLAN is not used for normal operational running; all routing is done through the core switch, and it is the default gateway for all the PCs. However, it is configured to provide a troubleshooting reference point: if that address is pingable, then GVRP configuration of all uplink ports has succeeded.
...ip helper-address 10.0.0.yy
ip helper-address 10.0.0.zz
... 5151 # this is to forward UDP... Control from the edge VLAN 1003 to the
ip address 10.10.3.1 255.255.255.0
tagged Trk3Trk1 # this is the main trunk to the other core infrastructureswitch
# it... used as a tagan indicator to show
ip igmp
exit
...vlan 1003
name "your VLAN name here"
untagged 1-20 # edge VLAN ports
tagged 21-24 # uplink/downlink ports
ip address 10.10.3.9 255.255.255.0
ip igmp
SpamAssassin
ins.insert { background-color: #AFA; color: #080; text-decoration: inherit; }
del.delete { background-color: #F88; color: #800; text-decoration: inherit; }
Distributing a standardised config file with puppet
killing me softly
ins.insert { background-color: #AFA; color: #080; text-decoration: inherit; }
del.delete { background-color: #F88; color: #800; text-decoration: inherit; }
...kill -KILL (a.k.a. -9)
The only thing that can ignore a KILL signal is I/O. If your process still won't die when you use KILL, there is often no option but to reboot the system. This is one of my pet peeves about Linux.
Template
Here's a bash function to do the job:
kill_softly()
{
for sig in TERM HUP INT QUIT PIPE KILL; do
echo "kill -$sig $@"
if ! kill -$sig "$@"; then
# the kill command failed - this usually means that the process is now dead
break
fi
sleep 2
done
}
The only thing that can ignore a KILL signal is I/O. If your process still won't die when you use KILL, there is often no option but to reboot the system. This is one of my pet peeves about Linux.
Template
Here's a bash function to do the job:
kill_softly()
{
for sig in TERM HUP INT QUIT PIPE KILL; do
echo "kill -$sig $@"
if ! kill -$sig "$@"; then
# the kill command failed - this usually means that the process is now dead
break
fi
sleep 2
done
}
killing me softly
ins.insert { background-color: #AFA; color: #080; text-decoration: inherit; }
del.delete { background-color: #F88; color: #800; text-decoration: inherit; }
...or, how to be as gentle as possible when killing a Linux/Unix process
I recommend kills in this order, with a short delay between each:
kill -TERM: same-TERM (same as kill
kill -HUP (same as closing the window)
kill -INT (same as Ctrl-C)
I recommend kills in this order, with a short delay between each:
kill -TERM: same-TERM (same as kill
kill -HUP (same as closing the window)
kill -INT (same as Ctrl-C)
killing me softly
ins.insert { background-color: #AFA; color: #080; text-decoration: inherit; }
del.delete { background-color: #F88; color: #800; text-decoration: inherit; }
or, how to be as gentle as possible when killing a Linux/Unix process
I recommend kills in this order, with a short delay between each:
kill -TERM: same as kill without an argument)
kill -HUP (same as closing the window)
kill -INT (same as Ctrl-C)
kill -QUIT (same as Ctrl-\)
kill -PIPE (same as quitting the program you've piped it into, e.g. less)
kill -KILL (a.k.a. -9)
The only thing that can ignore a KILL signal is I/O. If your process still won't die when you use KILL, there is often no option but to reboot the system. This is one of my pet peeves about Linux.
or, how to be as gentle as possible when killing a Linux/Unix process
I recommend kills in this order, with a short delay between each:
kill -TERM: same as kill without an argument)
kill -HUP (same as closing the window)
kill -INT (same as Ctrl-C)
kill -QUIT (same as Ctrl-\)
kill -PIPE (same as quitting the program you've piped it into, e.g. less)
kill -KILL (a.k.a. -9)
The only thing that can ignore a KILL signal is I/O. If your process still won't die when you use KILL, there is often no option but to reboot the system. This is one of my pet peeves about Linux.
Cheat sheets
ins.insert { background-color: #AFA; color: #080; text-decoration: inherit; }
del.delete { background-color: #F88; color: #800; text-decoration: inherit; }
...fdisk
GRUB
killing me softly
MySQL basics
NUT - Network UPS Tools
GRUB
killing me softly
MySQL basics
NUT - Network UPS Tools
About this wiki
ins.insert { background-color: #AFA; color: #080; text-decoration: inherit; }
del.delete { background-color: #F88; color: #800; text-decoration: inherit; }
... the focus. If you're interested in exploring Linux, you might want
This wiki would not exist without the kind support of my clients, some of whom have paid for the time to start withdevelop the notes on major distributions.procedures and their documentation which can be found here. My thanks is extended to them.
You can contact me about anything here at my company's home page. If you'd like to keep up-to-date with changes to this wiki, you can subscribe to the RSS feed.
Please note that the advertising on this wiki is in no way endorsed or checked by myself. Following the links will help to support Wikispaces, the free provider of infrastructure for this wiki.
This wiki would not exist without the kind support of my clients, some of whom have paid for the time to start withdevelop the notes on major distributions.procedures and their documentation which can be found here. My thanks is extended to them.
You can contact me about anything here at my company's home page. If you'd like to keep up-to-date with changes to this wiki, you can subscribe to the RSS feed.
Please note that the advertising on this wiki is in no way endorsed or checked by myself. Following the links will help to support Wikispaces, the free provider of infrastructure for this wiki.
Creating a cron job with puppet
ins.insert { background-color: #AFA; color: #080; text-decoration: inherit; }
del.delete { background-color: #F88; color: #800; text-decoration: inherit; }
...class remote_office_server {
...
include avupdateavupdates
...
}
...
include avupdateavupdates
...
}
Creating a cron job with puppet
ins.insert { background-color: #AFA; color: #080; text-decoration: inherit; }
del.delete { background-color: #F88; color: #800; text-decoration: inherit; }
...Puppet has a built-in mechanism for managing cron jobs which edits root's crontab automatically. I've never been a fan of individual user crontabs, and especially not root's, since it is so error-prone and easy to make a mess of it. Adding puppet to the mix makes it worse, because you can't really have puppet-managed and non-puppet-managed jobs in the same crontab.
Solution
... be moved elsewhere):elsewhere). This creates separate files for each cron job, with the penalty that it requires Linux's Vixie cron daemon. Since i'm not really interested in other server platforms, this seems like a reasonable compromise to obtain better flexibility and separation.
# manage cron jobs in separate files - call with enable => "false" to delete the job
define cron_job( $enable = "true", $interval = "daily", $script = "", $package = "" ) {
Solution
... be moved elsewhere):elsewhere). This creates separate files for each cron job, with the penalty that it requires Linux's Vixie cron daemon. Since i'm not really interested in other server platforms, this seems like a reasonable compromise to obtain better flexibility and separation.
# manage cron jobs in separate files - call with enable => "false" to delete the job
define cron_job( $enable = "true", $interval = "daily", $script = "", $package = "" ) {
device-based VLANs
ins.insert { background-color: #AFA; color: #080; text-decoration: inherit; }
del.delete { background-color: #F88; color: #800; text-decoration: inherit; }
...10.10.xx.9: edge switch
10.10.xx.10-63: reserved for core network devices which may need to be present on each switch
... the switch VLAN; printers in the edge VLAN are allocated starting at .127 and working down towards .64. (Unless you have an unusually high ratio of printers to PCs, it's unlikely you'll even reach .100 using this scheme.)
10.10.xx.128-254: dynamic IP address allocations in the switch VLAN
Miscellaneous notes
10.10.xx.10-63: reserved for core network devices which may need to be present on each switch
... the switch VLAN; printers in the edge VLAN are allocated starting at .127 and working down towards .64. (Unless you have an unusually high ratio of printers to PCs, it's unlikely you'll even reach .100 using this scheme.)
10.10.xx.128-254: dynamic IP address allocations in the switch VLAN
Miscellaneous notes
device-based VLANs
ins.insert { background-color: #AFA; color: #080; text-decoration: inherit; }
del.delete { background-color: #F88; color: #800; text-decoration: inherit; }
...Introduction
This document explains some of my recent experience in rolling out device-based (or location-based) VLANs.
Environment
This VLAN strategy has been implemented in a medium-sized educational institution. Many of the guidelines will apply to other sites, but your requirements may dictate a different approach. The examples given are for an HP ProCurve 2824 edge switch, and a 5400xl core switch.
Goal
The goal of using device-based VLANs is to ensure that all client devices (desktop PCs, wireless laptops, printers, or whatever) are isolated from the VLAN which contains servers, switches, and other core network infrastructure.
Definitions
core switch: a higher-throughput switch which connects servers, storage, and other infrastructure. No end-user devices are plugged into the core switch.
edge switch: a switch which connects end-user devices.
edge VLAN: a VLAN which is defined for an individual edge switch. Every edge switch has its own VLAN.
Setup
General
All edge switch management addresses are on the default VLAN, which has IP address range 10.0.0.0/16.
Routing between VLANs is done in the core switch. The core switch has IP routing turned on, and an IP address on each VLAN.
The core switch has DHCP relay enabled with option 82 turned on. The core switch forwards all DHCP requests to a DHCP server on the default VLAN.
The DHCP server has a network range for each VLAN defined. The ISC DHCP server will automatically give out addresses in these ranges if it receives a DHCP request via a relay in that range.
Port membership
Uplink ports for edge switches are untagged on the default VLAN.
GVRP is used to manage edge VLAN tagging on all managed switch uplink ports.
Every non-uplink port in an edge switch is untagged in that switch's VLAN.
Areas which are still allocated on unmanaged switches receive their own dedicated VLAN range, and the uplink of the unmanaged switch is untagged in that VLAN in the managed switch it connects to.
Numbering standards
The VLAN IDs used are all in the range 10xx. This means that we are limited to 99 VLANs in this range, but it is possible to go further than that and still adhere to the same numbering standards.
Each switch has a management IP address on the default VLAN which corresponds to the final 2 digits of its VLAN number. It also has an IP address on its own VLAN, ending in .9.
The core switch IP address in each VLAN ends in .1.
The IP address range used by end-user devices on the VLAN corresponds to the VLAN ID.
Here's a complete example of the numbering standards in action:
VLAN ID: 1039
Management IP of edge switch: 10.0.10.39
IP range of VLAN: 10.10.39.0/24
VLAN IP address of edge switch: 10.10.39.9
VLAN IP address of core switch: 10.10.39.1
(Note that this VLAN numbering scheme means that each VLAN is limited to 254 devices. In most cases this is desirable from a performance perspective anyway.)
Numbering of port-based VLANs follows a similar scheme to that of device-based VLANs. In this configuration, the VLAN ID range is 11xx, and all other aspects of the numbering scheme follow suit. There is no edge switch management IP in this case, so VLAN IDs are simply allocated starting from 1.
The 0 and 255 subnet ids are avoided normally, although there is no technical reason why they should not be used.
IP ranges within the switch VLAN subnet are:
10.10.xx.1: core switch
10.10.xx.2-8: reserved for future switch IP addresses
10.10.xx.9: edge switch
10.10.xx.10-63: reserved for core network devices which may need to be present on each switch
10.10.xx.64-127: fixed IP address allocations in the switch VLAN
10.10.xx.128-254: dynamic IP address allocations in the switch VLAN
Miscellaneous notes
The edge switch's IP address in the VLAN is not used for normal operational running; all routing is done through the core switch, and it is the default gateway for all the PCs. However, it is configured to provide a troubleshooting reference point: if that address is pingable, then GVRP configuration of all uplink ports has succeeded.
Configuration examples
Core switch
Here's the core switch base config (required once for all VLANs):
max-vlans 250 # you might need more than this, depending on your switch setup
ip routing # enable routing between VLANs
ip udp-bcast-forward # enable "ip forward-protocol udp" commands in each VLAN
dhcp-relay option 82 replace ip # enable DHCP option 82 for "ip helper-address" in each VLAN
# NOTE: this assumes there are no other DHCP relays in the network
Here's the core switch (HP ProCurve 5400xl) config for an edge VLAN (ID 1003):
vlan 1003
name "your VLAN name here"
ip helper-address 10.0.0.xx # put your DHCP & PXE servers in this list
ip helper-address 10.0.0.yy
ip helper-address 10.0.0.zz
ip forward-protocol udp 10.0.255.255 5151 # this is to forward UDP broadcasts for AB Tutor Control from VLAN 1003 to the default VLAN
ip address 10.10.3.1 255.255.255.0
tagged Trk3 # this is the main trunk to other core infrastructure
# it is not required, but used as a tag to show that the VLAN exists on this switch
ip igmp
exit
Edge switch
Here's the edge switch (HP ProCurve 2824) config for the same edge VLAN:
vlan 1003
name "your VLAN name here"
untagged 1-20
tagged 21-24
ip address 10.10.3.9 255.255.255.0
ip igmp
exit
This document explains some of my recent experience in rolling out device-based (or location-based) VLANs.
Environment
This VLAN strategy has been implemented in a medium-sized educational institution. Many of the guidelines will apply to other sites, but your requirements may dictate a different approach. The examples given are for an HP ProCurve 2824 edge switch, and a 5400xl core switch.
Goal
The goal of using device-based VLANs is to ensure that all client devices (desktop PCs, wireless laptops, printers, or whatever) are isolated from the VLAN which contains servers, switches, and other core network infrastructure.
Definitions
core switch: a higher-throughput switch which connects servers, storage, and other infrastructure. No end-user devices are plugged into the core switch.
edge switch: a switch which connects end-user devices.
edge VLAN: a VLAN which is defined for an individual edge switch. Every edge switch has its own VLAN.
Setup
General
All edge switch management addresses are on the default VLAN, which has IP address range 10.0.0.0/16.
Routing between VLANs is done in the core switch. The core switch has IP routing turned on, and an IP address on each VLAN.
The core switch has DHCP relay enabled with option 82 turned on. The core switch forwards all DHCP requests to a DHCP server on the default VLAN.
The DHCP server has a network range for each VLAN defined. The ISC DHCP server will automatically give out addresses in these ranges if it receives a DHCP request via a relay in that range.
Port membership
Uplink ports for edge switches are untagged on the default VLAN.
GVRP is used to manage edge VLAN tagging on all managed switch uplink ports.
Every non-uplink port in an edge switch is untagged in that switch's VLAN.
Areas which are still allocated on unmanaged switches receive their own dedicated VLAN range, and the uplink of the unmanaged switch is untagged in that VLAN in the managed switch it connects to.
Numbering standards
The VLAN IDs used are all in the range 10xx. This means that we are limited to 99 VLANs in this range, but it is possible to go further than that and still adhere to the same numbering standards.
Each switch has a management IP address on the default VLAN which corresponds to the final 2 digits of its VLAN number. It also has an IP address on its own VLAN, ending in .9.
The core switch IP address in each VLAN ends in .1.
The IP address range used by end-user devices on the VLAN corresponds to the VLAN ID.
Here's a complete example of the numbering standards in action:
VLAN ID: 1039
Management IP of edge switch: 10.0.10.39
IP range of VLAN: 10.10.39.0/24
VLAN IP address of edge switch: 10.10.39.9
VLAN IP address of core switch: 10.10.39.1
(Note that this VLAN numbering scheme means that each VLAN is limited to 254 devices. In most cases this is desirable from a performance perspective anyway.)
Numbering of port-based VLANs follows a similar scheme to that of device-based VLANs. In this configuration, the VLAN ID range is 11xx, and all other aspects of the numbering scheme follow suit. There is no edge switch management IP in this case, so VLAN IDs are simply allocated starting from 1.
The 0 and 255 subnet ids are avoided normally, although there is no technical reason why they should not be used.
IP ranges within the switch VLAN subnet are:
10.10.xx.1: core switch
10.10.xx.2-8: reserved for future switch IP addresses
10.10.xx.9: edge switch
10.10.xx.10-63: reserved for core network devices which may need to be present on each switch
10.10.xx.64-127: fixed IP address allocations in the switch VLAN
10.10.xx.128-254: dynamic IP address allocations in the switch VLAN
Miscellaneous notes
The edge switch's IP address in the VLAN is not used for normal operational running; all routing is done through the core switch, and it is the default gateway for all the PCs. However, it is configured to provide a troubleshooting reference point: if that address is pingable, then GVRP configuration of all uplink ports has succeeded.
Configuration examples
Core switch
Here's the core switch base config (required once for all VLANs):
max-vlans 250 # you might need more than this, depending on your switch setup
ip routing # enable routing between VLANs
ip udp-bcast-forward # enable "ip forward-protocol udp" commands in each VLAN
dhcp-relay option 82 replace ip # enable DHCP option 82 for "ip helper-address" in each VLAN
# NOTE: this assumes there are no other DHCP relays in the network
Here's the core switch (HP ProCurve 5400xl) config for an edge VLAN (ID 1003):
vlan 1003
name "your VLAN name here"
ip helper-address 10.0.0.xx # put your DHCP & PXE servers in this list
ip helper-address 10.0.0.yy
ip helper-address 10.0.0.zz
ip forward-protocol udp 10.0.255.255 5151 # this is to forward UDP broadcasts for AB Tutor Control from VLAN 1003 to the default VLAN
ip address 10.10.3.1 255.255.255.0
tagged Trk3 # this is the main trunk to other core infrastructure
# it is not required, but used as a tag to show that the VLAN exists on this switch
ip igmp
exit
Edge switch
Here's the edge switch (HP ProCurve 2824) config for the same edge VLAN:
vlan 1003
name "your VLAN name here"
untagged 1-20
tagged 21-24
ip address 10.10.3.9 255.255.255.0
ip igmp
exit
device-based VLANs
ins.insert { background-color: #AFA; color: #080; text-decoration: inherit; }
del.delete { background-color: #F88; color: #800; text-decoration: inherit; }
Introduction
This document explains some of my recent experience in rolling out device-based (or location-based) VLANs.
Introduction
This document explains some of my recent experience in rolling out device-based (or location-based) VLANs.
organisation-based VLANs
ins.insert { background-color: #AFA; color: #080; text-decoration: inherit; }
del.delete { background-color: #F88; color: #800; text-decoration: inherit; }
Criteria for grouping machines in VLANs
Number of machines
Bandwidth utilization of machines
Data access requirements
Similarity of function
Physical exposure of network devices & ports
A number of these will likely need to be balanced against each other.
Foundations
Printers and other embedded devices (e.g. IP cameras, UPSes, disk arrays) that you rely on should be in a separate VLAN only accessible from those who absolutely require them; for some reasons why, see:
http://www.blackhat.com/html/bh-europe-03/bh-europe-03-speakers.html#FX
http://www.sans.org/newsletters/newsbites/newsbites.php?vol=10&issue=4#sID308
http://news.softpedia.com/news/Xerox-Printers-Vulnerability-Unveiled-at-Black-Hat-32021.shtml (more info here)
It is very unlikely that there is any reason for an external or public entity to access anything on your staff members' workstations or laptops. (I would have said "There is never any reason ..." rather than "It is very unlikely ...", but i'm sure if i said "never", a reason would come up. ;-)
Some VLAN suggestions for school networks
In a typical large school environment you might consider putting each of these groups on its own VLAN:
servers
administration PCs
student PCs
teacher PCs
staff wireless
student wireless
public wireless
IP security cameras
printers
VPN
DMZ
Criteria for grouping machines in VLANs
Number of machines
Bandwidth utilization of machines
Data access requirements
Similarity of function
Physical exposure of network devices & ports
A number of these will likely need to be balanced against each other.
Foundations
Printers and other embedded devices (e.g. IP cameras, UPSes, disk arrays) that you rely on should be in a separate VLAN only accessible from those who absolutely require them; for some reasons why, see:
http://www.blackhat.com/html/bh-europe-03/bh-europe-03-speakers.html#FX
http://www.sans.org/newsletters/newsbites/newsbites.php?vol=10&issue=4#sID308
http://news.softpedia.com/news/Xerox-Printers-Vulnerability-Unveiled-at-Black-Hat-32021.shtml (more info here)
It is very unlikely that there is any reason for an external or public entity to access anything on your staff members' workstations or laptops. (I would have said "There is never any reason ..." rather than "It is very unlikely ...", but i'm sure if i said "never", a reason would come up. ;-)
Some VLAN suggestions for school networks
In a typical large school environment you might consider putting each of these groups on its own VLAN:
servers
administration PCs
student PCs
teacher PCs
staff wireless
student wireless
public wireless
IP security cameras
printers
VPN
DMZ
