This information is historical -- VLAN management is now handled entirely by IST (trg, 2014-2-28) (OBSOLETE)
Tutorial 10: Setting up a new network (VLAN)
Roadmap for this tutorial: In this tutorial, the procedures for creating a new network are described, including the IST request for the network VLAN assignment, selection of names and addresses, route-point implementation and required documentation.
Overview
- From a practical perspective, a "network" consists of name and a collection of IP addresses (for layer 3 and up), combined with a VLAN tag (for layer 2). It's a little bit imprecise, but we'll use the term "network" and "VLAN" interchangeably: from a practical perspective they are equivalent in our environment.
- In principle, VLANs that are local to a single device don't need to be allocated and managed globally, but if one intends to use ONA to manage the VLAN (eg switchport assignments), the VLAN tag needs to be allocated by IST.
- VLANS that span devices usually will need to be routed, and route-points will need to be created on the routing devices (the dc-cs1 & dc-cs2 pair, mc-cs1 & mc-cs2 pair or the firewall). See the discussion of route-point naming before creating the route-point names.
- Network allocations (name and address range) are recorded centrally by IST in Infoblox.
- VLAN tags are allocated and managed by IST. Historically, when all networks were CIDR /24 blocks, the convention of matching the VLAN tag with the subnet number was used (eg for 129.97.15.0/24, the VLAN tag would be "15"). However, with the current VLSM ("Variable Length Subnet Masking") practice on campus, this convention is no longer valid.
IST has indicated that it will be using an arbitrary block of numbers for each department/OU, so other than the block there is no predictive way of knowing what tag will be assigned to a VLAN. Thus, our Wiki-based VLAN tables are crucial in allowing us to understand what VLAN goes with what IP address range. Pleas try to keep them accurate.
Decide whether to use a UW-public, campus-routable or CS-private address range
A network can be based on a public 129.97.0.0/16 address ("
Maintain" zone
cs-inet), a 172.19.0.0/16 campus-routable address (
cs_campus), or a 10.15.0.0.16 CS-only address (
cs_private).. See "
CSCF networking philosophy and schema" for more details.
Request network setup from IST
The network must be allocated in the IST "Infoblox" database. You will need to choose a network name and size (CIDR block size). For public addresses, you will also need to indicate how many addresses (if any) are to be reserved for the IST dynamic address system. Typically we give back eight addresses for a /24 network. Use the
IST ST System to request VLAN ids (see the template below).
IST will advise of the VLAN tag that is assigned to the new network.
Template for VLAN and network requests
Requests to hostmaster for a new network and VLAN should contain the following information:
- network numbers, either as a range (start..end) or a network number with the bit suffix (number/bits)
- OU, which for us is always "CS"
Here is an example:
Hostmaster:
Please allocate the network and a VLAN tag for 10.15.3.0/24 in Infoblox for OU "CS".
Thank you,
Choose routing device (Netscreen or HP) and route-point DNS names
You must decide whether to route the new network on the Netscreen firewalls or on the HP devices. In the latter case you must know which building the network will be in (MC or DC). With this information, you can assign the route-point names and addresses. The basic form for the name is:
device-name-network-name
The numbers are always the first two usable addresses in the network (typically, but not always, the .1 and .2 addresses). See "
Host numbering within networks" for more information.
HP route-point organization
For networks that are routed on HP switches we use VRRP routing to provide redundancy, with the two router in a building providing redundancy for each other (redundancy does not span buildings). We typically put the master route-point on the "-cs2" router, and the backup on the "-cs1" router. See the
the network topology tutorial for more details. [One notable exception to this practice: the "math student organization" network, VLAN 134, provides connectivity for the "mirror" site mirror.csclub.uwaterloo.ca. Because this host generates significant external traffic, its network route-points put the master on the "-cs1" router to place it closer to our external gateway.]
Create inventory records, update VLAN Wiki page and add to ONA
Networks and route-points must be properly documented, as follows:
- Record the DNS names in the CSCF inventory system (https://www.cs.uwaterloo.ca/cscf/internal/inventory/). Create "IP" type records and fill in the name, address, location (usually dc3558 or mc3015). The description field should identify the network name and CIDR block. For firewall networks, records the virtual interface number in the comment field.
- Add the VLAN tag to the list of manageable VLANs in ONA: ONA -> Maintenance -> Vlan Group Memberships.
Set up DHCP for the network
If the new network is to support clients that require DHCP services, you must ensure that our DHCP server is set up correctly. The following is a quick summary:
For more information on our DHCP setup, see
DHCPInCS.
You will also need to decide on whether or not the routing configuration will need to specify DHCP helpers. The templates show below list three helper addresses: one in CSCF and two in IST. If you know you don't need these, don't include them in the configuration.
Create configuration scripts
Create configuration scripts for the new network based on the templates shown below. Store the configurations in a Wiki page linked to from the "Configurations" column in the appropriate table in the
current network assignments Wiki page.
Regardless of the device below, you will have to do some manual discovery of the correct values to use in the script. You cannot just cut & paste the templates without modification.
Template for HP routepoints
For HP routing, you will need to determine an available "vrid" to use. These are integer numbers between 0 and 255 and are not centrally managed. The numbers you use aren't terribly important as long as they are unique from other route-points.
To determine an available "vrid", use the
show vrrp
to get a list of all the current route-points. You can do this on either one of the pair of routers (-cs1 or -cs2) since the vrid will be the same on each for each route-point. The output will look something like:
VRRP Virtual Router Statistics Information
Vlan ID : 812
Virtual Router ID : 254
State : Master
Up Time : 23 days
Virtual MAC Address : 00005e-0001fe
Master's IP Address : 10.15.18.1
Associated IP Addr Count : 1 Near Failovers : 0
Advertise Pkts Rx : 1 Become Master : 1
Zero Priority Rx : 0 Zero Priority Tx : 0
Bad Length Pkts : 0 Bad Type Pkts : 0
Mismatched Interval Pkts : 0 Mismatched Addr List Pkts : 0
Mismatched IP TTL Pkts : 0 Mismatched Auth Type Pkts : 0
Note the line
Virtual Router ID : 254
assigning the number 254 to the virtual route. You need to choose a number that is unique amongst the entire set of route-points on the switch. Our current practice is to choose the next unused number in the decreasing sequence starting at 255. As of the time of writing (May 2010):
- on the DC routers, we're down to 250, so 249 would be next
- on the MC routers, we're at 249, so 248 will be next.
Note that in the days before private networks or networks smaller that /24, we would use the "129.97.x.0 is vrid x" rule, but that is no longer reliable.
On the {mc|dc}-cs2 switch
The -cs2 switch will be the ".1" address in the new network (which may or may not be the actual number 1, depending on the CIDR block alignment). See "
Host numbering within networks" for details.
Items that you must substitute are shown:
__like this__
config
router vrrp
vlan __new-vlan-tag__
name __network-name-as-requested-for-Maintain__
ip address __a.b.c.1/nn__
ip helper-address 129.97.15.253
ip helper-address 129.97.128.9
ip helper-address 129.97.129.9
tagged trk1
forbid trk2,trk3
ip ospf area 4
ip ospf passive
vrrp vrid __new-vrid__
owner
virtual-ip-address __a.b.c.1/nn__
enable
exit
exit
write memory
exit
On the {mc|dc}-cs1 switch
The -cs1 switch will be the ".2" address in the new network.
config
router vrrp
vlan __new-vlan-tag__
name __network-name-as-requested-for-Maintain__
ip address __a.b.c.2/nn__
ip helper-address 129.97.15.253
ip helper-address 129.97.128.9
ip helper-address 129.97.129.9
tagged trk1
forbid trk3
ip ospf area 4
ip ospf passive
vrrp vrid __new-vrid__
backup
virtual-ip-address __a.b.c.1/nn__
enable
exit
exit
write memory
exit
Template for Netscreen routepoints
In the following:
- refers to an interface number
- is a vlan tag id (i.e. an integer in the range 1 to 4095)
- is a firewall zone identifier (e.g. "Zone4")
- / is a CIDR network specification
- and are single IP addresses representing the two route-point addresses for the network
- is a network mask specification
- is an unused access-list number
- is an access-list sequence number in the access-list referenced prior in the same command
- is an unused route-map entry number
Notes
- There appears to be no particular reason to choose the untrust-vr access-list 2 for the new sequence numbers.
- We seem to use a distinct access-list and route-map entry per interface, so the access-list number and route-map entry number align with the interface sub-number. It's not clear whether this is requirement, but it works. If we run into a limit on the number of entries, we'll have to figure it out.
- The following commands may be helpful in determining existing settings and values:
- get interface
- get vrouter untrust-vr access-list
- get vrouter trust-vr access-list
- get vrouter trust-vr route-map
Example
Setting up vlan 170 (Zone 4 client network, 129.97.170.170/23) on dc-csfw1:
set interface "redundant2.2" tag 170 zone Zone4
set interface "Redundant2.2" ip 129.97.170.2/23
set interface "Redundant2.2" route
set interface "Redundant2.2" ip manageable
set interface "redundant2.2" manage ping
set interface "Redundant2.2" protocol rip
set interface "Redundant2.2" protocol rip enable
set interface "Redundant2.2:1" ip 129.97.170.1/23
set interface "Redundant2.2:1" route
set interface "Redundant2.2:1" ip manageable
set interface "redundant2.2:1" manage ping
set interface "Redundant2.2:1" protocol rip
set interface "Redundant2.2:1" protocol rip enable
set vrouter untrust-vr access-list 2 permit ip 129.97.170.0/23 10
set vrouter trust-vr
set access-list 3
set access-list 3 permit ip 129.97.170.0/23 1
set route-map name "rtmap1" permit 3
set match interface "redundant2.2:1"
set match ip 3
exit
exit
set interface "redundant2.2:1" dhcp relay server-name "129.97.15.253"
set interface "redundant2.2:1" dhcp relay service
save config
Note that I chose not to use the IST DHCP relays in this case.
Apply the changes
Checklist:
- networks names have been allocated at IST
- HP or Netscreen
- inventory, ONA and wiki updated
- DHCP set up
If this is in fact not a new network, but a migration from HP to Netscreen or vice versa, now is the time to schedule downtime and send notices to the user community. Then:
- if this is a migration, dismantle the existing setup
- apply the scripts you created above
- test that routing is working:
- on HP switches:
show ip route a.b.c.d
- on Netscreens:
get route ip a.b.c.d
- on a client workstation,
ping
the two route-points of the new network
Rough notes from Dave's email:
0.) Decide on VLan name,
VLanID, and VRRP master and backup rout points.
1.) Decide where and setup routing on the master and backup
2.) Add Vlan name and routing points to Maintain (vlan entry must be via IST)
192.17.X.128/25 would get three entries: 192.17.X.128 as an "A record" - 192.17.X.129 - 129.17.X.130
3. ) Add above to Inventory as UP devices
4.) Fix DHCP to provide service for the VLan (if it needs DHCP)
Configuration archive
Historically, CSCF used to manage network definitions. Configuration scripts were attached to the vlan entry on VLANInformation. Since IST has taken over management of the networks, this set of definitions has become obsolete and has been deleted from the Twiki page. However, as there may be some historical utility in maintaining samples of "how we did things", a couple have been preserved. See NetworkTutorial10ConfigurationArchive.