softflowdのデータ構造

softflowdのデータ構造 softflowdは、筆者がメンテナンスしているソフトウェアですが、元々はDamien Millerという方がオリジナルの作者です。 そのため、自分があまりきちんと把握せずにメンテしている部分もあります(正確に言うと自分で書いていないから忘れてしまう)。そのあまりきちんと把握していない部分にsoftflowd内部で使われているFlowのメモリ管理がわからなくなったのでコードを読み直して調べなおしました。そのメモです。 分析したのはsoftflowd.hのFLOWTRACK構造体です。 struct FLOWTRACK { /* The flows and their expiry events */ FLOW_HEAD (FLOWS, FLOW) flows; /* Top of flow tree */ EXPIRY_HEAD (EXPIRIES, EXPIRY) expiries; /* Top of expiries tree */ struct freelist flow_freelist; /* Freelist for flows */ struct freelist expiry_freelist; /* Freelist for expiry events */ struct FLOWTRACKPARAMETERS param; }; freelist リストを実現する構造体です。一定のエントリ数分まとまってメモリ領域を確保するようになっており単純なリストに比べて連続した領域をとるようになっています。freelist.hで定義されているstruct freelistは以下の内容です。 struct freelist { size_t allocsz; size_t nalloc; size_t navail; void **free_entries; }; allocszはallocate sizeの略と想定され、free_entriesが指し示す先の各エントリのサイズを意味しています。 softflowd....

February 3, 2024

geneve-oamを調べてみた

