9.8. Logging¶
Sometimes, in order to meet the requirements of the government agencies, it is necessary to monitor all subscriber connections passing through NAT. For these purposes, it is possible to configure connections logging on external servers. This section describes various logging parameters and commands available to configure them.
Log Types¶
There are several types of messages that could be sent to external servers:
- Address mapping (
address-map
) Log creation and deletion events of the mappings between private and public IP addresses. Ports and destination addresses are not logged. This type of message is suitable if you’re using NAT type of pools and you do not need to store information about destination addresses.
- Port mapping (
port-map
) Log creation and deletion events of the mappings between private and public IP addresses and ports. This type of message is suitable if you’re using NAPT type of pools and you do not need to store information about destination addresses.
- Session (
session
) Log the subscriber session start and end events. Private addresses, public addresses, and ports, as well as destination addresses are logged. This type of message is the most detailed.
- Port blocks (
port-block
) Log the port blocks allocation and release events. Destination addresses are not logged. This type of messages is available only when using pools of the Port Block Allocation type.
Interim NAT logs can be enabled for this type of messages.
The specific message format depends on the logging protocol and will be described below.
Logging Protocols¶
Syslog¶
When using this protocol, messages are sent to an external Syslog server in accordance with RFC 5424.
Packet header¶
The header format is described in RFC 5424#section-6.
Header fields are usually automatically processed by the Syslog server and provided in a readable format.
PRI
This field combines the
Facility
andSeverity
parameters of the message. By default, messages are sent withFacility = LOCAL0
andSeverity = Informational
. It is possible to change both parameters depending on the server and the logging type.VERSION
In this field,
1
is always sent.TIMESTAMP
By default, messages are sent without timestamps, meaning that the
-
symbol is sent in this field. There is an option to enable timestamps.HOSTNAME
By default, messages are sent without the system name, meaning that the
-
symbol is sent in this field. There is an option to enable system name.APP-NAME
NAT
is always sent in this field.PROCID
-
is always sent in this field.MSGID
-
is always sent in this field.STRUCTURED-DATA
-
is always sent in this field.
Message format¶
Messages are sent in the MSG
field. The Syslog server provides these messages “as is”. The message format depends on the logging type used.
Address mapping display format:
EVENT VRF ID INT IP EXT IPEVENT
-A
when created,D
when deleted.VRF ID
- theID
field specifies the ID of the VRF that processes the subscriber’s traffic.INT IP
- theIP
field specifies subscriber’s private IP address.EXT IP
- theIP
field specifies subscriber’s public IP address.Example:
A VRF 0 INT 10.0.0.1 EXT 100.64.0.1
Port mapping display format:
EVENT VRF ID PROTO INT IP:PORT EXT IP:PORTEVENT
-A
when created,D
when deleted.VRF ID
- theID
field specifies the ID of the VRF that processes the subscriber’s traffic.PROTO
- the protocol number in accordance with the IANA registry.INT IP:PORT
- theIP:PORT
field specifies subscriber’s private IP address and port.EXT IP:PORT
- theIP:PORT
field specifies subscriber’s public IP address and port.Example:
A VRF 0 6 INT 10.0.0.1:57938 EXT 100.64.0.1:28475
Sessions format:
EVENT VRF ID PROTO INT IP:PORT EXT IP:PORT DST IP:PORT DIR TYPEEVENT
-A
when created,D
when deleted.VRF ID
- theID
field specifies the ID of the VRF that processes the subscriber’s traffic.PROTO
- the protocol number in accordance with the IANA registry.INT IP:PORT
- theIP:PORT
field specifies the subscriber’s private IP address and port.EXT IP:PORT
- theIP:PORT
field specifies the subscriber’s public IP address and port.DST IP:PORT
- theIP:PORT
field` specifies the destination IP address and port.DIR TYPE
- theTYPE
field specifiesOUT
for outbound sessions andIN
for inbound sessions.Example:
A VRF 0 6 INT 10.0.0.1:57938 EXT 100.64.0.1:28475 DST 185.165.123.206:443 DIR OUT
Port blocks format:
EVENT VRF ID INT IP EXT IP:START-ENDEVENT
-A
when created,D
when deleted.VRF ID
- theID
field specifies the ID of the VRF that processes the subscriber’s traffic.INT IP
- theIP
field specifies subscriber’s private IP address.EXT IP:START-END
- theIP:START-END
field specifies subscriber’s public IP address and the port block allocated to it.Example:
A VRF 0 INT 10.0.0.1 EXT 100.64.0.1:1024-1535
NetFlow¶
When using this protocol, messages are sent to an external NetFlow collector in accordance with RFC 3954.
Packet header¶
The header format is described in RFC 3954#section-5.
All fields except Source ID
are standard. The Source ID
field is used to separate different message flows from the same source. Each processor core sends its own message flow, so the Source ID
field specifies the number of the core that sent a certain packet, so that the receiver can divide the received packets into different flows.
Message format¶
The message format depends on the logging type used.
Address mapping display format:
Field Name |
Size (bits) |
IANA ID |
Description |
---|---|---|---|
timeStamp |
64 |
323 |
System Time when the event occurred |
sourceIPv4Address |
32 |
8 |
Source IPv4 Address |
postNATSourceIPv4Address |
32 |
225 |
Translated Source IPv4 Address |
ingressVRFID |
32 |
234 |
VRF ID in case of overlapping networks |
natEvent |
8 |
230 |
Type of Event |
Port mapping display format:
Field Name |
Size (bits) |
IANA ID |
Description |
---|---|---|---|
timeStamp |
64 |
323 |
System Time when the event occurred |
sourceIPv4Address |
32 |
8 |
Source IPv4 Address |
postNATSourceIPv4Address |
32 |
225 |
Translated Source IPv4 Address |
protocolIdentifier |
8 |
4 |
Transport protocol |
sourceTransportPort |
16 |
7 |
Source Port |
postNAPTSourceTransportPort |
16 |
227 |
Translated Source port |
ingressVRFID |
32 |
234 |
VRF ID in case of overlapping networks |
natEvent |
8 |
230 |
Type of Event |
Sessions format:
Field Name |
Size (bits) |
IANA ID |
Description |
---|---|---|---|
timeStamp |
64 |
323 |
System Time when the event occurred |
sourceIPv4Address |
32 |
8 |
Source IPv4 Address |
postNATSourceIPv4Address |
32 |
225 |
Translated Source IPv4 Address |
protocolIdentifier |
8 |
4 |
Transport protocol |
sourceTransportPort |
16 |
7 |
Source Port |
postNAPTSourceTransportPort |
16 |
227 |
Translated Source port |
destinationIPv4Address |
32 |
12 |
Destination IPv4 Address |
postNATDestinationIPv4Address |
32 |
226 |
Translated IPv4 destination address |
destinationTransportPort |
16 |
11 |
Destination port |
postNAPTDestinationTransportPort |
16 |
228 |
Translated Destination port |
natOriginatingAddressRealm |
8 |
229 |
Address Realm |
ingressVRFID |
32 |
234 |
VRF ID in case of overlapping networks |
natEvent |
8 |
230 |
Type of Event |
Port blocks format:
Field Name |
Size (bits) |
IANA ID |
Description |
---|---|---|---|
timeStamp |
64 |
323 |
System Time when the event occurred |
sourceIPv4Address |
32 |
8 |
Source IPv4 Address |
postNATSourceIPv4Address |
32 |
225 |
Translated Source IPv4 Address |
portRangeStart |
16 |
361 |
Allocated Port Block start |
portRangeEnd |
16 |
362 |
Allocated Port Block end |
ingressVRFID |
32 |
234 |
VRF ID in case of overlapping networks |
natEvent |
8 |
230 |
Type of Event |
IPFIX¶
When using this protocol, messages are sent to an external IPFIX collector in accordance with RFC 7011.
Packet header¶
The header format is described in RFC 7011#section-3.
All fields except Observation Domain ID
are standard. The Observation Domain ID
field is used to separate different message flows from the same source. Each processor core sends its own message flow, so the Observation Domain ID
field specifies the number of the core that sent a certain packet, so that the receiver can divide the received packets into different flows.
Message format¶
The message format is identical to the NetFlow message format.
RADIUS¶
When using this protocol, messages are sent to an external RADIUS server in accordance with RFC 2865 and RFC 2866.
Packet header¶
The header format is described in RFC 2865#section-3.
To send information about the subscriber sessions, Accounting-Request
messages are used, so the Code
header field is set to the value 4
. The rest of the header fields are standard.
Warning
This is not a full-fledged implementation of the RADIUS protocol. NAT only uses the Accounting-Request
message format to send messages to an external server. NAT does not expect to receive Accounting-Response
from the RADIUS server.
Message format¶
To correctly process messages on the RADIUS server, you need to download the RADIUS dictionary
. The following description uses the internal identifiers described in this dictionary.
- Address mapping display format:
Not supported.
Port mapping display format:
Type |
Length (bytes) |
Description |
---|---|---|
Acct-Status-Type |
4 |
1 for Start, 2 for Stop |
Acct-Session-Id |
4 |
Hash value for all message fields |
NAS-Identifier |
6 |
“vCGNAT” |
Event-Timestamp |
4 |
System Time when the event occurred |
NFWare-vCGNAT-Protocol |
4 |
Transport protocol |
NFWare-vCGNAT-Action |
4 |
3 for Add, 4 for Delete |
NFWare-vCGNAT-Inside-Addr |
4 |
Source IPv4 Address |
NFWare-vCGNAT-Inside-Port |
2 |
Source Port |
NFWare-vCGNAT-Nat-Addr |
4 |
Translated Source IPv4 Address |
NFWare-vCGNAT-Nat-Port |
2 |
Translated Source port |
NFWare-vCGNAT-VRF |
4 |
VRF ID in case of overlapping networks |
NFWare-vCGNAT-Direction |
4 |
Direction |
Sessions format:
Type |
Length (bytes) |
Description |
---|---|---|
Acct-Status-Type |
4 |
1 for Start, 2 for Stop |
Acct-Session-Id |
4 |
Hash value for all message fields |
NAS-Identifier |
6 |
“vCGNAT” |
Event-Timestamp |
4 |
System Time when the event occurred |
NFWare-vCGNAT-Protocol |
4 |
Transport protocol |
NFWare-vCGNAT-Action |
4 |
3 for Add, 4 for Delete |
NFWare-vCGNAT-Inside-Addr |
4 |
Source IPv4 Address |
NFWare-vCGNAT-Inside-Port |
2 |
Source Port |
NFWare-vCGNAT-Nat-Addr |
4 |
Translated Source IPv4 Address |
NFWare-vCGNAT-Nat-Port |
2 |
Translated Source port |
NFWare-vCGNAT-Dest-Addr |
4 |
Destination IPv4 Address |
NFWare-vCGNAT-Dest-Port |
2 |
Destination port |
NFWare-vCGNAT-VRF |
4 |
VRF ID in case of overlapping networks |
NFWare-vCGNAT-Direction |
4 |
Direction |
Port blocks format:
Type |
Length (bytes) |
Description |
---|---|---|
Acct-Status-Type |
4 |
1 for Start, 2 for Stop |
Acct-Session-Id |
4 |
Hash value for all message fields |
NAS-Identifier |
6 |
“vCGNAT” |
Event-Timestamp |
4 |
System Time when the event occurred |
NFWare-vCGNAT-Protocol |
4 |
Transport protocol |
NFWare-vCGNAT-Action |
4 |
3 for Add, 4 for Delete |
NFWare-vCGNAT-Inside-Addr |
4 |
Source IPv4 Address |
NFWare-vCGNAT-Nat-Addr |
4 |
Translated Source IPv4 Address |
NFWare-vCGNAT-NAT-Port-Start |
2 |
Allocated Port Block start |
NFWare-vCGNAT-NAT-Port-End |
2 |
Allocated Port Block end |
NFWare-vCGNAT-VRF |
4 |
VRF ID in case of overlapping networks |
NFWare-vCGNAT-Direction |
4 |
Direction |
Configuration¶
To begin logging connections information to external servers, it is necessary to enable the required types of logs, configure at least one server, and enable logging globally.
You can configure several logging servers at the same time, they can use the same protocol or different ones. Messages will be duplicated to all configured servers.
When adding a server, it is possible to configure the sender’s IP address and a VRF that will be used to route logs packets. By default, packets are routed within the default VRF, and the sender address is the address of the interface from which the packets are sent.
- nat log type <address-map|port-map|session|port-block> enable¶
Enable the appropriate logging type.
- no nat log type <address-map|port-map|session|port-block> enable¶
Disable the appropriate logging type.
- nat log server (0-62) type <syslog|netflow|ipfix|radius> ip A.B.C.D port (1-65535) [{vrf NAME|source-ip A.B.C.D}]¶
Add a logging server. If you already have a server configured with a specific identifier (parameter
(0-62)
), then if you re-use the same identifier, the previous settings will be overwritten.
- no nat log server (0-62)¶
Delete a log server.
- nat log server (0-62) type syslog hostname NAME¶
Add the system name when sending messages via the Syslog protocol.
- nat log server (0-62) type syslog timestamp enable¶
Add a timestamp when sending messages via the Syslog protocol.
- nat log server (0-62) type syslog log-type <address-map|port-map|session|port-block> facility FACILITY¶
Set the
Facility
parameter of thePRI
field when sending messages via the Syslog protocol.
- nat log server (0-62) type syslog log-type <address-map|port-map|session|port-block> level LEVEL¶
Set the
Severity
parameter of thePRI
field when sending messages via the Syslog protocol.
- nat log server (0-62) type <netflow|ipfix> template-resend-pkts (1-1440)¶
When sending logs using the NetFlow and IPFIX protocols, it is necessary to periodically refresh the template with the format of the messages being sent. This command allows you to set the frequency of the template refresh in the number of packets. By default, the template is refreshed in every 20th packet.
- nat log server (0-62) type <netflow|ipfix> template-resend-timeout (1-1440)¶
When sending logs using the NetFlow or IPFIX protocols, it is necessary to periodically refresh the template with the format of the messages being sent. This command allows you to set the frequency of the template refresh in minutes. By default, the template is refreshed every 10 minutes.
- nat log server (0-62) type radius secret SECRET¶
Set the
Shared Secret
when sending messages via the RADIUS protocol.
- nat log enable¶
Enable logging.
Show Commands¶
- show nat log counters¶
- clear nat log counters¶
Display the NAT log counters.
Counter
Description
Generated
The number of the generated log messages
Sent
The number of the log messages that have been already sent (if there are several log servers, then sent = generated * nb_log_servers)
No Memory
The number of the log messages that were not queued for processing
No Server
The number of the log messages that could not be sent because there is no configured log server
No VRF
The number of the log messages could not be sent because the vrf, to which the log server should be bound, is missing
No Packet
The number of the log messages could not be sent because of failure to allocate a packet from the packet pool to write nat log messages to it
- show nat log queues¶
Display NAT log queues. The output is as follows:
nfware# sh nat log queues NAT-log task id 0 (socket 0): NAT-log ring-size: 16384 Free-space Processed Loading Ring id 0 : 16384 0 0 % Ring id 1 : 16384 0 0 %
Name
Description
NAT-log task id
NAT-log task id is bound to cores, and the core is bound to a socket. The number of tasks is configured in the platform settings
NAT-log ring-size: 16384
The maximum size of the messages queue that is waiting to be sent to the log server
Ring id 0
Control plane queue
Ring id 1
Data plane queue
Processed
The total number of the processed log messages
- show nat log servers¶
Display all log servers and their configuration. There are three states the server could have:
State
Description
Active
The log server is configured, and nat log messages are sent to it
Inactive
If you configured the log server with VRF and there is no such VRF
Not Configure
IP address and port are not configured
NAT Log Balancing¶
The NAT log balancing mechanism divides the entire logging server set into groups. For each NAT entry (for example, creating or deleting a session), exactly one server is allocated from each group, and the entry is duplicated on all selected servers. The choice of one or another server in the group depends on the IP source address. All actions of one user are logged on the same subset of servers.
Note
Groups consisting of a single server are not explicitly identified as a group. They are single servers and are configured in the same way as mentioned above. However, it should be considered that the balancing mechanism is not applied to them, and the logs of all users will be duplicated on them.
- nat log group N¶
Create a group of servers where N is the group number. Up to eight server groups are allowed, numbered 1, 2, and 3. Each group can have up to 24 servers, while the numbering of servers in different groups is independent. The numbering of single servers is independent of each of the groups. The total number of servers, including single servers and servers in all groups, can be at most 63 because of the synchronization mechanism between control and worker threads. Inside the group, you can add servers and set their parameters using any of the existing commands of the form.
- no nat group N¶
Delete an entire server group. If you delete all servers in a group, the group itself will also be deleted.