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 the following figure:

 Locating conflicts and beginning their resolution

Numerous types of conflicts are possible:

• Device Information conflict

• Port Reservation conflict, including Used Port Reservation conflicts (usually resulting from a request to reserve a port that has already been assigned to another IPAM object)

• Fixed address conflict

• IP Address conflicts

• DHCP Range conflicts (such as: Discovered address is within an existing DHCP range but does not match an existing lease, fixed address, or exclusion range)

• MAC Address conflict (such as: Discovered MAC Address conflicts with existing fixed address).

The Conflict Resolution wizard automatically recognizes the object associated with the conflict (which is listed in the Related Objects pane as noted in the previous figure Figure 15.27) and ensures that changes you make during resolution are applied correctly to the object. An example appears in the following figure:  Conflict resolution example

Resolving Port Reservation Conflicts

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:

1. Click the link provided in the Conflicts Smart Folder.

2. Expand the Toolbar and click Resolve Conflict, as shown in the above figure - Locating conflicts and beginning their resolution.
   The Resolve Port Reservation Conflict dialog opens, showing the differences between the reserved and discovered information.

3. Choose from the following options:

   • Change the reserved port to be the same as the discovered port.

   • Keep the configured port reservation and clear the conflict for the next 1 day(s).
     Note that 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 about defining seed routers for probe members, see Configuring Discovery Properties.

4. Click OK to save changes.

Another category of conflicts involves incorrectly defined device information for the object:

• The reserved Device Type information provided is different from the discovered vendor and device type (Router vs. Switch, for example).

• The defined Device Vendor information does not match with the discovered information.

• A User Port Reservation conflict occurs when an unmanaged IP address attempts to use a port that is already reserved by an IPAM object on a different IP address.
  
  You can choose from the following options:

  • Change configured information to discovered information.

  • Keep the current device configuration and clear the conflict for the next 1 day(s).

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.

Resolving Multiple Conflicts

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:

1. To quickly locate any conflicts, open the Smart Folders panel and open the Conflicts list.

2. Click the IP address for any entry in the Conflicts list. The IPAM page opens for the selected IP address, with the top panel highlighted in pink to indicate the conflict.

3. Open the vertical toolbar and click Resolve Conflict.

4. If multiple issues are involved with the conflict entry, the Resolve Conflicts wizard lists each of them as shown in the following figure:
   
   Resolution of Multiple Conflicts

   Open

   

    

5. 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 the previous 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 the following figure:
   
   Troubleshooting the first selected conflict

   Open

   

    

   1. In this case, the MAC address specified in the last fixed address object configuration, for that object, conflicts with the discoveredMACaddress associated with the IP. (You can verify this by checking the RelatedObjects tab in the IPAM page for the IP address.) Choose from one out of two options:

      • Change the configured MAC address to be the same as the discovered MAC address;

      • 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.

6. Select the Update... with discovered data option and click Resolve.
   The wizard updates with a return to the first step, in which you select the next conflict to resolve. A banner shows the result of the first resolution.

7. Select the next conflict to resolve and click Next. As an example, the following Figure 15.31 shows a device configuration conflict.
   Device Information conflict for an object

    

8. a.  To resolve the conflict, the Configured information must be overwritten with the Discovered information. Choose any of the following:

   • Change configured device type and vendor to be the same as the discovered device type and vendor

   • Keep current device configuration and clear the conflict for the next 1 day(s)

             Other conflict types have similar options.

9. Select from the above choices and click Resolve.

Continue through the wizard to resolve the last conflict associated with the IP address.

Conflict Calculation Between IP Discovered vs DHCP Range and Leases

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.

Principle of Conflicts for DHCP Ranges

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 LEASE IP has the same MAC than the discovered IP. All good. 

• The LEASE IP has a different MAC than the discovered IP. Here a MAC ADDRESS conflict will be seen between the IP discovered and the IP LEASED.

Computation of Conflicts (for RANGE or MAC ADDRESS Conflicts)

The conflicts are computed (raised or cleared) when:

• IP is discovered or re-discovered or has disappeared

• When the DHCP Range is updated (by UI, WAPI, PAPI)

• 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.

When computing a conflict, the process lookup for the IP discovered and verify this against any DHCP Range that includes the same IP:

• No Range : There will be no conflict with the Range (However, there can be other type of conflict see documentation.

• There is a Range, but there is nothing in that IP slot, neither Reservation, Fixed Addresses … or LEASE: this IP is classified to be available for LEASE. If that IP is discovered, it means there is a device that uses that IP without holding the LEASE and a RANGE conflict is raised.

• There is a Range and this IP slot is used by:

  • Reservation or DHCP Reservation: no RANGE conflict.

  • Fixed Address or Host Address: no RANGE conflict. (There can be a MAC Conflict.)

  • LEASE:

    • If the lease has currently no activity or never had any activity (eg BACKUP state). A RANGE Conflict is raised because we consider there is no LEASE.

    • If the lease includes dates of activity (eg ACTIVE, RENEW, ABANDONED, FREE, …) , the “last-discovered” timestamp of the IP is checked against the dates of activity:

    • If the “last-discovered” is BEFORE start of LEASE : we cannot say if there was a conflict or not. A SYSLOG “Maybe conflict - IGNORED” is issued, but no RANGE, neither MAC ADDRESS conflict is raised.

      • If the “last-discovered” is DURING activity of LEASE, it is expected. No RANGE conflict. However if the MAC does not match, a MAC ADDRESS conflict will be raised.

      • If the “last-discovered” is AFTER the activity of the LEASE : a RANGE conflict is raised, as there is no LEASE at time of the timestamp.