Network Operations

Engineering designs and manages the core network equipment including routers, switches, firewalls, encrypted tunnels (VPN) and remote site connectivity. They support all aspects of the OSU Wireless network. The team also provides up/down monitoring, network and system performance monitoring, and utilization graphing.

Engineering manages OSU's IP allocation, including IPv4 and IPv6. They provide tier 2 and tier 3 support to departmental IT staff at OSU.


Contact Us / 7-HELP

Contact Us / 7-HELP

Network Staff List

Consulting & Tier 3 Requests

Email Network Services

ONID, Computer & Printing

Call 7-HELP for phone repair and network issues

7-HELP Support Line for Phone Repair & Network Issues

Techs are on call 24/7 so please reserve after-hours help requests for urgent phone and network issues only.

  • Phone Repair & Network Issues
    • Email Us
    • Phone: 7-HELP or 541-737-4357
    • Handles: phone repair & network issues

Network Abuse & Network Security

Other Help Requests

Email IT Infrastructure Services & Telecom

Contact Us / 7-HELP

Network Staff List

Consulting & Tier 3 Requests

Email Network Services

ONID, Blackboard, Computer & Printing

This question is for testing whether you are a human visitor and to prevent automated spam submissions.
2 + 0 =
Solve this simple math problem and enter the result. E.g. for 1+3, enter 4.

Network Consulting & Tier 3 Requests

Contact Us / 7-HELP

Network Staff List

Consulting & Tier 3 Requests

Email Network Services

ONID, Computer & Printing

Active Directory and Exchange Account Help

Departmental Computing Administrators (DCAs) can contact Server Support for Windows networking, Active Directory, and Exchange questions.

Jason Appah, Nathan Power, Bruce Beicke, Mike Akey, Mark Hammerschmith
Phone: 541-737-4710
Email: ServerSupport (@)

Tier Three Issues & Requests

Departmental Computing Administrators (DCAs) can email the Network Engineering staff for other tier three issues and requests noted below.

Email: net (at)

Domain Name Requests
Mike Akey, Kirsten Petersen

General Email Issues
Jason Appah, Nathan Power, Bruce Beicke, Mike Akey, Mark Hammerschmith

Mailman Email Lists
Mike Akey, Mark Hammerschmith

Maintain, DNS and DHCP
Mike Akey

SQL Database Hosting
Jason Appah, Bruce Beicke, Nathan Power

Network Operations Center (NOC)
Steve Heitmeyer, Joel Burks, Ian Downie, Josh Crowl, Greg Edmaiston

Network Security: Incident Response, Vulnerability Scanning, Firewalls
Alec Dhuse, Dave Nevin (Office of Information Security)

Mike Akey

Server Backups
Steve Fowler, Gaylon DeGeer (Shared Infrastructure Group)

Server Monitoring with OpenNMS, Paging
Joel Burks

SSL Certificates
Alec Dhuse, Kirsten Petersen

Alec Dhuse, Mike Akey, Tony Brock

Steve Fowler, Gaylon DeGeer (Shared Infrastructure Group)

Wireless Network
Josh Crowl

Campus Firewall

Network Engineering has implemented a firewall design with the following goals in mind:

  • High availability, performance and redundancy.
  • Usability of the network preserved without creating barriers to information sharing.
  • Distributed control of firewall rulesets to Colleges/Departments.

Our current strategy is to configure a separate services firewall context for each department. Machines in a "services" network are those that need to provide services to off-campus or non-firewalled hosts. Rulesets for each departmental services subnet are then managed by the department.

Workstations are placed behind the Enterprise Firewall, which denies all inbound connections. No outbound connections are restricted. Some access to workstations behind the firewall will be enabled via the VPN for services such as RDP or SSH.

Frequently Asked Questions

Q: Will I be able to access my workstation from home via Remote Desktop or SSH after it has been moved behind the firewall?
A: Yes, you will be able to use the VPN to access your workstation remotely.

Q: For servers behind the firewall, if I don't want to allow outbound port 80 access, how do I use proxy?
A: Most applications support a proxy server and are easy to configure. For those that don't, you may be able to use an environment variable to specify the proxy server. For example, in bash, do: export http_proxy=''

Q: For servers behind the firewall, if I block outbound access, how can I do SVN via Proxy?
A: SVN supports proxy and our proxy servers are configured to allow the needed methods. Instructions for SVN are here: 

List of Departments Behind the Firewall

The following groups and departments have moved all or part of their systems behind the campus firewall:

  • College of Business
  • College of Forestry
  • Fisheries & Wildlife
  • College of Science
  • CGRB
  • Community Network - Technology Support Services
  • Student Health Services
  • ResNet
  • Athletics
  • Enterprise Computing Services - Banner, ONID, Blackboard
  • Milne Computing Center
  • Network Engineering
  • Registration and Enrollment


Quick Information
Authoritative Name Servers,
Caching Name Servers for OSU,
Policies Domain Name Policy
DNS/DHCP Registration System Maintain
DNS Information List of OSU Domains

What is DNS?

