designetwork

ネットワークを軸としたIT技術メモ

Kibana6.xのReporting CSV Export機能を試してみる

f:id:daichi703n:20170717192510p:plain

Kibanaで長らく要望されている機能である、Discoverタブでの検索結果をCSVエクスポートする機能が、Version.6からついに実装される。GAリリースが待ち遠しく、Alpha版を試してみた。

github.com

Kibana 6.0.0-alpha2 is released | Elastic

CSV export

Did someone say CSV export? We’re pretty sure we heard someone ask for CSV export. Just to be safe, we built CSV export.

Search for the documents you want to export in the Discover app, and then export matching documents as a CSV file via the reporting menu. CSV export comes with X-Pack basic, which is our free license.

ElasticスタックVer 6.0.0を試す

ElasticスタックVer 6.0.0は2017/7月現在alpha2版がリリースされている。本記事時点でalphaリリースのため画面等は変更になる可能性がありますがご了承ください。

CSVエクスポート機能はX-Pack Reportingのうちの無償範囲で提供される。

検証用にDockerコンテナでKibana + Elasticsearchを構築する。docker-compose.ymlファイルはこちらの通り。設定は環境変数で与え、X-Pack Securityは無効化している。(インストールはElasticのリポジトリ追加によりYumでも可能)

$ sudo vi ./docker-compose.yml
version: '2.1'
services:
  elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:6.0.0-alpha2
    container_name: els_60
    environment:
      - bootstrap.memory_lock=true
      - xpack.security.enabled=false
      - xpack.monitoring.history.duration=1d
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
      - "network.host=0.0.0.0"
      - "http.host=0.0.0.0"
    ulimits:
      memlock:
        soft: -1
        hard: -1
      nofile:
        soft: 65536
        hard: 65536
    mem_limit: 1g
    memswap_limit: 1g
    volumes:
      - es_data1:/usr/share/elasticsearch/data
    ports:
      - 9200:9200
    networks:
      - kibana_net
  kibana:
    image: docker.elastic.co/kibana/kibana:6.0.0-alpha2
    container_name: kibana_60
    environment:
      SERVER_NAME: "kibana.designet.local"
      ELASTICSEARCH_URL: "http://els_60:9200"
      XPACK_MONITORING_ELASTICSEARCH_URL: "http://els_60:9200"
      XPACK_SECURITY_ENABLED: "false"
    ports:
     - 5606:5601
    networks:
      - kibana_net
    depends_on:
      - elasticsearch
    links:
      - elasticsearch
volumes:
  es_data1:
    driver: local
networks:
  kibana_net:

CSV Export動作確認

起動したElasticsearch, Kibanaでindex取り込み設定をすると、DiscoverタブからRepoerting > Generate CSVでSave済みの検索をエクスポートできる。

f:id:daichi703n:20170717185817p:plain

生成されたCSVファイルをダウンロードすると、以下の通りCSV形式のファイルを得られる。

timestamp,"source_node.ip","source_node.name","cluster_state.status","_type"
"2017-07-17T09:54:16.189Z","172.19.0.2",SstbTYy,,"index_stats"
"2017-07-17T09:54:16.189Z","172.19.0.2",SstbTYy,,"index_stats"

これまではPDFでのエクスポートだったが、CSVでのエクスポートが可能になり、外部連携が容易になる。

なお、Discoverタブで単純にindexを開いた状態ではReport機能は使用することができず、以下のメッセージが表示される。

Please save your work before generating a report.

そのため、カラムの選択をしてSaveしてからReporting機能を使用する。

Virtual Memoryのエラー対応

DockerでElasticsearchを動かす場合にはこちらの通りVirtual Memoryの拡張が必要。

www.elastic.co

els_60           | ERROR: [1] bootstrap checks failed
els_60           | [1]: max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]

まとめ - Kibana6.xのReporting CSV Export機能を試してみる

