Best Practice: Configure round-robin address allocation for the NAT pool used by traffic served with APP. Round-robin allocation allocates ports from different IP addresses.

Best Practice: Do not configure EIM together with the SIP ALG; doing so adds processing overhead with no benefit.

• Don’t enable EIM for applications that are defined ALGs or are known not to use Session Traversal Utilities for NAT(STUN) servers to discover the presence of a NAT router.
• Enable EIM for applications that do reuse the source ports and rely on a CGNAT device to maintain the same address:port mapping for all traffic sent to different destinations, such as on-line gaming applications like Xbox and PS3, or applications that use unilateral self-address fixing methods (UNSAF). see (IETF RFC 3424 IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation).

Best Practice: Define PBA blocks with a size that is a power of 2 or 4 related to the average number of sessions a user is expected to have active. For example, if a user is expected to have an average of approximately 200 to 250 sessions active, configuring the PBA block size to 512 or 1024 will provide a liberal allocation.

Best Practice: When changing PBA configurations, restart the services PIC if possible. Minimally, you must deactivate and reactivate the affected service set.

Best Practice: Do not configure NAT pools with more than 64 addresses (that is, a /26 network) and round-robin configured and 64K ports from each address.

• Use logging to the system log at the service-set level rather than at the services PIC interface level when possible.
• Do not enable logging for redundant information. When using PBA, you don’t need to configure logs per session because knowing the PBA block and the block size enables you to derive the ports allocated to each user. In this case, a log that reports all sessions created by that user with ports belonging to a block is redundant. If you have configured deterministic NAT (DetNat) a log is completely unnecessary because all information on port allocation can be deduced mathematically.
• Rate-limit the number of logs generated from an sp- interface. When not set, the default limits apply: 10K for the local host system log server (RE) and 200K for the external system log server.
  user@router# show interfaces sp-1/1/0 services-options

  system log {
      host 1.2.3.4 {
          services info;
      }
      message-rate-limit 1000;
  }

• Always system log to an external server to avoid loading the Routing Engine and specify system log class to restrict logging.
  • If you do not specify system log class, all log messages are allowed (subject to priority check and rate limiting).
  • When you specify system log class, only messages meeting the class criteria are retained.
  • Use the show services service-sets statistics system log detail command to check what is being dropped by unconfigured classes.
    user@router# show services service-set S-SET-1 system log

    host 1.2.3.4 {
            services info;
        class {
            session-logs open close;
            packet-logs;
            stateful-firewall-logs;
            alg-logs;
            nat-logs;
            ids-logs;

Best Practice: System log generation can be rule-based or event-based.

• Use rule- based system logging with care; it generates a log for every packet that enters the rule term, since rule-based logging is not subject to class or priority filtering.
• System log messages can be dropped only as a result of message rate limiting. Make sure you have set a realistic rate-limit that is unlikely to be exceeded.
• Use rule-based logging only for discarded traffic (a relatively small percentage of the traffic) or for troubleshooting. Since rule-based logging applies to all traffic that enters the PIC and creates a flow, logging can be excessive, resulting in reaching the configured induce rate limit with a consequent loss of needed logs.
  cli# show services stateful-firewall

  rule rule-sfw-accept {
      match-direction input-output;
      term term-sfw-accept {
          then {
              accept;
              system log;
          }
      }
  }
  rule rule-sfw-reject {
      match-direction input-output;
      term term-sfw-reject {
          then {
              reject;
              system log;
          }
      }
  }
   

  All rule match logs are enabled by their respective rules: ASP_COS_RULE_MATCH (class-of-service rules) ASP_COS_RULE_MATCH (class-of-service rules) ASP_IDS_RULE_MATCH (ids rules) ASP_NAT_RULE_MATCH (nat rule) ASP_SFW_RULE_ACCEPT (stateful firewall rules) ASP_SFW_RULE_DISCARD ASP_SFW_RULE_REJECT

• The usage of Redundant Service PIC (RSP) interfaces, allows the active services PIC to perform an immediated switchover to the secondary services PIC in case of major issues that require a services PIC reboot.
• This results in a minimal service impact for user traffic.
• There are two modes for redunancy: warm-standby (default) and hot-standby. Hot-standby provides 1:1 redundancy, while warm-standby provides 1:N redundancy. With both modes , there is no impact on the UDP forwarding.
• When the secondary services PIC is shared among multiple RSPs, only warm-standby is possible and the impact to traffic is limited to the time to load the appropriate configuration on the secondary PIC.
  user@router# show interfaces rsp0

  redundancy-options {
      primary sp-0/1/0;
      secondary sp-1/1/0;
      hot-standby;
  }

Best Practice: Configure the fragment-limit, the maximum number of fragments for a packet, and reassembly-timeout, the maximum wait for a missing fragment, after which all other fragments for the same packet are flushed out.

services-options {
    open-timeout 5;
    close-timeout 5;
    inactivity-timeout 30;
    tcp-tickles 4;
    fragment-limit 10;    
    reassembly-timeout 3; 
    cgn-pic;
} 

• Configure a firewall filter that accepts only the traffic meant to go to the services PIC on the output direction of the sp- interface. That is, accept only traffic identified in the NAT rule from option as received from the source-address that identifies the customer private network; discard and log all the rest.
• Allow only intended traffic to be serviced by the service set by configuring the stateful-firewall rules and NAT rules to translate only the traffic from the customer private source address ranges and intended applications. Although this does not prevent unintended traffic from being processed by the services PIC, it prevents the creation of flows, objects, and states that are not consistent with the expected traffic and are likely to be problematic.