DNS stands for "domain name service". In essence, it is a directory of names that point to services on the local network or the Internet. Computers communicate with each other over the Internet via IP addresses (e.g. DNS provides human-friendly names for these IP addresses. For example: the DNS name points to the IP address

What is DHCP?

The Dynamic Host Configuration Protocol (DHCP) is an Internet protocol for automating the configuration of computers on a network. DHCP can be used to automatically assign IP addresses, to deliver TCP/IP stack configuration parameters such as the subnet mask and default router, and to provide other configuration information such as the addresses for DNS servers.

Registering Your Computer on the OSU Network

Most OSU network registration is done via Maintain, an open source application developed at OSU. For general help with Maintain, network registration, or activating your ONID account, please contact the OSU Computer Helpdesk.

  • Maintain Replacement Project
    Maintain, our existing network registration system is scheduled to be replaced with Cyder. See this page for additional details and updates on this project.
  • Departmental Computer Administrators (DCAs)
    DCAs have access to Maintain to register network devices for use on departmental networks. If you are a DCA and need access to Maintain, please contact Network Engineering (
  • Employees
    Employees needing a device registered should contact their DCA. Employees may also register their own wireless devices by logging into Maintain with their ONID account.
  • Students Using Wireless
    You may register your own wireless devices by logging into Maintain with your ONID account. For help, see Helpdocs: Wireless Registration.
  • Students in the Residence Halls
    Directions for registering your computer on the Residence Hall Network (ResNet) are here: Helpdocs:ResNet.

Recursive Requests

As of August 3rd, 2013 Oregon State University's authoritative name servers ns1 and ns2 no longer answer recursive requests from outside of our network. This change was made to prevent our name servers from being used in DDoS attacks against other Internet hosts.


The Cyder implementation planned for March 22, 2014 has been delayed. An updated implementation date will be posted to this page and communicated directly to DCAs and Maintain Zone admins.

In Spring 2014, Information Services will replace Maintain with Cyder as our central IP address management solution. This new software will bring a revamped web interface, and more robust and extendable back-end design. This will allow us to deploy new functionality like IPv6 allocation/support, a RESTful API, DNS views, and more.

We're in the final stages of development and focused on feature parity between Maintain and Cyder. However, some functionality will be lacking at release. Additional features beyond what Maintain offered will have lower priority until we've matched Maintain. Included below is a list of major features and their estimated completion schedule.

Anticipated ready by release:
-API Read-only
-New wireless self-registration system
-Bulk interface move
-Interface expiration

End of Summer 2014:
-Other bulk operations (container moves, user permissions cloning)
-Last seen
-Audit History
-CSV mail/export from web interface

Changes since inital preview release:
-Related interface list now excludes interfaces with blank MAC addresses
-Range lists now include type column (static/dynamic)
-Range names migrated/shown
-Added combined static/dynamic interface view to System section called 'Interfaces'
-Properly migrate Interfaces to Legacy VRF, Campus site
-Overhauled inventory attribute creation/editing/storage
-Range usage displayed, and updated correctly now
-MAC address field on forms no longer mangles entries
-VRF/Site/VLAN/Network detail views show more related data
-Numerous bug fixes and UI tweaks/enhancements

Note: this list is not exhaustive and has been truncated to only include changes relevant to DCAs.

Preview site available here:
Source code available here:

Cyder User Guide



Cyder is OSU's IP address and DNS management system. This provides a web interface and RESTful API for DCAs to manage their network allocations, assets, and names. Cyder also is the basis of network allocation and assignment documentation for our network engineers.

Transitioning from Maintain

Hosts in Maintain are now Systems in Cyder. A System can have one or more Interfaces. A System is where informational data resides, like department, other_id, etc. IP/DHCP information is tied to the Interface. Our data migration process from Maintain creates a System and a single corresponding Interface. If you have a device/system that has multiple network interfaces and subsequently had multiple host entries in Maintain, these can be combined into a single System with two Interfaces in Cyder. We do not have a merge function yet, but it is planned.

Maintain's method of delegating permissions to departments is accomplished with groupings called Zones. In Cyder, a Zone is now called a Container. As a part of the migration process, Containers will have the same name as their zone counterpart but without the 'zone.' prefix (Note: This change has not happened yet, but will before or on the deployment day). The permissions model, at least initially, will mimic that of Maintain with one exception: Any user can see all objects within Cyder (even those not in their Container), just not edit them. Select the global Container to see everything.

Introduction to Cyder's structure and naming conventions

This software provides a thin layer of abstraction between what is generated in a DHCP or DNS server configuration file. For DHCP, Cyder extracts information from objects called Systems and Interfaces. Systems are devices that exist on our network. The System object in Cyder retains inventory information and Interfaces. A System can have one or more Interfaces. The Interface of a System determine the IP address and name assigned to it. This allows a device such as a laptop to have both its wired and wireless interfaces tracked as a single entity, a System.

Interfaces drive DNS and DHCP configuration for Systems. There are two types of Interfaces: Static and Dynamic. As their names imply, a Static Interface defines a static IP reservation. Dynamic Interfaces allow a device to obtain an IP in the specified range. A System name is merely for reference, and the Interface label is what determines the hostname generated. We do not support Dynamic DNS, and as such, Cyder will only auto-generate A and PTR records for dynamic Ranges of the format and respectively. The domain suffix used to auto-generate A records for dynamic Ranges is configured by network engineers.

Subnets are now referred to as Networks.  In addition to referring to a maskable range of IP space and a corresponding VLAN, Networks also have a Site and a VRF.  A VRF, in the simplest of terms, is a collection of related networks.  A Site refers to a building router, and not necessarily a physical location.  Because these are new concepts, all Networks migrated from Maintain will be a part of the 'Legacy' VRF and the 'Campus' Site.  Note: VRF is synonymous with the term Security Domain.

DHCP options sent to clients are derived from Workgroup and Network options. An Interface must belong to a Workgroup – if none is selected, the Workgroup named 'Default' will be used. Options can also be set at the Network level. Workgroup options override those of the Interface's Network. Network options override global options (not displayed within Cyder).

Most common DNS records can be created/managed with Cyder. A, AAAA, PTR, CNAME, SRV, TXT, MX, etc can all be created ad-hoc and not be tied to any specific System or Interface. If there is an RR type that is not available via the Cyder web interface, please submit a feature request and we will work to add it (requests for the DNAME RR type will be ignored, we will never support these).

DNS Views

Cyder supports two DNS views (also referred to as split-brain, split-horizon, and merely split-DNS). For most DNS objects, you will be given the option of exposing them to either the public or private view. If a service requires a different DNS query response depending on the network of the client making the request, make two objects – one with only the private view checked, and one with the public view checked. The views are defined as such:

Public: All queries from IP addreses not in the Private view will receive records that have this view checked.

Private: Queries from and will receive records checked as private.

When an object is set to both public and private views, the query response for that record will be the same from any client source IP address. When none are selected, the object is disabled and will not be included in any DNS zone files.


How to navigate the web interface

Table Filter

Cyder has many data tables on various pages. Each table can be filtered in-place using the Filter text box at the top of each table. This should not be confused with the Global Search text box at the upper-right of all pages. This filter can be a simple text filter or use RegEx as well.

To see additional details and related objects to an entry in a table, click on the magnifying glass with a lowercase 'i' inside it. This is located in the left-most column of all tables. Similarly, on the right-hand side of all tables will be an Actions column. If your account and/or Container have the necessary permissions to edit or delete an object, a clipboard and waste bin icon will appear here. An object can be deleted by clicking on the waste bin icon – you will be prompted to confirm your action.

Clicking the clipboard icon will expand an object edit form between the table name and the table itself. The page will not reload/redirect to a new page for editing. Your browser will automatically scroll to the top of the page to show the form. When editing any object, you must click on the Update button at the bottom of the form to commit changes. This will also make the edit form disappear.

Cyder Main page

The following image shows what you will see after logging in to Cyder.

Cyder Landing Page

1. Sidebar Menu: See Sidebar Menu section for details on menu structure

2. Home and log-out buttons, respectively

3. User: The currently logged-in username (hopefully yours!).

4. Container permission level: The permission the currently logged in user account has on the selected container (5). Permission levels are defined in the Account Permissions section.

5. Current Container: The Container selected in this dropdown acts like a filter on most of the various data tables displayed within Cyder's interface. This selection does not affect some listings, like the global search results. To view objects outside of your assigned container(s), select 'global' from the list to have all objects appear in views/tables. Selecting a Container from the list automatically causes the current page to reload with data relevant to the newly selected Container.

6. Container detail (magnifying glass): Loads the currently selected Container's (5) detail view.

7. Click the "Set as default container?" text to set the currently selected container (5) as the container to be selected by default when you log in.

8. Global search: Search usage covered in greater detail in Search section.


Common Operations

Registering a device on the OSU network

Assigning a device an IP address and name on the OSU network requires at a minimum, a System and an Interface. When a System is created, you must create at least one Interface at the same time. Creating a new System will automatically provide you with the form to create the first Interface. To begin, make sure the Container selected at the top of the page is one you wish to assign this System/Interface to. Do not use 'global.'

Expand the Core sidebar menu, and then select System. This will load a list of Systems that exist in the currently selected Container. At the top of the table, click on the Create System button. When presented with a Create a System form, enter in a descriptive name for this device. This name is not used outside of Cyder for DNS. Then select the Interface type (static or dynamic) and the appropriate Interface creation form will expand below.

For static Interfaces:

The most important, and required fields are the hostname, MAC address, Domain, and IP address. The hostname and Domain are used to create an A-record for this Interface. A corresponding PTR record will be created given the IP address specified. The MAC address does not need to be supplied if DHCP will not be used to configure this Interface on the device (i.e. hard-coding the address on the device).

To ease selection of an IP address, you may use the VRF, Site, and Range filters selections. Selecting a VRF will then limit the amount of Sites selectable to those wish are assigned this VRF. Select a Site to reduce the available Ranges to choose from. Initially only the Legacy and Campus VRF/Site combination will be available, and automatically selected. Now select the Range from which the IP address should be assigned. Check the 'Select available IP' box to have the next free IP address auto-filled in to the IP address field.

The automatically generated A and PTR records for this Interface can be disabled by un-checking the Enable DNS box. The DNS view for these records can also be changed from this form as well. Un-checking both the public and private views will have the same effect as un-checking Enable DNS.

For dynamic Interfaces:

Dynamic Interfaces are very simple: Only a MAC address and range are required. Just like the static Interface form, the VRF and Site fields are only to help filter the Range selections available. Unlike the static Interface form, the Range is required.

DNS cannot be disabled for dynamic Interfaces, but DHCP can. Generally DHCP should only be disabled if the MAC address is not yet known but a reservation in the Range is needed.


Sidebar Menu Structure Details

The sidebar menu is the primary method for navigating through the various objects Cyder keeps track of. A brief description of each menu item is listed below, with links to additional details. Most users will only see three top-level menus on the sidebar: Core, DNS, and DHCP. Clicking on a top-level menu name will reveal the menu's objects/categories. An additional Admin menu is available to users with the cyder- and superadmin account levels.


- Container: Provides a list of all Containers. This list is not affected by the Container selected in the dropdown of the main page.

- Interface: Also referred to as the 'Combined Interface View,' this will provide a list of all interfaces static and dynamic in the currently selected container. This listing is not available when the global pseudo-container is selected.

- System: Provides a list of all Systems within the currently selected Container.


- DNS Statistics: A list of DNS record counts for the current Container.

- Address Record, CNAME, NS, MX, PTR, SOA, SSHFP, TXT, SRV: Provides a list of the named record type in the currently selected Container.

- Domain: A list of all domains, forward and reverse, allowed to be used within the context of the currently selected Container.


- Dynamic, Static Interface: Provides a list of all dynamic or static Interfaces within currently selected Container.

- Network: A list of Networks (subnet in ISC-DHCPd parlance) allowed to be used within the context of the currently selected Container. Networks are further broken down in to Ranges and the entirety of a Network may not actually be allocated to your Container for use.

- Range: A list of IP Ranges (pools) that that can be used by Interfaces within the context of the currently selected Container.

- Sites: A list of logical locations, referring to typically to different campuses/physical locations, but not always. All objects migrated from Maintain will have the site 'Campus.'

- VLAN: A list of all VLANs used by Networks in the currently selected Container.

- VRF: A list of VRFs (Security Domains) available.

- Workgroups: A list of Workgroups (groups) available for use in the currently selected Container.


Edit Form fields, defined


- Name: A short name for the system. Does not affect DNS. DNS records are generated based off the Hostname set on the Interface or the range an Interface is in.

Static Interface

- Description: A brief description of the interface (e.g. 'Management Interface')

- Hostname: The DNS name used for this Interface's A Record.

- Domain: The DNS name suffix used for this Interface's A Record.

- MAC Address: The hardware ethernet address of this Interface. Can be blank or invalid if DHCP is disabled for this Interface (see below). Can include colons or dashes, but they will be stripped upon saving. The following fields are used to select an appropriate IP address and are not actually values stored with a Static Interface object. Begin in order from VRF to Range to locate an IP. These selections are to ease the location of a free IP address, and are not required.

- VRF: Filter Ranges by VRF.

- Site: Filter Ranges by Site.

- Range: Ranges available for use in this Container, optionally filtered by the previous two selections.

- IP Address Type: Identifies this as a IPv4 or IPv6 Interface. If a System requires both IPv4 and IPv6, two interfaces must be created for each type.

- Select free IPv4 IP?: Allow Cyder to automatically select the next free available IP in the selected range. IP Address field will be automatically updated with the selected IP before you save changes.

- IP Address: The IP address for this Interface. Can be an IPv4 or IPv6 address, depending on type selected earlier.

- Time to Live: The TTL value for the automatically generated DNS records for this host (A, PTR)

- Workgroup: The DHCP options that should be sent from the DHCP server to this interface. Typically this should be Default unless you have a special device like an IP-Phone or thin client.

- Expire: The expiration date for this interface (interface will be deleted on this date). Format is MM/DD/YYYY. If the System this interface is tied to only has one interface, the System will also be deleted on the expiration date. Leave field blank to never expire interface.

- Views: This allows you to configure how DNS records automatically generated for this Interface are queriable from. If Public is checked, the A and PTR records will be available from outside of OSU's IP space. If Private is checked, they will be queriable internally. The private view is for and, public is for the rest of the Internet. Default: public, private both checked

- Enable DHCP?: Enable/Disable DHCP for this entry. If disabled, this IP is reserved and can still be used, but a lease for this address will not be given out. Default: Enabled

- Enable DNS?: If disabled, Cyder will not auto-generate an A Record or PTR for this Interface's address. Equivalent to unchecking both the public and private view. Default: Enabled

Dynamic Interface

- MAC Address: The hardware ethernet address of this Interface. Can accept colons or dashes, but they will be stripped upon saving. Field can be blank if DHCP is not enabled.

The VRF and Site selections are only for filtering down the Range selection. They are not actually fields stored with the Dynamic Interface object.

- Range: The IP range in which this Interface should be assigned an address. Use dynamic Range to register an interface to bypass the captive portal on OSU_Access.

- Workgroup: The DHCP options that should be sent from the DHCP server to this interface. Typically this should be Default unless you have a special device like an IP-Phone or thin client.

- Expire: The expiration date for this interface (interface will be deleted on this date). Format is MM/DD/YYYY. If the System this interface is tied to only has one interface, the System will also be deleted on the expiration date. leave field blank to never expire interface.

- Enable DHCP?: Enable/Disable DHCP for this entry. If disabled, this IP is reserved and can still be used, but a lease for this address will not be given out. Default: Enabled

A Record

-Label: The non-fully-qualified name (no domain suffix!)

-Domain: The domain suffix for this record.

The following fields (VRF, Site, Range) are used to aide in finding/selecting an appropriate IP. Use is not necessary, especially if the IP address is not within OSU's IP space.

-VRF: Filter Ranges by VRF.

-Site: Filter Ranges by Site.

-Range: Ranges available for use in this Container, optionally filtered by the previous two selections.

-IP Address Type: Selects whether this is an A record or AAAA.

-Select free IPv4 IP?: Allow Cyder to automatically select the next free available IP in the selected range. The IP Address field will be automatically updated with the selected IP before you save changes. Again, this is not necessary if you are not using the VRF/Site/Range filters above.

-IP Address: The IP address this A record points to. Can be an IPv4 or IPv6 address, depending on type selected earlier.

-Views: This allows you to set where this record is queriable from. If Public is checked, the A and PTR records will be available from outside of OSU's IP space. If Private is checked, they will be queriable internally. The private view is for and, public is for the rest of the Internet. Default: public, private both checked

-Time to Live: The TTL value for this record, in seconds. Default: 3600 seconds (one hour)

-Description: A description/note for this record (only shown within Cyder).


-Label: The non-fully-qualified name (no domain suffix!)

-Domain: The domain suffix for this record.

-Target: The name that this CNAME points to. Do not enter an IP address here!

-Views: This allows you to set where this record is queriable from. If Public is checked, the A and PTR records will be available from outside of OSU's IP space. If Private is checked, they will be queriable internally. The private view is for and, public is for the rest of the Internet. Default: public, private both checked

-Time to Live: The TTL value for this record, in seconds. Default: 3600 seconds (one hour)

-Description: A description/note for this record (only shown within Cyder).


Account Permissions

Account permissions are set per-Container. Containers are merely a group of objects within Cyder that are related e.g. a department or related equipment.

There are five different account levels in Cyder, ordered least to most privileged: guest, user, admin, cyder-admin, and super-admin. The guest level is generally considered superfluous because all accounts have access to view all objects managed by Cyder. The guest level is only useful if an admin account (or above) wishes to give another account read-only access only, and that account has not been given any permissions to any Containers.

The user and admin permission levels are very similar. Most accounts should be at the user permission level for any given container. The admin permission level is the typical Container permission level given to DCAs or IT staff managers. The admin level allows an account to add, remove, and change permissions of other users within a given Container.

Cyder-admin and super-admin permission levels are reserved for NOC staff and administrators of Cyder itself. A detailed break-down of permissions are listed in the table below.


Object User Admin Cyder Admin
Container R R RW
Container Users R RW RW
Container Objects R R RW
VRF, Network, Range, Workgroup, VLAN, Site R R RW
System, Interface RW RW RW
SOA, NS, Domain R R RW
Subnet Options R R RW
Workgroup Options R RW RW

R = read-only, RW = read/write access.


What is Internet2?

Internet2 is a consortium of universities working in partnership with industry and government to develop and deploy advanced network applications and technologies. OSU has been an Internet2 partner since 1999.

What does Internet2 do for me?

Internet2 members enjoy high speed connections to each other, enabling improved performance for bandwidth-intensive applications such as digital video, distributed learning, remote instrumentation and tele-immersion (virtual reality).

How do I use Internet2?

When you communicate with another institution that is an Internet2 member, your network traffic will flow over the faster Internet2 connection. Much of OSU's commodity traffic (i.e. traffic to commercial sites) is now over I2 through the Commercial Peering Service.

Who are the members of Internet2?

As of July 2012, there are 221 higher education members of Internet2, as well as corporate, governmental and international members. See the following for more information about the I2 community:

Where can I learn more about Internet2?

Learn more at

I have an application that could make use of Internet2. Who should I talk to?

Talk to your Department Computing Administrator (DCA), or contact Network Engineering for more information.

Network Info & Policies

System Status & Statistics

Resource graph: Bits In/Out (64 bit Counters)

Example of the I2 Commercial Peering (OB1) graph from OSU Border Traffic

Network Policies

Important: The following are network policies developed and managed by Information Services. It is your responsibility to understand any other applicable policies developed by departments and colleges, as well as all university-wide OSU IT policies.

OpenNMS Server Monitoring

Network Services uses OpenNMS to monitor servers for several groups on campus.

Please visit the server monitoring page for more information on OpenNMS and Testutil.

Domain Name Policy


Access the Domain Name Request Form to acquire a new domain.

1. OSU assigned Internet Address and Domain Name space

Oregon State University has been assigned the Class B block of IP addresses - by the American Registry for Internet Numbers (ARIN). In addition Oregon State University has registered the following Internet Domain Names with the InterNIC:


As of January 1, 2002, our preferred Domain Name is OREGONSTATE.EDU.

Technical: Kirsten Petersen, IT Manager
Managerial: Jon Dolan, Director, Network Services
Business: Jon Dolan, Director, Network Services

Oregon State University is responsible for managing all of these assignments. There is no association between our assigned block of IP addresses and our registered domain names other than associations that we make using Domain Name Service.

2. Domain Name Service

The Network Engineering Team (NET) is responsible for implementing and/or delegating Domain Name Service (DNS) for ALL systems connected to the campus network, and for coordinating this service with other campus units. DNS provides mapping between domain names and their IP addresses used for routing of network traffic to all destinations.

3. 3rd Level Domain Names

A 3rd level domain name is that portion of the name immediately preceding OSU's registered domain name. OSU departments, programs and approved activities are eligible to use OREGONSTATE.EDU domain names upon request to the Network Engineering Team. This request must be from a dean or department head and will either be approved by the IS OSU Domain Name Review Committee or forwarded to the Associate Provost for Information Services for consideration. REQUESTS should be made to Network Engineering.

Typically, a department or organization would apply for a 3rd level domain name which implies its name or function as in the examples below.

Unit Domain

  • a college: engr.OREGONSTATE.EDU
  • a program: smile.OREGONSTATE.EDU
  • a team: net.OREGONSTATE.EDU
  • a server: ftp.OREGONSTATE.EDU

In general, workstations and server names should be at the 4th level, behind a 3rd level domain name, in which case consultation with NET is unnecessary. To be considered for a 3rd level name a server would need to be of global interest to the Oregon State University community. Example: ftp.OREGONSTATE.EDU

Network administrators may assign/create additional subdomains, aliases (using CNAMES), or machine names behind their own 3rd level domain name, again without the need to consult NET. For example:

  • machine name rex.NWS.OREGONSTATE.EDU
  • alias beasley.UCS.ORST.EDU

4. Non-OSU registered Domain Names

All domain names pointing to OSU network addresses (IP space) must be approved by the IS Domain Name Committee and maintained by Network Engineering. To be considered, a "non-OSU registered" domain name must be requested by a dean or department head, be consistent with the OSU Acceptable Use Policy (OSU AUP), and it must be demonstrated why the requested name should not be within OSU registered domain name space (i.e. OREGONSTATE.EDU).

Domain names used as aliases to content provided entirely by OSU may be approved only on the condition that the URL is rewritten to reflect an OREGONSTATE.EDU domain name. For example, a hostname like might be approved on the condition that when visitors put into their browser, the URL is rewritten to

Requests should be sent to Network Engineering and will either be approved by said committee or forwarded to the Vice Provost for Information Services for consideration.

In all cases, departmental workstations and servers on OSU's network will be registered in the department's domain. This is reflected in the DNS registration of the IP address, otherwise known as a DNS "A Record". This assures that network administrators can always determine at least what organization/department claims responsibility for that machine. These machines may then be assigned approved aliases using CNAMES, as in the following examples.

Alias Machine name (CNAME) Responsible Group

www.FORESTLEARN.ORG     COF.OREGONSTATE.EDU              College of Forestry
alumni.OREGONSTATE.EDU  www.ORST.EDU                         WebWorks         cn-mom.tss.OREGONSTATE.EDU   Technology Support Services

5. No Fees for Assignment of Domain Names

The creation of domain names by NET is done free of charge. However, other  services associated with a name, such as web server or web page hosting, may not be free. These services are available on a cost recovery basis from IS (Central Web Services) and possibly other departments.

6. Naming Conflicts and Priority

Domain names are generally available on a first-come, first-served basis. In cases where a desired name or alias/CNAME is already taken, NET can explain the options. NET surveys the database regularly to avoid naming conflicts and preserve the OSU AUP and otherwise protect the interests of Oregon State University.

7. Unacceptable Domain Names

The Oregon State University network is for instruction and research use only, as indicated by the OREGONSTATE.EDU domain name suffix. In general, other suffixes such as ".com", ".net", etc., are not acceptable for OSU domain names. Requests for inappropriate domain names - names that are not consistent with OSU's mission and the OSU AUP - will be not be approved.

Reasons for rejecting applications for 3rd level domain names include but are not limited to the following.

If in the opinion of the Domain Name Review Committee:

  • The implied scope of the name exceeds the intended use of the name as indicated in the Domain Name Application.
  • The requested name would generally be considered vulgar or offensive or would reflect poorly on Oregon State University.
  • The proposed activity to which the requested name would be attached would violate the Oregon State University network AUP.

Individuals and groups wishing to host servers, websites or networks that are outside the scope of the OSU acceptable use policy will be required to obtain Internet service and Domain Name Service from a local or national Internet Service Provider (ISP).

8. Exceptions

Unusual name requests, circumstances, and issues will be referred to the Director of Network Engineering and/or the IS Management Group for further consideration, as appropriate. Final determination will be subject to the approval of the Associate Provost for Information Services. Decisions of the Domain Name Review Committee may be appealed to the Vice Provost for Information Services.

9. Problem Resolution

In cases where faculty and staff are involved in creating or hosting an unacceptable domain name on a system that uses an OSU IP address, NET will first contact the individual and attempt to resolve the issue directly.

If this fails, the Department head and the Director of Network Engineering will be notified. When undergraduate or graduate students are involved, whether on the residence halls network or elsewhere, the responsible manager will contact the student first to attempt to resolve the issue. Failing this, the student will be referred to the office of Student Affairs and the Director of Network Engineering (Shay Dakan) will be notified.

11. OSU Recourse

If issues are not resolved in a timely fashion, NET is authorized to

a) remove the inappropriate domain name or alias/CNAME
b) filter the system's IP address or
c) disconnect the system from the network,

