[megoldva] OpenStack (DevStack) hálózat probléma

 ( wowbagger | 2018. március 29., csütörtök - 15:16 )

Kedves Fórumozók!

Érdekes problémával kerültem szembe a napokban.
Egy on-line kurzus elvégzése után játszani szerettem volna az OpenStack-kel.
A könnyű telepíthetőség miatt a DevStack-re esett a választásom, Ubuntu 16.04 alatt.

Az DevStack sikeresen feltelepült, fel is vettem egy saját tenant-et, publikus, és privát hálózattal, routerrel, majd pedig létrehoztam egy instance-ot.
A probléma az volt, hogy az instance-ot nem tudtam hálózaton elérni abból a LAN-ból, amiben az Ubuntu-t futtató OpenStack-es gép volt, pedig mindent beállítottam, úgy ahogy leírták.
A debuggolás során rájöttem, hogy nincs kapcsolat a kinti fizikai és a DevStack-beli external hálózatom között.

Ezután találtam rá erre a doksira: https://docs.openstack.org/devstack/latest/guides/neutron.html
Itt az első részletezett use-case írja le az én összeállításomat.
A DevStack-et újra is telepítettem az oldalon ajánlott beállításokkal, majd kipucoltam a built-in demo és demo_alt usereket és projekteket, valamint a router1 routert és a public és private hálózatokat.

Létrehoztam egy külső (flat, fizikai network neve: public) és egy belső hálózatot, ahogy kell, létrehoztam egy virtuális routert a két hálózat közé.
A külső hálózat címtartományát a fizikai hálózat címtartományával megegyezően vettem fel, a belsőt pedig 10.1.0.0/16-nak.
Vettem fel a külső hálózat tartományából való floating IP-ket is.
Végül létrehoztam egy instance-t is, ami viszont nem lát ki a fizikai hálózatra. (A security groupot is jól beállítottam, szóval a ping-nek és az SSH-nak mennie kellene.)
A saját, valamint a router külső és belső IP-it tudja pingelni sikeresen, valamint a floating IP-t is a routeren, de a fizikai hálózat GW-ét már nem tudja pingelni.
Amit magamtól gondoltam, hogy gond lehet, azt már megnéztem, de minden rendben levőnek tűnik. Mi lehet a gond?
Olyan ötleteket is szívesen veszek, hogy mit nézzek meg, csak már kicsit belefáradtam a több napos debuggolásba és jól jönne némi hozzáértő segítség.

Előre is köszönöm!

János

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

A fizikai hálózatról tudod egyáltalán pingelni a router külső lábát? Mert ha azt sem, akkor eleve a flat networkod beállítása a rossz. OVS-t vagy LinuxBridget használsz?

Nem sajnos, az nem megy.
Amennyire látom, bentről kifelé megy minden a router external network-be lógó interfészéig, illetve a floatingIP-ig.
Onnantól kifelé, és a fizikai hálózatről befelé nem megy.

Elvileg Open vSwitch-et használok.

Q_USE_SECGROUP=True
FLOATING_RANGE="192.168.20.0/24"
IPV4_ADDRS_SAFE_TO_USE="10.0.0.0/16"
Q_FLOATING_ALLOCATION_POOL=start=192.168.20.35,end=192.168.20.50
PUBLIC_NETWORK_GATEWAY="192.168.20.1"
PUBLIC_INTERFACE=eno1

# Open vSwitch provider networking configuration
Q_USE_PROVIDERNET_FOR_PUBLIC=True
OVS_PHYSICAL_BRIDGE=br-ex
PUBLIC_BRIDGE=br-ex
OVS_BRIDGE_MAPPINGS=public:br-ex

Ovs fronton mit nézhetek meg? Ahhoz nem értek annyira.
-------------------------------------------------------------------------------
Az életben csak egy dolog a szép, de az épp nem jut eszembe.

Slackware Linux 14.2 | 4.4.37-janos

Egy ovs-vsctl show kimenetét nézd meg.

3362e534-e2bf-4785-8631-5d0e0ffae097
    Manager "ptcp:6640:127.0.0.1"
        is_connected: true
    Bridge br-int
        Controller "tcp:127.0.0.1:6633"
            is_connected: true
        fail_mode: secure
        Port "qg-9ca3ad12-58"
            tag: 4
            Interface "qg-9ca3ad12-58"
                type: internal
        Port patch-tun
            Interface patch-tun
                type: patch
                options: {peer=patch-int}
        Port "qvo1bf57de4-75"
            tag: 3
            Interface "qvo1bf57de4-75"
        Port int-br-ex
            Interface int-br-ex
                type: patch
                options: {peer=phy-br-ex}
        Port "qr-0cf3b0ae-36"
            tag: 3
            Interface "qr-0cf3b0ae-36"
                type: internal
        Port br-int
            Interface br-int
                type: internal
        Port "tapaaf8dca1-c1"
            tag: 3
            Interface "tapaaf8dca1-c1"
                type: internal
    Bridge br-ex
        Controller "tcp:127.0.0.1:6633"
            is_connected: true
        fail_mode: secure
        Port br-ex
            Interface br-ex
                type: internal
        Port phy-br-ex
            Interface phy-br-ex
                type: patch
                options: {peer=int-br-ex}
    Bridge br-tun
        Controller "tcp:127.0.0.1:6633"
            is_connected: true
        fail_mode: secure
        Port patch-int
            Interface patch-int
                type: patch
                options: {peer=patch-tun}
        Port br-tun
            Interface br-tun
                type: internal
    ovs_version: "2.8.1"

