Network Address Translation Command Reference

This command creates a text description which is stored in the configuration file to help identify the content of the entity.

The no form of the command removes the string from the configuration.

This command administratively disables the entity. When disabled, an entity does not change, reset, or remove any configuration settings or statistics. Many entities must be explicitly enabled using the no shutdown command.

The shutdown command administratively disables an entity. The operational state of the entity is disabled as well as the operational state of any entities contained within. Many objects must be shut down before they may be deleted.

This command configures an ISA NAT group.

This command configures the number of active ISAs in active-standby ISA redundancy model for NAT. The active ISAs are automatically selected by the system and any the remaining ISA beyond the number of active limit will automatically assume the standby role. An ISA in the standby mode is idle until the failure of an active ISA occurs. Standby ISA can accept traffic from exactly one failed active ISA. Multiple standby ISAs can be configured in the system to protect against multiple simultaneous failures.

Once the active ISA fails, the standby ISA will start forwarding traffic. NAT translations from the failed ISA will have to be re-initiated by the clients and consequently setup on the newly active ISA.

In order for this commands to take effect, the intra-chassis redundancy mode must be set to active-standby (config>isa>nat-group>redundancy active-stanby).

This command configures the maximum number of supported simultaneously failures

in active-active intra-chassis NAT redundancy model. Traffic from the failed ISAs is distributed over the remaining ISA in the system. Memory resources are reserved in every ISA to accommodate new mappings from the failed ISA. However, bandwidth is not reserved and each ISA operates at max speed in all conditions (with failure or without the failure).

NAT translations are no preserved across switchovers and consequently they will have to be re-initiated by the clients.

In order for this commands to take effect, the intra-chassis redundancy mode must be set to active-active (config>isa>nat-group>redundancy active-active).

This command configures an ISA NAT group MDA.

This command specifies the RADIUS accounting policy to use for each MDA in this ISA group.

The no form of the command removes the policy ID from the configuration.

This command configures intra-chassis redundancy mode for NAT.

This command configures the ISA NAT group session limits.

This command configures the number of sessions per block that will be reserved for prioritized sessions.

This command configures the ISA NAT group watermarks.

This command configures, creates or deletes a NAT instance.

This command configures the script generated for deterministic NAT.

This command configures the remote location where the Python script will be exported. The Python script is then used off-line to perform reverse query. If this command is configured, the Python script generation is triggered by any modification of the deterministic NAT configuration. The new script reflects the change in mappings caused by configuration change. However, the script must be manually exported to the outside location with the admin nat save-determinisitic-nat command. The script cannot be stored locally on the system.

The script allows two forms of queries:

Forward Query:

output:

Reverse Query:

output:

This command enters the “inside” context to configure the inside NAT instance.

This command enters the “outside” context to configure the outside NAT instance.

This command assigns an IPv4 filter policy to the downstream NAT interface. This filter is applied to downstream traffic after the NAT function is applied but before it enters the inside VPRN instance.

The no form of the command removes the filter from the configuration.

This command specifies a filter to apply to the downstream traffic after routing in the outside virtual router instance and before the NAT function; it is useful for traffic that bypasses the egress filters applied in the inside virtual router instance, such as DSLite traffic.

The no form of the command removes the filter from the configuration.

This command configures the ipv6-filter for downstream traffic. This filter is applied to downstream traffic after it leaves the outside virtual router instance but before the NAT function is applied. This is useful for shared v6 filters that apply to all v6 DSM hosts.

The no form of the command removes the filter from the configuration.

This command configures the Maximum Transmission Unit ( MTU) for downstream traffic flowing through this router (as outside NAT router). The system fragments IP datagrams exceeding the MTU.

The no form of the command reverts to the default.

This command configures a destination prefix. An (internal) static route will be created for this prefix. All traffic that hits this route will be subject to NAT. The system will not allow a destination-prefix to be configured if the configured nat-policy refers to an IP pool that resides in the same service (as this would result in a routing loop).

This command enables the context to configure deterministic NAT.

This command affects ingress hashing of the subscribers for deterministic NAT. It will also affect hashing of the subscribers for non-deterministic NAT if the both types of NAT are configured simultaneously. The hashing will ensure that traffic load is distributed over multiple MS-ISAs in the system. For deterministic LSN44, (32 – n) bits of the source IP address will be considered for hashing, where 2^n= classic-lsn-max-subscriber-limit.

The scope of this command is the inside routing instance. This command must match the largest subscriber limit of all pools that are referenced by nat-policies configured within the corresponding inside routing instance.

This parameter must be configured before any prefix is configured and can be modified only if there are no prefixes configured under the deterministic NAT CLI hierarchy.

If non-deterministic NAT is not used simultaneously with deterministic NAT within a routing context, then hashing for non-deterministic NAT will be performed based on the subscriber.

This command sets the value for the number of high order bits of the source IPv6 address that will be considered as DS-Lite subscriber. The remaining bits of the source IPv6 address will be masked off, effectively aggregation all IPv6 source addresses under the configured prefix length into a single DS-Lite subscriber. Source IPv4 addresses/ports of the traffic carried within the DS-Lite subscriber will be translated into a single outside IPv4 address and the corresponding deterministic port-block (port-blocks can be extended).

The range of values for subscriber-prefix-length in non-deterministic DS-Lite is limited from 32 to 64 (a prefix will be considered as a DS-Lite subscriber) or it can be set to a value of 128 (the source IPv6 address is considered as a DS-Lite subscriber).

In cases where deterministic DS-Lite is enabled in a giver inside routing context, the range of values of the subscriber-prefix-length depends on the value of dslite-max-subscriber-limit parameter as follows:

subscriber-prefix-length – n = [32..64,128]

where n = log2(dslite-max-subscriber-limit)

[or in an alternate form: dslite-max-subscriber-limit = 2^n.]

In other words the largest prefix length for the deterministic DS-lite subscriber will be 32+n, where n = log2(dslite-max-subscriber-limit). The subscriber prefix length can extend up to 64 bits. Beyond 64 bits for the subscriber prefix length, there only one value is allowed: 128. In the case n must be 0, which means that the mapping between B4 elements (or IPv6 address) and the IPv4 outside addresses is in 1:1 ratio (no sharing of outside IPv4 addresses).