depending upon the nature and severity of the problem. Notice of any such action will be provided to the responsible parties and units, as well as to the Information Services Management Group.

Network Outage Policy

Our standard Outage windows are as follows:

  • Saturday 10:00PM - Sunday noon
  • Tuesday and Thursday mornings before 8:00AM
  • Holidays and Breaks

NOTE: These are general outage windows. For some services, these outage windows may not be appropriate, and another time may be chosen. Network Engineering will work with affected units to minimize outage impact on their operations.

Maintenance that does not cause service interruption may be performed at other times, depending on the scope and potential impact of the change.

All planned outages will be announced no later than two (2) business days before the outage. Emergency outages may need to be performed at other times and will be announced as soon as possible.

All outages will be announced on the Outages mailing list and will be posted to the Outages Log here:

Maintenance work that is non service-impacting will be announced to the Maintenance Log, posted here:

Network Security Policy

Oregon State University Network Security Policy
May 26, 2000

OSU's network shall be run in a secure manner, with reasonable steps taken to protect electronic data assets owned and/or managed by Oregon State University, and the transmission of them.


Information Services is the appropriate agency to manage and register data networks and their connection to other data networks for Oregon State University. Network Engineering is responsible for the design, maintenance, and operation of the overall OSU network. Each department has the responsibility to run their sub networks in a manner consistent with University Policies and consistent with the University Mission and Goals.


