[cento] make IPFIX field for dst mac address configurable (either 57 or 80)

[chriswelti]

Due to compatibility issues with other IPFIX collectors (e.g. Flowmon), it would be great if you could add an option to use Element ID 57 for dst mac address instead of 80. Or just use both at the same time :) The problem stems from the fact that in the original Netflow v9 (RFC3954), the mac address fields were:

56: SRC_MAC 57: DST_MAC

Later on, Cisco changed the NFv9 definitions to

56: IN_SRC_MAC 57: OUT_DST MAC 80: IN_DST_MAC 81: OUT_SRC_MAC

In IPFIX, although claiming to just re-use ElementID of NFv9 for 1-127, unfortunately they changed the name of those fields again to:

56: sourceMacAddress 57: postDestinationMacAddress 80: destinationMacAddress 81: postSourceMacAddress

And this although they claim to be backwards compatible to NFv9. Thus, now the confusion about which fields to use when you only see 2 mac addresses (just src and dst mac) on a wire tap.

Just reading the IPFIX standard, one would probably use 56 for source mac address and 80 for destination mac address (as you do in cento), but to remain backwards compatible, the option of using 57 for destination mac address would be better.

Of course, you could also just send all 4 Element IDs (56, 57, 80, 81) duplicating information but staying compatible with all collectors that way.

[lucaderi]

I have updated nProbe with support for the following elements [ 56] %IN_SRC_MAC %sourceMacAddress Source MAC Address [ 57] %OUT_DST_MAC %postDestinationMacAddress Destination MAC Address [ 80] %IN_DST_MAC %destinationMacAddress Destination MAC Address [ 81] %OUT_SRC_MAC %postSourceMacAddress Post Source MAC Address

In cento I would like to keep things simple and avoid duplications. So in essence for SRC MAC you suggest 56 and for DST MAC 57? If so I have made this chance. Please check it out.

[chriswelti]

Looks good to me for nProbe. For Cento, I don't know if its a good idea to just use 57 for DST MAC. I'd rather see a configuration knob, to choose between the two (57/80). E.g. for Flowmon collectors 57 is a good choice, however, for other IPFIX collectors that actually conform to the IPFIX standard, using 57 might be wrong, as they would only recognize 80 as valid DST MAC. It's a mess.

[lucaderi]

What if I would use 80 only for IPFIX and 57 for v9?

[chriswelti]

That doesn't really help, as even for v9, there is no agreed standard on which fields to use when only looking at a cable. The earlier spec in the RFC where there were just 2 mac adresses involved, it was easy as there were just fields 56 (SRC MAC) and 57 (DST MAC). Later on when they changed NFv9 to the "router model" with in and out src and mac addresses, that's when the mess began. People were already using fields 56 and 57 obviously, but then the naming changed. In NFv9 you can argue to use 57 as a dst mac when you are looking at a cable (due to the old definition, and also , that's whats actually going further "out" on the tapped cable). But you can also just as well claim that 80 should be used, as when looking at a tap, there are only inbound src/dst mac (as no traffic is leaving inspecting device). Whatever you do as an exporter device, you end up possibly breaking semantics on the collector, depending on how the collectors act :) Thus, my vote for making this configurable, then the actual user can have his own semantics, depending on the situation. If that's not an option, then your idea to take 80 for IPFIX and 57 for v9 (at least as a default) makes most sense to me (although that wouldn't fix my personal issue with the flowmon collector).