sendmailtest123

sendmailtest123

V2EX 第 260075 号会员,加入于 2017-10-16 20:31:09 +08:00
今日活跃度排名 1243
根据 sendmailtest123 的设置,主题列表被隐藏
二手交易 相关的信息,包括已关闭的交易,不会被隐藏
sendmailtest123 最近回复了
浙江移动的所谓"精品宽带"理应是个能光明正大装到商业地址下的(动态公网)家宽才对,不然实际报价和对等 PON 专线相差这么多功能却一样,用户反而没理由去签约后者了。例:基于 OP 提供的目录价+抹零后实际报价,有提供双栈固定地址的情况下 500/250 精品宽带线路收费 2000 ,而 200/200 专线线路收费 7200 。。。

关于双栈公网,一朋友在同省邻市有报装移动对等 PON 专线(就一年 7200 的那个版本),竣工初期也只有 v4 单栈,和相关负责人沟通后确实额外取得了 v6 前缀:兴许这是两种业务有报价区别的原因之一?但价位也不应该相差这么多吧。。。不过介于设备标签显示业务是"PON 专线",说不定是客户经理业务不熟工单下错了(血赚!)
14 天前
回复了 acbot 创建的主题 宽带症候群 BRAS 能获取到哪些下游信息
标准 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
19 天前
回复了 acbot 创建的主题 宽带症候群 IPoE 认证开源自建方案
@acbot 用三层交换机的内置功能算是现成方案,兴许 BRAS 上的类似功能厂商也是复用自己的交换产品线代码实现的,但“纯软件”实现也不是不可以:比如#21 和我都提到能自己扩展 DHCP 服务器(不管是改代码还是调用钩子,api,脚本)做到和 netfilter 之类的联动。无非就是没有现成的开包即用项目罢了 -- 目前来讲,花心思深入调试一下几个模块化的 DHCP 服务器,你想要的效果可以直接实现。
20 天前
回复了 acbot 创建的主题 宽带症候群 IPoE 认证开源自建方案
@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 用户上线控制技术类似。
20 天前
回复了 acbot 创建的主题 宽带症候群 IPoE 认证开源自建方案
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)作为网关地址验证能否上网。
123 天前
回复了 leonunix 创建的主题 宽带症候群 披露一下新加坡机房 CN2 接入的费用
第一行似乎写着服务类型是 Global Transit (GT) ?区分两种服务肯定不能从是否存在 BGP Peering 判断,GIA 应该要再贵不少吧。
@ggf 感谢告知~ 我顺便去问问存量业务续费能不能按这个新价格
关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   1156 人在线   最高记录 5497   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 16ms · UTC 23:38 · PVG 07:38 · LAX 16:38 · JFK 19:38
Developed with CodeLauncher
♥ Do have faith in what you're doing.