• 文章搜索:
  • 目录

        • 分享到...

        • 新浪微博
        • 腾讯微博
        • 推荐到豆瓣 豆瓣空间
        • 分享到搜狐微博 搜狐微博
        • 分享到QQ空间 QQ空间
        • 分享到腾讯朋友 腾讯朋友
        • 网易微博分享 网易微博
        • 添加到百度搜藏 百度搜藏
        • 转贴到开心网 开心网
        • 转发好友 告诉聊友
    • 推荐
    • 打印
    • 收藏

    NAT转发一些细节的汇总

    作者:  |  上传时间:2012-06-01  |  关键字:网络大爬虫5-NAT专题

    NAT的基本原理并不复杂,但是在落实到具体的软件实现中,还是有很多的细节值得玩味的。

    NAT的基本原理并不复杂,只是在网关设备上维护私网地址(端口)到公网地址(端口)的映射关系,通过修改流经网关的IP报文头部实现地址转换。由于NATIP转发流程中的一个环节,具体的实现势必和软硬件密切相关。为了尽可能提高设备转发和报文处理的性能,软件数据结构和处理流程会应根据设备硬件的特点进行设计。本节我们就把讨论焦点放在ComwareV5平台单核CPU与多核CPUNAT实现细节上,同时介绍交换机产品支持NAT的方法。

    1      单核还是多核?

    由于NAT的业务处理包括对于网络层、传输层甚至应用层的处理,普通的ASIC和交换芯片很难实现,因此一般的NAT实现都是通过CPUNP来完成的。目前主流的实现方案包括单核CPU、多核CPUNP三种。以下以Comware v5平台为例,分别介绍在单核CPU硬件平台和多核CPU硬件平台上NAT实现方式的异同点。

    1.1      单核CPU硬件平台

    单核CPU一般用于中低端设备。对于Comware v5平台,NAT的业务处理使用专门的NAT会话来实现,同时针对NAT ServerASPFALG等进行一系列特殊处理。

    1.1.1 普通NAT处理

    当不涉及ALG等特殊场景时,单核CPU方式的NAT使用NAT会话表来记录会话信息,下面是在PATEasy IP方式下,一个从18.1.0.1发起,目的地为18.2.0.1HTTP连接建立的NAT会话:

    Protocol      GlobalAddr  Port      InsideAddr  Port        DestAddr  Port

         TCP    18.2.255.254 12288        18.1.0.1  1912        18.2.0.1    80

         status:111     TTL:00:00:10   Left:00:00:06   VPN:---

    同样一个连接,如果使用No-PAT方式的NAT,会话信息如下:

    Protocol      GlobalAddr  Port      InsideAddr  Port        DestAddr  Port

           -        18.2.1.1   ---        18.1.0.1   ---             ---   ---

         status:NOPAT   TTL:00:04:00   Left:00:04:00   VPN:---

     

         TCP        18.2.1.1  1934        18.1.0.1  1934        18.2.0.1    80

         status:NOPAT   TTL:00:00:10   Left:00:00:04   VPN:---

    No-PAT方式下的会话其实是由一个主会话和多个子会话组成的。在该方式下,NAT模块依旧要根据子会话对端口进行判断,确定返回的报文的端口和发出的报文匹配,才进行NAT转换,防止满足第一条SESSION条件的报文(仅需要二元组匹配)从外网轻松穿越NAT。这样在NO PAT的转换方式下,同样保证了只能由内网主动发起连接,提供了更可靠的安全性。

    1.1.2 ALG的处理

    多数协议在经过NAT网关时只需要使用普通的NAT转换处理,但是对于一些特殊协议如FTPRTSPSIP等,由于这些协议在应用层中携带了IP地址或端口等信息,因此需要ALG的帮助才能正常穿越NAT网关。

    FTP协议为例,PORT模式的FTP在经过NAT时需要ALG的处理,因此NAT网关需要关注用户的每一个FTP命令,并识别需要进行ALG处理的命令,进行相应的ALG处理:

    *May 28 10:54:30:820 2011 MSR50 NAT/7/debug:

      Ftp Packet To Svr (Vlan-interface102-out :) Find a Ftp PORT CMD

    *May 28 10:54:30:821 2011 MSR50 NAT/7/debug:

      Ftp Packet To Svr (Vlan-interface102-out :) Process the PORT command 18.1.0.1:1976

    以上内容是通过打开设备调试开关跟踪到的信息。由此可以看出,NAT网关识别了FTP PORT命令,并进行了ALG的处理,那么究竟进行了哪些ALG的处理呢?

    当数据通道连接建立完毕后,NAT的会话表如下:

    Protocol      GlobalAddr  Port      InsideAddr  Port        DestAddr  Port

           -        18.2.1.1   ---        18.1.0.1   ---             ---   ---

         status:NOPAT   TTL:00:04:00   Left:00:04:00   VPN:---

     

         TCP        18.2.1.1  1998        18.1.0.1  1998        18.2.0.1    21

         status:NOPAT   TTL:00:05:00   Left:00:04:57   VPN:---

     

         TCP        18.2.1.1  2002        18.1.0.1  2002        18.2.0.1    20

         status:NOPAT   TTL:00:05:00   Left:00:04:57   VPN:---

     

         TCP        18.2.1.1  2002        18.1.0.1  2002             ---   ---

         status:NOPAT   TTL:---        Left:---        VPN:---

    此处关注最后一个标红的会话,其目的地址和目的端口都为空,表示任何一个外网的IP地址都可以使用任意源端口来连接这个2002端口。这个会话正是为了适应FTP的“第三方连接”特性而设计的,是NAT ALG工作的结果。

    从上面内容可以看出,对于单核CPUNATALG工作的效果是直接体现在NAT会话中的。

    1.1.3 ASPF的共存

    ASPFApplication Specific Packet Filter)是一种基于应用层状态的包过滤方法。ASPF能够检查应用层协议信息,如报文的协议类型和端口号等信息,并且监控基于连接的应用层协议状态。每一个连接状态信息都将被ASPF维护,并用于动态地决定数据包是否被允许通过防火墙进入内部网络,以阻止恶意的入侵。 同时,ASPF能够检测传输层协议信息(即TCP/UDP检测),根据源、目的IP地址及端口号决定TCPUDP报文是否可以通过防火墙进入内部网络。

    对于单核产品,当在设备上配置了应用层协议检测后,ASPF可以检测每一个应用层的会话,并创建一个状态表项和一个临时访问控制列表(Temporary Access Control ListTACL),对于多通道协议,后续还会创建数据通道的TACL

    (1)状态表项在ASPF检测到第一个向外发送的报文时创建,用于维护一次会话中某一时刻会话所处的状态,并检测会话状态的转换是否正确。

    (2)临时访问控制列表的表项在创建状态表项的同时创建,会话结束后删除,它相当于一个扩展ACLPermit项。TACL主要用于匹配一个会话中的所有返回的报文,为某一应用返回的报文在防火墙的外部接口上建立一个临时的返回通道。

    ASPF一般用于阻止外网发起到内网的连接,对于普通的内网访问外网的NAT并没有影响,但是对于PORT模式的FTP,由于数据连接是从外部服务器发起的,因此还是存在影响的。

                                                                                                             图1 NAT/ASPF并存

    如上图,NATASPF并存,当使用PORT模式的FTP时,ASPF实际上进行了特殊处理,放过了入方向的数据连接:

    *May 28 11:29:10:620 2011 MSR50 ASPF/7/FTP:  Session 0xB36CE80 - state = 33, token = 32, string 'PORT', value 3

    *May 28 11:29:10:620 2011 MSR50 ASPF/7/FTP:  Session 0xB36CE80 - state = 33, token = 44, string '8', value 8

    *May 28 11:29:10:620 2011 MSR50 ASPF/7/FTP:  Session 0xB36CE80 - state = 33, token = 13, string '77', value 77

    //捕获了PORT命令和命令中的端口

    *May 28 11:29:10:620 2011 MSR50 ASPF/7/EVENT:  Source address :18.2.0.1 port number:(1:65535) destination address :18.1.0.1 port number:(2125:2125)

    *May 28 11:29:10:621 2011 MSR50 ASPF/7/OBJ_CREATE:  Create session entry 0xB36BA40 address 18.2.0.1 bucket 2131

    //为服务器的地址建立ASPF会话

    *May 28 11:29:10:621 2011 MSR50 ASPF/7/OBJ_CREATE:  Create the temporary ACL entry 0x7D67D00 originator 18.2.0.1(1:65535) destination 18.1.0.1(2125:2125) bucket 2131

    //为入方向数据连接建立TACL

    *May 28 11:29:10:621 2011 MSR50 ASPF/7/FTP:  Session 0xB36CE80 - state = 34, token = 32, string '200', value 3

    *May 28 11:29:10:621 2011 MSR50 ASPF/7/FTP:  Session 0xB36BA40 - process the PORT command 18.2.0.1:0

    *May 28 11:29:10:623 2011 MSR50 ASPF/7/FTP:  Session 0xB36CE80 - state = 33, token = 32, string 'LIST', value 255

    *May 28 11:29:10:773 2011 MSR50 ASPF/7/FTP:  Session 0xB36CE80 - state = 33, token = 32, string '150', value 254

    *May 28 11:29:10:873 2011 MSR50 ASPF/7/EVENT:  Source address :18.2.0.1 port number:(20:20) destination address :18.1.0.1 port number:(2125:2125)

    *May 28 11:29:10:973 2011 MSR50 ASPF/7/OBJ_CREATE:  Create the temporary ACL entry 0xB5CEAA0 originator 18.1.0.1(2125:2125) destination 18.2.0.1(20:20) bucket 2149

    //为出方向数据连接建立TACL

    *May 28 11:29:11:123 2011 MSR50 ASPF/7/OBJ_DELETE:  Delete the temporary ACL entry 0xB5CEAA0 originator 18.1.0.1(2125:2125) destination 18.2.0.1(20:20) bucket 2149

    *May 28 11:29:11:274 2011 MSR50 ASPF/7/OBJ_DELETE:  Delete session entry 0xB36BA40 address 18.2.0.1 bucket 2151

    //删除入方向TACL和会话

    *May 28 11:29:11:424 2011 MSR50 ASPF/7/OBJ_DELETE:  Delete the temporary ACL entry 0x7D67D00 originator 18.2.0.1(20:20) destination 18.1.0.1(2125:2125) bucket 2151

    //删除出方向TACL

     

    1.1.4 NAT Server

    NAT Server实际上是反方向的NAT,需要用户进行静态配置。需要注意的是,对于单核CPU设备,经过NAT Server的流量不会再另外创建NAT会话。

    对于NAT Server来说,如果和ASPF共存,需要在ASPF的入方向包过滤引用的ACL中将NAT Server对应的IP/端口放开,如下图:

                                                                                                                图2 NAT ServerASPF

    在接口的入方向,ASPF是先于NAT对报文进行处理的,因此ASPF的入方向包过滤引用的ACL应进行如下的配置,NAT Server才能正常工作:[d1] 

    #

    acl number 3001

     rule 0 permit icmp

     rule 1 permit tcp destination 18.1.0.1 0 destination-port eq ftp

     rule 5 deny ip

    #

     

    同样,NAT Server对于特殊的应用层协议也需要ALG的支持,对于Passive模式的FTP客户端,在访问NAT Server时需要ALG处理:

    *May 28 12:19:06:505 2011 MSR50 NAT/7/debug:

      Ftp Packet To Client (Vlan-interface102-out :)Find a Ftp Entering PASV CMD

    *May 28 12:19:06:605 2011 MSR50 NAT/7/debug:

      Ftp Packet To Client (Vlan-interface102-out :) Process the PASV command 18.1.0.1:2330

    回过头来看NAT会话:

    Protocol      GlobalAddr  Port      InsideAddr  Port        DestAddr  Port

         TCP    18.2.255.254  2343        18.1.0.1  2343        18.2.0.1  3590

         status:241     TTL:00:05:00   Left:00:03:48   VPN:---

     

         TCP    18.2.255.254  2343        18.1.0.1  2343             ---   ---

         status:8241    TTL:---        Left:---        VPN:---

    同样,最下面一条会话也是为了支持FTP的“第三方连接”功能。

     

    那么,当NAT Server/ASPF/ALG共存,会出现哪些问题呢?

    如图2,当接口配置如下时,Passive模式的FTP客户端,数据连接建立失败:

    #

    interface Vlan-interface102

     ip address 18.2.255.254 255.255.0.0

     nat outbound 2000

     nat server 1 protocol tcp global current-interface ftp inside 18.1.0.1 ftp

     firewall packet-filter 3001 inbound

     firewall aspf 1 outbound

    #

    FTP数据连接是从客户端发起的TCP连接,因此被入方向的packet filter过滤掉了,只要在ACL3001中增加对应的配置即可。但是对于Passive模式的FTP数据连接来说,源端口和目的端口都不是固定的,无法进行ACL的配置。

    解决问题的方法是另外配置一条入方向的ASPF

    #

    interface Vlan-interface102

     ip address 18.2.255.254 255.255.0.0

     nat outbound 2000

     nat server 1 protocol tcp global current-interface[d2]  ftp inside 18.1.0.1 ftp

     firewall packet-filter 3001 inbound

     firewall aspf 1 inbound

     firewall aspf 1 outbound

    #

    入方向的ASPFFTP协议进行了检测,并放行了数据连接:

    *May 28 12:40:05:171 2011 MSR50 ASPF/7/FTP:  Session 0xB346CC0 - state = 33, token = 32, string 'PASV', value 4

    //检测到PASV命令

    *May 28 12:40:05:321 2011 MSR50 ASPF/7/FTP:  Session 0xB346CC0 - state = 35, token = 32, string '227', value 4

    *May 28 12:40:05:422 2011 MSR50 ASPF/7/FTP:  Session 0xB346CC0 - state = 35, token = 44, string '9', value 9

    *May 28 12:40:05:522 2011 MSR50 ASPF/7/FTP:  Session 0xB346CC0 - state = 35, token = 41, string '115', value 115

    *May 28 12:40:05:672 2011 MSR50 ASPF/7/EVENT:  Source address :18.2.0.1 port number:(1:65535) destination address :18.1.0.1 port number:(2419:2419)

    *May 28 12:40:05:772 2011 MSR50 ASPF/7/OBJ_CREATE:  Create session entry 0xB346A80 address 18.2.0.1 bucket 2425

    *May 28 12:40:05:922 2011 MSR50 ASPF/7/FTP:  Session 0xB346A80 - process the reply to the PASV command 18.1.0.1:2419

    //开始处理对PASV命令的应答消息

    *May 28 12:40:06:022 2011 MSR50 ASPF/7/OBJ_CREATE:  Create the temporary ACL entry 0x9226360 originator 18.2.0.1(1:65535) destination 18.1.0.1(2419:2419) bucket 2425

    //针对数据连接的端口创建入方向TACL

    *May 28 12:40:06:122 2011 MSR50 ASPF/7/EVENT:  Source address :18.2.0.1 port number:(3621:3621) destination address :18.1.0.1 port number:(2419:2419)

    *May 28 12:40:06:273 2011 MSR50 ASPF/7/OBJ_CREATE:  Create the temporary ACL entry 0x9226420 originator 18.1.0.1(2419:2419) destination 18.2.0.1(3621:3621) bucket 6044

    //针对数据连接的端口创建出方向TACL

    *May 28 12:40:06:373 2011 MSR50 ASPF/7/FTP:  Session 0xB346CC0 - state = 33, token = 32, string 'LIST', value 255

    *May 28 12:40:06:473 2011 MSR50 ASPF/7/FTP:  Session 0xB346CC0 - state = 33, token = 32, string '125', value 254

    *May 28 12:40:06:623 2011 MSR50 ASPF/7/FTP:  Session 0xB346CC0 - state = 33, token = 32, string '226', value 254

    *May 28 12:40:09:531 2011 MSR50 ASPF/7/OBJ_DELETE:  Delete the temporary ACL entry 0x9226420 originator 18.1.0.1(2419:2419) destination 18.2.0.1(3621:3621) bucket 6044

    //传输结束后删除出方向TACL

    *May 28 12:40:09:531 2011 MSR50 ASPF/7/OBJ_DELETE:  Delete session entry 0xB346A80 address 18.2.0.1 bucket 6046

    *May 28 12:40:09:531 2011 MSR50 ASPF/7/OBJ_DELETE:  Delete the temporary ACL entry 0x9226360 originator 18.2.0.1(3621:3621) destination 18.1.0.1(2419:2419) bucket 6046

    //传输结束后删除入方向TACL

    1.1.5 静态NAT

    单核CPU设备支持一对一和网段对网段的静态NAT,被静态NAT绑定的内网地址可以通过对应的外网地址从外网直接进行访问,对于ALG的需求和普通的NAT Outbound以及NAT Server并没有区别。

    静态NAT处理的流量要创建NAT会话,会话有些类似No-PATNAT

    Protocol      GlobalAddr  Port      InsideAddr  Port        DestAddr  Port

           -        18.2.1.1     0        18.1.0.1     0             ---   ---

         status:800     TTL:00:05:00   Left:00:04:57   VPN:---

     

         TCP        18.2.1.1  3477        18.1.0.1  3477        18.2.0.1    21

         status:60008   TTL:00:05:00   Left:00:04:58   VPN:---

    需要注意的是,静态NAT由于能够保证地址一一对应,因此不再做端口的转换。

    1.2      多核CPU硬件平台

    多核CPU被视为一种有效提升软转发性能的手段,使用范围越来越广。Comware v5NAT功能针对多核硬件平台的实现和针对单核硬件平台的实现有很大的不同。

    1.2.1 会话管理

    Comware v5平台中,会话管理是多核CPU设备所特有的功能。会话管理是为了实现NATASPF、攻击检测及防范等基于会话进行处理的业务而抽象出来的公共模块。会话管理把传输层报文之间的交互关系抽象为会话,并根据发起方或响应方的报文信息对会话进行状态更新和超时老化。

    会话管理支持多个特性分别对同一个报文进行处理,实现的主要功能包括:

    Ø  报文到会话的快速匹配;

    Ø  传输层协议状态的管理;

    Ø  报文应用层协议类型的识别;

    Ø  支持会话按照协议状态或应用层协议类型进行老化;

    Ø  支持指定会话维持永久连接;

    Ø  会话的传输层协议报文校验和检查;

    Ø  为需要进行端口协商的应用层协议提供特殊的报文匹配;

    Ø  支持对ICMP差错控制报文的解析以及根据解析结果进行会话的匹配。

    对于NAT来说,在多核CPU设备上没有独享的会话表,而是和ASPF等协议使用共同的会话表。这种实现大大简化了多种应用在一个接口上并存情况下的互操作。

    NAT处理的普通流量创建的会话表如下:

    Initiator:

      Source IP/Port : 18.1.0.1/2545

      Dest IP/Port   : 18.2.0.1/80

      VPN-Instance/VLAN ID/VLL ID:

    Responder:

      Source IP/Port : 18.2.0.1/80

      Dest IP/Port   : 18.2.255.254/1026

      VPN-Instance/VLAN ID/VLL ID:

    Pro: TCP(6)     App: HTTP              State: TCP-EST

    Start time: 2011-05-28 13:07:25  TTL: 3587s

    Received packet(s)(Init): 27 packet(s) 1465 byte(s)

    Received packet(s)(Reply): 36 packet(s) 48751 byte(s)

    上表中已经明确列出了流量的发起方(Initiator)的源和目的地址和响应方(Responder)的源和目的地址,因为经过了NAT的处理,所以二者并不完全对称。会话表比单核CPU设备的NAT会话表包含更多的信息,也更为直观。

    1.2.2 ALG的处理

    提到多核CPU设备的ALG,不得不谈的就是关联表。

    对于单核CPU设备来讲,ALG处理无法共享代码,同样一个FTP ALGNAT需要对其进行特殊处理,ASPF也要对其进行特殊处理,大家各自维护一套代码,效率低下且不利于维护管理。

    正如会话表统领了NAT会话表、ASPF会话表等表项一样,关联表被用来处理一切和ALG有关的问题。

    和“单核CPU硬件处理平台ALG的处理”一节同样的场景,NAT网关为多核CPU设备,当ALG检测到客户端的PORT命令时,会创建关联表:

    *May 28 13:18:38:400 2011 SR66 ALG/7/ALG_DBG: -Slot=2; Alg debug info:

    Receive a FTP PORT CMD packet.

    *May 28 13:18:38:400 2011 SR66 ALG/7/ALG_DBG: -Slot=2; Alg debug info:

    From VPN :      0,Pro : TCP

    Direction : OUT

    (       18.1.0.1:   2616 ) ----> (   18.2.255.254:   1039 )

     

    *May 28 13:18:38:454 2011 SR66 SESSION/7/RELATION: -Slot=2;

     LocalTuple3: 18.1.0.1/2616 : GlobalTuple3:18.2.255.254/1039 (TCP)

     Create  module call

    关联表信息如下:

    Local IP/Port                Global IP/Port           MatchMode

    18.1.0.1/2616                18.2.255.254/1039        Global

     App: FTP-data         Pro: TCP   TTL: 300s   AllowConn 1

    关联表中各字段的含义如下:

    字段

    描述

    Local IP/Port

    内网IP地址/端口号

    Global IP/Port

    外网IP地址/端口号

    MatchMode

    会话表向关联表匹配模式,包括:LocalGlobalEither

    l      Local表示新建会话的源IP/源端口与关联表的Local IP/Port匹配

    l      Global表示新建会话的目的IP/目的端口与关联表的Global IP/Port匹配

    l      Either表示新建会话的信息与关联表的Local IP/PortGlobal IP/Port匹配

    App

    应用层协议类型,包括:FTPMSNQQ

    Pro

    传输层协议类型,包括:TCPUDP

    TTL

    关联表的剩余存活时间,单位为秒

    AllowConn

    关联表允许创建的会话数

                                                                                                           表1 关联表中各字段的含义说明

    上面的关联表被用来匹配服务器发起的FTP数据连接,对于FTP协议来说,一个PORT命令只能对应一个数据连接,因此关联表中“AllowConn”字段的值为1,当数据连接建立成功后,关联表的连接数满,被删除:

    *May 28 13:18:38:464 2011 SR66 SESSION/7/RELATION: -Slot=2;

     LocalTuple3: 18.1.0.1/2616 : GlobalTuple3:18.2.255.254/1039 (TCP)

     Delete  child full

    *May 28 13:18:38:464 2011 SR66 SESSION/7/RELATION: -Slot=2;

     LocalTuple3: 18.1.0.1/2616 : GlobalTuple3:18.2.255.254/1039 (TCP)

     Delete  module call / child full

    总之,对于多核CPUNATALG主要通过关联表进行工作。

    1.2.3 ASPF的共存

    多核CPU设备的ASPF和单核CPU设备不同,不存在TACL的概念。ASPF的应用层协议检测功能由会话管理及ALG功能协作实现。ASPF将检测到的应用层会话的首报文与配置的策略进行匹配,匹配的结果交由会话管理用来建立会话信息数据库以及维护会话状态。之后,ASPF根据会话管理返回的会话状态信息决定后续报文的处理方式。

    因此,一般来说多核CPU设备的NATASPF之间是比较松散的耦合关系,二者通过会话管理联系。

    1.2.4 NAT Server

    对于多核CPU设备,经过NAT Server的流量还是会创建会话,这一点与单核CPU处理不同。NAT Server对于特殊的应用层协议也需要ALG的支持,对于Passive模式的FTP客户端,在访问NAT Server时需要ALG处理:

    *May 28 14:05:06:350 2011 SR66 ALG/7/ALG_DBG: -Slot=2; Alg debug info:         

    Receive a FTP PASV Response packet.                                            

    *May 28 14:05:06:350 2011 SR66 ALG/7/ALG_DBG: -Slot=2; Alg debug info:         

    From VPN :      0,Pro : TCP                                                    

    Direction : OUT                                                                

    (       18.1.0.1:   2793 ) ----> (   18.2.255.254:   2793 )                    

    1.2.5 静态NAT

    和单核CPU设备一样,多核CPU设备也支持一对一和网段对网段的静态NAT,被静态NAT绑定的内网地址可以通过对应的外网地址从外网直接进行访问,对于ALG的需求和普通的NAT Outbound以及NAT Server并没有区别。

    静态NAT处理的流量要创建会话表。

    1.3      单核架构和多核架构实现的区别

    从上面描述可见,单核架构的NAT实现和多核有很大的区别,主要表现在以下几个方面:

     

    会话表管理

    ALG处理

    NAT Server

    单核构架

    使用独立的NAT会话表

    处理结果在NAT会话中体现

    经过NAT Server流量不创建会话

    多核构架

    多个业务使用统一的会话表

    处理结果用关联表体现

    经过NAT Server流量创建会话

                                                                                                         表2 单核NAT和多核NAT的区别

    2      NAT插卡相关的转发实现

    对于中高端交换机产品来说,NAT功能需要专门的业务插卡来实现,如何将流量引入和引出插卡是转发流程的关键所在。

    2.1      二三层转发方式

    这种方式是将NAT插卡视为一台独立的设备,交换机只做二层转发,报文在入VLAN A被转发到插卡的三层接口A,经插卡内部的三层转发到达三层接口B进行NAT处理,处理完毕后转发到交换机的VLAN B,最终二层转发到外网,外网返回的报文走相反的流程,如下图:

     [d3] 

                                                                                                         图3 二三层转发方式引流

    这种引流方式的原理和配置都比较简单,一般用于交换机和SecBlade插卡配合的场景,但是缺点也很明显,引流难以控制,所有流量都上插卡可能导致插卡负担过重,成为性能瓶颈。

    2.2      重定向方式

    第二种引流的方式是通过重定向的方式将需要NAT处理的流量送上插卡进行处理,不需要NAT处理的流量由交换机直接转发。

                                                                                                             图4 重定向方式引流

    这种引流方式克服了方法一的缺点,重定向方式的引流可以有效的控制上NAT插卡的流量,达到优化网络性能的目的。但是这种引流方式在配置方面还是比较繁琐,需要在NAT插卡和交换机两方面分别进行NAT的配置和引流的配置,由于引流配置的固定性,难以实现多块NAT板的备份功能。

    2.3      OAA方式

    OAA方式的引流是NAT插卡通过ACFP协议获取交换机的端口信息,然后通过ACFP协议下发策略,将特定端口的特定流量引到插卡进行NAT处理,处理完毕送回交换机进行转发。

                                                                                                              图5 OAA方式引流

    OAA方式引流的配置简单,大部分配置都在插卡上完成,交换机只需使能ACFP协议,另外,多块NAT插卡还可以下发相同规则但优先级不同的ACFP策略,实现NAT插卡之间的备份。

    3      小结

    对于不同的硬件平台,转发方面的设计和实现必然会有所区别。针对单核CPU和多核CPU两种硬件构架,Comware v5平台设计了两种NAT实现,目的是为了更好的适配硬件平台,实现功能、性能和可维护性等方面的优化。

    丰富的业务插卡是H3C公司中高端交换机的亮点之一,而多样化的引流方式,尤其是OAA的引流方式增强了NAT插卡的灵活性。


     [d1]增加了ASPFNAT处理顺序的讲解

     [d2]该参数并没有问题,只是比i较老的版本不支持。

     [d3]已标明AB