UCS 产品线内硬件算是强耦合，管理都要走 UCS Manager ，故 UCS 6200 这类 Fabric Interconnect 大概率只能和 UCS 服务器搭配使用；加上 FI 只有二层交换能力，已经妥妥和 N5K 拉开差距了。

端口间交换带宽在这问也没用啊。。先不说端口间互联速率会取决于机器内部交换芯片数量和选型、外围电路设计，而且 400 能答复就已经很好了，这类核心信息有些厂商研发都不愿意提供给客服部门。

因一般同芯片内交换是线速无阻塞的，如果楼主测试主机确实都在一个二层网络中，加上 400 明说不同形态端口间只有 10G 带宽，那遇到此类速率问题基本能确定是交换机硬件设计上的锅了，原因不出(a)两种端口挂在不同芯片下、但形成互联架构过程中的某组连线只能安排 10G 带宽；(b)芯片扩展性比较拉跨导致 4 个 SFP+端口需要共享同一条 10G 总线。

不过最后 400 的说法像是暗示 2 个 QSFP+间是满带宽互联的，可以考虑把其中一个拆成 4*10G 用看看是否还有瓶颈。

@wang418 @blankmiss @diguoemo
浙江移动确实有概率能转公网，前提是对接到有权限人员（网运中心。集团网短号电话过去成功率高，如果和客户经理关系好可以试试）并给合适理由。
https://i.imgur.com/PBbA5bM.jpg

既然猫棒不支持多对一映射，为什么不直接把单个用户侧 VLAN 同时划给多个电口，分别下接路由器 WAN 拨号呢？从主贴描述看运营商也没有限制单用户 VLAN 下能同时学习到的 MAC 地址数量，而且 PPPoE 建会话只要发起 MAC 不一样就不会冲突，不需要费心隔离广播域。

@phpfpm 针对#3 中描述的拓扑，假设 PA 的角色是透明网桥（ ETH0-1 桥接且不会过滤广播报文，即不是网关或路由模式）可以用纯二层组网实现你想要的效果，需要在 5600 上改动的配置也极少。


创建一个新 id 为非 1 的 vlan ，记为 x
g/1 配置 pvid = x
g/10 配置相同 pvid = x
若交换机和 PA 间启用了生成树协议，需要切换成能感知 vlan 的模式（ pvst ）
其余业务数据保持不变


以 g/2 下挂客户机 aaaa-bbbb-cccc 、g/1 下挂上级路由 dddd-eeee-ffff 为例，转发表学习到位以后双向网络就能通，而且报文走向应该符合楼主的要求，具体为
a) 客户机外发报文目的 MAC 为 dddd-eeee-ffff -> 交换机 g/2 查 vlan 1 表确定出接口 g/11 -> PA ETH1 查表确定出接口 ETH0 -> 交换机 g/10 查 vlan x 表确定出接口 g/1 -> 上级路由
b) 路由器回向报文目的 MAC 为 aaaa-bbbb-cccc -> 交换机 g/1 查 vlan x 表确定出接口 g/10 -> PA ETH0 查表确定出接口 ETH1 -> 交换机 g/11 查 vlan 1 表确定出接口 g/2 -> 客户机


底层转发表学习流程大致是这样的：

客户机发布 ARP 报文
客户机 -> g/2(5600 vlan 1 转发表学习 aaaa-bbbb-cccc 出接口 g/2) -> 泛洪至 g/11 进 PA ETH1(PA 转发表学习 aaaa-bbbb-cccc 出接口 ETH1) -> 泛洪至 PA ETH0 进 g/10(5600 vlan x 转发表学习 aaaa-bbbb-cccc 出接口 g/10) -> 泛洪至 g/1 进上级路由 LAN(上级路由器转发表学习 aaaa-bbbb-cccc 出接口 LAN)

上级路由器发布 ARP 报文
路由器 -> g/1(5600 vlan x 转发表学习 dddd-eeee-ffff 出接口 g/1) -> 泛洪至 g/10 进 PA ETH0(PA 转发表学习 dddd-eeee-ffff 出接口 ETH0) -> 泛洪至 PA ETH1 进 g/11(5600 vlan 1 转发表学习 dddd-eeee-ffff 出接口 g/11) -> 泛洪至 g/2 进客户机(客户机转发表学习 dddd-eeee-ffff 出接口交换机)


楼主若有兴趣可以用模拟器建立拓扑实验一下，用一台空配交换机平替 PA 就行。

@AlphaTauriHonda 是我对移动期望太高了 XD ，主要是当时客户经理表示年后高价值政企市场就会新增跨境加速业务，目前就口风和广告资料来看本地有些许进出口公司客户已经完成办理，只是路由还是老样子绕北京。鉴于业务已经能成单，而且有准备向电信学习的意思（ CN2 不下放给家庭客户的地区占大多数），估摸着上广出口就不会那么着急上线了。所以出口具体什么时间能开通，当下对我来说也是个未知数，抱歉。

