External Logging. Bulk Port Allocation. Restrictions for Bulk Port Allocation

Transcription

1 External logging configures ex and logging of table entries, private bindings that are associated with a particular global IP, and to use Netflow to ex table entries., page 1 Session logging, page Syslog, page Reliable Log Transfer, page 0 Frequently Asked Questions (FAQs), page The creation and deletion of sessions lead to creation of logs. If logs of all such translations are stored, n a huge volume of data is created. This data is stored on a NetFlow or a Syslog collector. To reduce volume of this data, a block of s is allocated. If bulk allocation is enabled, as soon as a subscriber creates first session, a number of contiguous external s are allocated. To indicate this allocation, a bulk allocation message is created in log. Note The bulk allocation message is created only during first session. Rest of sessions use one of allocated s. Hence no logs are created for m. A bulk delete message is created in log when subscriber deletes all sessions that are using allocated s. Anor pool of s is allocated only if number of simultaneous sessions is more than N where N is size of bulkk allocation. The size of pool can be configured from CLI. Restrictions for The restrictions for bulk allocation are as follows: The value for size of bulk allocation can be 16, 3, 6, 18, 56, 51, 10, 08 and 096. For optimum results, it is recommended that you set this size to half of limit. 1

2 Session logging If size of bulk allocation is changed, n all current dynamic transactions will be deleted. Hence it is advisable to change bulk allocation size (only if necessary) during a maintenance window. The numbers below value of dynamic--range start value (which is 10 by default), are not allocated in bulk. The algorithm that is used to allocate a public to a user remains same. When bulk allocation is enabled, session logging is not available. When bulk allocation is enabled, translation record will not contain information about L protocol. Bulk allocation features is not suped in 6 stateful application. Session logging Syslog Restrictions for Syslog In general, translation entries contain information about private IP, and translated public IP and. However, re could be cases when destination IP (public IP ) and may also be needed. In such cases, session logging has to be enabled so that Netflow or Syslog translation records include se values as well. Perform following tasks to configure Syslog for table entries. The restrictions for syslog are as follows: Syslog is suped over UDP only. Syslog is suped in ASCII format only. You cannot log onto multiple collectors or relay agents. All messages comply to RFC 395 except for timestamp format. Timestamp is represented in a simpler way as explained later in this section. Syslog shall be suped for DS-Lite and as of now. Sup for 6 is not yet available. Syslog Message Format In general, syslog message is made up of header, structured data, and msg fields. However, in CGv6 applications, structured data is not used. Header The header fields shall be as per RFC 5. Fields shall be separated by ' ' (white space) as per RFC. The header consists of following fields:

3 Syslog Message Format Field Priority The priority value represents both facility and severity. Ensure that severity code is set to Informational for all messages at value 6. Version This field denotes version of specification of syslog protocol. In CGv6 application, version value is set to 1. Timestamp Hostname This field is needed to trace usage. The format is <year> <mon> <day> <hh:mm:ss>. Ensure that syslog collector converts time to local time whenever needed. Note The timestamp is always reed in GMT/UTC irrespective of time zone configured on device. This field is used to identify device that sent syslog message. While configuring syslog server, ensure that host name does not exceed 31 characters. The default value for host name is '-'. App name and PROC MSG These fields are not included. In ASCII format, '-' is included for se fields. This field identifies type of syslog message. In ASCII format, values for and DS Lite messages are and DS LITE respectively. Structured Data It is not used. 3

4 Syslog Message Format MSG This field consists of information about or DS Lite events. In a single UDP packet, re 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 and DS Lite). Note, that, depending on event, some of fields may not be applicable. For example, fields such as ' Source IPv6' are not applicable for all events. In such cases, inapplicable fields will be replaced by '-'. The syntax of MSG part is as follows: [Name <L> < Source IP> <Inside Name> < Source IPv6> < Translated Source IP> < Port> <Translated First Source Port> <Translated Last Source Port> <Destination IP> <Destination Port>] The descriptions of fields in this format are as follows: Field Name Select any one of values for Name from following based on event: UserbasedA: User-based assignment SessionbasedA: Session-based assignment SessionbasedAD: Session-based assignment with destination information Note: SessionbasedAD is used only if session logging is enabled. Also, session-logging and bulk allocation are mutually exclusive. UserbasedW: User-based withdrawal SessionbasedW: Session-based withdrawal SessionbasedWD: Session-based withdrawal with destination information Portblockrunout: Ports exhausted L Specifies identifier for trans layer protocol. Select any one of values for L from following: 1 for ICMP 6 for TCP 1 for UDP for GRE Source IP Specify private IPv.