All computers connected to OSU's network must have the appropriate authorization from a recognized representative of OSU. All such authorized computers will be allowed to use an Internet Protocol (IP) address within the class B address space owned and managed by OSU in addition to other communications protocols as appropriate. All computers connected directly to OSU's network are subject to this policy.

Actions to be taken by Network Engineering Team (NET) personnel for various Network Security Events as defined later in this document:


  • CERT - Computer Emergency Response Team
  • DOS attack - Denial of Service Attack
  • NET - OSU Network Engineering Team
  • Network - An arrangement of hardware, software, and end stations interconnected to allow sharing of electronic information.
  • Network Administrator - Person responsible for the network on which the affected node resides.
  • Port Scan - Programmatically connecting to more than one TCP port and/or more than one machine.
  • Security event - Actions taken on the network which jeopardize, or threatens to jeopardize, the integrity of OSU's Network (or other Networks) or actions which violate Federal or State Law.
  • SPAM - Unsolicited bulk email
  • System Administrator Person responsible for the affected node.

1. Monitoring. NET will take reasonable steps to monitor the campus network in a way that will detect common network attacks originating either on or off campus.

2. Reporting of Security Events. Security Events are to be reported to the email alias and to the node and or network administrator originating the event. Reports made by phone must be followed up with an email report. In addition to log files showing dates, times, and specific host information regarding the event, the report must include the name and contact information for:

  • The person making the report.
  • The victim(s) of the event.
  • The likely perpetrators of the event.

