Bug 1268426 - [DOC][Director] Document Scanning Provisioning Network for IP Conflicts
[DOC][Director] Document Scanning Provisioning Network for IP Conflicts
Status: CLOSED CURRENTRELEASE
Product: Red Hat OpenStack
Classification: Red Hat
Component: documentation (Show other bugs)
7.0 (Kilo)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: 8.0 (Liberty)
Assigned To: Martin Lopes
Deepti Navale
: Documentation
Depends On:
Blocks: 1269041
  Show dependency treegraph
 
Reported: 2015-10-02 15:25 EDT by Dan Sneddon
Modified: 2016-02-22 00:14 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Known Issue
Doc Text:
There is a known issue that can occur when IP address conflicts are identified on the Provisioning network. As a consequence, discovery and/or deployment tasks will fail for hosts which are assigned an IP address which is already in use. You can work around this issue by performing a port scan of the Provisioning network. Run from the Undercloud node, this will help validate whether the IP addresses used for the discovery and host IP ranges are available for allocation. You can perform this scan using the nmap utility. For example (replace the network with the subnet of the Provisioning network (in CIDR format)): ---- $ sudo yum install -y nmap $ nmap -sn 192.0.2.0/24 ---- As a result, if any of the IP addresses in use will conflict with the IP ranges in undercloud.conf, you will need to either change the IP ranges, or free up the IP addresses before running the introspection process, or deploying the Overcloud nodes.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-01-17 18:19:57 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dan Sneddon 2015-10-02 15:25:08 EDT
Description of problem:
We should document how to detect IPs in use on the provisioning network. Several deployments at customer sites have failed because it turned out that the discovery or host IP ranges already had IPs in use on the network.

Version-Release number of selected component (if applicable):
OSP-D 7 GA

Additional info:
Here is the content I am adding to the Network Reference Architecture:
=================================

It is important to make sure that there are no IP conflicts on the Provisioning network. Perform a port scan on the Provisioning net from the Undercloud if you are not certain that the IPs used for discovery IP range and host IP range are free (replace the network in the nmap command with the IP subnet of the Provisioning network in CIDR bitmask notation).

######
$ sudo yum install -y nmap
$ nmap -sn 192.0.2.0/24
######

For example, you should see the IP address(es) on the Undercloud, and any other hosts that are present on the subnet:

######
$ nmap -sn 192.0.2.0/24

Starting Nmap 6.40 ( http://nmap.org ) at 2015-10-02 15:14 EDT
Nmap scan report for 192.0.2.1
Host is up (0.00057s latency).
Nmap scan report for 192.0.2.2
Host is up (0.00048s latency).
Nmap scan report for 192.0.2.3
Host is up (0.00045s latency).
Nmap scan report for 192.0.2.5
Host is up (0.00040s latency).
Nmap scan report for 192.0.2.9
Host is up (0.00019s latency).
Nmap done: 256 IP addresses (5 hosts up) scanned in 2.45 seconds
######

If any of the IPs in use conflict with the IP ranges in undercloud.conf, you will need to either change the IP ranges or free up the IPs before introspecting or deploying the Overcloud nodes.
Comment 4 Andrew Dahms 2015-10-08 19:53:42 EDT
Assigning Deepti as the QA contact.

Deepti - could you take a look at the content above?
Comment 5 Deepti Navale 2015-10-08 23:42:12 EDT
Content looks good. Changing to VERIFIED.
Comment 6 Andrew Dahms 2016-01-17 18:19:57 EST
This content is live on the Customer Portal.

Closing.

Note You need to log in before you can comment on or make changes to this bug.