Trema Day #9 参加メモ
Trema Day #9 に参加してきました。いつものメモ公開です。(LTはメモ取ってません。) 各発表の資料は Connpass に公開されると思いますのでそちらを参照してください。
まあ今回もなんと申しますか、よく言えばバラエティ豊かと申しますか。これだけニッチで雑多な話題が集まるのもそうそうない気がしますね。
NetTesterで物理ネットワークの受け入れテスト(@yasuhito)
- 物理ネットワークのテスト
- ネットワークの話を聞くと、みんなとても大変そう。
- 某所のテスト風景
- 手作業、現場に行って現物を操作しないとテストができない。
- これをなんとかリモートで、現物持ち込まなくてもテストできるようにしたい。
たとえばFWとかをテストしたい
- 通信するノード(サーバ・クライアント)、最低2台おいてパケットを送らないといけない
- 項目も爆発: いろんなIP,ポートでテスト、機器もいるし組み合わせもたくさんある。
NetTester
- しくみは単純
NetTesterの特徴
- シナリオの書き方で工夫
テストの時に考えること
- テストツール、周辺のツールはたくさんある。充実しているので、それらはなるべくそのまま使いたい。
- 代表的なのは cucumber, rspecなど
- テストの手法もいろいろある。
- 自動テストの仕組みもいろいろある。CIとかも。
すでにあるツール・知見をネットワークにも適用しよう!
- もともとテストのツール、アプリ屋さんが強い。
- アプリ屋さんとネットワーク屋さん
- NetTesterはそれらの間をつなぐツールを狙う
- https://github.com/yasuhito/net_tester
NetTester
- いまのところ、受け入れテストのツールとうたっている
- ゆくゆくは、設計フレームワーク。
- ネットワーク設計の時の助けになるツール
- TDD
QA
- Fiewall以外のケース想定
- まだ検討中。
最近のTremaを触ってみてちょっとはまったこととか (@stereocat)
(自分しゃべってるところなのでメモありません。資料参照してください。)
「GoBGP活用によるSD-WANプラクティス (@ttsubo)
GoBGP
- BGPエキスパートがいろいろつかってる。
- 最先端のBGP機能
- gRPC機能で連携が図りやすい
GoBGPにもD-planeを
- pingがデモで使えないという課題をどうにかする。
- Quagga環境を活用
- Quagga bgp daemon を GoBGP にする。
- netlinkでFIB注入を行う。
- 中間に goplane を置く。
- OpenFlowでFIBに注入する
- goplane ではなく openflow controller (trema or ryu)
- パブリックな実装はないけど、個人的な実装でサンプル的に動かしてみたことがある
そもそも
- OFCでgolangに対応したモノって、ニーズあるんだろうか?
本題: SD-WAN
- whitebox switch とか持ってきて環境作りたいけど、自宅だと敷居が高いなあ。
- うるさくなくて、自宅におけるようなモノ……RasPI?
プラクティス
コンフィグの一元管理
- とりあえずgoBGPベースのところ
BGP Peer断の即時通知
最後に
- goBGPは環境くみ上げるのは簡単なので、みんなもお手軽に始めてみようよ!
QA
- 投資額?
- SRXはこのためだけに買ったわけでは泣くほかにも使っている。(5万円とか)
- BGPだけでも迂回できるはず。orchestratorの役割は?
- デモのところはorchestratorは関係ないところ、orchestrator の動きのところは公開済み動画で説明してます!
Bird in Cloud (@hibitomo)
Interop Tokyo 2016 Shownet に lagopus を入れた話
Lagopus
- OpenFlow Switch 実装。
- dpdkで高速スイッチング
- openflow 1.3 に strict に準拠
- 雷鳥
- 高いところに住んでいる鳥 → Cloud に住んでいる
in ShowNet
- NFV島でうごいていた
- servicechain
- netfpga で処理してlagopusで転送
- VNFではVirNOS
- Serverの中でlagopus/virnosそれぞれがdpdkで動いている。外-lagopus/virnos-外 をちゃんとdpdkでやってる。
性能を出すための設定ポイント
- dual socket のサーバ
- コアアサイン(lagopus/VNF)
- パケットや処理の流れを想像してコアアサインを考える。
- 性能を測ってみた。2倍くらい変わる。
- トラフィックの偏りも考える。
- これでも10％くらい性能が変わる。
- フロールール設計
性能評価
QA
- nsh passing
- Servicechain, コントローラはNOCメンバが書いてた。BGP flowspec でまげて、openflow で source ip base のルーティング。openflow 部分でトンネリングとかはやってない。
- コア混ぜるとどうなるか?
- 今回はコア混ぜたのはやってない。時間がなかったので。
- 1個のNICに対して1CPUコアがアサインされる?
- そういう風に割り当てている。dpdkがそういう仕組み。割組じゃなくてポーリング、担当している数でコア単位に分ける。
- これをつかってOFS作ろうとすると、コア数に制限されたスイッチしか作れない?
- lagopusは1コアで複数ポートを見るようにできる。IO/workerのバランスを変える。
LagopusでPPPoEを使えるか考えてみた件 (@masaru0714)
lagopus
- packet header encap/decap の機能が拡張されてる。
- ソース書き足せばほかのヘッダも対応できる
PPPoE
lagopusでPPPoE
- PPPoEヘッダつかえればlagopusでPPPoE終端させられるんじゃないか?
- PPPoE packet format
- プロトコルネゴシエーションはコントローラ、コネクション確立したらペイロードの転送はlagopusで、というのを考えた。
コントローラのプログラミング量が結構多そう
結局何ができるのか?
- ブロードバンドルータを実装したようなものになるのでは
- PPP処理は既存の実装流用でもいけるのでは
- 自宅のブロードバンドルータを lagopus で置き換えよう!
QA
- OXM?
- いまはべたっと書くので、正式な仕様の方でかぶったらずらさないといけない
OVSDBで遊んでみた (@tkshnt)
OVSDB
- Open vSwitch DataBase
- RFC7074
OVSDBの特徴
- DB変更があると側道差が反映される(commitがない)
- フロー情報もOVSDBに書き込まれている
- ovsdb-client/server
- OVSDB schema
- OVSDB tool
QA
- OVSDBでやらないとできないconfig, OVSDBいじったんだけど狙った通りに反映されないもの、どこかに情報あったりする?
- そこまでは調べられてない。
- 変なごみが残ってるらしい。(vsctl コマンドで変なごみが残る? /etc/openvswitch/ovsdb プレーンテキストで書いてある。そこにあらゆる消し忘れのごみが残っている。うまいことやるなら、vsctl だけじゃなくて自分でちゃんと消してあげる。そのせいでうまく動かないんじゃないか。
- いったん全部消してからやり直すと上手くいくかも?
ZodiacFXについて語ってみる (@kwi)
Zodiac FX
- "Affordable"
- Kickstarter, 期限ぎりぎりに達成。
- Kickstarter枠配布が終わって、ファームウェアは開発中。
- 直販で買える。送料込、諸経費のぞく、$99.00-AUD
- 配送はFedEx
使い方
- 電源兼シリアルなのでUSBシリアルから設定
- telnetもできるようになる予定
ファームの書き込み
- SMB-BAをつかってUSBシリアルで書き込み
- 最初の頃のファーム、コンパイラ荒い面とについてのところがナイーブに実装されててうまく動かないやつがあったり
ベータテスタ枠
- ベータ、実はたいした作業できていない。むしろ今から本番
ベータボードとプロダクションボードの違い?
- そんなに違いがない。
開発環境
- 開発しようぜ!
- Atmel Ice debugger
- SOCに直結してステップ実行とかできるようになる。
- 事実上必須
- github
- OSS運営自体もあまり経験がないみたい。一般的な流儀とちょっと違う。
開発中の注意
- 温度
- あまり触らない
- 電源ノイズ
ソフトウェア
- 悩んだときはAtmel の SOCの開発環境そのまま、Atmelのサンプル探してもってく売ると動く、みたいな感じ。
- いわゆるOSはない。
Logical view
実装してみた
なぜZodiac FX?
- 極論すると whitebox switch
- OpenWRTより簡単なフリーの開発環境なんじゃないの?
- 自由!
無線屋はエンタープライズSDNの夢を見るか? (@t_j_baldwin)
(諸事情によりメモ取っていません)
中国にopenflowを入れてきた話 (@Clorets8lack)
中国〜日本の間の経路
- 3重冗長[直結・上海経由・シンセン経由]のいいところを使う
- 2重だったところにシンセン経由を追加した
導入理由
- 基幹システムのレスポンス向上→VDI導入
- VDIはパケットロスに弱い。(0.5%ロスがギリギリ)
- でも、できると遅延を無視できる。
- 国際ネットワークのBCP
- 予算とかないんだけどでも何とか
- 無敵のBCP!?
実際の運用の工夫
中国の秘密
- キャプチャ全部取ってるので障害と化がいろいろ見えてくるものがある
- 通信通らなくなるのは割とある
- Great Firwall は中国の通信規制の一部
- なにがあるか?
中国は言ったもの勝ち
- トラブル、言ってみると治ったりする。CPE設定でやってることがあるので、証拠を出していってみると、意外と修正してくれたりする。
- 凡ミスもおおい。気づいたら言うのが重要。エビデンスを出して、こうしろ、という話をする(「調査してくれ」だけだと動かない)
- 時にはあきらめも必要
Enterprise国際インフラ運用
- 予算と人手が足りない中で何ができるか?
- 理不尽な障害が常に起きる。原因究明・再発防止のための可視化、というのが必要。
SonarMan
- VMあるよ!
NetOpsCoding #3 参加メモ
NetOpsCoding#3 : ATND に参加してきたのでいつものメモです。
各発表の資料とかは atnd の方参照してください。
Introduction to NetOpsCoding#3
Biglobe 土屋さん
NetOpsCodingとは
- 今日初めての方が6-7割
- NWにおける自動化事例、システム開発治験、有用なツールとかを共有
- NW装置の設定、監視、管理、手順書の作成…などの運用業務
- 自動化をキーに考えたい。
- 楽をしたい、ミスをしない、もっと楽しいことに時間を使いたい
- いざ開発を始めると壁
- ちょっとやってみた、位だとなかなかできない。システム開発のスキルセットはネットワーク運用と全然違う。覚えることも多いし、NW装置の標準もないから泥臭くやるしかなかったりする。作ったとしても自分しか使ってない…みたいな状況も。運用しかやってない人に使ってもらうのは意外と難しい。NW運用者がツール開発…開発の時間をどう確保する?
- ベストプラクティスを共有しよう! みんなで壁を乗り越えよう!
ネットワーク運用者へ
- 自分たちで使いたいモノを自分たちで作る。壁は多いけど、上手くいいツールが作れたら自分たちの仕事のやり方を自分たちで変えるチャンスがある。まずはできることから少しずつ。
ソフトウェア開発者へ
- ネットワーク運用はたくさんの課題。未だにこんなので? というのがいっぱいある。NW運用の実情を知ってもらって、改善のためのヒントがほしい。
- NW運用とソフトウェア開発が一緒にやれるといいよね。
NW装置メーカーへ
- いいAPIがあれば是非教えてください。業界動向とかも気になります。
自動化をやりたい、本気で困ってる、みんなのヒーローになりたい、というかたは前のめりに参加してください!
CloudStack を用いてLBサービスを開発してみた
IDCF上野さん
ロードバランササービス("ILBサービス")
システム構成
- MQを用いた分散システム
- 管理サーバ側の冗長構成や運用をやりやすくする。
- cloudstack + HA proxy によるLB提供
- 27台のサーバ
- 手作業運用は難しいので自動化。
サービス運用
継続的デリバリという考え方
- デリバリー
- ソフトウェアはユーザに提供して初めて価値がある。提供までの時間を短くするために何ができるか。
- 自動化 / こまめに
運用とは
- システムなどが正常に稼働し続けられるような状態を維持すること。
- 個人的には…夜間・休日とか対応したくない。開発に集中したい、できるだけ稼働取られたくない
- 1台くらいサーバが落ちても即時対応しなくていい設計
ILBサービス開発ポリシ(構成管理)
サービス基盤の運用設計ポリシ
- サーバ三重化
- MQが重要。容易にサーバ追加・削除ができること。
- 運用チームへのアラートをなるべく少なくする
LB運用自動化
- 手動によるLB追加・削除、LBダウン時の緊急対応みたいなのはやりたくない。必ず2台以上のサーバが生きているようにする。
運用を楽にする
- 自動化: LBの障害検知、スケールアウト、追加・削除, VMの物理ホスト分散
Sensuの活用
- エージェント型の監視
- いいところ
- チェックと目と陸の定義、レベルに応じた処理、管理画面がわかりやすい(!), RabbitMQを使ってる、最新版(0.2.5)からAggregator...(チェック結果をグルーピングして扱える)
Sensuを利用してIBLで行っていること
- LBプロセス監視, Failover, メトリクス収集
- 管理サーバの監視・メトリクス収集
まとめ
- 継続的デリバリ、というのが重要なかんがえかた
- 単体試験・振る舞い試験・デプロイ・ロールバックがボタンひとつでできるようにすべき
- MQ使うことで簡単にコンポーネントの追加削除
- Sensuわかりやすい。Aggregatorでたので複合事象ハンドリングも定義できるように。
今後
- LB振る舞い試験はまだできていない
- 管理系サーバの自動サーバ追加・削除
QA
- ふるまいの試験ってどういうのを考えているの?
- cookie parsistency, balancing algorithm, をクライアントツール系で確認できるようにしたい
- LBの振る舞い、SSLオフロードとかしてる場合、増やす・減らすが難しいんじゃないか。増減あったりしたときにコネクションもろとも落ちたりしない?
- 既存セッションの取り扱い。そのへん、HA proxy だと graceful にコネクション切り返してできるようになってる。サーバ減らすとき、タイムアウト地を設定して(デフォルトだと30分)セッション維持してあたらしいのを切り替えていくとか。時間をおいて自動で切れていくように。
- Sensu, uchiwa 画面以外に可視化していること、LB向けのプラグインとか作ってる?
- Sensuは特にいじってない。メトリクス可視化については influx db + graphana を使ってる。なのでSensuのほうはあまり作り込んでない。
- NW危機を触る場合、機器アクセスの排他制御。MQアプリ使うとそういうのがあるんじゃないか。MQ/worker, たとえば3台、同じタイミングで同じデバイスをさわりに行くとかは同コントロール?
- Ansible, 普通にplaybookでいじってるような感じ? HA proxyだとAPIないのでconfigいじってるんじゃないか。
- 実際 playbook をごりごり書いてる。bestpractice formatで書いてる。
- HA proxy 設定については playbook ではなくて worker というコンポーネントが設定取ってきて、変更確認して、変更置き換えるみたいな操作をしている。
Monitoring Intelligence
Microsoft 北島さん
NWチームの最大の顧客: MS Azure
- 毎年 100% ずつ増加! (3年くらい前の状況)
- レガシなモニタリングシステムだと、全体としてどうなってるのかとかわからない。
- ベンダのラボでは絶対再現しないようなバグが発生する。
- ベンダを説得するためにいろいろネタがいる。
典型的なトラブルシュートのフロー
- 問題 → chaos → 新しい情報を集める → Manage → 何が起きているのかを明らかにする → define → どういう情報をどう見れば問題が明らかになるか → Measure → Continuous Improvement
- レガシ監視システムだと chaotic - manage - define をどうするか。
- そもそもデータとれない、APIアクセス許可もらうのに2日かかる…
- NWチームがオレオレ監視サービスを乱立
- それじゃいかん。プラットフォームを作ろう!
- というのが3年前
プラットフォームへの要求
- すぐに新しいデータ収集ができること
- 全課程を通じてNWエンジニアがすぐに直接チェックイン・操作できること
- ライブデータを多角的に分析できること・APIアクセスできること・共有できること
時系列データを扱うためのOSS
- データ収集 - 蓄積 - 分析
- graphite
なにができるか?
- demo
- 時系列データが graphite のDBに入っている
- ツリー構造でデータがある
- ダッシュボードを作る
- グラフを追加
- ある項目を * にして複数データを重ねたりできる: graphana -- influx DB のクエリ, いろんな関数が選べる。
- データをその場で操作できる
- 移動平均を取ったり、2年前のデータとの比較をしたり、とか。
- その場でデータ操作してこりレーションを見つけられる
実例
- JUNOSのコードをあげる(code upgrade)
- アップグレードした結果何かが良くなったという結果がとれないとメンテナンス成功とはいえない。
- 収束性に関するパラメータ、ロードアベレージなどが旧バージョン機器台数が減るにつれて落ちていくのが見えた。
- アップグレードした結果何かが良くなったという結果がとれないとメンテナンス成功とはいえない。
- データ相関: ファイバカットの時の影響
- メンテナンスが上手くいっているかどうかのチェック
- IS-IS導入、保持経路数のチェックを確認。メンテナンスが進行して上手くいっているか?
- ルータごとのデータ相関
- ルータのCPU上がったことに対して相関
システムの動作
- graphite, 単純な作り。
- ルータからデータ持ってくるところ(data feeders)は自分で作る必要がある
- graphite へのデータ送るのは簡単。
どんなデータを送ってるか
demo
- code upgrade
- ダッシュボードの鮮度は重要。3ヶ月前のダッシュボードは役に立たない。問題がもう変わってしまっている。
- FPC Heap memory size... が新しいバージョンで増えている…メモリリークだろうという子音でアップグレード保留に、みたいなことをしている。
- あるルータグループ間のiOutDiscards
- 全ネットワークでどこがほっとなのか、というのはこの辺で見えたりする。
- アラートに対してその重要度の判断をするために参照したりする。
- Optical levelとifInErrorsの関係
- ?
- Black Hole検知: 様々なカウンタを見る
- Black Hole検知: LAG imbalance (LAG up してるんだけどある1本が死ぬ)
- LAGバランスが壊れたモノをカウント
- 問題バリエーションの多さに頓挫。問題のバリエーション・トラフィックパターンのバリエーションが多すぎてひとつのモデルじゃどうにもならない
- Black Hole検知: IN/OUT総和比較
Scripted Dashboard
- graphana
学んだこと
- 最初にもくろんだこと
- オレオレ監視はやめて、みんなで同じプラットフォームにデータをためて、コラボレーション
- トレーニングを3ヶ月に1回くらいやってたけどサボり始めるとアクティビティが落ちる
- 問題だけこっちに投げてくる人が続出
- ダッシュボードの管理
- 賞味期限は数ヶ月。どんどんその時々の eyeball を作って初めて役に立つ。
- システム管理コスト
- 3年で1回しか落ちてない。
QA
- graphanaで見ているメトリック、どうやってアレに気づいた?
- 基本的にはベンダに教えてもらった。childnexthopが増えると収束性が落ちる…といのが元々あって、それで調べたらメモリリークだった、という展開。
- いろんな相関関係をどうやって見つけるのか?
- 基本的には、議論するときにデータドリブンな議論を推奨するようにすべし、というCEOからの意見もあり。こんなんじゃないの、みたいないい加減な議論をしないようにしようと。その結果、運用者側が見つけたり、ベンダに投げてベンダが見つけたり、みたいな感じ。
- データドリブンな議論→データとれないと行けない。ルータあたりで取るデータすごく多い気がする。いっぱい全部取る? 特定のカウンタだけで当たりつける?
ネットワーク運用自動化の実際 〜現場で使われているツールを調査してみた〜
Biglobe 土屋さん
じゃあみんな、実際のところ何使ってんの?
ネットワーク自動化事例増えてきましたね。
みんな同じモノ作ってない?
- 共有してみようよ
- github.com/netops-coding
- みんなが作ったモノを寄せ集めていく。
そのまえに、今どんなモノを使っていて、どんなことで困ってる?
- アンケートしてみた。
- 2week, 28人回答
詳細は資料参照!
みんなで共有しようよ
理想的なdevops体制を作るために
- 一人で初めて運用チーム化していくところをサポートできないか
- 導入事例やノウハウの共有。作ってみた・使ってみた
github netops-coding
- tipsまとめてみた: netops-coding/netops-tips/wiki
Slackつくってみた
- いま招待制
- netopscoding@googlegroups.com あてに連絡を
QA
- rancid
- netops-coding へのプッシュとかどういうかんじでやればいい?
- ご意見ください
- 出したいモノはあるけど会社の都合で外に出せません的な
- 俺たちが文化を変えていくんだ!
LT
JSONからちょっといい感じのネットワーク図を書く
小島さん
ネットワーク図について
- NW図ほしいけど書きたくない
最低限の情報(json)で、いい感じに図を書いてくれ
- やってみると上手い配置にならない。レイアウトがいまいち
- リロードすると配置が換わってしまう
論文探してみた
- グラフ理論: オートレイアウトの話はたくさんある
- 配置するときに制約をつけるといいっぽい
- ノードのグルーピング
- ノード名(グループ)+リンク距離(ジャッカー度距離...集合間の距離)
- d3.jsで実装
そこそこ自動でレイアウトできつつある
- github codeout/inet-henge
多数のルータへのログインをはかどらせてみた
岩田さん
- 多数のルータログイン
- ルータが死んで隣接ルータからアラート
- 日々の運用操作で亜ログイン
- 手動でやると入力ミス…
- はかどらせてみた
StakStorm
@w4yh
StackStorm
- iftttを運用に持ってきた
- 自動化+自動復旧
- 自動化プラットフォーム+ワークフローエンジン
- 6/24にver1.5
- フリーミアムモデル
NW運用自動化におけるStackStormの位置づけ
- 作業入力代行…マクロ/expectみたいなところからの発展…
- ベンダの違いの抽象化・汎用化
- ransid, ansible, netcnf/yang, ...
- 多数のノードの操作・全体の制御(オーケストレーション9
- SDN/overlay
- StackStorm: システム全体の面倒を見れるモノ
- ベンダの違いの抽象化・汎用化
プラットフォームなので割と尾賀香里奈ツール
- トリガを受け付けるところ
- フィルタ
- マッチしてifで分岐
- アクションのキック
- いろんなインテグレーション、連携パックがある。1000+とかあると言われている。
- 連携ツールが充実しているのが特徴。
StackStormの生きるケース
- 単発ではなく分岐・並列・合流、ワークフロー的な処理
- 機器をまたいだ処理、他機種混在、かつ純正ツールがない…みたいなケース
- コマンド実行時の引数共有・使い回しとか
- ジョブ管理, ワークフロー, サーバレス, トリガーベース
操作
VyOSでL2透過なNetwork Emulatorをつくる
VyOS で Network Emulator という話は前見ていたので記憶の片隅にあったわけです。
で。こういうのを見つけたわけですね。
思ったわけです。これ二つ組み合わせれば、L2透過 (L2 Transparent) な Network Emulator つくれるんじゃないのか? と。
はい。結論から言うとできました。まあそんなに機能追いかけて検証したわけじゃないけど、ちょっとしたテストくらいだったらこれで充分回せるじゃないだろうか。なお、VyOSのバックエンドで何をどう使っているのかとかを理解しているわけではないので、怪しげなことを書いているかもしれません。ツッコミどころがあったら教えてください。
環境構成
いきなり実機デプロイの図出だしますが、こんな感じでやりました。
はいわかりにくいですね。ごめんなさい。この図で言いたいことは
- Internal セグメント (VLAN101) と Vyos Expr セグメント (VLAN701) を VyOS(vyos-expr) でブリッジしてひとつの L2 セグメント (192.168.1.0/24) としている。
- ホスト vyexpr1 (192.168.1.99) に対する通信はかならず Vyos Expr Seg/vyos-expr を経由する。
というあたりです。自宅の環境でやる以上、どうしてもいまある機材の中でどうするかという話があってですね。こういう状態になっていますね。あ、VyOS は 1.1.7 を使っています。
テストに当たって、基本は vyexpr1/vyexpr2 間の通信がどうなるのか、というのが見えれば良いです。ただ、Win10 だと今ひとつだったツールがあったりしたので、DMZ セグメントにいる host1 というのを召喚していたりします。なので、host1 使うのは重要ではありません。新しく VM 立てたりするのが面倒だったから既存の VM を使い回しているだけです。
スイッチ(core2)側のポート設定はこんな感じです。
interface GigabitEthernet1/0/16 switchport access vlan 701 switchport mode access ! interface GigabitEthernet1/0/17 switchport access vlan 701 switchport mode access ! interface GigabitEthernet1/0/18 switchport access vlan 101 switchport mode access !
なお、vyos-expr が接続している vSwitch (vSwitch2/3) は、L2で透過になってほしいので、プロミスキャスモードを有効にしてあります。
ブリッジ設定
まず、物理構成を確認した後、vyos-expr をブリッジとして設定し、vyexpr1 が vyos-expr 経由で(L2透過で)通信できることを確認しましょう。
vyos-exprの設定
- eth0/1 を bridge-group 追加する、というだけで良いのですが、bridge 自体に IP を振っておくとデバッグ用に使えるのに IP も設定しましょう。(参照; User Guide - VyOS)
set interface bridge br0 set interface bridge br0 address 192.168.1.100/24 set interfaces ethernet eth0 bridge-group bridge br0 set interfaces ethernet eth1 bridge-group bridge br0
今回、br0 に設定した IP をつかって vyexpr2 から ssh していますが、当然このあとの delay/packet-loss 等の設定をすると ssh connection も影響を受けます。リモートアクセス用のパスは別にしておくのがベターだと思います。(面倒だったので今回はやっていませんが…)
スイッチ側の確認(物理接続: MACアドレステーブルの確認)
core2#show mac address-table | inc 1/0/1[6-8] 101 000c.291a.d732 DYNAMIC Gi1/0/18 701 000c.291a.d73c DYNAMIC Gi1/0/17 701 000c.2978.3848 DYNAMIC Gi1/0/16 core2#
vyos-expr 側の確認
vyos@vyos# show interfaces
bridge br0 {
address 192.168.1.100/24
}
ethernet eth0 {
bridge-group {
bridge br0
}
hw-id 00:0c:29:1a:d7:32
}
ethernet eth1 {
bridge-group {
bridge br0
}
hw-id 00:0c:29:1a:d7:3c
}
loopback lo {
}
[edit]
vyos@vyos#vyos-expr に通信できることがわかったら ssh 接続も有効にしておきます。
set service ssh
遅延
通信遅延の設定。
遅延設定を入れる前に、何もしないときの通信遅延を見ておきます。おおむね 1ms 弱というところですね。なお、最初 vyexpr2 (Windows10) の ping (Cygwin package の ping) でやったんですけど、出力が小数点以下切り捨てになるんですよね。有効数字桁数がちゃんと出てくれた方がなんとなくうれしいので host1 を使っています。
stereocat@host1:/tftpboot$ ping -c 10 192.168.1.99 PING 192.168.1.99 (192.168.1.99) 56(84) bytes of data. 64 bytes from 192.168.1.99: icmp_req=1 ttl=63 time=0.615 ms 64 bytes from 192.168.1.99: icmp_req=2 ttl=63 time=0.713 ms 64 bytes from 192.168.1.99: icmp_req=3 ttl=63 time=0.657 ms 64 bytes from 192.168.1.99: icmp_req=4 ttl=63 time=0.726 ms 64 bytes from 192.168.1.99: icmp_req=5 ttl=63 time=3.03 ms 64 bytes from 192.168.1.99: icmp_req=6 ttl=63 time=1.04 ms 64 bytes from 192.168.1.99: icmp_req=7 ttl=63 time=0.547 ms 64 bytes from 192.168.1.99: icmp_req=8 ttl=63 time=0.610 ms 64 bytes from 192.168.1.99: icmp_req=9 ttl=63 time=0.565 ms 64 bytes from 192.168.1.99: icmp_req=10 ttl=63 time=0.578 ms --- 192.168.1.99 ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 8999ms rtt min/avg/max/mdev = 0.547/0.909/3.032/0.721 ms stereocat@host1:/tftpboot$
vyos-expr に遅延設定を入れます。
VyOS でネットワーク遅延やロスを発生させるには の丸パクでそのままやります。この後のもだいたいそうです。あと、network-emulator 設定は interface outbound にのみ設定…などの話はこのリンク先を参照してください。
set traffic-policy network-emulator DELAY-100 network-delay 100 set interfaces ethernet eth1 traffic-policy out DELAY-100
vyos@vyos# compare
[edit interfaces ethernet eth1]
+traffic-policy {
+ out DELAY-100
+}
[edit]
+traffic-policy {
+ network-emulator DELAY-100 {
+ burst 15k
+ network-delay 100
+ }
+}
[edit]
vyos@vyos#再度 ping 実行しましょう。
stereocat@host1:/tftpboot$ ping -c 10 192.168.1.99 PING 192.168.1.99 (192.168.1.99) 56(84) bytes of data. 64 bytes from 192.168.1.99: icmp_req=1 ttl=63 time=100 ms 64 bytes from 192.168.1.99: icmp_req=2 ttl=63 time=100 ms 64 bytes from 192.168.1.99: icmp_req=3 ttl=63 time=100 ms 64 bytes from 192.168.1.99: icmp_req=4 ttl=63 time=100 ms 64 bytes from 192.168.1.99: icmp_req=5 ttl=63 time=100 ms 64 bytes from 192.168.1.99: icmp_req=6 ttl=63 time=100 ms 64 bytes from 192.168.1.99: icmp_req=7 ttl=63 time=100 ms 64 bytes from 192.168.1.99: icmp_req=8 ttl=63 time=100 ms 64 bytes from 192.168.1.99: icmp_req=9 ttl=63 time=100 ms 64 bytes from 192.168.1.99: icmp_req=10 ttl=63 time=100 ms --- 192.168.1.99 ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9014ms rtt min/avg/max/mdev = 100.581/100.677/100.762/0.207 ms stereocat@host1:/tftpboot$
ちゃんと host1-vyexpr1 間の通信に設定した遅延が乗っかっていることがわかります。
いま eth1 の outbound で設定したので、eth0 の outbound にも同じポリシを設定してみると、当然 200ms の遅延が発生します。
set interfaces ethernet eth0 traffic-policy out DELAY-100
stereocat@host1:/tftpboot$ ping -c 10 192.168.1.99 PING 192.168.1.99 (192.168.1.99) 56(84) bytes of data. 64 bytes from 192.168.1.99: icmp_req=1 ttl=63 time=200 ms 64 bytes from 192.168.1.99: icmp_req=2 ttl=63 time=200 ms 64 bytes from 192.168.1.99: icmp_req=3 ttl=63 time=200 ms 64 bytes from 192.168.1.99: icmp_req=4 ttl=63 time=200 ms 64 bytes from 192.168.1.99: icmp_req=5 ttl=63 time=200 ms 64 bytes from 192.168.1.99: icmp_req=6 ttl=63 time=200 ms 64 bytes from 192.168.1.99: icmp_req=7 ttl=63 time=200 ms 64 bytes from 192.168.1.99: icmp_req=8 ttl=63 time=200 ms 64 bytes from 192.168.1.99: icmp_req=9 ttl=63 time=200 ms 64 bytes from 192.168.1.99: icmp_req=10 ttl=63 time=200 ms --- 192.168.1.99 ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9011ms rtt min/avg/max/mdev = 200.620/200.704/200.761/0.531 ms stereocat@host1:/tftpboot$
パケットロス
続いてパケットロスの設定にいきます。
set traffic-policy network-emulator LOSS-50 packet-loss 50 set interfaces ethernet eth1 traffic-policy out LOSS-50
遅延設定に続けてやったので
- eth0 out: delay 100ms
- eth1 out: loss 50%
となっている点に注意です。
vyos@vyos# show interfaces
bridge br0 {
address 192.168.1.100/24
}
ethernet eth0 {
bridge-group {
bridge br0
}
hw-id 00:0c:29:1a:d7:32
traffic-policy {
out DELAY-100
}
}
ethernet eth1 {
bridge-group {
bridge br0
}
hw-id 00:0c:29:1a:d7:3c
traffic-policy {
out LOSS-50
}
}
loopback lo {
}
[edit]
vyos@vyos#再度 ping 実行してみます。
stereocat@host1:/tftpboot$ ping -c 100 192.168.1.99 PING 192.168.1.99 (192.168.1.99) 56(84) bytes of data. 64 bytes from 192.168.1.99: icmp_req=1 ttl=63 time=100 ms 64 bytes from 192.168.1.99: icmp_req=4 ttl=63 time=100 ms (省略) 64 bytes from 192.168.1.99: icmp_req=89 ttl=63 time=100 ms 64 bytes from 192.168.1.99: icmp_req=91 ttl=63 time=100 ms 64 bytes from 192.168.1.99: icmp_req=92 ttl=63 time=100 ms 64 bytes from 192.168.1.99: icmp_req=94 ttl=63 time=100 ms 64 bytes from 192.168.1.99: icmp_req=95 ttl=63 time=100 ms 64 bytes from 192.168.1.99: icmp_req=96 ttl=63 time=100 ms 64 bytes from 192.168.1.99: icmp_req=97 ttl=63 time=100 ms 64 bytes from 192.168.1.99: icmp_req=99 ttl=63 time=101 ms 64 bytes from 192.168.1.99: icmp_req=100 ttl=63 time=100 ms --- 192.168.1.99 ping statistics --- 100 packets transmitted, 51 received, 49% packet loss, time 99322ms rtt min/avg/max/mdev = 100.560/100.734/101.324/0.341 ms stereocat@host1:/tftpboot$
100 発なげてほぼ 50% のパケットロスでした + 片側でのこした遅延の設定もそのまま有効になっていることがわかります。
帯域制御
いったん遅延やパケロスの設定は外します。
帯域測定については、今回は iperf を使いました。
- vyexpr2 (Win10): iperf 2.0.5 on Cygwin (iperf client)
- vyexpr1 (ubuntu): iperf 2.0.5-3 (iperf server)
という組み合わせで行きます。
まずは何も設定しない状態での測定。
stereocat@vyexpr2 ~ $ iperf -c 192.168.1.99 ------------------------------------------------------------ Client connecting to 192.168.1.99, TCP port 5001 TCP window size: 208 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.1.20 port 56689 connected with 192.168.1.99 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 1.09 GBytes 939 Mbits/sec stereocat@vyexpr2 ~ $
1Gbps近く出ました。いやまあ、間のリンク全部 1Gbps だからなのですが、でも VyOS Bridge とか挟んだ割にはそれなりに出ましたね…。
帯域制御設定を入れてみます。
set traffic-policy network-emulator BANDWIDTH-100mbps bandwidth 100mbit set interfaces ethernet eth1 traffic-policy out BANDWIDTH-100mbps
設定や単位についてはこの辺も参照してみてください。
- VyOS traffic-policy 設定 〜 bit/Byte単位指定 | blog.ebiken.me
- VyOS で作る帯域制御可能なネットワークと NAT 経由の外部アクセス at SE の雑記
再度帯域測定を実行してみます。
stereocat@vyexpr2 ~ $ iperf -c 192.168.1.99 ------------------------------------------------------------ Client connecting to 192.168.1.99, TCP port 5001 TCP window size: 208 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.1.20 port 56814 connected with 192.168.1.99 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 115 MBytes 96.6 Mbits/sec stereocat@vyexpr2 ~ $
ちゃんと 100Mbps 弱くらいの値になりました。
まとめ
VyOS で L2 Transparent なネットワークエミュレータが作れました。まあ精度とか性能とかでどこまで保証できるのか、というのはともかく、ちょっとした実験であればすぐ使えるんじゃないかと思います。これ、思いつきでちょっと試してみようと思って数時間ですよ…凄いお手軽。このお手軽さでこれだけできるんだからありがたいことです。