Kibana6.xのX-Pack Reportingに含まれるCSV Export機能を試してみた。期待通りの動作が可能だったため、これまでの独自パッチ適用は不要で、X-Packを適用すればよくなる。X-Packではあるが無償範囲で使用可能であるため、ハードルなく使用できる。

Kibana5にパッチ適用しDiscoverタブからCSVエクスポートする

f:id:daichi703n:20170717024455p:plain

こちらの記事でKibanaのDiscoverタブからExportできる機能追加版をビルドしたが、正直かなり手間がかかった。

designetwork.hatenablog.com

時間が経ち、同様機能をパッチとして作成した方がいるようなので、使ってみた。

github.com

Kibana Exportパッチの使い方

作成者から紹介されている使用方法はこちらの通り。内容を確認したところ、パッチはsrcディレクトリの内容となっていた。それを置き換えた上でoptimizeを削除し、起動時に再作成する。(自動的に)

cd ${KIBANA_HOME}
tar -zcvf optimize-backup.tar.gz
rm -rf optimize
wget https://github.com/fbaligand/kibana/releases/download/v5.4.0-csv-export/csv-export-patch.tar.gz
tar -zxvf csv-export-patch.tar.gz
rm -f csv-export-patch.tar.gz
bin/kibana

Dockerでデプロイする

Kibanaは既に動かしている環境があり、競合を避けるために、Dockerコンテナとしてパッチ適用版のKibanaをデプロイする。

Docker-Composeで以下の通りデプロイできるようにした。なお、Elasticseach関連のパラメータは環境変数から読み込むようにはしておらず、configディレクトリをマウントする形にしている。

github.com

$ tree
.
├── README.md
├── docker-compose.yml
└── kibana_5.3
    ├── Dockerfile
    └── config
        └── etc
            ├── kibana.log
            └── kibana.yml

ベースイメージはシンプルにCentOSから作成する。ElasticオフィシャルはX-Packインストールなど、多機能で起動が重いと感じている。なお、既存のElasticsearchがVer.5.3.0のため、Kibanaもバージョンを揃えている。パッチは各バージョン向けにリリースされているので、該当のバージョンを使用する。

$ sudo vi ./kibana_5.3/Dockerfile
FROM centos

RUN rpm --import https://artifacts.elastic.co/GPG-KEY-elasticsearch
RUN echo $'[kibana-5.x]\n\
name=Kibana repository for 5.x packages\n\
baseurl=https://artifacts.elastic.co/packages/5.x/yum\n\
gpgcheck=1\n\
gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch\n\
enabled=1\n\
autorefresh=1\n\
type=rpm-md' > /etc/yum.repos.d/elastic.repo

RUN yum install -y kibana-5.3.0-1