This parameter can be changed only when there are no deterministic prefixes configured in the same routing context.

This command is applicable only to deterministic NAT (LSN44 or DS-Lite). It configures prefixes on the inside and their association with outside deterministic pools via the nat-policy. Subscribers within the prefix will be deterministically mapped to outside IP addresses and corresponding port-ranges in the associated pool.

Multiple prefixes within an inside routing instance can be defined and they can reference different nat-policies (and therefore outside pools and routing instances). Moreover, prefixes from multiple routing instances can share the same deterministic pool.

Non-deterministic NAT can be used simultaneously with deterministic NAT within the s ame inside routing instance. However, they cannot share the same pool.

Prefixes can be added/removed under the condition that the associated deterministic pool is in a no shutdown mode.

Removing a prefix or modifying the map statement under it requires that the prefix be in a ‘shutdown’ mode.

The subscribers under the prefix are mapped deterministically into the outside IPv4 addresses and port ranges. The subscribers in LSN44 are the IPv4 addresses under the configured prefix, while in DS-Lite the subscribers are IPv6 source addresses that fall under the configured prefix OR IPv6 sub-prefixes whose length is determined by the DS-Lite subscriber-prefix-length command.

This command is applicable to prefixes in deterministic NAT (LSN44 and DS-Lite). Its purpose is to split the number of subscribers within the configured prefix over available sequence of outside IP addresses.

There are several rules guiding the usage of the map statement:

To modify map statements, the corresponding prefix must be in a shutdown mode.

Map statements can be configured automatically by the system, as soon as the prefix is enabled (no shutdown state) or they can be configured manually by the operator while the prefix is disabled.

The following is an example of the map statement for the LSN44 case:

Since each outside IP address can accommodate only 128 hosts, the subscribers (IPv4 addresses in LSN44) from the 10.0.0.0/24 prefix will be split and mapped into two outside IP addresses

10.0.0.0 – 10.0.0.127 (10.0.0.0/25) - 128.251.0.1

10.0.0.128 – 10.0.0.255 (10.0.0.128/25) - 128.251.0.2

The first IP address range will be mapped to the ‘to’ address in the map statement => 128.251.0.1. The second IP address range will be mapped into the next consecutive IP address in the pool assuming that this IP address is free. In this case this consecutive address (128.251.0,2) would not be shown in the map statement.

For Deterministic DS-Lite, the example would be:

There are 256 DS-Lite subscribers within the 2001:DB8::/56 prefix. Each subscriber will be a /64 IPv6 prefix as dictated by the subscriber-prefix-length command.

Since each outside IP address can accommodate only 128 hosts, the subscribers from the 2001:DB8::/56 prefix will be split and mapped into two outside IP addresses

2001:DB8:: – 2001:DB8:0:7F:: (2001:DB8::/57) - 128.251.0.1

2001:DB8:0:80:: – 2001:DB8:0:FF::(2001:DB8:0:FF::/57) - 128.251.0.2

The first IP prefix range will be mapped to the ‘to’ address in the map statement => 128.251.0.1. The second IP prefix range will be mapped into the next consecutive IP address in the pool assuming that this IP address is free. In this case this consecutive address (128.251.0,2) would not be shown in the map statement.

This command enables the context to configure Dual Stack Lite parameters.

In order for the DS-Lite feature to work, the ingress traffic (the IPv6 traffic that has to go to the NAT) must come from an IOM-3. If an IOM-2 is used, the IPv6 packet with destination the NAT will be dropped and an ICMP packet will be sent back.

This command configures the IP address of the NAT redundancy peer in the realm of this virtual router instance.

This command sets the value for the number of high order bits of the source IPv6 address that will be considered as DS-Lite subscriber. The remaining bits of the source IPv6 address will be masked off, effectively aggregation all IPv6 source addresses under the configured prefix length into a single DS-Lite subscriber. Source IPv4 addresses/ports of the traffic carried within the DS-Lite subscriber will be translated into a single outside IPv4 address and the corresponding deterministic port-block (port-blocks can be extended).

The range of values for subscriber-prefix-length in non-deterministic DS-Lite is limited from 32 to 64 (a prefix will be considered as a DS-Lite subscriber) or it can be set to a value of 128 (the source IPv6 address is considered as a DS-Lite subscriber).

In cases where deterministic DS-Lite is enabled in a giver inside routing context, the range of values of the subscriber-prefix-length depends on the value of dslite-max-subscriber-limit parameter as follows:

subscriber-prefix-length – n = [32..64,128]

where n = log2(dslite-max-subscriber-limit)

[or in an alternate form: dslite-max-subscriber-limit = 2^n.]

In other words the largest prefix length for the deterministic DS-lite subscriber will be 32+n, where n = log2(dslite-max-subscriber-limit). The subscriber prefix length can extend up to 64 bits. Beyond 64 bits for the subscriber prefix length, there only one value is allowed: 128. In the case n must be 0, which means that the mapping between B4 elements (or IPv6 address) and the IPv4 outside addresses is in 1:1 ratio (no sharing of outside IPv4 addresses).

This parameter can be changed only when there are no deterministic prefixes configured in the same routing context.

The no form of the command reverts to the default.

This command configures downstream IPv6 fragmentation behavior in DS-lite and NAT64. IPv6 fragmentation is performed in the ISA. IPv4 fragmentation is not affected by this command. If desired, downstream IPv4 packet can be fragmented in the carrier IOM before the packet reaches ISA (and the NAT function). The IPv4 fragmentation in the downstream direction can be set by the config>router/vprn>nat>outside>mtu command

DS-Lite IPv6 Fragmentation in Downstream Direction (IPv4 to IPv6)