Elvileg a konfig alapján a br-ex interfésznek kellene a cloud forgalmát rápakolnia a fizikai hálózatra.
Ennek ellenére azt látom, hogy a cloud-on belül megy minden, ami virtuális: (vm => virtuális rounter belső és külső IP-i, routeren felvett floating IP).
A fizikai hálózat GW-jét viszont már nem tudom pingelni.
-------------------------------------------------------------------------------
Az életben csak egy dolog a szép, de az épp nem jut eszembe.

Slackware Linux 14.2 | 4.4.37-janos

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: ens1f0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 00:25:b3:aa:5e:34 brd ff:ff:ff:ff:ff:ff
3: ens1f1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 00:25:b3:aa:5e:36 brd ff:ff:ff:ff:ff:ff
4: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 1c:98:ec:0e:0b:b4 brd ff:ff:ff:ff:ff:ff
    inet 192.168.20.10/24 brd 192.168.10.255 scope global eno1
       valid_lft forever preferred_lft forever
    inet6 fe80::1e98:ecff:fe0e:bb4/64 scope link 
       valid_lft forever preferred_lft forever
5: eno2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 1c:98:ec:0e:0b:b5 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::1e98:ecff:fe0e:bb5/64 scope link 
       valid_lft forever preferred_lft forever
13: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 52:54:00:14:f3:df brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
       valid_lft forever preferred_lft forever
14: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr0 state DOWN group default qlen 1000
    link/ether 52:54:00:14:f3:df brd ff:ff:ff:ff:ff:ff
42: qbr841eb67d-fa: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default qlen 1000
    link/ether f2:a9:4d:9f:d5:39 brd ff:ff:ff:ff:ff:ff
43: qvo841eb67d-fa@qvb841eb67d-fa: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default qlen 1000
    link/ether 8a:48:09:b9:67:4a brd ff:ff:ff:ff:ff:ff
    inet6 fe80::8848:9ff:feb9:674a/64 scope link 
       valid_lft forever preferred_lft forever
44: qvb841eb67d-fa@qvo841eb67d-fa: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1450 qdisc noqueue master qbr841eb67d-fa state UP group default qlen 1000
    link/ether f2:a9:4d:9f:d5:39 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::f0a9:4dff:fe9f:d539/64 scope link 
       valid_lft forever preferred_lft forever
46: ovs-system: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether b2:8f:23:53:79:56 brd ff:ff:ff:ff:ff:ff
47: br-int: <BROADCAST,MULTICAST> mtu 1450 qdisc noop state DOWN group default qlen 1000
    link/ether 1e:ca:93:0f:c2:46 brd ff:ff:ff:ff:ff:ff
48: br-ex: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ether 82:a1:f9:68:d6:4c brd ff:ff:ff:ff:ff:ff
    inet 172.24.4.1/24 scope global br-ex
       valid_lft forever preferred_lft forever
    inet6 2001:db8::2/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::80a1:f9ff:fe68:d64c/64 scope link 
       valid_lft forever preferred_lft forever
49: br-tun: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 4e:a6:93:ad:a1:4d brd ff:ff:ff:ff:ff:ff
57: qbr1bf57de4-75: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default qlen 1000
    link/ether 4a:b4:89:74:07:94 brd ff:ff:ff:ff:ff:ff
58: qvo1bf57de4-75@qvb1bf57de4-75: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1450 qdisc noqueue master ovs-system state UP group default qlen 1000
    link/ether ce:d5:d9:9d:83:9b brd ff:ff:ff:ff:ff:ff
    inet6 fe80::ccd5:d9ff:fe9d:839b/64 scope link 
       valid_lft forever preferred_lft forever
59: qvb1bf57de4-75@qvo1bf57de4-75: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1450 qdisc noqueue master qbr1bf57de4-75 state UP group default qlen 1000
    link/ether 4a:b4:89:74:07:94 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::48b4:89ff:fe74:794/64 scope link 
       valid_lft forever preferred_lft forever
60: tap1bf57de4-75: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc pfifo_fast master qbr1bf57de4-75 state UNKNOWN group default qlen 1000
    link/ether fe:16:3e:dc:b4:31 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc16:3eff:fedc:b431/64 scope link 
       valid_lft forever preferred_lft forever

Most épp ezek az fizikai és virtuális interfészek vannak a dolbozon. Az eno1 kapcsolódik a fizikai hálózatra.

-------------------------------------------------------------------------------
Az életben csak egy dolog a szép, de az épp nem jut eszembe.

Slackware Linux 14.2 | 4.4.37-janos

