hardware, linux, 小ネタ

おはようございます。ライトノベル好きのツチノコです。ヒマワリの季節が近づいてきましたね。

さて、タイトルの通り、ONIEをbuildしました(というか何回かしている)ので日本語で手順をまとめておきます。
公式のドキュメントは https://github.com/opencomputeproject/onie/wiki/Building-ONIE です。

5月のJapan ComCamp meets de:codeでLTした、例のブンチンカッコカリからのリカバリの時にも利用しました(スライド中ではONIE関連は省略)。

前の記事はここです。間があいてしまってもうしわけないです(夏休みの宿題はためるタイプでした)

環境はDockerで作ってしまうことにします。Dockerfileは https://gist.github.com/wataken44/e5e6c7f94b257c15196d50bab9a9a2de にあります。

まずはimageをbuildします。

Dockerfileの中身は以下のようになってます。

コンテナを走らせてbuildします。

<vendor>,<model>のところにはお手元の機種名を入れます。DellのS6000-ONだとそれぞれdell, s6000_s1220になります。一覧は ~/onie/machine 以下にあります。

1時間くらいでbuildが終わり、isoイメージやpxe用のイメージができます。

あとはUSBメモリに焼くなりなんなりしてセットアップすればONIEのインストールができるようになります。
ご活用ください。

BIOS
上はDell S6000-ONのBIOS画面です。AMIのBIOSが動いていて、8GBのメモリが乗っていることがわかります。
シリアル経由ですがツチノコブログの読者には見慣れた画面ではないでしょうか。

S6000のBIOS
Boot orderを変更できる画面です。

ネットワークスイッチのBIOS画面が見れて、そこらへんのPCと同じようにOSをインストールしたりできるようになりました。すごい時代ですね。

p.s. このテンプレ展開のせいで、おれのラブコメが鬼畜難易度がすごい

hardware, コラム, 失敗談, 歴史, 雑談

注意: 読んでも時間の無駄、思い出話です。35歳未満の方はそっと閉じていただければ幸いです。

15年前 「まぁまぁ」定番のNIC

 10年、いや15年以上前の Linux。コンピュータ屋さん以外にもやっと Linux というものが認知されはじめ、流行のディストリビューションは Slackware から Red Hat Linux へ。「どうやら最近の Linux は結構ちゃんと動くらしいね」という巷での噂 …そんな頃を思い出すモノが会社の廃棄物置き場で発見され、思わず救出しました。

dec21140
DEC 21140

 もしかしてこれは DMM が東京進出した際にはじめて導入されたサーバに入っていたNICかも…?

 これは DEC の 21140 というチップが載った 100BASE-TX の NIC です。tulip というコード名のほうが通りがよいでしょうか。当時 Linux での NIC といえば、カニ(Realtek RTL8139シリーズ), 3com 3c905シリーズ、Intel PRO/100(8255x), そしてこの DEC の 2114x 系列 (tulip/de4x5) がポピュラーでした。他にもあることにはありましたが、Linux においての選択肢は多くありませんでした。

  1. Intel eepro100, 3com 3c905: 高級、ちゃんと動く
  2. DEC 21140: そんなに高価じゃない(6,000円程度と記憶) まあまあちゃんと動く
  3. RTL8139C or lator: 安価(2,000円?), やたらCPUを食う、運が悪いとNICが止まってOS再起動、カーネル刺さる
  4. それ以外: 安価、動くかわからない、カーネル刺さる

 この中で “まぁまぁ” の NIC は DEC 21140, これが定番でした。

安いNICはよくカーネルがpanicした

 安いNICはろくなことがありませんでした。CPUを食う、kernel panic で死ぬのは高負荷時とも限らず再現性が謎、速度が超遅くなる、NICの存在ごと沈黙、たまたま動いていてもカーネルをアップデートするとおかしくなるなどなど。珍しいパターンでは ネットワークに何かしら流れていないとCPUが食われてしまう(トラフィックのグラフと CPU使用率のグラフが対称っぽい形を描く)、などなど、さまざまな珍現象に見舞われました。

 FreeBSDの rl, RTL8139 ドライバのソースに「史上最低のひどいチップだ」のようなコメントが書かれていたことも話題になりました。

