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

ということで,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ということで,今回は現時点で最新のベータバージョンを利用した。

Logstashのマルチパイプライン設定

Filebeatsからの入力とローカルのファイルを読み込んでの処理を分けるためにマルチパイプラインの設定をする。

blog-pipeline-log.jpg
公式サイト(Introducing Multiple Pipelines in Logstash)より

https://www.elastic.co/blog/logstash-multiple-pipelines
https://www.elastic.co/guide/en/logstash/master/multiple-pipelines.html

以前作成したFilebeatsの設定ファイルを転用して, CSVファイル用の設定ファイルを作成して, それぞれ異なるパイプラインで処理する設定を行う。
CSVファイルで使うのは長年エクセルで管理してグラフ化していた光熱費のデータを使う(笑)。

手順
1. /etc/logstash/pipelines.yml 作成
2. filebeatsのConfig(既存転用)とCSV用のConfigを作成
3. index Pattern作成
4. グラフ作成

1. pipelines.yml 作成

pipelines.ymlには各パイプラインの設定を記述する。ここに記述されなかった設定はlogstash.ymlを参照してそれに従うとのこと。
・pipelines.yml には個別設定
・logstash.yml には共通設定
という住み分けらしい。(多分)

vi /etc/logstash/pipelines.yml

# For beats
- pipeline.id: filebeat
pipeline.workers: 2
pipeline.batch.size: 125
pipeline.batch.delay: 5
config.reload.automatic: true
config.reload.interval: 5s
path.config: "/etc/logstash/pipeconf.d/beats.conf"

# For csv
- pipeline.id: csvfile
pipeline.workers: 1
pipeline.batch.size: 125
pipeline.batch.delay: 5
config.reload.automatic: true
config.reload.interval: 5s
path.config: "/etc/logstash/pipeconf.d/csv.conf"

これに伴って /etc/logstash/logstash.yml を以下のように変更した。
vi /etc/logstash/logstash.yml

path.data: /var/lib/logstash
log.level: info
path.logs: /var/log/logstash

最低限のものに絞ったので設定値はpipelines.ymlへ持っていった。

2. csv用設定ファイル作成

csvファイルは次のような要素になっている。
「YYYYM,電気代,水道代,ガス代」
実際のデータはこんな感じ。
「201712,9308,11765,10018」

logstashはlogstashユーザで起動するので, データの配置場所は参照できるところへ配置する。(私はユーザのホームにおいてread権限あるから大丈夫だろうと思っていたらハマった。)
各パイプライン用の設定ファイルは /etc/logstash に pipeconf.d というディレクトリを新たに作成してそこに配置した。
vi /etc/logstash/pipeconf.d/csv.conf

input {
file {
path => "/tmp/logstash/kounetsu.csv"
start_position => "beginning"
}
}

filter {
csv {
columns => ["date", "elec", "water", "gus"]
skip_empty_columns => true
convert => {
"elec" => "integer"
"water" => "integer"
"gus" => "integer"
}
}
date {
match => [ "date", "yyyyM"]
}
}

output {
elasticsearch {
hosts => [ "http://172.16.10.50:9200" ]
index => "kounetsu"
}
}

3. index pattern作成

elasticsearchへ”kounetsu”というインデックスで渡しているので kibana でこれを指定してインデックスパターンを作成する。

4. グラフ作成

ここはお好みでとなりますが。。。

完成。


できるまで結構ハマっていたのでこれをポチった。 無駄にはならないよね・・・。

CiscoのAPPFWのログをfilebeat→logstash→elasticsearchからのkibanaでMap表示させる

昨年からダラダラと座学に取り組んできたものが年を超えてようやく形になったのでメモ。
もともとSplunkに変わる大体手段として何かないかなーと探していたところ, ELKでお試しという試みだったけど, 諸々の事情(後でやるやる詐欺)でこんなにも時間がかかった。

全体像

1. CiscoからSyslogを飛ばし, Rsyslogで受け取る。
2. Filebeatで該当ファイルをLogstashへ送る。
3. LogstashでパースしてElasticsearchへ送る。
4. Kibanaで表示。

