ARTICLE DETAIL

资讯详情

深耕网站视觉设计与运营推广的一线实战洞察。

上海贝尔阿尔卡特7750 SR OS:从开局配置到专线业务排障

上海贝尔阿尔卡特7750 SR OS:从开局配置到专线业务排障 简介上海贝尔阿尔卡特7750配置文档是一份面向企业网、电信网及数据中心运维人员的实用技术参考聚焦7750 SR路由器的硬件组件识别、设备管理及路由协议配置等核心操作。文档对应完整包体共1个doc文件压缩后大小约267KB虽体量精简但内容覆盖全面便于快速查阅。目前已有630人学习/下载。文档从硬件配置入手详细讲解IOM卡、MDA卡及POS/以太端口的查看与配置方法随后介绍路由器名称、系统时间、SNTP、Telnet服务等设备管理设置路由协议部分则涉及OSPF、RIP、ISIS等常用协议的配置思路。通过具体命令示例和分步说明读者可对照自身环境完成基础配置与排错尤其适合从事阿尔卡特设备维护的网络工程师作为日常手册使用。1. 上海贝尔阿尔卡特7750为什么说它是一台「配置文档依赖度」很高的核心设备提到上海贝尔阿尔卡特7750配置文档先别急着翻命令手册。7750 SR 是一台典型的「开局容易、业务难」的运营商级业务路由器端口起来很简单但接入、专线、QoS、冗余和排错全都压在配置细节上。我见过太多工程师把这台设备当思科配结果 SDP 起不来、SAP 状态不对最后只能用 show 命令一行行查。这篇笔记就是我给自己和团队留的配置文档级复盘——从串口开局到专线业务跑通再把常见翻车点一次说清。适合刚接手 7750 的承载网运维、做企业专线交付的系统集成商以及想系统理解 SR OS 配置哲学的甲方网络管理员。2. 开局第一件事接入、管理面与第一次保存基础不牢后面全白搭拿到的 7750 如果是一台原厂设备第一个要解决的问题不是配置业务而是怎么安全地进入命令行、把管理面配上、并把第一份配置完整保存下来。很多人在这一步就埋下了隐患管理 IP 没配、SSH 没开、save 的理解还停留在「commit 就是保存」的阶段。SR OS 的命令行体系和思科、华为差异很大开局阶段的几个习惯直接决定后面变更是否可控。2.1 用串口线进 MD-CLI 的最小命令序列7750 默认推荐用 MD-CLI 风格操作逻辑上接近一棵可折叠的配置树。串口接入后默认提示符长这样A:7750-1#这个提示符表示你已经站在 MD-CLI 的全局根节点。和经典命令行不同MD-CLI 更依赖层级路径而不是到处敲configure interface这种扁平动词。第一次接入建议先做三件事确认软件版本、查看现有运行配置、把终端长度关掉避免翻页卡住。A:7750-1# show version A:7750-1# show configuration A:7750-1# environment no moreshow version会输出 SR OS 的软件版本和机框型号这是后续找命令差异的依据。show configuration看当前运行中的配置全文新设备可能只有出厂默认内容。environment no more是关闭分页的命令等价于思科的terminal length 0否则配置多了以后每屏都会停下来等回车写脚本时会非常痛苦。串口参数我一般固定用 115200 波特率8 数据位、无校验、1 停止位关闭流控。有些老模块默认只支持 9600如果出现乱码先切回 9600 试一次。改波特率这类动作本身不产生业务影响可以在开局阶段直接做。2.2 配置管理 IP、SSH 与默认路由三个必须改的默认值管理面是所有后续操作的生命线。7750 的设备管理可以走带内也可以用专用的管理口我习惯把管理 IP 放在独立的 VRF 里避免业务路由抖动把管理面带崩。为简化这里先用全局路由表做一个最小可运维配置A:7750-1# configure A:7750-1# /configure router Base interface loopback0 A:7750-1# /configure router Base interface loopback0 address 10.10.10.1/32 A:7750-1# /configure router Base static-route 10.98.0.0/16 next-hop 172.16.0.1 A:7750-1# /configure system security ssh A:7750-1# /configure system security ssh admin-authentication local A:7750-1# /configure system netconf A:7750-1# commit配置 IP 时注意SR OS 的地址是写在「接口」下的而且接口必须先有名字。上面创建了一个名为loopback0的回环接口地址是 10.10.10.1/32。static-route命令设置了去往内网网段的静态路由。SSH 管理默认是开着的但生产习惯建议关掉 Telnet只开 SSH 和 Netconf。参数说明interface loopback0名字可以自己起但引号里的字符串要全局唯一。address子句支持一个接口挂多个地址加secondary后缀就行。如果把 SSH 的认证指定为 local那么本地管理员账号必须已经设了密码否则会出现「SSH 端口通、但认证进不来」的尴尬状态。这里有个很容易踩的差异点NG 版New Generation和 MD-CLI 的路径写法有时不同。如果你在/configure router Base下敲interface loopback0发现补全不出来先执行tree命令看当前节点支持哪些子命令。树形命令的优点是可发现性强缺点是阅读旧配置时会发现router Base和router Base混写都合法。2.3 配置文件管理save、admin-save 与 rollback 的后悔药机制SR OS 的配置管理是「候选配置激活配置」双层架构。你敲的每条命令都在修改 candidate执行commit后才会进入运行配置。但commit 不等于持久化保存。如果此时设备断电所有改动丢失。这是新手翻车率最高的一点。A:7750-1# /admin save A:7750-1# /admin rollback save/admin save是将当前运行配置写入启动配置文件下次重启自动加载。/admin rollback save把当前状态存为一个回滚点方便出问题时快速恢复相当于给网络配置拍了一张快照。回滚查看和恢复的命令A:7750-1# /show system rollback A:7750-1# /admin rollback 3 A:7750-1# /admin rollback 20250101-1200show system rollback会列出所有回滚点的序号和时间。rollback 3直接恢复到第三个回滚点rollback 名称按名字恢复。注意 rollback 只恢复配置不会恢复「已经被删除的文件」。真正删掉的配置文件可以从cf3:的备份目录找回那是文件系统层面的事。我的习惯是开局完成后先admin save一次再admin rollback save一次作为交付基线。之后的每次变更变更前 rollback save 一次变更后 save 一次。这样无论变更怎么翻车都能回到上个稳定点。生产环境里「后悔药」比「极限操作」重要得多。3. 把专线业务跑起来VLL 与 VPLS 的完整配置路径与选型开局做完只代表设备能管理了真正的交付是业务。7750 在运营商网络里最常见的任务不是跑一个普通三层接口而是承载大客户专线点到点专线、多站点局域网互联、商务楼宇接入。这一章我会把 VLL 和 VPLS 两条主路径拆开讲并给出选型建议。3.1 最短业务路径SAP、Spoke-SDP 与 VLL 的层级关系先建立一个三层认知SAPService Access Point是业务在用户侧接入的端口或 VLANSDPService Distribution Point是把业务封装后穿过核心网的隧道端点VLL也叫 Epipe是把 SAP 和 SDP 绑定在一起的二层服务实例。三者缺一不可。下面是创建一个点到点 VLL 的完整命令。这里假设物理端口 1/1/3 的 VLAN 100 接入用户核心侧通过 MPLS 隧道发送到对端 10.10.10.2。A:7750-1# /configure port 1/1/3 ethernet mode access A:7750-1# /configure service epipe VLL-100 customer 1 create A:7750-1# /configure service epipe VLL-100 sap 1/1/3:100 create A:7750-1# /configure service epipe VLL-100 sap 1/1/3:100 no shutdown A:7750-1# /configure service sdp 10 mpls create A:7750-1# /configure service sdp 10 far-end 10.10.10.2 A:7750-1# /configure service sdp 10 keep-alive shutdown A:7750-1# /configure service epipe VLL-100 spoke-sdp 10:100 create A:7750-1# /configure service epipe VLL-100 spoke-sdp 10:100 no shutdown A:7750-1# commit逻辑说明先把物理端口设为 access 模式再创建epipe服务实例。sap 1/1/3:100表示使用端口 1/1/3 的 VLAN 100 作为接入点1/1/3前面不加port因为 SAP 语法本身就是端口定位。然后创建名为 10 的 SDPfar-end指定对端地址MPLS 承载会自动找 LSP。最后在 epipe 里把 SDP 10 的 VC ID 100 绑定为 spoke-SDP形成完整的端到端通道。这里有几个参数必须敲对。epipe VLL-100引号里的名字本地唯一通常用客户编号业务编号的组合比如1220-0100。sap 1/1/3:100冒号后面是 VLAN ID注意如果是接入 trunks 模式业务会同时匹配多个标签这块容易和 access 模式混淆。spoke-sdp 10:100的冒号后是 VC ID这个值在对端必须一致否则业务状态起不来。我把keep-alive shutdown关了原因是本地和远端 SDP 之间默认启用了 SDP keep-alive 检测机制这个机制在二层专线场景偶尔会造成伪线震荡。很多老工程师宁愿用伪线的 OAM 机制代替 SDP keep-alive这也是一种取向。3.2 VPLS 多站点配置水平分割、MAC 学习与 STP 的取舍VPLS 解决的场景是多站点二层互通。典型如一个企业总部加两个分支要求所有站点在同一个二层网段。VPLS 的配置在 epipe 之外多一步因为是多点到多点SR OS 需要把「哪些 SDP 参与转发」以及「哪些 SAP 属于同一个广播域」管理起来。A:7750-1# /configure service vpls VPLS-88 customer 1 create A:7750-1# /configure service vpls VPLS-88 sap 1/1/3:88 create A:7750-1# /configure service vpls VPLS-88 sap 1/1/4:88 create A:7750-1# /configure service vpls VPLS-88 spoke-sdp 10:88 create A:7750-1# /configure service vpls VPLS-88 spoke-sdp 11:88 create A:7750-1# /configure service vpls VPLS-88 no stp A:7750-1# /configure service vpls VPLS-88 mac-learning A:7750-1# commitspoke-sdp 10:88和spoke-sdp 11:88分别连到两个分支站点no stp表示关闭 VPLS 实例内的生成树协议mac-learning默认是开的也可以显式写出来。这里的关键参数是 spoke-SDP 之间的水平分割。SR OS 默认在 VPLS 里 spoke-SDP 之间不会转发二层的广播和未知单播这可以避免环形拓扑产生广播风暴。但如果你想在站点之间做全互联就必须额外配置spoke-sdp的no disable-aging或直接使用 mesh-SDP。另外要注意VPLS 里的 SAP 和 spoke-SDP 不在同一个水平分割域也就是说接入端口收到的广播报文可以进入 SDP 转发出去。如果某个交换机在远端把两个站点串成了一个环路VPLS 自身不会帮你破环因为水平分割只约束 SDP 之间不约束 SAP。MAC 学习参数mac-learning下有几个值得调节的选项默认 MAC 地址表老化时间是 300 秒终端数量大的场景建议通过mac-table的aging调长max-mac-count可以限制学到的主机数量防止环路导致 MAC 表爆炸。排障时show service id VPLS-88 mac-table能看到每个 MAC 是从哪个 SAP 或 SDP 学到的这是判断流量走向最重要的命令之一。3.3 商务楼宇专线与点到点专线怎么选VLL 还是 VPLS实际交付时总会遇到一个灵魂拷问客户说「我要一条专线」到底给 VLL 还是 VPLS我的原则是先区分拓扑。只有两个端点、纯粹跑点对点互联用 VLL配置最简单、排障路径最短、也最容易向客户解释。超过两个站点且它们之间要二层互通用 VPLS。对比项VLLEpipeVPLS站点数量2 个超过 2 个二层广播无广播域概念存在广播域需要控制水平分割MAC 学习不需要需要且要关注老化大户配置复杂度低中高典型场景点对点专线、存储互联多分支局域网、IDC 互联另一个偏商业的判断标准是 SLA 承诺的服务粒度。VLL 的故障边界天然更清晰一条 VLL 挂了只影响一个客户排障时直接看 SAP 状态和 VC 状态即可VPLS 出了问题广播流量风暴可能波及多个站点调试时涉及更多维度。对于刚接手 7750 的团队我建议第一个业务从 VLL 做起把 VLL 调通并养成完整的配置习惯后再碰 VPLS。4. 调通之后才是坑的开始7750 故障排查与配置避坑现象→原因→解决配置文档写再多最后都要回到故障现场。下面这五条是我在 7750 上真实遇到并解决过的问题每条都按「现象→原因→解决」展开。它们不是偶发个例而是新团队接手 7750 时必然会踩的坑。4.1 现象一业务口 up 了但流量不通MTU 和 LAG 哈希在作祟接入侧端口显示port is up客户那台设备也能看到链路但业务就是不通。查看 SAP 状态显示upping 大包不通小包能通。这时候 MTU 的嫌疑最大。SR OS 的接口 MTU 是全局生效的默认值很高但接入交换机如果只按 1500 发帧而 7750 的 service 层对帧做了额外封装就会导致超过对端处理能力的帧被静默丢弃。解决办法是先确认 end-to-end 的 MTU 预算再同步调整端口和业务层的 MTU 设置。A:7750-1# /configure port 1/1/3 ethernet mtu 2000 A:7750-1# /configure service vpls VPLS-88 sap 1/1/3:88 ethernet mtu 2000 A:7750-1# commit这里有个容易被忽略的参数如果用了 LAG 接入且 LAG 成员端口速率不一致那么哈希结果可能导致所有流量都打在同一个成员口上出现「某个端口流量打满、其他端口闲置、整体吞吐上不去」的现象。检查show lag 1 statistics时注意每个成员口的丢包计数值必要时打开per-service-hashing开启按业务哈希避免二层业务在成员口之间乱跳。4.2 现象二改配置后没有生效commit 与 save 的区别没搞清楚「我明明在配置里加了 qos怎么业务测出来没变化」这是最常见的现场反馈。原因大概率是你只敲了命令没有commit配置停在候选区或者 commit 了但没 save设备一重启又回到旧配置。建一个清晰的检查习惯每改完一段配置先用show configuration对比确认候选配置里出现了目标内容再执行commit然后save。只要跳过其中一步后续排障就要花费十倍时间。A:7750-1# /show configuration | match qos|sap A:7750-1# /admin saveshow configuration | match会过滤出配置中包含相关关键字的行快速确认改动是否进入运行态。注意 SR OS 的管道符过滤语法和思科不同过滤条件要写在管道后面不支持思科那种show run | include xxx的写法在 MD-CLI 下通用。4.3 现象三VLL 显示 up 但报文丢弃服务状态机的几层状态怎么看VLL 业务最让人困惑的一点是「SDP up 不代表 VC upVC up 不代表业务通」。SR OS 服务状态是分层的物理口 → SAP → SDP → spoke-SDP/VC → 业务层。每一层都有独立状态互相依赖但不同步。查看顺序我建议固定为先show port 1/1/3确认物理层再show service id 100看服务整体状态然后show service sdp 10看 SDP 状态最后show service id 100 spoke-sdp看 VC 状态。如果 SDP 是 up 但 spoke-SDP 是 down常见原因是 VC ID 对端不匹配。A:7750-1# /show service id 100 A:7750-1# /show service sdp 10 A:7750-1# /show service id 100 spoke-sdp还有一个隐藏状态如果 SDP 配置成了 GRE 承载但两端没有正确设置隧道 IP 和 keep-aliveVC 会长期卡在up/down抖动。不要只看 SDP 的up要盯住 VC 的OperState。这个值等于up才是业务可用的真正信号。4.4 现象四配置文件回滚失败文本编码和换行符导致的「玄学」有一次我尝试 rollback 到前一天的回滚点系统提示成功但业务参数明显还是旧的。查了半天发现是有人直接用外部编辑工具改过配置文件文件里的换行符变成了 Windows 风格的 CRLF终端显示正常但 SR OS 解析时出现异常。解决方法是配置文件尽量在设备上用edit或vim修改不要从 Windows 本地用记事本改完再传。如果实在要外部编辑传输时使用二进制模式上传后先执行一次show configuration对比关键段落确认无解析异常再admin save。回滚操作本身是可靠的不可靠的是被人为编辑过的文件内容。4.5 现象五升级 SR OS 后原有配置不兼容降级与迁移思路软件升级后业务 RIS 起不来的情况并不罕见。SR OS 的配置文件在跨大版本升级时部分命令会被标记为 deprecated但还在解析也有些参数被改名比如老版本里的service-policy在新版本里换成queue-policy。升级前必做两步admin save存当前状态再show configuration导出全文并本地归档。升级后用show system errors查看解析告警重点看ERROR级别的提示WARNING可以先忽略。如果新版本确实无法承载旧配置降级不是丢脸的操作——在变更窗口内回到旧版本永远比在业务中断状态下强行修配置更专业。5. 收尾的进阶技巧批量开局、变更前检查和一套 A4 评审清单最后一个部分不是总结而是我每天实际用到的三件事批量推配置、变更前检查、以及一张贴在工位上的评审清单。批量开局时我习惯用 Python 的 Paramiko 库直连 SSH。这里有一个 7750 特有的坑SR OS 的 CLI 提示符会因为登入用户和节点名变化脚本里用正则匹配提示符时不能写死A:7750-1#而是用rA:\S?[#]\s*$这类 pattern否则命令回显慢或分页开启时脚本会在半路断掉。变更前五分钟我固定执行一组命令/admin save、/admin rollback save、/show system uptime。前两个保证有后悔药最后一个用来确认设备不是刚重启过——刚启动完的设备 CPU 可能还在处理缓存预热此时变更容易误判故障。我那张 A4 评审清单长这样业务编号和客户名称是否匹配SAP 的端口、VLAN 是否和资源分配表一致SDP 的 far-end 是否与对端打通VC ID 两端是否一致MTU 是否符合端到端预算是否已 commit 并 save是否已记录变更回滚点是否已通知对端配合验证。这套清单看起来简单但能挡住八成的低级错误。我到现在都保留着写完配置先对着清单过一遍的习惯尤其在深夜变更窗口。希望帮到你。本文还有配套的精品资源点击获取
返回列表