祝) IRCnetJPとして、2025年01月06日に日本国内にとってもとっても新しいIRCサーバーをリリースしました!!
こちらは、既存のIRCnet(日本国内では通称WIDE IRCといわれていた従来のネットワーク)に接続したものを提供しています。
前回同様、私個人ASのネットワーク上に設置されています。また、実験目的での提供となり、カナダに次ぐ2番目のサーバーとして日本に設置されました。インストールされているIRCdのバージョンは、irc2.12.0-preで、今の所ソースコードはGitHub上ではまだPrivateなものになります。IRCnet2においても数台このバージョンが適用され、動作確認がされているようです。既存のIRCnetとの相互接続性などの試験も十分に行われたことから、最新版のIRCdをインストールされたソフトウェアで、既存のネットワークに接続をして今後も開発をしていく、また、SASL対応の環境においてユーザーが困らないかテスト環境を提供するといった趣旨で設置されています。日本に設置を求められた経緯については、次のセクションで記載しますので、是非ご覧ください。
Server Name: dev.ircnet.ne.jp
IPv4: 103.167.46.70
IPv6: 2001:df6:a680:1014::7000
Port: 6667 / 6697 and 6679
※ irc.ircnet.ne.jp の DNSラウンドロビンには組み込みしておりません
★ 日本に設置されることとなった経緯:
このサーバーは、12月28日頃、IRCnet全体で決まり、既存のIRCnetに日本からサーバーを提供することとなりました。当初開発サーバーは1台のにでよいという他国の意見がありましたが、日本を好意にしてくれている方々が、日本にも必要だと言ってくれたことから、日本にも準備することとなりました。日本にも設置する必要があると認められた理由は、日本独自の文字コードがあり、ISO-2022-JP という文字コードが利用されています。この文字コードに対応するため、これまで、日本のIRCサーバーは「JP Patch」というのを個別に適用してビルドしていました。
このパッチの適用が無い場合、一部の文字が壊れ、チャネルへのログインやメッセージの送信に失敗します。これは、ISO-2022-JP の文字コード由来の一部の文字に潜在的に 「,」「:」 が含まれており、チャネル名に「:」の文字が含まれると、サーバーは区切り文字が来たと判断し、正しいチャネルを作れない、正しいチャネルにJOINできない、メッセージを送れない、壊れたチャネル名が作成されてしまうと言う問題がありました。故に、日本とリンクされている海外のサーバーとの間でも問題が発生しました。そのため、日本国内に閉じたサーバーに限り正しく文字コード処理ができたという話があります。IRCでは、プロトコル上、チャネルとメッセージの間の区切りに、「:」(コロン)を使用します。
このあたりは、
1999年度WIDE報告書 第17部 IRCの運用技術と活用技術に記載がありますので、興味がある方は是非ご覧ください。私がIRCに関わったのは2002年ごろで、私が参加した当時は、irc2.10.xが動作しており、Pentium3なサーバー上で動いていました。ircdそのものが使用しているメモリは100Mも無かったように記憶しています。90年代から使われているプロトコルで当時は回線も数十kbps〜数百キロbpsといった細い回線で使われているほどだったそうです。その当時からの実装のため、IRCは非常に軽量な実装となっています。その後、2.11へとアップグレードし少しずつ重たくなりましたが、現在でも数百MB以内に収まっています。IRCとは、Internet Relay Chatとよばれ、メッセージを中継するだけのとてもとてもシンプルな作りになっています。むしろいまはSSL処理の方が重たいのでは...。IRCの歴史については、
IRC Working Groupが解散されるまでの情報が毎年報告書として掲載されておりますので、こちらも気になる方はご覧ください。歴史の一部が分かるかと思います。
少し脱線てしまったので、話を戻します。今回の irc2.12.0-pre では、この「JP Patch」も取り込まれており、ISO-2022-JP に標準で対応されるようになりました。日本のメンテナが事実上不在となったことから私が、今まで使用されていた日本のパッチを投げることにより、新しいバージョンで取り込んでもらうに至りました。こういった背景から、日本人によるテストが必要なこと、日本で多く使われているIRCクライアントの対応の必要性があると言うことで、日本に設置することとなりました。
世界的に見ても、UTF-8に移行している中、日本は未だに ISO-2022-JP から移行できていませんし、今後も移行されることはおそらく無いでしょう。
私が考える大きな理由は、日本で提供されている日本語のクライアントに大きく依存しているためだと考えられます。また、その日本で慣れ親しんでかつ、一般的に利用されているクライアントの多くは開発が終了もしくは事実上メンテされていないことだと考えられます。では、TLS や SASL に対応し、かつ、ISO-2022-JP に対応した海外製のクライアントはほかにあるかというと、HexChat ぐらいしかみつけれませんでした(ほかにあったら教えてください)。そういう私も、Freenode に接続する際、クライアントがUTF-8に未対応のため、Tiarra を用いて文字コード変換を行い、慣れ親しんだクライアントで接続していたりします。
最近、新たにHexChatというのを試してみましたが、ISO-2022-JP にも対応していますが、NOTICEメッセージがきたら画面表示が壊れてみだれたり、なかなかUIになれれなかったりと、苦戦しており、こりゃー、移行がむりだなぁって気分になってしまいます。
今回、新たに用意したサーバーは、新バージョンでSASL対応の環境となるため、IRCクライアントを開発されてきた皆様、この環境を是非役立てていただければ幸いです。お願い申しあげます(切実)
以下についてはあくまでも超辛口個人的なコメントや愚痴で、気分を害するような記載があるので、注意願います。
----------- ここから -----------
特に日本人の多くはリテラシーが低く、また、多くの人は新しいものや変化、英語クライアントというだけで抵抗があったり、日本語で手取り足取り書いてあっても、手取り足取り教えてもらわないと使うことが出来ない人がおおいという感触を受けました。2000年代当時ゲームをしたい、連絡手段にIRCをつかいたいのにわからない。解説サイトがあっても面倒くさいから教えてくれ、それどころか「パソコンの使い方をおしえてくれという教えてクレくれ君」というのを多々見かけました。自分で調べて学ぼうという人が非常に少ないと感じられました。が故に、変化を嫌う、既存のままずっと使い続けるということもあるでしょう。
当時一番シェアを誇った、CHOCOAがISO-2022-JP以降対応していないこともあるでしょう。今まで困ってないし…というのもあるでしょう。これらから日本のIRCnetではUTF-8に行くのも難しく、クライアントの対応有無が混在することから、未だにIRCnetJPにおいては、ISO-2022-JPが標準になっており、今後もおそらく変わることは無いでしょう。無理矢理SASLに強行移行したら、ISO-2022-JPの問題はなくなり、全員UTF-8にいけると思いますが、おそらくそのタイミングで、IRC bouncersの多くが対応不可、また、新たなIRCクライアントを探して自分にあったクライアントを探し、英語の壁や日本語環境でうまく動くかわからない中、試行錯誤すると行った試練が待ち構えているでしょう。また、SASL認証するために登録をして、となると多くのIRCユーザーが離れてしまうと個人的には感じています。
すでに風前の灯火なので。いっそのこと入れ替えるか切り離して、サーバーを分けるという話も管理者の中で議論がありましたが、分断は崩壊を進めるだけになるので、阻止する方向で調整し、折り合いをつける必要がありました。ということで、日本で使われていたIRCクライアントの開発、アップデートが強く望まれます。正直私も行く当てが無くて困ってんだよー!!!(涙)
----------- ここまで -----------
こういう状況から日本の状況も配慮する必要があり、日本のサーバー直下にぶら下がった開発用JPサーバーが必要になったと言うことです。
私が見える範囲のチャンネルで、CTCP Versionをたたいて、どういうクライアントが多く使われているのか、暇なときに集計してみたいなと、思いました。
参考に、日本発日本クライアントで、UTF-8に対応しているのは、LimeChat2, Cottonぐらいで、CHOCOA, RainMaker, LimeChat1 は未対応です。
SASLに対応しているのは、Mac版のLimeChat2のみとなります。
SSL対応と記載があるのは、Windows版iでは、LimeChat2(SSLv3までかな?)、Cotton(対応バージョン未確認)です。時間があるとき調査します。
なお、数少ないUTF-8対応クライアントの一つである、Limechat2 Windos版について、
LimeChat 2.40の配信についても、つい先日ですが、バイナリの配布が停止してしまいました。
これは、
Vectorのホームページサービスが2024年12月20日終了による配布終了が起因です。。。公式の人にバイナリの復活が出来ないか、また当方でミラーをすることができるので、ミラー出来ないか打診してみようかと思います。(Windows版LimeChatで、SASL対応、TLS対応をしてほしい…)
★ IRCnetの利用状況:
現在、IRCnet全体のユーザー数は、執筆の時点で 17,000 程度です。
国別クライアント数(ユーザー数)においては、Netherlands: 3900, Finland: 3200, 日本: 1500 程度で3番目に利用されている国になります(Open serversのクライアント数除く)。
世界全体でもみても、日本はまだ上位3位に位置しています。まだまだ日本にユーザーがいることから、無視は出来ない存在だと思います(移行できないなら、切り離すという話も出ました…がなんとか阻止しました)
なお、全盛期、IRCnetJP(日本のクライアント数)では、接続数で2万以上ありました...
IRCの利用者人口は年々減っておりますが、また活気を取り戻したいなあ、これほどシンプルで素晴らしいプロトコルはないので、是非とも皆さん、新しい動きがありますので是非戻ってきてください。インターネット中年会や老人会といわれても仕方ありませんが、昔懐かしのチャンネルもまだ残っておりますので、是非もどってきてくださいませ。dh.ircnet.ne.jp を含め、日本のIRCサーバーはまだまだ生き残ります。というか私が引っ張っていきます。
日本の中のオペレーター内にあった蟠りもほぼ解消しております。これから新たなスタートに向けて勢いをつけて行きたいので、是非レガシーな懐かしい世界にもどってきてくださいませ。今回SSLの対応も入っていることから通信路の暗号化も実装が入りました。通信路を暗号化したい方は、是非TLSをご利用くださいませ。
さらに、IRCサーバーを設置させていただけるネットワークも是非募集中です。興味がありましたら国際間で調整しますので、是非お声がけください。
DDoS対策などのノウハウも必要に応じて技術提供いたします。
★ IRCといえば、TELNET クライアントが一番最強でしょ?:
IRCといえば、TELNETで接続出来るぐらい軽量であり、シンプルなプロトコルであると言うことが言えます。では、IRCnet2や、今回リリースした、dev.ircnet.ne.jp など、SASL認証が入ったネットワークではどのように接続するのでしょうか?また、TLSに対応した場合どのように接続するのでしょうか?それはとても簡単なことです。手で接続するときのサンプルを貼り付けておきますので是非ご参考にしてください。なお、SASL Plain認証による例となります。
SASLパスワードである、SASL Plain Base64は以下の方法で作成します。
PLAIN 認証では mechanism が PLAIN、argument が "ユーザID\0ユーザID\0パスワード" という文字列を Base64 エンコードした物になる。
以下はユーザ名 user、パスワード pass の場合の argument 文字列を作成する Perl スクリプト。
$ perl -MMIME::Base64 -e 'print encode_base64("user\0user\0pass");'
dXNlcgB1c2VyAHBhc3M=
(出展:
SASL base64によるエンコード演算プログラム)
$ openssl s_client -connect dev.ircnet.ne.jp:6697
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = E5
verify return:1
depth=0 CN = dev.ircnet.ne.jp
verify return:1
---
Certificate chain
0 s:CN = dev.ircnet.ne.jp
i:C = US, O = Let's Encrypt, CN = E5
1 s:C = US, O = Let's Encrypt, CN = E5
i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDgDCCAwagAwIBAgISA/quCPeNgRf1slSZe33yZY9FMAoGCCqGSM49BAMDMDIx
CzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQDEwJF
NTAeFw0yNTAxMDQyMjU4MjhaFw0yNTA0MDQyMjU4MjdaMBsxGTAXBgNVBAMTEGRl
di5pcmNuZXQubmUuanAwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAASBXLHJvou7
6Y94f1lt+/bcXPpn6VGAE7GP515BXHC0rdld42PRzf3IsG9ZxXBRKuwRduwtBqRJ
51/TWjfL+oCfo4ICETCCAg0wDgYDVR0PAQH/BAQDAgeAMB0GA1UdJQQWMBQGCCsG
AQUFBwMBBggrBgEFBQcDAjAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBSZloGZjyx5
iX0fQ1jpuQ1ogjXEVjAfBgNVHSMEGDAWgBSfK1/PPCFPnQS37SssxMZwi9LXDTBV
BggrBgEFBQcBAQRJMEcwIQYIKwYBBQUHMAGGFWh0dHA6Ly9lNS5vLmxlbmNyLm9y
ZzAiBggrBgEFBQcwAoYWaHR0cDovL2U1LmkubGVuY3Iub3JnLzAbBgNVHREEFDAS
ghBkZXYuaXJjbmV0Lm5lLmpwMBMGA1UdIAQMMAowCAYGZ4EMAQIBMIIBAwYKKwYB
BAHWeQIEAgSB9ASB8QDvAHUAzPsPaoVxCWX+lZtTzumyfCLphVwNl422qX5UwP5M
DbAAAAGUM8AlswAABAMARjBEAiBg5IYH82Y0AJUas19n9+8ExDWRPwayYtT9gfvA
MKWNbwIgXyPRcyIUDvSefA5RlJw1CfrMGOq+PJyMVRm5zcmW3OkAdgDgkrP8DB3I
52g2H95huZZNClJ4GYpy1nLEsE2lbW9UBAAAAZQzwCXNAAAEAwBHMEUCIHZH1YFd
kKnBJtWC7/BkHG55Cr/hoCmjDqrUz6Eot3dmAiEAqkNhkBR9A21oeHhyZ/1AilJy
LzkovRd+OHWN4MQI0OYwCgYIKoZIzj0EAwMDaAAwZQIwXDduNyxWjoLYrZV0nLl0
fnwPUTIJ2VXzTLxR3iWXoU1nrFXgX33P5mS9+M7SkoT5AjEA3aMK1Z+MmU5q0ALV
J2Xf1NAP4Y2KqoVQydVrqoQdncsZggwWpi44e6SJwo5KJCRm
-----END CERTIFICATE-----
subject=CN = dev.ircnet.ne.jp
issuer=C = US, O = Let's Encrypt, CN = E5
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: ECDSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 2395 bytes and written 394 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 256 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_AES_256_GCM_SHA384
Session-ID: 46A60731DA3425BF57E81CC83E8ABD79E91DD0D2218CD7326AF6DE134C5646F5
Session-ID-ctx:
Resumption PSK: E0C3ECD28DA503688DAB2327F18A5E9EC7B7C7C3A07B2FA417A73F5780653E303A15D344FD1CE482B403D63910C3CD90
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 6b f1 a1 2c e9 6f 56 63-ce 00 9b 88 1f 16 c6 a2 k..,.oVc........
0010 - 52 b5 47 b0 35 44 cc 3b-de 32 57 59 08 92 2d f8 R.G.5D.;.2WY..-.
0020 - 0f b0 da da 9c 5c 1e 73-56 c2 f1 c2 f4 be 35 46 .....\.sV.....5F
0030 - 11 dd b0 3d 64 c9 1c 0c-85 6c ec ba f3 20 05 08 ...=d....l... ..
0040 - 6d 42 e6 65 a3 66 28 73-5c 23 ac da e0 52 1e 39 mB.e.f(s\#...R.9
0050 - 57 3a db 82 81 06 d4 b8-85 ad 50 cd 42 c8 d9 94 W:........P.B...
0060 - d6 89 04 8f 24 9c 91 20-de 47 e6 4b 14 dd b8 a1 ....$.. .G.K....
0070 - 23 bc 26 76 99 39 0f 99-d6 70 aa ab dd 77 aa f9 #.&v.9...p...w..
0080 - 09 1d 9a ef 8d 1b 99 db-9d 8f 3a 97 89 d6 db ad ..........:.....
0090 - 62 07 27 30 71 4d b3 ae-19 e7 8a 74 07 8a b1 d8 b.'0qM.....t....
00a0 - 10 18 e0 53 27 68 5d 75-80 01 c6 a7 c0 d8 59 79 ...S'h]u......Yy
00b0 - 9a 04 c8 a9 af fe 9f f7-32 7d 40 68 55 7c 28 f0 ........2}@hU|(.
00c0 - 67 5f 6a b9 0b 95 8c 0f-3c 14 41 ee 3c ac 6f 20 g_j.....<.A.<.o
00d0 - d9 74 1d d1 5c ed b7 41-18 01 6a 7b 1d 4f c4 87 .t..\..A..j{.O..
00e0 - 04 52 f0 3f 36 6f c8 68-ca bc a3 72 04 80 36 11 .R.?6o.h...r..6.
Start Time: 1736755741
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
Max Early Data: 0
---
read R BLOCK
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_AES_256_GCM_SHA384
Session-ID: A06D178561B14439775672D22209A1E52A16D6A86246CDD5C4D3C4674A32F950
Session-ID-ctx:
Resumption PSK: C740D49409010B867FC4E8583F8773FE550E1BF1FBA222B54C5E031F9D7458FD9F0D5C9A94519745B0D4E527E9925838
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 6b f1 a1 2c e9 6f 56 63-ce 00 9b 88 1f 16 c6 a2 k..,.oVc........
0010 - d6 78 1a 4c cd 24 d9 2c-a3 ff 90 db 7e ec 46 56 .x.L.$.,....~.FV
0020 - 27 7c b3 84 ee 0b 08 de-e1 3c 8b 7a 52 24 97 89 '|.......<.zR$..
0030 - f9 70 a7 a3 1d b0 2e 88-62 b5 83 db 33 88 8a fc .p......b...3...
0040 - ac ef de 9b ba fa c6 d4-42 26 1c c6 e9 c5 e0 78 ........B&.....x
0050 - d8 18 f5 8a 29 c8 bf 83-10 bd e1 e0 4b f2 bb e0 ....).......K...
0060 - 87 68 90 7b 7b fc 3a 07-83 f5 fb 5d 7e 4e 5b 64 .h.{{.:....]~N[d
0070 - 11 4a 0d d8 a0 8c 33 d8-9b d8 34 c0 6d e0 b4 77 .J....3...4.m..w
0080 - 7d 22 42 41 dd 1f 25 3a-29 11 53 34 d7 57 cb 97 }"BA..%:).S4.W..
0090 - 3c a3 e4 ee 11 8b 81 1d-29 ef a3 a3 42 3b 69 60 <.......)...B;i`
00a0 - 86 12 22 f0 65 7b 1a 39-f7 f8 b7 5e db 62 0e 21 ..".e{.9...^.b.!
00b0 - ee dd 68 53 f0 0f cc 20-71 0c e9 04 8a c8 ba e8 ..hS... q.......
00c0 - 4a 78 24 a3 c7 91 55 a2-16 44 c0 ea b5 e1 70 4f Jx$...U..D....pO
00d0 - 43 3b 5b 9b a6 b9 22 17-69 de 44 14 3a 5c 08 71 C;[...".i.D.:\.q
00e0 - 4c 73 e7 9d 5e 95 48 62-32 a0 d8 1e 72 85 0b 12 Ls..^.Hb2...r...
Start Time: 1736755741
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
Max Early Data: 0
---
read R BLOCK
:dev.ircnet.ne.jp 020 * :Please wait while we process your connection.
CAP LS 302
:dev.ircnet.ne.jp CAP * LS :extended-join ircnet.com/extended-join multi-prefix sasl
NICK tomocha_dev4
USER tomocha 0 * :tomocha
CAP REQ :extended-join multi-prefix sasl
:dev.ircnet.ne.jp CAP tomocha_dev4 ACK :extended-join multi-prefix sasl
AUTHENTICATE PLAIN
AUTHENTICATE +
AUTHENTICATE <encode_base64("user\0user\0pass");>
:dev.ircnet.ne.jp 900 tomocha_dev4 tomocha_dev4!tomocha@tomocha.users.ircnet.com tomocha :You are now logged in as tomocha.
:dev.ircnet.ne.jp 903 tomocha_dev4 :SASL authentication successful
CAP END
:dev.ircnet.ne.jp 001 tomocha_dev4 :Welcome to the Internet Relay Network tomocha_dev4!~tomocha@tomocha.users.ircnet.com
:dev.ircnet.ne.jp 002 tomocha_dev4 :Your host is dev.ircnet.ne.jp, running version 2.12.0-pre(3a7b5ff)
:dev.ircnet.ne.jp 003 tomocha_dev4 :This server was created Sun Jan 5 2025 at 07:55:02 JST
:dev.ircnet.ne.jp 004 tomocha_dev4 dev.ircnet.ne.jp 2.12.0-pre(3a7b5ff) aoOirw abeiIklmnoOpqrRstv
:dev.ircnet.ne.jp 005 tomocha_dev4 RFC2812 PREFIX=(ov)@+ CHANTYPES=#&!+ MODES=3 CHANLIMIT=#&!+:42 NICKLEN=15 TOPICLEN=255 KICKLEN=255 MAXLIST=beIR:64 CHANNELLEN=50 IDCHAN=!:5 CHANMODES=beIR,k,l,imnpstaqr :are supported by this server
:dev.ircnet.ne.jp 005 tomocha_dev4 PENALTY FNC WHOX EXCEPTS=e INVEX=I CASEMAPPING=ascii NETWORK=IRCnet :are supported by this server
:dev.ircnet.ne.jp 042 tomocha_dev4 392DAAAQK :your unique ID
:dev.ircnet.ne.jp 251 tomocha_dev4 :There are 17352 users and 2 services on 32 servers
:dev.ircnet.ne.jp 252 tomocha_dev4 75 :operators online
:dev.ircnet.ne.jp 254 tomocha_dev4 10145 :channels formed
:dev.ircnet.ne.jp 255 tomocha_dev4 :I have 35 users, 1 services and 1 servers
:dev.ircnet.ne.jp 265 tomocha_dev4 35 37 :Current local users 35, max 37
:dev.ircnet.ne.jp 266 tomocha_dev4 17352 19763 :Current global users 17352, max 19763
:dev.ircnet.ne.jp 375 tomocha_dev4 :- dev.ircnet.ne.jp Message of the Day -
:dev.ircnet.ne.jp 372 tomocha_dev4 :- 5/1/2025 20:00
:dev.ircnet.ne.jp 372 tomocha_dev4 :- *************************************************************
:dev.ircnet.ne.jp 372 tomocha_dev4 :- Server: dev.ircnet.ne.jp
:dev.ircnet.ne.jp 372 tomocha_dev4 :- Location: Tokyo, Japan
:dev.ircnet.ne.jp 372 tomocha_dev4 :- Admins: tomocha
:dev.ircnet.ne.jp 372 tomocha_dev4 :-
:dev.ircnet.ne.jp 372 tomocha_dev4 :- Disclaimer
:dev.ircnet.ne.jp 372 tomocha_dev4 :- This is an irc 2.12.0 development server. To connect you
:dev.ircnet.ne.jp 372 tomocha_dev4 :- need to authenticate with SASL: https://sasl.ircnet.com
:dev.ircnet.ne.jp 372 tomocha_dev4 :-
:dev.ircnet.ne.jp 372 tomocha_dev4 :- This server is running for AS45679 experimental purposes
:dev.ircnet.ne.jp 372 tomocha_dev4 :- and stability is not assured.
:dev.ircnet.ne.jp 372 tomocha_dev4 :-
:dev.ircnet.ne.jp 372 tomocha_dev4 :- *************************************************************
:dev.ircnet.ne.jp 372 tomocha_dev4 :-
:dev.ircnet.ne.jp 372 tomocha_dev4 :- Website: https://www.ircnet.com
:dev.ircnet.ne.jp 372 tomocha_dev4 :- Server/Channel list: https://www.ircnet.info
:dev.ircnet.ne.jp 372 tomocha_dev4 :- Webchat: https://ircnet.chat
:dev.ircnet.ne.jp 372 tomocha_dev4 :-
:dev.ircnet.ne.jp 372 tomocha_dev4 :- *************************************************************
:dev.ircnet.ne.jp 376 tomocha_dev4 :End of MOTD command.
:dev.ircnet.ne.jp NOTICE tomocha_dev4 :Your connection is secure (SSL/TLS).
:dev.ircnet.ne.jp NOTICE tomocha_dev4 :Due to an administrative decision, your connection is cloaked.
JOIN #arege
:tomocha_dev4!~tomocha@tomocha.users.ircnet.com JOIN #arege * :tomocha
:dev.ircnet.ne.jp 353 tomocha_dev4 @ #arege :tomocha_dev4 ...(snip)
:dev.ircnet.ne.jp 366 tomocha_dev4 #arege :End of NAMES list.
quit
ERROR :Closing Link: tomocha_dev4[~tomocha@tomocha.users.ircnet.com] ("")
closed
★ 参考リンク:
ずいぶん前のネタになりますが、日本のIRC管理者は、Tomocha だって海外から宣言されて、
IRCnet2という網で、新しい実装をした実験網だから日本でも提供してほしいといわれたので、提供することにしました。
サーバー名は、
ircnet2.ircnet.ne.jpというホスト名で提供することになりました。本文にも記載しているとおり、個人AS、個人所有の設備で運用しているものであり、実験・研究・自ASのネットワーク品質のモニタリングのため、品質は保証いたしませんが、最大限の安定稼働を出来るよう努めさせていただく予定です。
サーバー情報
Server Name: ircnet2.ircnet.ne.jp
IPv4: 103.167.46.69
IPv6: 2001:df6:a680:1014::6900
Port: 6667 / 6697 and 6679
IRCnet2では、構築当初
irc2.11.3 (2024/12/13 release)のRCバージョンで動いており、ircnet2用(後にirc2.12.0で取り込まれる内容)のパッチ適用し、SASL認証、TLS接続などの実装が入っております。
基本的には、既存のIRCnetとは独立していますが、ゆくゆくは既存のIRCnet網と統合するか、廃止するかという前提での運用のようです。
そんなわけで、日本時間の2024年8月28日夜23時頃メッセージが来て、0時頃にはサーバの準備が始まり、海外との国際リンクの構築を行い、朝の5時にはリリースしているという頭のおかしい状況が出来ました(祝)
提供に至った経緯としては、自ASは実験・検証での使用を主としており、サービスを設置していないこと、品質のモニタリングをするにあたってもサービスが無いため正確なモニタリングがしにくいこと、IRCというプロトコルの特性上、常時TCPコネクションを張り続けるといいとてもインフラを管理する側からすれば嫌な実装で、メンテナンスしにくい実装です。これらの特徴から、ネットワークの安定性が一目瞭然でわかりやすく、ネットワークの品質モニタリングもかねて提供するに至りました。また、irc2.11.2より、14年間開発が停止しており、政権交代ならず世代交代、枯れたプロトコルから今時の実装として、認証・認可、またSSL/TLS対応などを行っています。このあたりは、
IRCv3 Specifications準拠に伴う内容となります。このサーバーは、世界と接続された日本国内にある唯一オープンなサーバーであり、実験的リソースの供給という公共・社会性から判断しました。ここからは完全な個人的な思いなのですが、WIDE ProjectのIRC Working Groupから始まり、20年以上日本のサーバーの管理者の一人として運用に関わっています。また、当時研究してきたものが廃れて日本または世界から消えていくのは忍びなかったことなどがあります。そんななか20年以上面倒を見ていたところ、海外より相談があったことから、じゃあ、日本でももう一回ちゃんとやるか!って気持ちになり、取り組み始めたのが現在です。これらの成果は今後、日本のIRCnetに生かされるはずで、それにより、20年以上生活した憩いの場を失うのを阻止しようという思いもあります。でも人口は減っていく悲しさ...
★ 接続方法:
IRCnet2に接続するには、最初に
アカウント登録をする必要があります。
その上で、SASL対応のクライアントで、ircnet2.ircnet.ne.jp を設定すればよいでしょう。また、既存の
CHOHOAはSSLそのものが未対応、Windows版の
LimeChatでは、TLS1.2以降に未対応のため、IRCサーバーには接続出来ません。また、SASL認証にも対応していないため、事実上HexChatかmIRCあたりになります。
対応クライアント一覧は、
IRCnet2 How to configure SASLを参照の上接続ください。
Mac版のLimeChatはGitHubに公開されているソースコードベースに、SASL Plain認証のみ使用可能となっています。
なお、
サーバー一覧にサーバーリストもあり、実際に接続されているサーバー一覧、ユーザー数、IRCdのVersion、設置されている国などの一覧表があります。
そのほか、
Tiarraについては、PerlのSSLライブラリを使用している
(参照:
Tiarra over SSL without stone) ことから、そのままSSL/TLSで対応出来ますが、今後、実装が変わっていく可能性が高いことから、SASLの実装をしてほしいとご本人に聞いてみたところ、SASL対応するコードを追加する予定はなさそうなので、雄志によるパッチのリクエストを私は希望します。 :)
なお、
Tiarra - ChangeLogや、
doc-srcをみても、SSL対応の記載が無く、
tiarra/main/Tiarra/Socket/Connect.pm
を見たところ、以下の記載があり、commit logで確認することが出来ました。
* check ssl module before connect.
* fix bug tiarra entering busy-loop after verification error.
* handle ssl-configuration failure.
現時点では、IRC Bouncers で、SASL対応しているクライアントは見つけれておりませんので、ご存じの方は教えてください。
★ ネットワーク運用のこぼれ話:
運用開始して数日後、10Gbpsを超えるDDoSを受けているらしいです。
直接流れ込むトラフィックもあり、モニタリングしていると、数時間毎に5分間のDDoSを観測されるなどとてもとても楽しい状況を楽しんでおります。
この自宅にある個人ASは10Gbpsの専用線を含むアップリングが複数本あり、そのほか、1Gbpsになりますが、NGN閉域接続のよる回線などがあります。ルータについては、Cisco ASR や 各種ソフトウェアルータなど複合的に組み合わせ、冗長化構成を取っており、リージョン間でも同様の仕組みを構築しています。その辺の普通の一般的なAS運用と同じレベルでの運用を目指しておりますが、電気代高騰に伴うコスト増のため、半分はハードウェア、半分はソフトウェア(仮想化基板上)で実装していました。
その中で、10Gbpsを超えるDDoSが流入し、一部のパケットが仮想化基盤へ流れ込み、その結果ppsに負けてしまい、vDS含む仮装基板が破綻しました。帯域では無くパケットの数で負けました。なお、ハードウェアで構成されたネットワーク部分については、余裕でした。
自宅の構成は、インターフェースはすべて10G以上で構成されているので帯域的には戦えるのですが、それ以前のボトルネックにぶち当たる羽目に。元々、普段トラフィックがないので通常は仮想化することによる集約メリットがあるのですが、DDoSが流れ込むと仮装基板が破綻することから、一部のサービスを仮想化するという事を辞め、機能ごとに、オンプレに回帰する方向に向かっています。
もちろんナレッジをためたいのは山々ですが、DDoSを耐えるためのオーバースペックともいえる最新CPUの搭載したサーバーを何台も用意しチャレンジする、とか、SR-IOVやNICをまるまるVMに渡すなど、いくつかの方法は考えられるのですが、結局、その分システム全体が大きく、また複雑になります。自宅で運用するには金銭面だけではなく、運用コストも含めると、全くもってコストメリットがでない状態になります。また、DDoSに耐えれる仮想化基盤を作るのが目的では無く、リソースの集約のための仮想化基盤のため、リソースの集約が出来ないような代物については、オンプレでホストごと潰すというのが一番手っ取り早くてコストが安いものです。ネットワーク機器の仮想化は日常的にDDoSが来る事を想定すると向かないということが頭ではわかっていたものの、ここまで性能が出ないのかというのを目の当たりにしました。また、ホストの組み合わせ方によっては巻き添えを喰らうvmもでてくることから、結局組み合わせなどを考えて最適な配置をする必要が出てきて、結果物理サーバーの台数が必要になってしまいます。
また、トランジットを受けている一部の上位でも悲鳴が上がり、協議の結果、BGP flowspecによるネットワーク保護、RTBH、特定IPに対して、事前フィルタを上位で設定するなど、いくつか調整を行い、DDoSパケットを落とす仕組みが入っています。
そのほか、IRCでは、C&Cサーバー
*1
などが設置され悪用されることも多いと言われていますが、IRCnetにはそういうのが居ないことを願いたいものです。今回、そのためユーザーを認証するという概念が取り込まれています。セキュリティー系の人からすれば、IRCってC&Cサーバーの温床でしょ?っていう方も居るぐらいIRC=C&Cのプラットフォームと思われているケースもあります。
ガチ運用できて落としても怒られないASって最高ですね。面白い。商用でこういうサービスをぶち込む勇気のある事業者がほとんどおらず、WIDE ProjectがIRCの提供を終了するとなったとき、引取先や協力してくれる事業者やASが見つからなかったのもそういう背景がありました。だったら、おうちで持ってみたらどうか?って思い始め、さらに品質モニタリングもしちまえっていうのが今回の私のテーマです。とりあえず、対外線などを100Gになればとりあえず頑張れるのですがなかなか頑張れる気がしませんね。
そんなわけで、省電力で10G喰えてソフトウェアルータに向く箱、IRCサーバーに向く箱などを探していたというのもあり、先日の
2024/05/06 MINISFORM MS-01検証などをやってたというのが実は関連していたりしました。個人的には見送りましたけど....
面白そうだからオンプレだけじゃなくて、クラウドやVPSにおいてどうなるかもためしてみたいなぁ。
*1:
C&Cサーバー:
「コマンド&コントロール(C&C)サーバ」とは、ボットネットや感染コンピュータのネットワークに対し、不正なコマンドを遠隔で頻繁に送信するために利用されるサーバのこと。この用語は、もともと、司令官が目的遂行のために、部隊へ直接指令(com >
mand)を送り、制御(control)するといった軍事的な概念から派生したものである。C&Cサーバは、「Internet Relay Chat(IRC)」や>正規のWebサイト、ダイナミックDNSサービスを利用することで知られている。
(出展:
TrendMicro: コマンド&コントロール(C&C)サーバ)
Facebookの広告がすざましく、以前からとても気になっていた、
MINISFORUM MS-01をFacebookで複数台調達し、NIC/CPUの性能評価をされていた
seirios氏がいたので、拉致して一緒に検証することにしました。幸いにもこのタイミングでEthernet Testerがあったため、いろんなパターンで測定を行い、IP Unicast Routingの性能評価を実施。
実施したときの流れは、Twitterに投稿していたとおりです。
MINISFORUM MS-01 を借りて遊んだよ。
結論としては、FreeBSD 14R で実装しルータとして使ったときのパフォーマンスは、512byteパケット長であればほぼワイヤーレートに近いIP Unicast Routingはできました。
ほぼワイヤーレートに近いと書いている理由は、複数ストリームで流す必要があると言うことと、0.0001%ぐらいこぼします。
詳細などはTwitterにつらつらと書いていますが、1 stream 10G は 512byte は出ず4G前後でした。5 stream 以上なら問題なし!理由はCPU割り込みの関係でコアが張り付きます。
これはキューの関係で、In/Outの処理を同一スレッドで処理しているため、CPUパワーが足りずに性能が出ません。
src mac/dst ipなどが異なっている場合に於いて、CPUコアが分散することにより、性能が出るようになりました。通常のルータであれば、十分nic性能とcpu性能があることがわかりました。フルルート食わせてランダムな通信のimix試験は今度やってみます。
詳細レポートは、後に、主よりドキュメントが出ると思います。出てきたら紹介しますね。
seirios氏がAmazonでポチって面白いデバイスを持ってきたので、軽く検証、面白い結果が得れたので私も合計で5台ほど調達することにした。
検証した機器は、
八丁 seekswan XikeStor SKS8300-8X 10G SFP+ 8port マネージメント Layer L3 Switchというのを2万円以下で見つけてしまい、即購入。
ちょうど10G/25G/40G/100G対応のパフォーマンステスターが落ちていた^H^H^H^H^H手元にあったため、さくっと検証した。
Realtek RTL9303のチップを搭載したスイッチであり、
データシートからすると、Layer 3 (IPv4/IPv6 IP Unicast Routing) については、ハードウェアで処理され、また、160Gbpsのバックプレーンとしての帯域があるため、ワイヤーレートの性能があるそうだ。
最初、L3処理はCPUで性能全然出ないだろうと考えていたが、なんと調べてみる限り、PHYによるASIC処理しているとのこと。
これらから、とても優秀なスイッチだと仮定し、手元にあった VeEX のテスターを使用して、性能試験を行った。
結論から言うと、Layer 2 Ethernet Switchとして、72byte パケット長(IPv4利用環境を想定)において、packet dropすること無く100%の性能があった。
IPv6 Layer 3 Unicast Routing において、92byteパケット長でワイヤーレートの性能があった。
なお、 Layer 2 Ethernet 試験において、64byte パケット長では、0.08%のパケットをdropし、4%以上壊れたフレームとして戻ってきたため、95.37% packet forwarding できる結果となった。
64byte Ethernet Flameを扱う特殊な環境以外ににおいて問題になることはありませんでした。
いずれの試験も1時間のヒートラン実施時において、上記の結果であった。
テスターで試験した詳細結果は以下の通り。
試験環境: 室温 24℃、外部FAN設置無し、TransceiverはFINISAR 10GLR/10GSR、10GigTek/FiberStore 10GBASE-Tを使用、L2試験の際には、2port単位でVLAN分割を行い、物理的に数珠つなぎにした状態で両端からloopback試験を実施。テスターと接続したインターフェースにおいて、802.1Q VLAN Trunkを使用し、Tagでアクセス。
テスター: VeEX TX340s, 各パケットサイズ長 1ストリーム
- 全ポート負荷試験 64byteパケット長において、 Ethernet Flame は 95.37% の packet forwarding 性能 (約0.08%のパケットdrop, 4.63%のpacketがbit Error及びLost Frameとなった)
※ 0.08% drop から修正 (5/9)
- 全ポート負荷試験 72byteパケット長において、 Ethernet Flame は 100% の packet forwarding 性能。(IPv4 / Ethernet+IP header 相当のパケットフレーム長においてワイヤーレートの性能有り)
- IPv6 Layer 3 性能試験(92byte長)において、ハードウェア処理のため100%のIP Unicast routing 性能
- 1時間の100%負荷におけるヒートラン実施で異常な挙動は無し
- ACアダプタ:ACアダプタ12V 2A、Amazonで購入した物についてはPSEマーク有り、購入時期により付属してるACアダプタが異なる。
- 消費電力:無負荷7W, 8ポート10GLRでリンクアップ16W(1 SFPポートあたり最大1.5W程度が設計値)、負荷の有無にかかわらず消費電力に違いは無し
- SFP+ 10GBASE-Tの利用は2ポートまで可能(10GBASE-T モジュールあたり約3.5W程度)、10GLR/SRと併用して合計で20W、また、発熱により、エラーフレームが大量発生するため別途冷却が必要
- DACは認識しませんでした(ファームウェアの更新により解消するという記事もありましたが未確認)
- CLIはCisco Like.
- DHCPv6-PDの実装はあるが、クロスでアドレスは取得出来ず
- 10G/25G AOC Cable 認識OK、Link OK、25Gはmediaは25Gとして認識するが、interface status では、10Gとして認識
- Routed Portは使用出来ない為、SVIのみの実装
- Q-in-Q 64byteパケット長(2port) にて、ワイヤーレート/100%の性能。CPUは100%にならなかった
- VLAN Translation 64byteパケット長(2port) にて、ワイヤーレート/100%の性能。CPUは100%にならなかった
ということで、写真付き結果。
試験環境はこのような形で試験しました。
★ 10GBASE-T における消費電力及び試験結果:
- 10GBASE-T 2本を未接続、Link Down時 13.2W
- 10GBASE-T 2本を接続、Link Down時 16.3W
- 10GBASE-T 2本を接続、Link up時 19.5W
- 10GBASE-T 2本を使用時の試験 21W、FAN無しだと10GBASE-T及びその隣のポートでInterface Error発生、左からFANを当てた場合、右側のポートでErrorが発生。発熱による影響だと考えられる
★ Layer 2 試験結果(10GLR/SR使用):
試験構成: 各ポートにVLANを設定し、全ポート数珠つなぎになるような構成とした。全8ポート負荷試験とする。テスター側ははLoopbackモードでsrc/dst macを書き換えてテースターにトラフィックを戻し、正常に帰ってきたパケット数をカウントする全二重方向試験。
SFP+ Port 1: trunk port, tag vlan 100
SFP+ Port 2: access port, vlan 100 - SFP+ Port 3: access port, vlan 101
SFP+ Port 4: access port, vlan 101 - SFP+ Port 5: access port, vlan 102
SFP+ Port 6: access port, vlan 102 - SFP+ Port 7: access port, vlan 103
SFP+ Port 8: trunk port, tag vlan 103
Switch#show cpu utilization
Last 5 second CPU USAGE: 25%
Last 30 second CPU USAGE: 21%
Last 1 minute CPU USAGE: 21%
Last 5 minute CPU USAGE: 20%
From running CPU USAGE: 14%
Switch#
64byte Results
72byte Results
1本だけどうしてもエラーが出るOpticsを引いてしまい、十分な本数のOpticsを用意出来ず、単体で完全に0%ロスに出来なかったため、その点はご了承ください。
この結果には不満があるので、改めて後日再試験を予定しています。
★ Layer 3 / IPv6 Unicast Routing 試験結果:
SFP+ Port 1及びPort8をテスターに接続、SVIを作成し、access portとしてテスターと接続し負荷試験を実施した。
フレームサイズは最小のため、92byteパケット長で試験の実施。遅延時間も短く非常に良好。
SFP+ 2ポート(10GLR)使用、負荷試験時において、消費電力は10Wであった。
なお、スクリーンショットのカウンター値が一致していないが、細かく検証した際には、おおよそ一致していたた。おおよそというのは、ND/NDPパケットなど吐いている可能性があり、数パケット分の誤差が生じていたためである。
試験時間: 1分
参考に、1時間のヒートランしたときの結果。パケットの数がほぼ一致している。
Switch#show cpu utilization
Last 5 second CPU USAGE: 7%
Last 30 second CPU USAGE: 8%
Last 1 minute CPU USAGE: 7%
Last 5 minute CPU USAGE: 7%
From running CPU USAGE: 15%
Switch#
合格。CPU負荷も上がらず。
★ VLAN Translation 2port 64byte パケット長 試験:
構成:
Port 1: trunk port, vlan 2000を設定, テスターのvlanは2002を設定し、vlan-transrationで、2002を2000へ変換
Port 2: trunk port, vlan 2000を設定, テスターのvlanは2000を設定
64byte packet長による負荷試験
config
vlan 2000;2002
Interface Ethernet1/0/1
transceiver-monitoring enable
vlan-translation enable
vlan-translation 2002 to 2000 in
vlan-translation 2002 to 2000 out
switchport mode trunk
switchport trunk allowed vlan 2000
Interface Ethernet1/0/8
transceiver-monitoring enable
switchport mode trunk
switchport trunk allowed vlan 2000
スクリーンショットの通り、フルワイヤーレートが出ていること、転送されたパケット数が、スイッチの値とテスターの値が一致しており、十分な性能があることが確認できた。なお、試験中のスイッチのCPU負荷は10%程度にとどまっていたため、ハードウェア処理されていることが確認出来た。
★ 分解写真:
搭載しているチップを確認するために、分解をする必要があった。
しかし、ヒートシンクが搭載されており、これは半田付けされていた。
赤色の場所のハンダを落とさない限りヒートシンクは外せない。なお、25Wの半田ごてでは溶かすことが出来ず、40Wの物を用意した。
搭載されているチップは、
Realtek RTL9303(
Data Sheet)
で、以下の写真の通り。分解に時間がかかって大変だった。
★ ACアダプタ:
PSEマークはきちんと存在している。購入時期により入っているACアダプタが異なるようだ。
いずれも、12V 2A のACアダプタのΦ5.5の物であった。
★ スペック 及び ドキュメント類:
なお、
xikestorのサイトはは、日本のIPからアクセスすると、Products などに製品名が表示されない。
また、
Seekswanのサイトにて、
製品情報を中国語にて確認することが出来る。なお、英語ページは存在しない。
また、xikestor の方よりたどると、
xikestore Download Centerにて英語のドキュメント類がダウンロード可能。
seekswanより、マニュアル及びファームウェア類がダウンロード可能。
いつ消滅するか不明の為、
ミラーも作成した。
ファームウェアについては形式が不明だった。
[tomo@sv XikeStor_SKS8300-8X]$ hexdump -C SKS8300-8X-V1-V300SP10231222-C200117-U.img | head -n 20
00000000 80 92 a7 0d 16 18 79 34 23 ac 80 82 00 de e6 6f |......y4#......o|
00000010 d1 c6 27 7b 45 65 77 ff 90 1b 34 23 0a 04 7d 9c |..'{Eew...4#..}.|
00000020 14 23 32 0f 1d ac 02 30 43 55 23 1f 1c 4c 2b 7d |.#2....0CU#..L+}|
00000030 13 02 30 33 4a ab 34 5d 13 2b 3a 82 23 34 df ad |..03J.4].+:.#4..|
00000040 14 b3 24 00 ad ab 33 3d de ff 80 82 11 44 8b 9a |..$...3=.....D..|
00000050 5a 40 34 d1 02 30 12 34 23 ab ff ff ff ff 3b 9c |Z@4..0.4#.....;.|
00000060 94 e6 89 2d dd b6 b1 3d 0a c5 82 11 44 8b 9a 77 |...-...=....D..w|
00000070 1d e3 7d 23 02 ab 72 55 83 ab 80 82 01 ff 54 9a |..}#..rU......T.|
00000080 f2 37 6e 27 8d 1b ff ff 43 1b f0 32 ff ff 46 18 |.7n'....C..2..F.|
00000090 c2 23 7f 5f ad cd ff ff 66 3b f0 56 ff 32 76 1f |.#._....f;.V.2v.|
000000a0 4f 05 00 80 ad 89 00 00 90 24 00 ff 00 00 35 4f |O........$....5O|
000000b0 60 d0 00 00 ab 5a 00 00 36 43 ff ff 00 00 37 4e |`....Z..6C....7N|
000000c0 7f 70 ff 00 a6 df 00 ff 87 44 ff 00 88 00 85 4d |.p.......D.....M|
000000d0 2c 69 ff 00 ad ab 57 04 23 5b ff 42 51 3f 8b 3b |,i....W.#[.BQ?.;|
000000e0 72 29 89 00 ab 30 f3 54 ff ab 80 82 11 44 82 1a |r)...0.T.....D..|
000000f0 0f 94 ae 00 cd ea 68 34 ff ff ff ff 00 00 87 78 |......h4.......x|
00000100 a5 23 34 df 70 06 87 49 88 30 44 4c 00 de e5 3f |.#4.p..I.0DL...?|
00000110 b3 43 21 52 c5 8a 88 2f 9c 49 7b 4e 0f 09 7f 9d |.C!R.../.I{N....|
00000120 14 23 32 0f 1d ac 02 30 43 55 23 1f 1c 4c 2b 7d |.#2....0CU#..L+}|
00000130 13 02 30 33 4a ab 34 5d 13 2b 3a 82 23 34 df ad |..03J.4].+:.#4..|
[tomo@sv XikeStor_SKS8300-8X]$
★ Realtek RTL9303 Datasheet:
Realtek RTL9303 Datasheet を見ると以下の記載がある。一部抜粋する。
なお、データシートにはECMPが対応しているとは記載が無いため、ECMPは動作しないものと考えられる
メンドクサイので抜粋のみ。筆者が気になったところのみピックアップ。気になる方はデータシートを読んでネ(^_^)v。
つーか、「IP unicast routing supports Strict and loose uRPF checks and PBR (Policy-Based Routing).」とか対応してるってステキデスネ。
ブロック図
The RTL9303 has a 4K-entry VLAN table. It provides VLAN classification according to port-based, protocol-and-port-based, MAC-based, IP-subnet-based, Ingress VLAN translation and Flow-based capability. It also supports IVL (Independent VLAN Learning), SVL (Shared VLAN Learning), and IVL/SVL (both Independent and Shared VLAN Learning) for flexible network topology architecture. In network access applications it provides IEEE802.1ad (Q-in-Q) for double tag insertion and removal function. In addition, VLAN translation function is also supported for Metro Ethernet applications.
The RTL9303 supports 16K entries in a L2 MAC table with 2-left 4-way hashing algorithm. An independent 1K-entry Forwarding table is used to support Multicast functions, such as IGMP snooping.
The RTL9303 supports a 2K-entry VLAN/Ingress Access Control List (ACL). The ACL function supports L2/L3/L4 in IPv4/IPv6 protocols and performs configurable actions, such as Drop/Permit/Redirect/ Copy/Unicast Routing/Mirror/Logging/Policing/Ingress VLAN conversion/Egress VLAN conversion/QoS remarking/ VLAN tag status assignment. The RTL9303 supports per-port ingress/egress bandwidth control and per-queue egress bandwidth control.
L3 routing supports IPv4 unicast routing, IPv6 unicast routing, IPv4 multicast routing and IPv6 multicast routing. Routing table is mainly composed of L3 host table and L3 LPM table. L3 host table is shared by IPUC and IPMC, and is 2-left 6-way host table. Routing is the process of forwarding packets hop by hop on layer3. It primarily includes finding an outgoing interface and a next hop, modifying the packets’ SMAC, DMAC, VID (if provided), TTL, and L3 header checksum (for IPv4) and forwarding. The RTL9303 supports strict and loose uRPF.
・ 160Gbps switch capacity
L2 MAC Function
・ 16K-entry L2 MAC table
・ 2-left 4-way hashing algorithm
・ 2 hash algorithm selection for L2 table searching/learning
・ Source/Destination MAC filtering
・ Per port enables aging
・ Independent 1K entry Multicast table for L2/IP Forward function
・ 12Mbit SRAM Packet Buffer
・ Jumbo frame up to 12KB
Supports Link Aggregation (IEEE 802.3ad) for 64 groups of link aggregators with up to 8 ports per-group
・ Hardware trunk fail-over
・ Distribution algorithm can be based on SPP, SMAC, DMAC, VLAN ID, SIP, DIP, L4 source port, L4 destination port, Protocol ID and IPv6 Flow Label
OAM
・ 802.3ah OAM loopback
・ 802.3ah Dying Gasp
L3 Functions
・ IPv4/IPv6 unicast routing
・ 64 Router MAC
・ 6K-entry host table (6K IPv4/2K IPv6)
・ 2-left 6-way host table
・ 2 hash algorithm selection for host table searching
・ 512-entry LPM (Longest Prefix Match) table(512 IPv4/128 IPv6)
・ 2K next hop table
・ 128 Egress L3 interfaces
・ Supports uRPF (unicast Reverse Path Forwarding)
・ Supports PBR (Policy-Based Routing)
Access Control List (ACL) Function
・ Supports 2K shared entry for VLAN and Ingress ACL
・ Supports L2/L3/L4 format and user defined field
・ Supports 256 policer for traffic policing DLB/srTCM/trTCM
7.13.2. Ingress ACL
The Ingress ACL function supports functionalities similar to VLAN ACL. Differences between them are mainly determined by their lookup phase. For example, Inner VLAN translation function of VLAN ACL translates a packet before the ingress VLAN filter/L2/L3 process, but the function of ingress ACL is after the ingress VLAN filter/L2/L3 process.
7.14. L3 Unicast and Multicast Routing
Layer 3 routing supports IPv4 and IPv6 protocols. Routing is the process of forwarding packets hop by hop on layer3, it primarily includes finding an outgoing interface and a next hop, modifying the packets’ SMAC, DMAC, VID (if provided), TTL and L3 header checksum (for IPv4), and forwarding. L3 routing performs the source/destination IP lookups for IPv4 and IPv6 unicast and multicast packets.
7.14.1. IP Unicast Routing
L3 termination is initiated via a lookup in the Router MAC table. The L3 Host Routing Table is a 2-left 6-way host table, supports max 6K IPv4 entries or 3K IPv6 entries. When a look miss in the L3 host table LPM (Longest Prefix Match) table lookup occurs, it supports 512 IPv4 entries or 128 IPv6 entries. Once matched, a L3_NEXT_HOP entry is used to modify the packets, including outgoing interface and DMAIDX , and fully supports 2K next hop.
The Outgoing interface provides the packets’ SMAC, VID etc. information, and includes 128 interfaces. The DMAC and the outgoing port information should be retrieved from an L2 entry indexed by DMACIDX. Values in the MAC field of the L2 entry indicate the next hop’s MAC address, and are used to replace the packets’ DMAC field in the L2 header.
IP unicast routing supports Strict and loose uRPF checks and PBR (Policy-Based Routing).
★ 今後の検証予定:
- BGP、OSPF周りの試験、RIB/FIBあふれの時の挙動確認
- フレッツクロス環境でのIPv6 PD試験、及びパフォーマンス試験
幸いにもクロスが複数の占有回線があるため、PDで受けてテスターを回す予定
この価格帯で出てくるのはありがたいことですが、ファームウェア内部にバックドアが仕掛けられていないかとても気になります。
面白いデバイスを紹介してくださった、
seirios氏、ありがとうございます
★ 変更履歴:
- 5/7 64byteパケット長における転送性能の値を修正。0.08% drop → 4.63% drop and bit errorの為、正常なpacket frameは95.37%という結果に修正
- 5/15 Q-in-Q の結果および、VLAN Translation の結果を追加