# Components of IPAM Infraon IPAM organizes IP addresses in a hierarchical structure, allowing large blocks to be divided into manageable groups. This structure helps categorize IP ranges by **location, department, network zone, or business unit.** The hierarchy includes:

Level	Description
Container	Top-level grouping for IP ranges. Used to represent major network categories such as regions or sites.
Subcontainer	A logical division under a container. Used for smaller segments such as buildings, zones, or departments.
Block	Grouping of subnet ranges under a subcontainer. Helps organize networks before allocating subnets.
Subnet	Defines the actual IP range. All IPs in the subnet are populated and monitored from this level.

## **Add Components** * Navigate to **IPAM → Containers** to add a component. * Click **Add Items**, select the required component, and refer to the sections below for instructions on adding each type. ![](/files/41a98ab1fcd388b4e59bbb48bff87fbf55c75c7b) ### **Container** A Container is the highest-level grouping of an IP address space within IPAM. It represents a broad logical or organizational boundary under which all further subdivisions are created. Why does it exist? * Helps organize large IP ranges by major categories (e.g., location, customer, region). * Allows role-based access control (visibility can be limited to specific users or teams). * Provides a top-level view of total, used, and available IPs across multiple subnets. Example If a company manages IP networks for multiple cities:

Location	Container
Bengaluru Data Center	DC-Bangalore
Mumbai Corporate Office	Office-Mumbai
Remote Branches	Branch-Networks

Each of these becomes a **Container**, and further IP structures are created under them. #### **Add Container** Add Container **| Basic Details**

Label	Action	Description / Example
Container Name*	Enter name	Name of the top-level IP group. Used to represent large network areas such as regions or data centers. Example: Bangalore-DC
Description	Enter description	A summary explaining what the container represents. Example: Primary Data Center for South Region
IP Version*	Select IPv4 or IPv6	Select the IP protocol for the container. Only one version can be chosen per container. Example: IPv4
Network Address*	Enter the CIDR base address.	Starting network range for the container in CIDR format. This defines the highest-level range under the container. Example: 10.0.0.0
CIDR Prefix*	Select prefix	Defines the container's range size. Example: 8 (Large enterprise range)
Customer	Select a customer from the drop-down list.	Assigns the container to a specific customer (valid in MSP environments). Example: Sify Telecom
Entity	Select an entity from the drop-down list.	Internal segmentation within a customer, such as a business unit or division. Example: IT Infrastructure
Users	Select users from the drop-down list.	Assigns visibility to specific users. Only assigned users can view the container.
Teams	Select teams from the drop-down list.	Grants selected teams access to view or manage the container.
Roles	Assign roles from the drop-down list.	Defines the role-based access for the container (e.g., Viewer, Admin).
Breach Threshold*	Enter % value	Sets a percentage threshold for IP utilization alerts. Alerts trigger when usage exceeds the threshold. When breached, an event will be generated. Example: 80 means alerts when 80% IPs are used

{% hint style="info" %} Fields marked with an asterisk (\*) are mandatory. {% endhint %} ![](/files/c11f734cab19c731ec68c8e7fd6340822b2edd28) {% hint style="success" %} Click **Submit** to create the container and add it to the hierarchy. {% endhint %} ### **Subcontainer** A Subcontainer is a subdivision of a Container that categorizes IP ranges into more specific operational or physical groups. Why does it exist? * Break down networks further into zones, departments, buildings, or customer segments. * Allow logical separation within a large site while keeping all IPs grouped under the same parent container. Example Under the Container DC-Bangalore: | Zone | Subcontainer | | ---------------- | ------------ | | Core Network | Core-Segment | | Server Rack Area | Rack-Zone | | Wireless Network | WiFi-Zone | This structure helps identify where IPs are being used within a site. #### **Add SubContainer** Add SubContainer **| Basic Details**

Label	Action	Description / Example
Sub container Name*	Enter name	Name for the subdivision under the selected container. Example: Rack-Zone
Description	Enter description	Summary describing the purpose of the subcontainer. Example: Racks and server zones for core networking
Container*	Select from the drop-down.	Select the parent container under which the subcontainer will be created. Upon selecting a container, the Customer and Entity fields auto-populate based on the container’s configuration.
CIDR Prefix*	Select prefix	Select the prefix range for the subcontainer. Example: 13 to 15.
Network Address*	Select from the drop-down.	Select a predefined IP range inherited from the parent container. The subcontainer inherits the base CIDR from the selected container and does not allow manual IP entry; only available sliced segments can be chosen. Example: Selecting the container 10.0.0.0/8 may list segmented ranges, such as 10.2.0.0/15, for selection.
Customer	Auto-filled or select	Automatically inherited from the selected container. This field cannot be changed.
Entity	Auto-filled or select	Automatically inherited from the selected container. This field cannot be changed.
Users	Select users from the drop-down list.	Assigns visibility to specific users. Only assigned users can view the container.
Teams	Select teams from the drop-down list.	Grants selected teams access to view or manage the container.
Roles	Assign roles from the drop-down list.	Defines the role-based access for the container (e.g., Viewer, Admin).
Breach Threshold*	Enter % value	Sets the utilization alert threshold for this subcontainer. Example: 80

