Multicast Traffic Monitoring and NetFlow

Multicast Traffic Monitoring and NetFlow

    Multicast Traffic MonitoringWith the increasing popularity of multicast media applications, the monitoring of multicast traffic becomes more and more important. When it comes to NetFlow, it has been supporting unicast and multicast traffic as well, since the legacy version 5. However, as NetFlow v5 supports only ingress monitoring, it is not possible to determine how a flow is replicated to output interfaces. Therefore, all multicast packets may not be counted. As we will discuss later, an output interface is Null in case of ingress monitoring.  For this reason, we will focus on the configuration of Flexible NetFlow v9 that allows egress monitoring as well. Furthermore, Flexible NetFlow allows service providers to collect and export parameters related to multicast traffic. This includes a replication factor and replicated packet/bytes.

    What is Multicast routing and how does it Work?

    IP Multicasting enables a host to send packets to a specific group of hosts. Hosts are called group members. Multicast Packets are delivered to group members that are identified by a single multicast group address. A group of hosts consists of both senders and receivers. Any host, regardless of whether it is a member of a group, can send multicast traffic to a group. However, only the group members can receive multicast messages.

    Multicast routing is about building the forwarding trees from the sender to a group of receivers. There is only one path between every pair of routers, and the path is loop-free.  In a Core-based tree, one router is selected as a Core or Rendezvous Point (RP) and all receivers build the shortest path to the core. The tree is shared by all senders. This concept assumes that members of the multicast group are sparsely distributed throughout the network and bandwidth is not necessarily widely available. The example of this multicast protocol is the PIM Sparse Mode (PIM-SM).

    In our network, multicast traffic is streamed from a host Source by the VLC media player to the multicast address 239.0.0.2, port 5004 towards three listeners (Picture 1). They are dynamically registered to a multicast channel. All three listeners are also running VLC configured to open network stream rtp://239.0.0.2:5004.

    The router R1 is configured as a Rendezvous Point (RP) for 239.0.0.2 multicast group. (Picture 2). R1 is also configured as a candidate BSR (Picture 3). RP distribution is enabled by using the PIM Bootstrap Router (BSR). As a result, other routers are notified via BSR about R1’s RP role. BSR sends messages on a hop-by-hop basis to 224.0.0.13 address with a local scope (TTL=1) informing all PIM neighbors about the RP address. This is the lo0 address of R1 (1.1.1.1) (Picture 2).

    OWD measurements

    Picture 1: Multicast Network Topology with VLC Streaming Source and Three Listeners


    Checking PIM Rendezvous Point (RP) Information

    Picture 2: Checking PIM Rendezvous Point (RP) Information


    Checking Bootstrap router (v2) Information

    Picture 3: Checking Bootstrap router (v2) Information


    Multicast Routing with PIM-Sparse Mode (BSR) Configuration

    R1 Configuration

    Firstly, enable multicast routing.

    ip multicast-routing

    Enable PIM Sparse Mode on interfaces.

    interface Loopback0
     ip address 1.1.1.1 255.255.255.255
     ip pim sparse-mode
           
    interface GigabitEthernet1/0
     ip address 192.168.1.2 255.255.255.0
     ip pim sparse-mode
    
    interface GigabitEthernet2/0
     ip address 10.0.2.2 255.255.255.252
     ip pim sparse-mode
    
    interface GigabitEthernet3/0
     ip address 10.0.3.2 255.255.255.252
     ip pim sparse-mode
    
    interface GigabitEthernet4/0
     ip address 192.168.5.2 255.255.255.0
           
    interface GigabitEthernet5/0
     ip address 10.0.4.2 255.255.255.252
     ip pim sparse-mode

    Configure OSPF routing.

    router ospf 1
     network 1.1.1.1 0.0.0.0 area 0
     network 10.0.2.0 0.0.0.3 area 0
     network 10.0.3.0 0.0.0.3 area 0
     network 10.0.4.0 0.0.0.3 area 0
     network 192.168.1.0 0.0.0.255 area 0
     network 192.168.4.0 0.0.0.255 area 0
     network 192.168.5.0 0.0.0.255 area 0

    Allow R1 to send candidate rp advertisement to the BSR.

    ip pim rp-candidate Loopback0

    Configure R1 as candidate BSR.

    ip pim bsr-candidate Loopback0 0

    R2 Configuration

    Configuration for all clients is similar, thus we will only show the configuration for the R2 router.

    ip multicast-routing 
    
    interface Loopback0
     ip address 2.2.2.2 255.255.255.255
     ip pim sparse-mode
    
    interface GigabitEthernet0/0
     ip address 192.168.2.2 255.255.255.0
     ip pim sparse-mode
     
    interface GigabitEthernet0/1
     ip address 10.0.2.1 255.255.255.252
     ip pim sparse-mode
    
     router ospf 1
     network 2.2.2.2 0.0.0.0 area 0
     network 10.0.2.0 0.0.0.3 area 0
     network 192.168.2.0 0.0.0.255 area 0

    Flexible NetFlow Configuration

    The Flexible NetFlow (FnF) is the configuration interface on a device that allows users to configure and customize what information is exported in flow records using NetFlow version 9. Flexible NetFlow consists of 3 components.

    1) Flow Record

    2) Flow Exporter

    3) Flow Monitor

    Firstly, we will configure the NetFlow parameters for multicast. The statement below enables accounting for the number of bytes and packets forwarded.

    R1(config)# ip multicast netflow output-counters

    Ingress Multicast Accounting

    Multicast ingress accounting provides information about the source and how many times the traffic was replicated.

    Flow Record Configuration

    The Flow Record serves as the basis for the NetFlow template used in the export process by specifying the information that we want to collect. The template contains key fields that are matched with match statement and non-key fields matched with the collect statements. All the key-fields matched with the match statement are collected as well.

    Just as with traditional NetFlow v5, we match 7-tuple key fields with the match statements in order to identify the flow. This includes a source/destination address, source/destination transport layer port, IP Protocol, Type of Service (ToS), and the input interface port. A unique flow is created in a flow cache of the device if any of the key fields are matched. Flexible NetFlow (FnF) allows defining additional matching key fields. In addition to the 7-tuple key field, we match multicast traffic with the matching routing is-multicast statement. The flow match direction is matched, as well.

    We also collect additional information that will be added to the Flow Record as non-key fields. They are specified by the collect statement. Like key-fields, no-key fields are exported with flows when configured with a collect statement. However, the non-key fields are not used to create or characterize flows, instead, they report flow parameters. In our example, we collect non-key fields such as interface output, packet, and bytes counters and timestamps.

    Multicast replication factor and replicated packets/bytes are useful statistics in multicast accounting provided by Flexible NetFlow. The counter for replicated packets indicates the number of replicated packets to the output interfaces. Similarly, the counter for replicated bytes indicates the number of replicated bytes to the output interfaces. In our case, each input multicast packet is replicated by R1 to three output interfaces (Gi2/0, Gi3/0, and Gi5/0) towards Listeners 1, 2 and 3.

    R1(config)# flow record MULTICAST-RECORD
    R1(config-flow-record)# match ipv4 source address
    R1(config-flow-record)# match ipv4 destination address
    R1(config-flow-record)# match transport source-port
    R1(config-flow-record)# match transport destination-port
    R1(config-flow-record)# match ipv4 protocol
    R1(config-flow-record)# match ipv4 tos
    R1(config-flow-record)# match interface input
    R1(config-flow-record)# match interface output
    R1(config-flow-record)# match routing is-multicast
    R1(config-flow-record)# match flow direction
    
    R1(config-flow-record)# collect routing multicast replication-factor
    R1(config-flow-record)# collect counter bytes
    R1(config-flow-record)# collect counter packets
    R1(config-flow-record)# collect counter bytes replicated
    R1(config-flow-record)# collect counter packets replicated
    R1(config-flow-record)# collect timestamp sys-uptime first
    R1(config-flow-record)# collect timestamp sys-uptime last
    R1(config-flow-record)# exit

    Flow Export Configuration

    Define the IP address of NetFlow collector and destination UDP port the collector is listening on.

    R1(config)# flow exporter MULTICAST-EXPORTER
    R1(config-flow-exporter)# description Flexible NetFlow version 9
    R1(config-flow-exporter)# destination 192.168.4.1
    R1(config-flow-exporter)# source GigabitEthernet0/3
    R1(config-flow-exporter)# transport udp 2055
    R1(config-flow-exporter)# exit

    Flow Monitor Configuration

    Assign flow record and exporter to the flow monitor.

    R1(config)# flow monitor MULTICAST-MONITOR
    R1(config-flow-monitor)# description Multicast Monitor
    R1(config-flow-monitor)# exporter MULTICAST-EXPORTER
    R1(config-flow-monitor)# record MULTICAST-RECORD
    R1(config-flow-monitor)# exit

    Interface Configuration for Flows

    Activate the flow monitor that we created previously by assigning it to the interface in the ingress direction. In our example, both unicast traffic and multicast traffic are monitored. If you want to monitor multicast traffic only, add the multicast keyword.

    R1(config)# interface gigabitEthernet0/0
    R1(config)# ip address 192.168.1.2 255.255.255.0
    R1(config)# ip flow monitor MULTICAST-MONITOR input
    R1(config)# exit

    When multicast flow accounting is enabled in the ingress direction, the destination interface on most flows is reported as Null (Picture 4). The replication factor specifies a source interface and IP address of the multicast traffic. It equals the number of output interfaces. In our case, the replication factor equals 0 instead of 3; the counters for replicated packets and bytes are 0 as well. This means that the feature is not supported by the platform configured as the router R1.

    Multicast Record

    Picture 4: Multicast Record in R1 Flow Cache When Ingress Flow monitoring is Enabled on the Interface Gi1/0


    Note: The IP protocol 17 defines the UDP transport layer protocol.

    Ingress multicast NetFlow accounting does not increase the amount of NetFlow traffic exported to NetFlow collector. However, it lacks information about the output interface.

    Egress Multicast Accounting

    Multicast egress accounting monitors the destination of the traffic flow. For each replicated flow on the output interface a new multicast flow is created (Picture 3). The output interface is different so the statement “match interface output” is matched with each replicated flow. As a result, three unique flows with the same source interface (Gi1/0) are created. The output interface is the interface towards listeners.

    interface GigabitEthernet2/0
     ip address 10.0.2.2 255.255.255.252
     ip flow monitor MULTICAST-MONITOR output
     ip pim sparse-mode
     
    interface GigabitEthernet3/0End.
     ip address 10.0.3.2 255.255.255.252
     ip flow monitor MULTICAST-MONITOR output
     ip pim sparse-mode
          
     interface GigabitEthernet5/0
      ip address 10.0.4.2 255.255.255.252
      ip flow monitor MULTICAST-MONITOR output
      ip pim sparse-mode
    Replicated Multicast Flows

    Picture 5: R1 Flow Cache with Three Replicated Multicast Flows when Egress Flow monitoring is Enabled


    If the NetFlow analyzer correlates flow information based on input and output interfaces only, it may wrongly assume that those three replicated multicast flows enter the router R1 via the interface Gi1/0. As a result, NetFlow analyzer can determine three times higher throughput for Gi1/0 than it really is as only a single multicast flow enters R1 via Gi1/0. As a workaround, we can enable ingress multicast accounting on the interface Gi1/0. This allows the NetFlow analyzer to obtain a more accurate picture of the replication of multicast flows (Picture 6). This approach, however, can lead to faster flow cache exhaustion and higher bandwidth utilization due to the increased amount of NetFlow data being exported towards collectors.

    interface GigabitEthernet1/0
     ip address 192.168.1.2 255.255.255.0
     ip flow monitor MULTICAST-MONITOR input
     ip pim sparse-mode
    Flow Cache with Multicast Flow

    Picture 6: R1 Flow Cache with Multicast Flow when Ingress Flow monitoring is Enabled


    Conclusion:

    The accuracy of NetFlow multicast traffic monitoring and accounting can be greatly improved by a collection of multicast related non-key fields that are available in Flexible NetFlow v9. Those are replication factor and replicated packets/bytes. Moreover, NetFlow v9 allows egress (output) monitoring, so we can safely determine how a multicast packet is replicated to interfaces. Service providers and content/application providers may utilize the information for more accurate billing. However, a Netflow analyzer must be able to support these multicast non-key fields to calculate the correct network utilization and application resource usage.


    Boost BGP Preformance

    Automate BGP Routing optimization with Noction IRP

    BGP Demo

    NO COMMENTS

    Leave a Reply