dec21140_2
DEC 21140 裏 (ぷらっとホーム)

 なんと、ぷらっとホームのシールが貼られています。DMM が東京進出した際のサーバがぷらっとホームの3Uのものだと聞き及んでおりますので、それに入っていた NIC でしょうか。

 tulip 互換をうたうチップはいくつか存在し(NETGEAR, ADMtek, なんかがあったような), ドライバのソースは互換チップのバグ ワークアラウンドで肥大化していた記憶があります。でも互換チップもちゃんと動かなかったような…

 この頃の PC-UNIX はメジャーな製品(≒ブランド品)しか動かず、貧乏学生のお財布には厳しかったものです。今日 2016 年 では Linux でもだいたいドライバはあるし、カーネルを巻き込んで死ぬようなものはとても少なくなりました。仮想化もあるし。何かハードウェアを買おうとする前に、Linux で動くのかどうか調べまくる人も減ったでしょう。


 ――なんて話を同年代の方々にしたら「チューリップ? そんなのあったなー」「俺は BSD だったし 21140 に特に思いdeはない」など しょっぱい反応……。そんな方々にも以下のカードはお気に召していただけたようです。

adaptec AHA-2940U2W
adaptec AHA-2940U2W

写真を撮ったあとそっと廃棄物置き場へ戻しました…。Interop 2016 でインターネットの未来を見たあと、ちょっと昔の思い出に耽っていました。
「歴史って、人類や生命全体の “おもいで” に違いないのよ」

hardware, イベント, ネットワーク

SDN/NFVサービスチェイニングのデモの中で、OpenFlowを今よりもさらに柔軟に使うコンセプトデモも含まれていました。

数年前と比べると、OpenFlowの仕様や実装が進化しているので、OpenFlowでできることは増えています。しかし、現在のOpenFlowは主にマッチと書き換えを行うものなので、直接計算は行えません(コントローラに判断を仰ぐ方法はありますが、それだとリアルタイムな処理は困難です)。

そこで、今年のShowNetではNetFPGA-SUMEとOpenFlowを使ってハッシュ計算を伴うロードバランシングを実現しています。

7

デモの内容としては、以下のようなものです。

  • イーサネットフレームは、NetFPGAを通過してからLagopusへとパケットが転送される。
  • OpenFlowで負荷分散をするための例として、送信元IPアドレスと宛先IPアドレスでハッシュして、イーサネットフレームに含まれる送信元イーサネットアドレスを書き換える。
  • NetFPGAは、ハッシュ結果を送信元イーサネットアドレス下位8ビットにマーキングをしていって、OpenFlowは送信元イーサネットアドレスの48ビットをマッチして使って転送。
  • NetFPGAに入ってくるイーサネットフレームは、上位のルータからなので、そもそも入力は毎回同じ送信元イーサネットアドレスだけど、NetFPGAが下位8ビットを変更する。

この他に、OpenFlowのフローエントリ数を減らす工夫(微調整)も行われています。

今回サーバ上で動いているVMは8台なので、3bitで全てのVMを指定できます。NetFPGAはそのまま8bitに埋め込み、Lagopusのルールは送信元MACアドレスのうちマスクを使って下位3bitのみを見ています。

8bitでは全てのパターンを指定するのに256個のフローエントリが必要になりますが、下位3bitを見るだけであれば8エントリのみで全てのVMにトラフィックを転送することができます。これによって、OpenFlowでIPアドレスをマッチして転送するのと同じことを、8個のフローエントリで実現しています。

L3な機能(VirNOS含む)が使われるときは、ARP解決のために、OpenFlowで宛先イーサネットアドレスを宛先とするL3デバイスのMACアドレスに書き換えています。

NetFPGAを使ったデモは、NOCメンバーがShowNet 2016のために独自開発されたものです。なかなかマニアックですが、こういうの大好きです。


LagopusとNetFPGA(上に基盤むき出しで乗っているのがPCIカード用給電されたNetFPGA)

hardware, イベント, セキュリティ, ネットワーク

ShowNetで行われるSDN/NFV関連デモは、年々進化しています。今年は、昨年よりも柔軟性と拡張性が大幅にアップしたSDN/NFVサービスチェイニングがShowNetで運用されていました。広帯域・高速処理が必要なバックボーンネットワークを構築しつつ、必要なトラフィックのみをSDN/NFV機器へと誘導することで、SDN/NFV機器を直接バックボーンネットワーク内に設置せずに運用しています。