In case that the length of the received IPv4 packet is larger than the configured tunnel-mtu value while fragmentation is allowed, the resulting IPv6 packet will be fragmented (IPv4 is tunneled within IPv6). The maximum size of the of the fragmented IPv6 packet will be 48bytes larger than the configured tunnel-mtu value. This is due to the size of the tunneling IPv6 header: 40bytes basic IPv6 header + 8 bytes of extended fragmentation IPv6 header.

In case that fragmentation is not allowed while the IPv4 packet size is larger than configured tunnel-mtu size, the IPv4 packet will be dropped and an ICMPv4 Datagram Too Big message will be generated towards the source. The advertised mtu size in that ICMP message will be set to configured tunnel-mtu value.

NAT64 IPv6 Fragmentation in Downstream Direction (IPv4to IPv6)

In contrast to DS-lite, NAT64 transport is not based on tunneling. Instead, IP headers are translated between IPv4 and IPv6. Consequently, NAT64 fragmentation operates based on the ipv6-mtu, as opposed to tunnel-mtu in DS-lite which represents the size of the tunnel payload (IPv4 packet).

In case that the length of the translated IPv6 packet exceeds the size of the configured ipv6-mtu value while fragmentation is allowed, the resulting IPv6 packet will be fragmented. The maximum size of the of the fragmented IPv6 packet will be the configured ipv6-mtu value.

In case that fragmentation is not allowed while the translated IPv6 packet size is larger than configured ipv6-mtu size, the IPv4 packet (that is supposed to be translated into IPv6) will be dropped and an ICMPv4 Datagram Too Big message will be generated towards the source. The advertised mtu size in that ICMP message will be set to the ipv6-mtu value minus 28bytes. The 28bytes comes from the size of the IPv6 overhead of the translated packet (20bytes difference between the IP header sizes  40bytes in IPv6 vs 20bytes in IPv4; 8 bytes for extended IPv6 fragmentation header).

This command sets the size of the payload in IPv6 packet in downstream DS-lite direction. The payload is, in essence, the tunneled IPv4 packet.

This command enters the “l2-aware” context for configuration specific to Layer 2-aware NAT.

This command configures the IP address and mask of the subnet.

The no form of the command removes the IP address and prefix length from the configuration.

This command enables the context to configure NAT64.

The no form of the command disables NAT64.

This command specifies if UDP datagrams with zero IPv4 checksum are dropped.

If this command is disabled, the system calculates the IPv6 checksum for each such datagram.

This command specifies if the IPv4 Type Of Service (TOS) is ignored and the IPv6 traffic class bits set to zero.

If this command is disabled, the system copies the IPv4 TOS into the IPv6 traffic class.

This command specifies if the system always inserts an IPv6 fragment header, to indicate that the sender allows fragmentation.

The no form of the command does not allow the system to insert an IPv6 fragment header.

This command enters the “l2-aware” context for configuration specific to Layer 2-aware NAT.

This command configures a Layer 2-aware NAT address. This address will act as a local address of the system. Hosts connected to the inside service will be able to ARP for this address. To verify connectivity, a host can also ping the address. This address is typically used as next hop of the default route of a Layer 2-aware host. The given mask defines a Layer 2-aware subnet. The (inside) IP address used by a Layer 2-aware host must match one of the subnets defined here or it will be rejected.

This command configures the NAT policy that will be used for large-scale NAT in this service.

The no form of the command removes the policy name from the configuration.

This command enables the context to configure NAT64 parameters.

The no form of the command disables NAT64.

This command enables the NAT64 node to drop received UDP datagrams with zero IPv4 checksum. By default, checksum is re-calculated for non-fragmented datagrams.

The no form of the command disabales the command.

This command specifies whether the IPv4 Type Of Service (TOS) is ignored and the IPv6 traffic class bits set to zero.

When disabled, the system copies the IPv4 TOS into the IPv6 traffic class.

The no form of the command recognizes the IPv4 Type Of Service (TOS).

This command specifies whether the NAT64 node will insert IPv6 fragment header to IPv6 packets for which the DF bit is not set in the corresponding IPv4 packet, and is not already a fragment.

The no form of the command disables the insertion.

This command sets the size of the IPv6 downstream packet in NAT64. This packet is translated from IPv4.

The no form of the command reverts to the default.

This command configures the IPv6 prefix used to derive the IPv6 address from the IPv4 address, and is same as the prefix used by DNS64 to generate AAAA record returned for IPv4 endpoint resolution. NAT64 node announces this prefix in routing to attract traffic from IPv6 hosts. If the prefix is not configured, then a well known prefix, 64:FF9B::/96, is used.

The no form of the command removes the prefix from the NAT64 configuration.

This command specifies the value of the IPv4 Type Of Service (TOS) field. When enabled, the NAT64 node ignores IPv6 traffic-class and sets IPv4 TOS to supplied tos-value in the translated IPv4 packet.

The no form of the command reverts to the default.

This command specifies the IPv6 address prefix length to be used for the NAT64 subscribers in this virtual router instance.

The no form of the command

This command enables the context to configure redundancy parameters.

This command is used in LSN44 multi-chassis redundancy in conjunction with filters. The configured peer address is an IPv4 address that is configured under an interface on the peering LSN44 node (active or standby). This IPv4 interface address is advertised via routing on the inside in order to attract traffic from the standby to the active LSN44 node.

If configured, the steering-route will be advertised only from the active LSN44 node. Consequently, upstream traffic for LSN44 will be attracted to the active LSN44 node. The nat action in the ipv4-filter on the active LSN44 node will forward traffic to the local MS-ISA where LSN44 function is performed. However, in that case that upstream traffic somehow arrives on the standby LSN44 node, the nat action in the IPv4-filter will forward traffic to the peer address (active LSN44 node).

The no form of the command removes the peer ipv4-address from the configuration.

This command is used in NAT64 multi-chassis redundancy in conjunction with filters. The configured peer6 address is an IPv6 address configured under an interface on the peering NAT64 node (active or standby). This IPv6 interface address is advertised via routing on the inside in order to attract traffic from the standby to the active NAT64 node.

