1

I've installed the Openstack without any issue. I'm facing the issue that cannot access the controller host from the other network.

In my work environment, I have many VLAN configured on Cisco Switch.

  • The user VLAN is (10.10.10.0/24.)
  • The server VLAN is (192.168.100.0/24).

The controller server ext IP (192.168.100.100), after creating network/router on the controller the network from the user (10.10.10.0/24) cannot ping/access to 192.168.100.100, but on the same network of the controller (192.168.100.0/24) still can ping to controller node.

It means only the same network of the controller can reach it the other network cannot.

So how to make it available to all networks?

Some results from the controller:

tcpdump:

verbose output suppressed, use -v or -vv for full protocol decode
listening on vxlan-1, link-type EN10MB (Ethernet), capture size 262144 bytes.

IP address

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever

2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:50:56:87:7c:e8 brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.11/24 brd 10.0.0.255 scope global ens160
       valid_lft forever preferred_lft forever
    inet6 fe80::250:56ff:fe87:7ce8/64 scope link
       valid_lft forever preferred_lft forever

3: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master brq2d2d66af-87 state UP group default qlen 1000
    link/ether 00:50:56:87:d6:1c brd ff:ff:ff:ff:ff:ff

6: tap96c05264-57@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master brq2d2d66af-87 state UP group default qlen 1000
    link/ether 72:b8:0a:01:9d:36 brd ff:ff:ff:ff:ff:ff link-netns qdhcp-2d2d66af-87f8-4c5e-9329-dbb903debc0d

7: tape473efb7-92@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master brq98128308-8d state UP group default qlen 1000
    link/ether 96:e0:72:ac:06:18 brd ff:ff:ff:ff:ff:ff link-netns qdhcp-98128308-8d26-4ef5-947d-0620396348d7

8: vxlan-1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master brq98128308-8d state UNKNOWN group default qlen 1000
    link/ether ee:48:01:ef:1f:03 brd ff:ff:ff:ff:ff:ff

9: brq98128308-8d: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default qlen 1000
    link/ether 02:d5:28:7f:48:8f brd ff:ff:ff:ff:ff:ff
    inet6 fe80::5093:1dff:feaa:1698/64 scope link
       valid_lft forever preferred_lft forever

10: brq2d2d66af-87: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:50:56:87:d6:1c brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.100/24 brd 192.168.100.255 scope global brq2d2d66af-87
       valid_lft forever preferred_lft forever
    inet6 fe80::250:56ff:fe87:d61c/64 scope link
       valid_lft forever preferred_lft forever
    inet6 fe80::70dc:72ff:fe53:152f/64 scope link
       valid_lft forever preferred_lft forever

11: tape188178b-33@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master brq98128308-8d state UP group default qlen 1000
    link/ether 02:d5:28:7f:48:8f brd ff:ff:ff:ff:ff:ff link-netns qrouter-50ae9644-5fe8-4bc3-9813-c96c22c294ff

12: tap97c393cc-e5@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master brq2d2d66af-87 state UP group default qlen 1000
    link/ether 1a:c8:66:85:59:c6 brd ff:ff:ff:ff:ff:ff link-netns qrouter-50ae9644-5fe8-4bc3-9813-c96c22c294ff

ip route

default via 10.0.0.1 dev ens160 proto static

default via 192.168.100.1 dev brq2d2d66af-87 proto static metric 100

10.0.0.0/24 dev ens160 proto kernel scope link src 10.0.0.11

192.168.100.0/24 dev brq2d2d66af-87 proto kernel scope link src 192.168.100.100

Thank you!

berndbausch
  • 1,033
  • 8
  • 12
Hung Ho
  • 21
  • 4
  • Can you explain your network architecture? Is the user network related to the OpenStack cloud? If yes, how, and how did you configure Neutron? – berndbausch Jan 25 '21 at 13:42
  • User network: 10.10.10.0/24 Openstack network: 192.168.100.0/24 (external network), 10.0.0.0/24 (internal network) Basically, Networks for users and OpenStack can reach each other by configured routing on Cisco Switch. I've to install Openstack on Ubuntu 20. After creating the virtual network in Openstack such as (provider, self-service, router), set gateway for router then from user network cannot ping or access to Openstack dashboard anymore. I think the issue on Openstack since the brq2d2d66af-87 interface created. – Hung Ho Jan 26 '21 at 03:16
  • I understand that the user network is outside of OpenStack. A device, e.g. PC, with address 10.10.10.x needs a route to the OpenStack controller 192.168.100.100. You tell me that this router is implemented on the switch, but you can't reach 192.68.100.100. To me, this looks like a router misconfiguration. Can you run `tcpdump` on the controller to see if any ICMP packets come from the router? Can you reach other devices on 192.100.100.0? **More questions**: How did you deploy this cloud? Can you update the question with the output of `ip address` and `ip route` on the controller? – berndbausch Jan 26 '21 at 03:50
  • I updated the question. I deploy the OpenStack manually by following the installation guide from Openstack. My environment only has 2 machines, 1 for controller and 1 for compute, on each machine has 2 NIC. By the way, the router I mentioned above is on Openstack. – Hung Ho Jan 26 '21 at 04:55
  • What is the second network used for (10.0.0.0/24, ens160)? I may be wrong, but you have two default routes, and the first default via 10.0.0.1 has the highest priority, since it uses default metric 0. My networking knowledge is not that profound, but I would at least temporarily remove the first default, then try again (`ip r del default via 10.0.0.1` should do the trick, though the route will reappear after a reboot). – berndbausch Jan 26 '21 at 06:36
  • To see if packets arrive at the controller, run `tcpdump -i ens192 icmp` on the controller and `ping 192.168.100.100` on a device with address 10.10.10.X. `tcpdump` should report incoming echo requests. If it doesn't, the problem is not on the controller. If it does, the question is whether echo replies are generated, and via which interface they leave the controller. They might leave via ens160, the wrong interface, due to that route. You could then see them with `tcpdump -i ens160 icmp`. If, however, they leave via ens192, the question would be why the sending device doesn't receive them. – berndbausch Jan 26 '21 at 06:38
  • This command saves my life ip r del default via 10.0.0.1. You are right since the ens160 is the internal interface and the first interface of this controller. So the metric is the highest priority. – Hung Ho Jan 26 '21 at 06:52
  • You also need to remove the route permanently, so that a reboot doesn't recreate it. How to do that depends on how the route is defined in the first place, and that depends on the network management tool you use. – berndbausch Jan 26 '21 at 06:57

1 Answers1

0

ip route

default via 10.0.0.1 dev ens160 proto static

default via 192.168.100.1 dev brq2d2d66af-87 proto static metric 100

it due to the default route is the internal interface so the user cannot reach Openstack. After doing the below command, the issue solved.

ip route del default via 10.0.0.1

Many thank for your help Mr.Berndbausch

Hung Ho
  • 21
  • 4