sendmailtest123

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
浙江移动确实有概率能转公网，前提是对接到有权限人员（网运中心。集团网短号电话过去成功率高，如果和客户经理关系好可以试试）并给合适理由。

既然猫棒不支持多对一映射，为什么不直接把单个用户侧 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