Under normal circumstances, the NAT64 prefix will be advertised only from the active NAT64 node. Consequently, upstream traffic for NAT64 will be attracted to the active NAT64 node. The nat action in the ipv6-filter on the active NAT64 node will forward traffic to the local MS-ISA where NAT64 function is performed. However, in that case that upstream traffic somehow arrives on the standby NAT64 node, the nat action in the IPv6-filter will forward traffic to the peer6 address (active NAT64 node).

The no form of the command removes the peer6 ip-address from the configuration.

This command is optionally used in LSN44 multi-chassis redundancy when filters are used on the inside to send traffic destined for the LSN44 function to MS-ISA, where NAT is performed.

If configured, the steering-route is advertised only from the active LSN44 node: the purpose is to bring the LSN44 node activity awareness to downstream routers. In this fashion, downstream routers can make a more intelligent decision when forwarding traffic in the upstream direction. Based on the steering-route, traffic can be sent directly towards the active LSN44 node. This route avoids an extra forwarding hop which would ensue in the case without LSN44 activity awareness, where the upstream traffic can be forwarded to the standby LSN44 node and then to the active LSN44 node.

LSN44 node activity (active/stanby) is evaluated per isa-group based on monitoring routes advertised on the outside.

The no form of the command removes the ip-prefix/length from the configuration.

This command enables the context to configure subscriber identification for Large Scale NAT.

This command defines the attribute that will in addition to framed-ip-address (inside IP address) and service-id be used for correlating BNG subscriber with the NAT subscriber.

Only a single attribute at the time can be configured. The attribute will be extracted from the BNG accounting start and/or interim-update messages via Radius accounting proxy server. This attribute can be then optionally passed to the Large Scale NAT44 accounting server. User-name attribute (if included) in Large Scale NAT44 accounting messages will be automatically set to the subscriber-id string.

The attribute parameter can be changed at any given time and the change will be reflected automatically when the next interim-update message from the BNG host is received by Radius accounting proxy.

In case that the BNG accounting message in RADIUS accounting proxy does not contain this attribute, subscriber aware Large Scale NAT44 functionality for this particular subscriber will be disabled.

When this command denies address translation to subscribers that have not been identified via accounting messages sent by BNG and received by Radius accounting proxy. This command has effect only in Subscriber Aware Application.

This command configures RADIUS proxy server parameters. This is a reference to a RADIUS accounting proxy server in Subscriber Aware Large Scale NAT44 application. RADIUS accounting proxy server will cache attributes related to a BNG subscriber as they are received in standard accounting messages (RFC 2866). Radius accounting proxy server can be configured in any routing instance within 7750 SR.

This command configures the MTU for downstream traffic flowing through this router (as outside NAT router). The system fragments IP datagrams exceeding the MTU.

This command creates a NAT pool in the outside routing context. The nat pool defines the parameters that will be used for IP address and port translation within the pool.

This command configures a NAT address range.

This command starts or stops draining this NAT address range. When an address-range is being drained, it will not be used to serve new hosts. Existing hosts, however, will still be able to use the address that was assigned to them even if it is being drained.An address-range can only be deleted if the parent pool is shut down or if the range itself is effectively drained (no hosts are using the addresses anymore).

This command specifies the mode of operation of this NAT address pool.

The no form of the command reverts to the default.

This command configures the end of the port range available for port forwarding. The start of the range is always equal to one.

The number of ports that can be configured is half of the available block => 64512 : 2 = 32256

In combination with port-forwarding-range the formulas are:

      "max port-reservation blocks" = 65535 - "port-forwarding-range"

      "max port-reservation ports" = (65535 - "port-forwarding-range") / 2

with:

the default min value for "port-forwarding-range" = 1023

Also, the same applies for max port-forwarding-range if the port-reservation is already configured:

      "max port-forwarding-range" = 65535 - "port-reservation blocks"

      "max port-forwarding-range" = 65535 - ("port-reservation ports" * 2)

The no form of the command reverts to the default.

This command configures deterministic NAT for this pool

This command is applicable only to deterministic NAT. It configures the number of deterministic ports per subscriber (for example a subscriber is an inside IP address in LSN44 or IPv6 address or prefix in DS-lite). Once this command is enabled, the pool will transition into deterministic mode of operation. This means that the subscribers can use dynamic port-blocks in the pool only as a mean to expand the range of originally assigned deterministic ports. A pool with such property is referred to as deterministic pool. However, deterministic NAT and non-deterministic NAT cannot use the same pool simultaneously.

All subscribers in deterministic pool are pre-mapped during the configuration phase to outside IP addresses and deterministic port-blocks. Because of this, the deterministic pool cannot be oversubscribed with subscribers (first-come, first-served).

Once the deterministic pool becomes operational (no shutdown) a log is created. The same applies if the pool is disabled (shutdown). As a result of this ’one time’ logging, there will be no additional logging when a subscriber starts using ports from the pre-assigned deterministic port block. This drastically reduces the logging overhead. However, when a deterministic port block is expanded by a dynamic port block, a log will be created on any allocation/de-allocation of the dynamic port block. The logs are also created for static port forwards (including PCP).

The number of subscribers per outside IP address (subscriber-limit) multiplied by the number of deterministic ports per subscriber (port-reservation) will determine the port range of an outside IP address that will be dedicated to deterministic mappings. The number of subscribers per outside IP address in deterministic NAT must be power of 2 (2^n). Once the deterministic ports are allocated, the dynamic ports are carved out of the remaining port space of the same outside IP address according to the existing port-reservation command under the same hierarchy,

This command configures the size of the port-block that will be assigned to a host that is served by this pool. The number of ports configured here will be available to UDP, TCP and ICMP (as identifiers).

This command configures the mode of operation of this NAT pool.

This command will enable the reservation of the dynamic port blocks when the first port forward for the subscriber is created. The dynamic port bloc allocation is logged only if the block is being utilized (mapping are created). In other words, dynamic port block reservation due to the port forward creation but without any dynamic mapping, will not be logged.

The reserved port block will be released only when the last mapping in the block expires AND there is not port forward associated with the subscriber. The de-allocation log (syslog or Radius) will be generated when the dynamic port block is completely released.