3. Response. Once NET has determined the nature of the Event, and has an understanding of who is doing what to whom, the following actions may be taken by NET personnel:

  • Disable access to local hosts.
  • Filter remotes sites from campus network.

Both of these actions will usually be done at the campus border router in which case, email will be sent to the following aliases informing them of the block:

Assuming there is no evidence that the system has been compromised, the following aliases will also be informed:


In some cases, it may be appropriate to disable access to a node at a point closer to the node than the border router.

For single user workstations it may only be possible to notify the Network administrator.

  • Notify appropriate System Administrator and/or Network Administrators.
  • Notify OSU Director of Network Services.
  • Notify OSU campus legal authorities.
  • Notify law enforcement agencies.
  • Notify CERT.
  • Report incident to other sites which track specific types of abuse, ie SPAM.
  • Consult with local system and network administrators in securing their departmental networks.

4. Re-enabling of blocked hosts. Hosts that have had their access to the network blocked by NET will be re-enabled once NET Security personnel have a reasonable belief that the system is no longer a security risk.

OSU Mailing List Policy

Information Services fully supports the use of the University's computing and networking resources by the OSU community. Information Services has a responsibility to ensure these resources are being used responsibly, and must be in a position to take corrective action should a problem occur.

OSU Mailing lists are currently hosted on Mailman. Information about this service can be found here:

