いろいろ備忘録

雑記です。

EVPNメモ

Disposition PE...MPLSラベルをPOP(Dispose)するPE
given...(EVPNに限った話じゃないが)「所与の」と訳すと良いケースが多い

Platform Label Space...1つのルータ内でのラベル空間。ラベルIDでのみ転送先を決定する。ほかの種類にInterface Label Spaceがあり、そちらは受信IFとラベルIDにより転送先を決定する。

Context(-specific) Label Space...MPLSでは普通はDownStreamからラベルを割り当てていくが、いくつかのケースではUpStreamから割り当てる。その場合、もしラベル空間が一つしかなければ、UpStreamのLSRが割り当てたラベルが既存のラベルと被ってしまう可能性がある。そのため、リモートLSRごとにContext Label Spaceを持っておき、フレーム受信時にどうやって受信したかによって参照するラベル空間を変える。

 

Traffic Trombone(Tromboning)って何

Traffic Tromboneはかなり大雑把に言うとトラフィックが最適でない(無駄な)経路を通ることらしい。

 

例えば、本来アクセス層だけで済む通信(ヘアピン)が、ネットワーク設計の問題によりコアを一度経由してしまうケースとか。

Traffic Tromboneが指す構成は決まっておらず、文脈によって変わる。

 

言うまでもなく遅延や帯域圧迫などの原因となるので、回避・防止すべきものとして描かれる。

EVPNメモ(RFC 7209)

1章 モチベーション

L2仮想化の一つであるVPLSは広く使われているものの、冗長性、マルチキャストの扱い、プロビジョニングの複雑さがイケてない。

それに、E-Tree(疑似的なハブ&スポーク構成)や、VPWS(疑似的な専用線)という新しいニーズも増えた。

 

マルチホーミングについては、VPLSはAct-Sby構成しかサポートしていない。

マルチキャスト最適化については、マルチキャストLSPをVPLSと組み合わせて使う方法はあるが、VPLSが一対他しかサポートしていない。(多対多をサポートしていない)

 プロビジョニングについては、BGPをベースにしたauto-discoveryを使って、single-side provisioning(よくわからん、後でググる)ことができる。ただ、この場合も、コアネットワークの設定はちょっと必要。

データセンター間の接続については、VLANを上手く扱えるインターフェース(VLAN-aware bundling)が欲しくなってきた。

仮想サーバの隆盛で、扱うMACアドレスの量も増えてきた。PEで学習するMACアドレスがいくら多くても、障害発生後の切り替わりに影響を及ぼさないようにしたい。

VPLSやH-VPLSじゃ出来ないような複雑なトポロジーも作りたい。

 

2章、3章は割愛

 

4章 冗長性の要件

 

4.1 フローベースのロードバランシング

CE-PE間のマルチホーミングで一般的なMC-LAGだけど、ICCPもそんな感じの技術。

LAGのアルゴリズムは柔軟で、唯一の要件はトラフィックフローにおけるフレームの順番を保証すること。

LAGの普通の実装では、ヘッダの情報をもとにフローを識別するけど、RFCじゃ標準が決まってないから、実装次第で動作が変わっちゃう。まあ実際非対称になってても動作には問題ないんだけど。

ここが良くないから、L2~L4のヘッダを基にフローを識別するアルゴリズムRFCで決めなきゃならんね。

 

要件 1a:CEが行う柔軟なフローベースのロードバランシングに対応すること。

 

要件 1b:CEが複数のPEに接続されていても、CE宛のトラフィックフローベースでロードバランシングすること。CEが何本PEに接続されていようと、そのすべてのリンクを使うこと。

 

マルチホーミングの場合、マルチホーミングしている2つ以上のPE~どっかのPE間にECMPパスがあることもある。そのマルチホーミングがAct-Actなら、どっちのPEに送っても良いようにしたい。その時は、それもフローベースでロードバランシングしよう。

 

要件 1c:複数のASにまたがる冗長のPEに対し、フローベースでロードバランシングできること。

 

4.2 フローベースのマルチパス

 4.1で説明した機能について、PEの間でも複数の通信経路を使えること。

例えば、あるPEとAct-ActのPEの間に通信経路が2つ以上あるなら、Act-Actが宛先のトラフィックは、ロードバランシングできること。

 また、そのパスのコストが同じ(ECMPパスである)なら、そのすべてを使えること。

後者なら、 RFC6790で規定されているエントロピーラベル(後でググる)を使ってもいい。

 

 要件 2a:あるPE~Act-Actのマルチホーミングが有効な冗長グループに属する全PE間の、全てのLSPを、全てActiveとしてロードバランシングに使用できること。

 

 要件 2b:あるPE~Act-Actのマルチホーミングが有効な冗長グループに属する任意のPE間にあるECMPをすべて使用すること

 

たとえば、CE1=PE1,2(Act-Sby), CE2=PE3,4(Act-Act)の構成で、PE1,2~PE3,4に3つのECMPパスがあるとき。

FROM:CE1 TO:CE2のトラフィックはMPLS/IPコア上で以下の12通りにロードバランシングできる。

①CE1→PE1,2の2通り(Act-Sbyでも、要件1aにより受信は可能)