Dynamic port block reservation can be enabled only if the configured maximum number of subscriber per outside IP address is less or equal then the maximum number of configured port blocks per outside IP address.

This command specifies the end of the port range available for port forwarding. The start of the range is always equal to one.

This command enables the context to configure NAT pool redundancy parameters.

This command configures the route to export to the peer. While the export prefix is configured and the value of the object tmnxNatPlLsnRedActive is equal to true, the system exports this prefix in the realm of the virtual router instance associated with this pool; to the NAT redundancy peer, the presence of this prefix is an indication that the Large Scale NAT function in this virtual router instance is active; hence, the export prefix of this system is the monitor prefix of the peer.

The export prefix must be different from the monitor prefix.

This command implicitly enables Pool Fate-Sharing Group (PFSG) which is required in case of multiple NAT policies per inside routing context. A NAT pool configured with this command will not advertize or monitor any route in order to change its (activity) state but instead it will directly follow the state of the lead pool in the PFSG. Once the lead pool changes its (activity) state, all the remaining pools following the lead pool will change their state accordingly.

This command configures the IP address of the prefix to be monitored.

While the monitor prefix is configured, the system monitors the presence of this prefix in the routing table of the virtual router instance associated with this pool; the presence of this prefix is an indication that the NAT redundancy peer is active; the monitor prefix of this system is the export prefix of the peer.

The monitor prefix must be different from the export prefix.

This command configures the maximum number of subscribers per outside IP address. In case multiple port blocks per subscriber are used, the block size is typically small; all blocks assigned to a given subscriber belong to the same IP address; the subscriber limit guarantees that any subscriber can get a mimimum number of ports.

This command configures the watermarks for this NAT pool.

This command configures the ip-filter for upstream traffic. This filter is applied to the upstream traffic after the NAT function and before it enters the outside virtual router instance; it is useful for traffic that bypasses the ingress filters applied in the inside virtual router instance, such as DSLite traffic.

This command configures the ipv6-filter for upstream traffic. This filter is applied to the upstream traffic after the NAT function and before it enters the outside virtual router instance. This is useful for shared v6 filters that apply to all v6 DSM hosts.

This command associates the MSS adjust group consisting of multiple ISAs with the routing context in which the application requiring TCP MSS adjust resides.

This commmand configures a NAT policy.

This command enables the context to configure Application Level Gateway parameters of this policy.

This command enables FTP ALG.

The no form of the command disables FTP ALG.

This command enables PPTP application-level gateway (ALG).

The call-id is captured in the outgoing call management messages and along with the source IP address and the source TCP, is translated by NAT. Once the PPTP call is established, the call-id in the associated GRE packet in the incoming direction (from outside to inside) is correspondingly translated so that it matches the call-id mapping established during the call establishment phase. The call-ids used in the mappings are selected randomly and they try to honor parity (odds/even).

A PPTP session can be initiated only from the inside of NAT.

GRE traffic is allowed through NAT only if the corresponding mapping exists. This mapping is created during the call negotiation phase.

There can be seven calls (GRE tunnels) per control session.

This command enables RTSP ALG.

The no form of the command disables RTSP ALG.

This command enables SIP ALG.

The no form of the command disables SIP ALG.

This command configures the maximum number of port blocks per subscriber.

The no form of the command reverts to the default.

This command configures the filtering of the NAT policy.

This command configures the IP flow information export protocol.

The no form of the command removes the IP flow information export protocol.

This command configures the NAT pool of this policy.

This command configures the port limits of this policy.

This command configures the maximum number of port forwarding entries.

This command configures the number of ports per block that will be reserved for prioritized sessions.

This command configures the port usage watermarks for the NAT policy.

This command configures the prioritized sessions of this NAT policy.

This command specifies what to do when a TCP packet without the SYN flag set is received by the NAT inside for an unknown flow. When this is enabled, the packet will be dropped and a TCP reset will be generated.

The no form of this command disables sending the reset; the packet will still be dropped.

This command configures the forwarding classes that have their sessions prioritized.

This command configures the session limit of this policy. The session limit is the maximum number of sessions allowed for a subscriber associated with this policy

This command configures the value to adjust the TCP Maximum Segment Size (MSS) option.

The no form of the command returns the segment size to the default.

This command configures session idle timeouts for this policy.

This command configures the timeout applied to an ICMP query session.

This command configures the SIP inactive media timeout.

This command specifies the subscriber retention timeout, the time a NAT subscriber and its associated IP address is kept after all hosts and associated port blocks have expired.

If a NAT subscriber host appears before the retention timeout has elapsed, it will be given the same outside IP address.

This command configures the timeout applied to an ICMP query session.

This command configures the idle timeout applied to a TCP session in the established state.

This command configures the timeout applied to a TCP session in the SYN state.

This command configures the timeout applied to a TCP session in a time-wait state.

This command configures the idle timeout applied to a TCP session in a transitory state.

This command configures the UDP mapping timeout.

This command configures the timeout applied to a UDP session with destination port 53.

This command configures the UDP mapping timeout applied to new sessions.

This command specifies the NAT inbound refresh behavior.

This command configures a a PCP server policy name.

The no form of the command removes the name from the configuration.

This command configures the lifetime of explicit mappings made by the PCP servers.

This command specifies the maximum length of mapping descriptions made by the PCP servers using this PCP policy.

This command specifies the PCP opcodes supported by the PCP servers using this PCP policy.

This command enables/disables support for the announce opcode.

This command enables/disables support for the get opcode.

This command enables/disables support for the map opcode.

This command configures the PCP options supported by the PCP servers using this PCP policy.

This command enables/disables support for the description option.

This command enables/disables support for the next option.

This command enables/disables support for the port-reservation option.

This command enables/disables support for the prefer-failure option.

This command enables/disables support for the third-party option.

This command configures the accepted protocol version range.

This command enables the context to configure NAT port forwarding parameters.

This command creates NAT static port forwards for L2 aware subscribers. The ESM subscriber must be present in the system before this command is executed. The no form of the command deletes NAT static port forwards for L2 aware subscribers.

