フィルタ型ルーティングの設定冒頭にも書きましたが、YAMAHA ルータのフィルタ型ルーティング機能を活用することで実現ができました。 UDP: 500, 4500, 1701 の通信のみを PPPoE にルーティング、それ以外は DS-Lite へルーティングする設定です。 ip route default gateway tunnel 2 gateway pp 1 filter 500001 500002 500003 ip filter 500001 pass * * udp 500 * ip filter 500002 pass * * udp 4500 * ip filter 500003 pass * * udp 1701 * // pp 1: IIJmio PPPoE 接続 // tunnel 2: transix DS-Lite 接続 上記で指定した UDP: 500, 45

仮想 I/O の高速化手法についてまとめました。特にネットワーク I/O の高速化について調べました。 デバイスの仮想化 仮想マシンが利用するネットワークカードは多くの場合、QEMU のようなエミュレータによってエミュレーションされており、物理的なネットワークカードとのやりとりはホスト上で動作する仮想スイッチを介して行われます。*1以下に構成を図示します。 エミュレートされるデバイスは Intel の 1Gbps NIC 等、実際に存在するネットワークカードと、virtio-net のような、物理的なハードウェアが存在しないインターフェースがあります。 仮想化技術は大きく「完全仮想化」と「準仮想化」に分類されます。*2 完全仮想化によってゲストへ提供される環境は、ゲストからは、現実に存在する物理ハードウェアと全く同じように見えるようエミュレートされます。結果として、ゲスト OS は、仮想化

割り込みタスクの対応にかかっている時間の割合を計算すると，どれくらいばたばたしているか計測できるのではないか たとえば，1日のうち，その日にやってきたタスクをやるのにかかった割合が1.0なら，完全にその日暮らしをしていて， 朝なにが起きるかまったく予想できない状態で出社していることになる その日にやってきたタスクにかけた時間が0.0なら，前日までに予定したタスクを進められていて，計画に沿って進められている たとえば，1週間みたいな単位で，毎日その日にやってきたタスクをやっているなら，毎日予期せぬことをやっているということで，長期的に計画を立てて動くことは不可能 新たなタスクが，すでに進めているタスクの緊急度を上回ることがないとき，手持ちのタスクを進めることができて，安定した状態．タスクをキューにして扱えるので順番に処理できる 新たなタスクが既存のタスクの優先度を上回るということは予想外のこ

Kubernetes Meetup Tokyo #10 2018.03.08 https://k8sjp.connpass.com/event/76816/

SynQuacer DevBoxで遊んでいる。 24コアARMでのmakeは十分に早いのか、誰もが気になる所なので、実験してみた。 Xeonと比較してしまうのは卑怯だ、という声もありそうだけども、気持ちとしては、 ネイティブARM開発環境を標榜するDevBox上でのビルドが、Xeon上でのクロスコンパイルよりも遅いなら、買う価値無くね？（Xeon使えばいいじゃん） という事です。 まあXeonが勝つ事は予想できるんだけど、大敗北になるか、僅差になるかで考え方は変わると思うので。 僅差ならば、クロスコンパイルコスト（ホストへのデータ転送コストに加えて、クロスコンパイル環境のセットアップコストや、それ用のビルドスクリプトを書くコスト等も含め）が上回って、DevBoxいいじゃん！ってなるわけです。 検証環境 SynQuacer Open DevBox sp.chip1stop.com 構成は完全

IPv6 link-localアドレス上でのIPv4経路交換とBGPピアの自動発見 前回の構成ではIPv6でオーバーレイするため、ユニークとなる様に管理された32-bitのルータIDとは別に、各ノードでLoopbackに対するIPv6アドレスの割り当てが必要となっていました。ルータIDとして利用される値をそのままトンネル終端用のアドレスに転用できれば、ノード固有のIPv6アドレス設定は省略することができます。また、IPv4・IPv6のサービスが主となる場合においては、オーバーレイを併用せずに構成できた方がよりシンプルです。 IPv6のコアに対してトンネルを介さずにIPv4の到達性を確保する場合、保持するIPv4 Prefixに対してIPv6 Next Hopが関連付けられることになるため、それに対応した実装が必要となります。具体的には、上記の経路を生成し交換できること・該当するFIBおよび

IP Fabricに関する情報 IP Fabricの動向や構成技術に関しては、解りやすく整理された資料が多く公開されています。検索で上位にヒットすると思われるものを中心に、関連する資料と併せて、末尾にURLを記載致しました。本コラムの前段階となる情報として、ぜひご参照頂ければと思います。 改めて触れておきたい点として、IP Fabricが収容対象のホストもしくはCE機器に対して提供可能な接続性（以下、単純にサービスと表現することがあります）にはバリエーションが存在し、それに従って利用される技術も異なることが挙げられます。IP Fabricを大別すると、接続性の要件がレイヤ3だけである環境に対して通常のIPルーティングとレイヤ3転送で実現するパターン（図1）と、レイヤ2接続やテナント分離などが要件にある場合にオーバーレイ技術を併用して構成するパターン（図2）となります。 図1：IPルーティン