{% hint style="info" %} Fields marked with an asterisk (\*) are mandatory. {% endhint %} ![](/files/fcb9fb0bf1dd1baefff21abce56482984f06e04e) {% hint style="success" %} Click **Submit** to create the container and add it to the hierarchy. {% endhint %} ### **Block** A Block is created under a Subcontainer to group multiple related subnets into a single logical category. Blocks help organize subnet allocations based on network function or architecture. Why does it exist? * Used when multiple subnets belong to the same functional area (e.g., Access Layer, Server Networks, Storage) * Helps structure subnet allocation under larger segments inherited from the Subcontainer * Supports more straightforward navigation and management of grouped subnets Example Under Subcontainer **Rack-Zone**, blocks may be created, such as: | Network Layer | Block Name | | ------------------ | ------------- | | Access Layer IPs | Access-Block | | Management Network | Mgmt-Block | | Storage Network | Storage-Block | Each block will then contain subnets related to that network layer. #### **Add Block** * Block must be created under an existing **Subcontainer.** * **Customer** and **Entity** values are inherited from the parent Container and cannot be modified. * Network Address and CIDR are selected from available inherited ranges (16-23), not manually entered. * Blocks define mid-level segmentation before subnet allocation. ![](/files/4606753dd8e547a997e99a3b17ece138e6d2ffd3) ### **Subnet** A Subnet defines the actual IP range. When a subnet is added, all IPs within that range are automatically generated, scanned, and tracked individually. Why it exists * This is the operational level where IPs are assigned to devices. * IP status, history, hostnames, MACs, and scan data are captured at this level. * Scanning workflows occur at the subnet level. Example Under Block Access-Block: | Purpose | Subnet | | ------------------ | --------------- | | Access Switch VLAN | 192.168.10.0/24 | | Printer Network | 192.168.11.0/24 | IPs inside 192.168.10.0/24 will be listed:192.168.10.1, 192.168.10.2, …, 192.168.10.254 Each IP has a status such as In Use, Free, Transient, etc., determined by scanning. #### **Add Subnet** Add Subnet **| Basic Details**

Label	Action	Description / Example
Subnet Name*	Enter name	Name of the subnet for identification. Example: Access-VLAN-10
Description*	Enter description	Purpose of the subnet. Example: Subnet for access switches in Rack Zone
Container*	Select from the dropdown	Select the container under which the subnet belongs.
Subcontainer*	Select from the dropdown	Select the subcontainer to place the subnet in. Example: Rack-Zone
Block*	Select from the dropdown	Subnets must be created under a block. Example: Access-Layer
CIDR Prefix*	Select prefix	Defines the subnet size. Range (as per UI): /24 – /32.
Network Address*	Select from the dropdown.	Select a predefined subnet range sliced from the block. Manual entry is not supported. Example: 10.10.0.3
Customer*	Auto-filled	Inherited from the parent container and cannot be modified.
Entity	Auto-filled	Inherited from container; cannot be changed.
Users	Select from the dropdown	Assign specific users to the subnet. Example: Network Admin Team
Role	Select roles	Defines access permissions, such as Viewer or Admin.
Teams	Select team	Assigns visibility to specific teams.
Breach Threshold*	Enter a numeric value	Trigger alert when subnet usage reaches the threshold. Example: 80 (alert when 80% IPs are used)
Data Collector*	Select data collector	Select a dedicated data collector responsible for scanning this subnet. Ensure data collectors are mapped in the default schedule configuration.

