【メモ】VyattaのHA構成

VyattaのHA構成の備忘録。
(vRouter 5600)
具体的にはconfig-syncで同期する対象を選択する点。
こんな設定になるんだけれども,

set system config-sync remote-router A.A.A.A password 'xxx'
set system config-sync remote-router A.A.A.A sync-map 'SYNC'
set system config-sync remote-router A.A.A.A username 'vyatta'
set system config-sync sync-map SYNC rule 1 action 'include'
set system config-sync sync-map SYNC rule 1 location 'ここ'

この「ここ」としているところで, 同期対象のConfig-treeを指定する。

具体的にはshow configuration comma で表示される内容の「set」以降の, ターゲットとしたい部分を記述すればOK。

ルーティング部分を同期対象としたければ

set system config-sync sync-map SYNC rule 1 location 'protocols'

スタティックルートに限定したければ

set system config-sync sync-map SYNC rule 1 location 'protocols static'

中々便利ね。

クラウドなのに

オンプレのような仮想環境をクラウド上へ作る意義とはなんだろうか。
専用線をわざわざ引き込んで, 今のまんまのアドレス体系を引き継いでVMだけを移行する。
データセンターという枠でパブリッククラウドを使うという点で, 設備コストを自前で持たない利点はあるのだと思う。だがしかし, 現在データセンターもラック単位でお金を払っていて, その環境をまんまクラウドへ出すということにモヤモヤを感じる。

その為に, 今まで通り, 要件定義から設計・構築・試験・切り替え/移行といわゆるSIerへ丸投げしてノウハウも自社に持たず, 結局運営は構築したベンダーやアウトソースされた他社が行う。クラウドの良さが9割減な気がしてならない。

最近, クラウドへ移行するプロジェクトが多いのだけれども, そのたびに何故要件定義から設計まで今まで通り同じことをやっているのかと疑問に感じている。

この方向であっているのか?

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

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で正常に通信できるんだから, 早いとこ対応してほしいのが本音。

【メモ】OSPFにおけるdistribute-listの扱い

今更だけどOSPFでは経路制御は同一エリア内だと受信側で拒否するしかできないのね。
送信でフィルタは掛けられない, 途中のルータで受信拒否してもLSAでアドバタイズされるからその先には伝搬してしまう。このあたり理解できていなかった。

エリアを分けるかプロトコル分けるかなどして再配信じゃないと細かい制御ってできないのね。

簡単な構成で確認した。
R1とR3は普通にOSPFで配信。R2でdistribute-listで192.168系のルートを受信拒否。
R2で拒否すればその先へもルート情報は流れないだろうなーなんて安易に思っていました。OSPFとdistribute-listのこと理解できていませんでした。さーせん。

ルータ3台でOSPFでルーティングさせる

・R1のConfig

interface FastEthernet0/0
ip address 172.16.10.1 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet0/1
ip address 192.168.10.1 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet1/0
ip address 192.168.20.1 255.255.255.0
duplex auto
speed auto
!
router ospf 1
log-adjacency-changes
network 172.16.10.0 0.0.0.255 area 10
network 192.168.10.0 0.0.0.255 area 10
network 192.168.20.0 0.0.0.255 area 10
!

・R2のConfig

interface FastEthernet0/0
ip address 172.16.10.2 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet0/1
ip address 172.16.20.1 255.255.255.0
duplex auto
speed auto
!
router ospf 1
log-adjacency-changes
network 172.16.0.0 0.0.255.255 area 10
distribute-list Deny_OSPF in
!
ip forward-protocol nd
!
!
no ip http server
no ip http secure-server
!
ip access-list standard Deny_OSPF
deny 192.168.0.0 0.0.255.255
permit any

・R3のConfig

interface FastEthernet0/0
ip address 172.16.20.2 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet0/1
ip address 192.168.30.1 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet1/0
ip address 192.168.40.1 255.255.255.0
duplex auto
speed auto
!
router ospf 1
log-adjacency-changes
network 172.16.20.0 0.0.0.255 area 10
network 192.168.30.0 0.0.0.255 area 10
network 192.168.40.0 0.0.0.255 area 10

それぞれのルーティングテーブルを見ると

R1#sh ip route 
Codes: 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