5 Syslog Message Format Field Inside Name Source IPv6 Translated Source IP Port Translated First Source Port Translated Last Source Port Destination IP Destination Port The Inside vrf is essential to identify subscriber. Even though multiple subscribers connected to router might have same IP, y might be placed in different s. Hence name and original IP toger helps to identify a subscriber. Ensure that name is not more than 3 characters in length. Specifies IPv6 of tunnel in case of DS Lite. Specifies public IPv post translation. Specifies number before translation. This is not applicable for UserbasedA and UserbasedW events. Specifies first after translation. Specifies last after translation. This is applicable only for UserbasedA and UserbasedW events. Specifies destination IP recorded in syslogs for SessionbasedAD and SessionbasedWD events. Specifies destination recorded in syslogs for SessionbasedAD and SessionbasedWD events. Let us look at an example for user-based UDP translation mapping: [UserbasedA Broadband ] The description for this example is as follows: Value UserbasedA Broadband Name Source IP Inside name Translated Source IP Translated First Source Port Translated Last Source Port 5

6 Note The number of MSG fields in an UDP packet are determined by following factors: The space available in UDP packet depends on MTU. The translation events pertaining to MSG records in a given packet must have happened within a second (starting from time at which first event of that packet happened). The 6 stateful,, and DS Lite features sup Netflow for logging of translation records.. The Netflow uses binary format and hence requires software to parse and present translation records. However, for same reason, Netflow requires lesser space than Syslog to preserve logs. Considerations The considerations for NetFlow are as follows: NetFlow V9 is suped over UDP. You cannot log onto multiple collectors or relay agents. All messages comply to RFC 395. NetFlow Record Format As NetFlow V9 is based on templates, record format contains a packet header and templates or data records based on templates. Header All fields of header follow format prescribed in RFC 395. The field is composed of IPv of ServiceInfra interface (of card) and specific CPU-core that is generating record. The collector device can use combination of IPvAddress field plus Source field to associate an incoming NetFlow ex packet with a unique instance of NetFlow on a particular device. s for The templates are defined and used for logging various 6 stateful, and DS Lite events as follows. The templates may change in future software releases. Hence it is advised that Netflow collector software is designed to understand templates as distributed by router and accordingly parse records. Options s The translation entries consist of s which might be incomprehensible to a user. To simplify this process, CGv6 applications send options templates along with data templates. Options template is a special type of data record that indicates format of option data related to process of NetFlow. The options data consist of mapping between Ids and names. By parsing and using this data, NetFlow collectors can modify translation entries by adding names instead of s. 6

7 The value for of options template is 1 where as value of for data template is 0. For more information on Options template, see RFC395. s The events and corresponding template details are described in following table: IPFIX Nat translation create event 56 ingress 3 of Ingress egress 35 of Egress IPvAddress (pre-) 8 Source IPv postsourceipv Address 5 (outside) IPV TransPort (pre ) TransPort (translated) protocolidentifier 1 L protocol identifier

8 IPFIX Nat session create event - session based (with destination) 1 Enabled ingress egress 3 35 of Ingress of Egress IPvAddress 8 IPV postsourceipvaddress 5 (outside) IPV TransPort Source Port TransPort (translated) destinationipvaddress 1 Destination IP destinationtransport 11 Destination protocolidentifier 1 L protocol identifier 8

9 IPFIX Nat translation create event - user based 65 Enabled ingress egress 3 35 of Ingress of Egress IPvAddress 8 IPV postsourceipvaddress 5 (outside) IPV postportblockstart 361 Start of (translated) block postportblockend 36 End of block 9

10 IPFIX Nat translation delete event 5 ingress 3 of Ingress IPvAddress 8 IPV TransPort protocolidentifier 1 L protocol identifier Nat session delete event - session based (with destination) Enabled ingress IPvAddress 3 8 of Ingress IPV destinationipvaddress 1 Destination IP TransPort (translated) destinationtransport 11 Destination protocolidentifier 1 L protocol identifier 10

