VyOS Users Meeting #3 参加メモ

memo

VyOS Users Meeting Japan #3 に参加してきたのでいつものメモです。例によってLTについてはメモ取ってません。

開会

ギークナビとは?

I have a VyOS, I have a SoftEther

いしばしさん/ギークナビ

Yamahaルータを使ったVPNサービスとかを仕事でやってる。

AWS標準VPNではなくてvyosをつかっている

  • やすい
  • 接続時ログとかが取れる
  • 使い勝手が良い

仕事で使うリモートアクセスVPN

  • CiscoASA をよくつかう
    • でも高い
    • AnyConnect等の使い勝手が…

VPNなんだからリモートアクセスもvyosでもいいんじゃないか

  • VyOS: できんかった（同時接続が1になる?)
  • SoftEther
    • あわせてしまえばいいのでは

拠点間はVyOS, リモートアクセスはSoftEther

クラウドへのアクセスも含めて VyOS/SoftEther でできるのでは?

Demo

  • AWSでVyOSを起動
  • debian repos 追加
    • "apt install build-essentials git" とか
  • softether のダウンロード
  • softether のインストール
  • softether server の設定
  • AWSの場合セキュリティグループ設定も。
  • softether server-manager/client から接続

本当はこうしたかった

  • L2TP over IPSec つかえば windows 側に vpn client いれなくても
    • ただ、拠点間VPNのIPSecと競合しちゃうので、vyos側でNICわける
    • が、うまくいかず

QA

  • キャパシティ・性能
    • いまのところ t2.micro で試している。性能・キャパシティ的なお試しはこれから。
    • クラウドなので拡張性は。
  • VTIだと拠点間VPNとリモートの接続できなかったよ
  • 接続機器
    • Ciscoとか。Fortiはやってない。

Troublesome at vyos on aws

かみたさん/ギークナビ (急遽代打)

Trouble1: VyOSのVPN接続が切れる

  • 複数拠点とのVPN接続でVPNが切れる
    • 切れる。あるけど通信できない。あるけど通信できず経路なし。などなど
    • 回避策: keepalive等を入れて迂回
    • 回避はできるようになったので原因調査中

Trouble2: VyOSのディスク容量圧迫

  • auth.log の肥大化 (接続拠点が多いのでログがでかい)

Trouble3: AWSでのVyOS構成

  • AWS VPCの使用上、192.168.0.0/16をVPC内部ルーティングしようとする

AWSと複数拠点間でのBGP冗長化構成について

ふじいさん/ギークナビ

拠点間接続/dynamic routing の話をやってた

  • 今の会社はstatic routingだいすき
  • vyos はまだはじめたばかり

Cisco/VyOS接続検証

  • VyOS on AWS で対向はCisco(1812, ISR4331)で拠点間VPN
    • 1対1では問題ないけど複数拠点つなぐと通信できなくなる障害
      • VTI Interface が admin/down になる →まだ原因がつかめてない
    • Workaround: VTI Interface reset ("run reset vpn ipsec-peer") をping lossをトリガに自動実行

全部VPNじゃなくて、2拠点だけにしてdynamic routingで迂回いうのは?

  • bgp, 通常経路と迂回経路で使い分け
  • 拠点追加の増減で設定変更するのも面倒だよね
  • route map による制御とかの話はまだこれから

VyOSとLXCと僕

@gentaさん

JSONを投げると雲の中にルータが爆誕するやつの話

LXCとは?

  • 「コンテナ」をLinuxで実現する
    • VM: Kernel部分のオーバーヘッド
    • コンテナ: Kernel部分のオーバーヘッドがない分高密度に収容できるように
  • Linuxの提供するリソース分離機能を使う
    • 頑張ると、mount point は別なのに見えるNWインタフェースが見える、みたいなちょっと変なものもできる。
  • LXC: 簡単に仮想環境みたいのができる。VMたくさん並べるよりもいっぱい詰め込める。

それでVyOSうごかしてみよう

  • VyOSをひとつのVMの中でたくさん動かしてお金を減らしたい
    • ユーザが増えたらそれなりにスケールするようにしたい
    • それなりにいろいろできるようにしたい

構成

  • vxlanベース: VTEPはホストOS側で。
  • コントローラにjson投げるとコントローラがvyosをホストOS上に立てていく
    • 12RPM(Router per Minutes)

特徴

  • LXCを直接たたくので軽い
  • 網構成はコンテナ内ネットワークで割といろいろおやれる
    • vxlan id ごとにブリッジを作ってvethでVyOS(container)につなぐ