VXLAN-OAMや、IOAMを調べている間に、GENEVEのOAM(https://datatracker.ietf.org/doc/draft-ietf-nvo3-geneve-oam/)とVXLAN BFDを規定したRFC8971を発見した。この2つのドキュメント2名の著者が重複している。( G. Mirsky氏(ZTE→Ericsson), S. Pallagatti(vmware))。

January 8, 2024

IOAMを調べてみた(2)

In-Situ OAMと既存プロトコルの関係 前回見たIOAMのデータ構造は様々なプロトコルの埋め込みが検討されている。 RFC9378の5章に記載があるのが以下のプロトコルである。 IPv6: RFC9486 NSH: RFC9452 BIER: https://datatracker.ietf.org/doc/html/draft-xzlnp-bier-ioam GRE: https://datatracker.ietf.org/doc/html/draft-weis-ippm-ioam-eth : : Expire(2022/8/25) GENEVE: https://datatracker.ietf.org/doc/html/draft-brockners-ippm-ioam-geneve : Expire(2021/5/23) SR: https://datatracker.ietf.org/doc/html/draft-gandhi-mpls-ioam SRv6: https://datatracker.ietf.org/doc/html/draft-ali-spring-ioam-srv6 : Expire(2023/1/10) VXLAN-GPE: https://datatracker.ietf.org/doc/html/draft-brockners-ippm-ioam-vxlan-gpe IPv6とNSHはStandard RFCで、それ以外は今のところ個人ドラフトである。 IPv6は既にLinuxに実装されている。以下のリンクが参考になる。IOAMの強みは実装が既にあることである。 https://github.com/torvalds/linux/commit/7C804E91DF523A37C29E183EA2B10AC73C3A4F3D#diff-2057966913dd51af9650a4c3dd9900811631e93961b0ad48e78d74026e1b726a https://zenn.dev/shu1r0/articles/0e8e0d79ea75e9 RFC9259がある中でSRv6がExpireしているのが意外であるが、RFC9486のIPv6のIOAMを併用すればSRv6環境でも使えるだろうし、そもそもuSID(Compress SID)でSRHを使わない環境が多くなっていくとするとSRHで実現する必要性も薄い。(議論の経過は追いかけていないので勝手な推測である。) VXLAN-GPEのDraftも、03は2020/5/7にExpireしており、04が2023/11/26に作成されているところを見ると、他のプロトコルも突然更新がされる可能性もある。 GENEVEもExpireしているのでVXLAN-GPE用のIOAMを調査してみる。なおVXLAN-GPEは(NVO3の標準はあくまでGeneveであるため)Informational Trackで進んでいるのにもかかわらず、VXLAN-GPE用のIOAM個人ドラフトはStandard Trackで進んでいる。 VXLAN-GPEのIOAMのOSS実装はVPPで行われている。 https://github.com/FDio/vpp/blob/master/src/plugins/ioam/lib-vxlan-gpe/ VXLAN-GPE用のIOAMヘッダ構造はVXLAN-GPEヘッダも含めて記載では以下の通りになる。 VXLAN-GPEヘッダのNext PotocolはIOAMを示す0x81(提案ドラフトの提案値)で、RFC9305(LISP-GPE)に対する提案値と同一である。 IOAMのヘッダ構造構造(IOAM-Type, IOAM HDR len, Reserved, Next Protocolの並び順)は、NSH用のIOAM(RFC9452)と同一になっている。 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outer Ethernet Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outer IP Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outer UDP Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+ |R|R|Ver|I|P|R|O| Reserved | NP=TBD_IOAM | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GPE | Virtual Network Identifier (VNI) | Reserved | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ | IOAM-Type | IOAM HDR len | Reserved | Next Protocol | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I !...

January 8, 2024

IOAMを調べてみた(1)

In-Situ OAM 過去のNVO3での提案は802.1agをもとにした方式が提案されたいた。一方最近は、IETFの計測系WGであるIPPM(IP Performance Metric) WGでIn-Situ OAMが積極的に標準化されている模様である。WikipediaによるとIn-Situ(イン・サイチュ)とはラテン語で「その位置において」ということらしい。 RFC 9197 - Data Fields for In Situ Operations, Administration, and Maintenance (IOAM)と、 RFC 9378 - In Situ Operations, Administration, and Maintenance (IOAM) Deploymentを読むのがよさそうである。 IOAMの種類は以下の4つのオプションタイプ。 ホップ毎トレース(Per-hop tracing) 事前確保済み形式(Pre-allocated) 増分形式(Incremental) トランジット証明(Proof of Transit) エッジツーエッジ(E2E: Edge-to-Edge) 直接エクスポート(DEX: Direct Export) ホップ毎トレース オプションタイプ RFC9197によるとPre-allocated and Incremental(事前確保済み及び増分の)Trace-Option Header用には以下のデータフォーマットが定義されている。 ヘッダ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Namespace-ID |NodeLen | Flags | RemainingLen| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IOAM Trace-Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ データ...

January 7, 2024

vxlan-oamを調べてみた

Overlayで利用できるOAMは今どんな手段が標準議論されているのかを調査しました。 draft-tissa-nvo3-oam-fm-04 VXLANをはじめとするNVO3でのOAM提案は、過去にdraft-tissa-nvo3-oam-fm-04があったが2017/11/6Expireしている。筆頭はCisco、Huawei所属の人も連名である。実装的にはCisco NexusのNX-OSのみの実装と思われる。 また、RFC7455: Transparent Interconnection of Lots of Links (TRILL): Fault Management , RFC7456: Loss and Delay Measurement in Transparent Interconnection of Lots of Links (TRILL)も参照しており、TLVのTypeなどは再利用していることになっている。 ドキュメントの随所にIEEE802.1Qの記載があり、基本的な概念はIEEE802.1Q/IEEE802.1agから持ってきている。 登場する代表的な用語は以下で基本的にはIEEE802.1Qから持ってきている。 用語 意味 MP Maintenance Point [8021Q] MEP Maintenance End Point [8021Q] MIP Maintenance Intermediate Point [8021Q] MA Maintenance Association [8021Q] MD Maintenance Domain [8021Q] CCM Continuity Check Message [8021Q] LBM Loop Back Message [8021Q] PTM Path Trace Message MTV Multi-destination Tree Verification Message ISS Internal Sub Layer Service [8021Q] SAP Service Access Point [8021Q] OAMのビットは、先頭から8bit目である。(https://datatracker....

January 7, 2024

holo routingを動かす(2)

前回の続きでholo-cliでOSPFの状態を見てみました。 holo-cli -c "show state xpath /ietf-routing:routing/control-plane-protocols" root@rt1:/# holo-cli -c "show state xpath /ietf-routing:routing/control-plane-protocols" { "ietf-routing:routing": { "control-plane-protocols": { "control-plane-protocol": [ { "type": "ietf-bfd-types:bfdv1", "name": "main", "ietf-bfd:bfd": { "summary": { "number-of-sessions": 0, "number-of-sessions-up": 0, "number-of-sessions-down": 0, "number-of-sessions-admin-down": 0 }, "ietf-bfd-ip-mh:ip-mh": { "summary": { "number-of-sessions": 0, "number-of-sessions-up": 0, "number-of-sessions-down": 0, "number-of-sessions-admin-down": 0 } }, "ietf-bfd-ip-sh:ip-sh": { "summary": { "number-of-sessions": 0, "number-of-sessions-up": 0, "number-of-sessions-down": 0, "number-of-sessions-admin-down": 0 } } } }, { "type": "ietf-ospf:ospfv2", "name": "main", "ietf-ospf:ospf": { "spf-control": { "ietf-spf-delay": { "current-state": "quiet", "remaining-time-to-learn": "not-set", "remaining-hold-down": "not-set", "last-event-received": 5381664, "last-spf-time": 5382164 } }, "router-id": "1....

December 31, 2023

holo routingを動かす

最近知ったholo routing. rustで書かれたルーティングスイートである. build とりあえずbuildしてみよう。 https://github.com/holo-routing/holo/blob/master/INSTALL.md を参考にソースコードを取得して、 $ git clone https://github.com/holo-routing/holo.git # apt-get install build-essential cmake libpcre2-dev protobuf-compiler $ cd holo/ $ cargo build --release を行うとyang関連で失敗します。よく読むと、 Holo uses unstable Rust features, so building it from the source code requires a nightly version of the Rust compiler. と書いてありnightlyにしないといけないようです。 https://qiita.com/object-kazuAtGitHub/items/a24cc8a833f4663ad4b2 の記事を参考にnightlyの環境を作ります。 rustup update rustup override set nightly rustup self update rustup update nightly これを行った後に、cargo build --releaseを再度行ったところコンパイルが出来ました。作成されたファイルを見てみるとどうやらholodとholo-cliというバイナリができてます。Zebra/Quagga/FRRみたいにプロトコル毎にプロセスが分かれないんですね。1プロセスで動作するという意味でコンテナ向きだけど、複数組み合わせて動くマイクロサービス感はない。 ls holo/target/release/ build deps examples holo-cli holo-cli....

December 30, 2023

gnmiのプログラムを書いてみる

何でもかんでもOpenConfigで操作できたらよいじゃないですか。 というわけでFRRoutingがOepnConfigに対応したらよいのにと思ったりもしてみてOpenConfigdとかも少し見てみたのですが、イマイチ使い方がわからない。 なので自分で勉強がてらプログラムを書いてみるかと思いました。というわけでGW中に取り組んだ内容です。 さて、OpenConfigのyangデータモデルをもとにプログラミング言語のひな型を作ろうと思うとOpenConfig純正のygotを使うのが良いかなということでygotを使います。goyangでもいいんですが、より複雑なことをしたければygotって書いてあるのでいきなりygotを使います。 今回はprotocol bufferといいますか、grpcベースでOpenConfigの変数を操作できることを目標に作業始めました。 https://github.com/openconfig/ygot/blob/master/docs/protobuf_getting_started.md を参考にしていきましょう。 ygotのprotogeneraotrを入れる サンプルが go run $GOPATH/src/github.com/openconfig/ygot/proto_generator/protogenerator.go となっていたので、~/go/src/github.com/openconfig/ygotにgit cloneした後、 ~/go/src/github.com/openconfig/ygot/proto_generator/でgo installしました。~/go/bin/proto_generatorが作られていればOKです。 protocol bufferを生成する 今回パッケージ名はocdcとしています。OpenConfig Data Converterの意図だったのですが、実際今できていることはOpenConfig Data Storeという感じでしょうか。 元々FRRoutingがOpenConfigで設定できたらよいなと思ったので、OpenConfigのBGPやOSPFのデータモデルを扱いたいと思ったのでですが、それらBGPやOSPFはすべてnetwork-instanceに内包されている(network-instanceからuseで呼び出されている)ので、openconfig-network-instance.yangから生成しようとすると、依存関係が足りないエラーを延々出され、最終的に、以下のyangを呼び出さないといけないことになりました。 なおpublilcは https://github.com/openconfig/public/ をcloneしたディレクトリです。 https://github.com/golang-standards/project-layout に従って、protobufをapiディレクトリ以下に作るようにしました。 proto_generator -generate_fakeroot \ -base_import_path="go_src_dir/ocdc/api" \ --go_package_base="go_src_dir/ocdc/api" \ -path=public/release/models/ -output_dir=api \ -package_name=ocdc \ -exclude_modules=ietf-interfaces \ public/release/models/network-instance/openconfig-network-instance.yang \ public/release/models/openconfig-extensions.yang \ public/release/models/interfaces/openconfig-interfaces.yang \ public/third_party/ietf/ietf-interfaces.yang \ public/release/models/types/openconfig-yang-types.yang \ public/release/models/optical-transport/openconfig-transport-types.yang \ public/release/models/bgp/openconfig-bgp-types.yang \ public/release/models/platform/openconfig-platform-types.yang \ public/release/models/policy/openconfig-policy-types.yang \ public/release/models/local-routing/openconfig-local-routing.yang \ public/release/models/bfd/openconfig-bfd.yang \ public/release/models/rib/openconfig-rib-bgp.yang \ public/release/models/segment-routing/openconfig-segment-routing-types.yang \ public/release/models/mpls/openconfig-mpls....

May 13, 2023

sonicをpyatsで操作してみる。

昨日寝ぼけて、pyatsのシナリオを書こうとしていたフォルダをrm -rfしちゃいました。というわけでtestbed.yamlから作り直ししたのでその作業記録です。 pyatsのインストール ちょっと前にやっていたので、忘れてしまいました。historyを辿ると、 python3 -m pip install genie 'pyats[full]' で何も考えず多分入れたと思います。 公式ドキュメントによるとvenvの利用が推奨らしいです。 $ mkdir pyats $ cd pyats $ python3 -m venv . $ source bin/activate . (pyats)$ pyATS/Genie: インストールとアップグレードのお話によると、 pip install pyats[full] rest.connector yang.connectorがおすすめのようです。 pyatsのtestbed.yamlの設定 testbed.yaml配下のように作りました。ip: に続くIPアドレスは皆さんの環境に合わせて適当(適切)に書いてください。 credentials以下のusernameとpasswordはSONiCの標準のままです。環境に合わせて適当(適切)に書いてください。 osは適切なものがなくlinuxにしています。 testbed: name: sonic-testbed devices: sonic-vs1: os: linux connections: ssh: protocol: ssh ip: 任意 credentials: default: username: admin password: YourPaSsWoRd pyatsの内部で動く接続用のlibraryであるuniconの公式ドキュメントのSupported Platformsによると、osのlinuxの配下に、platformがないのでplatformは空欄にしています。 但しpyats validate testbedをするとWarningを言われます。ですが問題なく動きます pyats validate testbed testbed.yaml 出力結果: Loading testbed file: testbed....

April 9, 2023

frrとgrpcで通信する

FRRとgrpcでお話しするまでの道のりの記録です。 FRRの準備 土日にFRRoutingでgrpcを試してみました。環境はUbuntu 20.04です。 まず最初に最新のリリースパッケージを試してみましたが、どうやらコンパイルオプション的にgrpcは有効じゃなさそうでした。というわけで最新ソースコードからコンパイル。 事前に必要なパッケージは https://docs.frrouting.org/projects/dev-guide/en/latest/building-frr-for-ubuntu2004.html#installing-dependencies を参考に入れます。 加えて以下を入れます。但しhistoryからたどっていったので正確かどうかわかりません。 sudo apt install libprotobuf-c-dev sudo apt install protobuf-c-compiler sudo apt install libgrpc-dev sudo apt install libgrpc++-dev sudo apt install libprotoc-dev sudo apt install protobuf-compiler-grpc あと、libyang2, libyang2-devが必要です。で、これ最初にfrrの最新リリースのバイナリパッケージを入れた関係で依存関係で入っています。 frrの最新リリースのバイナリパッケージを入れる場合は、 https://deb.frrouting.org/ を見て入れてください。 FRRoutingのコンパイルオプションは以下で実施。 configure --enable-grpc 普通にコンパイルとインストール。 make make install 野良パッケージをなるべく入れたくないし、入れる場合は管理したいので、管理のためにporgを使いました。 sudo apt install porg sudo porg -lD make install なお、ちなみに、FRRは適当にmasterで作業してしまっています。 Merge: c99978f7b 74dd0c84d Author: Russ White <russ@riw.us> Date: Wed Mar 29 11:05:30 2023 -0400 Merge pull request #12645 from gpnaveen/ospf_error_msg_enhancements tests: [topojson] Update assert/error messages for ospf scripts Frr起動 本当は/etc配下とかにある(ソースコンパイルなら/usr/local以下)daemonsにファイルに、...

April 2, 2023