VyOSとEdgeRouterにおけるBGPの設定と挙動の差異

目次

概要

本記事では、VyOSとEdgeRouterそれぞれにおいてBGPを設定する場合の設定項目の差異と、挙動の違いについてまとめます。
隅々まで調査したわけではなく、利用する中で判明した点をまとめたものですので、完璧ではないことを予めご理解ください。

VyOS

VyOSとは、オープンソースで提供されるソフトウェアルータです。
Debianをベースとして開発されており、ルーティングなどのネットワークの基本的な機能から、各種VPNプロトコルやトンネリングプロトコルなどを扱うことが出来ます。
vyos.io

EdgeRouter

EdgeRouterは、Ubiquiti Networks社が発売しているネットワーク機器のブランドです。
低価格でありながら高機能であり、またライセンス料などが発生しないという特徴を持つ製品です。
中身はVyOSベースとなっているようなので、基本的にVyOSのドキュメントを参考にすることが出来ます。

本記事では、EdgeOS v2.0.9-hotfix.1 を例に取り上げていきます。

BGP設定周りのコマンド体系

VyOSでは1.2系列からBGP設定周りのコマンド体系が一部変更となっています。
例えば、広報するネットワークを明記する場合、VyOS 1.2系以降では次のように記述します。

1
set protocols bgp address-family ipv4-unicast network 192.168.1.0/24

しかし、VyOS 1.1.8以前、またはEdgeRouterにおいては、address-family の下に ipv4-unicast という設定項目は存在しません。
したがって、VyOS 1.1.8以前、またはEdgeRouterにおいては次のように記述する必要があります。

1
set protocols bgp 65001 network 192.168.1.0/24

network項目で設定したネットワークの広報動作の違い

上記で例を示した network で指定した広報したいネットワークの広報動作についても、VyOSとEdgeRouterで挙動の違いがみられます。
VyOSの場合、こちらのページに次のような記述があります。

1
By default, the BGP prefix is advertised even if it’s not present in the routing table. This behaviour differs from the implementation of some vendors.

これは、この network で設定したネットワークについては、そのネットワークがルーティングテーブル上に存在しない場合でも広報を行うことを示していると解釈できます。
しかしながら、EdgeRouter環境においてはこの挙動に違いがみられます。
例として、先ほどのネットワークの設定を、先に述べたコマンド体系の違いを考慮した上で次のような設定をEdgeRouterへ流し込んだとします。

1
2
3
4
5
6
7
8
9
protocols {
bgp 65001 {
neighbor 10.0.0.2 {
remote-as 65002
}
network 192.168.1.0/24 {
}
}
}

上記設定の場合、VyOSのドキュメントを信用する限り、192.168.1.0/24というネットワークがルーティングテーブル上に存在しなくてもremote-asであるAS65002に対してこのネットワークが広報されることになります。
ここで、上記設定を流し込んだEdgeRouter上でルーティングテーブルを確認してみると以下のようになっていたとします。

1
2
3
4
5
6
7
8
9
$ show ip route
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
> - selected route, * - FIB route, p - stale info

IP Route Table for VRF "default"
K *> 0.0.0.0/0 [20/0] via XXX.XXX.XXX.XXX, eth0, 07:09:35

すなわち、192.168.1.0/24というネットワークはルーティングテーブル上に存在しないという事です。
この状態で、自ASが広報しているネットワークを確認してみると、次のようになります。

1
$ show ip bgp neighbors 10.0.0.2 advertised-routes

結果を書き忘れたわけではありません。広報しているネットワークが存在しない場合、説明書きすら表示されません。
ということで、ルーティングテーブル上に存在しなくても広報されるはずの192.168.1.0/24というネットワークは、EdgeRouter環境においては広報されない、という事になります。
この点、VyOSと挙動が異なるようですので注意が必要です。

実際には、ルーティングテーブル上に無いネットワークを広報することは危険であると考えられます。したがって、VyOSのドキュメントに記載があるように、他ベンダーやEdgeRouterにおいてこのような実装がなされていること自体は不思議ではありません。
(多くの場合、redistributeなどの指定を行うと思います。)
また、VyOSのドキュメントには、次の設定を行うことで、ルーティングテーブル上に存在しないネットワークを広報しなくなるという旨の記載があります。

1
set protocols bgp parameters network-import-check

もう少し調査してみると、EdgeRouterには上記の設定項目は存在しないことが分かります。これは、デフォルトでこのチェックが行われていることを暗示していると言えます。
また、次のような設定項目が存在することを確認できます。

1
set protocols bgp 4220101001 parameters disable-network-import-check

コマンド名から推察するに、デフォルトで有効になっている「ルーティングテーブル上に存在するかどうかのチェック」を無効化するコマンドであると考えられます。
しかし、EdgeRouterを展開するUbiquiti Networksのコミュニティサイトのこのページには、次のような記述があります。

1
2
3
The list below shows other config settings that are no longer supported.
~~中略~~
protocols bgp <> parameters disable-network-import-check

つまり、EdgeOS v1.8.0以降では上記設定はサポートされなくなっています。
実際、上記設定を EdgeOS v2.0.9-hotfix.1 に流し込んでみても、挙動は変化しませんでした。

では、対象のネットワークがルーティングテーブル上に存在する場合は正しく広報が行われるのか。
試しに、次のような設定をしてみます。

1
set protocols static route 192.168.1.0/24 blackhole

上記は、192.168.1.0/24を宛先無しで静的ルート登録を行うものです。
先ほどと同様にルーティングテーブルを確認してみます。

1
2
3
4
5
6
7
8
9
10
$ show ip route
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
> - selected route, * - FIB route, p - stale info

IP Route Table for VRF "default"
K *> 0.0.0.0/0 [20/0] via XXX.XXX.XXX.XXX, eth0, 07:09:35
S *> 192.168.1.0/24 [1/0] is a summary, Null

これで、ルーティングテーブルに192.168.1.0/24というネットワークが登録されました。(多少無理矢理ですが…)
少し待ってから、先ほどと同様に自ASが広報しているネットワークについて確認してみます。

1
2
3
4
5
6
7
8
9
$ show ip bgp neighbors 10.0.0.2 advertised-routes
BGP table version is 45, local router ID is XXX.XXX.XXX.XXX
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*> 192.168.1.0/24 10.0.0.1 100 32768 i

Total number of prefixes 1

ルーティングテーブルに登録された192.168.1.0/24というネットワークが広報されていることが確認できます。

ということで、EdgeRouterではルーティングテーブル上に存在しないネットワークは、たとえ指定したとしても広報されず、この動作はVyOSとは異なる というお話でした。

まとめ

EdgeRouterでBGPを扱うサンプルは割と散見されるのですが、「とりあえずBGPを動かしてみた」といった感じで実際の挙動に触れていないものが多かったので書いてみました。
VyOS 1.2系以降と、VyOS 1.1.8系以前やEdgeRouterでは、BGP周りのコマンド体系に違いがあります。
VyOSの情報を参考とする場合、注意が必要です。
また、BGP設定内の network で設定した挙動について、VyOSとEdgeRouterで違いがあることも確認できました。
実際、設定中にこの問題に直面したので、実験等でこの設定をされる際には注意が必要です。(ハマります)

kolla-ansibleを使ってOpenStack環境を構築してみる all-in-one編

目次

2021/01/09 インスタンスにパスワードを設定する箇所の誤りを修正しました。

kolla-ansibleとは

公式ページ

OpenStack 環境のデプロイメントツールです。
更に、完全にカスタマイズ可能であることも大きな特徴です。
加えて、CentOS や Ubuntu などの多くの Linux ディストリビューションに対応しているのも大きな特徴と言えます。
なお、デプロイには Ansible が利用されます。

他にも devstack や microstack など数多くのデプロイメントツールが存在しますが、これらは開発環境向けで、カスタマイズが困難であったり、再起動したら壊れてしまうものなど、扱いにくいのが現状です。
また、 kolla-ansible と同様に Ansible を利用して OpenStack 環境の構築を行う openstack-ansible なども存在しますが、こちらも筆者環境での検証では再起動したら壊れてしまうものでした。

そこで、今回は kolla-ansible を利用してみることにしました。
なお、 kolla-ansible ではすべてのコンポーネントを1つのサーバ上で動作させる all-in-one 構成と、複数のサーバをクラスタリングして利用する multinode 構成を選択することができます。
今回は all-in-one 構成を構築してみます。
multinode 構成については、次回以降取り扱う予定です。

インストール準備

kolla-ansible では CentOS や Ubuntu などを利用することができますが、本記事では Ubuntu 20.04 LTS を利用しています。

事前に python3 などを用意しておく必要がありますので、必要なパッケージとともに導入します。

1
2
3
$ sudo apt update
$ sudo apt install python3-dev libffi-dev gcc libssl-dev
$ sudo apt install python3-pip

インストールされた pip3 が最新バージョンであるか確認します。

1
$ sudo pip3 install -U pip

続いて、 Ansible をインストールします。

1
$ sudo apt install ansible

kolla 及び kolla-ansible のインストールを行います。
なお、ここでは apt でインストールする方法と、 github から落としてくる方法の2つが選択できますが、2020/12/29時点では apt からインストールするとUbuntu 20.04 LTSは動作対象外との旨が表示され先に進むことができなくなりますので、ここでは github から落としてきて利用します。

1
2
3
4
$ git clone https://github.com/openstack/kolla
$ git clone https://github.com/openstack/kolla-ansible
$ sudo pip3 install ./kolla
$ sudo pip3 install ./kolla-ansible

必要なディレクトリを作成し、所有権の設定を行います。

1
2
$ sudo mkdir -p /etc/kolla
$ sudo chown $USER:$USER /etc/kolla

先程 github から落としたファイルのうち、必要なファイルを作成したディレクトリへコピーします。