今年のShowNetで行われたSDN/NFVサービスチェイニングの非常に大きなポイントは、BGP Flowspecを使ってバックボーンルータから特定のトラフィックをSDN/NFVエリアまで誘導できるようにしてあるところです。今年のShowNetでは、SDN/NFVエリアがdcwestエリアにまとめてありますが、任意のタイミングで任意のトラフィックをバックボーンからSDN/NFVエリアを経由させることができます。

1

2

SDN/NFVエリア内では、OpenFlowを使ったサービスチェイニングが行われています。ファイアウォールやDDoS mitigationを行う機器に対してユーザ単位でトラフィックを誘導できるようになっています。

3

4

5

今年のShowNetでのSDN/NFVデモは、SDN/NFV機器へとトラフィックを誘導することを目的として、通常トラフィックが通過する経路上にSDN/NFV機器を設置せずに実現できているという点が昨年と大きく異なります。

昨年のShowNet構成では、出展社などのユーザはvCPE(virtual CPE)に収容され、そのvCPEを通過するトラフィック”のみ”がOpenFlowで変更されるというネットワーク設計でした。そのために、OpenFlowで実現していたサービスチェイネイングの網自体もバックボーンから見ると下流にありました。必要に応じてサービスチェイニングを利用できるようにようするために、すべての出展社へのネットワーク提供の入り口に工夫をする必要があったのが去年の構成です。

去年の構成と比べると、今年の構成はシンプルでエレガントだと思いました。今年は、ShowNet各所でBGP Flowspecが活用されていますが、BGP Flowspec対応機器が増えたことで、サービスチェイニングを行う機器に流入するトラフィックを柔軟に制御しやすくなるので、処理能力に制約がある高機能機器も使いやすくなるのかも知れないと思える展示内容でした。

hardware, IPv6, イベント, ネットワーク

こんにちは。あきみちです。Interop Tokyo 2016取材記事第二弾です。

特定のフローに対する設定情報をBGP(Border Gateway Protocol)のNLRI(Network Layer Reachability Information)で広告できるBGP FlowspecがShowNet 2016で活用されています。

BGP FlowspecのRFCは、RFC 5575として2009年に発行されていますが、その中では、ACL(Access Control List)やファイアウォール設定を行うために使うという用途が紹介されています。

BGP Flowspecの標準化は2009年に行われていましたが、ネットワーク機器への実装が増えてきたのは、ここ2年ぐらいです。ネットワーク機器への実装が増えてきた背景のひとつとして、大規模なDDoSトラフィックへの対処への要求が増え、それを行う要素技術のひとつとしてBGP Flowspecが注目されたことがあげられます。

今年のShowNetでのBGP Flowspec活用は、以下の5種類です。

  • ACLの配布
  • IPv6対応(Rate limit、Discard、Marking)
  • NFV(サービスチェーニング)へとVRFリダイレクト
  • セキュリティオーケストレータからの動的ACL設定
  • DDoS detection装置との連携

ACLの配布は、ShowNet外部からShowNet内部に対するtelnetなどのトラフィックを遮断するなどが行われています。

BGP FlowspecのIPv6対応は、いままさにIETFで標準化が行われていますが、RFC発行に先駆けて実装が登場しているので、今年のShowNetではそれらが活用されています。

今回のShowNetでは、dcwest内にNFV関連の展示をまとめたエリアが作られています。NFVを経由してからShowNet内の出展社ブースなどに転送されるべきトラフィックに関する設定がvMXで行われ、その設定をBGPルータに対して配布するためにBGP Flowspecが使われています。

flowspec-interop-2016

セキュリティオーケストレータからの動的ACL設定、DDoS detection装置との連携に関する話は、別途記事を書きます。

今回のShowNetでは、昨年と比べてBGP Flowspecの活用方法が増えていますが、これら意外にも様々な活用手法のひろがりがありそうです。もはやBorder Gatewayではなくなりつつあるぐらい、様々なものがBGPへと突っ込まれているような気がしている今日この頃です。

PAGE TOP