発展トピック¶
このページは、ACL / CoPP / mirror の基本線から少し外れるが、同じ「分類、保護、観測、rate limit」の考え方で読める機能への案内です。通常運用の入口は前ページまでで足りることが多く、ここでは境界だけを整理します。
CoPP Manager Redesign¶
CoPP Manager 再設計は、COPP_TRAP と FEATURE の整合性を見直し、feature が disabled または存在しない場合は trap を install しない、ただし always_enabled=true の trap は常に install する、というルールに整理します。
これは ACL rule の priority 問題ではなく、CPU bound trap をいつ hostif trap として作るかの問題です。BGP、ARP、LACP、UDLD、IP2ME などの trap が feature 状態とどう連動するかを読むときに参照します。
CoPP Neighbor Miss と Capability¶
Neighbor miss trap は、ARP / ND 解決前の IP packet が CPU に集中して他の control plane traffic を巻き込む問題を避けるため、SAI_HOSTIF_TRAP_TYPE_NEIGHBOR_MISS を個別 policer に分離する拡張です。同時に、SAI enum capability query でサポート trap 一覧を STATE_DB に公開し、未対応 trap の install 失敗を可視化します。
CoPP のトラブルシュートでは、show copp configuration で trap が hardware に入っているかを見る入口になります。
DASH ACL Tags¶
DASH ACL tags は、DASH の ACL rule でサービスを IP prefix 群として扱うための仕組みです。通常 ACL の ACL_TABLE / ACL_RULE ではなく、DASH_PREFIX_TAG_TABLE と DASH_ACL_RULE_TABLE の拡張として読みます。
通常 ACL との共通点は、match 対象を抽象化し、rule 生成時に展開することです。違いは、DASH pipeline と APP_DB schema が別系統であり、SONiC の data plane ACL 設定と同じ運用コマンドでは扱わないことです。
Port Access Control¶
PAC は 802.1x / MAB / RADIUS によるポート単位の認証です。認証結果に応じて MAC、VLAN、learning mode、host trap を制御するため、ACL に似た「許可 / 不許可」の話に見えますが、主体は authentication manager、hostapd、mabd、RADIUS です。
ACL 章では、物理ポート単位の access 制御であり、LAG / VLAN への ACL bind とは別の設計として位置付けます。
DHCP DoS 緩和¶
DHCP DoS 緩和は、従来 CoPP のシステム全体 DHCP rate limit では単一ポートの flood が他ポートの正規 DHCP を巻き込む問題を、ポート単位の Linux TC rate limit で局所化する設計です。
ただし既存ページでは discrepancy-found とされており、データ層や CLI は取り込まれている一方、HLD が要求する portmgrd の TC 投入ロジックや CoPP 側の完全な置き換えは未確認です。設計参考として扱い、実装判断では現行コードと platform 動作を確認します。
関連ページ¶
- CoPP Manager 再設計テストプラン
- CoPP Neighbor Miss trap と enum capability query
- DASH ACL タグ
- Port Access Control
- DHCP DoS 緩和
発展トピック¶
- ERSPAN Type-II / Type-III: 通常 SPAN/Everflow に加え、GRE 経由で remote collector に届ける ERSPAN は SAI mirror session の
SAI_MIRROR_SESSION_ATTR_TYPEで表現する。Type-III は timestamp と probabilistic sampling をサポートする。 - ACL counters の telemetry export:
COUNTERS_DBから ACL rule 単位のヒット数を gNMI / streaming telemetry で出す構成。Top talker / DoS 検出に直結する。 - TCAM 共有 (ACL group sharing): 同じ ACL を複数 port に bind するとき、ASIC TCAM を group 共有でケチる。SAI side で
SAI_ACL_TABLE_GROUPの MULTIPLE binding が要件。 - Egress ACL の counter visibility: ingress ACL counter は読みやすいが egress ACL counter は ASIC によって粒度が異なる。
show acl ruleで counter が更新されない場合は SAI 側 attribute サポートを確認する。 - CoPP trap 別 policer の動的調整: 障害対応中に特定 trap (例えば LACPDU storm) の policer を一時的に上げる運用がある。
COPP_GROUP/COPP_TRAPで per-feature に切り替える。
既知の制約と回避方法¶
- ACL update 中の transient match miss: rule replace 時に一瞬 hit しない瞬間がある。
atomic updateを ASIC がサポートするなら priority 違いで shadow rule を先入れし、後で旧 rule を消す。 - mirror session の TTL / source MAC: ERSPAN の outer header はデフォルトで encap した装置の MAC / IP を使う。collector 側 NAT / FW が想定外の send 元を弾く例があるので outer header を明示する。
- CoPP の Linux 側 hostif との二重バケット: SAI policer と Linux netdev queue の両方が rate limit を持つ。CPU 到達後にも drop されることがあるので、
ethtool -S Ethernet*で host queue drop を確認する。 - DASH ACL tag と data plane ACL の混同: 名前は似るが pipeline が別。DASH pipeline 上で動くため
iptablesや CONFIG_DBACL_RULEで代用できない。
将来計画 / ロードマップ¶
- gNOI
gnoi.system.SetPackageやgnoi.os.Activateと組み合わせた dynamic ACL push 提案がある (集中 controller からの policy 更新)。 - ACL の P4 表現 (18 P4/PINS) は中長期テーマで、SDN controller が P4 table 経由で ACL を流し込む。
- CoPP の YANG モデル整備 (
sonic-copp.yang) が進めば、設定検証とgnmi Set経由の運用が安定する。
関連 RFC / 仕様書¶
- RFC 6035 — sFlow と ACL counter の関係参考
- RFC 7011 — IPFIX (ACL hit を export する将来形)
- IEEE 802.1X — Port Access Control の基準
- RFC 6749 — OAuth2 (PAC + RADIUS 連携の将来モデル)
- RFC 2475 — DiffServ (CoPP の DSCP マッチで参照)
upstream 開発の最新動向¶
sonic-swssのaclorch/coppmgr/copporchで trap capability 公開、policer attribute 動的更新、ACL counter race 修正の PR が継続。- DASH ACL tags は
sonic-dash-api(proto) の更新で flow rule 表現が拡張されており、controller 側との binding が変化しやすい。 - 802.1X / MAB 関連は hostapd の SONiC docker 統合と RADIUS attribute 拡張の PR が散発的にあり、AAA 章 (15) と相互に影響する。
ハンドオフ¶
- 概念とアーキテクチャは本章の concept / internals と、area HLD の acl-qos/ 配下の ACL / CoPP / Mirror 系ページで完結する。aclorch / coppmgrd / coppmgr / mirror orch の責務分担は internals に集約。
- 設定とリファレンスは reference/cli の
config acl/show acl/config copp/show mirror系、ACL_RULE,ACL_TABLE,COPP_TRAP,COPP_GROUP,MIRROR_SESSIONの CONFIG_DB スキーマ で網羅される。 - 本ページ は ACL counter export、CoPP policer の動的調整、ERSPAN/SPAN の境界、DASH ACL tags、P4 表現といった「ACL/CoPP/Mirror を周辺機能と結合する」発展領域だけを扱う。
トラブルシュート観点¶
- ACL rule が ASIC に降りないときは、まず
aclshow -aで counter の有無、redis-cli -n 1 keys 'ACL_*'で APPL_DB / ASIC_DB の rule 数を確認する。TCAM 不足の場合はswssのsyncdログにSAI_STATUS_INSUFFICIENT_RESOURCESが出る。 - CoPP で control plane を drop しているときは、
docker exec swss coppmgrの状態とshow coppの rate/burst を確認する。BGP / LACP / ARP のような protocol trap がMATCH_DROPに分類されていると、コンソール経由でも疎通しない事象が起きる。 - mirror session が動作しないときは、
show mirror_sessionで session の active/inactive、MIRROR_SESSIONテーブルの GRE/ERSPAN 設定、宛先 next-hop の到達性を点検する。VXLAN 経由 mirror は dst VTEP の MAC 解決失敗で停止しやすい。
検証パスとラボ要件¶
- ACL scale 検証は
sonic-mgmtのacl/test_acl.pyを baseline に、4k〜16k rule を投入して TCAM 使用率と orchagent レイテンシを計測する。ASIC capability (TCAM 段数、stateful 数) を事前にsaictl queryで取得しておく。 - CoPP 検証は
iperf3やhping3で各 trap rate の限界を計測する。target rate はCOPP_GROUPのcir/cbs設定通りに収まるべきで、超過時はpolicer drop counterが増えることを確認。 - Mirror session の throughput / drop は
ostinato/pktgenで帯域を上げ、show mirror_sessionの active 状態と GRE encap オーバーヘッドを考慮した宛先側受信量を比較する。