Expand key for template cache in IPFix and v9

[rachelScout]

Currently V9 and IPFIX templates are cached using template id and exporter address as a key.
Rfc3954 implies that v9 templates should be cached using the following fields:

msg header Source ID
exporter source IP
Template id

As stated below:

Source ID:
A 32-bit value that identifies the Exporter Observation Domain.
NetFlow Collectors SHOULD use the combination of the source IP
address and the Source ID field to separate different export
streams originating from the same Exporter.

[dbardbar]

@akshah,

A pcap that demonstrates the problem is attached. In packet #1 and #2, template id 257 is being sent on domain id 3.
In packet #3, the same template id from the same host is being send, but now on domain 4. The elements are slightly different on this packet. The last 2 elements are of type mibObjectValueOID (element id 436) and mibObjectValueBits (element id 437), while in packet #1 those fields were element octetDeltaCount (element id 1) and packetDeltaCount (element id 2).

Now comes packet #4, which demonstrates the problem. It has template id 257, and domain 3, so it should be parsed using the template from packet #1, and not the template seen later, in packet #3.
In Wireshark this is done correctly. You can see when looking at packet #4 that the it knows the the template packet is #1, and parses the data in packet #4 based on the template in packet #1.

In vflow without the fix, packet #4 is being parsed based on packet #3, because it came later, and vflow ignores the domain id. In vflow with the fix, packet #4 is being parsed on the packet #1, because that's the packet which matches the combination of sender IP + template id + domain id.

ipfix_different_domain.zip