This command creates NAT static port forwards for LSN44, Ds-Lite and NAT64. Static port forwards (SPF) are static mappings created so that certain applications on the inside (private side) can be reached from host that are on the outside of the NAT. SPF statically map the subscriber (inside IP address in LSN44, CPE IPv6 address/prefix in DS-Lite and IPv6 prefix in NAT64), inside port and protocol to an outside IPv4 address, port and the same protocol.

If only the inside router, the inside IPv4/v6 address/prefix and the protocol are configured as parameters in the SPF request, the remaining fields in the mapping (outside port and outside IPv4 address) will be selected automatically by the node and reported in CLI once the command execution is completed.

Specifying the outside IPv4 address in the SPF request, mandates that all other, otherwise optional, parameters be also specified in the request (inside port and outside port). This creates a fully specified SPF request. Fully specified SPF request can be used in multi-chassis NAT redundancy deployments where the SPF is manually replicated between the SROS nodes. In single chassis NAT deployments, fully specified SPF request is guaranteed to work only in the system with a single MS-ISA in it. Otherwise (multiple MS-ISAs in the system) a conflict may arise where two distinct inside IP addresses that may reside on separate MS-ISAs are requested to be mapped to the same outside IPv4 address. This will not be possible since the outside IPv4 address cannot be split across the MS-ISAs (each IP address, inside or outside, is tied to a single MS-ISA).

In non-fully specified SPF requests (missing the inside port and/or outside port and the outside IPv4 address within the SPF request), the outside IPv4 address selection will depend on the configuration of the outside port in the SPF request:

If multiple NAT policies per inside routing context are used, then the NAT policy must be specified in the SPF creation request. This is needed so the SPF be created in the correct pool.

SPFs are disabled by default and they must be explicitly enabled by the port-limits forwarding command within the NAT policy.

Configured SPFs, unlike SPFs created via the tools commands, are preserved across reboots without having to configure persistency (config>system>persistence>nat-port-forwarding) since they are part of the configuration. When the pool is shutdown the SPFs will be deactivated. When the pool is enabled (no shutdown), the SPFs (as created by tools command or via configuration) will be activated.

To avoid possible persistency related conflicts, SPFs can only be created using one method on a given node: either as configuration (the CLI configure branch) or using the tools command. For example: if a first SPF entry is created via CLI tools commands, the node will prevent SPF creation via configuration (the CLI configure branch) and vice versa.

The no form of the command deletes NAT static port forwards for LSN44, Ds-Lite and NAT64.

This command enables the context to configure IPFIX parameters.

This command creates an IPFIX export policy with a set of transport parameters that will be used to transmit IPFIX records generated by an application within 7750 SR node to an external collector node. This policy name can be referenced from each application within 7750 SR that requires flow logging.

This command defines an external collector node that will collect IPFIX records sent by 7750 SR node. The IPFIX records will be streamed to the collector node using UDP transport. Traffic is originated from a random ephemeral UDP port to the destination port 4739. Up to two collector nodes can be defined for redundancy purposes.

UDP streams are stateless due to the significant volume of transactions. However they do contain 32bit sequence numbers such that packet loss can be identified.

Multiple IPFIX records are sent in a single UDP packet. UDP packet transmission is triggered when the packet size containing IPFIX records exceeds the configured MTU value or the internal timer which is set to 250ms, whichever occurs first.

This command sets the MTU size of the UDP packet containing IPFIX records destined for the collector node. Multiple records will be stuffed into a single IP packet until stuffing an additional data record would exceed MTU or the internal timer of 250ms expires.

This command configures the source address from which UDP streams containing IPFIX flow records will be sourced.

This command configures the time interval in which Template Set messages are sent to the collector node. Template sets is an IPFIX message that defines fields for subsequent IPFIX messages but contains no data of its own. In other words, IPFIX data is NOT passed as set of TLVs, but instead data is encoded with a scheme defined through the Template Set message.

This command creates a policy template related to transport of accounting messages from the BB-ISA card to the accounting server. It also defines accounting attributes that will be included in accounting messages. The policy template will be instantiated once it is applied to the BB-ISA cards in the nat-group.

The no form of the command removes the policy name from the configuration.

This command configures attributes to be included in RADIUS accounting messages.

This command configures attributes to be included in RADIUS authentication messages.

This command enables the acct-delay-time.

This command enables the acct-trigger-reason.

This command includes called station id attributes.

The no form of the command excludes called station id attributes.

This command enables the inclusion of the calling-station-id attribute in RADIUS authentication requests and RADIUS accounting messages.

This command enables the generation of the agent-circuit-id for RADIUS.

This command enables insertion of RADIUS VSA containing all dhcp-options from dhcp-discover (or dhcp-request) message. The VSA contains all dhcp-options in a form of the string. If required (the total length of all dhcp-options exceeds 255B), multiple VSAs are included.

This command includes the “[26-6527-36] Alc-DHCP-Vendor-Class-Id” attribute in RADIUS accounting messages. The content of the DHCP Vendor-Class-Identifier option (60) is mapped in this attribute.

If a DHCPv6 stack is active for a UE, this attribute defines if options received in the last DHCPv6 message should be reflected.

If authentication was triggered by DHCPv6, this knob defines if options received in that DHCPv6 message should be reflected in the radius Access-Request.

This attribute defines if the ipv6 address of the UE is present during authentication if the datatrigger packet is IPv6.

If an active IA_NA lease exists, this attribute defines if the IA_NA address of the UE is present in accounting.

This command enables the context to specify the RADIUS parameters that the system should include into RADIUS authentication-request messages.

This command includes the frame-counters attribute.

The no form of the command excludes frame-counters attribute.

This command enables the inclusion of the framed-ip-addr attribute.

The no form of the command excludes called framed-ip-addr attributes.

This command enables the inclusion of the framed-ip-netmask attribute.

The no form of the command disables the inclusion.

If an active SLAAC lease exists, this attribute defines if the SLAAC prefix of the UE is present in accounting..

This command enables the inclusion of the hardware timestamp attributes.

The no form of the command excludes the hardware timestamp attributes.

