Nokia BNG NAT logging support about nfdump HOT 11 CLOSED

Another funny fact: records does not explicitly says if they are ADD ou DEL event. [1]

One has to imply that by the presence (or absence) of flowStartMilliseconds and flowEndMilliseconds.

For ADD events, flow records comes with flowStartMilliseconds field while for DEL events, flowEndMilliseconds is available.

Nokia being Nokia.

[1] https://infocenter.nokia.com/public/7750SR227R1A/topic/com.nokia.Multiservice_ISA_and_ESA_Guide/template_format-d1085e12219.html

from nfdump.

The Nokia nat records are now decoded in the master repo.
See also nfconf.dist for a possible output format an nfdump(1) for the new definitions:

nfdump -r tmp -o 'fmt:%ts %te %flid %pr %sap -> %dap %isid %osid %nats'

The Nokia elements are listed in raw, fmt and json

As Nokia does not send NAT events for ADD/DELETE and uses different templates for each, there are no NAT event records available. To add them as a best guess of what was sent is too risky and may lead to unwanted results with data from other exporters. Therefore it is left to the user to evaluate correctly the appropriate events.

from nfdump.

@gabrielmocan I added another file from the vendor

• for ADD and DEl action Nokia had two different template set, snd page in attached document
• extract only IP address from type 93 proprietary field (source IP stored with LSN session number LSNxxx@ipaddress)
  IPFIX-NAT_Logging V1.pptx

For my use case type 93 field extraction enough

from nfdump.

@anetrjuns this seems fine to me.

First entry is the ADD event, second entry is the DEL event.

You'll have to imply this logic wherever you're going to use these information.

from nfdump.

Thanks for the sample! I will check.

from nfdump.

Nokia being Nokia.

They're putting the pre-NAT IP address in a proprietary field...

from nfdump.

So it's about the 3 missing and Nokia specific elements? @anetrjuns, @gabrielmocan - as of NAT logging - does that work for you? Honestly, I don't see much NAT stuff thee?

from nfdump.

@phaag that's Nokia way of doing things. They always just ignore standards, most likely to sell their proprietary monitoring stuff.

But well, in regards to NAT logging, we would need 2 things:

• Imply if the flow record is a ADD or DEL event (based on the logic that I described in my previous message) to fill natEvent field;
• Extract pre-NAT IP address that's stored within type 93 proprietary field - aluNatSubString.

@anetrjuns for your use case you would need types 91 and 92 fields? aluInsideServiceID and aluOutsideServiceID

from nfdump.

@phaag can we have this extensions for go-nfdumpas well?

from nfdump.

@phaag can we have this extensions for go-nfdumpas well?

Done!

from nfdump.

@phaag many thanks, unbelivable, it's working :)

Only one question about date/time
For the one flow we have duplicate entries: the first one has "Date first seen" filed with right value and 0-s for "Date last seen"
and for second one the values reversed.
Is this expected behaviour?
The screenshot is attached.

from nfdump.