Share
Embed
SAI ちょっと調べてみた
OCP (Open Compute Project)に寄贈された、ネットワーク機器を抽象化して制御・管理する標準APIであるSAI (Switch Abstraction Interface)について、調べてみた概要を紹介します。
Masaru OKI
June 08, 2018
Transcript
61 slides
-
軽く自己紹介 • 名前 沖 勝 (おき まさる) @masaru0714 • 所属 株式会社インターネットイニシアティブ
ネットワーク本部 SDN開発部 ネットワーク基盤開発課 • 近年関わった開発 OpenFlowソフトウェアスイッチ Lagopus (データプレーンのI/Oまわり、OpenFlowのmatch action処理の設計・実装を担当) • 個人所有のXeonマシン 4台 (Xeon E3-1231 v3, Xeon D-1540 2台, Xeon E3-1105C v2) 3 -
ネットワーク機器とASICの関係 • ASIC - Application Specific Integrated Circuit 特定用途向け集積回路。 •
ネットワーク機器向けのASICは、ハードウェアでパケット処理する LSI。 • パケット転送やVLAN処理などはASICで。BGPなど複雑な処理はCPUで。 • CPUから設定処理を行い、そのとおりに、 ASICによるパケット転送が実行される。 CPU ASIC メモリ ストレージ PHY PHY PHY PHY 管理用NIC 設定、運用 ・ユーザートラフィック ・BGP, OSPF等 5 -
従来のスイッチとホワイトボックススイッチ 従来のスイッチ(C社、J社、……) • OSは機器に内蔵されていて、別の OSには入れ替えできない。(IOS, JUNOS, …) • スイッチASICは基本自社製品。 ホワイトボックススイッチ
• OSは入っていなくて、あとからインストールする。 • スイッチASICはマーチャントシリコン。Broadcomの他Cavium, Mellanox等 ◦ スイッチベンダーの製品ラインナップにより採用される ASICが異なる。 • OS x 製品(ASIC)の組み合わせが複数あり、エンドユーザはそこから選択することになる。 ◦ 製品によって動作する OSの種類は異なる。 6 -
ホワイトボックススイッチ: OS x 製品(ASIC) • 製品X: A, B, Cが動く •
製品Y: B, Cが動く • 製品Z: Bが動く • Aを使いたい→製品Xしかない • Bを使いたい→X, Y, Zから選べる • Cを使いたい→X, Yから選べる OS開発を考えると、組み合わせが増えると開発工数やサポートが増え、コスト増大につながる。 OS-A OS-B OS-C API-X API-Y API-Z 製品X 製品Y 製品Z CLI-A, API-A API-B Linux互換API 7 -
SAI (Switch Abstraction Interface) • SAI: Switch Abstraction Interface •
ベンダ非依存でパケット転送 (主にスイッチASIC)を制御するC言語のAPI仕様。 • 2015年7月に、Open Compute Projectにおいて標準APIとして承認された。 • Microsoft, Mellanox, Dell, Broadcom, Cavium, Barefoot, Metaswitchによるもの。 • バージョンは0.9.1からはじまり、2018年6月現在の最新は1.3.0。 • https://github.com/opencomputeproject/SAI/ • SAIを使えば、OS開発の際の特定ベンダー依存コードを大幅に減らすことができる。 • SAIの実装は、スイッチASICベンダーから提供される。 8 -
SAIを使うとどうなるか • OS-A, B, CがいずれもSAIを使い • 製品X, Y, ZがいずれもSAIを提供 •
すると任意の組み合わせが可能 • 実際にはそれぞれのOSが 各製品のSAIをリンクした パッケージを用意する。 OS-A OS-B OS-C 製品X 製品Y 製品Z CLI-A, API-A API-B Linux互換API SAI+API-X SAI+API-Y SAI+API-Z SAI (Switch Abstraction Interface) 9 -
SAIによるプログラミング C言語で記述する。大まかには下記のような制御を、 APIを呼び出して実行する。 1. SAI全体の初期化 2. スイッチIDの取得 3. ポートIDの取得 4.
仮想ルーターの作成 5. ルータインタフェースの作成と、仮想ルーター及びポートとの関連付け 6. インタフェースに対してnexthopとneighborの設定 7. ルートエントリの追加 11 -
さまざまなプログラマビリティ • OpenFlow ◦ OpenFlow Protocolを用いて仕様で決まった範囲内のデータプレーンプログラミング ◦ 機器の外部からランタイムで。ユーザーあるいは企業がコントローラを開発する • P4
◦ プログラマブルなハードウェアに対して P4言語を用いて自由にデータプレーンプログラミング ◦ コンパイルしておいて起動時にイメージを流し込む • SAI ◦ C言語を用いてASIC種類非依存の、あらかじめ ASICに用意された典型的機能を制御するプログラミング ◦ (OSベンダーが)プログラムを開発する • ASICベンダーのSDK ◦ (大半はC/C++言語を用いて)ASIC種類ごとに提供される機能を制御するプログラミング ◦ (OSベンダーが)プログラムを開発する 12 -
SAI採用のメリット • OSベンダー ◦ 開発・保守コストの削減 ◦ サポートハードウェアの多様化 • ASICベンダー ◦
OS選択の自由度向上 • エンドユーザー ◦ OSおよびハードウェアの選択の幅が広がる ◦ つまりネットワークプログラマビリティの選択幅も広がる 14 -
SAIを採用しているASICベンダー SAI実装自体は、各ASICベンダーから、ASICのSDKに含まれる形で提供される。 • Broadcom • Barefoot • Cavium • Centec
• Mellanox • Marvell • Nephos 15 -
SAIを採用するネットワークスイッチ用OS ここでいう「ネットワークスイッチ用 OS」はスイッチ単体の中で動作するものを指す。 複数のネットワーク機器を統括的に管理する ONOS等とは異なる。 紛らわしいので、ここではNOSと呼ばない。 • SONiC • OpenSwitch
• 商用OSの場合、内部のAPIは非公開のため、SAIが使われているかは不明 ◦ 以前からあるものはおそらくベンダーの独自 APIを使用していると思われる ◦ SAIであれ独自APIであれトータルサポートするので、 SAI採用を強調することはなさそう 16 -
SONiC • https://azure.github.io/SONiC/ • Microsoftのデータセンターで使われている。 • オープンソース。OCPに寄贈されている。Apache v2 (kernelに関する部分はGPLv2) •
正確には、Linux上で動作するネットワーキングソフトウェアをまとめたもの。 • パッケージ内に設定管理DBやFRRなどを含む。 • ホワイトボックススイッチへのインストールイメージも配布されている。 ◦ https://github.com/Azure/SONiC/wiki/Supported-Devices-and-Platforms ◦ ASICベンダのSDKはオープンソースになっていないものもあるが、その場合も利用できる • C/C++, Python APIを使い外部から制御する。 • 設定情報はJSONで記述する。 • ASICの制御にはSAIを使用している。 18 -
OpenSwitch • https://www.openswitch.net/ • 2015年に米HPにより公開。現在はDell EMCが参加し開発の中心となっている。 ◦ 当初のものを “OPS”、Dell EMC参加後のものを
“OPX” と呼んで区別することがある。 • オープンソース。Apache v2。Linux Foundationのプロジェクトとなっている。 ◦ Dellテックセンターブログによる紹介記事 http://ja.community.dell.com/techcenter/b/weblog/archive/2018/02/06/openswitch-opx • Debian上で動作し、Ubuntuにも移植された。 • ホワイトボックススイッチへのインストールイメージも提供されている。 ◦ https://github.com/open-switch/opx-docs/wiki/hardware-support • CLI、REST APIのほか、Linuxのnetlink経由での設定も可能。 ◦ (商用のCumulus Linuxのように)Linux上で見えているNICに対する操作で ASICを制御可能。 • ASICの制御にはSAIを使用している。 19 -
ホワイトボックススイッチなしで試せるSONiC • SONiC P4 Software Switch https://github.com/Azure/SONiC/wiki/SONiC-P4-Software-Switch • 各ホストをdockerコンテナで作成し、トポロジを構成する。 •
switch1は192.168.1.0/24を広報するBGP AS • switch2は192.168.2.0/24を広報するBGP AS • host1からpingを送信し、応答があることを実際に確認できる。 • SAIはSONiCの内部で使われているが、ユーザがそれを意識する必要はない。 • 両switch内で、/etc/sonic/config_db.jsonや/etc/swss/config.d/default_confg.jsonを用意。 host1 Ubuntu 192.168.1.2/24 host2 Ubuntu 192.168.2.2/24 switch1 SONiC switch2 SONiC 20 -
SONiCのconfig_db.jsonの例(一部抜粋) { "VLAN": { "Vlan14": { "members": [ "Ethernet0" ],
"vlanid": "14" }, }, "VLAN_MEMBER": { "Vlan14|Ethernet0": { "tagging_mode": "untagged" }, }, "VLAN_INTERFACE": { "Vlan14|10.0.0.1/31": {}, } } 21 -
手元で試せるOpenSwitch • https://github.com/open-switch/opx-docs/wiki/Run-virtual-machine • Vagrant(+VirtualBox)を使って、仮想マシン上で OpenSwitchを動作させる。 ◦ 実際には、手順に従って VMを作成すると、仮想マシンへの OpenSwitchをインストールが始まる。
• デモ設定や環境などは用意されていないので、トポロジ等は自分で組む必要がある。 ◦ 設定の多くはLinuxのコマンド(ip addr, ip routeなど)で設定可能。 ◦ https://github.com/open-switch/opx-docs/wiki/Network-integration ◦ Ansibleで設定するロールなどが提供されている ◦ https://github.com/open-switch/opx-docs/wiki/ansible • SAIはOpenSwitchの中で使われているが、ユーザがそれを意識する必要はない。 22 -
OpenSwitchへの設定(一部抜粋) # Set MTU $ ip link set dev e101-002-0
mtu 1400 $ ip link show e101-002-0 17: e101-002-0: <BROADCAST,MULTICAST> mtu 1400 qdisc noop state DOWN mode DEFAULT group default qlen 500 link/ether 90:b1:1c:f4:ab:f2 brd ff:ff:ff:ff:ff:ff alias NAS## 0 29 # Show interface parameters $ ip addr show e101-001-0 16: e101-001-0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 500 link/ether 90:b1:1c:f4:ab:ee brd ff:ff:ff:ff:ff:ff inet 10.1.1.1/24 scope global e101-001-0 valid_lft forever preferred_lft forever inet6 2000::1/64 scope global tentative valid_lft forever preferred_lft forever 23 -
SAIは縁の下の力持ち • ネットワーク機器はスイッチ用 ASICによってパケット転送を実現している • ホワイトボックススイッチ内の ASICの種類ごとに異なるSDKが用意され、OSの対応状況も様々 • ベンダー非依存でASICを制御するAPIとしてSAIが公開され、多様なASICが対応している •
SAIを使ったネットワークスイッチ用 OSとして、SONiCやOpenSwitchがある • SONiCやOpenSwitchは、実機がなくても、コンテナや仮想環境で試せる • SONiCやOpenSwitchの中でSAIが使われているが、ユーザがそれを意識する必要はない 25 -
SAIの概要 • Switch Abstraction Interface • C言語のライブラリで、ネットワークスイッチの抽象化 APIを提供する ◦ 基本、ライブラリを提供するのはスイッチベンダー。
• ネットワーク機器の内部で動作する。いうなればホワイトボックススイッチ用。 • Open Compute Project (OCP)にcontributeされている • SAIをサポートするプラットフォーム ◦ ASICs (Broadcom, Mellanox, Cavium, Barefoot, Centec, Marvell, Nephos) ◦ ソフトウェア実装 SAI-P4-BM • SAIを使ったスイッチ実装 ◦ SONiC ◦ OpenSwitch 27 -
SAI-P4-BM • https://github.com/Mellanox/SAI-P4-BM • ソフトウェア実装。 • ルータやブリッジの機能を P4言語で実装、P4のBehavioral Model (BM)で動かす。
• BMにThriftによるRPC操作を加えて、外部から設定管理を可能にする。 • SAIのAPI実装としてThriftでBMに設定可能にするsai_adaptorを用意。 • SONiCなどはsai_adaptorを呼び出すようリンクして動作する。 • ポートはLinuxのNICをsocket(libpcap)で読み書きする。 28 -
SONiC + SAI-P4-BMの構成 SAI-P4-BM BM BM bridge.p4 JSON router.p4 JSON
Linux kernel sai_adaptor (SAI実装を提供) libsaithrift Thrift RPC(9090) Thrift RPC(9091) sonic-syncd (client) SAI Thrift RPC(9092) pcap pcap admin_status (up/down) SAI C API for ASICs (ハードウェアの場合) SAI Thrift RPC(9092) 29 -
SAI-P4-BM以外のソフトウェア実装 SONiCやOpenSwitchの中に、Virtual Switch or Virturl Machine実装がある。 • SONiC ◦ platform/vs
(実体はsonic-sairedis/vslib) • OpenSwitch ◦ opx-sai-vm • いずれも、Linuxのnetdevを読み書きし、fdb等は自前で持つ。 • カーネルスタックを使わない。 • vslibはソース内に一部SONiC依存がある。 • opx-sai-vmは未確認。 30 -
外部からの制御方法 • SONiC ◦ JSONで書かれた設定内容を redisに設定 ◦ https://github.com/Azure/SONiC/wiki/Configuration • OpenSwitch
◦ CPS (Control Plane Services) ▪ https://github.com/open-switch/opx-docs/wiki/Application-programming ▪ C/C++とPythonのAPIが提供される ▪ Ansibleのroleなども提供され、自動化も可能 ◦ Linux 標準API (ipコマンド等を使い , netlinkによる操作) • どちらもSAIを直接意識する必要はない。 • (当然)互換性はない。 • あえてSAIを意識するなら、SONiCのSAI Thrift RPCか。 31 -
試してみる • SONiC - SONiC-P4 Software Switch ◦ https://github.com/Azure/SONiC/wiki/SONiC-P4-Software-Switch •
OpenSwitch - Run Virtual Machine ◦ https://github.com/open-switch/opx-docs/wiki/Run-virtual-machine • ソフトウェア実装は、統計情報関連の実装が omitされていたりするので、あくまでお試し。 32 -
• 最低限必要なオブジェクトを図示。 ACLだのVLANだのは省いている。 SAIで制御、管理できるオブジェクト switch port bridge port router interface
bridge virtual router fdb route router interface neighbor next hop 33 -
ARP? • ACLには指定があるがこれはフィルタリング用 • CPUで処理するようだ ◦ CPUで処理するには、 hostifを使う(trapするパケットの種類を指定する ) ◦
SONiCでは、swss用の設定JSON内にtrapの設定を記述する。 • hostifのtrap指定の種類はかなり多い ◦ switch用: STP, LACP, EAPOL, LLDP, IGMP関連など ◦ router用: ARP, DHCP, OSPF, PIM, VRRP, DHCPv6, OSPFv6, VRRPv6, IPv6 ND,MLD ◦ Unknown L3 multicast ◦ local IP用: 自分宛route, SSH, SNMP, BGP, BGPv6 34 -
まとめ • SAIはASICの種類によらず制御を可能とする、 C言語のAPI • 基本的にSAI実装は、スイッチベンダーより提供される • スイッチを運用管理するときは、 SAIを意識する必要はない •
SONiCやOpenSwitchなどのスイッチ実装を管理・運用する • SAIを意識する必要があるのは、スイッチ実装を開発する場合 35 -
SAIのAPI 種別: sai_api_t (enum)で区分けされている (34種類) switch, port, fdb, vlan, virtual_router,
next_hop, next_hop_group, router_interface, neighbor, acl, hostif, mirror, samplepacket, stp, lag, policer, wred, qos_map, queue, scheduler, scheduler_group, buffer, hash, udf, tunnel, l2mc, ipmc, rpf_group, l2mc_group, ipmc_group, mcast_fdb, bridge, unspecified 全部は紹介できないので、いくつかピックアップする。 37 -
APIの使い方 • API種別ごとの関数テーブルを取得 sai_api_query(sai_api_id, &api_method_table) • テーブルはsai_api_*_tで定義されている。 • 例 sai_api_query(SAI_API_PORT,
&method)で得られる関数テーブル typedef struct _sai_port_api_t { sai_create_port_fn create_port; sai_remove_port_fn remove_port; sai_set_port_attribute_fn set_port_attribute; sai_get_port_attribute_fn get_port_attribute; sai_get_port_stats_fn get_port_stats; sai_clear_port_stats_fn clear_port_stats; sai_clear_port_all_stats_fn clear_port_all_stats; } sai_port_api_t; • status = table->create_port(&portid, swid, attr_size, attr); というふうに呼ぶ。 39 どのAPIもこの4つは定義される。 これ以外はAPI種別ごとに独自で 基本の4つしかないAPIもある。 -
attribute • API種別ごとにたくさんの属性が定義されている。 • 属性は扱い方によって大きく下記に分かれる。 ◦ CREATE_ONLY ▪ create_xxxx()でしか使えない ◦
READ ONLY ▪ get_attribute()でしか使えない ◦ CREATE AND SET ▪ create_xxxx(), set_attribute(), get_attribute()で使える • それぞれの関数で一度に複数の属性を指定できる。 40 -
switch API (SAI_API_SWITCH) • スイッチそのものに関する API (saiswitch.h) • create_switch ◦
スイッチ(管理・設定対象)を用意する。switch idを取得する。 ◦ これがないとはじまらない。 bridgeやrouterをスイッチ上に構成して動き出す。 • remove_switch ◦ スイッチの使用を終了する。 • set_switch_attribute • get_switch_attribute ◦ 属性を読み書きする。属性次第では read only (実際は書き込み可能なものが少なかった ) ◦ fdbやL3 neighbor table、L3 route tableのサイズはread only ◦ ポート数や最大 MTU、仮想ルータ最大数なども read only ◦ ECMPをいくつ組めるか、 ECMPにいくつ束ねられるかも read only ◦ MACラーニング数やACLオブジェクトとの関連付けは create and set ◦ unknown unicastを(CPU portに)転送するか捨てるかも create and set 41 -
switchのattribute(一部抜粋) • SAI_SWITCH_ATTR_NUMBER_OF_ACTIVE_PORTS • SAI_SWITCH_ATTR_MAX_NUMBER_OF_SUPPORTED_PORTS • SAI_SWITCH_ATTR_PORT_LIST • SAI_SWITCH_ATTR_MAX_MTU •
SAI_SWITCH_ATTR_CPU_PORT • SAI_SWITCH_ATTR_MAX_VIRTUAL_ROUTERS • SAI_SWITCH_ATTR_FDB_TABLE_SIZE • SAI_SWITCH_ATTR_L3_NEIGHBOR_TABLE_SIZE • SAI_SWITCH_ATTR_ROUTE_TABLE_SIZE • SAI_SWITCH_ATTR_LAG_MEMBERS • SAI_SWITCH_ATTR_NUMBER_OF_LAGS 42 -
port API (SAI_API_PORT) ポート(サブポートを含む)に関するAPI (saiport.h) • create_port • remove_port •
set_port_attribute • get_port_attribute ◦ up/down, loopback, FEC mode, speed, MTUなどのほか、port/subportがcreate and set ◦ MACアドレス関連の属性はそもそも存在していない (router interfaceに属性がある) • get_port_status ◦ 各種カウンター値の取得。 IP/IPv6やパケットサイズごとのカウンタも用意されている。 ◦ (サポートされているかは別の話 ) • clear_port_status • clear_port_all_status 43 -
portのattribute (一部抜粋) • SAI_PORT_ATTR_TYPE • SAI_PORT_ATTR_OPER_STATUS • SAI_PORT_ATTR_SUPPORTED_BREAKOUT_MODE_TYPE • SAI_PORT_ATTR_CURRENT_BREAKOUT_MODE_TYPE
• SAI_PORT_ATTR_QOS_NUMBER_OF_QUEUES • SAI_PORT_ATTR_QOS_QUEUE_LIST • SAI_PORT_ATTR_SPEED • SAI_PORT_ATTR_ADMIN_STATE • SAI_PORT_ATTR_FEC_MODE 44 -
bridge API (SAI_API_BRIDGE) • create_bridge • remove_bridge • set_bridge_attribute •
get_bridge_attribute • create_bridge_port ◦ 作成時にport typeを指定。Port or LAG, Port or LAG w/ VLAN, bridge router port, tunnel ◦ さらにport object idを指定して関連付ける。 (Port or LAG (w/ VLAN含む) の場合) ◦ bridge router portの場合はrouter interface object idを関連付ける。 ◦ bridge object idも指定し、作成済みの bridgeに所属させる。 • remove_bridge_port • set_bridge_port_attribute • get_bridge_port_attribute 45 -
bridge portのattribute (一部抜粋) • SAI_BRIDGE_PORT_ATTR_TYPE • SAI_BRIDGE_PORT_ATTR_PORT_ID • SAI_BRIDGE_PORT_ATTR_TAGGING_MODE •
SAI_BRIDGE_PORT_ATTR_VLAN_ID • SAI_BRIDGE_PORT_ATTR_RIF_ID • SAI_BRIDGE_PORT_ATTR_TUNNEL_ID • SAI_BRIDGE_PORT_ATTR_BRIDGE_ID • SAI_BRIDGE_PORT_ATTR_FDB_LEARNIG_MODE • SAI_BRIDGE_PORT_ATTR_MAX_LEARNED_ADDRESSES 46 -
bridgeのattribute • SAI_BRIDGE_ATTR_TYPE • SAI_BRIDGE_ATTR_PORT_LIST • SAI_BRIDGE_ATTR_MAX_LEARNED_ADDRESSES • SAI_BRIDGE_ATTR_LEAN_DISABLE •
SAI_BRIDGE_ATTR_UNKNOWN_UNICAST_FLOOD_CONTROL_TYPE • SAI_BRIDGE_ATTR_UNKNOWN_UNICAST_FLOOD_GROUP • SAI_BRIDGE_ATTR_UNKNOWN_MULTICAST_FLOOD_CONTROL_TYPE • SAI_BRIDGE_ATTR_UNKNOWN_MULTICAST_FLOOD_GROUP • SAI_BRIDGE_ATTR_BROADCAST_FLOOD_CONTROL_TYPE • SAI_BRIDGE_ATTR_BROADCAST_FLOOD_GROUP 47 -
fdb API (SAI_API_FDB) fdbエントリ関連のAPI。作成時は他と違い、構造体に値を入れて呼び出す。 typedef struct _sai_fdb_entry_t { sai_object_id_t switch_id;
sai_mac_t mac_address; // 宛先MACアドレス sai_fdb_entry_bridge_type_t bridge_type; sai_vlan_id_t vlan_id; sai_object_id_t bridge_id; // エントリを設定するbridge } sai_fdb_entry_t; • create_fdb_entry • remove_fdb_entry • set_fdb_entry_attribute • get_fdb_entry_atttribute ◦ bridge port id • flush_fdb_entries 48 -
fdbのattribute • SAI_FDB_ENTRY_ATTR_TYPE • SAI_FDB_ENTRY_ATTR_PACKET_ACTION • SAI_FDB_ENTRY_ATTR_USE_TRAP_ID • SAI_FDB_ENTRY_ATTR_BRIDGE_PORT_ID •
SAI_FDB_ENTRY_ATTR_META_DATA • SAI_FDB_ENTRY_ATTR_ENDPOINT_IP 49 -
virtual router API (SAI_API_VIRTUAL_ROUTER) 仮想ルータに関するAPI。VRF相当。VRRPを考慮する。 • create_virtual_router • remove_virtual_router •
set_virtual_router_attribute • get_virtual_router_attribute ◦ IPv4, IPv6それぞれのadmin state ◦ TTL 0 or 1のときtrapを発生させるか否か ◦ IP optionつきのときtrapを発生させるか否か ◦ L3マルチキャストパケット受信時の振る舞い (default: drop) 50 -
virtual routerのattribute • SAI_VIRTUAL_ROUTER_ATTR_ADMIN_V4_STATE • SAI_VIRTUAL_ROUTER_ATTR_ADMIN_V6_STATE • SAI_VIRTUAL_ROUTER_ATTR_MAC_ADDRESSES • SAI_VIRTUAL_ROUTER_ATTR_VIOLATION_TTL1_PACKET_ACTION
• SAI_VIRTUAL_ROUTER_ATTR_VIOLATION_IP_OPTIONS_PACKET_ACTION • SAI_VIRTUAL_ROUTER_ATTR_UNKNOWN_L3_MULTICAST_PACKET_ACTION 51 -
router interface API (SAI_API_ROUTER_INTERFACE) • create_router_interface ◦ interface type、port idとvirtual
router idを指定して関連付けが必要。 • remove_router_interface • set_router_interface_attribute • get_router_interface_attribute ◦ MTU ◦ ingress ACL, egress ACL ◦ IPv4 multicast, IPv6 multicast 52 -
router interfaceのattribute (一部抜粋) • SAI_ROUTER_INTERFACE_ATTR_VIRTUAL_ROUTER_ID • SAI_ROUTER_INTERFACE_ATTR_TYPE • SAI_ROUTER_INTERFACE_ATTR_PORT_ID •
SAI_ROUTER_INTERFACE_ATTR_VLAN_ID • SAI_ROUTER_INTERFACE_ATTR_SRC_MAC_ADDRESS • SAI_ROUTER_INTERFACE_ATTR_MTU • SAI_ROUTER_INTERFACE_ATTR_INGRESS_ACL • SAI_ROUTER_INTERFACE_ATTR_EGRESS_ACL • SAI_ROUTER_INTERFACE_ATTR_V4_MCAST_ENABLE • SAI_ROUTER_INTERFACE_ATTR_V6_MCAST_ENABLE 53 -
next hop API (SAI_API_NEXT_HOP) • create_next_hop ◦ next hop type
(IP or MPLS or ENCAP)、next hopのIPアドレス、router interface idを指定 ◦ next hop typeがENCAPのときはtunnel idを指定 • remove_next_hop • set_next_hop_attribute • get_next_hop_attribute 54 -
next hopのattribute • SAI_NEXT_HOP_ATTR_TYPE • SAI_NEXT_HOP_ATTR_IP • SAI_NEXT_HOP_ATTR_ROUTER_INTERFACE_ID • SAI_NEXT_HOP_ATTR_TUNNEL_ID
• SAI_NEXT_HOP_ATTR_SEGMENTROUTE_SIDLIST_ID • SAI_NEXT_HOP_ATTR_SEGMENTROUTE_ENDPOINT_TYPE • SAI_NEXT_HOP_ATTR_SEGMENTROUTE_ENDPOINT_POP_TYPE • SAI_NEXT_HOP_ATTR_LABELSTACK 55 -
route API (SAI_API_ROUTE) ルートエントリ関連のAPI。fdbと同様に、構造体に値を入れて呼び出す。 typedef struct _sai_route_entry_t { sai_object_id_t switch_id;
sai_object_id_t vr_id; // エントリを設定するvirtual router sai_ip_prefix_t destination; // 宛先IP prefix } sai_route_entry_t; • craete_route_entry • remove_route_entry • set_route_entry_attribute • get_route_entry_attribute ◦ next hop id 56 -
neighbor API (SAI_API_NEIGHBOR) typedef struct _sai_neighbor_entry_t { sai_object_id_t switch_id; sai_object_id_t
rif_id; // 設定するrouter interface sai_ip_address_t ip_address; // 近隣IPアドレス } sai_neighbor_entry_t; • create_neighbor_entry ◦ destination mac • remove_neighbor_entry • set_neighbor_entry_attribute • get_neighbor_entry_attribute • remove_all_neighbor_entries 58 -
ACL関連のattributeはかなり種類が多い まず対象自体が多い。 • SAI_ACL_TABLE_GROUP_ATTR • SAI_ACL_TABLE_ATTR • SAI_ACL_ENTRY_ATTR • SAI_ACL_COUNTER_ATTR
• SAI_ACL_RANGE_ATTR ACL ENTRYのattributeにはマッチさせるヘッダフィールドがずらっと定義されている。 • ether_type, vlan id, ip_protocol, src ip addres, L4 dst port等。 • in_portやout_portのようなパケットデータに含まれないものも指定できる。 60