11 IPFIX Nat translation delete event - user based 66 ingress IPvAddress 3 8 of Ingress IPV postportblockstart 361 Start of (translated) block. Note this is not defined by yet. DS-Lite translation create event 6 ingress 3 of Ingress egress 35 of Egress 11

12 IPFIX Pre Source IPv Address 8 IPV. This field is valid only when sesion-logging is enabled. Else, it will be reed as 0 Pre Source IPv6 Address 16 IPv6 of B element (Tunnel ) postsourceipvaddress 5 (outside) IPV TransPort TransPort (translated) 1

13 IPFIX DS-Lite session create event - session based (with destination) 3 Enabled ingress egress 3 35 of Ingress of Egress IPvAddress 8 IPV IPv6Address 16 IPv6 of B element (Tunnel ) postsourceipvaddress 5 (outside) IPV TransPort TransPort (translated) destinationipvaddress 1 Destination IP destinationtransport 11 Destination protocolidentifier 1 13

14 IPFIX L protocol identifier DS-Lite translation create event - user based 69 Enabled ingress egress 3 35 of Ingress of Egress IPvAddress 8 IPV. This field is valid only when sesion-logging is enabled. Else, it will be reed as 0 IPv6Address 16 IPv6 of B element (Tunnel ) 1

15 IPFIX DS-Lite translation create event - user based postsourceipvaddress 5 (outside) IPV postportblockstart 361 Start of (translated) block postportblockend 36 End of block 15

16 IPFIX DS-Lite translation delete event 0 ingress 3 of Ingress IPvAddress IPV IPv6Address IPv6 of B element (Tunnel ) TransPort protocolidentifier L protocol identifier 16

17 IPFIX DS-Lite session delete event - session based (with destination) ingress IPvAddress 3 8 of Ingress IPV IPv6Address 16 IPv6 of B element (Tunnel ) TransPort protocolidentifier 1 L protocol identifier 1

18 IPFIX DS-Lite translation delete event - user based 0 ingress IPvAddress 3 8 ingres IPV IPv6Address 16 IPv6 of B element (Tunnel ) postportblockstart 361 Start of (translated) block 6 stateful translation create event 58 IPv6Address postsourceipvaddress 5 16 Source IPv6 (outside) IPV TransPort TransPort (translated) protocolidentifier 1 L protocol identifier 18

19 IPFIX 6 stateful session create event - session based (with destination) 60 Enabled IPv6Address postsourceipvaddress 5 16 Source IPv6 (pre translation) (outside) IPV destinationipv6address 8 16 Destination IPv6 (pre translation) translation Destination IP 6 Destination IPv (post translation) TransPort TransPort (translated) destinationtransport 11 Destination protocolidentifier 1 L protocol identifier 19

20 Reliable Log Transfer IPFIX 6 translation delete event 59 IPv6Address 16 IPv6 of B element (Tunnel ) TransPort protocolidentifier 1 L protocol identifier 6 stateful session delete event - session based (with destination) 61 Enabled IPv6Address destinationipv6address IPv6 of B element (Tunnel ) Destination IPv6 (pre translation) TransPort destinationtransport 11 Destination protocolidentifier 1 L protocol identifier Reliable Log Transfer The VSM Line Cards sup CGN application with feature. feature performs IPv operations. The CGN applications based on server configuration generates NetFlow and Syslog records that 0

21 Reliable Log Transfer Configuration: Examples contain critical information. If an external NetFlow server is configured for storage and retrieval of information, information is transferred to server using UDP connection. The CGN application VM running on VSM also sups transfer of records to external NetFlow servers using TCP. This provides reliable log transfer. Use protocol command to define protocol to be used for transfer. Limitations Netflow and syslog records may be lost during any reload of VSM or restart of IOS XR VM or process. A maximum of two NetFlow or Syslog servers are suped. Server IP along with number defines one server. Same TCP server can be configured on any number of s and is considered as one TCP server. Loss of TCP connection may result in loss of NetFlow records. Bulk allocation needs to be enabled with a minimum allocation value of 56 to prevent loss of records, when Syslog and Netflow records are sent using TCP protocol. Reliable Log Transfer Configuration: Examples Configure NetFlow records' trans using TCP protocol when TCP server is in default global instance: service cgn cgn1 service-location preferred-active 0/3/CPU0 service-type nat nat1 inside-vrf insidevrf1 map outside-vrf outsidevrf1 outsideserviceapp ServiceApp -pool / external-logging netflow version 9 server protocol tcp Configure NetFlow records' trans using TCP protocol when TCP server is in an non-default instance: service cgn cgn1 service-location preferred-active 0/3/CPU0 service-type nat nat1 inside-vrf insidevrf1 map outside-vrf outsidevrf1 outsideserviceapp ServiceApp -pool / external-logging netflow version 9 server protocol tcp vrf netflow-srv-vrf Disabling NetFlow records' trans: service cgn cgn1 service-type nat nat1 inside-vrf insidevrf1 no external-logging netflow version 9 Configure Syslog records' trans using TCP protocol when TCP server is in default global instance: service cgn cgn1 service-location preferred-active 0/3/CPU0 service-type nat nat1 inside-vrf insidevrf1 1