ストレージ構成

  • 普通にやるとCD1枚分くらいある。たくさん作るときついので、Overlay FS で実装。
    • Clone しても zero copy (mount point 操作のみ), ログとか書き込まれたら差分だけ別ディレクトリに入れる。

フロー

はまったこと

  • LXC由来の問題は今のところほとんどない
  • bind mount:
    • VyOS起動時: /config → /opt/vyatta/etc/config とかを bind mount してる。
    • 落とした時に umount してない
    • LXC の hook script で回避
  • start-stop-daemon
    • debian の start stop script がへぼくて killall とかやる…
  • overlayfs + VM Snapshot の問題

まとめ

  • 「意外と動いている」
    • マニアックな機能テストはしてないけど
  • コンテナごとにbgpdが増えるのが地味につらい
    • bgpdでnetns対応してVRFみたいに動いてほしい

なぜVyOS?

  • PCルータを手軽に使う
    • 設定ノウハウの蓄積…config generatorの部分だけ把握して、VyOSじゃなくてふつうのlinux上の話でいいんじゃ…
  • お客様との責任分界点

QA

  • LXC wrapper みたいので LXD というのが。そちらはためした?
    • 作った後に出てきて、気にはなっているけど調べられていない。便利機能があれば、と思うけど。
    • ストレージバックエンドをZFSにできる。overlayfs のスナップショットのところはZFSに任せられるのでは
  • コンテナ内プロセス、NTPとか動作がkernelに依存するプロセスはどうする?
    • ホスト側起動するときに事前にinsmodして合わせる…kernel環境はvyosから見て一緒になるように合わせる。

vyos-buildでつくるカスタムVyOS

@m_asamaさん

VyOSのカスタムイメージを作る

vyos-build

  • あたらしいvyos install imageを作るための仕組み
  • 1.1.7まではdebian/squeezeベース。1/2からはjessyベース。
    • 1.1まではbuild-iso → 1.2からはvyos-buildでインストールイメージを作る
    • debian-live がベースになってる。

ISOイメージ作る流れ

  • debian jessie 環境をつくる
  • git clone vyos-build
  • git checkout -b current
  • README読む
  • 必要なdeb packageいれる
  • configure && make iso

カスタマイズする場合

  • vyos-build/packages に deb file をおいてから make iso (2015/12/22からの機能)
  • vyatta-* vyos-* の修正
    • git submodule update --init packages/vyatta-cfg とかをやる
    • current checkout
    • 修正
    • fakeroot make: packages に deb が書き出されてれば make isoではいる

カスタムカーネルに差し替えたい

  • ビルドの仕方がよくわからない。ドキュメントも見当たらず。

今後

  • 1.2でjessieベースだけど、CLIとかはそのまま
  • vyos2.0とかからは、vyatta-cfg-*, vyatta-op-* とかがスクラッチのものに変わるといわれている。

余談

VTIが落ちる話 : http://bugzilla.vyos.net/show_bug.cgi?id=183

  • admin downしてなぜかupしない
    • strong-swan の中で、IPsec SA焼失したときにinterface落とすような設定がある。
    • vyatta static route で interface route 設定できる。これでnext hopしているとき、経路切り替わるように、interfaceもおとす。
  • ときどき route-client で上がらないのがある。up-client もつかう
    • ほかのところでも問題が、というコメントがあっておいといたらrevertされちゃった。
    • 1.1.7だおこのパッチでよくなるかもしれない。このパッチで安定しているところがあるのであてたほうがいい。
  • IPsecのSA切れる理由
    • DPD(dead peer detection)でheartbeatとかが死んでるなって時にSA落とすケース
    • DPD生きてるけどIKE鍵交換がうまくいかない(回線品質悪いとうまくいかないケースがある気配)
      • パケロスが多いところで頻繁におこるかも

最近のVyOSの様子 2017/01

@higebuさん

Webサイトとかシステムが変わりました

  • 公式HP, 開発ブログ
    • BTS(bugzilla→fabricator): 重要そうじゃないのは移行されてないみたい
  • RocketChat を自分たちでホスティング
    • 日本語channelもある
  • Forum
    • 各言語(日本語も)のフォーラムができた

1.2/2.0とかいつでる?

  • 公式Blogをみましょう : "Change is coming to VyOS project"

