Interop 2023のShowNetバックボーン詳解:Geekなぺーじ
Interop Tokyo 2023のShowNetバックボーンに関して、ShowNet NOCの中村遼さんからの寄稿を頂きました。 詳細であり、かつ、わかりやすい素晴らしい解説、ありがとうございます！ 2023年のInterop Tokyo ShowNetにおいて、ルーティングという観点からの見どころはおおきく2つです。 SRv6によるバックボーンネットワーク EVPN-VXLANによるユーザ収容ネットワーク それぞれの技術の概要と、2023年のShowNetのどこでどう使われているか、ShowNet名物の一つ、トポロジー図から見ていきます。 SRv6によるバックボーンネットワーク Segment Routingは、ネットワーク上のあらゆる要素、たとえばノードやノード同士の隣接関係、そしてサービス等を、Segment Identifer (SID)と呼ばれる識別子で表現し、転送するパケッ
IPv4アドレスが枯渇して10年経った:Geekなぺーじ
日本時間2011年2月3日深夜に、IPv4アドレスの中央在庫(IANA在庫)が枯渇しました。 もう、あれから10年です。 JPNIC : IANAにおけるIPv4アドレス在庫枯渇、およびJPNICの今後のアドレス分配について(2011年2月) 昔は、「IPv4アドレスは枯渇しない」と主張している人も多く、実際に枯渇するまでは、IPv4アドレス在庫が減り続けていることを信じない人も多かった記憶があります。 都市伝説だ、とか、石油と一緒で枯渇しない、といった主張がありました。 IPv4アドレス在庫の枯渇がどのように定義されているのかが複雑であるためわかりにくかったり、インターネットが使えれば良くてTCP/IPそのものには興味がない人が大半であるなどの要因もあり、いまだにIPv4アドレス在庫が枯渇したことを知らない人も多くいますが、気がつけばIPv4アドレスが枯渇してから10年経過しているわけで
MACアドレスの再利用は、みんなが思っているよりもはるかに一般的:Geekなぺーじ
MACアドレスは、原則として、一意に割り当てられるものです。 ネットワークインターフェースごとに、ひとつずつユニークな値をベンダーが付けるものとされています。 ただ、これは、あくまで「原則として」であって、実際は、MACアドレスが重複することもあります。 IPv6に関連するいくつかのRFCで、MACアドレスの重複への言及があります。 この記事では、MACアドレスの重複とIPv6アドレスの自動生成という、わりと限定された視点ではありますが、MACアドレスが一意とは限らない、という話を紹介します。 なお、この記事のタイトルである「MACアドレスの再利用は、みんなが思っているよりもはるかに一般的」は、RFC 7217に書かれている一文の日本語訳です。 MACアドレスの重複とIPv6アドレス生成の仕様 MACアドレスがIPv6アドレスの自動生成で使われる場合があります。 IPv6アドレス体系のRF
RFC 8501 : Reverse DNS in IPv6 for Internet Service Providers:Geekなぺーじ
TOP > ブログ > RFC 8501 : Reverse DNS in IPv6 for Internet Service Providers IPv4では、すべてのIPv4アドレスに対する逆引きとしてIN-ADDR.ARPAによるPTRレコードをDNSサーバに登録するといった運用が一般的に行われてきました。 しかし、各ネットワークセグメントごとに/64を割り当てるIPv6では、同様の運用を行うことは非現実的です。 ISP(Internet Service Provider)がIPv6での逆引きを扱う際のアプローチなどをまとめたInformationalなRFCとして、RFC 8501が2018年11月に発行されています。 この文章は、RFC 8501に記載されている内容を要約しています。 詳しくは、原文をご覧ください。 PTRレコードの主な用途 RFC 8501の4章で、DNSの逆引
すごいIPv6本を無料配布！:Geekなぺーじ
2021年12月20日追記：第2版できました！ IPv6を解説した「プロフェッショナルIPv6」をラムダノート株式会社から出版しました。 初版は456ページになりました。紙版の厚さは23mmになる予定です。 現時点で、IPv6に関して世界で最もまとまっているIPv6本であると個人的に考えています。 「プロフェッショナルIPv6」は、株式会社日本レジストリサービス様、BBIX株式会社様、NTTコミュニケーションズ株式会社様、日本ネットワークイネイブラー株式会社様、クラウドファンディング(「すごい技術書を一緒に作ろう。」という企画です)でのみなさまによるサポートにより実現しました。 IPv6に関する技術情報を広く公開するという趣旨に賛同いただき、本書の執筆と制作、公開にあたって多大な協賛をいただきました。ありがとうございます！！！ 「プロフェッショナルIPv6」は、通常の書籍として5000円で
TCAMと同等以上の性能をソフトウェアで実現したBGPルータ＠Interop Tokyo 2018:Geekなぺーじ
Latency Numbers Every Programmer Should Know より 今回、Kamueeで使われている機材でのCPUキャッシュ参照にかかる時間は、上記値とは異なりますが、メインメモリ参照がCPUキャッシュ参照と比べて著しく遅いことは変わりません。 （Intel 64とIA-32アーキテクチャのCPUでの値(単位はサイクル)は、「Intel 64 and IA-32 Architectures Optimization Reference Manual」のp.54参考にしてください。） 100Gbpsの性能をPCアーキテクチャの機材で稼働するソフトウェアで実現するために、CPUキャッシュに収めることが非常に大事なのです。 そして、CPUキャッシュに収まるようなサイズに経路情報を扱うデータを圧縮して収めることで高速化ができるのは、メインメモリからの読み込みが頻繁に発生
アカマイの新たなバックボーンネットワーク:Geekなぺーじ
RIPE 75のライトニングトークで、アカマイが、自社トラフィックを運ぶための専用バックボーンネットワークを構築していることを発表しました。 Christian Kaufmann - ICN Akamai 発表資料(PDF) アカマイは、ユーザに近いところにCDN用のキャッシュサーバを置くために、世界各地に拠点を構築しています。 そういった拠点は、たとえば、ISPの中に構築されたりしています。 これまで、アカマイは拠点間の通信にはパブリックなインターネットを利用していました。 発表では、個々に孤立していたことを示すために各拠点を「島 (islands)」と表現しています(islandsという表現は、RFC等でも割と良く使われます)。 世界中の様々なAS内に拠点を築き、その拠点間トラフィックもパブリックなインターネットを利用していたことは、アカマイの非常に大きな特徴であったとも言えます。 し
NATのせいで犯罪者が特定できないという問題提起がEUで行われる:Geekなぺーじ
欧州刑事警察機構(Europol)のプレスリリースにて、ISP等で運用されるCGN(Carrier Grade NAT/大規模NAT)が犯罪捜査の妨げになっていると述べられています。 Europol: Are you sharing the same IP address as a criminal? Law enforcement call for the end of Carrier Grade NAT (CGN) to increase accountability online Europolのプレスリリースによると、欧州連合理事会(EU Council)の今期議長国であるエストニアとEuropolが共同でCGNの問題に関するワークショップを開催したとあります。 ワークショップには、EUのポリシーメーカーや法執行機関当局者35名が参加しました。 さらに、Europolの技術的なパー
インターネットは当初目指したものではなくなってしまった:Geekなぺーじ
NANOG 68のDesperately Seeking Defaultという発表にて、APNICのGeoff Huston氏が、いまのインターネットはかつてエンジニア達が目指したものとは違うものになってしまったと表現しています。 この発表が行われたNANOG 68(2016年10月17日)は、ネットワークエンジニアが集まるイベントであるため、ここで言う「我々」というのは、主にネットワークエンジニアを指しています。 IETFでもそういう雰囲気があるのですが、「我々がインターネットを作っている」という自負がある人々が会場内に多いです。そういった空気感がある「場」での発表です。 発表そのものは、インターネットを運用する際に見える「経路」は組織によって異なり、インターネットでは互いに通信ができないネットワークがあるという話です。 「Default」の経路として提供されるものが異なり、インターネッ
「ひとりで何でもできるエンジニア」と時代背景:Geekなぺーじ
インターネットそのものが「新しいもの」であったころは、インターネットそのものとともにITエンジニアが成長できました。未踏な領域に踏み込む冒険心をくすぐられるミッションが、そこら中に転がっていました。「できなくてツラい」と苦しみつつも、マゾ的に心を踊らせチャレンジする環境がありました。 インターネットを利用することが珍しいことではなくなり、インターネットを活用したビジネスを実現するためのエンジニアリングの分業化も進みました。それに伴い、IT系エンジニアに求められる技能が細分化しており、「必要に応じて全部やる」ことが求められない環境も非常に多くなっています。 そういった環境の変化もあり、「昔と違って何でもできる人は育ちにくくなっている」という感想を持っている人も結構多い印象です。私の周りで「ひとりで何でもできるんじゃないかと思えるほど守備範囲が広いエンジニア」と私が思う凄い人々は、インターネッ
「ひとりで何でもできるエンジニア」は勝手に育つ:Geekなぺーじ
「スタートアップベンチャーはスーパーエンジニアを求めるけどエンジニア界隈と起業家界隈で想像しているスーパーエンジニアの定義が違う件」という記事が話題です。 その中で、「「ひとりで何でもできるエンジニア」は存在しないと思った方が良い」」として、以下のように書かれています。 「ひとりで何でもできるエンジニア」は存在しないと思った方が良い」 起業家の方が知らない側面として 現在バリバリ活躍しているエンジニアのほとんどが得意領域を持っていて それ以外の分野については出来る人であっても「平均点以上」ぐらいの活躍しか出来ないということです。 そして優秀なエンジニアの方はそのことをよくわかっています。 たまに化け物みたいな化け物がいて物理からインフラからアプリケーションからUI/UX ネイティブアプリ開発からwebマーケティングに資産管理まで全部出来ちゃう人もいますが その人を望む事は「年収1000万の
RFCは、なぜ「意見募集」という名前だったのか？:Geekなぺーじ
インターネットで使われる各種仕様の多くは、RFCと呼ばれる文書として発行されています。 RFCは、「意見募集」や「意見を求む」といった意味を持つRequest For Commentsの略ですが、インターネットに関連する通信仕様の標準を示す文書の名称が、なぜ意見を募集するとなっているのでしょうか？ それには、初期のRFCが発行された時代背景があるのです。 RFCの文書番号は新しい文書とともに増加していくので、基本的に文書番号が小さいほど昔のものになります。 最初のRFCである、RFC 1は、1969年4月7日に発行されています。 多少余談になりますが、RFC 1は、「インターネット」という単語が生まれる前に発行されています。 「インターネット（internet）」という単語が初めて登場するRFCは、1974年に発行されたRFC 675です。 1973年に発行されたRFC 604とRFC 6
Geekなぺーじ : Tier1 ISPは「秘密結社」か？
NIKKEI NET IT+PLUSに「払ったりもらったり、力で決まるISPの接続料 インターネットのお値段（２）」という記事が掲載されていました。 基本的には書いてある事は正しい気がするのですが、最後の部分が結構ひどいと思いました。 以下、引用です。 ■ティア1は「秘密結社」 それなると、もらう一方のティア１は大もうけですね。 「そうですね（笑）。ティア１のISPはティア１同士で接続しており、世界の主要なISPへとつながっています。NTTコム傘下の米ベリオなどが知られていますが、実は事業者のすべての名前が明らかになってはいないなど、ベールに包まれた『秘密結社』なのです」 オープンと考えていたインターネットの中核が秘密結社というのは驚きです。 「これにはインターネットの成り立ちが関係しています。始めは限られた人たちが相互に助け合う精神でスタートしたのですが、有料ISPが登場し利用者が増えた
TCPだけでDNSサーバにqueryできるようになってた:Geekなぺーじ
DNSメッセージといえばUDPの53番というイメージの方々も非常に多いと思いますが、1987年に発行されたRFC 1035の時点でDNSメッセージのトランスポートとして利用できるのはUDPとTCPであると記述されています。 しかし、これまでDNSにとってはUDPが基本でした(ゾーン転送を除く)。「RFC 1123: Requirements for Internet Hosts」には、以下のようにあります。 DNS resolvers and recursive servers MUST support UDP, and SHOULD support TCP, for sending (non-zone-transfer) queries. Specifically, a DNS resolver or server that is sending a non-zone-transfer
地雷警報としての「一度お会いしてお話をうかがいたい」:Geekなぺーじ
ビジネスを前提としつつ「一度お会いしてお話をうかがいたい」という話は、比較的どこにでもあります。フリーランスだと特にそういったことがありがちではないでしょうか。 私もフリーランスになって7年目になるのですが、そういったお話を頂くことが多いです。しかし、いくつかそういった話を経験すると、それがどのように表現されるかで相手が地雷であるかどうかを推測するようになりました。「一度お会いして話をうかがいたい」といって呼び出しておいて、散々ノウハウ情報を引き出そうとしたあげくに「ありがとうございました。さようなら」とか、「次に面白い人を紹介してください」と言う人があまりに多いのです。 一方で、実際に案件を依頼するかどうかを考える状態の発注者側が、外注側を呼び出す側の気持ちもわからなくもないです。「一度お会いしたい」というのは、要は相手がどういった人物であるかのチェックを主目的としていることも多いのです
BGPフルルートは必要か？GREEの事例:Geekなぺーじ
「インターネットに接続された全てのネットワークへの経路」であるBGPのフルルート(Full Route)を「ネットワークエンジニアの夢」と表現するネットワークエンジニアもいます。INTEROP Tokyo 2014のShowNetでも、あえてフルルートを受け取らないAS運用がテーマのひとつでした。 さて、そんなフルルートですが、「それって本当に必要なの？夢とかロマンとか感情的な話じゃなくて、現実問題として必要なの？」といった方向性の議論がコンテンツ事業者などの間で増えつつあります。 今回は、2年前にフルルート運用から脱却したグリー株式会社インフラストラクチャ本部の黒河内倫氏に、何故フルルートの運用をやめたのかや、それによって何が変わったのかを伺いました。 フルルートを捨てる決断を促した障害 GREEがフルルートを捨てる決断をしたのは、2年前、2012年の夏に発生した障害が原因でした。当時G
BGPルータの512K問題について:Geekなぺーじ
インターネットでの通信障害を発生させた「BGPルータの512K問題」が一部界隈で話題です。今回は、それがどういった問題で、それが発生する背景がどのようなものであるかを紹介します。 インターネットの仕組みとBGP インターネットは、AS(Autonomous System/自律システム)という単位で運営されていますが、AS同士はBGPという経路をやり取りするプロトコルを利用して互いに接続することで成り立っています。BGPは、伝言ゲームのように「私の隣に○○というASの××というネットワークがある」という情報を伝えて行くものです。世界中のASが伝言ゲームに参加することによって、世界中のASへの到達方法を共有しているのがインターネットなのです。 BGPによって集められた、世界中のASに含まれるネットワークへの経路を全て(もしくは全てと推測される規模の)経路情報は「フルルート(Full Route
8.8.8.8に対するBGPハイジャックの話:Geekなぺーじ
一昨日書いた記事に対する補足です。 まず、最初にBGPハイジャックそのものは、世界各所で毎月のように発生しており、別に珍しくもない話です。 そのほとんどが、意図的にトラフィックを乗っ取る目的で行われたものではなく、単なるオペレーションミスであると言われています。 BGPハイジャックで有名なのが、2008年にYouTubeへのトラフィックをパキスタンのISPが吸い込んでしまった事件(参考：RIPE-NCC: YouTube Hijacking: A RIPE NCC RIS case study)ですが、これも意図的にやったのではなく、パキスタン国内向けのネット検閲設定が外部に漏れてしまったというオペレーションミスだったと思われます。 オペレーションミスは、漏らしてしまった側だけではない可能性もあります。 そもそも、/32などのプレフィックス長を持つ経路はフィルタされていることが多いので、普
Google Public DNSがBGPハイジャックされる:Geekなぺーじ
ブラジルとベネズエラのネットワークで、Google Public DNSが運用されている8.8.8.8が、最大22分間BGPハイジャックされたとBGPmonがTwitterで表明しています。 https://twitter.com/bgpmon/status/445266642616868864/photo/1 BGPmonのTweetによると、ベネズエラにあるAS7908(BT LATAM Venezuela,S.A.)が8.8.8.8/32を広告したことが原因のようです。 ブラジルといえば、ブラジル国民のデータをブラジル国内に留めることを求めた法律が成立したことによって、昨年10月に同国からGoogle Public DNSが撤退しています(Renesys: Google DNS Departs Brazil Ahead of New Law)。 実際のところは知りませんが、その撤退に
前代未聞？RFC 7158が一瞬で廃止されてRFC 7159に！:Geekなぺーじ
3月2日より、ロンドンにてIETF 89が開催中ですが、IETFでRFC 7158が一瞬で廃止されるという珍事が発生しました。 どうも、2014年3月と記載すべきところを2013年3月としてしまったので、それを修正するためにRFC 7159が発行され、RFC 7158は即座に廃止されています。 RFC 7158とRFC 7159のdiffを見ると、見事に2013と2014の違いしかありません。 しかし、「本当にこれだけの違いで大丈夫なの？」と思える部分もあります。 たとえば、「Status of This Memo」Errataを記載する部分がRFC 7159において、Errataを「http://www.rfc-editor.org/info/rfc7158」としているのですが、正しくは「http://www.rfc-editor.org/info/rfc7159」だと思われます。 また
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
