[ English | Indonesia | Deutsch | 日本語 ]

Pemecahan Masalah Jaringan

Pemecahan masalah jaringan bisa jadi menantang. Masalah jaringan dapat menyebabkan masalah kapan saja di cloud. Menggunakan prosedur pemecahan masalah logis dapat membantu mengurangi masalah dan mengisolasi di mana masalah jaringan berada. Bab ini bertujuan untuk memberi Anda informasi yang Anda butuhkan untuk mengidentifikasi masalah apa pun untuk nova-network atau OpenStack Networking (neutron) dengan Linux Bridge atau Open vSwitch.

Menggunakan IP untuk Memeriksa Status Antarmuka

Saat node komputasi dan node menjalankan nova-network, gunakan perintah berikut untuk melihat informasi tentang antarmuka, termasuk informasi tentang IP, VLAN, dan apakah antarmuka Anda sudah aktif:

# ip a

Jika Anda menghadapi kesulitan jaringan apa pun, satu langkah pemecahan masalah awal yang baik adalah memastikan bahwa antarmuka Anda sudah aktif. Sebagai contoh:

$ ip a | grep state
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP
   qlen 1000
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
   master br100 state UP qlen 1000
4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN
5: br100: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP

Anda dapat dengan aman mengabaikan status virbr0, yang merupakan jembatan default yang dibuat oleh libvirt dan tidak digunakan oleh OpenStack.

Memvisualisasikan nova-network Traffic di Cloud

Jika Anda masuk ke instance dan melakukan ping host eksternal, misalnya, Google, paket ping mengambil rute yang ditunjukkan Angka. Rute lalu lintas untuk paket ping.

Traffic route for ping packet

Angka. Rute lalu lintas untuk paket ping

  1. Mesin virtual menghasilkan paket dan menempatkannya pada Network Interface Card (NIC) virtual di dalam mesin virtual, seperti eth0.

  2. Paket transfer ke NIC virtual host komputasi, seperti, vnet1. Anda dapat mengetahui apa vnet NIC yang digunakan dengan melihat file /etc/libvirt/qemu/instance-xxxxxxxx.xml.

  3. Dari vnet NIC, paket mentransfer ke sebuah jembatan (bridge) di node komputasi, seperti br100.

    Jika Anda menjalankan FlatDHCPManager, satu bridge ada di simpul komputasi. Jika Anda menjalankan VlanManager, ada satu bridge untuk setiap VLAN.

    Untuk melihat bridge mana yang akan digunakan paket, jalankan perintah:

    $ brctl show

    Carilah vnet NIC. Anda juga dapat mereferensikan nova.conf dan mencari opsi flat_interface_bridge.

  4. Paket transfer ke NIC utama dari node komputasi. Anda juga dapat melihat NIC ini dalam brctl output, atau Anda dapat menemukannya dengan merujuk opsi flat_interface di nova.conf.

  5. Setelah paket berada di NIC ini, ia mentransfer ke gateway default node komputasi. Paket sekarang kemungkinan besar di luar kendali Anda pada saat ini. Diagram menggambarkan gateway eksternal. Namun, dalam konfigurasi default dengan multi-host, host komputasi adalah gateway.

Balikkan arah (reverse) untuk melihat jalur balasan ping. Dari jalur ini, Anda dapat melihat bahwa satu paket bergerak melintasi empat NIC yang berbeda. Jika masalah terjadi dengan salah satu NIC ini, masalah jaringan terjadi.

Memvisualisasikan OpenStack Networking Service Traffic di Cloud

OpenStack Networking memiliki lebih banyak derajat kebebasan daripada nova-network karena back end pluggable-nya. Ini dapat dikonfigurasikan dengan plug-in open source atau vendor proprietary yang mengontrol plug-in atau hardware software defined networking (SDN) yang menggunakan fasilitas native Linux pada host Anda, seperti Open vSwitch atau Linux Bridge.

Bab jaringan dari OpenStack Administrator Guide menampilkan berbagai skenario jaringan dan jalur koneksinya. Tujuan dari bagian ini adalah untuk memberi Anda alat untuk memecahkan masalah berbagai komponen yang terlibat namun mereka diselami bersama di lingkungan Anda.

Untuk contoh ini, kita akan menggunakan back end Open vSwitch (OVS). Plug-in back-end lainnya akan memiliki jalur aliran yang sangat berbeda. OVS adalah driver jaringan yang paling populer digunakan, menurut Survei Pengguna OpenStack April 2016. Kami akan menjelaskan setiap langkah pada gilirannya, dengan Figur. Jalur jaringan neutron sebagai referensi.

  1. Instance menghasilkan paket dan menempatkannya di NIC virtual di dalam instance, seperti eth0.

  2. Paket transfer ke perangkat Test Access Point (TAP) pada host komputasi, seperti tap690466bc-92. Anda dapat mengetahui TAP apa yang sedang digunakan dengan melihat file /etc/libvirt/qemu/instance-xxxxxxxx.xml.

    Nama perangkat TAP dibuat menggunakan 11 karakter pertama port ID (10 hex digits plus an included '-'), jadi cara lain untuk menemukan nama perangkat adalah dengan menggunakan perintah neutron. Ini mengembalikan pipe-delimited list, item pertama di antaranya adalah port ID. Misalnya, untuk mendapatkan ID port yang terkait dengan alamat IP 10.0.0.10, lakukan ini:

    # openstack port list | grep 10.0.0.10 | cut -d \| -f 2
 ff387e54-9e54-442b-94a3-aa4481764f1d

    Mengambil 11 karakter pertama, kita dapat membuat nama perangkat tapff387e54-9e dari output ini.

    Neutron network paths

    Figur. Jalur jaringan neutron

  3. Perangkat TAP terhubung ke jembatan integrasi, br-int. Jembatan ini menghubungkan semua perangkat TAP instance dan jembatan lainnya pada sistem. Dalam contoh ini, kita memiliki int-br-eth1 dan patch-tun. int-br-eth1 adalah setengah dari pasangan yang terhubung ke jembatan br-eth1, yang menangani jaringan VLAN yang di-trunking melalui perangkat Ethernet fisik eth1. patch-tun adalah port internal Open vSwitch yang menghubungkan ke jembatan br-tun untuk jaringan GRE.

    Perangkat TAP dan perangkat veth adalah perangkat jaringan Linux normal dan dapat diperiksa dengan alat yang biasa, seperti ip dan tcpdump. Buka perangkat internal vSwitch, seperti patch-tun, hanya terlihat dalam lingkungan Open vSwitch. Jika Anda mencoba menjalankan tcpdump -i patch-tun, itu akan memunculkan kesalahan, mengatakan bahwa perangkat tidak ada.

    Dimungkinkan untuk menonton paket pada antarmuka internal, tetapi dibutuhkan sedikit senam jaringan. Pertama, Anda perlu membuat perangkat jaringan tiruan yang bisa dilihat oleh alat Linux normal. Maka Anda perlu menambahkannya ke jembatan yang berisi antarmuka internal yang ingin Anda sembunyikan. Terakhir, Anda perlu memberi tahu Open vSwitch untuk mencerminkan semua lalu lintas ke atau dari port internal ke port dummy ini. Setelah semua ini, Anda kemudian dapat menjalankan :command: tcpdump pada antarmuka dummy dan melihat lalu lintas di port internal.

    To capture packets from the patch-tun internal interface on integration bridge, br-int:

    1. Membuat dan memunculkan antarmuka dummy, snooper0:

      # ip link add name snooper0 type dummy
# ip link set dev snooper0 up

    2. Tambahkan perangkat snooper0 untuk menjembatani br-int:

      # ovs-vsctl add-port br-int snooper0

    3. Buat mirror dari patch-tun ke snooper0 (mengembalikan UUID port mirror):

      # ovs-vsctl -- set Bridge br-int mirrors=@m  -- --id=@snooper0 \
  get Port snooper0  -- --id=@patch-tun get Port patch-tun \
  -- --id=@m create Mirror name=mymirror select-dst-port=@patch-tun \
  select-src-port=@patch-tun output-port=@snooper0 select_all=1

    4. Profit. Anda sekarang dapat melihat lalu lintas di patch-tun dengan menjalankan tcpdump -i snooper0.

    5. Bersihkan dengan menghapus semua mirror di br-int dan menghapus antarmuka dummy:

      # ovs-vsctl clear Bridge br-int mirrors
# ovs-vsctl del-port br-int snooper0
# ip link delete dev snooper0

    Pada jembatan integrasi, jaringan dibedakan menggunakan VLAN internal terlepas dari bagaimana layanan jaringan menentukannya. Ini memungkinkan instance pada host yang sama untuk berkomunikasi secara langsung tanpa mentransit sisa jaringan (rest of network) virtual atau fisik. ID VLAN internal ini didasarkan pada urutan pembuatannya pada node dan dapat bervariasi antar node. ID ini sama sekali tidak terkait dengan ID segmentasi yang digunakan dalam definisi jaringan dan pada kabel fisik.

    Tag VLAN diterjemahkan antara tag eksternal yang ditentukan dalam pengaturan jaringan, dan tag internal di beberapa tempat. Pada br-int, paket yang masuk dari int-br-eth1 diterjemahkan dari tag eksternal ke tag internal. Terjemahan lain juga terjadi di jembatan lain dan akan dibahas di bagian-bagian tersebut.

    To discover which internal VLAN tag is in use for a given external VLAN by using the ovs-ofctl command

    1. Temukan tag VLAN eksternal dari jaringan yang Anda minati. Ini adalah provider:segmentation_id yang dikembalikan oleh layanan jaringan:

      # neutron net-show --fields provider:segmentation_id <network name>
+---------------------------+--------------------------------------+
| Field                     | Value                                |
+---------------------------+--------------------------------------+
| provider:network_type     | vlan                                 |
| provider:segmentation_id  | 2113                                 |
+---------------------------+--------------------------------------+

    2. Grep untuk provider:segmentation_id, 2113 dalam hal ini, dalam output dari ovs-ofctl dump-flows br-int:

      # ovs-ofctl dump-flows br-int | grep vlan=2113
cookie=0x0, duration=173615.481s, table=0, n_packets=7676140,
n_bytes=444818637, idle_age=0, hard_age=65534, priority=3,
in_port=1,dl_vlan=2113 actions=mod_vlan_vid:7,NORMAL

      Di sini Anda dapat melihat paket yang diterima pada port ID 1 dengan tag VLAN 2113 dimodifikasi untuk memiliki tag VLAN internal 7. Menggali lebih dalam, Anda dapat mengonfirmasi bahwa port 1 sebenarnya int-br-eth1:

      # ovs-ofctl show br-int
OFPT_FEATURES_REPLY (xid=0x2): dpid:000022bc45e1914b
n_tables:254, n_buffers:256
capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS
ARP_MATCH_IP
actions: OUTPUT SET_VLAN_VID SET_VLAN_PCP STRIP_VLAN SET_DL_SRC
SET_DL_DST SET_NW_SRC SET_NW_DST SET_NW_TOS SET_TP_SRC
SET_TP_DST ENQUEUE
 1(int-br-eth1): addr:c2:72:74:7f:86:08
     config:     0
     state:      0
     current:    10GB-FD COPPER
     speed: 10000 Mbps now, 0 Mbps max
 2(patch-tun): addr:fa:24:73:75:ad:cd
     config:     0
     state:      0
     speed: 0 Mbps now, 0 Mbps max
 3(tap9be586e6-79): addr:fe:16:3e:e6:98:56
     config:     0
     state:      0
     current:    10MB-FD COPPER
     speed: 10 Mbps now, 0 Mbps max
 LOCAL(br-int): addr:22:bc:45:e1:91:4b
     config:     0
     state:      0
     speed: 0 Mbps now, 0 Mbps max
OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0

  4. Langkah selanjutnya tergantung pada apakah jaringan virtual dikonfigurasi untuk menggunakan tag VLAN 802.1q atau GRE:

    1. Jaringan berbasis VLAN keluar dari jembatan integrasi melalui antarmuka veth int-br-eth1 dan tiba di jembatan br-eth1 pada anggota lain dari pasangan veth phy-br-eth1. Paket pada antarmuka ini tiba dengan tag VLAN internal dan diterjemahkan ke tag eksternal sebagai kebalikan dari proses yang dijelaskan di atas:

      # ovs-ofctl dump-flows br-eth1 | grep 2113
cookie=0x0, duration=184168.225s, table=0, n_packets=0, n_bytes=0,
idle_age=65534, hard_age=65534, priority=4,in_port=1,dl_vlan=7
actions=mod_vlan_vid:2113,NORMAL

      Paket, sekarang ditandai dengan tag VLAN eksternal, kemudian keluar ke jaringan fisik melalui eth1. Switch Layer2 yang terhubung dengan antarmuka ini harus dikonfigurasi untuk menerima lalu lintas dengan ID VLAN yang digunakan. Hop berikutnya untuk paket ini juga harus berada di jaringan layer-2 yang sama.

    2. Jaringan berbasis GRE diteruskan dengan patch-tun ke bridge tunnel br-tun pada antarmuka patch-int. Jembatan ini juga berisi satu port untuk setiap peer tunnel GRE, jadi satu untuk setiap node komputasi dan node jaringan di jaringan Anda. Port diberi nama secara berurutan dari gre-1 dan seterusnya.

      Mencocokkan antarmuka ``gre- <n> `` dengan endpoints terowongan dimungkinkan dengan melihat kondisi Open vSwitch:

      # ovs-vsctl show | grep -A 3 -e Port\ \"gre-
        Port "gre-1"
            Interface "gre-1"
                type: gre
                options: {in_key=flow, local_ip="10.10.128.21",
                out_key=flow, remote_ip="10.10.128.16"}

      Dalam hal ini, gre-1 adalah terowongan dari IP 10.10.128.21, yang harus cocok dengan antarmuka lokal pada node ini, ke IP 10.10.128.16 di sisi jarak jauh (remote side).

      Terowongan ini menggunakan tabel routing biasa pada host untuk merutekan paket GRE yang dihasilkan, jadi tidak ada persyaratan bahwa endpoint GRE semua pada jaringan layer-2 yang sama, tidak seperti enkapsulasi VLAN.

      Semua antarmuka pada br-tun bersifat internal ke Open vSwitch. Untuk memantau lalu lintas, Anda perlu mengatur port mirror seperti dijelaskan di atas untuk patch-tun di jembatan br-int.

      Semua terjemahan terowongan GRE ke dan dari VLAN internal terjadi di jembatan ini.

    To discover which internal VLAN tag is in use for a GRE tunnel by using the ovs-ofctl command

    1. Temukan provider: segmentation_id dari jaringan yang Anda minati. Ini adalah bidang yang sama dengan yang digunakan untuk ID VLAN di jaringan berbasis VLAN:

      # neutron net-show --fields provider:segmentation_id <network name>
+--------------------------+-------+
| Field                    | Value |
+--------------------------+-------+
| provider:network_type    | gre   |
| provider:segmentation_id | 3     |
+--------------------------+-------+

    2. Grep untuk 0x<`` provider: segmentation_id``>, 0x3 dalam hal ini, dalam output dari ovs-ofctl dump-flows br-tun:

      # ovs-ofctl dump-flows br-tun|grep 0x3
cookie=0x0, duration=380575.724s, table=2, n_packets=1800,
n_bytes=286104, priority=1,tun_id=0x3
actions=mod_vlan_vid:1,resubmit(,10)
 cookie=0x0, duration=715.529s, table=20, n_packets=5,
n_bytes=830, hard_timeout=300,priority=1,
vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:a6:48:24
actions=load:0->NXM_OF_VLAN_TCI[],
load:0x3->NXM_NX_TUN_ID[],output:53
 cookie=0x0, duration=193729.242s, table=21, n_packets=58761,
n_bytes=2618498, dl_vlan=1 actions=strip_vlan,set_tunnel:0x3,
output:4,output:58,output:56,output:11,output:12,output:47,
output:13,output:48,output:49,output:44,output:43,output:45,
output:46,output:30,output:31,output:29,output:28,output:26,
output:27,output:24,output:25,output:32,output:19,output:21,
output:59,output:60,output:57,output:6,output:5,output:20,
output:18,output:17,output:16,output:15,output:14,output:7,
output:9,output:8,output:53,output:10,output:3,output:2,
output:38,output:37,output:39,output:40,output:34,output:23,
output:36,output:35,output:22,output:42,output:41,output:54,
output:52,output:51,output:50,output:55,output:33

      Di sini, Anda melihat tiga aliran yang terkait dengan terowongan GRE ini. Yang pertama adalah aliran terjemahan dari paket inbound dengan ID terowongan ini ke ID VLAN internal 1. Yang kedua menunjukkan aliran unicast ke port output 53 untuk paket yang ditujukan untuk alamat MAC fa:16:3e:a6:48:24. Yang ketiga menunjukkan aliran terjemahan dari representasi VLAN internal ke terowongan GRE yang ID dibanjiri ke semua port output. Untuk detail lebih lanjut dari deskripsi aliran, lihat halaman manual untuk ovs-ofctl. Seperti pada contoh VLAN sebelumnya, ID port numerik dapat dicocokkan dengan representasi namanya dengan memeriksa output ovs-ofctl show br-tun.

  5. Paket tersebut kemudian diterima pada node jaringan. Perhatikan bahwa lalu lintas apa pun ke l3-agent atau dhcp-agent hanya akan terlihat dalam namespace jaringan mereka. Menonton antarmuka apa pun di luar namespace itu, bahkan yang membawa lalu lintas jaringan, hanya akan menampilkan paket siaran seperti Address Resolution Protocols (ARPs), tetapi lalu lintas unicast ke router atau alamat DHCP tidak akan terlihat. Lihat Berurusan dengan Network Namespaces untuk detail tentang cara menjalankan perintah di dalam namespaces ini.

    Atau, dimungkinkan untuk mengkonfigurasi jaringan berbasis VLAN untuk menggunakan router eksternal daripada agen l3 yang ditunjukkan di sini, selama router eksternal berada di VLAN yang sama:

    1. Jaringan berbasis VLAN diterima sebagai paket yang ditandai pada antarmuka jaringan fisik, eth1 dalam contoh ini. Sama seperti pada node komputasi, antarmuka ini adalah anggota dari jembatan br-eth1.

    2. Jaringan berbasis GRE akan diteruskan ke bridge tunnel br-tun, yang berperilaku seperti antarmuka GRE pada node komputasi.

  6. Selanjutnya, paket-paket dari salah satu input masuk melalui jembatan integrasi, lagi seperti pada node komputasi.

  7. Paket kemudian menuju ke l3-agent. Ini sebenarnya adalah perangkat TAP lain dalam namespace jaringan router. Namespace router diberi nama dalam bentuk ``qrouter- <router-uuid> ``. Menjalankan ip a dalam namespace akan menampilkan nama perangkat TAP, qr-e6256f7d-31 dalam contoh ini:

    # ip netns exec qrouter-e521f9d0-a1bd-4ff4-bc81-78a60dd88fe5 ip a | grep state
10: qr-e6256f7d-31: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
    state UNKNOWN
11: qg-35916e1f-36: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
    qdisc pfifo_fast state UNKNOWN qlen 500
28: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN

  8. Antarmuka qg- <n> `` di namespace router l3-agent mengirim paket ke hop berikutnya melalui perangkat ``eth2 di jembatan eksternal br-ex. Jembatan ini dibangun mirip dengan br-eth1 dan dapat diperiksa dengan cara yang sama.

  9. Jembatan eksternal ini juga menyertakan antarmuka jaringan fisik, eth2 dalam contoh ini, yang akhirnya mendaratkan paket pada jaringan eksternal yang ditujukan untuk router atau tujuan eksternal.

  10. Agen DHCP yang berjalan pada jaringan OpenStack dijalankan dalam namespace yang mirip dengan agen l3. Namespace DHCP diberi nama ``qdhcp- <uuid> `` dan memiliki perangkat TAP di jembatan integrasi. Debugging masalah DHCP biasanya melibatkan bekerja di dalam namespace jaringan ini.

Menemukan Kegagalan di Path

Gunakan ping untuk menemukan dengan cepat di mana ada kegagalan di jalur jaringan. Dalam sebuah instance, pertama-tama lihat apakah Anda dapat melakukan ping host eksternal, seperti google.com. Jika Anda bisa, maka seharusnya tidak ada masalah jaringan sama sekali.

Jika Anda tidak bisa, coba ping alamat IP dari node compute tempat instance di-host. Jika Anda dapat melakukan ping IP ini, maka masalahnya adalah di suatu tempat antara node komputasi dan gateway node komputasi itu.

Jika Anda tidak bisa melakukan ping alamat IP dari node komputasi, masalahnya adalah antara instance dan node komputasi. Ini termasuk jembatan yang menghubungkan NIC utama node komputasi dengan vnet NIC dari instance.

Satu tes terakhir adalah meluncurkan instance kedua dan melihat apakah kedua instance dapat saling ping. Jika mereka bisa, masalahnya mungkin terkait dengan firewall pada node komputasi.

tcpdump

Satu cara hebat, meskipun sangat mendalam, cara mengatasi masalah jaringan adalah dengan menggunakan tcpdump. Kami merekomendasikan penggunaan tcpdump di beberapa titik di sepanjang jalur jaringan (network path) untuk menghubungkan di mana masalah mungkin terjadi. Jika Anda lebih suka bekerja dengan GUI, secara langsung atau dengan menggunakan tangkapan tcpdump, periksa Wireshark.

Misalnya, jalankan perintah berikut:

# tcpdump -i any -n -v 'icmp[icmptype] = icmp-echoreply or icmp[icmptype] = icmp-echo'

Jalankan ini pada command line area berikut:

  1. Server eksternal di luar cloud

  2. Node komputasi

  3. Sebuah instance berjalan pada node komputasi itu

Dalam contoh ini, lokasi ini memiliki alamat IP berikut:

Instance
    10.0.2.24
    203.0.113.30
Compute Node
    10.0.0.42
    203.0.113.34
External Server
    1.2.3.4

Selanjutnya, buka shell baru ke instance dan kemudian ping host eksternal di mana tcpdump sedang berjalan. Jika jalur jaringan ke server eksternal dan kembali berfungsi penuh, Anda melihat sesuatu seperti berikut:

Di server eksternal:

12:51:42.020227 IP (tos 0x0, ttl 61, id 0, offset 0, flags [DF],
proto ICMP (1), length 84)
    203.0.113.30 > 1.2.3.4: ICMP echo request, id 24895, seq 1, length 64
12:51:42.020255 IP (tos 0x0, ttl 64, id 8137, offset 0, flags [none],
proto ICMP (1), length 84)
    1.2.3.4 > 203.0.113.30: ICMP echo reply, id 24895, seq 1,
    length 64

Pada node komputasi:

12:51:42.019519 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF],
proto ICMP (1), length 84)
    10.0.2.24 > 1.2.3.4: ICMP echo request, id 24895, seq 1, length 64
12:51:42.019519 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF],
proto ICMP (1), length 84)
    10.0.2.24 > 1.2.3.4: ICMP echo request, id 24895, seq 1, length 64
12:51:42.019545 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF],
proto ICMP (1), length 84)
    203.0.113.30 > 1.2.3.4: ICMP echo request, id 24895, seq 1, length 64
12:51:42.019780 IP (tos 0x0, ttl 62, id 8137, offset 0, flags [none],
proto ICMP (1), length 84)
    1.2.3.4 > 203.0.113.30: ICMP echo reply, id 24895, seq 1, length 64
12:51:42.019801 IP (tos 0x0, ttl 61, id 8137, offset 0, flags [none],
proto ICMP (1), length 84)
    1.2.3.4 > 10.0.2.24: ICMP echo reply, id 24895, seq 1, length 64
12:51:42.019807 IP (tos 0x0, ttl 61, id 8137, offset 0, flags [none],
proto ICMP (1), length 84)
    1.2.3.4 > 10.0.2.24: ICMP echo reply, id 24895, seq 1, length 64

Pada instance:

12:51:42.020974 IP (tos 0x0, ttl 61, id 8137, offset 0, flags [none],
proto ICMP (1), length 84)
 1.2.3.4 > 10.0.2.24: ICMP echo reply, id 24895, seq 1, length 64

Di sini, server eksternal menerima permintaan ping dan mengirim balasan ping. Pada node komputasi, Anda dapat melihat bahwa ping dan balasan ping berhasil dilewati. Anda mungkin juga melihat paket duplikat pada node komputasi, seperti yang terlihat di atas, karena tcpdump menangkap paket di kedua jembatan dan antarmuka keluar.

iptables

Melalui nova-network atau neutron, OpenStack Compute secara otomatis mengelola iptables, termasuk meneruskan paket ke dan dari instance pada node komputasi, meneruskan lalu lintas IP mengambang, dan mengatur aturan grup keamanan. Selain mengelola aturan, komentar (jika didukung) akan dimasukkan dalam aturan untuk membantu menunjukkan tujuan aturan.

Komentar berikut ditambahkan ke aturan yang ditetapkan sesuai:

  • Lakukan NAT sumber pada lalu lintas keluar.

  • Aturan penurunan default untuk lalu lintas yang tidak cocok.

  • Lalu lintas langsung dari antarmuka VM ke rantai grup keamanan.

  • Beralih ke rantai spesifik VM.

  • Lalu lintas masuk langsung dari VM ke rantai grup keamanan.

  • Izinkan lalu lintas dari pasangan IP/MAC yang ditentukan.

  • Turunkan traffic tanpa aturan IP/MAC.

  • Izinkan lalu lintas klien DHCP.

  • Mencegah Spoofing DHCP oleh VM.

  • Kirim lalu lintas yang tak cocok ke rantai fallback.

  • Turunkan paket yang tidak terkait dengan keadaan.

  • Paket langsung yang terkait dengan sesi yang diketahui ke rantai RETURN.

  • Izinkan lalu lintas ICMP IPv6 untuk memungkinkan paket RA.

Jalankan perintah berikut untuk melihat konfigurasi iptables saat ini:

# iptables-save

Catatan

Jika Anda mengubah konfigurasi, itu akan kembali saat Anda memulai kembali nova-network atau neutron-server di lain waktu. Anda harus menggunakan OpenStack untuk mengelola iptables.

Konfigurasi jaringan dalam Database untuk nova-network

Dengan nova-network, tabel database nova berisi beberapa tabel dengan informasi jaringan:

fixed_ips

Berisi setiap kemungkinan alamat IP untuk subnet yang ditambahkan ke Compute. Tabel ini terkait dengan tabel instance melalui kolom fixed_ips.instance_uuid.

floating_ips

Berisi setiap alamat IP mengambang (floating IP) yang ditambahkan ke Compute. Tabel ini terkait dengan tabel fix_ips melalui kolom floating_ips.fixed_ip_id.

instances

Tidak sepenuhnya spesifik jaringan, tetapi berisi informasi tentang instance yang menggunakan fixed_ip dan opsional floating_ip.

Dari tabel ini, Anda dapat melihat bahwa IP mengambang secara teknis tidak pernah terkait langsung dengan instance; itu harus selalu melalui IP tetap.

Secara Manual Melepaskan IP Mengambang

Terkadang sebuah instance dihentikan tetapi IP mengambang tidak dipisahkan dengan benar dari instance itu. Karena database berada dalam keadaan tidak konsisten, alat yang biasa digunakan untuk memisahkan IP tidak lagi berfungsi. Untuk memperbaikinya, Anda harus memperbarui basis data secara manual.

Pertama, temukan UUID dari instance yang dimaksud:

mysql> select uuid from instances where hostname = 'hostname';

Selanjutnya, cari entri IP tetap untuk UUID itu:

mysql> select * from fixed_ips where instance_uuid = '<uuid>';

Anda sekarang bisa mendapatkan entri IP mengambang terkait:

mysql> select * from floating_ips where fixed_ip_id = '<fixed_ip_id>';

Dan akhirnya, Anda dapat melepaskan IP mengambang:

mysql> update floating_ips set fixed_ip_id = NULL, host = NULL where
       fixed_ip_id = '<fixed_ip_id>';

Secara opsional Anda juga dapat membatalkan alokasi IP dari kumpulan pengguna:

mysql> update floating_ips set project_id = NULL where
       fixed_ip_id = '<fixed_ip_id>';

Debugging Issue DHCP dengan nova-network

Salah satu masalah jaringan yang umum adalah bahwa instance mem-boot dengan sukses tetapi tidak dapat dijangkau karena gagal mendapatkan alamat IP dari dnsmasq, yang merupakan server DHCP yang diluncurkan oleh layanan nova-network.

Cara paling sederhana untuk mengidentifikasi bahwa ini adalah masalah dengan instance Anda adalah dengan melihat output konsol instance Anda. Jika DHCP gagal, Anda dapat mengambil log konsol dengan melakukan:

$ openstack console log show <instance name or uuid>

Jika instance Anda gagal mendapatkan IP melalui DHCP, beberapa pesan akan muncul di konsol. Misalnya, untuk image Cirros, Anda melihat output yang terlihat seperti berikut:

udhcpc (v1.17.2) started
Sending discover...
Sending discover...
Sending discover...
No lease, forking to background
starting DHCP forEthernet interface eth0 [ [1;32mOK[0;39m ]
cloud-setup: checking http://169.254.169.254/2009-04-04/meta-data/instance-id
wget: can't connect to remote host (169.254.169.254): Network is
unreachable

Setelah Anda memastikan bahwa instance boot dengan benar, tugasnya adalah mencari tahu di mana kegagalannya.

Masalah DHCP mungkin disebabkan oleh proses dnsmasq yang salah. Pertama, debug dengan memeriksa log dan kemudian restart proses dnsmasq hanya untuk proyek itu (tenant). Dalam mode VLAN, ada proses dnsmasq untuk setiap tenant. Setelah Anda me-restart proses dnsmasq yang ditargetkan, cara paling sederhana untuk mengesampingkan penyebab dnsmasq adalah dengan mematikan semua proses dnsmasq pada mesin dan me-restart nova-network. Sebagai upaya terakhir, lakukan ini sebagai root:

# killall dnsmasq
# restart nova-network

Catatan

Gunakan openstack-nova-network di RHEL / CentOS / Fedora tetapi nova-network di Ubuntu / Debian.

Beberapa menit setelah nova-network dimulai ulang, Anda akan melihat proses dnsmasq baru berjalan:

# ps aux | grep dnsmasq
nobody 3735 0.0 0.0 27540 1044 ? S 15:40 0:00 /usr/sbin/dnsmasq --strict-order
    --bind-interfaces --conf-file=
    --domain=novalocal --pid-file=/var/lib/nova/networks/nova-br100.pid
    --listen-address=192.168.100.1 --except-interface=lo
    --dhcp-range=set:'novanetwork',192.168.100.2,static,120s
    --dhcp-lease-max=256
    --dhcp-hostsfile=/var/lib/nova/networks/nova-br100.conf
    --dhcp-script=/usr/bin/nova-dhcpbridge --leasefile-ro
root 3736 0.0 0.0 27512 444 ? S 15:40 0:00 /usr/sbin/dnsmasq --strict-order
     --bind-interfaces --conf-file=
     --domain=novalocal --pid-file=/var/lib/nova/networks/nova-br100.pid
     --listen-address=192.168.100.1 --except-interface=lo
     --dhcp-range=set:'novanetwork',192.168.100.2,static,120s
     --dhcp-lease-max=256
     --dhcp-hostsfile=/var/lib/nova/networks/nova-br100.conf
     --dhcp-script=/usr/bin/nova-dhcpbridge --leasefile-ro

Jika instance Anda masih tidak dapat memperoleh alamat IP, hal berikutnya yang perlu diperiksa adalah apakah dnsmasq melihat permintaan DHCP dari instance. Pada mesin yang menjalankan proses dnsmasq, yang merupakan host komputasi jika berjalan dalam mode multi-host, lihat /var/log/syslog untuk melihat output dnsmasq. Jika dnsmasq melihat permintaan dengan benar dan membagikan IP, hasilnya terlihat seperti ini:

Feb 27 22:01:36 mynode dnsmasq-dhcp[2438]: DHCPDISCOVER(br100) fa:16:3e:56:0b:6f
Feb 27 22:01:36 mynode dnsmasq-dhcp[2438]: DHCPOFFER(br100) 192.168.100.3
                                           fa:16:3e:56:0b:6f
Feb 27 22:01:36 mynode dnsmasq-dhcp[2438]: DHCPREQUEST(br100) 192.168.100.3
                                           fa:16:3e:56:0b:6f
Feb 27 22:01:36 mynode dnsmasq-dhcp[2438]: DHCPACK(br100) 192.168.100.3
                                           fa:16:3e:56:0b:6f test

Jika Anda tidak melihat DHCPDISCOVER, ada masalah dengan paket yang didapat dari instance ke mesin yang menjalankan dnsmasq. Jika Anda melihat semua output sebelumnya dan instance Anda masih tidak dapat memperoleh alamat IP, maka paket tersebut bisa mendapatkan dari instance ke host yang menjalankan dnsmasq, tetapi tidak dapat melakukan perjalanan kembali.

Anda mungkin juga melihat pesan seperti ini:

Feb 27 22:01:36 mynode dnsmasq-dhcp[25435]: DHCPDISCOVER(br100)
            fa:16:3e:78:44:84 no address available

Ini mungkin masalah dnsmasq dan/atau nova-network terkait. (Sebagai contoh sebelumnya, masalahnya adalah bahwa dnsmasq tidak memiliki alamat IP untuk diberikan karena tidak ada lagi IP tetap yang tersedia di basis data OpenStack Compute.)

Jika ada pesan log dnsmasq yang tampak mencurigakan, lihat argumen baris perintah untuk proses dnsmasq untuk melihat apakah mereka terlihat benar:

$ ps aux | grep dnsmasq

Outputnya terlihat seperti berikut:

108 1695 0.0 0.0 25972 1000 ? S Feb26 0:00 /usr/sbin/dnsmasq
 -u libvirt-dnsmasq
 --strict-order --bind-interfaces
 --pid-file=/var/run/libvirt/network/default.pid --conf-file=
 --except-interface lo --listen-address 192.168.122.1
 --dhcp-range 192.168.122.2,192.168.122.254
 --dhcp-leasefile=/var/lib/libvirt/dnsmasq/default.leases
 --dhcp-lease-max=253 --dhcp-no-override
nobody 2438 0.0 0.0 27540 1096 ? S Feb26 0:00 /usr/sbin/dnsmasq
 --strict-order --bind-interfaces --conf-file=
 --domain=novalocal --pid-file=/var/lib/nova/networks/nova-br100.pid
 --listen-address=192.168.100.1
 --except-interface=lo
 --dhcp-range=set:'novanetwork',192.168.100.2,static,120s
 --dhcp-lease-max=256
 --dhcp-hostsfile=/var/lib/nova/networks/nova-br100.conf
 --dhcp-script=/usr/bin/nova-dhcpbridge --leasefile-ro
root 2439 0.0 0.0 27512 472 ? S Feb26 0:00 /usr/sbin/dnsmasq --strict-order
 --bind-interfaces --conf-file=
 --domain=novalocal --pid-file=/var/lib/nova/networks/nova-br100.pid
 --listen-address=192.168.100.1
 --except-interface=lo
 --dhcp-range=set:'novanetwork',192.168.100.2,static,120s
 --dhcp-lease-max=256
 --dhcp-hostsfile=/var/lib/nova/networks/nova-br100.conf
 --dhcp-script=/usr/bin/nova-dhcpbridge --leasefile-ro

Output menunjukkan tiga proses dnsmasq yang berbeda. Proses dnsmasq yang memiliki rentang subnet DHCP 192.168.122.0 milik libvirt dan dapat diabaikan. Dua proses dnsmasq lainnya adalah milik nova-network. Kedua proses itu sebenarnya saling terkait — yang satu hanyalah proses induk dari yang lain. Argumen proses dnsmasq harus sesuai dengan detail yang Anda konfigurasikan nova-network dengan.

Jika masalah tampaknya tidak terkait dengan dnsmasq itu sendiri, pada titik ini gunakan tcpdump pada antarmuka untuk menentukan di mana paket-paket hilang.

Lalu lintas DHCP menggunakan UDP. Klien mengirim dari port 68 ke port 67 di server. Cobalah untuk mem-boot instance baru dan kemudian secara sistematis mendengarkan NIC sampai Anda mengidentifikasi yang tidak melihat lalu lintas. Untuk menggunakan tcpdump untuk mendengarkan port 67 dan 68 di br100, Anda harus:

# tcpdump -i br100 -n port 67 or port 68

Anda harus melakukan pemeriksaan kewarasan pada antarmuka menggunakan perintah seperti ip a dan brctl show untuk memastikan bahwa antarmuka benar-benar siap (up) dan mengkonfigurasi cara Anda berpikir bahwa mereka.

Mendebug DNS Issues

Jika Anda dapat menggunakan SSH untuk masuk ke sebuah instance, tetapi butuh waktu yang sangat lama (dalam urutan satu menit) untuk mendapatkan prompt, maka Anda mungkin memiliki DNS issue. Alasan masalah DNS dapat menyebabkan masalah ini adalah bahwa server SSH melakukan pencarian DNS terbalik pada alamat IP yang Anda hubungkan. Jika pencarian DNS tidak bekerja pada instance Anda, maka Jika Anda dapat menggunakan: istilah: SSH <secure shell (SSH)> untuk masuk ke sebuah instance, tetapi butuh waktu yang sangat lama (dalam urutan satu menit) untuk mendapatkan prompt, maka Anda mungkin memiliki Masalah DNS. Alasan masalah DNS dapat menyebabkan masalah ini adalah bahwa server SSH melakukan pencarian DNS terbalik pada alamat IP yang Anda hubungkan. Jika pencarian DNS tidak berfungsi pada instance Anda, maka Anda harus menunggu waktu tunggu DNS reverse lookup agar proses masuk SSH selesai.

Ketika men-debug masalah DNS, mulailah dengan memastikan bahwa host tempat proses dnsmasq untuk instance berjalan dapat menyelesaikan dengan benar. Jika host tidak dapat menyelesaikan, maka instance tidak akan bisa baik.

Cara cepat untuk memeriksa apakah DNS berfungsi adalah dengan menyelesaikan nama host di dalam instance Anda dengan menggunakan perintah host. Jika DNS berfungsi, Anda akan melihat:

$ host openstack.org
openstack.org has address 174.143.194.225
openstack.org mail is handled by 10 mx1.emailsrvr.com.
openstack.org mail is handled by 20 mx2.emailsrvr.com.

Jika Anda menjalankan image Cirros, itu tidak memiliki program "host" yang diinstal, dalam hal ini Anda dapat menggunakan ping untuk mencoba mengakses mesin dengan nama host untuk melihat apakah itu menyelesaikan. Jika DNS berfungsi, baris pertama ping adalah:

$ ping openstack.org
PING openstack.org (174.143.194.225): 56 data bytes

Jika instance gagal untuk menyelesaikan nama host, Anda memiliki masalah DNS. Sebagai contoh:

$ ping openstack.org
ping: bad address 'openstack.org'

Dalam cloud OpenStack, proses dnsmasq bertindak sebagai server DNS untuk instance selain bertindak sebagai server DHCP. Proses dnsmasq yang keliru mungkin menjadi sumber masalah terkait DNS di dalam instance. Seperti disebutkan di bagian sebelumnya, cara paling sederhana untuk mengesampingkan proses dnsmasq yang rusak adalah dengan mematikan semua proses dnsmasq pada mesin dan memulai kembali nova-network. Namun, perlu diketahui bahwa perintah ini mempengaruhi semua orang yang menjalankan instance pada node ini, termasuk penyewa yang belum melihat masalah. Sebagai upaya terakhir, sebagai root:

# killall dnsmasq
# restart nova-network

Setelah proses dnsmasq mulai lagi, periksa apakah DNS berfungsi.

Jika memulai kembali proses dnsmasq tidak memperbaiki masalah, Anda mungkin perlu menggunakan tcpdump untuk melihat paket-paket untuk melacak di mana kegagalannya. Server DNS mendengarkan pada port UDP 53. Anda harus melihat permintaan DNS pada bridge (seperti, br100) dari node komputasi Anda. Katakanlah Anda mulai mendengarkan dengan tcpdump pada compute node:

# tcpdump -i br100 -n -v udp port 53
tcpdump: listening on br100, link-type EN10MB (Ethernet), capture size 65535 bytes

Kemudian, jika Anda menggunakan SSH untuk masuk ke instance Anda dan mencoba ping openstack.org, Anda akan melihat sesuatu seperti:

16:36:18.807518 IP (tos 0x0, ttl 64, id 56057, offset 0, flags [DF],
 proto UDP (17), length 59)
 192.168.100.4.54244 > 192.168.100.1.53: 2+ A? openstack.org. (31)
16:36:18.808285 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF],
 proto UDP (17), length 75)
 192.168.100.1.53 > 192.168.100.4.54244: 2 1/0/0 openstack.org. A
 174.143.194.225 (47)

Pemecahan masalah Open vSwitch

Open vSwitch, seperti yang digunakan dalam contoh OpenStack Networking sebelumnya adalah switch virtual multilayer berfitur lengkap yang dilisensikan di bawah lisensi open source Apache 2.0. Dokumentasi lengkap dapat ditemukan di the project's website <http://www.openvswitch.org/> _. Dalam prakteknya, mengingat konfigurasi sebelumnya, masalah yang paling umum adalah memastikan bahwa jembatan yang diperlukan (br-int, br-tun, dan br-ex) ada dan memiliki hak port yang terhubung dengannya.

Driver Open vSwitch harus dan biasanya mengelola ini secara otomatis, tetapi berguna untuk mengetahui bagaimana melakukan ini dengan tangan dengan perintah :command: ovs-vsctl. Perintah ini memiliki lebih banyak sub perintah daripada yang akan kita gunakan di sini; lihat halaman manual atau gunakan ovs-vsctl --help untuk daftar lengkap.

Untuk daftar jembatan pada suatu sistem, gunakan ovs-vsctl list-br. . Contoh ini menunjukkan node komputasi yang memiliki jembatan internal dan jembatan terowongan. Jaringan VLAN trunked melalui antarmuka jaringan eth1:

# ovs-vsctl list-br
br-int
br-tun
eth1-br

Bekerja dari antarmuka fisik ke dalam, kita dapat melihat rantai port dan jembatan. Pertama, jembatan eth1-br, yang berisi antarmuka jaringan fisik eth1 dan antarmuka virtual phy-eth1-br:

