preface

In the previous series, “Bull” summarized the Neutron deployment mode under different server and network configurations. Over the years, I have occasionally worked part-time in deployment operation and maintenance, so I have a deep understanding of this experience. However, after reading it, I still feel enlightened and refreshing. In a word, it is simple and direct.

Ideal is beautiful, reality is skinny. When I went to a customer’s site to do POC, after early communication, the site conditions were not bad, the machine was freely used, the independent layer 2 switch was freely used, I felt good. But, however, the only layer 3 network is the office network, obtained by DHCP, cannot be changed! Instantly feel a little high blood pressure, meng, as if with imagination is not the same ah, said to provide a continuous section of accessible address? (Once again, until the final implementation of the deployment of the moment, nothing is floating clouds) no difficulties, more difficulties, as yan Rong men, work will continue, can not say no, let us take a breath, clear thoughts.

In fact, after thinking about it, the variation of this problem or encountered, but the brain short circuit, and then mentioned.

Divide and conquer

There is no picture, there is no truth. Let’s look at the reality, and of course the truth is not only that, but also routes, gateways and distances.

As we all know, if VMS in Neutron need external traffic, at least one external network is required. In this network, several IP addresses are required. In addition, Neutron maintains DHCP by itself. However, in terms of the actual situation above, we cannot obtain a continuous IP address for a long time (some IP addresses may be pinged out at night and then automatically distributed during the day), nor can we enable another EXTERNAL DHCP in our Neutron network. For those in the community, you need to learn leverage. When you have problems, you have to go to the community to find out whether Neutron can utilize the existing DHCP for the external network, but to no avail. There are only questions but no answers.

Fortunately, the site hardware conditions are good, enough network port, enough switch. We can create a contiguous IP address pool, as long as it does not conflict with the existing IP address pool, such as 172.16.10.0/24. Select this network segment for the BR-EX configuration. (Other networks are not described in detail. For example, the management network can be isolated from the existing DHCP by using other independent private networks.)

The OpenStack environment is deployed, but the virtual machines are still isolated. Under the current topology, the office network and the upstream network of OpenStack are on different network segments. The two switches cannot be directly connected, otherwise DHCP will be in chaos, and a router is needed to communicate across network segments. However, the answer is definitely no, (.

Well, there’s nothing that one Linux operating system can’t handle, just two. We can use a server and do some iptables configuration on the operating system to achieve the purpose of router.

If the DHCP Server can be modified, the 172.16.10.0/24 routing Server can be configured to be the same as the Linux routing Server. It is used for forwarding. Alternatively, manually adding a route on the office network desktop can achieve the same effect.

conclusion

The paper tries to use some other ways to solve practical problems under limited circumstances. In fact, it seems that such a model is also traceable. For example, if a private cloud is deployed in a typical equipment room, access to VMS outside the equipment room is similar, except that a firewall is required to perform NAT. Limited by the author in the network of limited understanding, writing and technology inevitably omissions, welcome correction.