HOMENOCでは第9回ICTトラブルシューティングコンテスト（以下ICTSC9）に接続提供を行いました。ICTSCへの接続提供は毎回恒例になっているのですが、毎回何か新しい取り組みにチャレンジしようということで取り組んでいます。今回は「ダークファイバを用いた光波長多重通信とBGPフルルートの提供」を行いました。 【ICTSC初の対外接続10G + BGPフルルート + 経路冗長化！】 ICTSC9ではインターネット接続をHome NOC Operators' Group (AS59105)様に提供して頂いております。 大阪のPOPとダークファイバを用いて10Gで接続、東京のPOPとEtherIPトンネルを用いて1Gで接続しております。 #ictsc pic.twitter.com/BZOuTuiin4— ICTトラブルシューティングコンテスト (@icttoracon) 2018年3月2

研究室内で行ったKubernetesハンズオン資料です。 対象者はKubernetesに触り始めたばかりの人の資料なので、永続化などは範囲外となっています。 また、概念などについてはあまり詳しく触れていないので、他の記事やKubernetes公式のドキュメント等を参考にしてください。

Hacker Tackle 2018 発表資料

Not your computer? Use a private browsing window to sign in. Learn more

巷ではIntel, AMD, ARMを巻き込んだCPUのバグ "Meltdown", "Spectre" が話題です。 これらの問題、内容を読み進めていくと、コンピュータアーキテクチャにおける重要な要素を多く含んでいることが分かって来ました。 つまり、このCPUのセキュリティ問題を読み解いていくと現代のマイクロプロセッサが持つ、性能向上のためのあくなき機能追加の一端が見えてくるのではないかと思い、Google, Intelの文献を読み解いてみることにしました。 が、私はセキュリティの専門家ではありませんし、過去にデスクトップPC向けのような大規模なCPU設計に参加したこともありません。 あくまでコンピュータアーキテクチャに比較的近い場所にいる人間として、この問題の本質はどこにあるのか、可能な限り読み解いていき、現代のマイクロプロセッサが持つ高性能かつ高機能な内部実装について解き明かしていき

We have discovered that CPU data cache timing can be abused to efficiently leak information out of mis-speculated execution, leading to (at worst) arbitrary virtual memory read vulnerabilities across local security boundaries in various contexts. Variants of this issue are known to affect many modern processors, including certain processors by Intel, AMD and ARM. For a few Intel and AMD CPU models

Goで始める、すこし低レイヤのプログラミング入門。入出力、ネットワーク、メモリなど、現実の世界でプログラムが動くために必要な機能をプログラム言語Goを通して覗いてみよう。OSの機能とは何か、それをプログラミングでどう利用するのか、システムプログラミングの世界をプログラマの視点から眺めていく連載企画。 2017年06月21日 17時00分 プログラミング＋ Go言語によるプログラマー視点のシステムプログラミング 第20回 Go言語とコンテナ 本連載の最終回。この連載ではプログラムがコンピュータ上で動くときに何が起きているのかをGo言語のコードを通して覗いてきました。今回はその締めくくりとしてコンテナについて紹介します。 2017年06月07日 21時30分 プログラミング＋ Go言語によるプログラマー視点のシステムプログラミング 第19回 Go言語のメモリ管理 ソフトウェアにとってメモリは不

以前のエントリー*1で、netmap API を使ったアプリケーションを作成する方法やデータ構造についてとりあげました。今回は少しレイヤーを下げて、カーネルのどのような機能を使って、netmap API が作られているのかについてまとめました。 Linux カーネルハックを始めてみたいけれど、何から手をつければよいかわからないという方にとって、netmap で使われているカーネルハックの方法について知ることは、とても良い導入の一つだと思います。 Linux カーネルハック netmap は、キャラクタデバイスのカーネルモジュールとして実装されています。今回はキャラクタデバイスのカーネルモジュールで何ができるのか、ということと、netmap がそれらをどのように使っているかについて説明します。 カーネルハックで、Linux カーネルに新しい機能を追加する場合に、カーネルのソースコードを直接変

はじめに 本記事はLinux Advent Calendar 2017の最終日、25日目の記事です。 みなさんはWindows Subsystem for Linux(WSL)というWindowsのソフトウェアをご存知でしょうか。これはUbuntu, openSUSE, あるいはSUSE Linux Enterpriseという3つのLinux distributionをWindowsから使えるという機能です。Microsoftストアから無償でインストール可能です。低レイヤの細かいところ(/procや/sysのファイルが少なかったり、ほとんどのデバイスファイルが無かったり)は違うのですが、おおよそ通常のLinuxディストリビューションと同様に使える優れものです。 本記事は、Linuxソフトウェア開発環境という目的に絞って、WSLと、Windows上で動作するVirtualBoxにインストール