YAMAHAルータの帯域制御で速度の遅い回線を再現してみる

たまにはネットワークの話もしてみようというわけで、YAMAHAルータで接続速度の遅い回線を再現する方法をお送りします。

どういう状況下というと

ネットワーク対応の製品を開発しているところで、速度の遅い回線でどのくらい使えるか確認したいので、速度調整ができる回線PLZ,ということになりました。

図にするとこんな感じですね。

もちろん、何百万円するお高い機械を使えば性格に速度制限ができます。でもキャリアやプロバイダじゃないんだからそんなお高い機械など津開けるわけもなし。IIJは1000万円以下の機械は稟議いらないとかいう話なんかちっとも羨ましくなんかないんだからね（涙目)

そこで、ガチに正確な回線速度のエミュレートはできませんが、だいたいいい感じに回線速度を遅くすることができるフィルタをYAMAHAルータで実現してみました。

材料

YAMAHAのRTX系列ルータ。中古なら2000円くらいで買えるRTX1000でもおーけー。SRTとかFWXでもいけるようだけど、RT107eはshaping機能に対応してないから使えないので注意。

ネットワーク構成

ルータのLAN2側を172.17.0.0/16、LAN1側を192.168.0.0/24として、LAN1側につないだ機器がLAN2側にアクセスするときの速度を上下とも制限します。今回は上下とも同じ速度にしますが、上下の速度を変えるとADSLを再現することもできます。

設定ファイル

設定ファイルはこんな感じです。
# この例ではIP Masquaradeだけど # LAN2側ととLAN1側の通信が成立するなら # 中継方法はなんでもいいよ

console character ascii

# デフォルトルート設定

ip route default gateway 172.16.0.1

# インタフェイスの設定

ip lan1 address 192.168.0.1/24
ip lan2 address 172.16.0.2/16
ip lan2 nat descriptor 1

# LAN1から出て行く通信の帯域を200kbpsに制限

queue lan1 type shaping
queue lan1 class filter list 2
queue lan1 class property 3 bandwidth=200k
queue lan1 class property 4 bandwidth=200k

# LAN2から出て行く通信の帯域を200kbpsに制限

queue lan2 type shaping
queue lan2 class filter list 1
queue lan2 class property 1 bandwidth=200k
queue lan2 class property 2 bandwidth=200k

# Queueing configuration

queue class filter 1 1 ip * * *
queue class filter 2 3 ip * * *

# LAN1側クライアントのための設定
# この例ではIP Masquaradeで接続、クライアント側アドレスは
# DHCPで配布する

nat descriptor type 1 masquerade
nat descriptor address outer 1 primary
nat descriptor address inner 1 192.168.0.2-192.168.0.191

dhcp service server
dhcp server rfc2131 compliant except remain-silent
dhcp scope 1 192.168.0.2-192.168.0.191/24

dns host lan
dns service recursive
dns server 8.8.8.8 4.4.4.4

この設定は何をやっているかというと

LAN1とLAN2のそれぞれについて、出て行く通信の帯域を制限しています。この設定例では200kbpsに制限しています。
でも、RTXの帯域制限はソフトウェアベースのキューイングでやるので、制限の結果の帯域は、大体これぐらい、という数字になります。

RTXのキューイングは帯域制御とQoSとで共用します。キューはルータ内部からのパケットがインタフェイスから外に出るときに制御されます。そのため、上り下りの上下方向で制限をかけるには、外側内側の両方のインタフェイスでそれぞれ制限をかける必要があります。

インタフェイスごとにプロパティが、フィルタ定義されている者とされていない者の一つずつありますが、これは、フィルタ対象（IPのパケット）と、念のためにそれ以外のものも全部制限をかける、というので書いています。

でも、IPXとか、IP以外のパケットが出てくることはないと思うので、フィルタ定義されてないプロパティは削ってもいいような気がします。

そういえばうちはネットワークのサークルだった

ネットワークっぽい記事って初めてだなー。というわけで今回はおしまいです。

#裏書典 について思ったこと

普段はこういうことは書かないのですが、件の裏書典の件については書いておきたいことがあるのですよ。
風邪を引くとこういうものを書く時間がとれてしまうこともあるのですが。

企画を知ったとき、正式にやるならスタッフやると名乗り出た人間として、ちょっと書いておきたい。

パイの切れ端が足りない？なら作っちまえ

いま、技術同人がブームです。
日経ソフトウェア2013年10月号の記事で、エンジニアの副収入の手段として書かれていましたが、これはブーム以前の話です。
記事の穴埋めに困った筆者がオチとして書いた、という解釈でよいかと思います。

ただ、ブームの結果として本を対面頒布する機会というキャパシティが急に不足してきたことは否めないです。
同人誌というのは、印刷したらおしまいではありません。
即売会で頒布して、作った本の費用を回収して、そこまでが本作りだと思っています。
その、最後のステップを行う場所が得られないとしたら。

