You can sometimes encounter conflicts when defining port reservations for IPAM-managed objects such as Fixed IP addresses or host records. The quickest way to locate any conflicts in Grid Manager is to open the Conflicts Smart Folder as noted in Figure15.27.
Figure 15.27 Locating conflicts and beginning their resolution
Numerous types of conflicts are possible:
MAC Address conflict (such as: Discovered MAC Address conflicts with existing fixed address)
When you execute discovery (Discovery -> Discover Now from the Toolbar), the appliance does not send SNMP trap if it finds any conflicting information between the NIOS data and the discovered data.
The Conflict Resolution wizard automatically recognizes the object associated with the conflict (which is listed in the Related Objects pane as noted in Figure 15.27) and ensures that changes you make during resolution are applied correctly to the object. An example appears in Figure 15.28.
Figure 15.28 Conflict resolution example
Sometimes, administrators may accidentally request a device port to be reserved for an IP address when the port is already reserved for another object, or try to apply a different port to an object that already has a port reservation. When these cases arise, Grid Manager reports a conflict.
To resolve port reservation conflicts:
Keep the configured port reservation and clear the conflict for the next 1 day(s).
In the Grid Discovery Properties –> Advanced tab, the Ignore Conflict Duration setting governs the default time duration to ignore (clear) certain types of conflicts that may occur when defining IPAM objects that are associated with discovered and managed devices, interfaces, or IP addresses. Increments can be defined in Hours or Days. For more information, see Defining Seed Routers for Probe Members.
Click OK to save changes.
For other conflict examples, see Resolving Multiple Conflicts.
Another category of conflicts involves incorrectly defined device information for the object:
In virtually all cases, replacing the configured information with the discovered information successfully clears the conflict; click OK to commit changes or to temporarily clear the conflict.
You can define objects for IP addresses, attempt to apply a port reservation, or incorrectly specify a value such as a MAC address or a vendor name, and accidentally cause multiple conflicts after creating the new object.
To resolve multiple conflicts for a particular IP address, use a Resolve Multiple Conflicts wizard:
Select the conflict that you want to resolve first and click Next. For example, consider choosing to resolve the MAC Address conflict as shown in Figure 15.29. The second step of the wizard appears, listing the differences between the Existing and Discovered information for the conflict as shown in Figure 15.30.
Figure 15.30 Troubleshooting the first selected conflict
Keep fixed address and ignore this conflict for the next 1 day(s).
In this example, the Discovered information for the MAC address associated with the Fixed Address object is one digit off from the Existing MAC information, which was entered incorrectly by the administrator. The DIscovered MAC, shown in red, is the correct value and should be used to overwrite the record for the conflict.
Figure 15.31 Device Information conflict for an object
8. Select from the above choices and click Resolve.
9. Continue through the wizard to resolve the last conflict associated with the IP address.
In the Polling tab –> Advanced page of the Grid Discovery Properties editor, the Ignore Conflict Duration setting governs the default time duration to ignore (clear) certain types of conflicts that may occur when defining IPAM objects that are associated with discovered and managed devices, interfaces, or IP addresses. Increments can be defined in Hours or Days. This setting cannot be modified when resolving conflicts.
The Discovery Engine uses several background processes to determine the existence of IPs. Depending on the process the ‘timestamp’ of discovery (last-discovered date) corresponds to a real date by a direct check (ping, SNMP, CLI), or an indirect check (presence in forwarding tables, or ARP tables).
When the check is indirect the timestamp of an IP is NOT real time as compared to a direct check against the device. It means that this timestamp may not be accurate when the device was associated to this IP, but not really at the time denoted by the timestamp. This will have impact when computing conflict with RANGE and LEASE, as the timestamp may be inaccurately stated at a time the LEASE is already ended.
A DHCP Range is an object used for DHCP Service, to define which IP can be temporary allocated to a device using LEASE. It is expected that ONLY the device that hold the LEASE is using this IP.
If an IP is discovered on an IP slot of a DHCP Range and there is no corresponding LEASE, then there is a possible DHCP Range conflict (between the IP and the DHCP Range).
If in case the IP discovered is allocated for a LEASE, then we have two use case scenario:
The conflicts are computed (raised or cleared) when:
Any of the NIOS object that can change the slots in the RANGE are updated (Range reservation, Fixed Address, Reservation …) by UI, WAPI or PAPI.
LEASE operations DOES NOT trigger any recomputation of the conflict.
When computing a conflict, the process lookup for the IP discovered and verify this against any DHCP Range that includes the same IP:
Conflicts based on dates of “last-discovered” timestamp, depends on how the IP was discovered, with timestamps more or less accurate. Then a FALSE POSITIVE conflict can get raised. This condition needs to be manually verified along with the dates, assess the conflict and maybe resolve that conflict manually.
If there is a delay to collect the LEASE from the DHCP Member, a conflict is raised at the time of processing the IP, because the corresponding LEASE was not yet consolidated on GM. This require a manual assessment of the conflict, and needs to be resolved manually.
This page has no comments.