This command enables the inclusion of the NAT inside service ID attributes.

The no form of the command excludes NAT inside service ID attributes.

This command enables the generation of the client MAC address RADIUS attribute.

This command enables the inclusion of the multi-session-id attributes.

The no form of the command excludes the multi-session-id attributes.

This command enables the inclusion of the NAS-Identifier attributes.

The no form of the command excludes NAS-Identifier attributes.

This command specifies the RADIUS NAS-IP-Address attribute.

The no form of the command reverts to the default.

This command enables the generation of the nas-port-id RADIUS attribute. Optionally, the value of this attribute (the SAP-id) can be prefixed by a fixed string and suffixed by the circuit-id or the remote-id of the client connection. If a suffix is configured, but no corresponding data is available, the suffix used will be 0/0/0/0/0/0.

This command enables the generation of the NAS-Port-Type RADIUS attribute.

The no form of the command disables the generation.

This command enables the inclusion of the NAT subscriber string attributes.

The no form of the command excludes NAT subscriber string attributes.

This command enables the inclusion of the octet-counters attributes.

The no form of the command excludes octet-counters attributes.

This command enables the inclusion of the outside IP attributes.

The no form of the command excludes outside IP attributes.

This command enables the inclusion of the NAT outside service ID attributes.

The no form of the command excludes NAT outside service ID attributes.

This command enables the inclusion of the NAT port range block attributes.

The no form of the command excludes NAT port range block attributes.

This command enables the inclusion of the release reason attributes.

The no form of the command excludes release reason attributes.

This command enables the sending of remote ID option. The client DHCP Unique Identifier (DUID) is used as the remote ID.

The no form of the command disables the sending of remote ID option relay packet.

This command enables including the per-SSID VLAN ID in Alc-Wlan-SSID-VLAN.

This command specifies the password that is used in the RADIUS access requests.It shall be specified as a string of up to 32 characters in length.

The no form of the command resets the password to its default of ALU and will be stored using hash/hash2 encryption.

This command enables periodic RADIUS logging of currently allocated port blocks for a NAT subscriber (NAT binding).

This command enables the inclusion of the session-time attributes.

The no form of the command excludes session-time attributes.

This command enables the inclusion of subscriber data attributes.

The no form of the command excludes subscriber data attributes.

This command specifies that subscriber ID attributes should be included into RADIUS accounting messages.

This command enables including the Alc-Wlan-Ue-Creation-Type.

This command enables the inclusion of user name attributes.

The no form of the command excludes user name attributes.

This command enables including the Alc-RSSI.

This command enables including the per-SSID VLAN ID in the Alc-Wlan-SSID-VLAN.

This command enables the context to enable or disable the sending of triggered interim-updates, with the exception of the following:

If enabled, an interim-update will be sent for a DSM UE whenever a DHCP, SLAAC or DHCPv6 address gets allocated or freed.

This command creates the context for defining RADIUS accounting server attributes under a given session authentication policy.

This command configures the algorithm used to access the list of configured RADIUS servers.

This command configures the number of times the router attempts to contact the RADIUS server for authentication, if not successful the first time.

The no form of the command reverts to the default value.

This command specifies the number of times the router attempts to contact the RADIUS server for authentication, if not successful the first time.

The no form of the command reverts to the default value.

This command adds a RADIUS server and configures the RADIUS server IP address, index, and key values.

Up to five RADIUS servers can be configured at any one time. RADIUS servers are accessed in order from lowest to highest index for authentication requests until a response from a server is received. A higher indexed server is only queried if no response is received from a lower indexed server (which implies that the server is not available). If a response from a server is received, no other RADIUS servers are queried.

The no form of the command removes the server from the configuration.

This command configures the start IP address of the source address range from which the source IP addresses of the ISA cards will be allocated. A source-address-range start-ip-address must be configured for radius packets to be sent out.

This command configures the number of seconds the router waits for a response from a RADIUS server.

The no form of the command reverts to the default value.

This command configures accounting for this server.

This command configures authentication for this server.

This command configures Change of Authorization (CoA) messages.

Configures the The IP address of the RADIUS server. Two RADIUS servers cannot have the same IP address. An error message is generated if the server address is a duplicate.

This command configures the secret key to access the RADIUS server. This secret key must match the password on the RADIUS server.

This command defines the format of the user-name field in the session authentication request sent to the RADIUS server. For authentication of IPv6 triggers (ICMPv6, DHCPv6, IPv6 data-trigger) the user-name format will always fall back to mac only.

The no form of the command switches to the default format, mac.

This command configures the NAT policy to be used for subscribers associated with this subscriber profile.

This command saves the script that calculates Deterministic NAT map entries.

Once the location for the Python deterministic NAT script is configured, the script is generated/updated every time deterministic NAT configuration is modified. However, the script must be manually exported to the remote location. This command triggers the export of the script to a remote location.

This command enables the context to configure UPnP parameters

This command creates a new upnp-policy or enters the configuration context of an existing upnp-policy.

The no form of the command removes the upnp-policy policy-name from the configuration.

This command enables UPnP IGD services for the subscriber. All ESM hosts of the subscriber could use the UPnP protocol to create port mapping. This feature only support L2-Aware NAT host.

UPnP parameters are defined in the referenced upnp-policy configured in the config>service>upnp context.

This command specifies the listening port of UPnP server.

The no form of the command reverts to the default.

This command specifies the maximum number of UPnP mapping per subscriber.

The no form of the command reverts to the default.

This command enable UPnP strict mode. With strict-mode, system only allows changes to existing UPnP mapping if the request comes from same UPnP client.

This command creates the profile Bridged Residential Gateway (BRG) devices. The BRG profile specifies default parameters that are used for host management under a single BRG.

The no form of the command removes the profile name from the configuration.

This command configures the BRG connectivity verification. The system uses ICMP Echo request messages for connectivity verification.

When the last host associated to a BRG is removed, a ping mechanism is used to verify if the BRG is still active. This command specifies the parameters used in this mechanism.