有一说一，OLT 是改不了网关侧用户数据的（比如域名解析条目），要实现也是需要通过智能网关管理平台走 TR069 发；但每个厂商的网关底层配置树路径大相径庭，适配起来很花时间，故应该没有一家运营商会这么操控域名解析。一般向网关发起 DNS 请求后返回 127 或 0 的基本是运营商省 /市 /区级 DNS 服务器（ WAN 侧自动分配或 UDP53 无差别劫持）的锅，至于为什么这么做有待研究 --- 兴许是为了验证能否减少核心网出口（或者墙？）负担之类的。

“数据不知道要到另外一个网口”？交换机正常学习到客户端 MAC 地址后就可以查表把报文往对应端口送啊，除非(a)两侧设备交互的不是以太报文(b)报文已经带了 vlan 。如果是前者用直通头是唯一方案，后者要不让 5600 也参与这部分 vlan 的转发，要不配置 q-in-q 。

有一定概率是城域 /省网路由配糊了，毕竟连自家 CMI 的地址都不能通，算得上是移动网维基本操作了。测: 2402:4f00:100::66d

临省移动，光猫线路模板没有绑下行限速（默认 1G ），同市账号能互用（可能全省都行）。上网速率控制是 RADIUS 认证回复报文添加扩展字节传带宽参数，BRAS 动态限速实现。相关产品文档 -> https://support.huawei.com/enterprise/en/doc/EDOC1100270076/9abf158/

@AlphaTauriHonda 封网期骨干业务调整 /割接理论是不批也不做的，11 月放开以后看看吧。不过介于北京出口已经验证了一套数据样板，上广到年底兴许会有戏。

浙江移动的所谓"精品宽带"理应是个能光明正大装到商业地址下的（动态公网）家宽才对，不然实际报价和对等 PON 专线相差这么多功能却一样，用户反而没理由去签约后者了。例：基于 OP 提供的目录价+抹零后实际报价，有提供双栈固定地址的情况下 500/250 精品宽带线路收费 2000 ，而 200/200 专线线路收费 7200 。。。

关于双栈公网，一朋友在同省邻市有报装移动对等 PON 专线（就一年 7200 的那个版本），竣工初期也只有 v4 单栈，和相关负责人沟通后确实额外取得了 v6 前缀：兴许这是两种业务有报价区别的原因之一？但价位也不应该相差这么多吧。。。不过介于设备标签显示业务是"PON 专线"，说不定是客户经理业务不熟工单下错了（血赚！）

标准 PPPoE 当然不会交互这些所谓“隐私”信息 -- 相较于 IP 地址、MTU 等参数，主机名或软件版本又不是链路 /网络层需要关注的信息，再加上 PPPoE 有 ID 区分会话，在控制报文写入上述无关紧要的内容已经是累赘了，要是保活报文里再添上岂不有点离谱。

当然要不要这部分可选字段纯看运营商喜好，毕竟它们可以通过此类参数来牵制客户选择第三方网关型号的能力（现在可能比较少见了。参考部分路由器自带的“特殊拨号模式”）。

今天 58807 往外宣告的路由多了不少，新增部分主要隶属先前一直没有出现的长三角、珠三角地区分公司。粗略做了一下追踪，实际路由仍绕北京，不过也许上广出口已经准备得差不多了。

几个测试 IP
183.194.134.1 上海 24400 （上海居然这么快就有吃 CMIN2 螃蟹的外企了: 思爱普 /SAP 中国，AS135577 ，157.133.197.235 ）
112.53.180.1 浙江 56041
36.158.32.1 湖南 56047
183.206.224.1 江苏 56046
120.236.114.1 广东 56040

@acbot 用三层交换机的内置功能算是现成方案，兴许 BRAS 上的类似功能厂商也是复用自己的交换产品线代码实现的，但“纯软件”实现也不是不可以：比如#21 和我都提到能自己扩展 DHCP 服务器（不管是改代码还是调用钩子,api,脚本）做到和 netfilter 之类的联动。无非就是没有现成的开包即用项目罢了 -- 目前来讲，花心思深入调试一下几个模块化的 DHCP 服务器，你想要的效果可以直接实现。

@acbot 假设我的说法和运营商、大厂的实际实现相匹配，那扩展一个开源 DHCP 服务器使其能够识别挑战应答 Option 并针对性处理、决定需不需要返回 DHCP Offer 就可以了。。当然你也可以选择不处理扩展字段无脑返回 DHCP Offer ，随便一种 DHCP 服务器都可以实现这个功能。

说到底目前部署 IPoE 地区认证全脱胎于 DHCP ，DHCP 是完全不需要交换机硬件或某种特定协议支持的（这里先不考虑 BRAS 的用户上线控制，后续讨论见下）。另外，上面多层回复均提出非标准 IPoE 认证方式没有统一、且 CTC 的那套挑战应答（大概）还没被逆向出来、加上考虑到 IPoE 尚未完全铺开（或许以后每个省采用的认证标准都要额外加点料称作创新呢），通用实现会比较难做。说到这我其实好奇你想自主实现接入认证后作何种用途。。。