IS will support mailing lists that meet the following guidelines:

  • Maintenance of the list is performed by a member of the faculty, staff, or student body who is the owner of the list. The owner confirms that the list meets the guidelines on this page. The owner is the contact in the event a system problem arises, or an abuse of the network is detected.
  • A list owner is designated to maintain the list, answer inquiries, track down address changes, remove subscribers who violate list guidelines, and remove addresses causing mail loops. When absent, the owner must ensure that an alternate performs these tasks.
  • The list owner (or alternate) must read mail regularly.
  • The purpose of the list is for OSU-related business.
  • Use of the list conforms to the Acceptable Use Policy of OSU.
  • In situations where the list is interfering with normal operation of the computer system or network, IS will notify the owner (or sponsor). IS will shut down the list if the problem is not corrected promptly.
  • In the event that a list is running without a list owner, due to a retirement or re-location, Information Services will contact the list and give a two week deadline to find a new owner. IS will have no alternative but to shut down the list if a new owner is not located within the two week period.

Out-of-Band Policy

The IS OOB network is intended for out-of-band access to systems in the Milne and Kerr data centers. To connect a system to the OOB network, please contact for assistance.

Users of the OOB network are subject to the following use policy:

  1. No person shall dual-home a host on the OOB network and the OSU network. OOB gateway hosts will be provided by IS and access will be restricted to registered OOB users only.
  2. No person shall attempt to gain access to a system they do not manage on the OOB network.
  3. System administrators should change the default password for all OOB connections.
  4. System administrators shall notify the OOB gateway managers of any issues or need for special software.