正直に言うと、技術書典とは違う、技術系同人誌イベントが必要と思っています。
複数のイベントが並立してこそ健全、というのが建前。
本音は、増やさないと自分が出られる確率が下がる、ということ。
パイの切れ端の分配は、これまでは余るぐらいだったのが足りなくなってきている。
なら自分の食べる分は作ってしまえ。そのほうが早い。
そして、もっと同人誌即売会の顔をしたイベントが欲しいという思いもあった。
後者についてはまた後程論じましょう。

このような理由から、自分でなんとかするしかないじゃん。
そう思ったので、この企画でスタッフやってみようと思った。
次回のコミケも当落がどうなるか判らないこの頃、作った本を次はいつ頒布できるか判らなくなってる。
なので、技術書典落選組で場所を作る動きがあるなら、そういうイベントのスタッフやって、場所を作ろうと。

なお、C93コミケカタログ欄外の配置担当コーナーによると、C94はメカミリで応募しているラズパイやIoTを、カテエラ落選でなく同人ソフトに誘導するそうです。
つまり、C94は同人ソフトその他の倍率が、さらに上がると推測しています。

進化と革命

企画に乗った立場であった気楽さから、これから即売会スタッフ経験者も集まるだろうし、これからの打ち合わせで、詳細を詰めたり、日程を別にすることを検討する提案もできるだろうと思っていました。
そして、一夜明けたら。
主宰の方のお考えもあるので、中止に至る経緯は論じません。

でも、NetBSDが386BSDに遠慮してたら、BSDは4.4BSDまでの伝説のOSとして消えていた。
Theoが元いたNetBSDに遠慮していたら、OpenBSDも、いくつかのセキュアプロダクトもなかった。
タネンバウム先生の言うことをライナスが偉大な先人のお言葉として受け取ってたら、Linuxはスマホを通じてだれもが使うOSにはならなかった。

なぜEvolutionとRevolutionは一文字違いの単語なのか。

以下は個人の思うところ

今の技術同人ブームってどうなんだろう、いう思いもあります。

わたしは、コミケで、同人ソフトその他というジャンルを知りました。
コミケで、いわゆる技術系同人誌を収容するジャンルです。
コミケという同人誌即売会で、同人誌で技術書をつくっていいんだ、という知見を得ました。

単発では、90年代の小倉のコミックライブで、DEC Alphaの同人誌を買った覚えがあります。
でもその時は、評論情報というジャンルの存在が見えていなかったから、こんな本を出す人がいるんだな、で終わっていました。

これまでは、技術同人は、同人誌即売会から知られていくもの、書き手も、同人誌即売会という環境に触れていること、という前提があったかと思います。
よくいえば、頒布の場のキャパシティに見合ったゆっくりした広まり方であったのではないでしょうか。
悪く言えば、その境地にたどり着かないといけない、スタート地点が無駄に遠いジャンルではあったわけです。

前回の技術書典に参加して思ったのは、良くも悪くも、同人誌即売会っぽくないということ。
blogﾄGitHubしか知らない人が、同人文化抜きで、やっていけるイベント、といえばよいのでしょうか。
こうであることは、技術同人というジャンルの人口を増やし、新陳代謝を促すには必要なことなのでしょう。

でもこれは言いたい。みんな同じように、Re:view使って、同じようにオフセット印刷してないか？

AliceSystemはどこまで行っても同人サークルだから

それでも、同人っぽくやっていく自由はあると思っています。禁止されてないし。
技術書典でも、いつものようにペーパーを配りました。
次のコミケに出られたら、もらって困るノベルティナンバー１（主観）である、洗濯ばさみでIPアドレス配布を久々にやりましょうか。
RFC2322を勝手に拡張して、2001:db8::/32で配っちゃうぞー。
しかもAliceSystemは、コミケならコスプレ売り子だって装備済みだ。

※コスプレ売り子さんは私の中の人ではありません (@infra_imouto)

私自身は、第2の技術系の同人誌即売会をあきらめていません。
私はIT系のコミュニティや商業のライティングという世界には、影響力どころか知己もろくにいない人間です。
勉強会も基本ぼっち参加だし。
だからこそ遠慮なしでやれることがあるんじゃないかな、今はそんなことを考えています。

技術書典4……落選orz

まあ、タイトル通りです。

うちは昔からサークルカット詐欺ばっかりやってたけど、今回はかなり色々準備してたんだけどなぁ(´･ω･`)
どこかでTLSの本は出そうと思っています。

参加費払わなかったところの分の繰り上がりは前回あったらしいけど、今回はアテにはしないようにします。

以下、あくまでも個人の意見。
実際の所、ITで技術同人を出すことををブームとして呷るのはいいけれど、参入者の数が本を頒布するチャンネルのキャパを越えちゃってることは覚えておく必要があるぞ。