As the problem of multicast flow analysis was addressed in our previous blog, we have distinguished two scenarios input and output flow accounting configuration. Therefore, during the following demonstration, we will investigate how NetFlow multicast flow data looks like when these two configuration variations are used.
Multicast flow accounting configured on input interface
Interpretation of flow accounting is not as trivial as with unicast flows, as a result of multicast flow replication, from single input to multiple output interfaces. We will show, in the following tests, that multicast traffic produces different flow data in comparison to unicast. Input flow monitoring is applied on interface e1/0 on R1 (Fig.1) according to the following configuration:
Fig.1 Multicast topology with single streaming source and three listeners.
In the following figures, we can observe how multicast channel 239.1.1.1 is seen on NetVizura NetFlow Analyzer (NFA). Video streaming is destined to 239.1.1.1 and three listeners are receiving this stream meaning that it is replicated on output interfaces e0/1-3 on R1. Fig. 2 depicts dominant (in terms of traffic volume) source and destination addresses among which are multicast channel 239.1.1.1 and multicast source 10.5.0.10 (Fig.3). However, aside from assessing traffic volume generated by this video stream, we are unable to further analyze how this multicast stream is replicated and moved across the network.
Fig.2 Flow destined towards multicast channel 239.1.1.1. 
Fig.3 Flow sourced from video server 10.5.0.10.
Being aware of this visual limitation we dive further into multicast flow data received from R1 on NetVizura NFA by inspecting available raw data. Filtering flows destined to 239.1.1.1 we receive more usable data as depicted in Fig. 4.
Fig.4 Raw flow data for destination IP address 239.1.1.1.
According to this raw data two flows are distinguished one with destination port 5004 (video streaming port) and one with source/destination port 0. Both flows have input interface field equal to the SNMP ifindex of e1/0 interface, as it is the interface connected to the multicast source. On the other side, if we observe output interface, there is a difference between these flows. Output interface value for the first flow equals to 0, which is SNMP ifindex of multicast discard interface Null0. Null0 interface is a logical interface at which total multicast traffic entering the router is terminated. The flow volume corresponds to the total traffic volume terminated on the router itself, as this interface is used as a bit-bucket for packets being discarded by the router or as with multicast traffic terminated on the router, before replication.
Fig.5 Flow information towards Listener 1.
Output interface of the second 239.1.1.1 flow with source/destination ports 0 is equal to the SNMP ifindex of e0/1. This is where we stumble upon the problem with input multicast flow accounting. In our scenario, we have three listeners and raw data contains only single flow with output interface as if there was only Listener 1. The Fig. 5 depicts the mentioned multicast flow on the output interface e0/1. This confirms that according to the flow accounting on multicast video streaming is sent towards Listener 1. However, NFA is unable to display any flow information on other output interfaces e0/2 and e0/3 towards Listener 2 and Listener 3, respectively. We further tested it out to see what would happen if Listener 1 chose to stop receiving this video stream. If this happened, flow would change output interface that corresponds to the next higher SNMP ifindex, in this case it is the interface e0/2. When we subsequently turned off the video stream on Listener 2, the flow on NFA appeared with output interface e0/3. These experiments led us to the conclusion that when input flow monitoring is applied, it is not possible to obtain detailed multicast flow accounting that refers to the replication process and all output interfaces associated with the particular multicast flow. Only partial multicast insight may be obtained from a single output interface, which was shown in the previous experiment. However, this is not enough to grasp a full picture of the replication level, especially when there are a lot of registered multicast listeners in PIM-SM environment. Bearing in mind previously mentioned constraints, we now turn to investigate if configuration of multicast flow accounting on output interfaces would addresses the multicast replication shortcomings demonstrated by the input flow accounting.
Multicast flow accounting configured on output interfaces
We apply NetFlow interface configuration referencing flow monitor FLOW-MONITOR-MCAST previously explained in our previous blog. For the purpose of output multicast flow accounting configuration, we now apply the flow monitor in the output direction on all interfaces facing listeners.
We can see the results on the following figures obtained from Netvizura NFA. It is noticeable that by configuring output flow monitoring on multicast output interfaces NFA obtains necessary replication information related to multicast stream 239.1.1.1. Fig. 6-8 shows that on interfaces e0/1-3 flow 239.1.1.1 is detected in output direction. In order to provide better flow data overview on Netvizura NFA in this context, for each output interface from e0/1 to e0/3, we filter only traffic flows destined towards 239.1.1.1 by selecting "Dst" button.
Fig.6 Output multicast flow 239.1.1.1 towards Listener 1. 
Fig.7 Output multicast flow 239.1.1.1 towards Listener 2. 
Fig.8 Output multicast flow 239.1.1.1 towards Listener 3.
By going through raw data for multicast flow 239.1.1.1, it is clear that for each replicated flow on the output interface a new multicast flow is created. Furthermore, each multicast flow has source interface corresponding to the SNMP ifindex of interface on which multicast traffic is entering R1 and output interface corresponding to the SNMP ifindex of the interface towards individual registered multicast listener. Consequently, this provides us with necessary data on multicast replication.
However, as a result of the appearance of these independent multicast flows associated with interface input e1/0 a serious problem arises. Netflow analyzer (NFA) assumes that each of these new flows independently arrives at interface e1/0 and it can't determine that these flows are the result of replication from a single flow. Consequently, NFA assumes that identical three flows are coming into interface e1/0, thus creating false and multiplied traffic load on input interface. As we can notice from the Fig. 9-12, input bandwidth on e1/0 equals three times the output bandwidth of output interfaces e0/1-3. This means that instead of seeing traffic load generated by this single multicast flow, we see higher traffic load multiplied by the number of replicated flows. This false load is non-existent in reality and only appears in flow records or more specifically on NFAs. As a result of NFA's lack of ability to correlate original multicast flow with replicated flows, we have traffic load discrepancies on input interfaces in comparison to traffic load data provided by other tools, e.g. SNMP. It is important to be aware of this issue since it can affect the accuracy of visible traffic load that depends on the multicast replication level. The more multicast traffic is replicated on output interfaces, the higher discrepancy exhibited between real and false multicast traffic load on input interface.
Fig.9 Input throughput on interface e1/0. 
Fig.10 Output throughput on interface e0/1. 
Fig.11 Output throughput on interface e0/2. 
Fig.12 Output throughput on interface e0/3.
General guidelines on the implementation of multicast flow accounting
This demonstration has helped to identify certain deficiencies in the implementation of multicast NetFlow monitoring and point to the right direction when it comes to planning and deployment of multicast flow monitoring. We have shown that using input flow accounting on interfaces, a lot of relevant multicast statistics remain obscure pertaining packet replication process and output interfaces. However, modest insight about input multicast flow statistics may still be obtained. On the other hand, when applying output flow accounting, we must be aware of existing tradeoff between detailed flow statistics on one side and false traffic load appearing on input interfaces on the other side. This tradeoff is an important aspect to bear in mind when planning multicast flow accounting implementation as it can create operational problems in terms of throughput data accuracy when comparing different monitoring sources.
A potential approach would be to use simultaneously input and output flow monitoring that would provide comprehensive and accurate multicast flow information. However, such deployment may affect the cache size and also lead to flow duplication on NetFlow collector. Of course, it does not solve false traffic load appearing on input interfaces that we mentioned before. These multicast flow monitoring conclusions may easily pave the way on future improvement of NFAs. Improvements should reflect the ability to recognize replicated multicast flows and prevent them from associating to the multicast input interface as it will cause the traffic load discrepancy.