OpenNMS Server Monitoring

Network Operations uses OpenNMS to monitor servers for several groups on campus.

Publicly-Viewable Reports

Service or node outages can be configured to send email or generate pages, or both. The web interface allows you to view past and current outages, and acknowledge outage notifications.

If your department has servers that need to be monitored, please email us for more information.

OpenNMS Accounts

Full access to OpenNMS requires an account. Contact us to request a user account. Please include your first and last name, department, and preferred username if you do not want one generated for you.

Once you get your account you should be able to login at the OpenNMS login page.


Testutil is a utility for Linux and Solaris servers that will monitor cpu, memory, disk utilization and mail queue size and send traps to OpenNMS. Contact us for download information and to configure notifications.

Network Security at OSU

Network Security Contacts

  • Network Abuse Reporting
  • Security Reports (investigation)
  • Senior IT Security Analyst
    • Email: Rich Giesige
    • Phone Contact: 541-713-0256
    • Handles: Escalated Security Issues

Campus Firewall Project

The campus firewall is designed with the following goals in mind:

  • High availability, performance and redundancy
  • Usability of the network preserved without creating barriers to information sharing
  • Distributed control of firewall rulesets to colleges/departments

Please see the Campus Firewall page for more information.

Scanning & Security Analysis Services

Information Services is currently evaluating the Nessus security scanner.