Gateway of last resort is not set

O 192.168.30.0/24 [110/30] via 172.16.10.2, 00:10:34, FastEthernet0/0
C 192.168.10.0/24 is directly connected, FastEthernet0/1
O 192.168.40.0/24 [110/21] via 172.16.10.2, 00:10:34, FastEthernet0/0
172.16.0.0/24 is subnetted, 2 subnets
O 172.16.20.0 [110/20] via 172.16.10.2, 00:13:10, FastEthernet0/0
C 172.16.10.0 is directly connected, FastEthernet0/0
C 192.168.20.0/24 is directly connected, FastEthernet1/0
R2#sh ip route 
Codes: 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

Gateway of last resort is not set

172.16.0.0/24 is subnetted, 2 subnets
C 172.16.20.0 is directly connected, FastEthernet0/1
C 172.16.10.0 is directly connected, FastEthernet0/0
R3#sh ip route 
Codes: 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

Gateway of last resort is not set

C 192.168.30.0/24 is directly connected, FastEthernet0/1
O 192.168.10.0/24 [110/30] via 172.16.20.1, 00:11:22, FastEthernet0/0
C 192.168.40.0/24 is directly connected, FastEthernet1/0
172.16.0.0/24 is subnetted, 2 subnets
C 172.16.20.0 is directly connected, FastEthernet0/0
O 172.16.10.0 [110/20] via 172.16.20.1, 00:11:22, FastEthernet0/0
O 192.168.20.0/24 [110/21] via 172.16.20.1, 00:11:22, FastEthernet0/0

R2だけがルーティングテーブルに192.168系が載っていない。

設計時に経路制御とかしっかり盛り込んでおかないとあとから「やべっ!できねーじゃん」ってなるね。

エレベータの制御にこそAIを活用すべきだ

高層ビルの通勤・昼食・帰宅時のエレベーターの待ち行列の悲惨さは目に余るものがある。
こういうところにこそビッグデータやAIを活用してリアルタイムで流動的に制御すべきだと思うのだが, 未だ実装されたというのを聞かない。

このあたりに誰か神の一手をうってほしいところ(自分にはできないから人頼み)。

OSPFのデフォルトルート配信設定

OSPFでデフォルトルートを配信するときにややハマったのでメモ。

Ciscoでは「default-information originate」コマンドで設定する。

OSPFではデフォルトルートは配信されないので, このコマンドで配信のON/OFFを制御する。また, オプションでallwaysをつけない限りはそのルータにデフォルトルート(0.0.0.0/0)のルートを持っていない限りは配信されない。

大体スタティックルートでデフォルトルートの設定を入れるのだけれど, スタティックの向け先がデフォルトルートを配信するOSPFのエリアの外か内かでメトリック値の扱いが異なる。これに気が付かなかったので, とある案件の検証でちょっとハマった。

以下の構成でR2からデフォルトルートを配信することを考える。

R2のデフォルトルートを192.168.50.254とOSPFのエリアに所属していないインタフェースに設定し, それをArea0と100に配信する。
R1とR3のshow ip routeの結果はこうなる。

R1#sh ip route 
Codes: 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

Gateway of last resort is 192.168.20.2 to network 0.0.0.0

C 192.168.10.0/24 is directly connected, FastEthernet1/0
C 192.168.20.0/24 is directly connected, FastEthernet0/0
10.0.0.0/32 is subnetted, 1 subnets
C 10.1.1.1 is directly connected, Loopback0
O*E2 0.0.0.0/0 [110/1] via 192.168.20.2, 00:00:11, FastEthernet0/0

R3#sh ip route 
Codes: 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

Gateway of last resort is 192.168.30.2 to network 0.0.0.0

C 192.168.30.0/24 is directly connected, FastEthernet0/1
C 192.168.40.0/24 is directly connected, FastEthernet0/0
10.0.0.0/32 is subnetted, 1 subnets
C 10.3.3.3 is directly connected, Loopback0
O*E2 0.0.0.0/0 [110/1] via 192.168.30.2, 00:20:37, FastEthernet0/1

この場合メトリックは「1」。
ここで, R2の192.168.50.0/24側のインタフェースをArea0に所属させてみる。
また, わかりやすいようにそのインタフェースのコスト値を100に変える。
図にするとこんな感じ。