![](/files/0c887e34598dae7af73ebca3fad34160cf1ea2b2) #### **Scan Configuration** Once subnet details are entered (such as name, container, block, and breach threshold), the next step is to configure network scans. These scans help validate IP availability and retrieve device information from the subnet. Infraon IPAM supports **two types of scans**: * **Availability Scan** → Identifies which IPs are active or reachable. * **Inventory Scan** → Retrieves device-level information (e.g., ports, interfaces, SNMP details). ![](/files/8c3f5af78ebc2b005627244efc361a57b81c3837) The user can enable either or both using toggle options. #### **Availability Scan** Check whether IPs in the subnet are reachable and active on the network. | Reason | Outcome | | --------------------------------------------- | ------------------------------------------ | | **Detects unused or free IPs** | Helps avoid conflicts & manage allocations | | **Confirms IP is live** | Useful for tracking utilization | | **Ensures accuracy beyond manual assignment** | Reduces stale or outdated IP records | **Scan Method** | Scan Method | Description | When to Use | | ----------- | ---------------------------------------------------- | ------------------------------------------------ | | **Ping** | Uses ICMP packets to confirm if an IP responds | Basic availability checks where ICMP is allowed | | **Port** | Probes predefined TCP/UDP ports to test reachability | When ICMP is blocked, but service ports are open | **Ping Configuration**| Basic Details

| Field | Description | | -------------------- | ------------------------------------- | | **No. of Packets\*** | Number of ICMP packets to send | | **No. of Workers\*** | Parallel probes are used for scanning | | **Timeout\*** | Time allowed for response | | **No. of Retries\*** | Attempts before marking unreachable | **Port Configuration** | Basic Details

| Field | Description | | ---------------- | ----------------------------------------------------------------------------- | | **TCP Ports\*** | Comma-separated TCP ports to probe | | **UDP Ports\*** | Comma-separated UDP ports | | **Port Range\*** | Allows specifying range (e.g., 20-25,80,443) — visible in Inventory scan mode | #### **Inventory Scan** Collects detailed device information for responding IPs, helping build inventory-level mapping. | Reason | Destination Output | | --------------------------------------- | --------------------------------- | | **Identifies device type & OS** | Helps classify address usage | | **Retrieves port/interface info** | Useful for root-cause mapping | | **Captures SNMP & switch port mapping** | Enables network topology tracking | When **Inventory Scan** is enabled, it shows two cards: * Port * SNMP **Port Configuration |** Basic Details Same as in Availability Scan, but the **label may appear as "Port Range"** to define multiple ports efficiently. **Example:** 22,80,135,139,445,3389,5985,5986,443. ![](/files/1def11b54dd395b14da24daa0ea8de7c2d5558f2) Confirms device availability and retrieves running services based on open ports. **SNMP Configuration |** Basic Details

Field	Description
Scan Credentials*	Select SNMP credentials already configured.
Inventory Scan	Retrieves system-level information, including device details, MAC addresses, and interface data, via SNMP. Scan identifies active hosts and collects hardware-level attributes for accurate IP asset classification.
Switch Port Map Scan	Maps switch interfaces to connected devices.
Interface	Collect interface statistics
Retry	Number of retry attempts
No. of Workers*	Number of threads used during scan

After configuring the subnet and scan settings, click **Next** to move to the Scheduling stage, where you can define when scans should run. #### **Schedule** After submitting subnet details, the final step is to configure how and when the subnet scans run. Scheduling automates availability checks, eliminating the need to trigger scans manually every time. This stage appears after clicking **Submit** in the “Add Subnet” form. You can choose one of the following:

Option	Description	When to Use
Default Schedule	Uses the platform-wide schedule defined in IPAM settings. Applies the exact scan timings for all subnets.	Suitable for standard periodic scans across all networks.
Custom Availability Schedule	Allows defining a unique schedule specifically for this subnet. Overrides the global schedule.	When specific networks require a different scan frequency or timing.

If “Custom Availability Schedule” is selected, the following frequency options are provided: **Scheduling Mode |** Basic Details

Mode	Purpose	Example Use Case
Once	Run the scan once at a scheduled date/time.	Initial scan when onboarding a new subnet.
Every	Runs repeatedly after a fixed interval.	Scan every 6 hours for dynamic DHCP networks.
Daily	Runs once per day at a set time.	Daily tracking for branch office networks.
Weekly	Runs weekly on a specific day/time.	Audit weekend scans to reduce traffic.
Monthly	Runs once a month at a specified date/time.	Governance-based IP reporting schedules.

**Scheduling Fields |** Basic Details

Label	Description	Example
at*	Select a date and time for the scan execution	21 November 2025, 11:30 AM
Summary Message	Displays a confirmation summary of the scheduled time	Scheduled on 21 November 2025, 11:30

![](/files/d3b4cbdf549b080c4611cb022c279e8eebcfe3cb) Click **Submit** to save the schedule and complete subnet creation. The subnet will now appear in the Container hierarchy and follow the defined scan timings. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.infraon.io/infraon-help/infinity-user-guide/ipam/components-of-ipam.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.