BACKGROUNDThere exists a class of systems that can analyze traffic flows in a network while traffic is being switched at full line rate. These systems include a traffic analyzer that is inserted between two networks. The traffic analyzer might be installed, for example, between a company's private network and a public network, such as the Internet. The traffic analyzer analyzes the traffic that crosses the boundaries of the two networks. This kind of traffic analyzer does not work for analyzing traffic within a network.
Also, existing traffic analyzers operate on some subset of the traffic, such as suspicious traffic. One issue with these traffic analyzers is that the traffic analyzers reduce throughput and increase latency in the network. Another issue with these traffic analyzers is that the subset of traffic that the traffic analyzers operate upon has to be identified beforehand. Unfortunately, it is not always possible to identify beforehand which traffic is of interest.
SUMMARYAccording to one implementation, a device may include a memory, flow table logic, and a processing unit. The memory may store a flow table that stores, as a number of entries, statistics regarding a number of data flows. The flow table logic may generate flow creation records corresponding to new data flows for which entries are created in the flow table, generate flow termination records corresponding to terminated data flows for which entries exist in the flow table, and output the flow creation records and the flow termination records. The processing unit may receive the flow creation records and the flow termination records, correlate ones of the flow creation records and the flow termination records associated with a same one of the data flows, and store the correlated ones of the flow creation records and the flow termination records.
According to another implementation, a device may include a memory, flow table logic, sampling logic, and a processing unit. The memory may store a flow table that stores, as a number of entries, statistics regarding a number of data flows. The flow table logic may generate records corresponding to data flows for which entries are created in the flow table or removed from the flow table. The sampling logic may select one of the data flows for sampling and sample initial data units for the one of the data flows. The processing unit may receive the records generated by the flow table logic, receive the initial data units sampled by the sampling logic, analyze the initial data units to generate analysis results, correlate the records and the analysis results associated with a same one of the data flows, and store the correlated records and analysis results.
According to yet another implementation, a method, performed by a device that includes a memory device and a processing unit, may include receiving a data unit; identifying a data flow associated with the data unit; determining that the data flow is associated with no entry in a flow table stored within the memory device; creating an entry in the flow table for the data flow when there is no entry in the flow table that is associated with the data flow; generating a flow creation record, associated with the data flow, when the entry is created in the flow table; selecting the data flow for sampling; sampling initial data units associated with the data flow; sending the flow creation record and the initial data units to the processing unit; analyzing, by the processing unit, the initial data units to generate analysis results; and associating, by the processing unit, the flow creation record with the analysis results within the memory device.
According to a further implementation, a global analysis system may include a group of network devices connected to a global traffic analyzer. Each of the network devices may aggregate information regarding all data flows associated with data units received or transmitted by the network device without impacting throughput of the data units, and output the aggregated information. The global traffic analyzer may collect the aggregated information from each of the network devices, store the aggregated information, and present a user interface to facilitate searching and retrieval of information from the stored, aggregated information.
BRIEF DESCRIPTION OF THE DRAWINGSThe accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate one or more embodiments described herein and, together with the description, explain these embodiments. In the drawings:
FIG. 1 is a diagram of an exemplary network in which systems and methods, described herein, may be implemented;
FIG. 2 is a block diagram illustrating exemplary components of a network device ofFIG. 1;
FIG. 3 is a block diagram illustrating exemplary components of an interface ofFIG. 2;
FIG. 4 is a diagram of an exemplary data unit that may be transmitted between components in the interface ofFIG. 2;
FIG. 5 is a block diagram illustrating exemplary functional components of flow management and fabric queuing logic ofFIG. 3;
FIG. 6 is a diagram of exemplary fields of the flow table ofFIG. 5;
FIG. 7 is a diagram of exemplary components of the analyzer module ofFIG. 2;
FIG. 8 is a diagram illustrating exemplary communication planes in the network device ofFIG. 2;
FIG. 9 is a diagram illustrating exemplary components, of the network device ofFIG. 2, that may participate in communication on a visibility plane;
FIGS. 10-14 illustrate flowcharts of exemplary processes for monitoring, processing, and/or sampling data unit(s) of a data flow; and
FIG. 15 is a diagram of an exemplary global traffic analysis system.
DETAILED DESCRIPTIONThe following detailed description refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements.
Implementations, as described herein, may permit data flows to be analyzed within a network without affecting throughput or latency. For example, a network device, within the network, may collect statistics regarding data flows and sample data units associated with selected ones of these data flows. The term “data unit,” as used herein, may refer to a packet, a datagram, or a cell; a fragment of a packet, a datagram, or a cell; or another type or arrangement of data. The term “data flow,” as used herein, may refer to a collection of data units associated with communication between a particular source and a particular destination.
Exemplary NetworkFIG. 1 is a diagram of anexemplary network100 in which systems and methods, described herein, may be implemented. Network100 may include any type of network, such as the Internet, an ad hoc network, a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network (e.g., the Public Switched Telephone Network (PSTN) or a cellular network), or a combination of networks. In one implementation,network100 may take the form of a private network (e.g., a campus network).
As shown inFIG. 1,network100 may include a number ofendpoint devices102 connected via a set of network devices104-1,104-2, . . . ,104-N (collectively referred to herein as “network devices104,” or generically as “network device104”) (N≧1).Endpoint devices102 and/ornetwork devices104 may connect via wired and/or wireless connections. In another implementation,network100 may include additional, fewer, different, or differently arranged devices than are shown inFIG. 1.
Each ofendpoint devices102 may include any type of communication or computational device, such as a personal computer, a workstation, a laptop, a server device, a mobile device (e.g., a personal digital assistant (PDA), a mobile telephone, etc.), or the like. In the description to follow, assume thatvarious endpoint devices102 communicate withother endpoint devices102 vianetwork100.
Each ofnetwork devices104 may include a switch, a router, a server, or another type of device. Whilenetwork devices104 can be implemented as different types of devices, in the following paragraphs,network devices104 will be described in terms of a router, such as an aggregation router or a core router. The links interconnectingnetwork devices104 are shown by way of example.Network devices104 may be interconnected via different links than those shown inFIG. 1.
FIG. 2 is a block diagram illustrating exemplary components ofnetwork device104. As shown inFIG. 2,network device104 may include asystem control module210, aswitch fabric220, a group ofinterfaces230, and ananalyzer module240. In other implementations,network device104 may include fewer, additional, different, or differently arranged components than those illustrated inFIG. 2. Also, or alternatively, one or more of the functions described as performed by one of the components may be performed by another one of the components. Also, or alternatively, a single component may be implemented as two or more separate components, or multiple components may be implemented as a single component.
System control module210 may include, for example, a processor, a microprocessor, and/or processing logic (e.g., an application specific integrated circuit (ASIC), a field programming gate array (FPGA), etc.) that may be optimized for networking and communications.System control module210 may perform high level management functions fornetwork device104. For example,system control module210 may communicate with other networks and systems connected tonetwork device104 to exchange information regarding network topology. In some implementations,system control module210 may include a routing engine for creating routing tables based on network topology information, creating forwarding tables based on the routing tables, and sending these tables tointerfaces230 for data unit routing.System control module210 may also include a static memory (e.g. a read only memory (ROM)), a dynamic memory (e.g. a random access memory (RAM)), onboard cache, and/or flash memory for storing data and/or machine-readable instructions.
Switch fabric220 may include one or more switching planes to facilitate communication amonginterfaces230 and/orsystem control module210. In one implementation, each of the switching planes may include a single or multi-stage switch of crossbar elements.Switch fabric220 may also, or alternatively, include processors, memories, and/or paths that permit communication amongsystem control module210 and interfaces230.
Interfaces230 may include devices or assemblies, such as line cards, for receiving incoming data units from network links (or from other interfaces230) and for transmitting the data units to network links (or to other interfaces230). For example, interfaces230 may include Ethernet interfaces, optical carrier (OC) interfaces, and/or asynchronous transfer mode (ATM) interfaces.Interfaces230 may manage a set of input ports via which data units can be received and a set of output ports via which data units can be transmitted.
Analyzer module240 may include a device that may analyze traffic received and/or transmitted bynetwork device104 with no performance impact (e.g., no latency impact).Analyzer module240 may collect information regarding data flows, such as when data flows were created and/or terminated, how many data units and/or bytes were transmitted for these data flows, whichendpoint devices102 were the sources and/or destinations for the data flows, or the like.
Depending on the implementation, the components that are shown inFIG. 2 may provide fewer or additional functionalities. For example, ifnetwork device104 performs an Internet Protocol (IP) data unit routing function as part of a Multi-Protocol Label Switching (MPLS) router,system control module210 may perform tasks associated with obtaining routing information from other routers in a MPLS network. In such cases, conveying network traffic from one interface to another may involve label-based routing, rather than IP address-based routing.
FIG. 3 is a block diagram illustrating exemplary components ofinterface230. As shown,interface230 may include packet forwarding engines (PFEs)310-1 and310-2 (collectively referred to herein as “PFEs310,” or generically as “PFE310”), flow management and fabric queuing (FFQ) logic320-1 and320-2 (collectively and generically referred to herein as “FFQ logic320”),backplane330,switch340,switch350, and Visibility Central Processing Unit (VCPU)360. In different implementations,interface230 may include fewer, additional, different, or differently arranged components than those illustrated inFIG. 3. Also, or alternatively, one or more of the functions described as performed by one of the components may be performed by another one of the components. Also, or alternatively, a single component may be implemented as two or more separate components, or multiple components may be implemented as a single component.
PFE310 may each include hardware, or a combination of hardware and software, that may receive, store, process, and/or forward data units. PFE310 may each include a memory to aid in the storing, processing, and/or forwarding of received data units. PFE310 may process data units received from incoming network links and prepare data units for transmission on outgoing network links. PFE310 may perform various look-ups (e.g., destination look-ups, access control look-ups, etc.) based on header information of the data units, and may make forwarding decisions based on these look-ups. PFE310 may transmit received data units toFFQ logic320.
PFE310 may add a packet descriptor to a received data unit prior to sending the data unit toFFQ logic320. The packet descriptor may include information regarding the look-ups and/or forwarding decisions made by PFE310. In one implementation, PFE310 may include a pointer, within the packet descriptor, that points to a location where Internet Protocol (IP) header fields begin within the header of the data unit. The IP header fields may include a source IP address field, a destination IP address field, a layer 3 (L3) protocol type field, a destination port field, and a source port field.
FIG. 4 is a diagram of anexemplary data unit400 that may be transmitted between PFE310 andFFQ320.Data unit400 may includedata portion410,header portion420, and packet descriptor (PD)portion430.Data portion410 may include the payload of the data unit received by PFE310.Header portion420 may include some or all of the header information of the data unit received by PFE310.Packet descriptor portion430 may include information regarding the look-ups and/or decisions made by PFE310. In one implementation,packet descriptor portion430 may include apointer432 that may point to a location inheader portion420 where the IP fields start.Pointer432 may be stored in a particular location withinpacket description portion430 that is known toFFQ logic320 so thatFFQ logic320 knows where to locatepointer432 and, thus, where to locate the IP fields inheader portion420.
Returning toFIG. 3,FFQ logic320 may include hardware, or a combination of hardware and software, that may receive data units from PFEs310 and monitor data flows associated with the data units. In one implementation,FFQ logic320 may create a table entry for a data flow in a flow table and monitor flow statistics relating to the data flow. In one implementation,FFQ logic320 may use a timer for each data flow to track the timing of data units for the data flow, and a set of counters for each data flow to track data unit/byte counts for the data flow. In some implementations,FFQ logic320 may also sample data units and may send sampled data units and other information, such as flow table records, to switch340 and/orswitch350.FFQ logic320 may also transmit data units from PFE310 tobackplane330.
Backplane330 may include a switching fabric and/or one or more memories that may transmit data units to/from switch fabric220 (as shown inFIG. 2).Switch340 may include a high speed switching interface, such as a Peripheral Component Interconnect Express (PCI-E) switch, for transmitting/receiving data units and information betweenFFQ logic320 and/orVCPU360.
Switch350 may include an Ethernet switch, or another type of switch, that may transmit data units and/or information among PFEs310,FFQ logic320, and/orVCPU360.Switch350 may also transmit and/or receive data units and/or information over an out-of-band plane, viabackplane330 to another device (internal or external to network device104) for further processing and/or analysis.
VCPU360 may include one or more processors, microprocessors, and/or processing logic (e.g., ASICs, FPGAs, etc.) that may perform network communications, management, and analysis functions. For example,VCPU360 may control functions related to (local) operations between components shown inFIG. 3 and may control functions related to “visibility” of data units transmitted thoughinterface230. For example,VCPU360 may accumulate records associated with a flow table and/or sampled data units. For example,VCPU360 may receive a record, associated with a flow table entry, and/or sampled data units fromFFQ logic320. In one implementation,VCPU360 may include temporary storage, such as RAM and/or flash memory, to temporarily store the records and/or sampled data units.
VCPU360 may also transmit the records and/or sampled data units to an external device viaswitch350. For example,VCPU360 may receive flow table records and statistics fromFFQ logic320, aggregate and/or maintain the received flow table records and statistics, and export the aggregated flow table records and/or statistics to another component within network device104 (e.g., analyzer module240), or alternatively, to a device that is external tonetwork device104.VCPU360 may aggregate flow table records and/or statistics based on various parameters, such as communication protocol, port number, source and/or destination addresses, source and/or destination address prefixes, source and/or destination autonomous system (AS) prefixes, etc.VCPU360 may also perform management, accounting, or security processes, such as intrusion detection algorithms, analyses of successful to unsuccessful flows, etc.
Exemplary Functional Components of FFQ LogicFIG. 5 is a block diagram illustrating exemplary functional components ofFFQ logic320. As shown inFIG. 5,FFQ logic320 may include afabric interface510,flow table logic520, a flow table530, andsampling logic540. In another implementation,FFQ logic320 may include fewer, additional, different, or differently arranged functional components than those illustrated inFIG. 5. For example, in some implementations, one or more of the functional components ofFIG. 5 may be located external toFFQ logic320. Also, or alternatively, one or more of the functions described as performed by one of the functional components may be performed by another one of the functional components.
Fabric interface510 may include hardware, or a combination of hardware and software, that may provide an interface to PFE310,switch fabric220, and/or another component ofinterface230.Fabric interface510 may include one or more interfacing queues or buffers (not shown) that may temporarily store data units that have been processed byflow table logic520 and that await transmission fromFFQ logic320. In one implementation,fabric interface510 may include a separate queue for each output port. Additionally, or alternatively,fabric interface510 may include separate queues for different priority levels that may be assigned to the data units. Thus,fabric interface510 may include separate queues per port and per priority. In other implementations,fabric interface510 may include some other arrangement of queues.
Fabric interface510 may also include an arbiter that selects data units for transmission from the queues. In one implementation, the arbiter may use a fair selection technique based on data unit priority and/or output port availability. For example, the arbiter may select the highest priority data unit destined for an output port that is available to receive the data unit.
Flow table logic520 may include hardware, or hardware in combination with software, that may receive a data unit from PFE310, determine a flow identifier from the data unit (e.g., read the flow identifier from the data unit or generate the flow identifier based on information in the data unit), provide information regarding the data unit and the flow identifier to create and/or update information regarding the data flow in flow table530, and/or signal tosampling logic540 whether to sample data units associated with the data flow.
In one implementation,flow table logic520 may identify the flow identifier from information in the header of the data unit. For example, flowtable logic520 may construct the flow identifier from information in the data unit header that relates to information in the IP fields, such as the source IP address, the destination IP address, the source port, the destination port, and/or the L3 protocol type. In one implementation, the flow identifier may be calculated as a hash value of the information in the data unit header, and may be used to identify or create an entry in flow table530.Flow table logic520 may usepointer432 inpacket descriptor430 to locate the IP fields inheader portion420 of the data unit.
Flow table logic520 may, upon identification of the flow identifier associated with a data unit, determine if an entry corresponding to the flow identifier has been previously created in flow table530. For example, flowtable logic520 may compare the flow identifier to information in flow table530 to determine whether there is a match. If no entry exists, flowtable logic520 may create a corresponding entry in flow table530 and signalsampling logic540 to determine whether to sample data units corresponding to the data flow associated with the data unit. If, however, a corresponding entry had been previously created in flow table530 (i.e., at least one prior data unit belonging to the data flow had been previously received by network device104),flow table logic520 may update one or more fields in the corresponding entry to reflect the newly received data unit.
Flow table530 may be implemented within a memory device, such as one or more dynamic RAMs (DRAMs). Flow table530 may include a number of entries corresponding to data flows identified bynetwork device104. For example, each entry in flow table530 may include a flow identification field used to identify each data flow and other associated fields of information corresponding to a data flow (e.g., port or interface information, protocol information, etc.). Flow table530 may include information regarding a large number of data flows, such as over one million data flows.
FIG. 6 is a diagram of exemplary fields of flow table530. As shown inFIG. 6, flow table530 may include a number of flow table entries for each ofdata flows1 through y. Exemplary entries in flow table530 may include a flow identification (ID)field610, a layer 2 (L2)information field615, a layer 3 (L3)information field620, a layer 4 (L4)information field625, a dataunit counter field630, abyte counter field635, and atimer field640. In other implementations, an entry in flow table530 may include additional, fewer, or different fields.
Flowidentification field610 may include a unique, or a substantially unique, flow identifier associated with a particular data flow. For example, a flow identifier may include a value derived from certain information in a header of a data unit corresponding to the data flow. For example, the flow identifier may be constructed from information in the data unit header, such as the source IP address, the destination IP address, the source port, the destination port, and/or the L3 protocol type. In one implementation, the flow identifier may be calculated as a hash value of the information in the data unit header. The flow identifier may provide an efficient way to identify and locate data flows in flow table530.
L2 information field615 may include elements of L2 information, such as a source media access control (MAC) address associated with the data unit, a destination MAC address associated with the data unit, Ethertype information, or another form of L2 data.L3 information field620 may include elements of L3 information, such as source and destination IP addresses, an L3 protocol type (e.g., Transmission Control Protocol (TCP) or User Datagram Protocol (UDP)), or another form of L3 data.L4 information field625 may include one or more elements of L4 information, such as source and destination port information (which sometimes designates an application type associated with a data unit), or another form of L4 data.
Dataunit counter field630 may include information for accumulating and/or indicating a total number of data units, corresponding to a data flow, that have been passed throughinterfaces230 during a particular time period.Byte counter field635 may include information for accumulating and/or indicating a total number of bytes that have been transferred in the data flow during the particular time period.Timer field640 may include timing information, such as a timestamp, relating to data units received in the data flow. In one implementation, the timing information may include information regarding the time that the last data unit was received in the data flow. For example, each time that a data unit is received in a data flow, the information intimer field640 may be updated with a new timestamp value.
In one embodiment,L2 information field615 may include source and destination MAC addresses and/or Ethertype information,L3 information field620 may include source and destination IP addresses and a L3 protocol type, andL4 information field625 may include source and destination ports. The value oftimer field640, dataunit counter field630, andbyte counter field635 may be periodically reset or accumulated to provide a total count associated with a particular data flow.
Returning toFIG. 5, in an exemplary operation, flowtable logic520 may send certain information regarding entries in flow table530 to VCPU360 (FIG. 3). For example, whenflow table logic520 creates a new entry in flow table530,flow table logic520 may generate a flow creation record. In one implementation, a flow creation record may include information regarding the time that the entry is created in flow table530, the header of the data unit, the packet descriptor associated with the data unit, and/or bookkeeping information (e.g., the flow identifier or other information that may be useful to the operations performed by VCPU360).Flow table logic520 may include (or have access to) a clock and use this clock to identify the time at which the entry is created.
Flow table logic520 may periodically analyze the entries in flow table530 to identify entries associated with terminated data flows. The term “terminated data flow” may refer to a data flow for which a data unit has not been received in a particular threshold amount of time. For example, flowtable logic520 may use the information intimer field640 to identify entries associated with terminated data flows. Whenflow table logic520 identifies a terminated data flow in flow table530,flow table logic520 may generate a flow termination record. In one implementation, a flow termination record may include information regarding the time of termination, the flow identifier associated with the data flow, and a packet and/or byte count from flow table530.Flow table logic520 may include (or have access to) a clock, use this clock to identify the time at which the termination event occurred, and use this time as the time of termination for the flow termination record. Alternatively, flowtable logic520 may track the time at which the last data unit was received in the data flow and use this information as the time of termination for the flow termination record.
Flow table logic520 may send the flow creation and termination records to VCPU360. In one implementation,flow table logic520 may send the flow creation and termination records to VCPU360 in batches of M records (where M>1). In another implementation,flow table logic520 may send the flow creation and termination records to VCPU360 as individual records.
Sampling logic540 may include hardware, or hardware in combination with software, that may receive a signal fromflow table logic520 and determine whether to sample data units associated with a data flow. As explained above, flowtable logic520 may send a signal tosampling logic540 each time that flowtable logic520 creates a new entry in flow table530. In response to the signal fromflow table logic520,sampling logic540 may execute some function to determine whether to sample data units associated with the data unit (for which a data flow entry has been created in flow table530). In one implementation, the function may randomly select data flows to sample. In another implementation, the function may select data flows to sample based on an attribute of the data flows, such as the sources (or subnets) from which the data flows originate, the protocol type associated with the data flows, or some other data flow attribute. For example, the function may assign weights to data flows. In this implementation, the function may assign higher weights to a particular class of data flows (e.g., data flows associated with particular sources (or subnets)) than weights assigned to another class of data flows (e.g., associated with other sources (or subnets)). The function may then determine whether to sample a data flow based on the assigned weights.
Ifsampling logic540 identifies a data flow to sample,sampling logic540 may sample the initial X data units associated with the data flow (X≧1). The term “initial data units” may refer to the first data units transmitted for the data flow. The initial data units of a data flow carry the most useful information regarding the data flow. As a result,sampling logic540 may make a copy the initial X data units and send these data units toanalyzer module240 for deep inspection.
Exemplary Components of Analyzer ModuleFIG. 7 is a block diagram illustrating exemplary components ofanalyzer module240. As shown inFIG. 7,analyzer module240 may include aswitch710, a Visibility Network Processing Unit (VNPU)720, and aninterface730. In another implementation,analyzer module240 may include fewer, additional, different, or differently arranged components than those illustrated inFIG. 7. For example, in some implementations, one or more of the components ofFIG. 7 may be located external toanalyzer module240. Also, or alternatively, one or more of the functions described as performed by one of the components may be performed by another one of the components.
Switch710 may include an Ethernet switch, or another type of switch, that may receive data units and/or other information fromswitch350 of one ormore interfaces230.VNPU720 may include one or more processors, microprocessors, and/or processing logic (e.g., ASICs, FPGAs, etc.) that may perform network communications, management, and analysis functions. For example,VNPU720 may perform deep inspection (e.g., deep packet inspection) on sampled data units.VNPU720 may accumulate flow creation and termination records frommultiple interfaces230.VNPU720 may include long term storage to store the sampled data units and the accumulated records.
VNPU720 may match related information associated with a same data flow even when data units associated with the data flow are received and transmitted viadifferent interfaces230. In this case, certain header information in the data units may remain the same (e.g., source and destination IP addresses, source and destination ports, and L3 protocol type)—though some of the information may occur in different fields (e.g., the source IP address in one direction may be the destination IP address in the other direction, and vice versa). In one implementation,VNPU720 may send analysis results and/or accumulated information to a device that is external tonetwork device104.Interface730 may include a switch, such as an Ethernet switch, that may receive the analysis results and/or the accumulated information and send the information to the external device.
Communication PlanesFIG. 8 is a diagram illustrating exemplary communication planes innetwork device104. As shown inFIG. 8,network device104 may include multiple communication planes: a data plane, a control plane, and a visibility plane. Data communication may occur betweeninterfaces230 via the data plane. For example,interface230 may transfer a data unit to anotherinterface230 via the data plane. In one implementation, the communication on the data plane may occur viaswitch fabric220.
Control messages may be communicated betweeninterfaces230 andsystem control module210 via the control plane. For example,system control module210 andinterfaces230 may exchange exception and protocol messages, network statistics, and/or other types of control messages via the control plane. In one implementation, the communication on the control plane may occur via dedicated connections withinnetwork device104.
Visibility information (e.g., information relating to data flow monitoring) may be communicated betweeninterfaces230 andanalyzer module240 via the visibility plane. The visibility plane may be dedicated to the task of distilling information from flow table530, collecting the information, storing the information, and presenting the information. For example, interfaces230 may send information regarding data flow creation and/or termination, sampled data units, etc. toanalyzer module240 via the visibility plane. In one implementation, the communication on the visibility plane may occur via dedicated connections withinnetwork device104, such as via Ethernet connections.
FIG. 9 is a diagram illustrating exemplary components, ofnetwork device104, that may participate in communication on the visibility plane. As shown inFIG. 9,multiple interfaces230 may connect to one ormore analyzer modules240. Eachanalyzer module240 may connect to one ormore interfaces230. To facilitate communication betweeninterface230 andanalyzer module240 on the visibility plane,switch350, ofinterface230, may connect to switch710, ofanalyzer module240. In one implementation, the connection betweenswitch350 and switch710 may include an Ethernet connection.
Exemplary ProcessesFIGS. 10-14 illustrate flowcharts of exemplary processes for monitoring, processing, and/or sampling data unit(s) of a data flow. The processes illustrated inFIGS. 10-14 may be performed byFFQ logic320,VCPU360,VNPU720, and/or another component separate from or in conjunction withFFQ logic320,VCPU360, and/orVNPU720.
FIGS. 10 and 11 illustrate flowcharts of anexemplary process1000 for processing a data unit.Process1000 may begin with a data unit being received (block1010) (FIG. 10). For example,FFQ logic320 may receive a data unit from PFE310. As explained above, the data unit may include adata portion410, aheader portion420, and a packet descriptor portion430 (FIG. 4).
The data flow associated with the data unit may be identified (block1020). For example, flowtable logic520 may determine a flow identifier from the data unit (e.g., read the flow identifier from the data unit or generate the flow identifier from information in the data unit). As described above, flowtable logic520 may identify the flow identifier from information in the header of the data unit, such as the source IP address, the destination IP address, the source port, the destination port, and/or the L3 protocol type. In one implementation, the flow identifier may be calculated as a hash value of the information in the data unit header.Flow table logic520 may identify the information to use to generate the flow identifier based onpointer432 inpacket descriptor portion430.
It may be determined whether an entry, for the data flow, already exists in flow table530 (block1030). For example, flowtable logic520 may search flow table530, using the flow identifier, to determine whether flow table530 includes an entry with a matching flow identifier in, for example, flowidentification field610. If flow table530 includes an entry with a matching flow identifier, this may mean that an entry for the data flow has already been created. If flow table530 does not include an entry with a matching flow identifier, this may mean that an entry for the data flow does not exist.
If flow table530 already includes an entry for the data flow (block1030—YES), the entry in flow table530 may be modified (block1040). For example, flowtable logic520 may update information in the entry of flow table530. In one implementation,flow table logic520 may update flow statistics, such as the data count in dataunit counter field630, the byte count inbyte counter field635, and/or timing information intimer field640 of flow table530.
If flow table530 does not include an entry for the data flow (block1030—NO), an entry may be created in flow table530 (block1050). For example, flowtable logic520 may store various information, such as the information described above with regard toFIG. 6, in an entry of flow table530.
A flow creation record may be generated (block1060). For example, flowtable logic520 may generate a flow creation record that includes the time that the data flow entry was created in flow table530, all or a subset ofheader portion420 of the data unit,packet descriptor portion430 of the data unit, and/or bookkeeping information, such as the flow identifier.
The flow creation record may be sent to VCPU360 (block1070). For example, flowtable logic520 may send the flow creation record to VCPU360 when the flow creation record is generated. In another implementation,flow table logic520 may send flow creation records to VCPU360 in batch (e.g., M flow creation records at a time). In yet another implementation,flow table logic520 may send flow creation records in batch with flow termination records to VCPU360.
It may be determined whether to sample data units associated with the data flow (block1110) (FIG. 11). For example, flowtable logic520 may send a signal tosampling logic540 to indicate, tosampling logic540, that a new data flow has been received.Sampling logic540 may execute a function that determines whether to select a data flow for sampling. In one implementation,sampling logic540 may execute a random function that selects a particular percentage of all data flows for sampling. In another implementation,sampling logic540 may execute a function that assigns weights to data flows based on an attribute of the data flows. For example, certain data flows (e.g., data flows associated with particular sources and/or subnets) may be assigned higher weights than other data flows (e.g., data flows associated with other sources and/or subnets).Sampling logic540 may then select a data flow for sampling based on the weights assigned to the data flows. Alternatively, or additionally, certain data flows may be eliminated altogether from consideration for sampling (e.g., certain data flows may be known not to include information of interest).
If the data flow is not be sampled (block1110—NO), thenprocess1000 may continue atblock1010 where a next data unit is received. If the data flow is to be sampled (block1110—YES), then the initial X data units of the data flow may be sampled (block1120). For example,sampling logic540 may mark the data flow for sampling, and make a copy of the initial X data units associated with the data flow (as the data units are received) and send these data unit copies toVNPU720. In one implementation,sampling logic540 may send the data unit copies directly to VNPU720 viaswitches350 and710. In another implementation,sampling logic540 may send the data unit copies to VNPU720 viaVCPU360 andswitches350 and710.Process1000 may continue atblock1010 where a next data unit is received.
FIG. 12 illustrates a flowchart of anexemplary process1200 for generating a flow termination record.Process1200 may begin with an analysis of the entries in flow table530 (block1210). For example, flowtable logic520 may periodically analyze the contents of flow table530 to identify entries corresponding to active data flows (e.g., data flows for which data units have been received within a threshold amount of time) and terminated data flows (e.g., data flows for which no data units have been received for at least the threshold amount of time).
An entry, associated with a terminated data flow, may be identified (block1220). For example, flowtable logic520 may analyze the information in, for example,timer field640 of flow table530 to determine that at least the threshold amount of time has passed since the last data unit was received in the data flow. Since the data flow is considered terminated, the entry may be removed from flow table530 or marked for removal by a garbage collection process.
A flow termination record may be generated (block1230). For example, flowtable logic520 may generate a flow termination record that includes the time that the data flow was terminated, the flow identifier fromflow identification field610, the data unit count value in dataunit counter field630, and/or the byte count value inbyte counter field635. As explained above, flowtable logic520 may use information regarding when the timeout event occurred or information regarding when the last data unit was received for the data flow as the time that the data flow was terminated.
The flow termination record may be sent to VCPU360 (block1240). For example, flowtable logic520 may send the flow termination record to VCPU360 when the flow termination record is generated. In another implementation,flow table logic520 may send flow termination records to VCPU360 in batch (e.g., M flow termination records at a time). In yet another implementation,flow table logic520 may send flow termination records in batch with flow creation records to VCPU360.
FIG. 13 illustrates a flowchart of aprocess1300 for processing flow creation and termination records.Process1300 may begin with the accumulation of flow creation and termination records (block1310). For example, as explained above, flowtable logic520 may send flow creation and termination records to VCPU360.VCPU360 may receive the flow creation and termination records and store the records in temporary storage.
The flow creation and termination records may be processed (block1320). For example,VCPU360 may correlate flow creation and termination records associated with a same data flow. For example, even though data units, corresponding to the same data flow, may transitdifferent interfaces230 in different directions, information regarding these data units may be correlated sinceheader portion420 of the data units carry the same information (though perhaps in a different order).
Through this aggregation and correlation of flow creation and termination records,VCPU360 may create a history of which data flows existed at any particular point in time, determine when the data flows were created, determine when the data flows were terminated, identify the sources and destinations associated with the data flows, determine how many data units/bytes were sent on the data flows, determine how many active data flows existed at a particular point in time, determine what the flow creation rate is for a particular source, determine what the amount of bandwidth and/or data units is for aggregate data flows (e.g., data flows associated with applications running on a same server), etc. A benefit of this is that there is no need to decide beforehand what data flows are of interest. Information is collected and stored, in flow table530, for all data flows. This information may be parsed and analyzed in many different ways for reasons relating to security, management, accounting, or other reasons.
VCPU360 may also perform security and/or network functions. For example,VCPU360 may determine whether a particular source (e.g., a particular endpoint device102) is responsible for the creation of more than a particular quantity of data flows during a period of time, which might be a sign of an attack or a misconfiguration in the network. In another implementation,VCPU360 may determine the ratio of the number of successful data flows to the number of unsuccessful data flows associated with a particular source. Whether establishment of a data flow is successful or unsuccessful may be determined, for example, by monitoring the initial data units exchanged between a source and a destination (e.g., the transmission control protocol (TCP) messages exchanged in a three-way handshake). It might be useful forflow table logic520 to track successful and unsuccessful data flows in flow table530. In this case, flow table530 may include an additional field that indicates whether a data flow was successfully or unsuccessfully established.Flow table logic520 may send information regarding successful and unsuccessful data flows to VCPU360 as part of the flow creation or termination records. Such a technique is different from existing solutions that are based on the detection of signatures. A problem with detecting signatures is that the signatures have to be known beforehand. This is not an issue when monitoring data flows that are successfully and unsuccessfully established.
The flow creation and termination records and/or the process results (i.e., the results from block1320) may be sent to VNPU720 (block1330). For example,VCPU360 may periodically send flow creation and termination records to VNPU720. Alternatively, or additionally,VCPU360 may also send the process results, fromblock1320, toVNPU720.VCPU360 may send the flow creation and termination records and/or the process results to VNPU720 viaswitches350 and710.
FIG. 14 illustrates a flowchart aprocess1400 for processing flow creation and termination records and sampled data units.Process1400 may begin with the reception of flow creation and termination records (block1410). For example, as explained above,VCPU360 may accumulate flow creation and termination records.VCPU360 may periodically send the flow creation and termination records to VNPU720 viaswitches350 and710.
Sampled data units may be received (block1420). As explained above,sampling logic540, ofFFQ logic320, may select data flows for sampling and sample the initial X data units associated with the selected data flows.Sampling logic540 may send the sampled data units to VNPU720 viaswitches350 and710.
Deep inspection of the sampled data units may be performed (block1430). For example,VNPU720 may perform a deep inspection of the sampled data units. Deep inspection may reveal certain information about a data flow, such as the identity of an application involved in the data flow. Prior techniques used port number information to identify an application involved in a data flow. Port number information is no longer reliable, however, because standard ports may carry all kinds of traffic, including traffic that is unrelated to the traffic that conventionally has been transmitted to these ports. Deep inspection may alleviate this issue.
The inspection results and the creation and termination records may be stored (block1440). For example,VNPU720 may store this information in long-term storage.VNPU720 may make this information available for later analysis. In one implementation,VNPU720 may correlate information associated with data units corresponding to the same data flow. For example, even though data units, corresponding to the same data flow, may transitdifferent interfaces230 in different directions, information regarding these data units may be correlated sinceheader portion420 of the data units carry the same information (though perhaps in a different order).
Global Traffic AnalysisFIG. 15 is a diagram of an exemplary globaltraffic analysis system1500. As shown inFIG. 15, globaltraffic analysis system1500 may include aglobal traffic analyzer1510 connected tomultiple VNPUs720. EachVNPU720 may be associated with thesame network device104 or adifferent network device104.VNPUs720 may connect toglobal traffic analyzer1510 via interface730 (FIG. 7).
Global traffic analyzer1510 may aggregate information fromVNPUs720.Global traffic analyzer1510 may correlate information associated with data units corresponding to the same data flow. For example, even though data units, corresponding to the same data flow, may transitdifferent network devices104 in different directions, information regarding these data units may be correlated sinceheader portion420 of the data units carry the same information (though perhaps in a different order).
Global traffic analyzer1510 may present a user interface to an operator to permit the operator to submit queries for information of interest. In response to a query,global traffic analyzer1510 may search the information, thatglobal traffic analyzer1510 aggregated fromVNPUs720, to identify information that satisfies the query.
Global traffic analyzer1510 may also include a report generator that may generate various reports in which the operator may be interested. For example, the operator may input certain criteria, associated with information in which the operator is interested, andglobal traffic analyzer1510 may generate and present a report that satisfies the operator's criteria.
CONCLUSIONImplementations, described herein, may analyze all traffic received by a network device with no performance impact and no increase in latency. As described above, data, regarding all data flows received by the network device, is stored in a flow table without impacting the throughput of the network device. Implementations, described herein, may provide mechanisms for parsing the vast amount of data in the flow table. For example, information, regarding new data flows and terminated data flows, may be sent to a processing unit for analysis. Also, certain data flows may be selected for sampling, and the initial data units, associated with the selected data flows, may be copied and sent to the processing unit for analysis. Information from multiple interfaces and/or network devices may be accumulated and stored in a searchable format. Thus, a network operator may easily obtain information relating to management, accounting, security, or other matters of interest.
The foregoing description provides illustration and description, but is not intended to be exhaustive or to limit the invention to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of the invention.
For example, while series of blocks have been described with regard toFIGS. 10-14, the order of the blocks may be modified in other implementations. Further, non-dependent blocks may be performed in parallel.
Also, certain portions of the implementations have been described as “logic” or a “component” that performs one or more functions. The terms “logic” or “component” may include hardware, such as a processor, an ASIC, or a FPGA, or a combination of hardware and software (e.g., software running on a processor).
Further, a flow table has been described. The term “table,” as used herein, may refer to any searchable form or arrangement of data within a memory.
It will be apparent that aspects described herein may be implemented in many different forms of software, firmware, and hardware in the implementations illustrated in the figures. The actual software code or specialized control hardware used to implement aspects does not limit the embodiments. Thus, the operation and behavior of the aspects were described without reference to the specific software code—it being understood that software and control hardware can be designed to implement the aspects based on the description herein.
Even though particular combinations of features are recited in the claims and/or disclosed in the specification, these combinations are not intended to limit the disclosure of the invention. In fact, many of these features may be combined in ways not specifically recited in the claims and/or disclosed in the specification. Although each dependent claim listed below may directly depend on only one other claim, the disclosure of the invention includes each dependent claim in combination with every other claim in the claim set.
No element, act, or instruction used in the present application should be construed as critical or essential to the invention unless explicitly described as such. Also, as used herein, the article “a” is intended to include one or more items. Where only one item is intended, the term “one” or similar language is used. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise.