カテゴリー: VyOS

NW機器も公開鍵認証でSSH

oyageng

NW機器もそろそろSSHでアクセスするときは公開鍵認証でやるべきかと思い, 主に触るであろうNW機器の設定をまとめた。

– 鍵準備

SSHで必要となる公開鍵を準備する。

$ ssh-keygen -t rsa -C user01 -f ./rsa_id
$ ls rsa* 
rsa_id.pub  #公開鍵
rsa_id      #秘密鍵

– Cisco IOS

参考： SSH using public key authentication to IOS and big outputs.

1. SSH設定

# conf t
(config)# ip ssh version 2
(config)# line vty 0 4
(config-line)# login local
(config-line)# transport input ssh
(config-line)# hostname R1
(config)# ip domain name test.local
(config)# crypto key gen rsa

2. ユーザと公開鍵紐付け

(config)# ip ssh pubkey-chain
(conf-ssh-pubkey)# username cisco
(conf-ssh-pubkey-user)# key-string
(conf-ssh-pubkey-data)# 
※ 最大で貼り付けられる文字数が256字ということで複数行に分けてペーストする。
(conf-ssh-pubkey-data)# exit
(conf-ssh-pubkey-user)# end
#

テスト 

$ ssh -l cisco -i ./rsa.id 172.16.1.1
R1>


– VyOS

参考：Remote access

1. SSH設定

set service ssh port '22'

2. ユーザと公開鍵の紐付け認証設定

set system login user user1 authentication public-keys '鍵の識別子' key 'public key内の文字列のみ入力'  #ssh-rsa と ユーザは抜く

3. パスワード認証無効化

set service ssh disable-password-authentication

4. ホストバリデーション無効化(オプション)

set service ssh disable-host-validation

テスト

$ ssh -l user1 -i ./rsa_id 172.16.1.2
Welcome to VyOS

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: 
user1@vyos:~$

– Cisco ASA(9.x)

参考：Cisco ASA シリーズ 9.8 CLI コンフィギュレーション ガイド（一般的な操作）

1. SSH設定

ひとまずOutsideから全許可。

(config)# ssh 0.0.0.0 0.0.0.0 outside

2. 公開鍵のフォーマット変更

公開鍵をRFC4716形式で出力。

$ ssh-keygen  -e -m rfc4716 -f ./rsa_id.pub  # この出力結果を控えておく

3. ユーザと公開鍵の紐付け

(config)# aaa authentication ssh console LOCAL
(config)# username user1 attributes
(config-username)# service-type admin
(config-username) ssh authentication pkf

Enter an SSH public key formatted file.
End with the word "quit" on a line by itself:
###  2で変換したPublic Keyを貼り付ける ###
---- BEGIN SSH2 PUBLIC KEY ----
Comment: "2048-bit RSA, converted by ubuntu@HOST from OpenSSH"
～～～
---- END SSH2 PUBLIC KEY ----
quit

テスト

$ ssh -l user1 -i ./rsa_id 172.16.1.3
User user1 logged in to ASA
Logins over the last 1 days: 2.  Last login: 06:54:33 UTC Dec 8 2018 from 192.168.1.10
Failed logins since the last login: 0.
Type help or '?' for a list of available commands.
ASA>

– Cumulus linux

0. NCLU(Network Command Line Utility)インストール

参考：Network Command Line Utility – NCLU
※ ここは省略

1. LinuxのSSH公開鍵認証設定

ホームの.ssh配下のauthorized_keysに公開鍵を登録。

テスト

$ ssh -l cumulus -i ./rsa_id 172.16.1.4

Welcome to Cumulus VX (TM)

Cumulus VX (TM) is a community supported virtual appliance designed for
experiencing, testing and prototyping Cumulus Networks' latest technology.
For any questions or technical support, visit our community site at:
http://community.cumulusnetworks.com

The registered trademark Linux (R) is used pursuant to a sublicense from LMI,
the exclusive licensee of Linus Torvalds, owner of the mark on a world-wide
basis.
Last login: Sat Dec  8 04:45:53 2018 from 192.168.1.10
cumulus@cumulus:~$

– JUNOS

参考：authentication (Login)

1. SSH設定

 set system services ssh protocol-version v2

2. ユーザと公開鍵紐付け 

set system login user admin authentication ssh-rsa "ssh-rsa 省略 user01"

テスト 

$ ssh -l admin -i ./user2_rsa 172.16.1.5
Last login: Thu Dec  6 18:07:53 2018 from 192.168.1.10
--- JUNOS 15.1X49-D140.2 built 2018-05-25 18:23:50 UTC
admin>

[OSPF] DRとBDRの話

oyageng

最近になってOSPFでDRに関する認識が間違えていたことに気がついた。

ということでメモ。
何かというと, DRが落ちるとBDRがDRに昇格されるまでの間, そのネットワーク内ではルートが消失するということ。
正直, BDRがDB保持しているのでネイバーはそれを即時引き継ぐものだと思っていた。
しかし, とある環境で「なーんかメインの経路じゃないルータが落ちてPingロストするなー」なんて思って調べていて, わかったのがこれ。◯十年ネットワークエンジニアやっていたけど, この挙動は全く知なかったし意識したこともなかった。「障害ポイントによっては収束に時間がかかる場合があるよな」くらいの認識でした。
まだまだ知らないことばかり。
OSPF v2のRFC「https://www.ietf.org/rfc/rfc2328.txt」にも書いてありました。
Section 2 of this document discusses the directed graph
        representation of an area.  Router nodes are labelled with their
        Router ID.  Transit network nodes are actually labelled with the
        IP address of their Designated Router.  It follows that when the
        Designated Router changes, it appears as if the network node on
        the graph is replaced by an entirely new node.  This will cause
        the network and all its attached routers to originate new LSAs.
        Until the link-state databases again converge, some temporary
        loss of connectivity may result.  This may result in ICMP
        unreachable messages being sent in response to data traffic.
        For that reason, the Designated Router should change only
        infrequently.  Router Priorities should be configured so that
        the most dependable router on a network eventually becomes
        Designated Router.

改めて検証してみる。
ルータ3台でOSPFを組むシンプルな構成。
PC1からPC2の経路はRouter1～Router2となるようにOSPFのコストを調整する。その上で, Router 1のPriorityを0にしてDR選出から外し, 2のPriorityを50, 3のPriorityを100にする。これで, 通信経路はRouter2をメインとするが, DRはRouter3になる。

正常時のshow ip ospf neとshow ip ro の出力結果。設定どおり。

Router1のネイバー 

IOU1#sh ip ospf ne

Neighbor ID     Pri   State           Dead Time   Address         Interface
192.168.3.2      50   FULL/BDR        00:00:35    192.168.2.2     Ethernet0/0
192.168.3.3     100   FULL/DR         00:00:31    192.168.2.3     Ethernet0/0

IOU1#sh ip route 
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, 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
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       + - replicated route, % - next hop override

Gateway of last resort is not set

      192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.1.0/24 is directly connected, Ethernet0/1
L        192.168.1.1/32 is directly connected, Ethernet0/1
      192.168.2.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.2.0/24 is directly connected, Ethernet0/0
L        192.168.2.1/32 is directly connected, Ethernet0/0
O     192.168.3.0/24 [110/110] via 192.168.2.2, 00:10:35, Ethernet0/0

Router 2のネイバー

IOU2#sh ip ospf ne
Neighbor ID     Pri   State           Dead Time   Address         Interface
192.168.2.1       0   FULL/DROTHER    00:00:33    192.168.2.1     Ethernet0/0
192.168.3.3     100   FULL/DR         00:00:35    192.168.2.3     Ethernet0/0
IOU2#sh ip route 
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, 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
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       + - replicated route, % - next hop override

Gateway of last resort is not set

O     192.168.1.0/24 [110/110] via 192.168.2.1, 00:11:53, Ethernet0/0
      192.168.2.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.2.0/24 is directly connected, Ethernet0/0
L        192.168.2.2/32 is directly connected, Ethernet0/0
      192.168.3.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.3.0/24 is directly connected, Ethernet0/1
L        192.168.3.2/32 is directly connected, Ethernet0/1

Router 3のネイバー

IOU3#sh ip ospf
*Apr 18 07:04:07.804: %SYS-5-CONFIG_I: Configured from console by console
IOU3#sh ip ospf ne

Neighbor ID     Pri   State           Dead Time   Address         Interface
192.168.2.1       0   FULL/DROTHER    00:00:38    192.168.2.1     Ethernet0/0
192.168.3.2      50   FULL/BDR        00:00:34    192.168.2.2     Ethernet0/0
IOU3#sh ip route 
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, 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
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       + - replicated route, % - next hop override

Gateway of last resort is not set

O     192.168.1.0/24 [110/210] via 192.168.2.1, 00:12:06, Ethernet0/0
      192.168.2.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.2.0/24 is directly connected, Ethernet0/0
L        192.168.2.3/32 is directly connected, Ethernet0/0
      192.168.3.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.3.0/24 is directly connected, Ethernet0/1
L        192.168.3.3/32 is directly connected, Ethernet0/1

と, ここまでやってCiscoでは収束が早くて事象が出ない。 たまにPingロスト起きるけどこれOSPF関係ないやつだ。

Debugとってみたらコンマ数秒で切り替わっていたのでCiscoはよく出来ているということがわかりました。

ということでVyOSで検証。

VyOSではBDRがいなくなるとルートアップデートしないというバグらしき挙動をするので構成はちょっと変えた。

VyOS1のステータス。VyOS3がDRでVyOS2がBDR。PC2への宛先はVyOS2に向いている。なお, Helloは5秒。Deadは15秒にした。

vyos1@vyos:~$ sh ip ospf ne

    Neighbor ID Pri State           Dead Time Address         Interface                 RXmtL RqstL DBsmL
10.10.20.2       50 Full/Backup       11.994s 10.10.10.2      eth0:10.10.10.1               0     0     0
10.10.10.3      100 Full/DR           10.991s 10.10.10.3      eth0:10.10.10.1               0     0     0
vyos@vyos:~$ sh ip route 
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
       I - ISIS, B - BGP, > - selected route, * - FIB route

O   10.10.10.0/24 [110/10] is directly connected, eth0, 00:17:16
C>* 10.10.10.0/24 is directly connected, eth0
O>* 10.10.20.0/24 [110/30] via 10.10.10.2, eth0, 00:00:08
O>* 10.10.30.0/24 [110/40] via 10.10.10.2, eth0, 00:00:08
C>* 127.0.0.0/8 is directly connected, lo
O   192.168.1.0/24 [110/10] is directly connected, eth3, 00:17:16
C>* 192.168.1.0/24 is directly connected, eth3
O>* 192.168.2.0/24 [110/40] via 10.10.10.2, eth0, 00:00:08

この時点で, PC1からPC2への経路はVyOS1～VyOS2～VyOS4となっている。VyOS3はバックアップラインとなっている。
ここで, 通信に影響の無いはずのVyOS3(DR)のインタフェースをDisableにする。
VyOS3 

vyos3@vyos# set interfaces ethernet eth0 disable
[edit]
vyos@vyos# commit
[edit]
vyos@vyos#

VyOS1 

vyos1@vyos:~$ sh ip ro
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
       I - ISIS, B - BGP, > - selected route, * - FIB route

C>* 10.10.10.0/24 is directly connected, eth0
C>* 127.0.0.0/8 is directly connected, lo
O   192.168.1.0/24 [110/10] is directly connected, eth3, 00:33:43
C>* 192.168.1.0/24 is directly connected, eth3
vyos@vyos:~$ 
vyos@vyos:~$ sh ip ospf ne

    Neighbor ID Pri State           Dead Time Address         Interface            RXmtL RqstL DBsmL
10.10.20.2       50 Full/DR           14.753s 10.10.10.2      eth0:10.10.10.1          1     0     0

Pingの状態はというと・・・。 

84 bytes from 192.168.2.10 icmp_seq=136 ttl=61 time=4.304 ms
84 bytes from 192.168.2.10 icmp_seq=137 ttl=61 time=5.105 ms
*192.168.1.1 icmp_seq=138 ttl=64 time=0.999 ms (ICMP type:3, code:0, Destination network unreachable)
*192.168.1.1 icmp_seq=139 ttl=64 time=0.832 ms (ICMP type:3, code:0, Destination network unreachable)
*192.168.1.1 icmp_seq=140 ttl=64 time=0.925 ms (ICMP type:3, code:0, Destination network unreachable)
*192.168.1.1 icmp_seq=141 ttl=64 time=1.416 ms (ICMP type:3, code:0, Destination network unreachable)
192.168.2.10 icmp_seq=142 timeout
*192.168.1.1 icmp_seq=143 ttl=64 time=1.184 ms (ICMP type:3, code:0, Destination network unreachable)
192.168.2.10 icmp_seq=144 timeout
*192.168.1.1 icmp_seq=145 ttl=64 time=1.185 ms (ICMP type:3, code:0, Destination network unreachable)
192.168.2.10 icmp_seq=146 timeout
*192.168.1.1 icmp_seq=147 ttl=64 time=1.224 ms (ICMP type:3, code:0, Destination network unreachable)
192.168.2.10 icmp_seq=148 timeout
*192.168.1.1 icmp_seq=149 ttl=64 time=0.886 ms (ICMP type:3, code:0, Destination network unreachable)
192.168.2.10 icmp_seq=150 timeout
192.168.2.10 icmp_seq=151 timeout
192.168.2.10 icmp_seq=152 timeout
84 bytes from 192.168.2.10 icmp_seq=153 ttl=61 time=3.531 ms

16秒ほどパケロスしていた。
VyOSなので, DRが切り替わってBDRが選出されるまでの間が通信断になっていると思われる。

OSPFの仕様ということでしょうがないのかもしれないが, アクティブなルートに関係ないところでDRが落ちると影響出るというのは設計時には要注意ですね。
アップデートの負荷が小さいのであれば, イーサネットでもPoint-to-Multipointにした方が良いのではないかと思いました。

VyOS-1.1.8のqcow2イメージを作る

oyageng

過去, 幾度かやったけど毎度記憶が薄れていくので都度メモを残す。
(2018/4/18修正：MAC周りで不具合でたので修正)

1. isoダウンロード
2. 仮想ディスク作成
3. KVMで起動
4. VyOSインストール
5. sysprep

# isoダウンロード
wget https://downloads.vyos.io/release/1.1.8/vyos-1.1.8-amd64.iso
# 仮想ディスク作成
qemu-img create -f qcow2 ./vyos.qcow2 2G
# 仮想ディスク指定で起動
virt-install --name vyos118 --disk path=./vyos-1.1.8.qcow2 --vcpus=2 --ram 2048 --cdrom=./vyos-1.1.8-amd64.iso --os-type=linux  --graphics vnc,listen=0.0.0.0 --noautoconsole
# VyOSにログイン
virsh console vyos118
# イメージインストール
system image install
# 以降, 「Yes」を連打。終わったらrebootして確認。
# 再起動後, インタフェースにMACの記述があったら削除
vyos@vyos$ conf
vyos@vyos# delete interface ethernet eth0 hw_id **
vyos@vyos# commit
vyos@vyos# save
vyos@vyos# exit

以上。

CiscoルータでのVTI+IKEv2設定(NAT越し)～対VyOS編～

oyageng

ということで，Cisco～VyOS間でも試した。

検証した結果わかったことは以下の通り。

・VyOS1.1.x台ではVTI+IKEv2ではVPNは張れない。
   いや, 張れるんだけど(Phase2まで上がるんだけど) 疎通が取れない。
・EC2のElastic IPで，末尾が0だと（サブネットゼロだと）Cisco側でネットワークアドレスとしてみなされるらくしPhase2で失敗する。（たとえ ip subnet-zero が入っていたとしても）
<追記>
・改めてCisco～VyOS間のトラフィックを確認したら, 正常にトラフィックが流れていないことに気がついた。VyOSからソースIFをVTI指定してのPingでないとトラフィックがトンネルを通らない。Beta版のバグなのかな。
なので, 現時点ではVPNは張れるがまともに使えないという状況。要調査。

VyOSのBeta版はこちらからダウンロードする。
https://downloads.vyos.io/?dir=rolling/current/amd64
今回のバージョンはvyos-999.201802070337-amd64.iso
参考までにアップグレード方法を。
本家にやり方ありますが一応。

$ conf
# set system name-server 8.8.8.8 (Google先生スミマセン）
# commit
# exit
$ sudo su
# wget beta版URL
# exit
$ add system image file
$ show system image
The system currently has the following image(s) installed:

   1: 999.201802070337- (default boot)
   2: 1.1.8 (running image)
$ reboot

これでオッケー。
なお，設定はVTIのときとほぼ同じで至ってシンプル。

set interfaces vti vti1 address '10.10.10.1/30'
～途中省略～
set vpn ipsec esp-group ESP compression 'disable'
set vpn ipsec esp-group ESP lifetime '3600'
set vpn ipsec esp-group ESP mode 'tunnel'
set vpn ipsec esp-group ESP pfs 'dh-group14'
set vpn ipsec esp-group ESP proposal 1 encryption 'aes256'
set vpn ipsec esp-group ESP proposal 1 hash 'sha256'
set vpn ipsec ike-group IKE ikev2-reauth 'no'
set vpn ipsec ike-group IKE key-exchange 'ikev2'
set vpn ipsec ike-group IKE lifetime '3600'
set vpn ipsec ike-group IKE proposal 1 dh-group '14'
set vpn ipsec ike-group IKE proposal 1 encryption 'aes256'
set vpn ipsec ike-group IKE proposal 1 hash 'sha256'
set vpn ipsec ipsec-interfaces interface 'eth0'
set vpn ipsec site-to-site peer B.B.B.B authentication id '10.200.10.20'
set vpn ipsec site-to-site peer B.B.B.B authentication mode 'pre-shared-secret'
set vpn ipsec site-to-site peer B.B.B.B authentication pre-shared-secret 'password'
set vpn ipsec site-to-site peer B.B.B.B authentication remote-id '192.168.1.2'
set vpn ipsec site-to-site peer B.B.B.B connection-type 'initiate'
set vpn ipsec site-to-site peer B.B.B.B default-esp-group 'ESP'
set vpn ipsec site-to-site peer B.B.B.B ike-group 'IKE'
set vpn ipsec site-to-site peer B.B.B.B ikev2-reauth 'inherit'
set vpn ipsec site-to-site peer B.B.B.B local-address '10.200.10.20'
set vpn ipsec site-to-site peer B.B.B.B vti bind 'vti1'
set vpn ipsec site-to-site peer B.B.B.B vti esp-group 'ESP'

これでトンネル間の疎通が取れた。

vyos@VPN1:~$ ping 10.10.10.2 interface vti1 PING 10.10.10.2 (10.10.10.2) from 10.10.10.1 vti1: 56(84) bytes of data. 64 bytes from 10.10.10.2: icmp_seq=1 ttl=255 time=6.92 ms 64 bytes from 10.10.10.2: icmp_seq=2 ttl=255 time=6.86 ms

ちなみにVyOS1.1.8（以前）の場合，show crypto session や show vpn ipsec sa でステータスがアップになるが，疎通が取れない。VyOS側で確認するとトンネルインタフェースがAdmin Down状態となってしまう。（原因不明）

vyos@VPN2:~$ sh int vti vti1
vti1@NONE:  mtu 1500 qdisc noqueue state DOWN group default
    link/ipip 10.200.10.20 peer B.B.B.B
    inet 10.10.20.1/30 scope global vti1
       valid_lft forever preferred_lft forever

    RX:  bytes    packets     errors    dropped    overrun      mcast
             0          0          0          0          0          0
    TX:  bytes    packets     errors    dropped    carrier collisions
             0          0          0          0          0          0

VyOS1.1.x系はIKEv2に対してはlimited supportということで，今回は現時点で最新のベータバージョンを利用した。

【メモ】VyOSのBeta版(999-xxx) とCiscoのGREについて

oyageng

CiscoのGRE Tunnel設定にはkeepalive設定がある。ステートレスなGREだけどこれのおかげでCiscoルータではGREの状態を管理できる。

VyOSとよくGRE over IPSecの設定をやるが, このKeepaliveパケットが1.1.7では機能していたのだが, 今出ているBeta版では「martian source ・・・」とメッセージが出て折り返しパケットが破棄される。

なお, VyOSはGREのKeepaliveは対応していないが, CiscoのKeepaliveの仕組みは対向の機器が対応していなくても機能する仕組みとなっている。
参考) CiscoのGRE Keepalive メカニズム
実際, VyOSの1.1.7ではCisco側で設定しても問題ない。

とはいえ, Beta版のVyOSとCiscoルータでGREトンネルをはるときは, Keep Aliveは設定できないので注意が必要です。

パケットフォーマットを見るとたしかに気持ち悪いっちゃー気持ち悪いんだけど, 今の1.1.7で正常に通信できるんだから, 早いとこ対応してほしいのが本音。

VyOSのイメージ作成

oyageng

OpenStackでVyOSのイメージをESXからのイメージでなんとなく適当にやっていたけど, やっぱキレイなイメージ使いたいと思って今日やっとこさやった。

手順はこう。

  1. KVM上でVyOSのisoイメージから起動する用のCentOSを準備
  2. KVM on OpenStack(KVM)となるので, インスタンスをちょっといじる
  3. KVM用CentOSに必要なパッケージを入れる
  4. VyOSのisoをDL
  5. KVM上で起動
  6. MAC消してeth0をDHCPに設定したり自分色に染める
  7. qcow2をOpenStackにイメージとして登録で完了

実際の流れ。

CentOS7のインスタンスを立ち上げる。
KVM on KVMの設定をここを参考に実施。
必要なパッケージインストール。

sudo yum install -y qemu-kvm libvirt virt-manager libguestfs.x86_64

KVM上でVyOS起動 

qemu-img create -f qcow2 ./vyos.qcow2 2G
virt-install --virt-type kvm --name VyOS --ram 1024 
--cdrom=../vyos-1.1.7-amd64.iso 
--disk ./vyos.qcow2,format=qcow2 
--network default 
--nographics

VyOSをウィザードに従ってインストール。
これはオフィシャルの手順のまま。
インストール完了後再起動。VyOSはCD-ROMデバイスを再起動後に勝手にデタッチするので, この手順はやらなくてOK。

VyOSのテンプレートとなる設定を好みで入れる。(MACは消しておく)

conf
delete interface ethernet eth0 hw-id xx:xx:xx:xx:xx
set interface ethernet eth0 address dhcp

これで出来上がったqcow2をopenstack nodeへscp。
OPENSTACKにイメージとして登録。

openstack image create --file vyos-1.7.7.qcow2 --public --disk-format qcow2 --container-format bare VyOS-1.1.7

あとはこのイメージをもとにインスタンス作成。

openstack server create --flavor m1.small --image VyOS-1.1.7_true --security-group default --nic net-id=172.20.30.0/24  vyos_true

やっとすっきり!

参考までに今回作成したイメージをここに置いておく。

VyOSの登録（別の方法）

oyageng

まえ，ESXでディスクイメージ作ってから登録したけど，ダッシュボードの操作やる方法をメモ。

手順は以下の通り。

  1. VyOSのisoをイメージに登録してインスタンス起動
  2. 1GくらいのCinder ボリュームをアタッチする
  3. install image でそのボリュームにインストールする
  4. Cinderボリュームデタッチ
  5. そのボリュームをイメージへアップロード
これでまぁいける。イメージフォーマットがrawのままだけど，いやならqumeとかで変換かければいいのかなとも思ったけどダメでした。
qcow2じゃないよとエラーが出てこのイメージからは起動できない。
はて・・・。

【失敗】
・イメージダウンロード
> glance image-download –file ./vyos_beta.raw –progress image_ID

・変換
> qemu-img convert -f raw -O qcow2 ./vyos-beta.qcow2 vyos-beta.qcow2
・また登録
> glance image-create –name vyos-beta –visibility public
   –disk-format qcow2 –progress –file ./vyos-beta.qcow2
   –container-format bare
qcow2にしたければ起動中のインスタンスのスナップショットをとって，それをダウンロード。
で，またイメージアップロードすればいける。
ただ，この時，元となるインスタンスのフレーバが起動時の最小要件となるから注意。
そもそもめんどくさい手順だからrawのままでいいや。

てか，qemu-img変換はなんでダメなんだろう。