Please report any problems to email@example.com or use our support form. See release notes for more info https://wiki.doit.wisc.edu/confluence/display/ST/Confluence+5.7.1
IPv4 Allocation Guidelines
- Customer requests IP allocation from DoIT Network Services. Submission of request is acceptance of IP Allocation Policy Terms.
- Each IP allocation request needs to have an explanation of why address space is needed, which will be recorded for future reference.
- Request will undergo due-diligence by Operations Engineer. Due-diligence will include, but not be limited to:
- What subnets is customer currently responsible for?
- What is the utilization of current subnets?
- Does current utilization meet IP Allocation Policy requirements or can current subnets be reconfigured to satisfy customers needs?
- Is allocation replacing existing subnet or for new purpose? If replacing existing subnet, a tentative time frame to reclaim subnet will be established.
- Best judgment will be used when approving or denying allocation request. Allocations of up to a /23 maybe made by an individual. Assuming the resource is available, allocations of a /22 or larger will require additional review by the Network Engineers group.
- Unless there are extraordinary circumstances, a current subnet will at most be doubled in size (e.g., /26 to /25, /25 to /24, etc.).
- All requests for additional space will try and be satisfied by replacing original Classless Inter-Domain Routing (CIDR) block with a larger CIDR block for subnets that are /26 or smaller, unless there are specific technical requirements that can only be solved by a using a secondary address (firewalls, etc).
- When a customer asks to increase from a /25 or larger space, additional scrutiny will be give to whether a single larger CIDR will provide good IP utilization. For example, if a department with a /25 expects to only add 30 hosts over the next twelve months, it may be prudent to set aside a /26 secondary instead of using another /25.
- Auditing will be done (at least) annually from the date allocation was configured on the network.
- Data collection will be at a time scale that will provide high quality trend data with an accurate profile of usage - including cyclical or other patterns of variable usage that might be missed if data were collected infrequently.
- Is subnet utilization at least 40%? If not, is usage trending upward, downward, or unchanged?
- Is the lack of utilization the result of extraordinary circumstances (e.g loss of project funding and/or loss of personnel, etc)?
- Acceptable forms of utilization auditing, in order of preference:
- Allow Network Services to login and scrape router ARP tables at regular intervals (preferred 15 min). If customer already gathers or maintains this, or similar data, arrangements will be made to either allow Network Services access to this data or some type of data transfer will be made (i.e. ftp to a DoIT-run host)
- Allow Network Services to snmp poll data collected at regular intervals. If customer already gathers or maintains this, or similar type, information arrangements will be made to either allow Network Services access to this data or some type of data transfer will be made (i.e. ftp to a DoIT run host)
- A co-located host on customer's subnet that will be used only to gather subnet statistics
- Daily DHCP leases file (transferred in similar fashion as ARP/SNMP data)
- Ping sweep of subnet (this might not be viable due to possible number of host based firewalls)