Client-Side Security

Helpdocs has information on client-side solutions such as SSH and key encryption.

OSU IP Ranges

Range CIDR Group - /16 OSU public netblock - /8 OSU private netblock - /24 Oregon University System - /24 OSU - /24 County Extension, Ag Experiment Stations - /24 County Extension, Ag Experiment Stations - /23 OSL - /20 County Extension, Ag Experiment Stations

OSU Wireless Network

Wireless networks at OSUInformation Services provides consolidated wireless network access through the OSU Wireless Network. Hundreds of dual-band (2.4 GHz and 5 GHz) access points give students, faculty, and staff access to the high-speed 802.11n network throughout the campus.

Please note that some laptops and most phones are not equipped to access the higher (5 GHz) band. Laptops require a "dual band adapter" and only the very newest, top-end Android phones include a 5 GHz adapter. Please consult the OSU Computer Helpdesk if you have questions about purchasing equipment that lets you access the high-speed network.

Wireless Networks for ONID and OUS Users

Anyone who has a valid ONID or OUS account will have access to our networks. For more information, please see the Wireless helpdoc page.

  • OSU_Secure is the preferred network for ONID users on campus. It's an encrypted connection which allows for secure online browsing.
  • OSU_Access is an unsecured connection for ONID users on campus that's meant for quick sessions and simple web browsing. For this network, your computer or mobile device should be registered with Maintain so that you don't have to manually sign in to the network with each session.
  • Visitor is a network for brief connections. As the name suggests, this network does not require the user to have an ONID account.
  • eduroam is for visitors from off campus who are members of the eduroam federation.

Wireless Network IP Ranges

SSID IP Ranges