University of Waterloo
ISTNS > ISTReportsToCNAG? > ISTNSISTReportToCNAGNov2010 > CampusNetworkDeviceConfigurationandPracticeStandardization
TWiki webs: Main | TWiki | Sandbox?   Log In or Register

Changes | Index | Search | Go

Campus Network Device Configuration and Practice Standardization


  • Point to point networks:
    • /30 private networks
    • enable authentication
  • all other networks
    • vlan X ip ospf 129.97.X.x passive

Authorized Managers list

  • ip authorized-managers 129.97.x.y (ona host, plus others as needed)

Radius Authentication

  • radius-server host 129.97.x.y key key-string (ads radius server 1)
  • radius-server host 129.97.a.b key key-string (ads radius server 2)
  • Create groups on ads radius servers for faculty IT staff


  • crypto key generate ssh rsa
  • ip ssh
  • ip ssh filetransfer
  • no telnet-server
  • no web-management
  • aaa authentication login privilege-mode
  • aaa authentication ssh login radius local
  • aaa authentication ssh enable radius local
  • configure login authentication on ads radius servers based on faculty
  • change all console passwords, unique per orgunit, used only for emergency access (radius server down)


  • logging facility local7
  • logging 129.97.x.y (ona host)


  • aaa authentication port-access eap-radius
  • aaa port-access authenticator active


  • time timezone -300
  • time daylight-time-rule Continental-US-and-Canada
  • timesync sntp
  • sntp unicast
  • sntp server priority 1 129.97.128.a 3 campus ntp server
  • sntp server priority 2 129.97.129.a 3 campus ntp server

private management ip address

  • ip default-gateway 172.a.b.1
  • vlan NNN
    • name org-mgmt2-bldg
    • ip address 172.a.b.c

login banner

banner motd "~"
banner motd "***************************************************"
banner motd "This is an IST managed device"
banner motd "per"
banner motd "~"
banner motd "Console access may be provided for read-only functions."
banner motd "Configuration changes made via console must be coordinated with IST"
banner motd "***************************************************"
banner motd "~"

Spanning Tree and Loop Protection

  • spanning-tree
  • spanning-tree force-version rstp-operation
  • enable loop protect on edge ports

Device firmware

  • IST to upgrade firmware on devices as needed


  • Delete all existing snmp communities, and apply pseudo random community strings, unique per device

Subnet Usage

See the report at

  • A goal of 75% or higher subnet utilization should be set.
  • After discussion, IST to assist groups clean up unused IP addresses, and consolidate subnets


Hard coding IP addresses presents several challenges:

  • Creates a risk that incorrect IP/mask/gateway settings will be entered by the end user. This can result in a client workstation taking over the IP address belonging to another users computer, or worse, the router.
  • Creates additional work during IP address renumbering as would be required to use subnets more efficiently, or to group machines with similar security requirements into netblocks.
  • Prevents the deployment of ARP protection, a feature of the switches/routers which ensures computers use their correct DHCP assigned IP address.

After discussion, launch a campaign to migrate the majority of computers to DHCP.

Dynamic IP addresses

Currently most IP addresses in use on wired networks within faculties are static assignments (whether issued by DHCP, or hard coded). Dynamic IP address assignment is permitted in private areas per ISTNSIPRequestsAndRegistrations, as needed. This allows immediate connectivity to the campus network in private areas, through a dynamic IP address, without having to engage campus IT staff to assign a permanent IP name/address (in cases where users do not require a fixed domain name/address).

After discussion, IST to configure dynamic IP ranges on all subnets serving private areas, to allow immediate connectivity for temporary and mobile equipment. For cases where authorization/authentication is needed, 802.1x port authentication can also be enabled.

Wired Authentication Networks

The existing wired authentication networks provide captive portal authentication, tunnelled to the central Aruba controllers.

After discussion, IST to migrate the wired authentication network to a conventional dynamic IP range, in a suitably sized subnet, and enable 802.1x wired authentication where appropriate.

One to One Patch Cabling

A review of Telecommunications Rooms will be conducted to determine current patch cable practices, and jack counts versus available switch ports. All new buildings use one to one patch cabling, where all wall jacks are made live, and jacks are connected in a one to one manner to switch ports of the same number (e.g. jack E04 would be connected to switch E, port 4). This is also called ZANI (Zero Administration Network Implementation), as the pre-provisioning of network service reduces ongoing day to day network service provisioning activities.

IST to review jack and port counts, and develop a priority and timetable to migrate to ZANI, at IST expense (parts and labour).

Mixed Aggregation Access Layer

In some cases, layer 2 aggregation switches also provide access layer service on the leftover ports. IST generally prefers the aggregation and access functions to be on separate devices.

IST to review shared access/aggregation switches, and develop a priority and timetable to separate these functions, at IST expense (parts and labour).

10 gigabit

The standard networking within faculties is 1 gigabit/second or 10/100. Incremental expansion of these networks will continue, at IST expense. When needed, IST will offer 10 gigabit/second connections from faculties to the core, at IST expense.

Traffic levels within most faculties currently do not justify wide scale 10 gigabit deployment. IST will monitor network interconnections, and consider link aggregation (multiple parallel 1 gigabit connections), and/or 10 gigabit as needed. Requests for individual 10 gigabit host connections will be at client expense for parts (modules, optics).

Network Topologies

Review network topologies, and develop and timetable and priority to upgrade as needed, at IST expense. The generally preferred topologies are below.


Diagram 1 Non Redundant Routing and Aggregation

This is generally used where the distances between the router and access layer switches exceeds CAT6 distance limits, and fibre is used between routing and aggregation. The network within the Faculty of Science uses this design.


Diagram 2 Non Redundant Routing, Combined Routing/Aggregation

This is generally used when the distances between the router and access layer are within CAT6 distance limits. The network within individual buildings, e.g. NH, often uses this design.


Diagram 3 Redundant Routing, Combined Aggregation

This adds redundancy to the design in Diagram 2. This IST machine room uses this design.


Diagram 4 Redundant Routing

This adds routing redundancy to the design in Diagram 1.


Diagram 5 Redundant Routing and Aggregation

This adds router and aggregation device redundancy to the design in Diagram 1. This design involves two levels where paths will be blocked by spanning tree (from routing to aggregation, and from aggregation to access). Math uses this design.

I Attachment Action Size Date Who Comment
bmpbmp netexample1.bmp manage 637.6 K 14 Nov 2010 - 20:52 BruceCampbell  
bmpbmp netexample2.bmp manage 637.6 K 14 Nov 2010 - 20:48 BruceCampbell  
bmpbmp netexample3.bmp manage 637.6 K 14 Nov 2010 - 20:54 BruceCampbell  
jpgjpg netexample3.jpg manage 10.5 K 14 Nov 2010 - 20:52 BruceCampbell  
bmpbmp netexample4.bmp manage 637.6 K 14 Nov 2010 - 20:54 BruceCampbell  
bmpbmp netexample5.bmp manage 637.6 K 14 Nov 2010 - 20:55 BruceCampbell  
Edit | Attach | Print version | History: r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions

Parents: ISTReportsToCNAG? > ISTNSISTReportToCNAGNov2010

This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback