EVE-NG Linuxのイメージ追加

スポンサーリンク

EVE-NGはネットワークエミュレータのソフトウェアで、Cisco機以外も含めて様々なネットワーク機器をエミュレートする事ができます。このページでは、Linuxのイメージ追加(初期設定)方法を説明します。

前提

公式ドキュメント

参考になる公式ドキュメントを以下に示します。

動作確認済環境

動作確認済の環境は以下の通りです。

  • EVE Community Edition Version 5.0.1-19
  • VMware ESXi, 7.0.3, 20036589
  • Ubuntu 18.04 server, Alima Linux 8.9

EVE-NGが用意したディスクイメージを利用する場合

仮想ディスクのダウンロード

Linux images」をブラウザで開き、「Download link for ready to use Linux Images Here」のリンクをクリックします。

Linuxイメージのダウンロード

仮想ディスクのダウンロード画面が現れますので、お好みのLinuxの仮想ディスクをダウンロードします。以下、ubuntu-18.04-serverを例に挙げて説明します。

Ubuntuイメージのダウンロード

仮想ディスクの配置

「/opt/unetlab/addons/qemu/」配下にCD-ROMと仮想ディスクを配置するディレクトリを作成します。ディレクトリの命名規則は「–<任意の名前>」です。名前にはディストリビューションとバージョン番号を入れると分かりやすいでしょう。

mkdir /opt/unetlab/addons/qemu/linux-ubuntu-18.04-server/
cd /opt/unetlab/addons/qemu/linux-ubuntu-18.04-server/


仮想ディスクを上記ディレクトリに配置します。その後、gzipコマンドで展開操作をし、virtioa.qcow2という名前に変更します。


gunzip linux-ubuntu-18.04-server.tar.gz
mv linux-ubuntu-18.04-server.tar virtioa.qcow2

ディスクイメージを独自に作成する場合

CR-ROMと仮想ディスクの配置

「/opt/unetlab/addons/qemu/」配下にCD-ROMと仮想ディスクを配置するディレクトリを作成します。ディレクトリの命名規則は「-<任意の名前>」です。名前にはディストリビューションとバージョン番号を入れると分かりやすいでしょう。

以下、Alma Linux 9.8を例に挙げた操作方法を説明します。

mkdir /opt/unetlab/addons/qemu/linux-alma-8.9/

作成したディレクトリ配下にCD-ROMと仮想ディスクを配置します。

cd /opt/unetlab/addons/qemu/linux-alma-8.9/

wget https://repo.almalinux.org/almalinux/8.9/isos/x86_64/AlmaLinux-8.9-x86_64-minimal.iso
mv AlmaLinux-8.9-x86_64-minimal.iso cdrom.iso

/opt/qemu/bin/qemu-img create -f qcow2 virtioa.qcow2 30G

OSインストール

EVE-NGのラボ上に前述の操作で作成したLinuxを配置します。「Add an object」「Node」「Linux」の順にクリックし、「linux-alma-9.8」というイメージを配置します。

Amla Linuxの追加

仮想マシンを起動します。

Alma Linuxの起動

Linuxのインストール操作をします。

Alma Linuxのインストール

初期設定

おそらく、Linuxを用いた動作確認をする時に使用頻度の高い初期設定があるかと思います。毎度毎度同じコマンドを入力するのは手間ですので、初期設定保存済のLinuxのイメージを作成しましょう。

どのような初期設定が望ましいかは業務依存で、万人に望ましい初期設定は存在しません。参考情報として、私がよく使用する初期設定を以下に載せます。

mkdir .ssh
cat << EOF > .ssh/authorized_keys
ssh-rsa xxxxxxxx xxx@xxx.com
ssh-rsa yyyyyyyy yyy@yyy.com
ssh-rsa zzzzzzzz zzz@zzz.com
EOF

# enable ip forwarding
echo "net.ipv4.ip_forward = 1 " >> /etc/sysctl.conf
echo "net.ipv6.conf.all.forwarding= 1 " >> /etc/sysctl.conf

dnf install -y \
  net-tools traceroute net-snmp net-snmp-utils bind-utils \
  httpd git bash-completion \
  tcpdump wireshark-cli

# install tc
dnf install -y kernel-modules-extra iproute-tc 

# install hping3
dnf install -y epel-release
dnf install -y hping3

# install frrouting
dnf install -y --enablerepo=powertools git autoconf pcre-devel \
  automake libtool make readline-devel texinfo net-snmp-devel pkgconfig \
  groff pkgconfig json-c-devel pam-devel bison flex python2-pytest \
  c-ares-devel python2-devel libcap-devel \
  elfutils-libelf-devel
rpm -ihv https://rpm.frrouting.org/repo/frr-stable-repo-1-0.el8.noarch.rpm
dnf install -y frr frr-pythontools

# install mtools (multicast tools)
dnf groupinstall -y "Development Tools"
cd /usr/local/src/
git clone https://github.com/troglobit/mtools
cd /usr/local/src/mtools
make
ln -s /usr/local/src/mtools/msend /usr/local/bin/msend
ln -s /usr/local/src/mtools/mreceive /usr/local/bin/mreceive
echo "net.ipv4.conf.all.force_igmp_version = 2 " >> /etc/sysctl.conf

shutdown -h now

初期設定の保存

以上の操作によって作成された仮想ディスクを初期設定として保存しましょう。仮想ディスクは以下のディレクトリに保存されています。

/opt/unetlab/tmp/<POD Nr>/<Lab UUID>/<Node ID>/
変数 調査方法
POD Nr ポッド番号。ユーザ毎にポッドが割り当てられ、adminの場合は0になる。ユーザ編集画面より調査可能。
Lab UUID ラボの詳細画面(Lab Details)より調査可能
Node ID ノード編集画面(Nodes/Edit)より調査可能

以下のような操作で仮想ディスクを初期設定として保存する事ができます。

Lab UUIDやNode IDを調査するのが手間の場合は、ユーザー1つとラボ1つとノード1つだけを作成するタブ補完操作で目的のディレクトリまで移動する事ができます。

cd /opt/unetlab/tmp/0/4e925190-9136-4f69-aa7a-a5b7be57e101/1/
/opt/qemu/bin/qemu-img commit virtioa.qcow2

補足

checksum incorrect

現象説明

EVE-NGでLinuxを使用する場合、pingによる疎通確認は正常であるものの、ファイアウォール機器を経由したり一部アプリケーションのみが疎通不能になる現象に遭遇するかもしれません。そのような場合は、virtio driverのhardware offloadの不具合の可能性を疑ってみましょう。

Linux間の接続

以下スクリーンショットに示すような構成で、linux01(192.168.1.1)からlinux02(192.168.1.2)へのsshによる接続を試みます。

[root@linux01 ~]# ssh 192.168.1.2
root@192.168.1.2's password: 
Last login: Thu Dec 21 01:01:38 2023
[root@linux02 ~]# 

この時、送信元であるlinux01(192.168.1.1)でパケットキャプチャを試みると、"chsum 0xXXXX (incorrect -> 0xXXXX)"とchecksumが不正になっている事が分かります。

一見すると不具合っぽく見えますが、これは仕様です。多くのLinuxディストリビューションのデフォルト設定は、tcp checksumおよびudp checksumの計算はNICに処理をオフロード(委任)します。ですので、NICからパケットが送信される前の状態のパケットキャプチャではchecksumが正しくないのは、checksumの計算前の状態ですので意図した挙動です。

[root@linux01 ~]# tcpdump -nnn -vvv -i ens3 tcp port 22
dropped privs to tcpdump
tcpdump: listening on ens3, link-type EN10MB (Ethernet), capture size 262144 bytes
01:07:37.246614 IP (tos 0x0, ttl 64, id 60605, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.1.1.47986 > 192.168.1.2.22: Flags [S], cksum 0x8382 (incorrect -> 0x3a8a), seq 1134652971, win 29200, options [mss 1460,sackOK,TS val 3993615538 ecr 0,nop,wscale 7], length 0
01:07:37.250753 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.1.2.22 > 192.168.1.1.47986: Flags [S.], cksum 0x8382 (incorrect -> 0xe7e0), seq 109708415, ack 1134652972, win 28960, options [mss 1460,sackOK,TS val 3865207324 ecr 3993615538,nop,wscale 7], length 0

checksumの計算がNICへオフロードされているかどうかを確認するには、ethtoolコマンドを使用します。操作例は以下の通りです。

[root@linux01 ~]# ethtool -k ens3
Features for ens3:
rx-checksumming: on [fixed]
tx-checksumming: on
  tx-checksum-ipv4: off [fixed]
  tx-checksum-ip-generic: on
  tx-checksum-ipv6: off [fixed]
  tx-checksum-fcoe-crc: off [fixed]
  tx-checksum-sctp: off [fixed]
scatter-gather: on
  tx-scatter-gather: on
  tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: on
  tx-tcp-segmentation: on
  tx-tcp-ecn-segmentation: on
  tx-tcp-mangleid-segmentation: off
  tx-tcp6-segmentation: on
generic-segmentation-offload: on
generic-receive-offload: on

次に、宛先であるlinux02(192.168.1.2)でパケットキャプチャを試みます。"chsum 0xXXXX (incorrect -> 0xXXXX)"とchecksumが不正になっています。NICによるchecksum計算後のパケットですので、これは不具合です。

[root@linux02 ~]# tcpdump -nnn -vvv -i ens3 tcp port 22
dropped privs to tcpdump
tcpdump: listening on ens3, link-type EN10MB (Ethernet), capture size 262144 bytes
01:13:50.545239 IP (tos 0x0, ttl 64, id 51348, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.1.1.34796 > 192.168.1.2.22: Flags [S], cksum 0x8382 (incorrect -> 0x89f4), seq 3793683292, win 29200, options [mss 1460,sackOK,TS val 3993988377 ecr 0,nop,wscale 7], length 0
01:13:50.545540 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.1.2.22 > 192.168.1.1.34796: Flags [S.], cksum 0x8382 (incorrect -> 0x4868), seq 3599069946, ack 3793683293, win 28960, options [mss 1460,sackOK,TS val 3865580162 ecr 3993988377,nop,wscale 7], length 0
01:13:50.546690 IP (tos 0x0, ttl 64, id 51349, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.1.34796 > 192.168.1.2.22: Flags [.], cksum 0x837a (incorrect -> 0xe76d), seq 1, ack 1, win 229, options [nop,nop,TS val 3993988379 ecr 3865580162], length 0

回避策A. オフロードの無効化

NICへのオフロードを無効化する事で不具合を回避できます。オフロードを無効化する操作は以下のようになります。

virtioのオフロードに関する不具合のフォーラムをみると多くの場合はethtoolコマンドによる回避策例が示されています。ethtoolコマンドでも回避可能ですが、OS再起動と同時に設定が失われる事に注意ください。また、以下の操作例はNetwork Managerを採用しているLinuxディストリビューションを念頭に置いていますので、ディストリビューションによっては異なる操作が必要である事を注意ください

nmcli connection modify ens3 ethtool.feature-tx-checksum-ip-generic off

設定を反映させます。

nmcli connection up ens3

checksumのオフロードが無効に変わった事を確認します。

[root@linux01 ~]# ethtool -k ens3
Features for ens3:
rx-checksumming: on [fixed]
tx-checksumming: off
  tx-checksum-ipv4: off [fixed]
  tx-checksum-ip-generic: off
  tx-checksum-ipv6: off [fixed]
  tx-checksum-fcoe-crc: off [fixed]
  tx-checksum-sctp: off [fixed]
scatter-gather: on
  tx-scatter-gather: on
  tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: off
  tx-tcp-segmentation: off [requested on]
  tx-tcp-ecn-segmentation: off [requested on]
  tx-tcp-mangleid-segmentation: off
  tx-tcp6-segmentation: off [requested on]
generic-segmentation-offload: on
generic-receive-offload: on

オフロードの無効後、確かにchecksumの値がcorrectとなった事を確認します。

[root@linux02 ~]# tcpdump -nnn -vvv -i ens3 tcp port 22
dropped privs to tcpdump
tcpdump: listening on ens3, link-type EN10MB (Ethernet), capture size 262144 bytes
01:22:37.941936 IP (tos 0x0, ttl 64, id 27093, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.1.1.45844 > 192.168.1.2.22: Flags [S], cksum 0xa2a1 (correct), seq 2160137477, win 29200, options [mss 1460,sackOK,TS val 3994515697 ecr 0,nop,wscale 7], length 0
01:22:37.943544 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.1.2.22 > 192.168.1.1.45844: Flags [S.], cksum 0x8382 (incorrect -> 0x7cdc), seq 1864734855, ack 2160137478, win 28960, options [mss 1460,sackOK,TS val 356714932 ecr 3994515697,nop,wscale 7], length 0

回避策B. NIC変更

もう1つの回避策は不具合の存在しないNICを使用する事です。EVE-NGでLinuxを動作させる場合、デフォルト設定の状態でQEMU Nicは「virtio-net-pci」を使用します。この設定を「e1000」に変更する事でchecksumに関する不具合を回避する事ができます。

NIC変更

タイトルとURLをコピーしました