22 Frequently Asked Questions (FAQs) map outside-vrf outsidevrf1 outsideserviceapp ServiceApp -pool / external-logging syslog server protocol tcp Configure Syslog records' trans using TCP protocol when TCP server is in an non-default instance: service cgn cgn1 service-location preferred-active 0/3/CPU0 service-type nat nat1 inside-vrf insidevrf1 map outside-vrf outsidevrf1 outsideserviceapp ServiceApp -pool / external-logging syslog server protocol tcp vrf syslog-srv-vrf Disabling Syslog records' trans: service cgn cgn1 service-type nat nat1 inside-vrf insidevrf1 no external-logging syslog Frequently Asked Questions (FAQs) This section provides answers to following frequently asked questions on external logging. Q: How to trace a subscriber by using logs? A: In order to trace a subscriber, you should know public IP (post ), post, protocol, and time of usage. With se parameters, steps to trace a subscriber are as follows: 1 Search for create event that has matching public IP, post Source IP (postsourceipvaddress) and protocol, egress /Name and time of usage. Ensure that time of create-event is same or earlier than time of usage reed. You may not find protocol entry or exact post in logs if bulk allocation is enabled. In such cases, find create-event whose Port Block Start and Port Block End values include post. The Pre IP along with corresponding ingress /Name will identify subscriber. The corresponding delete record may be found optionally to confirm that subscriber was using specified public IP and during time of reed usage. Q: The Netflow records provide s for ingress and egress s. How will I know names? A: The following are two ways to find name from. 1 Use command show rsi vrf-id <vrf-id> on Router console to find - to -NAME associations. The CGv6 applications periodically send out option templates containing - to -NAME mapping. The Netflow collector software presents information with -Names rar than s. Q: Does time format in Syslog or Netflow account for Day light saving?

23 Frequently Asked Questions (FAQs) A: The Syslog and Netflow formats re time corresponding to GMT/UTC. The Netflow header contains time in seconds that elapsed since EPOCH whereas Syslog header contains time in human readable formats. In both cases, day light saving is not accounted. The Netflow/Syslog collectors have to make that adjustments if needed. Q: Since Netflow and Syslog use UDP, how can we know if a packet containing translation record was lost? A: The Netflow header contains a field called Sequence Number. This number is indicates count of packet coming from each Source. The Netflow collector traces Seqence Number pertaining to each unique Source. The sequence numbers should be increased by one for each packet sent out by Source. If collector ever receives two successive packets with same Source, 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 use of session-logging? A: Session logging includes destination IP and number as well. Though this information is not directly useful in tracing subscriber, in some cases, this information may be useful or may be mandated by legal authorities. There are cases where, legal authorities may not have post '', however may know destination IP (and optionally destination, such as IP and of an server). In absence of post information, a list of subscribers who used specified public IP during that time may have to be pruned furr based on destination IP and information. Q: How does bulk allocation reduce data volume of translation logs? A: With bulk allocation, subscribers are allocated a range of contiguous s on a public IP. Quite often, a subscriber will need more s than just one. Especially AJAX based web pages and or web applications simultaneously open several s. In such cases, pre-allocated s are used and only one log entry is made that specifies range of s allocated to user. Hence, bulk allocation significantly reduces log data volume and hence demand on storage space needed for translation logs. Q: What else can be done to reduce log data volume? A: Predefined is an option that can be used to eliminate logging altoger. The Predefined translates private IP to public IP and a certain range by using an algorithm. Hence re is no need to keep track of entries. 3

24 Frequently Asked Questions (FAQs)