QUICとNATと – JANOG48 Meeting場所 OHGAKI(完全リモート) 日時 Day3 2021年7月16日(金) 14:45～15:15(05分) 概要 RFC9000で標準化が完了したQUICはUDP443番ポートを使うプロトコルです。それが故にIPv4のNATルータとの間で起こる問題について考察したいと思います。 発表者 川上 雄也(NTTコミュニケーションズ株式会社) 公開資料 公開資料
VXLAN Routing の検証 - Qiita
モチベーション CLOS Network を想定した VXLAN/EVPNの動作を確認したい SDNコントローラ無しで 自立分散型の Overlay Network を実現したい Linux でどのように VXLAN/EPVN を実現しているか? CumulusLinux 上でconfigを投入し、Linuxのnetwork設定がどのように変更されているかを確認 サーバーエンジニアから見たら触れる機会が少ない(と思われる)ネットワーク技術を使ってみたい BGP, EVPN, VRF, Route Leaking など 何をやりたいか VXLAN/EVPNを使用したOverlay Networkで、異なるToR間における相互接続を検証する. 各ToR配下で稼働する物理サーバ上では異なるネットワークに属するVMやコンテナが動作していると仮定する. 動作確認したい点 VXLAN/EVPN の動作
RFC7938 - 大規模データセンター内でのルーティングのためのBGPの利用方法 - show log @yuyarin
はじめに この文書は RFC7938 - Use of BGP for Routing in Large-Scale Data Centers の日本語訳です。 翻訳者はデータセンターネットワークの専門家ですが翻訳の専門家ではありません。技術的な意味を維持した上でなるべく読みやすい日本語になるようにしているため、英文の直訳ではなく一部のニュアンスがかけている場合がありますのでご了承ください。オリジナルの目次、謝辞、参考文献等は省略しています。 免責 いつものやつ 目次 はじめに 免責 目次 概要 1. 導入 2. ネットワーク設計の要件 2.1 帯域とトラフィックのパターン 2.2 CAPEXの最小化 2.3 OPEXの最小化 2.4 トラフィックエンジニアリング 2.5 要件の要約 3. データセンタートポロジーの概要 3.1 従来のDCトポロジー 3.2 Closネットワークトポロジー
小規模（5〜20人）オフィスのネットワーク構築例
背景 株式会社マインディアCTOの@matsubokkuriです。 事業規模の拡大に伴いオフィスの移転がありました。それに伴い社内ネットワークインフラの構築しました。オンサイトで働く人は約10名。エンジニアは私1名なのでインフラ整備を自分でやるか外注するかという選択でしたが、外注するためにはRFP作るのが面倒だし費用がかかるのでDIYしました。 中小企業のネットワーク構築の記事は5年前の@wadapさんの記事が詳しいです。その記事以降、まとまった社内LAN構築の良い感じのノウハウ記事を見つけられませんでした。その5年の差分を埋めるためにも記録を書いておきます。 要求定義 ゲスト用ネットワークの分離（インターネット回線、LAN回線） 将来のシステム監査で指摘されるであろうことなので。 トラフィックのQoS制御のため。 インターネット上のホストにおいてグローバルIPアドレスによるアクセス制限が
クラウドでのネットワーク レイテンシの測定 | Google Cloud 公式ブログ
※この投稿は米国時間 2020 年 6 月 17 日に、Google Cloud blog に投稿されたものの抄訳です。 クラウド アーキテクトによく寄せられる質問の一つに、「2 つのエンドポイント間でリクエストとレスポンスをどの程度まで迅速に交換できるのですか？」というのがあります。ネットワークのラウンドトリップ レイテンシを測定するツールには ping、iperf、netperf などがありますが、すべてが同じように実装、構成されるわけではないため、ツールによって結果が異なる場合があります。ほとんどの場合、この質問に対する代表的な回答が得られるツールは、netperf であると考えられます。これからその詳細について説明していきます。 Google は、レイテンシ ベンチマークに関する実践的な経験を重ねてきました。このブログでは、Google とサザン メソジスト大学の AT&T Cen
MACアドレスの再利用は、みんなが思っているよりもはるかに一般的:Geekなぺーじ
MACアドレスは、原則として、一意に割り当てられるものです。 ネットワークインターフェースごとに、ひとつずつユニークな値をベンダーが付けるものとされています。 ただ、これは、あくまで「原則として」であって、実際は、MACアドレスが重複することもあります。 IPv6に関連するいくつかのRFCで、MACアドレスの重複への言及があります。 この記事では、MACアドレスの重複とIPv6アドレスの自動生成という、わりと限定された視点ではありますが、MACアドレスが一意とは限らない、という話を紹介します。 なお、この記事のタイトルである「MACアドレスの再利用は、みんなが思っているよりもはるかに一般的」は、RFC 7217に書かれている一文の日本語訳です。 MACアドレスの重複とIPv6アドレス生成の仕様 MACアドレスがIPv6アドレスの自動生成で使われる場合があります。 IPv6アドレス体系のRF
A Deep Dive into Iptables and Netfilter Architecture | DigitalOcean
As a packet triggers a netfilter hook, the associated chains will be processed as they are listed in the table above from top-to-bottom. The hooks (columns) that a packet will trigger depend on whether it is an incoming or outgoing packet, the routing decisions that are made, and whether the packet passes filtering criteria. Certain events will cause a table’s chain to be skipped during processing
EdgeRouter X のロードバランサーで v6 プラスと PPPoE を併用する – ちとくのホームページ
構成v6 プラスに対応したルーターは JPNE のメーカー確認機種一覧3を参考に用意します。 接続EdgeRouter は eth0 から VDSL モデム、eth1 から v6 プラスルーターに直結しています。 VDSL モデム と v6 プラスルーターは別々のサブネットになるように構成します。 PPPoE 接続時のルーティングこの構成で PPPoE に接続するときは次の経路でルーティングします。 EdgeRouter（192.168.1.1/24）→ VDSL モデム（192.0.2.2/30）→ IPv4 v6 プラス接続時のルーティングv6 プラスで接続するときは次の経路でルーティングします。 EdgeRouter（192.168.1.1/24）→ v6 プラスルーター（192.0.2.6/30）→ IPv6 この経路では IPv6 へのカプセリングが v6 プラスルーターで行われ
Overlay&Underlay Network 僕の思い出 - Speaker Deck
All slide content and descriptions are owned by their creators.
TCPを（少しは）理解しておくべきその理由 | POSTD
この記事はTCPの 全て を理解する、あるいは 『TCP/IP Illustrated』 （訳注：日本語版: 『詳解TCP/IP〈Vol.1〉プロトコル』 ）を読破しようとか、そういうことではありません。ほんの少しのTCPの知識がどれほど欠かせないものなのかについてお話します。まずはその理由をお話しましょう。 私が Recurse Center で働いているとき、PythonでTCPスタックを書きました（ またPythonでTCPスタックを書いたらどうなるかについても書きました ）。それはとても楽しく、ためになる経験でした。またそれでいいと思っていたんです。 そこから1年ぐらい経って、仕事で、誰かが「NSQへメッセージを送ったんだが、毎回40ミリ秒かかる」とSlackに投稿しているのを見つけました。私はこの問題についてすでに1週間ほど考え込んでいましたが、さっぱり答えがでませんでした。 こ
本当に恐ろしいsnmpd - Qiita
昨今の Linux での仮想マシン、コンテナの使われ方をみるに、一つのマシンの中で netdev がたくさん存在するケースは普通になってきたと思う。そんな状況で見かけた恐ろしい現象。 snmpd を起動させるだけで CPU 100% で回り始める。 再現方法は後述するけれども、調べてみると、同様の現象に見舞われている人たちがみつかる。中でも詳しいのはこの記事 で、巨大な BGP routing table を持つシステムの例と、数千の VLAN を持つ例も同様なんだそうな。原因は定期的なキャッシュ更新で、ipaddress, netdev の数に対して、爆発的に増大するアルゴリズムが使われているため。私も調べてみた限りでは、手っ取り早く設定ファイルで抑制する方法は存在しない。 単純に時代の変化で、net-snmp snmpd が作られたころと今とで想定数が異なるんだろうな、というのは理解で
上位ISPで発生したとみられる通信障害についてまとめみた - piyolog
2018年10月4日夜にネットワーク上の障害により、サービス継続に支障が生じたと報告する運営元や、同時間帯にWebサイトなどに接続が出来なかったとするユーザーの報告が出ています。ここではこれら情報をまとめます。 尚、piyokangoはこれら複数の障害を結びつける確定的な情報は確認できていません。 障害発生、あるいはその可能性があるサービス 以下のいずれかの条件に基づき、障害が発生、あるいは発生していた可能性があるサービスを調べました。 (1) 障害発生を報告し、上位ISP、あるいは上位ネットワークで発生した障害を理由としてたサービス (2) 公式発表は確認できないが(1)の障害が発生した同時間帯に接続障害が報告されていたサービス 「同時間帯」として9月27日から10月5日に発生、または報告されたものを対象とした。 運営元 対象時間 ソース ノート セガゲームズ 2018年9月27日 13
Kubernetes: Flannel networking
This article explains how flannel network works in Kubernetes Kubernetes is an excellent tool for managing containerized applications at scale. But as you may know, working with kubernetes is not an easy road, especially the backend networking implementation. I have met many problems in networking and it cost me much time to figure out how it works. In this article, I want to use the most simple i
net.ipv4.tcp_tw_recycle は廃止されました ― その危険性を理解する - Qiita
Disclaimer 私はネットワークの勉強もちゃんとしたことないし、Linux のソース読むのもはじめてな素人です。 何かおかしなところなどあれば、遠慮なくコメント欄でまさかりをお願いいたします。 ソースコードの引用に関して 本文中で Linux のコード／ドキュメントを引用している箇所がありますが、すべてタグ v4.11 のものです。また、日本語のコメント・翻訳文は筆者が入れたものです。 TL; DR Linux のカーネルパラメータ net.ipv4.tcp_tw_recycle は、バージョン4.12から廃止されました。 今後はこの設定は行わないようにしましょう（というかできません）。 一方、net.ipv4.tcp_tw_reuse は安全であり、引き続き利用できます。 …というだけの話なのですが、自分用にメモがてら経緯・背景などを記録しておきます。 なんで気がついたか このパラ
HTTP/2における双方向通信とgRPCとこれから - Qiita
この記事は 第2のドワンゴ Advent Calendar 2017 最終日の記事です。 はじめに ウェブ技術を語る上で欠かすことのできない要素として、HTTPがある。 従来のHTTP/1を無くして、ここまでのウェブの発展はなかったといえるだろう。言うまでもなく、HTTP/1が我々人類に齎した功績は大きい。 しかしその一方で、その規格のシンプルな原理原則に縛られた結果、要件を達成するために非効率なネットワーク使用を前提とするシステムが量産されるなど、HTTP/1がもたらした技術的負債も存在する。 その中の一分野として、双方向通信に着目したときに、HTTP/1からHTTP/2へのアップグレードによってどのような変化がもたらされたか。 本稿ではHTTP/2という規格と、それが持つ可能性の一端としてgRPCについての仕組みを紹介し、従来とこれからのWeb開発における双方向通信について述懐する。
インターネットは当初目指したものではなくなってしまった:Geekなぺーじ
NANOG 68のDesperately Seeking Defaultという発表にて、APNICのGeoff Huston氏が、いまのインターネットはかつてエンジニア達が目指したものとは違うものになってしまったと表現しています。 この発表が行われたNANOG 68(2016年10月17日)は、ネットワークエンジニアが集まるイベントであるため、ここで言う「我々」というのは、主にネットワークエンジニアを指しています。 IETFでもそういう雰囲気があるのですが、「我々がインターネットを作っている」という自負がある人々が会場内に多いです。そういった空気感がある「場」での発表です。 発表そのものは、インターネットを運用する際に見える「経路」は組織によって異なり、インターネットでは互いに通信ができないネットワークがあるという話です。 「Default」の経路として提供されるものが異なり、インターネッ
自律分散監視システムとそれを利用したネットワークグラフ可視化への挑戦 - Hatena Developer Blog
はじめに はてなサマーインターン2017の大規模システムコースの成果報告をします。 今年の大規模システムコースではメンターのid:masayoshiさんとid:y_uukiさんの下、自律分散監視システムとそれを利用したネットワークグラフの可視化に取り組みました。自律分散監視システムでは単純なクラスタリングによる死活状況の確認だけではなくアプリケーションレベルの疎通確認を行えるものを実現しました。またどのようにしてクラスタを形成するかという問題に取り組む内に、サービス間のネットワーク上のつながりを取得できるようになり、その情報でサーバー間の関係性の可視化を行いました。この記事では、それらの詳細を説明します。 はじめに 自律監視システムの実現 中央サーバー型の監視システム 自律分散監視システム アプリケーションレベルの相互監視 どうやってクラスタを形成するか？ 実験 ネットワークグラフの可視化
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Calico Route Refelctors
モンスターストライクのリアルタイム通信を支える技術
HTTP and 5G partial draft