次のバージョンについて

  • 1.2
    • build-iso → vyos-build (debian live base)
    • Jessieベース + いろんなパッケージを新しく (新しくしたら壊れてるのもある)
    • テストがんばるしかない(使う機能が動けばいいや…というながれ)
  • Perl scriptしんどい → python に統一しようという流れ
    • コーディング規約とかもでてる。
  • 2.0
    • vyconfがOCamlでかかれてる (バックエンドなので普通の人は触らない)
    • コマンドテンプレートがXMLに
    • コンフィグのスキーマが変わりそう。古いのもサポートはしそうだけど。fabricatorで投票している。
    • 内部APIが protobuf に
    • ベースOSも見直しそう
    • Web UI Project も
    • development digest を読みましょう

自分が最近やっていること

  • vyos-buildにいろんな仮想環境用のスクリプトを足している (packer based)
  • vyos-cloudinit
    • EC2だけcloudinit的なのがある。いろんなところで動きそうなのに書き換え中
  • vyos自体のテスト


所感。

とりあえずみんないろいろやってみてはまったところの話であーそれ見たみたいな話がわらわらっとあがってるのをみると、やっぱりこういうミーティングとかは有用なんだなあと思う次第であります。開催自体は有志によるベストエフォートだからなかなか定期的にやるのも難しいというのはわかりつつ。平日昼間開催でキャンセルは入ったもののそれでも20-30人くらいは参加者がいるというのを考えると、やっぱりそれなりに関心がある人が多いんだなあ、とおもったのでした。あと、LTネタあったのを全部終わった後にああそういえばアレがあったなとか思い出したりしたので、ネタの収集/吸い上げという意味でもそれなりに定期開催されるのがいいんじゃないかなーと思いました。自分でやったことを忘れている…。

NetOpsCoding #4 参加メモ

memo

NetOpsCoding #4 に参加してきたのでいつものメモです。公開資料などについては atnd のページを参照してください。

ネットワーク機器運用自動化の傾向と対策, Fixpoint/服部さん

Kompila

  • 定型的な処理を「ジョブフロー」として登録しておくことで自動実行でいる
    • bash, ruby, python, なども
    • パラメータをWebから入力してフローをキックとかもできる。

今回手伝ったNW運用自動化(運用チーム)のしごと

  • 日々いろんな作業依頼がある

現状の運用

  • いわゆる「ガチガチ」な運用
  • アプリ開発者 → NW運用チームに作業依頼(メール)
  • NW作業担当者は依頼内容に基づいたExcelで作業手順書作成 → 責任者レビュー・承認リレー
  • 承認が下りたら作業実施 → 作業担当者へ手順書を渡して実行

毎回同じような手順書書かないといけない。実際の作業は手作業なので入力ミスや誤設定とかのリスクがある。

スクリプト実行で自動化だ!

  • 作業担当とかみんなノンプログラマ
  • 簡単なスクリプトと行ってもプログラム書くハードルが高い。
  • 責任者もノンプログラマなので、プログラム見ても判断が難しい。

ノンプログラマがやりやすい手順書みたいなのってないか?

  • YAML手順書へ
  • 日本語キーワードで可読性をあげる
  • キーワードの表記揺れに対応する

Kompiraによる自動運用

  • Excelのかわりに YAML 手順書
  • 承認リレーとかは従来通りにしてある
  • 作業実施は Kompila がYAML手順書を自動実施する。

実行の流れ

  • parse
  • パラメータのチェックとか手順書の内容が意味的に合っているかどうかをいまの設定情報を元にチェック。
    • 今のコンフィグ情報を取ってきて、YAML手順書のパラメータの整合性チェック。存在しないオブジェクトの参照や二重登録など。

自動化システム実現の際にあたった壁

  • CLIの壁
  • Telnetの壁
    • Telnetでしかアクセスできない機械がある
    • expect script
    • 踏み台の処理
  • 冗長構成の壁
    • 機械によっては active 側にだけコマンド入れるモノがある。どっちがActiveなのかを判断して動かないといけない。
  • 設定リカバリの壁
    • 間違えたときに切り替えたい、というのが発生する。
    • リブートさせたくない
    • コマンドを取り消すコマンドを入力する…

CLIの壁

  • SSG: get config → shlex で字句解析
  • コマンド生成: YAML を解析して構文木 → トラバースしてコマンドを生成

Telnetの壁

  • 実行したコマンドの結果とプロンプトの区別がない。
    • コマンドが終わってプロンプトが出てからコマンド入れないといけない。
    • コマンドによってはプロンプトが変わる
    • プロンプトが出る前にエラーメッセージが出ることがある。
    • エラーメッセージハンドリングは地道にやるしかない。
      • expect script が秘伝のタレ化…

