Patent Publication Number: US-11032151-B1

Title: Methods, systems, and computer readable media for providing dynamically configurable, distributed network visibility device

Description:
TECHNICAL FIELD 
     The subject matter described herein relates to implementing network visibility device features. More particularly, the subject matter described herein relates to methods, systems, and computer readable media for providing a dynamically configurable, distributed network visibility device. 
     BACKGROUND 
     Network visibility devices, such as network packet brokers and network tool optimizers, are used to monitor packets in a communications network and provide copies of the packets to one or more network tools. Network visibility devices often have diverse feature sets that require firmware updates, updates to the operating system, or both to implement. Examples of common network visibility device features include packet filtering, packet de-duplication, packet replication, masking, custom statistics generation, etc. 
     The turnaround time for adding a new feature to a network visibility device is on the order of months. It is desirable to be able to more rapidly develop and deploy network visibility device features. 
     Accordingly, there exists the need for a dynamically configurable network visibility device that avoids at least some of the difficulties associated with the development cycles of adding new features to a conventional network visibility device. 
     SUMMARY 
     The subject matter described herein includes methods, systems, and computer readable media for providing a dynamically configurable, distributed network visibility device. One method for providing a dynamically configurable, distributed network visibility device includes providing at least one target network visibility device for monitoring network packets, wherein the at least one target network visibility device includes a P4-configurable switching module. The method further includes providing a controller for receiving a P4 code package including or compilable into a P4 device image and one or more non-P4 plugins. The method further includes loading the P4 device image into the P4 configurable switching module of the at least one target network visibility device and using the P4 device image to configure the configurable switching module of the at least one target network visibility device to implement a desired network visibility device feature. The controller and/or the at least one target network visibility device uses the non-P4 plugin(s) to render a user interface or to extend functionality of the at least one target network visibility device. 
     In one example, providing at least one target network visibility device includes providing at least one network packet broker. 
     In another example, providing a least one target network visibility device includes providing at least one network tool optimizer. 
     In yet another example, the P4-configurable switching module comprises a P4-configurable hardware or firmware module. 
     In yet another example, the P4-configurable switching module comprises a virtual P4-configurable switching module. 
     In yet another example, the non-P4 plugin automatically renders at least one user interface element for displaying packet statistics. 
     In yet another example, the at least one user interface element comprises a packet statistics table and a popup graph accessible via the packet statistics table. 
     In yet another example, the non-P4 plugin transforms a user-facing load balancing table into a P4 runtime load balancing table. 
     In yet another example, the non-P4 plugin automatically initializes values in a network address table. 
     In yet another example, the plugin extends the functionality of the target network visibility device without requiring modification of code resident on the target network visibility device. 
     The subject matter described herein further includes a system for providing a dynamically configurable, distributed network visibility device. The system includes at least one target network visibility device for monitoring network packets, wherein the at least one target network visibility device includes a P4-configurable switching module. The system further includes a controller for receiving a P4 code package including or compilable into a P4 device image and a non-P4 plugin. The at least one target network visibility device loads the P4 device image into the configurable switching module and uses the P4 device image to configure the configurable switching module to implement a desired network visibility device feature. The controller and/or the at least one target network visibility device uses the non-P4 plugin(s) to render a user interface or to extend functionality of the at least one target network visibility device. 
     In one example, the at least one target network visibility device includes at least one network packet broker. 
     In another example, the at least one target network visibility device includes at least one network tool optimizer. 
     In yet another example, the P4-configurable switching module comprises a P4-configurable application specific integrated circuit. 
     In yet another example, the P4-configurable switching module comprises a virtual P4-configurable switching module. 
     In yet another example, the non-P4 plugin automatically renders at least one user interface element for displaying packet statistics. 
     In yet another example, the at least one user interface element comprises a packet statistics table and a popup graph accessible via the packet statistics table. 
     In yet another example, the non-P4 plugin transforms a user-facing load balancing table into a P4 runtime load balancing table. 
     In yet another example, the non-P4 plugin automatically initializes values in a network address table. 
     According to another aspect of the subject matter described herein, a non-transitory computer readable medium having stored thereon executable instructions that when executed by a processor of a computer controls the computer to perform steps. The steps include providing at least one target network visibility device for monitoring network packets, wherein the target network visibility device includes a P4-configurable switching module. The steps further include providing a controller for receiving a P4 code package including or compilable into a P4 device image and a non-P4 plugin. The steps further include loading the P4 device image into the P4-configurable switching module of the at least one target network visibility device to configure the P4-configurable switching module of the at least one target network visibility device to implement a desired network visibility device feature. The steps further include using the non-P4 plugin(s) to generate or render a user interface or to extend functionality of the at least one target network visibility device. 
     The subject matter described herein can be implemented in software in combination with hardware and/or firmware. For example, the subject matter described herein can be implemented in software executed by a processor. In one exemplary implementation, the subject matter described herein can be implemented using a non-transitory computer readable medium having stored thereon computer executable instructions that when executed by the processor of a computer control the computer to perform steps. Exemplary computer readable media suitable for implementing the subject matter described herein include non-transitory computer-readable media, such as disk memory devices, chip memory devices, programmable logic devices, and application specific integrated circuits. In addition, a computer readable medium that implements the subject matter described herein may be located on a single device or computing platform or may be distributed across multiple devices or computing platforms. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       Preferred embodiments of the subject matter described herein will now be explained with reference to the accompanying drawings, wherein like reference numerals represent like parts, of which: 
         FIG. 1  is a network diagram of a dynamically configurable, distributed Network visibility system; 
         FIG. 2  is a block diagram illustrating different types of target devices on which network visibility features can be implemented; 
         FIG. 3  is a flow chart of an exemplary process for implementing a dynamically configurable, distributed network visibility device; 
         FIG. 4  is a diagram illustrating transformation of a user-facing load balancing table into a P4 runtime load balancing table; and 
         FIG. 5  is a diagram illustrating the use of P4 code in combination with a plugin to generate a packet statistics table and a pop-up graph. 
     
    
    
     DETAILED DESCRIPTION 
       FIG. 1  is a network diagram illustrating a dynamically configurable, distributed network visibility system. In the illustrated example, the system includes one or more target network visibility devices  100  that implement network visibility features. The network visibility devices  100  may be network packet brokers or network tool optimizers. In the illustrated example, each network visibility device  100  includes network ports  102  for receiving packets from the monitored network and providing packets back to the monitored network. Each target network visibility device  100  may also include one or more tool ports  104  that provide monitored packets to one or more network tools  106 . An example of the network tool is a network security tool or a network performance monitoring tool. 
     Each network visibility device  100  may also include a configurable switch module  108 . In one example, each configurable switch module  108  maybe a Tofino or Tofino 2 switch module available from Barefoot Networks (www.barefootnetworks.com). The Tofino and Tofino 2 are application specific integrated circuits (ASICs) that are configurable using the P4 programming language, which enables rapid feature development. The P4 programming language is maintained by the P4 Language Consortium and is published at https://p4.org. In an alternate implementation, rather than implementing configurable switch modules  108  using the Tofino or Tofino 2 devices from Barefoot Networks, each configurable switch module  108  may be a P4 configurable ASIC, smart NIC or FPGA available from a different manufacturer or a virtual P4-configurable device. 
     In  FIG. 1 , the system further includes a network visibility device controller  110 . Network visibility device controller  110  deploys network visibility code to target devices  100  and presents a user interface for accessing and controlling network visibility device features. In the example illustrated in  FIG. 1 , network visibility device controller  110  receives P4 source code packages from a P4 source code library  112 . Each package may implement a desired network visibility device feature. The packages may also include P4 code annotation, which may be used to automatically generate a user interface (UI), including a command line interface (CLI), a graphical user interface (GUI) or combination of a CLI and a GUI. As such, network visibility device controller  110  may include a UI generator  114  that automatically generates a network visibility device user interface  116  based on annotations to P4 source code. The annotations may reference non-P4 plugins that are used to enhance or provide network visibility device functionality. Examples of P4 code annotation and user interfaces that may be generated by UI generator  114  will be described in detail below. 
     Network visibility device controller  110  may also receive and deploy plugins  116  that operate with P4 images to the enhance the functionality provided by network visibility devices. Plugins may be written in programming languages other than P4 (such as Python) to provide functionality that is not provided by the P4 programming language. Examples of plugins will also be provided below. 
       FIG. 2  is a diagram illustrating the examples of target devices that can be configurable using the P4 runtime environment. The P4 runtime environment is an application programming interface (API) that may be presented by a P4-configurable device. In the illustrated example, controllers  110  provide P4 images compliant with the P4 run time API to a plurality of different targeted target devices. The target devices that may be used to implement the network visibility devices  100  illustrated in  FIG. 1  include a P4 appliance/white box  200 , P4 blades  202  in a rack or other type of system, P4 smart network interface cards (NICs)  204 , P4 compliant data center equipment  206 , and virtual network functions  208  that include virtual switches that are P4-configurable. Any of devices  200 ,  202 ,  204 ,  206 , and  208  may be used implement network visibility features and may be dynamically configured using the methodology described herein. 
       FIG. 3  is a flow chart illustrating an exemplary process for providing a dynamically configurable, distributed network visibility device. Referring to  FIG. 3 , in step  300 , the process includes providing at least one target network visibility device for monitoring network packets, where the target network visibility device includes a P4-configurable switching module for controlling switching of monitored packets to one or more network tools. For example, the process may include providing one or more target network visibility devices  100  that perform network visibility functions, such as network tool optimizer or network packet broker functions. The target network visibility devices may include P4-configurable switching modules, such as Tofino ASICs or other P4-configurable switching modules. 
     In step  302 , the process includes providing a controller for receiving a P4 code package including or compilable into a P4 device image and a non-P4 plugin. In one example, the P4 code package may be a P4 source code package with annotation referencing a non-P4 plugin. In another example, the P4 code package may be a precompiled version of the P4 device image and the plugin. Controller  110  illustrated in  FIG. 1  may receive P4 packages that reference non-P4 plugins from developers. 
     In  FIG. 1 , controller  110  is located remotely from target devices  100 , so controller may communicate the P4 device images to target devices  110 . Accordingly, in such an implementation, in step  304 , the process includes communicating the P4 device image and to at least one target network visibility device. For example, controller  110  may communicate the P4 device image to target network visibility devices  100  by transmitting the P4 device image over a network to each target network visibility device  100 . In another implementation, controller may be implemented on each of target network visibility devices  100 . In such an implementation, step  304  may be omitted. 
     In step  306 , the process includes loading the P4 device image into the configurable switching element of at least one target network visibility device to dynamically configure the P4-configurable switching element of the at least one target network visibility device to implement a desired network visibility device feature. For example, each target device  100  illustrated in  FIG. 1  may load the P4 device image received from controller  110  and configure their respective configurable switching modules  108  to implement desired network visibility device features. Examples of network visibility device features that may be implemented include packet filtering features, packet de-duplication features, packet statistics generation features, etc. 
     In step  308 , the process includes using the non-P4 plugin to render a user interface or to extend functionality of the at least one target network visibility device. In one example, the plug-in code is used by controller  110  to automatically render a user interface, for example, for accessing packet statistics generated by one or more of target network visibility devices  100 . In another example, the plugin code may be loaded into the target network visibility devices themselves to extend functionality of the devices. For example, as will be described in detail below, a transform plugin may be used to transform a user-facing load balancing table into a P4 runtime table used to load balance packets among network visibility device ports. Loading the plugin code into controller  110  and/or network visibility devices  100  is intended to be within the scope of the subject matter described herein. 
     Examples of the uses of P4 code in combination with plugin code to implement network visibility device features will now be described. 
     Example 1—Transform Plugin 
     In this case, the application software on controller  110  would invoke a plugin module provided with the P4 code from the P4 developers (non-P4 code, e.g., Python), which would allow one to extend the behavior of the application framework of network visibility devices  100  or controller  110  without modifying the main code (e.g., the operating system (OS) and other target network visibility device resident code). Instead, network visibility devices  100  or controller  110  execute the plugin to transform a user-friendly, user-facing configuration table (load balance weights) into the actual run-time P4 table which is user-unfriendly. The actual details of the rendered user-facing table can be implemented in the plugin itself. 
       FIG. 4  conceptually illustrates the user-facing and P4 runtime tables. In  FIG. 4 , a user-facing table  400  contains physical ports of a network visibility device and corresponding load balancing weights to be assigned to the physical ports. In order to implement such load balancing at runtime, a runtime table may include relative numbers of entries that correspond to the weights in user table  400 . For example, the weight assigned to physical port 1.1 in user-facing table  400  is one and the weight assigned to physical port 1.2 is two. In runtime table  402 , logical port 0x52 corresponds to physical port 1.2 and logical port 0x51 corresponds to physical port 1.1. Because physical port 1.2 is weighted twice as much as physical port 1.1, entries corresponding to logical port 0x52 appear twice as often in runtime table  402  as logical port 0x51. Runtime table  402  illustrated in  FIG. 4  may include as many as 1,024 weighted entries and would be time consuming to be filled manually. Real-world implementations could have such tables which are orders of magnitude larger than this. A non-P4 plugin can be used to transform user-facing table  400  into P4 runtime table  402 . 
     The following P4 code references the plugin that transforms the user-friendly table into the P4 runtime table. In the code example, the lines preceded by the “@” symbol represent annotations which reference the non-P4 plugin used to transform the user-facing table into the P4 runtime table. The remaining code is a P4 code snippet which defines a table of size  1024 , whose table index is some hash value computed earlier in the code. It is the plugin&#39;s responsibility to populate this table with a number of port entries proportional to their relative load-balancer weights. The P4 info snippet shown is metadata created by the P4 compiler from the P4 code. The P4Info is used by the controller as part of the mechanism to access (read and write) the table in the target network visibility device. 
     P4 Code: 
     @plugin(“‘name’:‘xform_lb_tbl’, ‘type’:‘xform’”) 
     table lb_port_tbl { 
     key={ 
     meta.lb_hash: exact; 
     } 
     actions={ 
     set_hashed_lb_port; 
     } 
     size=1024; 
     P4 Info: 
     tables { 
     
         
         
           
             preamble {
           id: 33619954   name: “lb_port_tbl”   alias: “lb_port_tbl”   
         
             annotations: “@plugin(\“name:xform_lb_tbl,type:xform\”)” 
           
         
       
    
     } 
     The following example is a skeleton of the non-P4 transform plugin that may be used to generate the P4 runtime table. 
     Example Python Plugin (Skeleton): 
     class xform_lb_tbl(P4rt_Xform): 
     ′ ′ ′ 
     This class transforms a user-facing table of ports and relative weights 
     into a weighted-entry load balancing table. 
     ′ ′ ′ 
     def_init_:
         P4rt_Xform.init( )       

     def write_tbl(port_weight_tbl,1024):
         p4_tbl=xform_to_p4(port_weight_tbl,1024)   write_tbl_to_device(‘lb_port_tbl’, p4_tbl) # parent method—write data to device       

     def xform_to_p4(port_weight_tbl,size):
         p4_tbl=[ ]   # Algorithm to create weighted entry table data not shown   . . .   return p4_tbl       

     Example 2—Autorendering Pop-Up Graph Widgets 
     In this example, the application framework of the target network visibility device or the controller can auto-render a statistics table with built-in sparkline graphs (https://en.wikipedia.org/wiki/Sparkline) which embed a hyperlink to invoke a full-sized zoomable graph.  FIG. 5  illustrates an example of a statistics table  500 , a sparkline graph  502 , and corresponding code  504  including annotations referencing a plugin that can be used to generate table  500  and graph  502 . The following code is the same code  504  illustrated in  FIG. 5  that can be used to generate table  500  and graph  502 . The lines of code preceded with the “@” character are annotations that reference the plugin. The remaining P4 code defines fields in the statistics table. The P4 info is metadata generated by the P4 compiler describing the statistics table and sparkline graph accessible via the table. 
     @autorender(“‘name’:‘Ingress Port 
     Stats’, ‘attr’:‘[table,sparkline,zoom]’”) 
     Counter&lt;bit&lt;32&gt;, PortId_t&gt;(32w32768, 
     CounterType_t.PACKETS_AND_BYTES) ig_port_stats; 
     action do_ig_port_stats( ) { 
     ig_port_stats.count(meta.rxport); 
     } 
     table ig_port_stats_tbl { 
     actions={
         do_ig_port_stats;       

     } 
     size=1; 
     default_action=do_ig_port_stats( ); 
     } 
     P4 Info: 
     externs { 
     extern_type_id: 131 
     extern_type_name: “Counter” 
     instances {
         preamble {
           id: 2197879518   name: “process_ig_port_stats.ig_port_stats”   alias: “ig_port_stats”   annotations: “@autorender(\”\‘name\’:\‘Ingress Port Stats\’,\‘attr\’:\‘[table,sparkline,zoom]\’\“)”   
           }       

     Example 3—Table Initialization Plugin 
     In this example, the P4 code contains a table which requires initialization at P4-program load/startup phase using an algorithm. The annotation in the P4 code causes the software application framework in the target network visibility device, or the controller, to invoke a plugin distributed with the compiled P4 code, which can generate the required values to populate the table. The software application framework of the target network visibility device or controller is not required to know how to initialize the table. Only the P4 code developer is required to know the steps for table initialization, and those steps can be implemented by the plugin referenced by P4 code annotation. In the example, the P4 code contains an annotation that references the non-P4 plugin used to initialize values in a destination medium access control (MAC) rewrite table. Based on the values of the table keys, the MAC will be modified. The table can be generated statically using an algorithm specified in the plugin. The P4 info is metadata created by the P4 compiler and causes the application framework to invoke the plugin, which will in turn populate the destination MAC rewrite table with required data values. 
     P4 Code: 
     @plugin(“name:rewrite_dmac_tbl,type:init”) 
     table rewrite_dmac_tbl { 
     key={ 
     meta.inner_tunnel_type: exact; 
     meta.lb_type:exact; 
     meta.lb_port_group:exact; 
     P4 Info: 
     tables { 
     preamble {
         id: 33578275   name: “rewrite_dmac”   alias: “rewrite_dmac”
 
annotations: “@plugin(\“name:rewrite_dmac_tbl,type:init\”)”
       

     } 
     The following is an example of the non-P4 plugin used to populate the destination MAC address table. 
     
       
         
           
               
               
               
             
               
                   
                   
               
             
            
               
                   
                   
                  class rewrite_dmac_tbl(P4rt_Init):  
               
               
                   
                   
                   ′′′ 
               
               
                   
                   
                   This class initializes the rewrite_dmac table with  
               
               
                   
                   
                 static values  
               
               
                   
                   
                   ′′′ 
               
               
                   
                   
                   def __init__:  
               
               
                   
                   
                   P4rt_Init ( )  
               
               
                   
                   
                  def write_tbl ( ):  
               
               
                   
                   
                   p4_tbl = generate_data ( )  
               
               
                   
                   
                   write_tbl_to_device(′rewrite_dmac′, p4_tb1) # 
               
               
                   
                   
                 parent method - write data to P4 device tables  
               
               
                   
                   
                  def generate_data ( ):  
               
               
                   
                   
                   p4_tbl = [ ]  
               
               
                   
                   
                   for t in range (4):  
               
               
                   
                   
                    for g in range (8):  
               
               
                   
                   
                     b = ((t &lt;&lt; 6) + (g&lt;&lt;2) + 2)&lt;&lt;40  
               
               
                   
                   
                     p4_tbl.append( [t,g,b])  
               
               
                   
                   
                    return p4_tbl 
               
               
                   
                   
               
            
           
         
       
     
     Thus, using P4 code in combination with plugins, the time to implement new network visibility device features is decreased over the conventional feature development pipeline. Using plugins also allows network visibility functionality to be extended beyond that provided by P4 code alone and without requiring changes to native network visibility device software, such as operation system software. 
     It will be understood that various details of the presently disclosed subject matter may be changed without departing from the scope of the presently disclosed subject matter. Furthermore, the foregoing description is for the purpose of illustration only, and not for the purpose of limitation.