②PE1,2→PE3,4の3通り(上記ECMPパスの数)

③PE3,4→CE2の2通り

=>2x3x2=12通り。

 

4.3. 地理的に冗長なPE

マルチホーミングするPEを地理的に冗長しようとすると、マルチホーミングのグループ内のPE間のリンクを用意するのはコストがかかるので、そのリンクが無くても良いようにしたい。

また、IGPのコストの計算に遅延などが含まれる場合は、あるPEから上記の地理的に冗長なPEまでのコストが冗長グループ内で異なる可能性がある。

要件3a:マルチホーミンググループ内の制御用リンクが無くても、All-Activeなマルチホーミングができること。

 

要件3b:任意のPEからマルチホーミンググループの各PEへのIGPコストが異なるケースをサポートすること。

 

要件3c:同一ASで異なるIGPドメイン間のマルチホーミングをサポートすること。

 

要件3d:複数のASにまたがるマルチホーミングをサポートすること。

 

4.4 トラフィック転送の最適化

マルチホーミングのPEの先には、もちろんCEが1つじゃなくて2つのパターンもある。(CE1,2=PE1,2)
All-Actの場合、下記のすべてのケースで最適な転送をサポートすること。
( ”最適な転送”とは、宛先CEがマルチホーミンググループのPEに接続されていない限り
マルチホーミンググループのPE間でトラフィックが転送されないこと )

具体的なケース
A: シングルホームのCEから、マルチホーミングのCE
B: マルチホームのCEから、シングルホームのCE
C: マルチホームのCEから、マルチホームのCE(上述の通り、受信側は除く)

特に、マルチホームグループで地理的な冗長をとっているとき、距離分の遅延が発生するので、良くない。

 

4.5 柔軟な冗長のサポート

マルチホーミングカニズムはPEを複数の冗長グループに任意にグループ化できるようにすべき。
各冗長グループは、PEの同じグループを共有するすべてのマルチホーミングされたデバイスやネットワークを代表する。

 

例えば、PE1,2,3があるとき、①PE1,2 ②PE2,3 ③PE1,3の3つの冗長グループを作れる。

この冗長グループのいずれかに、CEをマルチホーミングできる。

 

4.6マルチホームネットワーク

マルチホーミングしているネットワークにおいて、MSTPやリングプロトコル(G.8032)が有効な時。PEはそれらに参加する必要はないが、VLANごとに、マルチホーミングしているリンクのうち1つのみアクティブ経路である必要がある。

 

要件6a:すべてのVLANが一つの

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Kasperskyを使っているとkibanaで「Request has been forbidden by antivirus」というエラーが出る

【問題】

カスペルスキー インターネットセキュリティを使っていると

kibanaで下記のようなエラーメッセージが表示されることがあります。

Unable to load index_pattern fields Request has been forbidden by antivirus

 

【解決策】 

カスペルスキーのウィンドウを開き、

設定>プロテクション>Webトラッキング防止>カテゴリと除外リスト>除外リスト>追加

そして、対象のホスト名など(ex.localhost)を追加。

Apresia AEOSにNetmikoからTelnetでコマンドを送る

コードは以下です。

 

import netmiko

net_connect = netmiko.Netmiko(host='IPアドレス', username='ユーザ名', device_type='apresia_aeos_telnet')

※パスワードは適宜追加してください

 

接続で気をつけること

プロンプトが出るまでコマンド出力を待つ仕組みなので、terminal length 0がrunning-configに含まれていることをログイン時に確認し、なければ投入する動作になっています。(---more---が出力されるとタイムアウトになる)

AEOSではshow running-configは特権モードで実行するため、特権ユーザでなければモード遷移に失敗し、接続できません。

また、接続時の引数にallow_auto_changeが入っていない場合、ter len 0 がコンフィグに含まれていなくても、ter len 0の投入を行いません。

 

特権ユーザ以外でログインしたい場合は、ApresiaAeosBaseクラスの
disable_pagingメソッドをpassするように書き換えればとりあえず動きます。

(もっと適切なやり方がある筈なので知っている方居たら教えて下さい)

 

追記:

netmikoは特権ユーザでログインするのが必須要件のようです。

requestsに信頼する証明書を設定する

基本はこのリンクの通りです。

Advanced Usage — Requests 2.22.0 documentation

 

今回、バイナリ形式のcerファイルを設定したのですが、

読み込んでくれなかったので、cer→pemに変換したら読み込んでくれました。

RSA鍵、証明書のファイルフォーマットについて - Qiita

 

この変換はopensslコマンドを使うのが一般的なようですが

今回はopensslコマンドが使えない状況だったので

ssl.DER_cert_to_PEM_certで変換しました。

ssl --- ソケットオブジェクトに対する TLS/SSL ラッパー — Python 3.7.3 ドキュメント

 

以上で読み込み完了です。良かったですね。

AWXでkintoneを定期的にフェッチしてCloudFormationを実行する

このセミナーに影響を受けています。

20171006_lightwell_AnsibleSeminer.pdf - Google ドライブ

 

簡単なPlaybookはこちら。

VPC名を必要とするCFnテンプレートと、kintoneから未作成のレコード一覧を検索して順番に作成するPlaybookです。

続きを読む