城域网NAT444运维管理研究

邱杨 傅岱松

【摘要】 介绍城域网部署了NAT444之后，城域网针对NAT444用户运维管理方案。

【关键字】 城域网 NAT444 CGN 运维管理

一、引言

全球公网IPV4 地址已经在2011年分配殆尽，这几年来我国几大运营商已经没有可用的公网IPV4地址分配，当前我国运营商解决IPV4地址不足的问题，主要通过NAT444、IPV6双栈、DS-LITE等方法解决。

由于目前我国绝大部分互联网应用仍然以IPV4为主，所以IPV6双栈以及DS-LITE解决方法从解决IPV4地址不足问题，因此NAT444成为各大运营商解决当前IPV4地址不足问题的首选办法。

NAT444部署之后，用户的上网流量走向以及流程进行了一定的变化，对城域网的运维产生了新的要求。本文主要探讨NAT444部署之后，城域网相关运维管理方法，主要从NAT444用户溯源、NAT端口块大小临时调整、私网用户转为公网用户等几个方面进行研究。

二、用户溯源

NAT444业务部署之后，用户访问internet，在internet上访问记录中留下的为NAT转换后的公网IP地址信息，并非用户的内部私网IP地址信息，为了有效的跟踪用户信息，需要建设一套溯源系统。溯源系统需要从AAA搜集某个时刻用户的帐号和分配的分配的私网IP地址信息，并从CGN设备上报的log上获得这个时刻公网地址和私网地址的映射关系，结合以上2个步骤的信息，综合判断出这个时刻公网上某个IP+端口当前为哪个帐户在使用。

NAT444业务溯源方案有以下四种。

方案一：采用由CGN设备在建立端口映射关系后，发送syslog日志信息的方式，将端口/端口段映射关系发送到日志服务器，AAA系统在接收溯源请求后，通过syslog服务器查询到动态地址映射关系，从而完成地址溯源；

方案二：CGN设备通过Radius报文方式将用户的动态端口映射关系上报到AAA系统，由AAA系统记录到用户在线信息表和原始话单中，当AAA系统接收到溯源请求后，直接查询在线用户信息表或原始话单，返回溯源结果；

方案三：CGN设备采用Radius报文方式将用户动态端口映射关系上报到Log服务器，AAA系统在接收溯源请求后，通过syslog服务器查询动态地址映射关系，完成地址溯源；

方案四：AAA与CGN通过网管系统下发参数，并执行相同的端口映射生成算法。在地址溯源过程中，CGN与AAA系统之间不需要传递映射关系，直接实现对地址的溯源。

在以上四种方案中，方案一和方案三需要新建溯源日志服务器。

三、端口块大小临时调整

当用户分配的公网端口耗尽时，如果用户还有应用流量需要访问internet，则CGN会将这些流量Drop，用户应用不能使用，这时候部分用户可能会投诉，为了解决这一问题，通过以下方法临时增大其公网端口块的长度。

对于插卡式CGN设备，临时调整公网端口块的大小有两种方式：

BRAS上的NAT配置和domain相关联，可以在BRAS上直接修改NAT配置模板中用户端口块大小，不过这种方法会影响整个domain下所有用户的端口块大小。

通过AAA下发RADIUS扩展属性调整端口块的大小，RADIUS扩展属性中有一项可以下发用户的端口块大小。

四、私网用户调整为公网

NAT444业务模型中，CGN设备作为ALG网关，目前大部分应用应用比如HTTP、FTP、BT都可以顺利穿透ALG网关，但是并非所有的业务都可以顺利通过CGN ALG网关。当用户有某个应用不能使用时候，可能会进行投诉，在这种情况下需要临时将用户调整为公网用户。

BRAS调整方法为：

如果用户是通过PPPOE拨号，可以在AAA上停止在RADIUS报文中下发用户的私网域信息，使BRAS按照原来用户拨号的公网域进行公网地址下发。对于DHCP获取IP的WIFI用户，只能引导其使用PPPOE拨号，通过AAA上停止在RADIUS报文中下发用户的私网域信息方式调整。

五、结束语

NAT444的部署增加了城域网故障排障难度，必须要有一套合理的运维管理方案，才可以保障NAT444用户的平稳运行，以及在出现故障和投诉之后迅速解决问题。

参 考 文 献

[1] RFC 7289文档，Carrier-Grade NAT （CGN） Deployment

with BGP/MPLS IP VPNs，http：//www.ietf.org/rfc/rfc7289

[2]RFC7422文档，Deterministic Address Mapping to Reduce Logging in Carrier-Grade NAT Deployments， http：//www.ietf.org/ rfc/rfc7422

[3]中国电信，NAT444独立设备技术规范 2011