全体像

オールインワン構成とした。

FilebeatからElasticsearchへ直接という方法もあるようだけど, インデックス作成周りでよくわからないことに陥りそうだから, Webでよく見るfluentd+logstash構成に習った。
なお, 有償のX-packは使わない。

一連の流れ

1. インスタンス作成, 事前準備
2. 各種インストール・設定
3. 詳細設定
4. 動作確認

1. インスタンス作成, 事前準備

はじめにELKを立てるインスタンスを準備する。
インデックス作成にJavaを使うということで, このJavaがリソースを結構持っていくのでリソースは多めに割り当てた。CentOS7でvcpu: 4 mem: 12GB disk: 60GB。
$ openstack flavor create --ram 12288 --disk 60 --vcpus 4 elastic-flavor
$ openstack server create --flavor elastic-flavor --image CentOS7 --key-name elastic-key elastic

インスタンスができたらrsyslogの設定。(※florting IPの設定は省略)
<Syslog方針>
– Cisco側はfacility local3でサーバへ渡す。
– Local3で受信したログは /var/log/rsyslog/ 配下に”hostname.log”で作成させる。

@Cisco

logging facility local3

vi /etc/rsyslog.conf

$template DynFile,"/var/log/rsyslog/%HOSTNAME%.log
local3.* -?DynFile

*.info;mail.none;authpriv.none;cron.none;local3.none /var/log/messages

続いてJDKのインストール。

# yum install java-1.8.0-openjdk.x86_64 java-1.8.0-openjdk-debug.x86_64 java-1.8.0-openjdk-devel.x86_64

オールインワン構成だけど, IP指定で構成するのとCiscoの名前解決必要なのでhostsファイルを編集する。
/etc/hosts 編集

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6

172.16.10.50 elastic
192.168.10.1 local-c841m

2. 各種インストール・設定

オフィシャルのオンラインマニュアルを参考にインストールできる。
Elasticsearch手順
https://www.elastic.co/guide/en/elasticsearch/reference/6.1/rpm.html
Kibana手順
https://www.elastic.co/guide/en/kibana/6.1/rpm.html
Logstash手順
https://www.elastic.co/guide/en/logstash/6.1/installing-logstash.html
Filebeat手順
https://www.elastic.co/guide/en/beats/filebeat/6.1/filebeat-installation.html

2.1 リポジトリ登録

rpm --import https://artifacts.elastic.co/GPG-KEY-elasticsearch

/etc/yum.repos.d/elasticsearch.repo 作成

[elasticsearch-6.x]
name=Elasticsearch repository for 6.x packages
baseurl=https://artifacts.elastic.co/packages/6.x/yum
gpgcheck=1
gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch
enabled=1
autorefresh=1
type=rpm-md


2.2 インストール

yum install elasticsearch kibana logstash
wget https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-6.1.1-x86_64.rpm
yum install ./filebeat-6.1.1-x86_64.rpm

2.3 Elasticsearch設定
とりあえず動作確認までこぎつけるため, 基本的な設定のみを実施。(Cluster.nameやnetwork.hostは気分で変えた)
/etc/elasticsearch/elasticsearch.yml

cluster.name: elastichome
node.name: elastic
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch
network.host: 0.0.0.0
http.port: 9200

起動設定。

systemctl enable elasticsearch
systemctl start elasticsearch

2.4 Logstash設定
filebeat用の設定ファイルは後にして一通り設定を済ます。
(ログ読み込まないなー等うまくいかない時はここで自動読み込み設定ONにしてlogレベルを適宜変更するとよい。)

