Perpetual PoE
交换机软件重启时,PoE 不中断。对 PoE 照明、门禁、楼宇传感器来说,这意味着升级窗口不再等于“灯灭窗口”[2]。
Cisco C9350 Series Smart Switches · 产品与方案解读
它不是“更快的 C9300”。C9350 换掉了接入交换机的芯片(Silicon One A100)、堆叠(以太网化的 StackWise-1.6T)、供电(三电源、48 口同时 90W)、控制平面(x86 + 16 GB DDR5 + SSD)与信任根(支持后量子签名的 Trust Anchor),并让同一台硬件可以在 Catalyst Center 与 Meraki 之间任选管理方式。
C9350# show lldp neighbors
把接入交换机剥到只剩本分,它要对每个终端交付五样东西:比特、瓦特、规则、可信,以及可被管理。过去十年,这五样需求是同时变大的——所以只换更快端口的升级,解决的只是其中一项。
一台 Wi-Fi 7 AP 接进配线间,你认为它对交换机提出的最大新要求是什么?带宽、供电,还是别的?
两样都要,而且互相牵制。C9350 数据表把 Multigigabit 与 90W UPOE+ 写在同一句话里,用来连接 Wi-Fi 6/6E/7 AP 和楼宇、摄像机等高功率终端[2]。端口提速以后,电力预算、上联收敛比、能装下多少分段策略,都会跟着被重新计算。
| 接入层的本分 | 过去的典型假设 | 今天的终端提出的要求 | C9350 的硬件回答 |
|---|---|---|---|
| 比特 | 桌面 1G 足够,上联 10G | Wi-Fi 6E/7 AP 需要超过 1G 的有线回程 | 48 × 10G mGig(48HX/TX);上联 NM-4C 4 × 100G,单机上联最高 400G[1] |
| 瓦特 | 电话 15W、AP 30W | AP、PTZ 摄像机、照明、楼宇控制器需要 60–90W;交换机重启时不能断电 | 3 个电源位;三块 1600W 时 48 口同时 90W(4320W);Perpetual PoE / Fast PoE[2] |
| 规则 | 几百条 ACL | 零信任分段把策略推到最边缘,ACL、SGT、NetFlow 同时膨胀 | A100 芯片 HCAM:8K TCAM + 128K 算法表项;默认模板 32K 条 ACE(C9300 为 4K,C9300X 为 8K)[3] |
| 可信 | 相信供应链 | 自己验证硬件与软件真伪;交换机生命周期内要面对量子计算对签名算法的威胁 | Trust Anchor module、Secure Boot、镜像签名;PQC 签名的 IOS XE[2] |
| 被管理 | 买之前就决定 CLI、本地控制器还是云 | 本地、云、混合并存,而且会变 | 同一硬件、同一许可证,开箱选择 Catalyst Center 或 Meraki Dashboard[3] |
如果五样需求同时变大,一台 1RU 的盒子要换掉哪些部件才跟得上?
答案几乎是“全部”。C9350 不是在 C9300 上加速:它的数据平面从 UADP 换成 Silicon One A100/L,堆叠从专有背板协议换成基于 VXLAN 封装、最短路径转发的 StackWise-1.6T,控制平面换成 Intel 第 12 代四核 x86 与 16 GB DDR5,电源从两块变成三块,风扇换成 N+1 模块化、风量提升 30% 的新设计[3]。代价也很明确:网络模块、电源和堆叠线缆都不与 C9300(X) 通用[2][3]。
先认识这台机器。下面是 C9350 的背面——大部分“新本事”都藏在这里。点一下编号,看每个部件负责哪一种供给。
点击图上区域或右侧列表
C9350 背板(图片来源:Cisco 数据表 Figure 3)。正面另有 USB-C Console、USB-C Host 口、蓝色定位灯与上联模块槽。
C9350# show power inline
决定一台接入交换机够不够用的,不是端口数,而是两本账:电力预算和上联收敛比。C9350-48HX 两本账都给得很宽——装满三块 1600W 电源,PoE 预算 4320W,正好等于 48 × 90W;上联最高 4 × 100G,48 个 10G 端口全部跑满时收敛比也只有 1.2 : 1。
先说电。交换机不是“插上就给电”,而是先预留再供电:每个端点接入时,交换机根据它的 PoE 等级或协商结果,从总预算里划走一块功率;预算划完了,后来的端点就不供电。可以把它理解成电表的“合同容量”——看的是承诺了多少,而不只是此刻用了多少。这个比喻的边界是:C9350 同时报告 Allocated(已预留)与 Consumed(实际消耗),运维可以分别看到两者[1]。
C9350-48HX 默认带一块 1600W 电源。你觉得这块电源能拿出多少瓦给 PoE?
1150W。交换机自己的 ASIC、CPU、风扇要先拿走“系统功率”,剩下的才进入 PoE 预算。加第二块 1600W,PoE 预算跳到 2750W;三块都是 1600W 时达到 4320W[2]。第二、三块电源带来的增量比第一块大,因为系统功率只扣一次。
调整终端数量、电源组合与上联模块,看两本账如何变化
PoE 可用预算取自 C9350 数据表 Table 7(48HX,主电源 PWR-C2-1600WAC,Combined 模式)。终端功率按其 PoE 等级上限保守预留,属于规划假设;实际预留可经 LLDP/CDP 协商得更低。1600W 电源在 115V 输入下仅输出 1200W,可用预算请用 Cisco Power Calculator 复核[4]。
交换机软件重启时,PoE 不中断。对 PoE 照明、门禁、楼宇传感器来说,这意味着升级窗口不再等于“灯灭窗口”[2]。
断电恢复后,PoE 在 IOS XE 完全启动前就开始供电,终端可以与交换机并行启动,而不是排在它后面[2]。
1600W 钛金级电源在 50% 负载时比金牌级效率高 4%,100% 负载时高 3%;每块电源保持时间约 20 ms,支持在线插拔[1]。
边界:Multigigabit 端口在 10/100 Mbps 下只支持全双工;48HXG 的 24 个 1G 口同样不支持 10/100 半双工[2]。老旧的半双工设备接入前需要确认。
C9350# show policy-map interface
C9350 的 Silicon One A100 用“虚拟输出队列 + 信用调度”把拥塞关在拥塞的那个出口里。这是它与上一代 UADP 接入交换机在缓冲架构上最根本的差别:不是缓冲更大,而是排队的方式变了。
数据来源:架构白皮书[1]、BRKARC-2668 第 31 页[3]。
先放第一块积木:缓冲。出口一时忙不过来,包就得在某处排队,好比收费站前的等候区。C9300 的 UADP 芯片主要把包排在出口一侧;Silicon One 则把包排在入口一侧[3]。
这立刻引出一个问题:在入口排队,如果队伍最前面那个包要去的出口正好堵死了,它身后那些要去畅通出口的包怎么办?
这就是第二块积木:队头阻塞(Head-of-Line Blocking)。想象一条单车道收费站,最前面的车要去一个正在封路的匝道,它停住了,后面所有去别处的车都只能干等——它们本来畅通无阻。
既然是排队的问题,把缓冲做大一点,能不能解决队头阻塞?
不能。缓冲变大只会让等候的队伍更长,队首那辆车仍然挡着所有人。队头阻塞是排序结构的问题,不是容量的问题。解决它需要改变排队的方式。下面的模拟器里,两种结构使用完全相同的缓冲容量和到达流量,你可以亲眼比较。
第三块积木:虚拟输出队列(VOQ)。每个入口不再只排一条队,而是为每个出口各开一条虚拟队列——就像路口的左转、直行、右转专用道,去封路匝道的车只堵自己那条道。
第四块积木:信用(credit)。入口的 VOQ 要先向目标出口申请“通行证”,出口有余量才发放;拿到信用的包才穿过交叉开关。于是包永远不会被送进一个已经塞满的出口,交换内部也就不会堵成一团。
比喻在哪里失效:专用道里排的并不是整个包。包体只在共享内存(SMS)里存一份,VOQ 里排的是指向它的“包描述符”(PD)[1]。所以 VOQ 不会把缓冲需求乘以出口数——这也是下面模拟器给两种结构相同缓冲容量的原因。
教学模型:3 个入口、3 个出口,每个入口缓冲 8 个包(VOQ 模式下 3 条虚拟队列共享这 8 个位置)。用于说明机制,不代表 A100 的实际队列数量与调度算法细节。
机制清楚了。那么,一个包在 A100 里实际走过哪些站?
C9350# show sdm prefer
零信任把策略推到了离终端最近的地方,接入交换机要记住的东西因此暴涨。A100 用三张“中央表”分工:LPM 查路由,CEM 查精确匹配,HCAM 查策略。其中 HCAM 以散列表为主、TCAM 兜底,让 C9350 默认就能装下 32K 条 ACE——C9300X 的 4 倍,C9300 的 8 倍。
| 接入层三代 | C9300 / 9300L(Gen1) | C9300X(Gen2) | C9350(Gen3) |
|---|---|---|---|
| 定位 | 成本优先 | 功能优先 | 规模优先 |
| IP 路由 | 8K IPv4 / 4K IPv6 | 16K IPv4 / 8K IPv6 | 256K IPv4 / 128K IPv6 |
| MAC 地址 | 32,000 | 32,000 | 64,000 |
| /32 主机路由 | 32,000 | 32,000 | 96,000 |
| ACE 条目 | 4,000 | 8,000 | 32,000 |
| 下行 | 按型号 | 最高 10G 下行 + 90W UPOE+ | |
来源:BRKARC-2668 第 80 页“Choose the right Access Switch for legacy Migration”[3]。C9350 数值为硬件能力;数据表按当前软件给出的可用规模为 IPv4 路由 192,000、Security ACL 5,000–32,000(仅第一种 ACL 类型可用扩展规模)[2],设计时以所用 IOS XE 版本为准。
规则多了,为什么不直接把 TCAM 做大四倍?
先认识 TCAM(三态内容寻址存储器)。它像一屋子办事员:你喊一声“谁匹配这个包?”,所有人同时查自己手里那条规则并举手,一个时钟周期出结果。它支持任意掩码,最快也最灵活——但每个办事员都要“领工资”:TCAM 密度低、功耗和发热高,扩容很贵[3]。
再看一个容易被忽略的事实:真实 ACL 的掩码非常“扎堆”。BRKARC-2668 的示例里,4 万条规则只用了两种掩码——前 2 万条都是 0.0.0.3(/30),后 2 万条都是 0.0.0.7(/29)[3]。
掩码相同,就意味着可以先把包的地址“套上这个掩码”,再做一次精确查找——而精确查找用便宜、密集的 SRAM 散列表就够了。这就是 HCAM(算法 TCAM)的思路:常见掩码的规则各占一个散列 tile,只有少数冷门或不连续掩码的规则才进入真正的 TCAM。像邮局分拣:格式规整的邮编直接投进对应格子,只有写得古怪的地址才送人工窗口。
A100 的 HCAM = 8K 原生 TCAM + 128K 算法 tile 表项(8 × 16K),可在 ACL、QoS、NetFlow 之间动态分配;默认 SDM 模板中每个 tile 一半给 ACL、一半给 NetFlow 缓存[1][3]。
SRAM 表,按最长前缀匹配查 IP/掩码路由。片上 256K IPv4 或 128K IPv6(IPv6 占两个表项)。接入层第一次拥有接近汇聚层的路由容量,为分布式三层接入、BGP EVPN 留出余量[1]。
SRAM 表,存 MAC、/32 与 /128 主机路由、组播、标签、SGT 等“每一位都要对上”的条目。256K IPv4 / 128K IPv6 规模,且可以在各张子表之间重新分配[1]。
TCAM + 散列 tile 混合,服务安全 ACL、QoS ACL 与 Flexible NetFlow。比传统 TCAM 更密、更省电,取消了僵硬的固定分区,碎片更少[1]。
对象组 ACL(OGACL)把“地址组 × 地址组”的组合写成一行。BRKARC-2668 的示例中,一个含 1,000 个地址的对象组,在 Silicon One 上只消耗 3 条 HCAM,地址本身展开到 1,000 条 CEM——把最贵的资源留给真正需要掩码匹配的规则[3]。默认模板下 C9350 的 Security ACL 总量为 36,864,FNF 流表 65,536,可用 show sdm prefer 查看。
C9350# show switch stack-bandwidth
StackWise-1.6T 把堆叠从专有协议改成了标准以太网:VXLAN 封装、基于 SPF 的最短路径转发,由 A100 内专用的堆叠 NPU 线速处理。结果是,环上一根线断了,只有这根线两端的两台从 1.6T 降到 800G,其余成员仍然全速。
8 台交换机连成一个环。其中一根堆叠线被误拔,会影响多少台交换机的堆叠带宽?
取决于是哪一代堆叠。上一代 StackWise 把包切片后在环的两个方向上负载分担,一处断开会让整个堆叠的带宽实际减半;StackWise-1.6T 下只有断点两端的两台受影响——show switch stack-bandwidth 会显示它们为 800G,其余成员仍为 1600G[3]。下面可以亲手剪一根线试试。
| 成员 | 角色 | 堆叠带宽 |
|---|
带宽数值依据 BRKARC-2668 第 62 页的 show switch stack-bandwidth 输出;上一代架构以相对值表示。
数据平面合成了一台,电呢?八台各自的电源能不能也“合成一个”?
可以,但范围是 4 台。StackPower+ 用后部专用端口和 55A 额定电流的线缆,把最多 4 台交换机的电源合成一个共享电力池;电源故障或负载突增时,功率在池内即时重新分配,有效可用功率比上一代 StackPower 高出 35% 以上[1]。8 台的数据堆叠可以拆成两个 4 台的电力堆叠。
它有两种模式。共享模式(默认):所有电源的输出都进池,坏一块只要剩余容量还够就无感。冗余模式:把最大一块电源的容量预留为备份,平时可用预算变小,但故障时有立即可用的余量[1]。
示意算术:4 台 × 3 块 1600W 即 BRKARC-2668 所示 19.2 kW 共享池;示例负载 14,000W 为假设值;未计入系统功率与效率损耗,实际预算以 show stack-power budgeting 为准。
C9350# show app-hosting list
C9350 给接入交换机配了一套服务器级的控制平面:x86 CPU、16 GB DDR5、最高 240 GB 可更换 SSD。其中 4 vCPU 与 8 GB 内存专门划给容器,再用 2 个 10G AppGig 端口把应用直接接到转发芯片上——应用离用户只有一跳,又与交换机自身的控制与转发相互隔离。
交换机为什么需要跑应用?把应用放在机房的服务器上不行吗?
有三类应用,放在机房恰恰是错位的。第一类是体验测量:用户抱怨“Teams 卡”,从机房测到的路径并不是用户的路径;ThousandEyes 代理跑在接入交换机上,测的就是这一层楼的真实出口。第二类是贴近终端的连接器:Cisco Spaces 需要尽量靠近 AP 与 IoT 设备收集数据。第三类是没有机房的地方:分支、门店、气隙环境,多一台服务器就多一份采购、空间、电源和运维[1][2]。
Catalyst 9000 支持应用托管已有多年,C9350 的变化在于资源翻了一档:应用内存翻倍,CPU 快 35% 以上,DDR5 快 13% 以上[3]。
| 资源 | C9350 规格 | 意味着什么 |
|---|---|---|
| CPU | x86 多核,Intel 第 12 代 Core 系列(BRKARC-2668 标注 i3-1316URE) | 控制平面处理 AVC/XDR 等软件辅助服务更从容,并为容器划出 4 vCPU |
| 内存 | 16 GB DDR5,其中 8 GB 专供应用 | 应用内存为上一代的 2 倍 |
| 存储 | 18 GB 内部 eUSB 闪存 + 后部可换 USB 3.0 SSD(120 / 240 GB,EXT4,硬件 AES-256,SMART 监测) | 第三方应用、抓包、trace 日志、GIR 快照放在 SSD;Cisco 签名应用可直接放闪存,无需 SSD |
| 应用网络 | 2 × 1/10G AppGig 端口 | 应用以线速收发流量,不占用前面板业务端口 |
| 高可用 | 堆叠内应用托管 1+1 | Active 成员故障时应用在 Standby 上接续 |
| AI 推理 | C9350-48HXG:8 核 CPU + 集成 GPU | 硬件已为在交换机上运行小型 AI 推理负载做好准备 |
来源:架构白皮书[1]、数据表[2]、BRKARC-2668 第 8、66、67 页[3]。
边界:交换机上的算力是为“贴近网络边缘的轻量服务”准备的,不是要替代机房服务器。具体可托管哪些应用、各自占用多少资源,以 Cisco 认证应用列表与 IOS XE 版本说明为准。
C9350# show platform integrity
C9350 的安全不只在 ACL 里,而是从“这台设备是不是它自己”开始。Trust Anchor module 作为硬件信任根,逐级验证引导代码与 IOS XE 镜像;这条链在硬件上已为后量子签名做好准备,数据表列出的 PQC 支持始于 IOS XE 26.2.1。数据在线路上则由线速 MACsec 与最高 100G 的硬件 IPsec 保护。
先放一块积木:数字签名。Cisco 用私钥给软件镜像贴一道“封条”,交换机用出厂时就固化的公钥核对封条:封条完好,说明镜像没被改过、确实来自 Cisco。它的边界也要说清:封条只证明“没被动过、来源可信”,不证明代码没有漏洞——运行时防护是另一层的事。
再放第二块:信任链。启动是一场接力,每一棒在交棒前先核验下一棒:硬件信任根核验引导代码,引导代码核验 IOS XE,IOS XE 再在运行期持续自检。任何一环核验失败,接力就停在那里。链的起点必须是改不掉的硬件,这正是 Trust Anchor module(TAm)的角色:存放设备身份证书(SUDI)与密钥,抵御仿冒硬件[1][2]。
那么,量子计算机威胁的到底是这条链的哪一环?
不是“明天就能解开所有加密”,而是更隐蔽的一点:今天广泛使用的 RSA、ECC 签名,在足够强大的量子计算机面前可以被伪造。封条一旦可以伪造,一个被篡改的镜像就能堂堂正正通过核验。NIST 已为此标准化了后量子签名算法,包括基于哈希的 LMS 与基于格的 ML-DSA[8][9]。
交换机的特殊之处在于:信任根焊在硬件里,以后无法靠升级补上。所以 C9350 在硬件上提前预备了三件事——SUDI 证书可使用 PQC 签名(如 ML-DSA-87)、引导程序具备 LMS 签名校验能力、存储用于验证操作系统的 ML-DSA 镜像签名密钥[3]。
Trust Anchor module:设备身份(SUDI)、安全密钥存储,证明“硬件是真的 Cisco”。
—核验引导代码的签名,确认引导程序未被修改。
—核验 IOS XE 镜像签名;C9350 运行 PQC 签名的 IOS XE。
—运行期完整性检查与运行时攻击防护,可用 show platform integrity 远程证明。
教学示意。PQC 软件支持版本以数据表为准(IOS XE 26.2.1 起)[2];BRKARC-2668 将部分 PQC 能力标注为“硬件就绪、软件路线图”[3]。
设备本身可信了,那么从它身上经过的数据呢?
A100 内嵌 AES-GCM 256 位加密引擎。MACsec 采用逐跳“线中插件”模型:入口解密、出口加密,包在交换机内部是明文,所以 ACL、QoS、NetFlow 等检查照常进行。适用于防窃听、防中间人、防仿冒接入[3]。
站点到站点、对接云安全服务(SIG)的 IPsec 由硬件完成,最高 100G,同样使用 AES-GCM-256;另支持 WAN MACsec[2][3]。
按身份(SGT)而不是按 IP 写策略;HCAM 的大容量让上万条分段规则在接入层线速执行。SD-Access 已支持,BGP EVPN 自 IOS XE 26.1.1 起[2]。
C9350 硬件已为 Live Protect 做好准备,可在线检测并阻断针对软件漏洞(包括零日漏洞)的攻击,在补丁到来之前争取时间[2]。
看得见才管得住:硬件 Flexible NetFlow、NBAR 应用识别、SPAN/ERSPAN 镜像、IP Device Tracking 提供终端与应用可见性;与 Cisco XDR 的集成将在后续软件版本提供[2]。
C9350# show license summary
C9350 把硬件、软件、许可证和支持合成一个系统。同一台交换机、同一份许可证,开箱即可选择被 Catalyst Center(本地)或 Meraki Dashboard(云)认领——不需要 -M 专用型号,不需要转换 CLI,也不必在采购那一刻押注管理方式[3]。
管理方式为什么值得在硬件层面保持可选?
因为决定管理方式的,往往是组织而不是设备:一次并购、一份外包合同、一条“必须物理隔离”的合规要求,都可能在交换机的服役期内改变答案。过去改答案意味着换硬件;C9350 让它变成一次重新认领。
交换机保持 IOS XE 模式,在 Catalyst Center 的 PnP 页面等待认领[3]。
此外,Meraki Dashboard 也可只做库存与许可证管理,而不接管配置[2]。
C9350# show inventory
C9350 家族共 16 个型号,全部基于 A100、全部支持 StackWise-1.6T、全部可在 Catalyst Center 与 Meraki 之间选择管理方式。差别只在三件事上:下行介质与速率、每口供电等级、以及要不要双 ASIC 带来的 400G 上联。
按终端需要的介质与供电筛选
16 个型号
24 × 10M/100M/1G 铜缆 · 不供电
1 × A100 · 上联最高 200G
48 × 10M/100M/1G 铜缆 · 不供电
1 × A100 · 上联最高 200G
24 × 1G · PoE+ 30W · 预算 720W
1 × A100 · 上联最高 200G
48 × 1G · PoE+ 30W · 预算 1440W
1 × A100 · 上联最高 200G
24 × 1G · UPOE 60W · 预算 1440W
1 × A100 · 上联最高 200G
48 × 1G · UPOE 60W · 预算 2880W
1 × A100 · 上联最高 200G
48 × 10G mGig · 不供电
2 × A100 · 上联最高 400G
48 × 10G mGig · UPOE+ 90W · 预算 4320W
2 × A100 · 上联最高 400G
24 × 10G mGig · UPOE+ 90W · 预算 2160W
1 × A100 · 上联最高 200G
36 × 5G + 12 × 10G mGig · UPOE+ 90W · 预算 4320W
1 × A100 · 上联最高 200G
48 × 2.5G mGig · UPOE+ 90W · 预算 4320W
1 × A100 · 上联最高 200G · 利旧铜缆
24 × 10G mGig + 24 × 1G · UPOE+ 90W · 预算 4320W
+8 GB 深缓冲 · 8 核 CPU + 集成 GPU · SyncE
24 × 1G SFP 光纤
1 × A100 · 上联最高 200G
48 × 1G SFP 光纤
1 × A100 · 上联最高 200G
12 × 1/10/25G SFP28
1 × A100 · 上联最高 200G
24 × 1/10/25G SFP28
2 × A100 · 上联最高 400G
来源:C9350 数据表型号说明与 Table 11 最低软件版本[2]。Multigigabit 型号在 10/100 Mbps 下仅支持全双工。
| 模块 | 端口 | 总带宽 | 适用型号 |
|---|---|---|---|
| C9350-NM-2C | 2 × 100G/40G QSFP | 200G | 全部模块化上联型号 |
| C9350-NM-4C | 4 × 100G/40G QSFP | 400G | 仅 C9350-48HX / 48TX / 24Y |
| C9350-NM-8Y | 8 × 25G/10G/1G,或 4 × 50G | 200G | 全部模块化上联型号 |
| C9350-NM-8L | 8 × 50G/25G/10G/1G | 400G | 仅 C9350-48HX / 24Y |
| C9350-NM-8M | 8 × 10G Multigigabit RJ-45 | 80G | 多数型号(以数据表为准),适合利旧铜缆上联 |
所有上联端口线速、与下行端口功能一致;支持在线插拔与 ACT2 硬件认证;交换机默认不含上联模块[1][2]。
C9350# show running-config
同一台 C9350,在不同的楼里被不同的需求“点名”。下面四个场景各以一种供给为主,说明该选哪个型号、开哪些能力。
方案示例 · 具体配置需按现场终端清单核算每层几十台 Wi-Fi 7 AP、会议室大屏与视频终端,午间与会议开场的突发流量集中。
2–4 × C9350-48HX 堆叠 · NM-4C 4 × 100G 上联 · 每台 3 × 1600W
照明、门禁、传感器、楼宇控制器都从交换机取电,“交换机重启 = 灯灭”不可接受。
C9350-48U(60W)或 48HX(90W)· StackPower+ 4 台共享电力池
门店没有 IT 人员也没有机房,总部想知道“收银系统慢”到底慢在门店、运营商还是 SaaS。
C9350-24P / 24HX · Meraki 云端配置 · 交换机内托管 ThousandEyes 代理
医疗设备、产线终端对时钟、突发与安全隔离都敏感,且设备生命周期很长。
C9350-48HXG · MACsec-256 · TrustSec 分段
C9350# write memory
开篇的问题是:五样需求同时变大,接入交换机要换掉什么?C9350 的答案是把芯片、堆叠、供电、控制平面和信任根一起换掉,于是一台 1RU 同时交付四种供给,并用统一的运营方式交到你手里。
| 如果你的情况是 | 建议 | 如何验证 |
|---|---|---|
| 计划部署 Wi-Fi 7 AP 或 60–90W 终端 | 以 48HX / 24HX / 48HXN 为主,按终端组合选 48HM、48HXG | 用本文控制台与 Cisco Power Calculator 核算 PoE 预算和上联收敛比[4] |
| 零信任分段推进,接入层 ACL 将超过 8K 条 | C9350(默认 32K ACE),配合 OGACL 节省 HCAM | show sdm prefer;在 Cisco Feature Navigator 核对目标版本特性[5] |
| 现网是 C9300 堆叠,需要扩容 | 新楼层或新堆叠整体采用 C9350,不与 C9300 混合堆叠 | 核对堆叠线、电源、上联模块与备件均为 C9350 专用料号[2] |
| 管理方式尚未确定,或可能随组织变化 | C9350 + 统一许可证(Cisco Networking Subscription 或 EA) | 试点时分别在 Catalyst Center 与 Meraki Dashboard 各认领一次[7] |
| 合规要求后量子密码 | 选择 PQC 已支持的 IOS XE 版本(数据表列为 26.2.1 起) | 核对版本说明与 show platform integrity 输出[2] |
References
产品照片与架构图版权归 Cisco 所有,取自上述官方资料。本文研究截止日期:2026 年 10 月 20 日。
Glossary