# ovs-vsctl list-ports eth1-br
eth1
phy-eth1-br

Selanjutnya, jembatan internal, br-int, berisi int-eth1-br, yang berpasangan dengan phy-eth1-br untuk menyambung ke jaringan fisik yang ditunjukkan pada jembatan sebelumnya, patch-tun, yang digunakan untuk menghubungkan ke jembatan terowongan GRE dan perangkat TAP yang terhubung ke instance yang sedang berjalan pada sistem:

# ovs-vsctl list-ports br-int
int-eth1-br
patch-tun
tap2d782834-d1
tap690466bc-92
tap8a864970-2d

Bridge tunnel, br-tun, berisi antarmuka patch-int dan antarmuka ``gre- <N> `` untuk setiap peer yang terhubung melalui GRE, satu untuk setiap komputasi dan node jaringan di kluster Anda:

# ovs-vsctl list-ports br-tun
patch-int
gre-1
.
.
.
gre-<N>

Jika ada dari tautan ini yang hilang atau salah, ini menunjukkan kesalahan konfigurasi. Bridges dapat ditambahkan dengan ovs-vsctl add-br, dan port dapat ditambahkan ke bridge dengan ovs-vsctl add-port. Saat menjalankan ini dengan tangan dapat menjadi debugging yang berguna, sangat penting bahwa perubahan manual yang Anda ingin tetap dipantulkan kembali ke file konfigurasi Anda.

Berurusan dengan Network Namespaces

Namespace jaringan Linux adalah fitur kernel yang digunakan layanan jaringan untuk mendukung beberapa jaringan layer-2 yang terisolasi dengan rentang alamat IP yang tumpang tindih. Dukungan mungkin dinonaktifkan, tetapi diaktifkan secara default. Jika diaktifkan di lingkungan Anda, node jaringan Anda akan menjalankan agen dhcp dan l3-agen di ruang nama yang terisolasi. Antarmuka jaringan dan lalu lintas pada antarmuka tersebut tidak akan terlihat di namespace default.

Untuk melihat apakah Anda menggunakan namespace, jalankan ip netns:

# ip netns
qdhcp-e521f9d0-a1bd-4ff4-bc81-78a60dd88fe5
qdhcp-a4d00c60-f005-400e-a24c-1bf8b8308f98
qdhcp-fe178706-9942-4600-9224-b2ae7c61db71
qdhcp-0a1d0a27-cffa-4de3-92c5-9d3fd3f2e74d
qrouter-8a4ce760-ab55-4f2f-8ec5-a2e858ce0d39

Namespace router agen L3 dinamai qrouter- <router_uuid> ``, dan space nama agen dhcp-agent dinamai ``qdhcp- <net_uuid> ``. Output ini menunjukkan node jaringan dengan empat jaringan yang menjalankan dhcp-agent, salah satunya juga menjalankan router l3-agent. Sangat penting untuk mengetahui di jaringan mana Anda perlu bekerja. Daftar jaringan yang ada dan UUIDnya dapat diperoleh dengan menjalankan ``openstack network list dengan kredensial administratif.

Setelah Anda menentukan namespace mana yang Anda butuhkan untuk bekerja, Anda dapat menggunakan salah satu alat debugging yang disebutkan sebelumnya dengan mengawali perintah dengan ``ip netns exec <namespace> ``. Misalnya, untuk melihat antarmuka jaringan apa yang ada di namespace qdhcp pertama yang dikembalikan di atas, lakukan ini:

# ip netns exec qdhcp-e521f9d0-a1bd-4ff4-bc81-78a60dd88fe5 ip a
10: tape6256f7d-31: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/ether fa:16:3e:aa:f7:a1 brd ff:ff:ff:ff:ff:ff
    inet 10.0.1.100/24 brd 10.0.1.255 scope global tape6256f7d-31
    inet 169.254.169.254/16 brd 169.254.255.255 scope global tape6256f7d-31
    inet6 fe80::f816:3eff:feaa:f7a1/64 scope link
    valid_lft forever preferred_lft forever
28: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
    valid_lft forever preferred_lft forever

Dari sini Anda melihat bahwa server DHCP pada jaringan itu menggunakan perangkat tape6256f7d-31 dan memiliki alamat IP 10.0.1.100. Melihat alamat 169.254.169.254, Anda juga dapat melihat bahwa agen dhcp menjalankan layanan proxy-metadata. Perintah apa pun yang disebutkan sebelumnya dalam bab ini dapat dijalankan dengan cara yang sama. Dimungkinkan juga untuk menjalankan shell, seperti bash, dan memiliki sesi interaktif di dalam namespace. Dalam kasus terakhir, keluar dari shell mengembalikan Anda ke namespace default tingkat atas.

Mengangkat alamat IPv4 yang hilang kembali ke proyek

  1. Menggunakan kredensial administrator, konfirmasi alamat IP yang hilang masih tersedia:

    # openstack server list --all-project | grep 'IP-ADDRESS'

  2. Membuat port:

    $ openstack port create --network NETWORK_ID PORT_NAME

  3. Perbarui port baru dengan alamat IPv4:

    # openstack subnet list
# neutron port-update PORT_NAME --request-format=json --fixed-ips \
type=dict list=true subnet_id=NETWORK_ID_IPv4_SUBNET_ID \
ip_address=IP_ADDRESS  subnet_id=NETWORK_ID_IPv6_SUBNET_ID
# openstack port show PORT-NAME

Alat untuk diagnosis neutron otomatis

`easyOVS <https://github.com/yeasy/easyOVS>`_adalah alat yang berguna untuk mengoperasikan jembatan dan iptables OpenvSwitch Anda pada platform OpenStack Anda. Secara otomatis mengaitkan port virtual dengan VM MAC/IP, tag VLAN dan informasi namespace, serta aturan iptables untuk VM.

Don adalah analisis jaringan dan sistem diagnostik yang nyaman yang menyediakan layanan yang sepenuhnya otomatis untuk memverifikasi dan mendiagnosis fungsionalitas jaringan yang disediakan oleh OVS.

Selain itu, Anda dapat merujuk neutron client untuk opsi lainnya.