R1#sh ip route 
Codes: 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

Gateway of last resort is 192.168.20.2 to network 0.0.0.0

C 192.168.10.0/24 is directly connected, FastEthernet1/0
C 192.168.20.0/24 is directly connected, FastEthernet0/0
10.0.0.0/32 is subnetted, 1 subnets
C 10.1.1.1 is directly connected, Loopback0
O 192.168.50.0/24 [110/110] via 192.168.20.2, 00:00:13, FastEthernet0/0
O*E2 0.0.0.0/0 [110/100] via 192.168.20.2, 00:00:13, FastEthernet0/0

R3#sh ip route 
Codes: 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

Gateway of last resort is 192.168.30.2 to network 0.0.0.0

C 192.168.30.0/24 is directly connected, FastEthernet0/1
C 192.168.40.0/24 is directly connected, FastEthernet0/0
10.0.0.0/32 is subnetted, 1 subnets
C 10.3.3.3 is directly connected, Loopback0
O*E2 0.0.0.0/0 [110/1] via 192.168.30.2, 00:31:07, FastEthernet0/1

R1はメトリックが100。R3はメトリックが1。

結果から見ると, 同じエリア内のルート情報だと該当するインタフェースのコスト値になり, エリア外だとメトリックは1になるということがわかった。

まぁ, 基本的に後者の構成が一般的だと思うけど, こんな挙動するってのは知らなかった。

検証って大事ね。

リュック

もう年なのか。最近腰と肩がコリにコッて痛い。
整骨院でショルダーとかやめたほうがいいよと言われたのでリュックへ転向しました。

PCは必須なのでラップトップ前提で作られているやつを選択。

やっぱりいいわ。ただし電車で座るときはかさばるなー。


【OpenStack】Magnum入れたらHorizonの表示がおかしくなった

ここに習ってコンテナのコンポーネント”Magnum”をインストールしたらHorizonの表示がおかしくなった。

イメージが表示されないし, インスタンスの新規作成も反応無し。

一体なんなんだ。

CLIでは普通に動くからHorizonなんだろうな。

なーんて思って色々試してみたら, アップデート手順で復活した。DBあたりの不整合かしらね。

使っていないから無視していたけど, ceilometerのComputeのERRORログは吐き出し続けている。

(4/14追記)
うまくいったかなーなんて思っていたんだけど, openstack-statusコマンドの表示がおかしい。全部”disabled on boot”で”inactive”になっていた・・・。いつのタイミングだ???
そしてインスタンスにもアクセスできない。

あちゃーこりゃ逝ったなーなんて思って, どうにか復旧させる。もう手っ取り早く(かなり強引に)復旧させる。レッツ上書きインストール。

packstack --answer-file=./ans.txt

残っていたanswerfileをつかって再度実行。
無事復活しました。
ファイルサーバとしてつかっていたインスタンスのデータもちゃんと(?)残っていたし, Cinder Bootだったのでデータはきっちり復旧できました。やっぱCinder Bootはいいね。
Magnumを追加したけどopenstack-statusの結果には載ってこない。
中身見るとMagnum分追加しないとダメみたいね。

また今度。

【OpenStack】Ocataでインスタンス作成エラー

AWSのインスタンスにOcataをPackstackで入れて見たんだけど, インスタンス作成時にエラーが出る。

 ERROR nova.conductor.manager [req-c532e549-5c8c-44b9-a1f6-728b6e8dccdf - - - - -] No host-to-cell mapping found for selected host packstack. Setup is incomplete. 

バグという情報もあり, Work Arroundに習って以下コマンドを実行することで回避出来た。

# nova-manage cell_v2 discover_hosts
# nova-manage cell_v2 list_cells
+---------+--------------------------------------+
| Name | UUID |
+---------+--------------------------------------+
| cell0 | 00000000-0000-0000-0000-000000000000 |
| default | cd0248ed-7350-48d6-9239-236083c4d401 |
+---------+--------------------------------------+

新たにCellが出来たっぽい。
が, インスタンスを作ってみると

nternal error: process exited while connecting to monitor

という新たなエラーで起動せず。んー。
なんか足りない。