path.data: /var/lib/logstash
path.config: /etc/logstash/conf.d/*.conf
config.reload.automatic: true
config.reload.interval: 5s
log.level: info
path.logs: /var/log/logstash

起動設定。

systemctl enable logstash
systemctl start logstash

2.5 Kibana設定
ここもほぼ基本的な設定のみ。
/etc/kibana/kibana.yml

server.port: 5601
server.host: "172.16.10.50"
server.name: "elastic"
elasticsearch.url: "http://172.16.10.50:9200"
elasticsearch.username: "kibana"
elasticsearch.password: "kibanapassword"
logging.dest: /var/log/kibana/kibana.log

起動設定。

systemctl enable kibana
systemctl start kibana

2.6 Filebeat設定
監視対象のログ指定と出力先をlogstashにする設定を入れる。
logstashでのフィルタ条件で利用するtagの設定も入れる。

filebeat.prospectors:
- type: log
paths:
- /var/log/rsyslog/*.log
fields:
log_type : ciscolog
fields_under_root: true
filebeat.config.modules:
path: ${path.config}/modules.d/*.yml
reload.enabled: true
reload.period: 10s
index.number_of_shards: 3
index.codec: best_compression
_source.enabled: false
setup.dashboards.enabled: false
output.logstash:
hosts: ["172.16.10.50:5044"]
index: "filebeat"
username: "logstash_internal"
password: "logstashpassword"
logging.level: debug

起動設定。

systemctl enable filebeat
systemctl start filebeat

3 フィルタリングとかインデックスとか設定

3.1 設定ファイル作成
Filebeat用のlogstash設定ファイルを /etc/logstash/conf.d/beat.conf として作成する。

input {
beats {
port => 5044
}
}
filter {
if [log_type] == "ciscolog" {
grok {
match => {
"message" => "%{SYSLOGTIMESTAMP:timestamp} %{HOSTNAME:log_host} %{NUMBER:unixtimestamp}: %{SYSLOGTIMESTAMP:ciscotimestamp} %{WORD:timezone}: %{GREEDYDATA:facility}: %{DATA:application} %{GREEDYDATA:msg_1} - %{WORD:protocol} %{WORD:msg_2} %{IP:src_ip}:%{NUMBER:src_port} %{IP:dst_ip}:%{NUMBER:dst_port} %{GREEDYDATA:msg_3}"
}
}
geoip {
source => "dst_ip"
}
mutate {
convert => {
"src_port" => "integer"
"dst_port" => "integer"
}
}
}
}
output {
elasticsearch {
hosts => [ "http://172.16.10.50:9200" ]
index => "myfilebeat-%{+YYYY.MM}"
}
}

※補足説明
7行目:   if [log_type] == “ciscolog” {

filebeatの設定で /var/log/rsyslog/*.log に対してciscologというlog_typeというフィールドを付与したので, ここで条件マッチングさせている。
他にもログを捕捉する場合はこのあたりで適宜フールドを追加して処理を変える目的。
ここでは省略しているけど, audit.log等も対象としていたのでこの設定入れた。

10行目:  “message” => “%{SYSLOGTIMESTAMP:timestamp} %{HOSTNAME:log_host} %{NUMBER:unixtimestamp}: %{SYSLOGTIMESTAMP:ciscotimestamp} %{WORD:timezone}: %{GREEDYDATA:facility}: %{DATA:application} %{GREEDYDATA:msg_1} – %{WORD:protocol} %{WORD:msg_2} %{IP:src_ip}:%{NUMBER:src_port} %{IP:dst_ip}:%{NUMBER:dst_port} %{GREEDYDATA:msg_3}”
CiscoルータのゾーンベースのFWログフォーマットを見ながらパーシングしたい箇所を切り出せるように記述する。
grokフィルタが良く分からないときはここ(Grok Debugger)を参考にトライアンドエラーでがんばる。GREEDYDATA(*と同義)を使って少しずつ細分化していくのがおすすめ。
14行目:  source => “dst_ip”
geoipフィルタで対象となるIPアドレスを指定する。
今回はログから通信先がどこか地図にマッピングすることを考えているので, ログ内のdst_ip(通信先IPアドレス)を指定した。
16行~21行: mutateの行
ここは実際にパースしたらなぜかtypeがtextになっていたので入れた。気になったのでtypeをコンバートする設定を追加。テンプレートあたりをしっかり理解すればこんなことしなくてもよいのかもしれない。
27行目:  index => “myfilebeat-%{+YYYY.MM}”
elasitcsearchへ出力する際にインデックスを追加する。

3.2 インデックス作成
インデックスはKibanaにログインし, 「Management → Index Patterns」でインデックスを作成する。

インデックス作成画面

これでいけるか!と思ったけど実際にマップ作成をやってみると, “kibanaのGeo Coordinatesマップで参照されるgeo_pointとなるタイプが無い”となって作成できない。

デフォルトのfilebeatのテンプレートを元に, 新たに作成する。
<手順>
Kibana上のDevToolsに「GET _template/filebeat-*」と入れ, 出力結果を編集してPUTする。
1. 元となるテンプレートを元に新しいテンプレートを作成する。

{
"filebeat": {
"order": 1,
"index_patterns": [
"myfilebeat-*"
],

~中略~
}
}
},
"geoip": {
"properties": {
"continent_name": {
"type": "keyword",
"ignore_above": 1024
},
"country_iso_code": {
"type": "keyword",
"ignore_above": 1024
},
"location": {
"type": "geo_point"
},
"region_name": {
"type": "keyword",
"ignore_above": 1024
},
"city_name": {
"type": "keyword",
"ignore_above": 1024
}
}
}

}
}
},
"aliases": {}
}
}

2. テンプレートをPUTする。
1の内容をDevToolsでPUTする。

PUT _template/filebeat
※ ここに1の内容を入れる

4. 確認

ここまで来ればKibana上で次のように表示されるはず。

インデックスが作成されている
geoip.locationというフィールドがgeo_pointタイプで作成されている

Map作成は

  1. Visualize → 「+」新規作成 → MapsのCoordinate Map
  2. myfilebeat-* を選択
  3. Bucketsで「GeoCoodinate」を選択
  4. Aggregationで「Geohash」を選択
  5. Fieldで「geoip.location」を選択

で完了。

次のようなMapが表示される。

Map表示。

Splunkのほうが大分楽にMap作成はできるけどSPLを覚えるのと比較すると, まぁどっこいどっこいかな。

とりあえずの動作確認ができた。
これからは細かく分析・その他データの可視化を目標として検証すすめる。

【メモ】CentOSにVirtualboxをインストールする

ESXにvCenterを入れたいのだけれども、今あるESXではメモリが足りないという事情があり、OpenStack上にCentOS7を立ててその中にVirtualBoxをインストールして、さらにその中にESXを動かそうという試み。

まぁ、ESXi over VirtualBox over KVM というまともに動くとは思えないことをやろうとしているのだけれども、手持ちの資源でやむなく(そしてとりあえず)やるだけやってみる。
その準備として、CentOS7にVirtualBoxを入れる。
オフィシャルに入れ方があるのでそのままやる。
<手順>
  1. virtualboxのリポジトリ登録
  2. kernel-devel インストール
  3. gcc / make インストール
  4. virtualbox インストール
  5. KERN_DIR の環境変数を設定
  6. OS再起動
  7. kernelのリビルド
こんな流れ。
– 1.
[virtualbox]
name=Oracle Linux / RHEL / CentOS-$releasever / $basearch - VirtualBox
baseurl=http://download.virtualbox.org/virtualbox/rpm/el/$releasever/$basearch
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://www.virtualbox.org/download/oracle_vbox.asc
– 2.
yum install kernel-devel-3.10.0-327.28.3.el7.x86_64
yum update

– 3.

yum install gcc make

– 4.

yum install VirtualBox-5.1.x86_64

– 5.

export KERN_DIR=/usr/src/kernels/3.10.0-514.26.2.el7.x86_64

– 6.

reboot

– 7.

/usr/lib/virtualbox/vboxdrv.sh setup

以上。

あとはvirtualboxコマンドで無事起動。

さて, ここからが問題だ・・・。

【メモ】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'

中々便利ね。

【メモ】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系が載っていない。

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

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になるということがわかった。

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

検証って大事ね。

【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分追加しないとダメみたいね。

また今度。