With the rapid proliferation of video services, particularly video streaming, deployment of multicast services demands an appropriate monitoring to be in place in order to keep track of this traffic type. Adequate and comprehensive monitoring is particularly important to account for all parameters that may affect very sensitive nature of video services. In previous blogs for Cisco and Juniper vendors, we mainly addressed the basic NetFlow configuration required for flow information export. NetFlow configuration and flow export were given under the assumption that unicast is dominant type of traffic. However, in content provider networks where multicast streaming services constitute a significant traffic share, flow monitoring should be deployed to obtain relevant multicast statistics such as flow replication.
Multicast essentially operates differently than unicast as a result of one-to-many communication and packet replication process. We will make several tests to see how multicast is different in terms of flow export. Depending on which flow export protocol we are using, the result may differ. In this blog, we are using Flexible NetFlow to investigate how it captures multicast flows and associated statistics. For demonstration purposes as a NetFlow collector we are using NetVizura NetFlow Analyzer to collect and analyze the multicast flows. We will set up the multicast streaming scenario with multicast sparse mode, single multicast source with three listeners, which is depicted in Fig. 1. For this demonstration we use Flexible NetFlow that is configured on Cisco router with IOS 15.4.
Fig.1 Multicast topology with single streaming source and three listeners.
Multicast traffic is generated by multicast source from which looped video is streamed on multicast address 239.1.1.1 towards three listeners which are dynamically registered to this multicast channel. Such layout allows us to have one input interface and three output interfaces.
PIM sparse mode is configured in such way that R1 is Rendezvous Point (RP) for this 239.1.1.1 multicast group, whereas other routers are notified via PIM Bootstrap Router (BSR) of R1's RP role. Alternatively, we could have used static RP configuration or AutoRP (for that purpose sparse-dense mode should have been used on interfaces). However, since our topology consists of three listeners and single source, we chose to use BSR because it enables RP distribution by simply putting "ip pim candidate-rp lo0" command on R1. BSR mechanism sends messages on hop-by-hop basis to 224.0.0.13 address with local scope (TTL=1) informing all PIM neighbors about the RP address, which is the lo0 address of R1
In the previous blog we have covered the relevant NetFlow configuration on Cisco network devices. We use Flexible NetFlow, which, as the name states, allows certain flexibility in definition of key and non-key fields. Key fields are a set of flow parameters which constitute a single flow. If a group of packets have the same values of all key fields then they belong to a single flow. Through selection of particular key fields you can easily define the parameters that constitute a single flow. On the other hand, non-key fields are defined as parameters which are relevant in terms of collected information. For example, byte and packet counters are non-key fields referring to the byte and packet number in a single flow. Once we have the clear idea of key and non-key fields in the context of Flexible NetFlow, we can proceed to flow monitoring configuration.
Flexible NetFlow configuration
Configuration of Flexible NetFlow consists of three main parts: record, exporter and monitor. As a part of flow records we define flow parameters to be either key or non-key fields. Also, in this part of configuration, we specify if we want to capture only multicast traffic or multicast and unicast traffic. Distinguishing flows by specifying set of key fields is the most important factor in flow record. Once we have configured what parameters constitute unique flow, we move on to define what kind of statistics is associated with the individual flow. Often, non-key fields are actual counters, which provide further insight in volume and packet number in flows. The record configuration for our multicast demonstration is given in the following snippet:
flow record FLOW-RECORD-MCAST
match routing is-multicast
match ipv4 source address
match ipv4 destination address
match transport source-port
match transport destination-port
match interface input
match interface output
collect routing multicast replication-factor
collect counter bytes
collect counter packets
collect counter packets replicatedAs we can see from the configured record FLOW-RECORD-MCAST, we have chosen key fields IPv4 source and destination address, source and destination ports, input and output interfaces, whereas non-key fields are byte and packet counter. Specific key field for multicast ("routing is-multicast") and non-key fields (replication-factor and number of replicated packets) require further clarification. Key field "routing is-multicast" designates that only multicast flows will be a part of this record. Non-key field concerning replicated packets will contain total number of packets that are replicated to the output interfaces, in our example each input multicast packet will be replicated to three output interfaces towards three listeners. The replication factor definition depends on the per-interface NetFlow configuration if flow capture is configured in input or output direction. If input direction is configured on the interface, replication factor indicates the number of output interfaces that flow is replicated to, whereas if flow capture is configured in the output, outgoing multicast flows are observed as individual flows. The latter also applies if input and output flow monitoring are configured on the interface at the same time.
Important note must be made in terms of multicast accounting since replication statistics described using parameters replicated packets and replication factor was not available neither on flow cache nor exported to NetFlow collector. This is due to constraints for NetFlow multicast accounting that requires multicast fast switching or multicast distributed fast switching to be configured. On the tested Cisco platforms for this demonstration, this was not supported. The absence of replication factor and replicated packet statistics may be observed from the following command output as the number of replicated packets for multicast flow 239.1.1.1 is 0.
R1#sh flow monitor FLOW-MONITOR-MCAST cache
Cache type: Normal
Cache size: 4096
Current entries: 5
High Watermark: 7
Flows added: 172
Flows aged: 167
- Active timeout ( 120 secs) 73
- Inactive timeout ( 15 secs) 90
- Event aged 4
- Watermark aged 0
- Emergency aged 0
IP IS MULTICAST: Yes
IPV4 SOURCE ADDRESS: 10.5.0.10
IPV4 DESTINATION ADDRESS: 239.1.1.1
TRNS SOURCE PORT: 0
TRNS DESTINATION PORT: 0
INTERFACE INPUT: Et1/0
INTERFACE OUTPUT: Et0/1
ip replication: 0
counter bytes: 96900
counter packets: 1275
counter packets replicated: 0After flow record configuration, we continue on with the configuration of exporter details that contain NetFlow collector IP address, export port on which flow collector listens for NetFlow packets and optionally, source interface from which export is carried out. The details are given in the next configuration snippet.
flow exporter EXPORTER-NETVIZURA
destination 10.8.0.1
source Ethernet0/0
transport udp 2055From the exporter configuration, the flow cache content is exported to 10.8.0.1 from local interface e0/0 via UDP protocol to port 2055, which is configured on NetVizura NetFlow collector.
Flow monitor configuration part is supposed to join together record and exporter parts so that flow records are exported towards collector specified in the flow exporter. Furthermore, as a part of flow monitor cache timeouts for active and inactive flows may be specified. Significance of these timeouts is explained in our previous blog. This part is pretty much straight forward and it should reference flow exporter and flow record that were previously configured.
flow monitor FLOW-MONITOR-MCAST
exporter EXPORTER-NETVIZURA
cache timeout active 120
record FLOW-RECORD-MCASTEach flow exporter support only single destination. Therefore, if there is a need for flow export to multiple destinations multiple flow exporters should be configured and each of them should be referenced in flow monitor part.
Once the flow record, exporter and flow monitor parts are finished, we need to decide whether the NetFlow will collect flow information on a per-interface level in input or output direction. The input/output choice will determine how multicast traffic will be visible on NetFlow collector. Once the configuration part is over, we turn our focus to how multicast flows look like when input and output Netflow configuration is applied on multicast router. For this purpose, high level overview of multicast flows is shown in Fig. 2 and Fig.3 for input and output Netflow configuration, respectively.
Fig.2 Overview of multicast flow data for input flow monitoring.
When input flow monitoring is configured on interfaces on R1, flow cache on R1 captures only a single flow with particular flow data. From a set of flow data, particularly important for the multicast flow accounting is the observation of input and output interfaces associated with the individual flows. As we can observe from the Fig. 2, input flow configuration on e1/0 interface captures only a single multicast flow with input interface e1/0. Output interface of this flow is actually unknown, as flow data does not contain any information about interfaces from which replicated multicast flows should originate. Input multicast flow terminates on the router itself on the Null0 interface. This interface is logical interface used as a sink for different packets, e.g. discarding packets denied by ACLs or inbound multicast packets before being replicated to the output interfaces. As such, Null0 interface is placed as an output interface on this multicast flow.
Fig.3 Overview of multicast flow data for output flow monitoring.
In the Fig. 3 we can see that once output flow monitoring is configured on the interfaces, replicated flow information becomes a part of flow cache on R1. This way, by going through the flow data, we can easily establish on how many interfaces is a single multicast flow replicated. However, from the perspective of flow data analysis this turns out to be a very serious issue. Netflow analyzer (NFA) is correlating flow information based on input and output interfaces. Consequently, NFA obtains false information that all replicated multicast flows are coming via interface e1/0 into the router. This creates three times higher throughput on e1/0 than it really is since there is only a single multicast flow entering R1 on e1/0. From the perspective of traffic monitoring, Netflow can offer false traffic load on an interface and create a significant discrepancies when comparing to SNMP traffic load data.
Mentioned discrepancies become much more noticeable if there is a high multicast traffic load with high level of replication.
In this blog, we have covered relevant Flexible Netflow configuration for the multicast flow monitoring. The next blog will cover detailed tests of this configuration and demonstration how Netvizura NFA sees multicast flows when input and output flow configuration is applied.
