No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

NE40E V800R010C00 Feature Description - NAT and IPv6 Transition 01

Rate and give feedback :
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
Common CGN deployment scenarios

Common CGN deployment scenarios

Figure 2-8  Common CGN deployment scenarios
  • CGN can be classified as standalone CGN or integrated CGN in terms of device patterns. For details, see Figure 2-8.
    • Standalone CGN refers to the use of a separate device to take over CGN functions.

      Standalone CGN has its own space in a chassis and requires cables to connect to a BRAS or CR. In addition, two extra interfaces need to be configured for the CGN device and CR/BRAS each, so that private IPv4 traffic can be diverted to the CGN device and public IPv4 traffic can be sent back to the CR/BRAS after NAT is implemented. A standalone CGN device requires a specific unit for network management. Considering that address translation and user management are performed on the CGN device and BRAS respectively, user tracing becomes difficult.

    • Integrated CGN indicates the insertion of a CGN board into a device, such as BRAS, SR, or CR.

      Integrated CGN uses only one device slot, with no need for extra chassis space, forwarding interface, or cable layout. Integrated CGN has a big advantage in scalability and does not require a specific unit for network management.

    In comparison, standalone CGN has no impact on services on the BRAS but requires an independent BRAS interface to divert traffic, whereas integrated CGN features a combination of CGN and BRAS and provides better user management. For details, see Table 2-4.

    Table 2-4  Comparison between standalone CGN and integrated CGN

    Deployment method

    Standalone CGN Integrated CGN

    Deployment characteristics

    • Excellent performance, multi-core CPU processing

    • Excellent capacity and scalability, support for expansion in multi-chassis or cascading mode

    • Flexibility in device placement

    • Occupancy of BRAS interfaces to divert traffic to the standalone CGN device

    • Small occupancy, low requirements on power dissipation, low investment

    • Interworking between the network layer and application layer, support for multiple routing protocols, integrated access, and CGN management

    • Excellent scalability, support for online deployment

    • Using a BRAS service slot

  • CGN can be classified as centralized CGN and distributed CGN in terms of deployment positions. For details, see Figure 2-8.

    • For centralized CGN, a standalone CGN device or a CGN board can be deployed at the CR position, such as where a P router is located on the metro or backbone network.
    • For distributed CGN, a standalone CGN device or a CGN board can be deployed at the BRAS or SR position.

    Table 2-5 outlines a comparison between centralized CGN (taking a standalone CGN device connected to a CR as an example) and distributed CGN (taking a CGN board inserted into a BRAS as an example).

    Table 2-5  Comparison between centralized CGN and distributed CGN
    Item Centralized CGN Distributed CGN
    Deployment position A standalone CGN device is deployed on the metro network egress to connect to a CR. A CGN board is inserted into a BRAS.
    Deployment complexity An independent CGN device is required. The other things new items are two extra 10GE interfaces on the CGN device and CR each, cable layout, and a traffic diversion policy. In case of CGN expansion or policy adjustment, network-wide routes need to be readjusted, and a designated log server is required. No new device is required. All you need to do is insert a CGN board into a BRAS. CGN deployment or expansion does not require adjustment of metro network routes, and no log server needs to be deployed.
    Impact Private network routes need to be advertised on the metro network. Private IP address and metro network routes need to be replanned. Centralized CGN expansion requires readjustment of metro network routes, which is complex in networking. In addition, centralized CGN supports only offline tracing. The metro network architecture is unchanged as private network routes are not advertised on the metro network. The BRAS can report a NAT mapping table to the AAA server by means of RADIUS and supports online tracing.
    Service traffic Service traffic within a single city is transferred to CRs and CGN devices for processing. This causes the traffic volume on CRs to increase. CGN easily becomes a performance bottleneck. The metro network structure is unchanged, and therefore the traffic model remains. The forwarding efficiency is high and performance requirements are low.
    Reliability CGN devices are maintaining a great number of sessions, requiring high reliability. A CGN device failure may affect a large number of users and is prone to vulnerabilities. The centralized networking will evolve to the distributed networking along with the ever-increasing number of metro network users. CGN devices are maintaining a few sessions, and therefore a CGN device failure affects a small number of users. The distributed networking minimizes the risk of attacks on CGN subcards.
    Network security Centralized CGN triggers management of NAT flow tables upon receipt of packets. After a user goes offline, the NAT flow table ages out for a Before the NAT flow table completely ages out, the host corresponding to the offline user exists on the private network and The BRAS gets aware of user online and offline. The user NAT flow table will be immediately deleted upon user offline.
    Network management An agent needs to be deployed on the CGN device, and a CGN NE needs to be added to the NMS workstation. The NMS needs to be redeployed, regardless of in-band or out-of-band management. For out-of-band NMS, cable layout is also required. The existing NMS can be reused.
    Costs The new items include chassis space, two forwarding interfaces (LPUs may also be required) on the CGN and CR each, cable layout, and log server. In the event of capacity expansion, network reconstruction is also required. The deployment and maintenance are complex. Inserting a CGN board on a BRAS does not require extra hardware deployment or reconstruction. The deployment and maintenance are simple.

Simply put, the distributed CGN solution outperforms the centralized CGN solution in terms of network impact, traffic model, reliability, and network management and therefore is recommended. When a CGN board is installed on a BRAS, the network architecture and traffic model remain unchanged, which makes it easy to perform private network route planning, MAN route management, user policy control, and source tracing. However, centralized CGN can be a choice for areas with a few number of users.

Download
Updated: 2018-07-04

Document ID: EDOC1100027155

Views: 21909

Downloads: 71

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next