Red Hat Bugzilla – Bug 1247286
rhos-d uses non-RFC1918 address schemes, possible external conflicts
Last modified: 2016-10-14 16:38:13 EDT
Description of problem:
In undercloud.conf and other places non-RFC1918 address ranges are used for private networks. This can cause problems as these networks are associated with ARIN for testing (or may be allocated externally). The network ranges in question are 192.0.2.0 based.
Please use an RFC1918 address range:
% IANA WHOIS server
% for more information on IANA, visit http://www.iana.org
% This query returned 1 object
inetnum: 192.0.2.0 - 192.0.2.255
dig 0.192.in-addr.arpa ns
; <<>> DiG 9.10.2-P2-RedHat-9.10.2-3.P2.fc22 <<>> 0.192.in-addr.arpa ns
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60507
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;0.192.in-addr.arpa. IN NS
;; AUTHORITY SECTION:
192.in-addr.arpa. 10800 IN SOA z.arin.net. dns-ops.arin.net. 2015062452 1800 900 691200 10800
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Adding, 192.0.2 is reserved via IANA as a "testnet" used for documentation.
192.0.2.0/24 TEST-NET-1 RFC 5737
"The blocks 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2),
and 203.0.113.0/24 (TEST-NET-3) are provided for use in documentation."
For undercloud deployments or internal purposes this type of range shouldn't be used, we should stick to RFC1918 allotment.
Created attachment 1056693 [details]
Attached: Example undercloud.conf.sample shipped
Attaching undercloud.conf.sample used with 192.0.2.x addressing scheme.
This bug did not make the OSP 8.0 release. It is being deferred to OSP 10.
(In reply to Will Foster from comment #4)
> Created attachment 1056693 [details]
> Attached: Example undercloud.conf.sample shipped
> Attaching undercloud.conf.sample used with 192.0.2.x addressing scheme.
I disagree that we are misusing the network 192.0.2.x as the default in our ctlplane configuration. The whole reason this range was chosen is that it is for documentation and examples. We definitively do not want people deploying in production with 192.0.2.x, so the default is actually intended to encourage people to choose their own subnet. Perhaps we could do a better job documenting that.
This is in contrast to the isolated networks, where we chose 172. addresses specifically to indicate that they are private, and the defaults may be used as-is.
If there were a similar "example" network available that would be a good fit for the External network default (currently 10.0.0.0/24), I would prefer to use that, because this is another network that we intend for people to customize.