冗長構成の壁

  • Activeにだけコマンドを来る。ログインした上で状態チェックをする。

設定リカバリの壁

  • 誤投入に対して元に戻したいけど、リブートするのはいやだ
  • 逆コマンド実行をする。
    • 投入したコマンドから逆コマンドが特定できるとは限らない
    • 設定差分(diff)から逆コマンドを生成する。
  • 単純に diff とれれば良いわけではない…

まとめ

  • Kompila でNW運用自動化システムを
  • 実際に現場で使うには、細かい処理を入れ込まないと行けなくて非常に面倒くさい。
  • 今のところ銀の弾丸はない
    • 地道にやるしかない
  • 自動化することで、手作業より確実にオペレータ工数削減はできる。

QA

  • 構成管理
  • YAMLのモデル、スキーマ?
    • つくってない。入れられるパラメタは決めてあるけど。
  • 機械のバージョンによって文字列パースが違ったりする。DB内とつらいんじゃない?
    • たぶんきつくなる。いまのところ、新しい機器に対してやるときは事前に動作チェックを屋って、処理追加を入れていって対応させる、という方向。

構成管理DBをGitで管理したいネットワーク管理者の憂鬱, internet Multifeed/川上さん

Internet Exchange とは?

  • 平たく言うとL2スイッチがある。
  • 各社がBGPルータをつないで、経路交換をして、トラフィックを交換する。
  • 100くらいの顧客(AS)がつながってる

NagiosやMRTGの設定を自動生成

  • 設定作業
    • プロビジョニング、開通作業、バックボーン作業(影響がある・ない)
  • いままで手作業
    • コンフィグファイルが非常にわかりにくい。不幸な人為ミスのオンパレード, 開通作業に5時間かかる…とか。
    • DBから自動生成したい。

どういうデータベースを?

  • RDB, Text, NoSQL, Other(Excel?)
  • 自分たちの運用方法や文化にあった技術を選ばないと、現場が崩壊してしまう。
    • 運用を無視したツールファーストはNG

例: スイッチのファームウェアアップデート

  • 設定変更手順
  • オペレーション
    • 作業者+確認者の2名体制
    • サーバ系設定
      • 各ステップのコンフィグは前日までに確認・承認しておきたい
      • 全体の作業内容は変化があるので、コンフリクトが起こる可能性がある。衝突が起きたら回避できるような仕組みじゃないといけない。

DBがRDBだったとすると…

  • コンフリクトに気づけないといけないし、気づいたら担当者が変えられないといけない。
    • SQLとかまでやるのはハードルが高い。生SQLとかやらないでしょう。モデルやインタフェースのオブジェクトをどう考えるか?
  • WebUI?
    • WebUIの手順書は書くのが大変。その通りに行われる保証がない。
    • 実装コストが高い…
  • rails console?
    • つらい

Gitならなんとかなるんじゃない?

  • 運用者が読み書きしやすい・機械処理ができる・バージョン管理できる。
    • ファイルなので誰でもいじれる。(中身はYAML)
    • 意味のあるコミット単位
    • ブランチを切ってコンフィグを作れる
    • ssh + git pull でデプロイできる

ワークフローの変化

  • 作業用ブランチ → テキストでコンフィグ → レビュー
    • 差分確認、コマンドの確認を担当者がやれる。入力するコマンドのチェック。
  • メンテナンス前に担当者が rebase して変更停止(master freeze)
  • 作業実施後に branch 削除

2年半くらい運用している

  • YAML, git にカンするトラブルは特になし。
    • どっちかというと人為ミス。typoとか。
  • Good
    • ブランチ斬る運用
    • 意味のある単位でのコミット、差分によるダブルチェック
  • Bad
    • オブジェクト管理レーションが相互参照
      • pry debug がつらい
      • stack trace がおもい
    • git pull デプロイに時間がかかる
      • gitlab のパフォーマンス
    • プログラムからDB変更する

運用自動化の段階

  • phase.1, スクリプトにパラメタ渡して人が実行
  • phase.2, DBから全部コンフィグ作って機器にデプロイ
    • 機器側にコンフィグリロードの仕組みがないといけない
  • phase.3, イベントドリブンで必要なコンフィグ差分を機器に投入
  • YAML をもとにしているとつらみ
    • コメントは消える
    • 人が書いたモノと出力されるモノに違いがある
    • 人の編集とシステムによる編集のコンフリクト…