WORKDIR /usr/share/kibana
RUN curl -OL https://github.com/fbaligand/kibana/releases/download/v5.3.0-csv-export/csv-export-patch.tar.gz
RUN tar -xzvf ./csv-export-patch.tar.gz
RUN chown kibana:kibana -R ./src
RUN rm -rf ./optimize/*

CMD /usr/share/kibana/bin/kibana

docker-composeファイルはこのようにかなりシンプル。

$ sudo vi ./docker-compose.yml
version: '2.1'
services:
  kibana:
    build: kibana_5.3
    container_name: kibana_5.3_export
    ports:
     - 5605:5601
    networks:
      - kibana_net
    volumes:
      - ./kibana_5.3/config/etc/:/etc/kibana/
networks:
  kibana_net:

設定ファイルは個別に作成して、コンテナ起動時にマウントする。logging設定はマウントディレクトリをひとつにするために同一ディレクトリに出力。

$ sudo vi ./kibana_5.3/config/etc/kibana.yml
server.port: 5601
server.host: "0.0.0.0"
server.name: "kibana.designet.local"
elasticsearch.url: "http://192.168.1.81:9200"
logging.dest: /etc/kibana/kibana.log

起動時に若干時間を要する

起動時にはoptimizeの処理で数分の時間を要する。私の環境では下記の通り90秒程度でKibanaが上がってきた。(logをSTDOUTしている状態)

$ sudo docker-compose up
Starting kibana_5.3_export ...
Starting kibana_5.3_export ... done
Attaching to kibana_5.3_export
kibana_5.3_export | {"type":"log","@timestamp":"2017-07-16T17:17:12Z","tags":["info","optimize"],"pid":1,"message":"Optimizing and caching bundles for kibana, timelion and status_page. This may take a few minutes"}
kibana_5.3_export | {"type":"log","@timestamp":"2017-07-16T17:18:43Z","tags":["info","optimize"],"pid":1,"message":"Optimization of bundles for kibana, timelion and status_page complete in 90.28 seconds"}
kibana_5.3_export | {"type":"log","@timestamp":"2017-07-16T17:18:43Z","tags":["status","plugin:kibana@5.3.0","info"],"pid":1,"state":"green","message":"Status changed from uninitialized to green - Ready","prevState":"uninitialized","prevMsg":"uninitialized"}

エクスポート動作概要

パッチ適用版だと、このようにExportが可能になっている。なお、Discoverタブの中でもカラム選択してSaveしOpenすることでExportが可能となる。そうしないと_sourceのみが表示されてしまう。

f:id:daichi703n:20170717004210p:plain

ここから以下のようにCSVでのエクスポートができる。

"@timestamp",action,"if_src","if_dst",proto,direction,"ip_src","ip_local","port_src",nat,"ip_dst","port_local","port_dst"
"July 17th 2017, 00:40:00.000",Built,outside,management,tcp,outbound,"172.217.27.68"," - ",443," - ","192.168.1.104",,"53,574"
"July 17th 2017, 00:40:00.000",Built,management,outside,tcp," - ","192.168.1.104"," - ","53,574",dynamic,"222.159.141.103",,"53,574"
"July 17th 2017, 00:40:00.000",Built,management,outside,tcp," - ","192.168.1.104"," - ","53,575",dynamic,"222.159.141.103",,"53,575"

まとめ - Kibana5にパッチ適用しDiscoverタブからCSVエクスポートする

Kibana5でパッチを適用しDiscoverタブから検索結果をCSVエクスポートできるようにした。シンプルな操作でエクスポート機能を追加できるため、非常に有用なパッチと評価している。

iTermのVimスクロールを設定からON/OFFする(.vimrc未使用)

f:id:daichi703n:20170715204230p:plain

MacBookのターミナルとして人気のあるiTerm2でVimスクリーンに切り替わったときのスクロール設定を変更する。

.vimrcに以下の設定をするという記事をよく見かけるが、私の環境ではうまく動作しなかった。

vi ~/.vimrc

set mouse=a

今回は.vimrcではなく、iTermの設定(Preferences)から動作を切り替える方法を記載する。

環境情報

  • MacOS Sierra 10.12.5(16F73)
  • iTerm2 Build 3.0.15

f:id:daichi703n:20170715195324p:plain

設定(Preferences)からスクロールをON/OFFする

iTerm2 > Preferences > Advanced

Mouse > Scroll wheel sends arrow keys in alternate screen mode.

検索ウィンドウからscrollで簡単にアクセスできる。

f:id:daichi703n:20170715195442p:plain

Scroll wheel sends arrow keys in alternate screen mode.の設定により、スクロールの動作が以下のように変わる。

YesVimウィンドウ内でスクロール
No: Vimに関係なくiTermウィンドウがスクロール

私の場合、これまでのコンソールログからVimで貼り付けたいケースが多いので、設定はNoにしてiTermウィンドウがスクロールするようにしている。

まとめ - iTermのVimスクロールを設定からON/OFFする(.vimrc未使用)

MacBookでiTerm2を使う中で、.vimrcでなはくPreferencesのScroll wheel sends arrow keys in alternate screen mode.からVimウィンドウ内でのスクロール設定を変更できる。

FilebeatでNon-Zero Metricsのログを出さないようにする

f:id:daichi703n:20170709195147p:plain

こちらの記事に記載した通り、Beats(Filebeat)でログをシンプルにFluentdを送っている。

designetwork.hatenablog.com

その中で次のようなログが多発していることに気付いた。BeatsのMetrics監視の仕組みのようだが、安定稼働している状態では、常時発生するログは削減して異常ログのみを検知したい。

$ sudo tail -f /var/log/filebeat/filebeat
2017-07-09T13:36:09+09:00 INFO Non-zero metrics in the last 30s: filebeat.harvester.open_files=1 filebeat.harvester.running=1 filebeat.harvester.started=1 libbeat.logstash.call_count.PublishEvents=1 libbeat.logstash.publish.read_bytes=96 libbeat.logstash.publish.write_bytes=2224 libbeat.logstash.published_and_acked_events=16 libbeat.publisher.published_events=16 publish.events=17 registrar.states.update=17 registrar.writes=1
2017-07-09T13:36:39+09:00 INFO No non-zero metrics in the last 30s
2017-07-09T13:37:09+09:00 INFO No non-zero metrics in the last 30s
2017-07-09T13:37:39+09:00 INFO No non-zero metrics in the last 30s

このログが発生しないように設定を追加する。

Non-Zero Metricsのログを出さない設定

上記ログを抑止する設定は以下の通り。

$ sudo vi /etc/filebeat/filebeat.yml
filebeat.prospectors:
- input_type: log
  paths: ["/var/log/messages"]
#  symlinks: true
  fields:
    tagtype: linux
    tagapps: syslog
    taghost: centos7-m1
output.logstash:
  hosts: ["localhost:5044"]
#logging.level: debug
logging.metrics.enabled: false  //この設定を追加する

logging.metrics.enabledを無効化することにより、ログが出なくなる。設定変更しFilebeatを再起動するとログが出なくなる。

逆に細かく出す設定

ロギング間隔は変更することができる。

logging.metrics.enabled: true
logging.metrics.period: 10s  //デフォルト30s

このようにすると、10秒おきにログを出力することができる。ログの収集状況を詳細確認したいときなどに効果的。

2017-07-09T14:00:12+09:00 INFO Harvester started for file: /var/log/messages
2017-07-09T14:00:22+09:00 INFO Non-zero metrics in the last 10s: filebeat.harvester.open_files=1 filebeat.harvester.running=1 filebeat.harvester.started=1 libbeat.logstash.call_count.PublishEvents=1 libbeat.logstash.publish.read_bytes=6 libbeat.logstash.publish.write_bytes=365 libbeat.logstash.published_and_acked_events=3 libbeat.publisher.published_events=3 publish.events=6 registrar.states.current=2 registrar.states.update=6 registrar.writes=1
2017-07-09T14:00:32+09:00 INFO No non-zero metrics in the last 10s
2017-07-09T14:00:42+09:00 INFO No non-zero metrics in the last 10s

参考情報

オフィシャルにログに関する情報が記載されている。

www.elastic.co

また、デフォルトを含む全設定は/etc/filebeat/filebeat.full.ymlに記載されているため、1度目を通しておくと良いだろう。

$ sudo cat /etc/filebeat/filebeat.full.yml
######################## Filebeat Configuration ############################

# This file is a full configuration example documenting all non-deprecated
# options in comments. For a shorter configuration example, that contains only
# the most common options, please see filebeat.yml in the same directory.
#
# You can find the full configuration reference here:
# https://www.elastic.co/guide/en/beats/filebeat/index.html
...

まとめ - FilebeatでNon-Zero Metricsのログを出さないようにする

Filebeatのログ出力設定を変更することでNon-Zero Metricsのログを出力しないようにした。なお、必要に応じてログ出力頻度を上げることもできる。

Beats(Filebeat)のログをFluentdで受け取りtagルーティングする

f:id:daichi703n:20170709124930p:plain

Beatsはバッファ・再送機能(確認応答)を持つ軽量なログシッパーで、ログの発生元となるサーバーにインストールすることにより、Elasticsearchでのログ解析を容易にする。

普段はFluentd(td-agent)をメインで使用しているのだが、ログ発生元のサーバにtd-agentをインストールするのは、依存パッケージ等の問題で面倒だと感じていた。Beatsの一つであるFilebeatなら、単一パッケージで簡単に導入でき、メリットが大きい。

ただし、Beats(Filebeat)を導入しても既存のFluentdでのログパース構成は崩したくないため、BeatsのログをFluentdのtagルーティングに取り込むための設定を検証した。

Filebeatログ送信設定

Fluentdでのtagルーティングを想定して、filebeatでは以下の通りfieldsを設定する。

$ sudo vi /etc/filebeat/filebeat.yml
filebeat.prospectors:
- input_type: log
  paths: ["/var/log/messages"]
#  symlinks: true
  fields:
    tagtype: linux
    tagapps: syslog
    taghost: centos7-m1
output.logstash:
  hosts: ["localhost:5044"]
#logging.level: debug
logging.metrics.enabled: false

fieldsの使用用途はFilter用などのオプショナルなものとして定義されているため、今回のようなケースに適していると考えられる。

www.elastic.co

fields内の項目名は自由に定義できる。私はtag用途なのでtagxxxxとして、他との混在を防ぎ明確化しておく。

宛先はとりあえず同一サーバ内のFluentd。

symlinks: true シンボリックリンクの場合に有効化
logging.level: debug デバッグ時に有効化(デフォルトinfo)
logging.metrics.enabled: false No non-zero metricsのログ防止

FluentdでのBeatsログ受信

Fluentd(td-agent)でのBeats(Filebeat)ログの受け取りにはfluent-plugin-beatsを使用する。

qiita.com

また、ログパース・保存のために以下の通りプラグインをインストールする。

sudo /opt/td-agent/embedded/bin/fluent-gem install fluent-plugin-beats --no-document
sudo /opt/td-agent/embedded/bin/fluent-gem install fluent-plugin-forest --no-document
sudo /opt/td-agent/embedded/bin/fluent-gem install fluent-plugin-elasticsearch --no-document
sudo /opt/td-agent/embedded/bin/fluent-gem install fluent-plugin-record-reformer --no-document

以下の設定でFilebeatのログを収集する。(td-agent.confからinclude)

$ vi /etc/td-agent/conf/td_beats.conf
### Log Collect from Beats
<source>
  @type beats
  tag "beats.collect"
</source>

### Reform for tag routing
<match beats.collect>
  @type record_reformer
  tag ${fields['tagtype']}.${fields['tagapps']}.${fields['taghost']}
</match>

### For Parse
<filter linux.syslog.*>
  @type parser
  format syslog
  key_name message
</filter>

### General match
<match *.*.*>
  type forest
  subtype copy
  <template>
    <store>
      @type elasticsearch
      host localhost
      port 9200
      logstash_format true
      logstash_prefix ${tag_parts[0]}.${tag_parts[1]}
      type_name ${tag_parts[0]}
      flush_interval 20
    </store>
    <store>
      @type file
      path /var/log/td-agent/${tag_parts[0]}/${tag_parts[1]}_${tag_parts[2]}.log
    </store>
  </template>
</match>

以下、設定解説

Log Collect from Beats

Beatsプラグインでログ受信する。デフォルトでポート5044が使用される。

Reform for tag routing

tagをfieldsの内容で書き換える。ここでBeatsのログとしての処理が終わり、新規tagで再度Fluentd内でルーティングされる。(matchディレクティブのため)

For Parse

受信したログをパースする。ここでは/var/log/messagesのログなのでシンプルにsyslogフォーマットで展開する。tagで汎用化・共通化して設定量を削減するのがポイント。

General match

パースが完了したログをElasticsearch, fileに送信・保存する。今回は同一ファイルで設定したが、別ファイルにしてincludeの最後で適用されるようにしておくのが良い。ファイルバッファ・チャンク設定等の最適化は未実装。

ログ受信結果

想定通りにログを受信・パース・保存できている。

$ tail /var/log/td-agent/linux/syslog_centos7-m1.log.20170709.b553d9a17802a264d
2017-07-09T11:57:37+09:00   linux.syslog.centos7-m1 {"host":"CentOS7-M1","ident":"systemd","message":"Stopping LSB: data collector for Treasure Data..."}
2017-07-09T11:57:38+09:00   linux.syslog.centos7-m1 {"host":"CentOS7-M1","ident":"td-agent","message":"Stopping td-agent: td-agent[  OK  ]"}
2017-07-09T11:57:38+09:00   linux.syslog.centos7-m1 {"host":"CentOS7-M1","ident":"systemd","message":"Starting LSB: data collector for Treasure Data..."}
2017-07-09T11:57:38+09:00   linux.syslog.centos7-m1 {"host":"CentOS7-M1","ident":"td-agent","message":"Starting td-agent: [  OK  ]#015td-agent[  OK  ]"}
2017-07-09T11:57:38+09:00   linux.syslog.centos7-m1 {"host":"CentOS7-M1","ident":"systemd","message":"Started LSB: data collector for Treasure Data."}

まとめ - Beats(Filebeat)のログをFluentdで受け取りtagルーティングする

Filebeatのfiledsの項目を利用することで、Fluentd内で使用するtagを設定し、通常のFluentdのログと同様にtagルーティングできるようにした。これにより、Filebeatでのログ送信時も従来のFluentdで集約・パース・保存 or Elasticsearch送信できる。

自宅ラボ+VyOSでネストESXiホスティング環境を構築する

自宅でサーバの勉強をしたいが、古いPC(32bit)しかなくESXiを構築できない、という同僚がおり、検証環境を提供するため、自宅ラボにESXiホスティング環境を構築した。

私はこの記事で選定したサーバでESXi v6.5を運用おり、メモリーは24GBに増強したが余しているため、部分的に切り出して貸し出してみようと思う。

designetwork.hatenablog.com

自宅サーバホスティングを事業として収入を得る場合は、電気通信事業法の内容を要確認。今回は無償提供なので抵触しない。

ネットワーク構成

実現性とセキュリティを考慮して、自宅ラボの中で以下のような位置付けでホスティング環境を構築した。検討ポイントは後述のとおり。

f:id:daichi703n:20170701144943p:plain

独立したネストESXiをホスティング

ホスティングは基本的にはLinuxWindowsのサーバ単位での貸し出しとなる。しかし、今回はESXi (VMware vSphere) を含めて自由に検証できる環境を提供したい。

自分用のESXiを提供し共有するのはプライバシー的に好ましくないので、ネスト構成でESXiを新規構築する。(いずれもESXi v6.5)

ユーザからするとネストであることは意識する必要がなく、通常通りESXi上にLinuxWindows、仮想アプライアンスなどのVMを自由に作成することができる。

ホスティング環境をネットワーク的に分離

図に記載の通り、ホスティング環境は自分のinside, dmzと完全に分離している。ネットワーク分離のために、仮想ルータVyOSを導入し、セグメント分割している。ASA5505はライセンス上限でVLAN追加不可で、また、仮想ルータはCisco CSRやXRV、F5 BIG-IP VEなどを使用したかったが、無償版ではスループット制限(数Mbps程度)があり、実用に耐えず、OSSのVyOSを選定した。

なお、ホスティング環境からはインターネットへのみ通信可能とするが、inside->hostingのメンテナス通信はしたいため、VyOSのステートフルファイアウォールを使用し、通信の開始方向を含めたアクセス制御を実装する。

このように戻り通信を許可した上で内部向け(inside, dmz: 192.168.x.x)の通信を拒否する。デフォルトはacceptとすることでインターネット宛の通信を全体的に許可する。

set firewall all-ping 'enable'
set firewall name hosting default-action 'accept'
set firewall name hosting rule 10 action 'accept'
set firewall name hosting rule 10 'destination'
set firewall name hosting rule 10 state established 'enable'
set firewall name hosting rule 10 state related 'enable'
set firewall name hosting rule 20 action 'drop'
set firewall name hosting rule 20 destination address '192.168.0.0/16'

(参考情報)VyOSの設定に関して参考にさせていただきました。

komeiy.hatenablog.com

インターネットからのアクセスはWindowsリモートデスクトップ

セキュリティ的な懸念はあるが、操作性を優先して、インターネットからWindows Serverへリモートデスクトップできるようにする。必要十分で言えば、ESXi Web Client (vSphere Web Client)へのWebアクセスのみを提供すれば、コンソールで全台操作可能だが、コピペなどの運用性が低い。そのため、一旦Windows Serverを踏み台として、そこからVM操作、SSH接続することにする。

インターネットFWとして使用しているCisco ASA5505でNAT/FWの処理をする。ASAでの公開設定はこちらの通り(設計見直し余地あり)。Webとして書いているが、ポート番号を変えればRDPにも適用できる。

designetwork.hatenablog.com

VPNホスティングセグメントに入れるようにすればさらに便利かも…

※RDP Win Serverがホスティング環境にいるとESXi再起動などの運用ができないため通常ESXi環境に配置。

DDNSでIP動的変更

固定IPは未契約なので、インターネットからのリモートデスクトップ接続にあたり、自宅グローバルアドレスはDDNSを使用してFQDNで接続できるようにしておく。

動作確認

テザリングでインターネットから以下の動作が可能であることを確認した。

まとめ - 自宅ラボVyOSでESXiホスティング環境を構築する

自宅ラボにセキュアなESXiホスティング環境を構築した。Windows Serverを踏み台にすることで、LinuxへのSSH接続なども実用的な環境とした。

また、ホスティング環境用として使用したVyOSは、設定がシンプルで、スループットも確保でき、今回のようなちょっとした拡張ではかなり有用だと思う。

環境の提供は応相談ですのでご連絡ください。自動デプロイの仕組みなどはなく手動対応です。

BIG-IPでOSPFを設定しダイナミックルーティングする

f:id:daichi703n:20170617194650p:plain

BIG-IPを通常のルータとしても使用するためにOSPFの設定をする。BIG-IP はVE評価版を使用する。

VyOSなどの仮想ルータを使用してもいいのだが、管理する機器を増やしたくないので、導入済みのBIG-IP VEをシンプルな仮想ルータとして兼用する。

前提構成

  • PowerEdge T110 II (Xeon E3-1220, RAM 24GB)
  • VMware ESXi6.5 (Build 5310538) 無償ライセンス
  • BIG-IP VE v13.0.0 (Build 0.0.1645) 評価版ライセンス

Route-DomainでOSPFを有効化する

私の環境ではBIG-IPをルートドメインで論理分割している。ルートドメインを使用している場合は、その中でOSPFを有効にする必要がある。

Route Domains > Properties > Dynamic Routing Protocols

ここでOSPFをEnabledに追加する。

f:id:daichi703n:20170617185230p:plain

続いてSelf IPでもOSPFを有効化する。(インタフェースでOSPFを動かす場合)

f:id:daichi703n:20170617185316p:plain

tmshからOSPF(zebos)プロセスの起動状況を確認する。環境によりルートドメイン指定が必要。ospfdが上がっていればOK。

root@(h-big-ip01)(cfg-sync Standalone)(Active)(/Common)(tmos)# zebos check
=== route domain: 0 ===
No dynamic routing protocol enabled

root@(h-big-ip01)(cfg-sync Standalone)(Active)(/Common)(tmos)# zebos
usage: zebos [-r <rd_id | -a] check
       zebos [-r <rd_id | -a] (cmd command1)[,command2]

root@(h-big-ip01)(cfg-sync Standalone)(Active)(/Common)(tmos)# zebos -r 1 check
=== route domain: 1 ===
nsm is running [2640]
imi is running [2639]
ospfd   is running [2641]

IMIシェルからZebOSの設定をする

上記BIG-IP GUIだけではOSPFの設定は完了していない。(私の環境では)

BIG-IPに搭載されているIMIシェルからZebOSの設定をする必要がある。こちらはCumulusのQuaggaと同じイメージ。ログイン時にルートドメインを指定する必要あり。

今回はBIG-IP配下の172.16.0.0/24のセグメント情報を192.168.1.0/24側に広告したい。

[root@h-big-ip01:Active:Standalone] config # imish -r 1
h-big-ip01.designet.local[1]>en
#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
(config)#router ospf 1
(config-router)#router-id 192.168.1.8
(config-router)#network 192.168.1.0 0.0.0.255 area 0.0.0.0
(config-router)#network 172.16.0.0 0.0.0.255 area 0.0.0.0

sh runを見ると、このようにかなりシンプル。OSPFコストの設定などは未実施。BIG-IP GUI側ではこのあたりのOSPF設定はできないように見える。

h-big-ip01.designet.local[1]#sh run
!
no service password-encryption
!
interface lo
!
interface tmm
!
interface inside
!
interface hosting
!
router ospf 1
 ospf router-id 192.168.1.8
 network 172.16.0.0 0.0.0.255 area 0.0.0.0
 network 192.168.1.0 0.0.0.255 area 0.0.0.0
!
line con 0
 login
line vty 0 39
 login
!
end

これでOSPF neighborが張れた。ルート情報も交換できている。対向機器はCisco ASA5505。

h-big-ip01.designet.local[1]#show ip ospf neighbor

OSPF process 1:
Neighbor ID     Pri   State            Dead Time   Address         Interface
192.168.1.5       1   Full/DR          00:00:38    192.168.1.5     inside

h-big-ip01.designet.local[1]#sh ip route

K*      0.0.0.0/0 [0/0] via 192.168.1.5, inside
C       127.0.0.1/32 is directly connected, lo
C       127.1.1.254/32 is directly connected, tmm
C       172.16.0.0/24 is directly connected, hosting
C       192.168.1.0/24 is directly connected, inside
O E2    192.168.50.0/24 [110/20] via 192.168.1.5, inside, 02:09:31

(対向機器のルーティングテーブル)
ASA5505# sh route

S*    0.0.0.0 0.0.0.0 [1/0] via 133.xxx.xxx.xx, outside
O        172.16.0.0 255.255.255.0
           [110/20] via 192.168.1.8, 02:10:10, management
C        192.168.1.0 255.255.255.0 is directly connected, management
L        192.168.1.5 255.255.255.255 is directly connected, management
C        192.168.50.0 255.255.255.0 is directly connected, dmz
L        192.168.50.1 255.255.255.255 is directly connected, dmz

参考情報

F5オフィシャル情報

AskF5 | Manual Chapter: Working with Dynamic Routing

AskF5 | K14490: Overview of OSPF/OSPFv3 on the BIG-IP system

個人ブログ(英語)だが、一通りの手順は書いてある。私の環境での必要設定とは若干差異あり。

www.fransvandokkumburg.com

評価版では非実用的

BIG-IP VEをルータとしたが、評価版ライセンスではスループットが2Mbpsに制限されており、配下セグメントは実用的ではない…。

まとめ - BIG-IPにOSPFの設定をしてダイナミックルーティングする

(設定内容に不安があるので誤りがあれば指摘ください)
F5 BIG-IP GUIとIMIシェル(imish/ZebOS)の設定により、BIG-IPでCisco ASA5505とOSPFネイバーを形成し、ルート情報を交換することができた。この設定により、BIG-IPをルータとして使用し、セグメント追加時にもルート情報をダイナミックにアップデートできる。