The no form of this command disables the BRG ping mechanism and removes the BRG without verification. Any configured hold-time still applies.

This command enables the context to configure per-subscriber IPv4 address pool parameters to be used for address allocation. Pools for different subscribers can overlap. Specific pool parameters can be overridden by RADIUS.

This command configures the lease time, in seconds, to be used when allocating addresses from the pool. This time should always be larger than the renew/rebind time.

The no form of the command reverts to the default.

This command enables the context to configure options that are reflected in DHCP.

This command configures DHCP options.

This command configures the subnet that will be used for the l2aware-subscriber. This subnet is only locally significant and can overlap with other subscribers. The subnet is derived by ignoring the host-bits of the ip-address. The ip address specifies the default gateway that will be signaled in DHCP along with the netmask derived from the prefix-length.

The start and end addresses specify the addresses that are suitable for allocation within the given subnet, the start and end address included. If the subnet address (host-bits 0), broadcast address (host-bits 1) or default-gw address fall in this range, they will not be considered for allocation.

Changing the subnet will only have effect for new subscribers. New and existing hosts for existing subscribers will keep allocating from the original subnet.

The no form of this command removes the subnet configuration. New l2-aware subscribers will no longer use this pool and fall back to a pool from radius. Existing subscribers will keep using the original subnet.

When the BRG should be deleted this still holds the BRG object for the specified time. This applies when connectivity-verification fails or when the last host is removed and no connectivity-verification is enabled. Hold time does not apply to an explicit removal via radius or clear commands.

The no form of the command deletes the hold-time.

This command configures the time to hold on to a BRG immediately after the system detected its presence. The hold time does not apply in case this system removes the BRG context upon an explicit request

This command enables BRG processing on the specified RADIUS proxy server. Whenever an Access-Accept is received with the attribute Alc-BRG-Id present, this will trigger the creation of a BRG. The BRG will use the brg-profile specified in Access-Accept or otherwise fall-back to this brg-profile. When the specified radius-proxy-server has a cache enabled, no cache entries will be created for a transaction identified as BRG. A RADIUS proxy server can only be listed in one brg-profile.

This command can be executed multiple times.

The no form of this command removes BRG processing for the specified radius-proxy server.

The radius-server-policy that is used if the BRG needs to be authenticated to the PCMP by the vG. This is required if the BRG does not perform radius authentication via the proxy itself. The vG will originate a valid Access Request using the BRG ID as username.

The no form of this command removes the radius-server-policy from the configuration. Setup of an unauthenticated BRG will now fail.

This command configures the SLA profile string which will be used as a default for SLA-profile lookup. This string can be overridden during BRG or host authentication.

The no form of the command removes the string from the configuration.

This string will be used as a default for subscriber-profile lookup. This string can be overridden during BRG or host authentication. The no form of the command removes the string from the configuration.

This command defines context for destination NAT (DNAT) specific configuration under the nat-policy.

This command configures outside routing context and nat-group in which DNAT translation shout take place. This command is mutually exclusive with the pool command in nat-policy.When DNAT-only is enabled, no source and port NAT (SNAPT) is performed. In other words, only the destination IP address (going from inside to outside) is translated while the source IP address and port are not translated.

This command enables the context on the NAT inside context where dnat-only parameters are configured.

This command references the nat-prefix-list that contains source IP addresses on the inside (private side).

The source IP addresses on the inside must be known in advance in a dnat-only instance. This is required so the corresponding routes can be installed in the routing table and thus the downstream traffic is properly routed towards the MS-ISAs where the original translation was performed (and state is kept).

In the dnat-only case, it is mandatory that the inside (private side) and the outside (public side) are in separated VPRNs.

The source IP addresses on the inside must be known in advance in a dnat-only instance. This is required so that the corresponding routes can be installed in the routing table and thus the downstream traffic is properly routed towards the MS-ISAs where the original translation was performed (and state is kept).

In the dnat-only case, it is mandatory that the inside (private side) and the outside (public side) are in separated VPRNs.

This command limits the number of source routes (inside routes) that are installed on the outside in dnat-only case. In case that the number of actual routes is larger than the number of configured routes, the excess of the routes will not be installed in the routing table and a log will be raised.

This command sets the granularity of traffic distribution in the upstream direction across the MS-ISA within the scope of an inside routing context. Traffic distribution mechanism is based on the source IPv4 addresses/prefixes. More granular distribution is based on the IPv4 address, while distribution based on the IPv4 prefix (determined by prefix length) will be less granular. The granularity will further decrease with shorter prefix length.

For example, a prefix length of 32 will distribute individual /32 IPv4 addresses over multiple MS-ISAs in an ISA group. This will ensure better traffic load balancing at the expense of forwarding table utilization on the outside (public side) where each /32 is installed in the forwarding table. On the contrary, shorter prefixes will ensure better utilization of the forwarding table on the outside, at the expense of coarser spread of IP addresses over multiple MS-ISAs.

This command affects all flavors of LSN44 within the inside routing contexts, although its primary use is intended for deterministic NAT and dnat-only.

The length of the prefix that is used for distribution purposes is (32-n), where 2^n= classic-lsn-max-subscriber-limit. For example, if traffic distribution is based on the IPv4 address (prefix length = 32), then n must be 0. From here, it follows that classic-lsn-max-subscriber-limit must be set to 1:

Prefix length = 32 -> 32-n = 32 -> n=0 -> 2^0= 1 = classic-lsn-max-subscriber-limit classic-lsn-max-subscriber-limit = 1

The implicit method given by this command uses power of 2 calculations to provide prefix length for traffic distribution purposes. This roundabout approach to determine the prefix-length has roots in deterministic NAT where this command was originally introduced.

Even though deterministic NAT and dnat-only have very little in common, the method (and CLI syntax) for calculating the prefix length using the classic-lsn-max-subscriber-limit parameter for traffic distribution purposes is shared between the two. In dnat-only, this parameter is important from an operational perspective since it affects traffic load balancing over MS-ISA and the size of the routing table.

This command must be configured before any prefix is configured and can be modified only if there are no prefixes configured under the deterministic NAT.