Cisco IOS XR Carrier Grade NAT Configuration Guide for the Cisco CRS Router, Release 5.1.x
Bias-Free Language
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
- Updated:
- January 31, 2018
Chapter: External Logging
External Logging
Many a times, the service providers are asked to identify subscribers based on data such as public source IP address, port, Layer 4 protocol, and time of usage. In the deployments involving NAPT or NAT, such identification is possible only if NAT entries are preserved. Only by searching and parsing these NAT entries, it is possible to identify the subscriber (private IP address) based on the parameters such as post NAT Source IP Address (public IP address), post NAT source port, protocol and the time of usage.
To make the identification process possible, the external logging is required. The translation information has to be exported to external collectors. The CGv6 applications export translation information in either Netflow or Syslog formats.
This chapter provides format details for these logs such as messages, message types and other important information. The chapter aslo describes few configuration options that affect these logs.
Bulk Port Allocation
The creation and deletion of NAT translations lead to creation of logs. If logs of all such translations are stored, then a huge volume of data is created. This data is stored on a NetFlow or a Syslog collector. To reduce the volume of this data, a block of ports is allocated. If bulk port allocation is enabled, as soon as a subscriber creates the first session, a number of contiguous external ports are allocated. To indicate this allocation, a bulk allocation message is created in the log.
Note
The bulk allocation message is created only during the first session. Rest of the sessions use one of the allocated ports. Hence no logs are created for them.
A bulk delete message is created in the log when the subscriber deletes all the sessions that are using the allocated ports.
Another pool of ports is allocated only if the number of simultaneous sessions is more than N where N is the size of the bulkk allocation. The size of the pool can be configured from the CLI.
Restrictions for Bulk Port Allocation
The restrictions for bulk port allocation are as follows:
- The value for the size of bulk allocation can be 16, 32, 64, 128, 256, 512, 1024, 2048 and 4096. For optimum results, it is recommended that you set this size to half of the port limit.
- If the size of bulk allocation is changed, then all the current dynamic translations will be deleted. Hence it is advisable to change the bulk port allocation size (only if necessary) during a maintenance window.
- The port numbers below the value of dynamic-port-range start value (which is 1024 by default), are not allocated in bulk.
- The algorithm that is used to allocate a public address to a user remains the same.
- When bulk allocation is enabled, session logging is not available.
- When bulk allocation is enabled, the translation record will not contain information about L4 protocol.
- Bulk port allocation features is not supported in NAT64 stateful application. Bulk port allocation is supported in NAT44 and DS Lite applications
Session logging
In general, NAT translation entries contain information about private source IP, port and translated public IP and port. However, there could be cases when the destination IP address and port may also be needed. In such cases, session logging has to be enabled so that Netflow or Syslog translation records include these values as well.
Note ● Session logging cannot be enabled if bulk port allocation is enabled and vice-versa.
Predefined NAT
As discussed in a previous chapter, NAT44 supports predefined mode where translations are done in accordance with the algorithm. To trace a subscriber, the log is not required for this mode.
Syslog
DS Lite and NAT44 features support Syslog as an alternative to Netflow. Syslog uses ASCII format, which can be read by users. However, the log data volume is higher in Syslog than Netflow.
Restrictions for Syslog
The restrictions for syslog are as follows:
- Syslog is supported over UDP only.
- Syslog is supported in ASCII format only.
- You cannot log onto multiple collectors or relay agents.
- All the messages comply to RFC 5425 except for the timestamp format. Timestamp is represented in a simpler way as explained later in this section.
- Syslog shall be supported for DS-Lite and NAT444 as of now. Support for NAT64 is not yet available.
- The Syslog collector shall be assumed to be in the default VRF. If not, appropriate ACLs have to configured and applied on to Service Infra interface to divert the Syslog packets from default VRF to specific VRF through which the collector can be reached.
Syslog Message Format
In general, the syslog message is made up of header, structured data, and msg fields. However, in the CGv6 applications, the structured data is not used.
Header
The header fields shall be as per the RFC 5424. Fields shall be separated by ' ' (white space) as per the RFC.
The header consists of the following fields:
Structured Data
MSG
This field consists of the information about the NAT44 or DS Lite events. In a single UDP packet, there could be one or more MSG fields each enclosed in [] brackets. The MSG field has many sub fields as it has a common structure across different records (for both NAT44 and DS Lite). Note, that, depending on the event, some of the fields may not be applicable. For example, fields such as 'Original Source IPv6' address are not applicable for all NAT44 events. In such cases, the inapplicable fields will be replaced by '-'.
The syntax of the MSG part is as follows:
[EventName <L4> <Original Source IP> <Inside VRF Name> <Original Source IPv6> < Translated Source IP> <Original Port> <Translated First Source Port> <Translated Last Source Port> <Destination IP> <Destination Port>]
The descriptions of the fields in this format are as follows:
Let us look at an example for NAT444 user-based UDP port translation mapping:
The description for this example is as follows:
|
|
|
|---|---|
Note The number of MSG fields in an UDP packet are determined by the following factors:
Netflow v9 Support
The NAT64 stateful, NAT44, and DS Lite features support Netflow for logging of the translation records.. The Netflow uses binary format and hence requires software to parse and present the translation records. However, for the same reason, Netflow requires lesser space than Syslog to preserve the logs
Considerations
The considerations for NetFlow are as follows:
- NetFlow V9 is supported over UDP.
- You cannot log onto multiple collectors or relay agents.
- All the messages comply to RFC 3954.
- It is assumed that the NetFlow collector is in the default VRF. Otherwise, the corresponding ACLs have to be configured and applied to the ServiceInfra interface to divert the NetFlow packets from the default VRF to the corresponding VRF in which the collector is present.
NetFlow Record Format
As NetFlow V9 is based on templates, the record format contains a packet header and templates or data records based on templates.
Header
All the fields of the header follow the format prescribed in RFC 3954. The source ID field is composed of the IPv4 address of ServiceInfra interface (of the card) and specific CPU-core that is generating the record. The collector device can use the combination of the Source IP address of the UDP packet plus the Source ID field to associate an incoming NetFlow export packet with a unique instance of NetFlow on a particular device.
Templates
The templates are defined and used for logging various NAT64 stateful, NAT44 and DS Lite events as follows. The templates may change in future software releases. Hence it is advised that the Netflow collector software is designed to understand the templates as distributed by the router and accordingly parse the records.
Options Templates
The translation entries consist of VRF IDs. The VRF IDs are numbers identifying a VRF configured on the router. For the users looking at the translation records, these numbers are difficult to comprehend. To simplify this process, the CGv6 applications send the options templates along with the data templates.
Options template is a special type of data record that indicates the format of option data related to the process of NetFlow. The options data consist of the mapping between VRF Ids and VRF names. By parsing and using this data, the NetFlow collectors can modify the translation entries by adding VRF names instead of VRF IDs.
The value for the Template ID of options template is 1 where as the value of the Template ID for data template is 0. For more information on Options template, see RFC3954.
Events
The events and the corresponding template details are described in the following table:
Frequently Asked Questions
This section provides answers to the following frequently asked questions on external logging.
- How to trace a subscriber by using the NAT logs?
- The Netflow records provide VRF IDs for ingress and egress VRFs. How will I know the VRF names?
- Does the time format in Syslog or Netflow account for Day light saving?
- Since the Netflow and Syslog use UDP, how can we know if a packet containing translation record was lost?
- What is the use of session-logging?
- How does the bulk port allocation reduce data volume of translation logs?
- What else can be done to reduce log data volume?
Q. How to trace a subscriber by using the NAT logs?
In order to trace a subscriber, you should know the public source IP address (post NAT source address), post NAT source port, protocol, and the time of usage. With these parameters, the steps to trace a subscriber are as follows:
a. Search for the create event that has the matching public IP address, post NAT Source IP address (postNATSourceIPv4Address) and protocol, egress VRF ID/Name and the time of the usage. Ensure that the time of the create-event is the same or earlier than the time of usage reported. You may not find the protocol entry or the exact post NAT source port in the logs if bulk allocation is enabled. In such cases, find the create-event whose Post NAT Port Block Start and Post NAT Port Block End values include the post NAT source port. The Pre NAT source IP address along with the corresponding ingress VRF ID/Name will identify the subscriber.
b. The corresponding delete record may be found optionally to confirm that the subscriber was using the specified public IP and port during the time of the reported usage.
Q. The Netflow records provide VRF IDs for ingress and egress VRFs. How will I know the VRF names?
The following are the two ways to find the VRF name from the VRF ID.
a. Use the command show rsi vrf-id <vrf-id> on the Router console to find VRF-ID to VRF-NAME associations.
b. The CGv6 applications periodically send out option templates containing the VRF-ID to VRF-NAME mapping. The Netflow collector software presents the information with VRF-Names rather than VRF IDs.
Q. Does the time format in Syslog or Netflow account for Day light saving?
The Syslog and Netflow formats report time corresponding to GMT/UTC. The Netflow header contains the time in seconds that elapsed since EPOCH whereas the Syslog header contains time in human readable formats. In both cases, the day light saving is not accounted. The Netflow/Syslog collectors have to make that adjustments if needed.
Q. Since the Netflow and Syslog use UDP, how can we know if a packet containing translation record was lost?
The Netflow header contains a field called Sequence Number. This number is indicates the count of the packet coming from each Source ID. The Netflow collector traces the Seqence Number pertaining to each unique Source ID. The sequence numbers should be increased by one for each packet sent out by the Source. If the collector ever receives two successive packets with the same Source ID, but with a Sequence number difference of more than 1, it indicate a packet loss.
However, currently, no such mechanism exists for Syslog.
Q. What is the use of session-logging?
Session logging includes destination IP and port number as well. Though this information is not directly useful in tracing the subscriber, in some cases, this information may be useful or may be mandated by the legal authorities. There are cases where, legal authorities may not have the post NAT source 'port', however may know the destination IP address (and optionally destination port, such as IP address and port of an e-mail server). In the absence of post NAT source port information, a list of subscribers who used the specified public IP during that time may have to be pruned further based on the destination IP and port information.
Q. How does the bulk port allocation reduce data volume of translation logs?
With bulk port allocation, subscribers are allocated a range of contiguous ports on a public IP. Quite often, a subscriber will need more ports than just one. Especially AJAX based web pages and other web applications simultaneously open several ports. In such cases, pre-allocated ports are used and only one log entry is made that specifies the range of ports allocated to the user. Hence, bulk port allocation significantly reduces log data volume and hence the demand on storage space needed for the translation logs.
Q. What else can be done to reduce log data volume?
Predefined NAT is an option that can be used to eliminate the logging altogether. The Predefined NAT translates private IP address to public IP address and a certain port range by using an algorithm. Hence there is no need to keep track of NAT entries.
Feedback