phase2→3

  • イベントごとにコンフィグ全生成というのはつらい
  • DBが半端に更新されているタイミングでコンフィグ生成しているとNG
    • branch 切れるDBというのもあるらしいけど (noms)

phase.3

規模

自動化実行に当たっての壁

  • 自動化のための整理

QA

  • デプロイを早くすることはやらない?
    • いまのところやってない。早くしても timing issue, デーモンリロードとかを伴うというのもある。早くはしたいけど。いま時間がかかる理由→ MRTGが5分間隔で動く。バックアップ側デプロイ→確認→メイン側デプロイ。過去、MRTGデプロイでバグを踏んでCPU食って死ぬ、というのがあって、サーバ側正常性の確認を入れている。そこの運用をあきらめられるのであれば2秒デプロイみたいなのも検討したいが。

LT

例によってLTについてはメモを取っていません。いくつか思うところや感想などを。

  • スマホのセンサーでネットワークを操る
    • スマホを振ったら Ansible Tower をたたいて経路変更 → 振った方向へ経路を切り替える。
    • LTでは残念ながらでも環境への接続が上手くいかず…
    • 懇親会で動くところを見せてもらえました!
    • デモ動画ができてた!

  • NetTesterで物理ネットワークのテストをプログラム!
    • あとで fixpoint の方とちょっと話をしたんだけど、感じている課題感や直面している課題はもうそのままですね。いろんなアプローチでどうにかできないかを試していけると良いと思います。
  • イベント紹介: TremaDayってどんなイベント?

感想

どれも何かしらの実装やコーディングの話が出てきて、具体的な話に突っ込んできているのが良かったなあと。まあその分泥臭い話も多めではありました…。最初の、fixpoint さんの取り組みとか、LTの "そろそろSSH/Telnetを離れて" の話ともそうなんだけど、このCLIベース自動化の話の泥沼からどうにか抜けたいところだなあ、と。あのへんの自動化実装の泥沼加減がわかりすぎるので


というツイートをしてしまいました。Ansible とか、いろんなツールややり方がいろいろ試してみるのはイイと思うんだけど、ちょっと気になるのは、こういうのをやるための地道な作り込みをどうもみんな何かしら再発明しているような気がするところかな…。いや、自分も最近ちょっとやってたというのもあるからなんだけど。APIで操作可能なガワを用意しても結局中身のCLI処理回すところの仕掛けやナレッジは自分で頑張らないといけないのがつらいなあ……とかね。プロンプトの正規表現作るとか、エラーメッセージ調べるとかのあれこれが超しんどい。何かこの辺をもうちょっと共有する・共通化するようなものがあればなあ、と思いました。

Trema Day #9 参加メモ

memo

Trema Day #9 に参加してきました。いつものメモ公開です。(LTはメモ取ってません。) 各発表の資料は Connpass に公開されると思いますのでそちらを参照してください。

まあ今回もなんと申しますか、よく言えばバラエティ豊かと申しますか。これだけニッチで雑多な話題が集まるのもそうそうない気がしますね。

NetTesterで物理ネットワークの受け入れテスト(@yasuhito)

  • 物理ネットワークのテスト
  • ネットワークの話を聞くと、みんなとても大変そう。
    • 某所のテスト風景
    • 手作業、現場に行って現物を操作しないとテストができない。
  • これをなんとかリモートで、現物持ち込まなくてもテストできるようにしたい。

たとえばFWとかをテストしたい

  • 通信するノード(サーバ・クライアント)、最低2台おいてパケットを送らないといけない
  • 項目も爆発: いろんなIP,ポートでテスト、機器もいるし組み合わせもたくさんある。

NetTester

  • しくみは単純
    • LinuxマシンとOFSを用意する。
    • テスト用のノードはLinuxマシン上に仮想的に用意する(netnsとか)
    • それをOFSを使って、テスト対象の機会につないであげる
    • つなぎ方、ノードの増減も何とでもなる。ソフトウェア的に操作できる。

NetTesterの特徴

  • シナリオの書き方で工夫
    • cucumber/受け入れテストのツール。
    • よくWeb屋さんとかで受け入れテスト(blackbox test)とかで使われている。振る舞いの記述のための言語とフレームワーク。ユーザがたくさんいる。
    • それをネットワークのテストでも使えないか。

テストの時に考えること

  • テストツール、周辺のツールはたくさんある。充実しているので、それらはなるべくそのまま使いたい。
    • 代表的なのは cucumber, rspecなど
    • テストの手法もいろいろある。
    • 自動テストの仕組みもいろいろある。CIとかも。