DevStacket régen nem használtam, de ránézére nincs benne a "br-ex"-ben a fizikai interface.
Esetleg egy "sudo ovs-vsctl add-port br-ex eno1" kiadása segíthet. Bár ahogy nézem az eno1-re önállóan is fel lett húzva egy ip, így az gondot okozhat, célszerű azt az ip-t inkább a br-ex bridgre felvenni.

Köszönöm, ez segített.
A következőkben megpróbálom majd kicsit ésszerűsíteni az összeállítást, mert jelenleg - ahogy mondod - a gép produktív IP-je az eno1-en van, és a bridge is erre próbál felhúzódni automatikusan. (Nem tudom a stack.sh miért nem csinálja meg.)
Lehet egy másik interfészre rakom ki a bridge portot, és akkor remélem nem lesz vele gond. (Reményeim szerint host OS szinten elég lesz konfigurálatlanul hagyni, és úgy betenni a bridge-be. Minden esetre meglátjuk.)

-------------------------------------------------------------------------------
Az életben csak egy dolog a szép, de az épp nem jut eszembe.

Slackware Linux 14.2 | 4.4.37-janos

igen, külön portra bridge-elve a "br-ex"-et szintén megy a dolog, sokkal flottabbul mint csak egy interfésszel. :)
-------------------------------------------------------------------------------
Az életben csak egy dolog a szép, de az épp nem jut eszembe.

Slackware Linux 14.2 | 4.4.37-janos

Hát én nem látom az eno1-et rákötve a br-exre.
Próbáld ki, hogy ovs-vsctl add-port br-ex eno1
Viszont ha ez az egy interfaced van, és ezen van a gép "igazi" IP-je, akkor lehet, hogy ezt nem fogod tudni így használni. Ebben az esetben kell egy másik bridge, mondjuk br-mgmt, ebbe kell berakni az eno1-et, a br-mgmt-nek adod a gép IP-jét, és a br-ex és br-mgmt-et összekötöd egy patch "kábellel".

(ja, látom, eggyel fentebb már majdnem ugyenezt írták, nem tudom, hogy az OVS agent elbírja-e, ha az általa kezelt bridgenek saját IP-je van, a LinuxBridge agent úgy leveszi róla az IP-t, mint a huzat).

szerintem hasznalj linuxbridget, azt picit egyszerubb debuggolni.

Azt olvastam, hogy az a devstack annyira nem szereti. :(
-------------------------------------------------------------------------------
Az életben csak egy dolog a szép, de az épp nem jut eszembe.

Slackware Linux 14.2 | 4.4.37-janos

Ilyenkor tipikus az 'ip ns' -sel a megfelelő, Neutron által létrehozott qrouter/qdhcp namespace-ben execelt shellből turkálás a megszokott eszközökkel, kézzel, egyidejűleg a neutron komponensei logjainak figyelése, opcionálisan debug-ra állított service mellett.
------------------------
{0} ok boto
boto ?

Igen, a végigpingelés megvolt már.
A neutron-t nem tudom, hogy tudnám debugosítani, de majd megpróbálom megnézni.

Esetleg van pár olyan kimenet, ami alapján - ha megosztom - kiderülne számotokra, hogy mit rontottam el/mi hiányzik?
-------------------------------------------------------------------------------
Az életben csak egy dolog a szép, de az épp nem jut eszembe.

Slackware Linux 14.2 | 4.4.37-janos

/etc/neutron/neutron.conf-ban kell debug=true paramétert beállítani majd service neutron* restart.

Log fájlokat én így nézem:
tail -F /var/log/neutron/* | ccze -A

Paraméterként további logfájlok vagy könyvtárak is felvehetők. A logot így látod szépen pörögni, a ccze -A pedig kiszínezi, hogy jobban lásd a piros ERROR-okat vagy sárga WARNING-okat.

Devstack alatt a debug alapból be van kapcsolva, és minden log a syslog-ba megy.
A fájdalmas dolog a shell formázókarakterek jelenléte a logokban, amin még a less -R sem segít :(
Összességében neutronnal kapcsolatos érdemi warning/error üzeneteket nem láttam benne.
-------------------------------------------------------------------------------
Az életben csak egy dolog a szép, de az épp nem jut eszembe.

Slackware Linux 14.2 | 4.4.37-janos

DevStacknél nem tudom,hogy van pontosan,de OpenStacknél a következőképp kéne működnie.

- ethernet interface-nek nincs ip-je csak sima "ip link set up dev eth0"
- ethernet interface bridge portként hozzáadva br-ex-hez "ovs-vsctl add-port br-ex eth0" (ha jól emlékszem)

Ekkor fog kilátni netre. Ez az ethernet interface soha ne legyen azonos azzal, amelyiken ssh-n belépsz a gépre és a két ethernet kártya ne lógjon egy hálóba!

Ha Virtualbox VM-ben használod, akkor a mgmt legyen "Host-Only" típusú ekkor saját gépről tudsz ssh-zni a node-ra és csak a br-ex-be lógó interface legyen "bridge" típusú.

DHCP range ne ütközzön arra figyelj.

Így mennie kéne DevStack alatt is.