若要实现类似于 BRAS 上的状态机来阻止转发未认证用户流量，纯自主实现就需要 DHCP 服务器和路由网关能够联动了。例：自己写或合理运用开源 DHCP 服务器（例如 ISC Kea ）的钩子接口，在 DHCP 发放地址同时执行外部代码放通用户接口的转发能力（默认阻塞）。若采用大厂设备（~三层交换机）则好办：它们一般提供诸如 IPSG 、DAI 、DHCP Snooping 等端口安全功能。关闭接口 ARP 学习能力后，设备内部 IP-MAC/ARP 对应表将完全通过监听 DHCP 报文维护，那不属于 DHCP 分配的地址（自配 IP ）的报文会直接被丢弃，体验上和先前提到的 BRAS 用户上线控制技术类似。

IPoE 既然是承载在以太网帧（~二层）上的 IP 报文（~三层），在当今标准以太接入大环境下只是个普通 IP 数据包。。。因此规范的认证方式只有基于 MAC/IP/VLAN 判断接入用户或 /和地点而已，也就是思科 /华为默认支持的认证方式。同时，两家的配置文档均有提到 “订户接口 Subscriber Interface” 这一概念：一种虚拟接口，用 VLAN 对应某客户的某一业务，且维护一个状态机（~会话）来指导报文转发。常见例子就是 PON 接入专线大抵采用基于 IP 认证的 IPoE：用户填入专线的静态地址，BRAS 分析用户设备与自身的交互报文（可以是 ARP ，ICMP 这类的） IP 头段是否为该用户订阅地址，只有符合才将会话上线使能报文转发（好比配置该订户接口防火墙策略在状态机 down 时为丢弃、online 时才为转发。不过这点是我猜的，但底层实现上应该类似）。需要避免用户随意盗用不属于自己的 IP 地址？当收到源 IP 不属于该订户的入向报文，直接将状态机置 down 中止后续报文转发。总的来说，标准 IPoE 只要在用户侧三层接口在填入合适的 IP/MAC/VLAN 参数后即可上网，从而印证常见路由固件并不需要额外模块来适配这一协议，因为它们早就支持了。

那么动态分配 IPv4 场景下 BRAS 要如何验证报文 IP 头部是否匹配，控制用户的会话状态机呢：问 DHCP 。不管是用 DHCP Snooping 这种安全技术，还是用特定的组网方式，运营商只要能确保 BRAS 自身或带外服务器间 DHCP 交互是可信的，就可以参照这些交互报文来控制客户状态机的上下线。比如，只有上游 DHCP 服务器返回 Offer 且客户端接受了，才让会话上线。后续则可以持续监控客户侧 IP 是否匹配 DHCP 下发的地址，遇不匹配就让客户状态机下线等。像电信的 CTC 协议就在 DHCP Option 字段做文章（/t/875362 ），设备需要与 DHCP 服务器互相挑战应答用户名密码（业务是否欠费等先决条件大概是在这里得到验证）才能获取到 DHCP Offer 回应。

至于 IPv6 单栈（/t/875742 ，/t/875467 ）场景，目前的方案看起来是 DHCPv6 绑定光猫上行口 MAC 下发固定前缀，且在订户接口上配置静态 v6 认证。

在 9808 内有路由优化之前延迟固然无法和 CN2 比较。58807 实现上就和 CN2 是完全不同两套方案，对于墙内用户前者所谓“精品”目前来看只是一条独立 C-I 段（测速的话应该比较好看），而后者则有完全重构骨干架构、减少不必要的转发层级或采用优质链路来减少时延。其实我倒好奇当下 58807 的专有国际带宽是不是都从 CMI 里面挤出来的，毕竟出口扩容一直是个老难题。。。另 58807 现有通告路由（来源 AS 大多属华北地区分公司）都经北京出口局入，可能因上、广出口尚未完成接入（审批？）

这个子网掩码似乎是标准以太互联 CIDR ，/30 空间减去广播地址减去网络地址实际只有 2 个 IP 可用，正好够同广播域内 1 台运营商侧网关设备和 1 台用户侧路由器互访，个人猜测移动交付了裸二层接入商宽，而不是基于 ppp 或类似魔改协议的某为 BAS 接口 /IPoE 实现。（参考 https://support.huawei.com/enterprise/zh/doc/EDOC1100125910/356527cf#ZH-CN_TASK_0172373974 ）

假设运营商网关安全策略不严格，用户侧上行目的地址为设备环回地址 /其他接口 IP 的报文兴许能被三层处理转发，但考虑到用户自带设备兼容性+运营商资产安全问题一般不会这么配参（正如楼主说的，普通路由器甚至不允许设置和主 IP 不同子网的网关地址）。因此我也感觉移动技术人员提供的网络数据有问题，兴许内部沟通出现了偏差？实际情况中装维获取的技术数据能倒好几次手，部分关键信息可能会和传话游戏一样丢失 /被改...

综上，楼主不妨试试将 211.136.X.(X-1)或 211.136.X.(X+1)作为网关地址验证能否上网。