1
2
$ cp -r kolla-ansible/etc/kolla/* /etc/kolla
$ cp kolla-ansible/ansible/inventory/* .

ここで、 /etc/ansible/ansible.cfg[defaults] に以下を追記して Ansible の設定を変更します。

1
2
3
host_key_checking=False
pipelining=True
forks=100

ここで、 Ansible の設定とインベントリの構成が正しいかチェックしておきます。

1
$ ansible -i all-in-one all -m ping

OpenStack の各サービスのパスワード類を生成します。

1
2
$ cd ~/kolla-ansible/tools
$ ./generate_passwords.py

/etc/kolla/globals.yml を編集して kolla の設定を行います。
設定はページKolla globals.yml を参考にしてください。
なお、cinder などの有効化設定もこちらで行います。
必要に応じて設定をしてください。

1
2
3
4
5
kolla_base_distro: "ubuntu" #ホストOSのディストリビューション
kolla_install_type: "binary" #パッケージの取得方法
kolla_internal_vip_address: "192.168.122.206" #管理IFのアドレス
network_interface: "enp1s0" #管理ネットワークのIF
neutron_external_interface: "enp6s0" #OpenStack Neutron ネットワークのIF

デプロイを行います。

1
2
3
4
$ cd ~/kolla-ansible/tools
$ ./kolla-ansible -i ../../all-in-one bootstrap-servers
$ ./kolla-ansible -i ../../all-in-one prechecks
$ ./kolla-ansible -i ../../all-in-one deploy

ここまで完了すると、 kolla_internal_vip_address で設定したIPアドレスにアクセスすると OpenStack のダッシュボードが表示されます。
しかし、外部へアクセスするためのネットワークなどが設定されていないため、それらの設定を行います。
kolla-ansible/tools/init-runonce をエディタで開き、下記を追記します。
CIDRRANGE , GATEWAY などを適時変更します。

1
2
3
4
ENABLE_EXT_NET=${ENABLE_EXT_NET:-1}
EXT_NET_CIDR=${EXT_NET_CIDR:-'192.168.122.0/24'}
EXT_NET_RANGE=${EXT_NET_RANGE:-'start=192.168.122.15,end=192.168.122.45'}
EXT_NET_GATEWAY=${EXT_NET_GATEWAY:-'192.168.122.1'}

cloud-init を利用してインスタンスのパスワードを設定する場合は以下の変更を行います。
~/kolla-ansible/ansible/roles/nova/templates/nova.conf.j2

1
2
3
[libvirt]
inject_password = True
inject_partition = -1

この変更は、 /etc/kolla/nova-compute/nova.conf に反映されますされると記述があるのですが、こちらの環境では反映を確認できませんでした。

~/kolla-ansible/ansible/roles/horizon/templates/local_settings.j2

1
2
3
4
5
6
OPENSTACK_HYPERVISOR_FEATURES = {
'can_set_mount_point': False,
'can_set_password': True, //FalseをTrueに変更
'requires_keypair': False,
'enable_quotas': True
}

この変更は、 /etc/kolla/horizon/local_settings に反映されます。

最後に、変更した設定を OpenStack に適用します。
その前に、 python3-openstackclient をインストールしておきます。

1
$ sudo apt install python3-openstackclient

続いて、認証情報の入ったスクリプトファイルを生成します。

1
2
3
$ cd kolla-ansible/tools
$ ./kolla-ansible post-deploy
$ . /etc/kolla/admin-openrc.sh

変更した設定を適用します。

1
2
3
$ kolla-ansible/tools/init-runonce
$ cd kolla-ansible/tools
$ ./kolla-ansible -i ../../all-in-one reconfigure

以上が完了すると、変更した設定が適用され、ネットワークなどがいくつか作成されているはずです。
なお、 Horizon のパスワードは以下のようにして表示することができます。

1
$ grep keystone_admin_password /etc/kolla/passwords.yml

以上、簡単にではありますが、参考になりましたら幸いです。

お家で始める仮想化環境 Proxmox VE Cloud-init編

目次

環境

前提として、Proxmoxの基本的な構築が完了している必要があります。
Proxmox環境の構築方法はこちらをご覧ください。

また、Cloud-init Supportを参考にしています。

Cloud-initテンプレートの準備

本記事では、VMで使用するOSとしてUbuntuを使用します。
https://cloud-images.ubuntu.com/でOpenstack向けのCloud-initに対応したイメージが配布されていますので、こちらを利用します。

Proxmoxホストのシェルにログインして、上記イメージをダウンロードします。
今回はUbuntu 20.04 LTSを使用しますので、こちらをダウンロードしました。

1
# wget https://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64.img

続いて、テンプレートで使用するためのVMを作成します。

1
# qm create 9000 --memory 2048 --net0 virtio,bridge=vmbr0

先ほどダウンロードしたイメージをインポートします。
以下の例では対象ディスクをlocal-lvmとしていますが、適時変更してください。(local-zfsなど)

1
# qm importdisk 9000 focal-server-cloudimg-amd64.img local-lvm

インポートしたディスクをscsi0としてVMにアタッチします。
先ほどと同様に、local-lvmvm-9000-disk-0は環境によって異なる場合がありますので、適時変更してください。

1
# qm set 9000 --scsihw virtio-scsi-pci --scsi0 local-lvm:vm-9000-disk-0

続いて、Cloud-initが利用するCDROMドライブを設定します。

1
# qm set 9000 --ide2 local-lvm:cloudinit

先ほどアタッチしたディスクをブートディスクとして設定します。

1
# qm set 9000 --boot c --bootdisk scsi0

Cloud-initはシリアルコンソールを使用するため、その設定をします。

1
# qm set 9000 --serial0 socket --vga serial0

最後に、テンプレートに変換します。

1
# qm template 9000

Cloud-initテンプレートからのデプロイ

先ほど作成したテンプレートを使用して、VMのデプロイを行ってみます。
普段はWebGUIから操作することが多いので、WebGUIから操作することにします。
作成したテンプレートを右クリックするとCloneの項目がありますので選択します。
ダイアログが表示されますので、VM IDNameを入力し、ModeFull Cloneを選択します。

入力出来たら、右下のCloneを押して処理が完了するのを待ちます。

処理が完了したら、クローンしたVMより、Cloud-initメニューを開きます。

必要に応じて、各項目を設定します。

  • User
  • Password
  • DNS domain
  • DNS servers
  • SSH public key
  • IP Config

設定が完了したら、VMを起動します。
起動完了後、しばらく待っているとCloud-initの処理が行われます。
ログが表示されますので、処理が完了するのを待ってログインしてみてください。
設定した内容が反映されているはずです。

複数のVMをデプロイしたい場合も、作成したテンプレートからクローンすることで簡単にデプロイすることが出来ます。

About

インフラエンジニア
主に作業ログ

About Me

Recent Posts