すでにあるツール・知見をネットワークにも適用しよう!

  • もともとテストのツール、アプリ屋さんが強い。
  • アプリ屋さんとネットワーク屋さん
    • NetTesterはそれらの間をつなぐツールを狙う
  • https://github.com/yasuhito/net_tester

NetTester

  • いまのところ、受け入れテストのツールとうたっている
  • ゆくゆくは、設計フレームワーク。
    • ネットワーク設計の時の助けになるツール
  • TDD
    • テストの結果から、ソフトウェアの設計を直していく。テスト書いていてAPIが使いにくいならAPIをリファクタリングする、というフィードバックをかける。テスト、設計、またテスト、というサイクルを回して元の設計をよくする。
    • それをそのままネットワークでもやりたい。

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?

プラクティス

  • RasPIにgoBGPを載せて、USB NIC足して環境を作った。
  • Juniper SRXをBGPルータに
  • Buffalo (OpenWRT + Quagga)でBGPルータに

コンフィグの一元管理

  • とりあえず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で、というのを考えた。

コントローラのプログラミング量が結構多そう

結局何ができるのか?

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

アーキテクチャ

使い方

  • 電源兼シリアルなのでUSBシリアルから設定
  • telnetもできるようになる予定

CLI

ファームの書き込み

  • SMB-BAをつかってUSBシリアルで書き込み
  • 最初の頃のファーム、コンパイラ荒い面とについてのところがナイーブに実装されててうまく動かないやつがあったり

ベータテスタ枠

  • ベータ、実はたいした作業できていない。むしろ今から本番

ベータボードとプロダクションボードの違い?

  • そんなに違いがない。

開発環境

  • 開発しようぜ!
  • Atmel Ice debugger
    • SOCに直結してステップ実行とかできるようになる。
    • 事実上必須
  • github
    • OSS運営自体もあまり経験がないみたい。一般的な流儀とちょっと違う。

開発中の注意

  • 温度
  • あまり触らない
  • 電源ノイズ

ソフトウェア

  • 悩んだときはAtmel の SOCの開発環境そのまま、Atmelのサンプル探してもってく売ると動く、みたいな感じ。
  • いわゆるOSはない。

Logical view

実装してみた

  • いろいろ書き換えたらオリジナルをほとんど書き換え。本家にマージされず。
  • どうせマージされないし、ってことでIPv6対応まで進める
  • はじめは gcc -O0 にしないといろんなところを踏んで闇

なぜZodiac FX?

  • 極論すると whitebox switch
  • OpenWRTより簡単なフリーの開発環境なんじゃないの?
  • 自由!

無線屋はエンタープライズSDNの夢を見るか? (@t_j_baldwin)

(諸事情によりメモ取っていません)

中国にopenflowを入れてきた話 (@Clorets8lack)

中国〜日本の間の経路

  • 3重冗長[直結・上海経由・シンセン経由]のいいところを使う
    • 2重だったところにシンセン経由を追加した

導入理由

  • 基幹システムのレスポンス向上→VDI導入
    • VDIはパケットロスに弱い。(0.5%ロスがギリギリ)
    • でも、できると遅延を無視できる。
  • 国際ネットワークのBCP
    • 予算とかないんだけどでも何とか
  • 無敵のBCP!?

実際の運用の工夫

  • 今までのネットワークの形を変えずにアドオン
  • エッジのOFS,コントロール通信自体の冗長化が必要
  • debug前提で作り込が必要
    • gateway wan/lan 全部キャプチャとれるように

中国の秘密

  • キャプチャ全部取ってるので障害と化がいろいろ見えてくるものがある
  • 通信通らなくなるのは割とある
    • Great Firwall は中国の通信規制の一部
  • なにがあるか?
    • DNSポイズニング
    • 検索サービスの結果操作
    • Great firewall
    • CPEでの制御(構内ルータとかONUとか)

中国は言ったもの勝ち

  • トラブル、言ってみると治ったりする。CPE設定でやってることがあるので、証拠を出していってみると、意外と修正してくれたりする。
    • 凡ミスもおおい。気づいたら言うのが重要。エビデンスを出して、こうしろ、という話をする(「調査してくれ」だけだと動かない)
  • 時にはあきらめも必要

Enterprise国際インフラ運用

  • 予算と人手が足りない中で何ができるか?
  • 理不尽な障害が常に起きる。原因究明・再発防止のための可視化、というのが必要。

SonarMan

  • VMあるよ!