US20140153577A1 - Session-based forwarding - Google Patents
Session-based forwarding Download PDFInfo
- Publication number
- US20140153577A1 US20140153577A1 US13/918,748 US201313918748A US2014153577A1 US 20140153577 A1 US20140153577 A1 US 20140153577A1 US 201313918748 A US201313918748 A US 201313918748A US 2014153577 A1 US2014153577 A1 US 2014153577A1
- Authority
- US
- United States
- Prior art keywords
- route
- session
- index
- packet
- neighbor
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/74—Address processing for routing
- H04L45/745—Address table lookup; Address filtering
- H04L45/748—Address table lookup; Address filtering using longest matching prefix
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/28—Flow control; Congestion control in relation to timing considerations
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L49/00—Packet switching elements
- H04L49/30—Peripheral units, e.g. input or output ports
- H04L49/3009—Header conversion, routing tables or routing tags
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/56—Routing software
- H04L45/566—Routing instructions carried by the data packet, e.g. active networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/12—Avoiding congestion; Recovering from congestion
- H04L47/122—Avoiding congestion; Recovering from congestion by diverting traffic away from congested entities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/19—Flow control; Congestion control at layers above the network layer
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/09—Mapping addresses
- H04L61/25—Mapping addresses of the same type
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0272—Virtual private networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
- H04L63/101—Access control lists [ACL]
Definitions
- the present disclosure relates to networking processing performance of a symmetric multiprocessing (SMP) network architecture.
- SMP symmetric multiprocessing
- the present disclosure relates to a system and method for providing session-based forwarding in a pipelined forwarding model.
- a symmetric multiprocessing (SMP) architecture generally is a multiprocessor computer architecture where two or more identical processors can connect to a single shared main memory.
- SMP architecture can apply to the CPU cores.
- multiple networking CPUs or CPU cores can receive and transmit network traffic. While receiving and transmitting the network traffic, the system may maintain a flow-based engine that transmits the network traffic on a per-flow basis. Each flow is uniquely identified by a session key.
- a network routing system typically uses longest prefix match to perform route lookup. Specifically, the routing system can look up in a route table for next hop information based on which Internet Protocol (IP) address provides the longest prefix match to the destination IP address.
- IP Internet Protocol
- the longest prefix match lookup may incur excessive cost when the packets have long IP addresses, e.g., in the scenario of IPv6 network.
- updating the route table to reflect the route changes in the flow table can be costly too.
- the rate of network convergence in the event of route changes may be slow with the conventional routing mechanisms that update the route information in the flow table.
- FIG. 1 is a diagram illustrating an exemplary wireless network environment according to embodiments of the present disclosure.
- FIG. 2 illustrates an exemplary architecture at multiple processing planes according to embodiments of the present disclosure.
- FIG. 3 illustrates an exemplary network forwarding process according to embodiments of the present disclosure.
- FIG. 4 is a diagram illustrating exemplary routing tables maintained in a shared memory according to embodiments of the present disclosure.
- FIG. 5 illustrates exemplary layer 3 and/or layer 2 packet flow data structure according to embodiments of the present disclosure.
- FIG. 6 illustrates an exemplary route catch table according to embodiments of the present disclosure.
- FIGS. 7A-7C illustrates various routing tables according to embodiments of the present disclosure.
- FIG. 9 illustrates an exemplary trie data structure used in session-based forwarding according to embodiments of the present disclosure.
- FIGS. 10A-10B illustrate processes for session-based forwarding according to embodiments of the present disclosure.
- FIG. 11 is a block diagram illustrating a system of session-based forwarding according to embodiments of the present disclosure.
- Embodiments of the present disclosure relate to networking processing performance.
- the present disclosure relates to a system and method for providing efficient session-based forwarding with multiple networking central processing unit (CPU) cores.
- the system achieves efficient session-based forwarding by maintaining a version associated with each route in a session table and determining whether a route is stale based on the value of the version associated with each route.
- the conventional route cache table that enumerates all destinations on the shared memory is trimmed down to regular Neighbor table without the need for LPM based Route lookup.
- the packet forwarding pipeline process is optimized by performing route lookup only once per session flow (assuming that no route changes during the session).
- the present disclosure allows for caching a reference to a route in the session and caching a reference to the session in a tunnel or a logical interface, and thus not only enhancing the conventional per-packet based route lookup to per-flow based lookup, but also allowing direct access to route information from the tunnel or logical interface.
- a disclosed network device receives a first packet in a session, and performs a route lookup based on a header of the first packet to determine a route for the first packet. Further, the network device caches a reference to the route in the session such that subsequent packets in the session are routed based on the cached reference in lieu of subsequent route lookups.
- the reference to the route comprises one or more of a route index (which may additionally include an equal cost multiple path (ECMP) index), a route version number, a neighbor index, and a neighbor index number.
- ECMP equal cost multiple path
- the disclosed system compares a route's version number in the session against the version number in a route referred by the index in the session. Likewise, the disclosed system also compares the neighbor entry's version number in the session against the version number in a neighbor referred by the index in the session.
- the disclosed system can validate reference to the session by comparing the source and destination IP addresses. Specifically, the disclosed system can checks the source and/or destination IP address in the tunnel against the source and/or destination IP address in the session.
- the disclosed network device can perform another route lookup to update the route with one or more of an updated route index, an updated route version number, an updated neighbor index, and an updated neighbor version number. In some embodiments, however, if the disclosed network device determines that the route is stale and the session is inactive, it will delay route lookup until at least one packet is received in the session.
- At least two paths with identical cost correspond to the route are stored in the route table.
- Each path is identified by a unique Equal Cost Multiple Path (ECMP) index.
- ECMP Equal Cost Multiple Path
- the route is determined to be stale based on difference between the first neighbor version number cached in the session and the second neighbor version number corresponding to the route in the neighbor table.
- VRRP Virtual Router Redundancy Protocol
- the disclosed network device if the route determined to be stale, performs another route lookup to update the session with an updated route index and an updated route version number. And if the updated route index and the updated route version corresponding to a shorter alternative route than the route, the disclosed network device forwards subsequent packets in the session using the shorter alternative route.
- the shorter alternative route is stored in a patricia trie as a child node of a parent node. Specifically, the parent node corresponds to the route; and, a route version number of the route corresponding to the parent node is updated/incremented in response to the child node being inserted in the patricia trie.
- the disclosed network device encapsulates the first packet based on information returned from a bridge lookup prior to encrypting the first packet.
- the disclosed network device identifies a network interface that the first packet is to be transmitted on. Then, the disclosed network device sends the first packet to a security engine of the network device to encrypt the first packet, and instructs the security engine to forward encrypted first packet to the identified network interface in lieu of returning the encrypted first packet to a processor within the network device.
- FIG. 1 shows an exemplary wireless digital network environment according to embodiments of the present disclosure.
- FIG. 1 includes at least one or more network controller (such as controller 100 ), one or more access points (such as access point 160 ), one or more client devices (such as client 170 ), a layer 2 or layer 3 network 110 , a routing device (such as router 120 ), a gateway 130 , Internet 140 , and one or more web servers (such as web server A 150 , web server B 155 , and web server C 158 ), etc.
- network controller such as controller 100
- one or more access points such as access point 160
- client devices such as client 170
- a layer 2 or layer 3 network 110 such as a routing device (such as router 120 ), a gateway 130 , Internet 140 , and one or more web servers (such as web server A 150 , web server B 155 , and web server C 158 ), etc.
- web servers such as web server A 150 , web server B 155 , and web server C 158
- Controller 100 is a hardware device and/or software module that provide network managements, which include but are not limited to, controlling, planning, allocating, deploying, coordinating, and monitoring the resources of a network, network planning, frequency allocation, predetermined traffic routing to support load balancing, cryptographic key distribution authorization, configuration management, fault management, security management, performance management, bandwidth management, route analytics and accounting management, etc.
- Access points are interconnected with network controller 100 .
- Each access points may be interconnected with zero or more client devices via either a wired interface or a wireless interface.
- client 170 is associated with access point 160 via a wireless link.
- Access points generally refer to a network device that allows wireless clients to connect to a wired network. Access points usually connect to a router via a wired network or can be a part of a router in itself.
- controller 100 can be connected to router 120 through zero or more hops in a layer 3 or layer 2 network (such as L2/L3 Network 110 ).
- Router 120 can forward traffic to and receive traffic from Internet 140 through gateway 130 .
- Router 160 generally is a network device that forwards data packets between different networks, and thus creating an overlay internetwork.
- a router is typically connected to two or more data lines from different networks. When a data packet comes in one of the data lines, the router reads the address information in the packet to determine its destination. Then, using information in its routing table or routing policy, the router directs the packet to the next/different network.
- a data packet is typically forwarded from one router to another router through the Internet until the packet gets to its destination.
- Gateway 130 is a network device that passes network traffic from local subnet to devices on other subnets.
- gateway 130 is a default gateway that often connects a local network (such as L2/L3 Network 110 ) to Internet 140 .
- gateway 130 may be a part of router 120 depending on the configuration of router 120 .
- Web servers 150 , 155 , and 158 are hardware devices and/or software modules that facilitate delivery of web content that can be accessed through Internet 140 .
- web server 150 may be assigned an IP address of 1.1.1.1 and used to host a first Internet website (e.g., www.yahoo.com);
- web server 155 may be assigned an IP address of 2.2.2.2 and used to host a second Internet website (e.g., www.google.com);
- web server 158 may be assigned an IP address of 3.3.3.3 and used to host a third Internet website (e.g., www.facebook.com).
- a flow In packet switching networks, a flow generally refers to a sequence of packets from a source network/client device to a destination network/client device, which may be another host, a multicast group, or a broadcast domain. A flow could consist of all packets in a specific session connection or media stream.
- Each layer 2 or layer 3 network session can be uniquely identified by a session key, which may be a layer 3 network session key or a layer 2 network session key.
- a layer 3 network session key generally includes information, such as a source Internet Protocol (IP) address, a destination IP address, a protocol, a layer 4 source port, a layer 4 destination port, etc.
- a layer 2 network session key generally includes a source Media Access Control (MAC) address, a destination MAC address, Ethernet type, etc.
- IP Internet Protocol
- MAC Media Access Control
- FIG. 2 illustrates a general architecture including multiple processing planes according to embodiments of the present disclosure. Specifically, FIG. 2 includes at least a control plane process 210 , two or more datapath processors 220 , a lockless shared memory 260 accessible by the two or more datapath processors 220 , and a network interface 250 .
- Control plane process 210 may be running on one or more CPU or CPU cores, such as CP CPU 1 212 , CP CPU 2 214 , . . . CP CPU M 218 . Furthermore, control plane process 210 typically handles network control or management traffic generated by and/or terminated at network devices as opposed to data traffic generated and/or terminated at client devices.
- datapath processors 220 include a single exception processing CPU, such as a slowpath (SP) processor (e.g., Exception Processing CPU 230 ) and multiple forwarding CPU, such as fastpath (FP) processors (e.g., Forwarding CPU 1 240 , Forwarding CPU 2 242 , . . . Forwarding CPU N 248 ). Only forwarding processors are able to receive data packets directly from network interface 250 . Exception processing processor, on the other hand, only receives data packets from the forwarding processors.
- SP slowpath
- FP fastpath
- Lockless shared memory 260 is a flat structure that is shared by all datapath processors 220 , and not tied to any particular CPU or CPUs. Any datapath processor 220 can read any memory location within lockless shared memory 260 . Therefore, both the single exception processing processor (e.g., Exception Processing CPU 230 ) and the multiple forwarding processors (e.g., Forwarding CPU 1 240 , Forwarding CPU 2 242 , . . . Forwarding CPU N 248 ) have read access to lockless shared memory 260 , but only the single exception processing processor (e.g., Exception Processing CPU 230 ) has write access to lockless shared memory 260 . More specifically, any datapath processor 220 can have access to any location in lockless shared memory 260 in the disclosed system.
- the single exception processing processor e.g., Exception Processing CPU 230
- the multiple forwarding processors e.g., Forwarding CPU 1 240 , Forwarding CPU 2 242 , . . . Forwarding CPU N 248
- control plane process 210 is communicatively coupled to exception processing CPU 230 , such as a slowpath (SP) CPU, but not forwarding CPU, such as fastpath (FP) processors (e.g., Forwarding CPU 1 240 , Forwarding CPU 2 242 , . . . Forwarding CPU N 248 ).
- exception processing CPU 230 such as a slowpath (SP) CPU
- FP fastpath
- control plane process 210 will communicate with exception processing CPU 230 , such as an SP processor.
- FIG. 3 illustrates an exemplary network forwarding process according to embodiments of the present disclosure.
- a typical pipeline process at a FP processor involves one or more of the following operations:
- the network forwarding process illustrated in FIG. 3 includes at least a port lookup operation 300 , a virtual local area network (VLAN) lookup operation 305 , a port/VLAN lookup operation 310 , a bridge lookup operation 315 , a firewall session lookup operation 320 , a route lookup operation 325 , a forward lookup operation 330 , an encapsulation operation 335 , an encryption operation 340 , a tunnel decapsulation operation 345 , a decryption operation 350 , and a transmit operation 360 .
- VLAN virtual local area network
- FIG. 4 is a diagram illustrating exemplary routing tables maintained in a shared memory according to embodiments of the present disclosure.
- Shared memory 380 can be used to store a variety of tables to assist software network packet forwarding.
- the tables may include, but are not limited to, a bridge table, a session table, a user table, a station table, a tunnel table, a route table and/or route cache, etc.
- the tables may include, but are not limited to, a bridge table, a session table, a user table, a station table, a tunnel table, a route table and/or route cache, etc.
- shared memory 400 stores at least one or more of a port table 410 , a VLAN table 420 , a bridge table 430 , a station table 440 , a route table 450 , a route cache 460 , a session policy table 470 , a user table 480 , etc.
- Each table is used during network forwarding operations illustrated in FIG. 3 for retrieving relevant information in order to perform proper network forwarding.
- port table 410 is used during port lookup operation to look up a port identifier based on the destination address of a network packet.
- VLAN table 420 is used during VLAN lookup operation to look up a VLAN identifier based on the port identifier and/or source/destination address(es).
- a table can be used by multiple network forwarding operations, and each network forwarding operation may need to access multiple routing tables.
- shared memory 400 is a lockless shared memory.
- multiple tables in shared memory 400 can be accessed by multiple FP processors while the FP processors are processing packets received one or more network interfaces. If the FP processor determines that a packet requires any special handlings, the FP processor will hand over the packet processing to the SP processor. For example, the FP processor may find a table entry corresponding to the packet is missed; and therefore, handing over the packet processing to the SP processor. As another example, the FP processor may find that the packet is a fragmented packet, and thus hand over the packet processing to the SP processor.
- a flow generally refers to a sequence of packets from a source network/client device to a destination network/client device, which may be another host, a multicast group, or a broadcast domain.
- a flow could consist of all packets in a specific session connection or media stream.
- FIG. 5 illustrates exemplary flow packets according to embodiments of the present disclosure.
- a layer 2 or layer 3 packet flow may include multiple fragmented packets, which include, e.g., a first fragment (or a parent fragment) and one or more subsequent fragments (or data fragments).
- each packet may include multiple portions.
- a packet with a L3 packet key 500 may include at least a network layer (layer 3 or L3) header that includes L3 source IP 510 , L3 destination IP 515 , and protocol 520 , a transport layer (layer 4 or L4) header that includes L4 source port 525 and L4 destination port 530 .
- a packet with a L2 packet key 550 may include at least a media access control layer (layer 2 or L2) header that include source media access control (MAC) address 560 , destination MAC address 570 , and Ethernet type 580 .
- MAC media access control
- Subsequent fragments include at least a network layer (layer 3 or L3) header, but do not include any transport (layer 4 or L4) header.
- Transport (layer 4 or L4) header is required for session-based forwarding, for example, when firewall policies need to be applied to the packet. Even though subsequent fragments do not include any transport (layer 4 or L4) header, they are typically applied with the same session policies as those applied to the first segment.
- FIG. 6 illustrates an exemplary route catch table according to embodiments of the present disclosure.
- route cache table 600 includes fields such as destination IP address 605 , next hop interface 610 , gateway MAC address 615 , and neighbor information 620 , which duplicates a corresponding neighbor entry in a neighbor table.
- a network device To populate route catch table 600 , a network device first performs a longest prefix match lookup in the route table based on the destination address (e.g., “1.1.1.1”) of a network packet to find out the next hop interface corresponding to the destination address (e.g., Interface NH1 ).
- next hop interface may include, but is not limited to, a VLAN, a tunnel, and/or a port.
- the network device inserts an entry in route cache table 600 with the destination IP address, the next hop MAC interface resulting from the route table lookup, and the default gateway MAC address (e.g., MAC GW1 ) that is known to the network device (e.g., a network controller).
- the inserted entry will also include other information in its corresponding neighbor entry Entry 1 from the neighbor table.
- the network device e.g., a network controller
- the next hop interface is Interface NH2
- the default gateway MAC address is MAC GW2
- the neighbor information includes neighbor entry Entry 2
- the next hop interface is Interface NH3
- the default gateway MAC address is MAC GW3
- the neighbor information includes neighbor entry Entry 3 .
- route cache table 600 is maintained as a hash table by applying a hash function on the destination IP address of the packet.
- Route cache table 600 may introduce a few issues. First, the cost of matching longest prefix for each packet can be high. This is especially true in IPv6 network, where the IP addresses become longer than conventional IPv4 addresses. Second, as the number of hashed entries in route cache table increases, the cost for looking up route cache table 600 also increases accordingly. Third, maintaining the consistency of route cache table 600 may result in additional costs.
- next hop address in a route corresponding to “1.1.0.0” changes in the routing table
- the system would have to perform a reverse lookup to search for all destination IP addresses for which “1.1.0.0” is the longest prefix match, and update the next hop address in all of those entries. Therefore, the convergence after a route change is slow because of the costs involved in maintaining the consistency of route cache table 600 .
- FIGS. 7A-7C illustrate various routing tables according to embodiments of the present disclosure.
- the illustrated routing tables in combination provide an alternative and an enhancement to the route cache table describe above.
- FIG. 7A illustrates an exemplary route table 700 , which includes a field for version 702 , prefix/length 705 and a field for next hop address 710 and also an optional next hop interface for routes through P2P interface (not shown).
- the next hop address for “1.0.0.0/8” is IP NH1
- the version of the route is 100
- the next hop address for “0.0.0.0/0” is IP NH2
- the version of the route is 101; etc.
- FIG. 7B illustrates an exemplary session table 720 , which includes at least the following fields: source IP address 725 , destination IP address 730 , route index 735 , route version 740 , neighbor index 745 , neighbor version 750 , etc.
- Route index 735 may also include a next hop index in cases where equal cost multiple paths (EMCP) apply.
- EMCP equal cost multiple paths
- the route index corresponding to a route from the source IP address “100.100.100” to the destination IP address “1.1.1.1” is route 1 .
- the corresponding route version for route 1 is 100; and, the corresponding neighbor index and neighbor version are ARP 1 and 10 respectively.
- the neighbor index, neighbor version, and route version are updated to ARP 2 , 20, and 101 respectively responsive to the next hop change for route 1 .
- the version number 100 for route 1 is the route version number corresponding to route entry route 1 in the route table at the time when the disclosed system performs the route lookup and insert the reference to route 1 into session table 720 .
- the version number 10 is neighbor ARP 1 is the neighbor version number corresponding to the neighbor entry ARP 1 in the neighbor table at the time when the disclosed system insert the reference to APR 1 into session table 720 .
- FIG. 7C illustrates an exemplary neighbor table 760 , which includes at least the following fields: version 765 , index 770 , IP address 775 , MAC address 780 , VLAN identifier 790 , etc.
- Neighbor table 760 provides a mapping between a destination IP address and MAC address.
- information in neighbor table 760 can be obtained by transmitting an Address Resolution Protocol (ARP) request and analyze the corresponding ARP response.
- ARP Address Resolution Protocol
- the IP address is 10.10.10.10, which corresponds to VLAN 10 ; the corresponding MAC address is MAC 1 ; and the version number is 10.
- the IP address is 18.18.18.18, which corresponds to VLAN 18 ; the corresponding MAC address is MAC 2 ; and the version number is 20.
- the IP address is 15.15.15.15, which corresponds to VLAN 15 ; the corresponding MAC address is MAC 2 ; and the version number is 30.
- the above examples are provided for illustration purposes only. Different neighbors may have the same version number, but their IP address and MAC address will be unique.
- firewall session policy table which includes information, such as permission (e.g., permit or deny access), destination network address translation (DNAT), source network address translation (SNAT), rate limiting, etc.
- a flow table can be used for stateful firewall purposes in addition to firewall purposes.
- the firewall session policy table and/or flow table can be modified to additionally include the next hop information and version information, and used for routing purposes.
- a typical forwarding pipeline includes a bridge lookup operation, a firewall session policy lookup operation, and subsequent routing operations.
- the firewall session policy lookup operation checks the firewall policy based on the destination IP address of the packets. For example, a user may be redirected to a captive portal page when the user is trying to access a destination IP address of “1.1.1.1” according to the enterprise firewall policy configurations.
- the system will be forwarding packets to “1.1.1.1” in a session (or a flow). Accordingly, the system will initiate a route lookup based on the destination IP address of the session, e.g., “1.1.1.1.” For illustration purposes only, assuming that the route lookup returns a next hop IP address of “10.10.10.10.” The system will then perform a neighbor lookup based on the resulting IP address of the next hop. In this example, it is assumed that the neighbor lookup returns MAC 1 (e.g., 01:02:03:04:05:06) and VLAN identifier V 10 .
- MAC 1 e.g., 01:02:03:04:05:06
- firewall session policies include source and destination IP addresses along with other keys. Therefore, in every session for which the system performs session-based forwarding, if the session is determined to be a router session (which means that the session is not a client-to-client session that the network system can simply forward the packets by bridging the packets, but a session that requires a router to route the packets to the Internet), the system can then cache the routing lookup results in the session itself.
- one router is configured as the default router. Thus, every packet will be sent to the same MAC address corresponding to the default router, but the next hop address will be different depending on the destination IP address of each session. In this example, it is possible to eliminate all user VLANs and to use only one VLAN to route all packets to the default router.
- a guest VLAN may be configured to route all guest traffic to a network controller within the WLAN.
- the disclosed system may optimize the forwarding pipeline by caching the routing information in each session.
- a route to the destination IP address may change.
- the disclosed system will update the session table to reflect the route changes.
- the disclosed system maintains a reference to an entry in the route table and a version number corresponding to the route reference, as well as a reference to an entry in the neighbor table and a version number corresponding to the neighbor reference.
- the disclosed system no longer needs to perform a route lookup after a firewall session lookup, because the system can obtain route information directly from the sessions. Neither is it necessary to maintain a route cache in the system any longer, which reduces the cost for routing operations compared with other solutions.
- the disclosed system is also able to efficiently maintain the consistency of the route information in the session table (or flow table) and the route information in the route table and the neighbor table (or ARP table). Because the reference and version number to each route is maintained in the session, any time when a route changes, the system will be able to quickly detect the route change based on one or more of a change in the route reference, route version, neighbor reference, and/or neighbor version. Moreover, the system can easily update the session with the route change by updating one or more of the route reference, route version, neighbor reference, and/or neighbor version to reflect the route change.
- the system de-references the route index and the neighbor index in the session entry to retrieve the corresponding entries in the route table and the neighbor table. The system then obtains the current version number corresponding to the route index in the route table and the current version number corresponding to the neighbor index in the neighbor table. Next, the system determines whether certain conditions that indicate that the route in the session table is stale have occurred. For example, the system can determine whether the route version number and the neighbor version number maintained in the session entry match the current version numbers and/or neighbor index obtained above.
- the system will perform a route lookup using longest prefix match of the destination IP address of the session, and update the route information based on the results from the route lookup.
- a version number corresponding to a route index changes whenever there is a change in the route, e.g., a change in the next hop address.
- a version number corresponding to a neighbor index changes whenever the mapping between the IP address and the MAC address of a network node (e.g., a default gateway or a next hop for a particular VLAN) changes, for example, when the Ethernet interface changes.
- the default gateway's IP address may change during a session because the route gets modified, for example, from “10.10.10.10” at time point t 1 to “18.18.18.18” at time point t 2 .
- the route entry has the version number of 100, index value of 1, prefix/length value of “1.0.0.0/8,” and next hop IP address of “10.10.10.10.”
- the session entry has values as shown in session entry 760 in session table 720 , e.g., having a source IP address of “100.100.100.100,” a destination IP address of “1.1.1.1,” a route index corresponding to route 1 , a route version of 100, a neighbor index corresponding to ARP 1 , and a neighbor version of 10.
- the same route entry has the version number of 101, index value of 1, prefix/length value of “1.0.0.0/8,” and next hop IP address of “18.18.18.18.”
- the system When the system receives the first packet in the session after the time point t 2 , the system will detect that the route version in the session table (e.g., 100) does not match the route version in the route table (e.g., 101). Thus, the system will deem the session entry as stale and perform a route lookup to update the session entry.
- the route version in the session table e.g., 100
- the route version in the route table e.g., 101
- the session entry will have the values as shown in session entry 765 in session table 720 , e.g., having a source IP address of “100.100.100.100,” a destination IP address of “1.1.1.1,” a route index corresponding to route 1 , a route version of 101, a neighbor index corresponding to ARP 2 , and a neighbor version of 20.
- the route version has changed from 100 to 101; the neighbor index has changed from ARP 1 (corresponding to “10.10.10.10” in neighbor table 760 ) to ARP 2 (corresponding to “18.18.18.18” in neighbor table 760 ); and, the neighbor version has changed from 10 (corresponding to APR 1 in neighbor table 760 ) to 20 (corresponding to ARP 2 in neighbor table 760 ).
- the system will also detect a mismatch in the version numbers between the session table and the route table, because the corresponding route entry in the route table is missing. Therefore, the system will initiate a route lookup to search for a new route to the destination IP address based on the longest prefix match to the current route table (in which the original route was deleted), and update the session table with the information regarding the new route.
- the route lookup is performed when the system receives a packet in the session after time point t 2 .
- the session entry will remain to be stale despite that a change has occurred in the route table at time point t 2 . This is because when the client is idle, the client is not using the route, and thus there is no need to spend any resources on updating the route for an idle client.
- the session entry remains to be stale for an excessive amount of time because no client is using the session, the session entry will eventually be removed without ever being updated with the route change at all.
- FIG. 8A illustrates a use case scenario of ECMP, where there exits multiple paths with equal cost.
- a packet in a session flow from node A 800 to a destination address in L2/L3 Network 880 needs to be forwarded by the disclosed system.
- node A 800 is interconnected with two different next hop nodes, which are next hop A 810 and next hop B 820 . Each of the two different next hop nodes corresponds to a unique path to the destination address with equal cost.
- next hop A 810 is associated with the IP address of “10.10.10.10” and is pre-existing at time point t 1 .
- the route entry has the version number of 101, index value of 1, prefix/length value of “1.0.0.0/8,” and next hop IP address of “10.10.10.10” corresponding to next hop A 810 .
- next hop B 820 is associated with the IP address of “18.18.18.18.”
- any new sessions to a destination address for which “1.0.0.0/8” provides the longest prefix match will be using the new ECMP route corresponding to next hop B 820 with the IP address of “18.18.18.18.” Nevertheless, any existing route will continue to use next hop A 810 with the IP address of “10.10.10.10,” because the route version number has not changed. As a result, the system will determine that the route through next hop A 810 is not stale and does not need to be changed or updated.
- This scheme can be particularly useful when traffic from a private IP network is to be forwarded to two or more networks corresponding to different uplink service providers (e.g., AT&T® and Verizon®) via two or more different IP addresses, such as IP 1 and IP 2 . It is desirable that the traffic to the first service provider is only transmitted via IP 1 , and the traffic to the second service provider is only transmitted via IP 2 . Therefore, the traffic from users of different service providers will not get mixed with each other.
- uplink service providers e.g., AT&T® and Verizon®
- FIG. 8B illustrates a use case scenario of VRRP, where there exits two alternative paths with alternative next hop nodes.
- a packet in a session flow from node A 800 to a destination address in L2/L3 Network 880 needs to be forwarded by the disclosed system.
- node A 800 is interconnected with two different next hop nodes, which are next hop A 810 and next hop B 820 .
- Each of the two different next hop nodes corresponds to the same virtual router under VRRP 815 . Therefore, at any given time, traffic from node A 800 will be able to reach next hop C 830 via either next hop A 810 or next hop B 820 but not both, and the traffic will continue to be forwarded to next hop C 830 via L2/L3 network 880 .
- next hop A 810 fails, and next hop B 820 starts to function as the virtual router. Therefore, in the neighbor table, the same neighbor entry now has the version number of 11, index value of 1, IP address of “10.10.10.10,” MAC address of MAC B (corresponding to next hop B 820 ), and VLAN identifier value of V 10 .
- the system will determine that the route has become stale. Consequently, the system will perform a route lookup and update the session entry in the session table with the new neighbor version number.
- FIG. 8C illustrates a use case scenario in which an alternative shorter route is added during the session.
- a packet in a session flow from node A 800 to a destination node D 890 is initially forwarded through next hop B 820 and L2/L3 Network 880 .
- node A 800 is interconnected with an additional next hop node, which is next hop A 810
- next hop A 810 is further interconnected with destination node D 890 .
- next hop A is associated with an IP address of “1.1.0.0”
- next hop B is associated with an IP address of “1.0.0.0.” Therefore, there are two alternative routes between node A 800 and destination node D 890 .
- traffic from node A 800 will be able to reach destination node D 890 via next hop A 810 , which provides a shorter route than the original route via next hop B 820 and L2/L3 Network 880 .
- the corresponding route entry (e.g., “1.0.0.0/8”) becomes stale due to the difference in the route version number in the session table (e.g., 100) and in the route table (e.g., 101).
- the system will perform a route lookup to update the route information.
- the route lookup will return the shorter route, e.g., “1.1.0.0/16”, with a new route index instead of the original route (e.g., “1.0.0.0/8”).
- subsequent traffic from the same source node to the same destination node will be forwarded through the updated shorter route.
- a computing environment as illustrated in FIG. 1 may have a L2/L3 network between controller 100 and access point 160 .
- a L2 or L3 tunnel e.g., a Generic Routing Encapsulation (GRE) tunnel
- GRE Generic Routing Encapsulation
- a tunnel is generally represented as (source IP address, destination IP address, protocol, L4 attributes), and is usually identified by a unique session key.
- a typical network forwarding process includes, inter alia, a bridge lookup 315 (e.g., on an Ethernet packet formatted as IEEE 802.3 packet), a firewall session lookup 320 , a route lookup 325 , a forwarding lookup 330 , etc. Then, if it is determined that the packet needs to be transmitted via a tunnel between a controller and an access point, the packet is further encapsulated with an outer header, e.g., a GRE header, to be converted to an IEEE 802.11 packet format.
- an outer header e.g., a GRE header
- the encapsulated packet in IEEE 802.11 format again goes through the same series of network forwarding process, e.g., a firewall session lookup 320 , a route lookup 325 , a forwarding lookup 330 , etc., before it can be properly forwarded to its destination.
- a firewall session lookup 320 e.g., a firewall session lookup 320 , a route lookup 325 , a forwarding lookup 330 , etc.
- one of datapath processors 220 (e.g., FP CPU 1 240 , FP CPU 2 242 , . . . , or FP CPU N 248 ) will perform a session and/or route lookup, then send the packet to a security engine (not shown) for encryption.
- the encrypted (and encapsulated) packet will be returned back to datapath processors 220 , which will then forward the encrypted and encapsulated packet to its corresponding network interface 250 .
- datapath processors 220 may perform encapsulation prior to sending the packet to the security engine for encryption.
- datapath processors 220 may instruct the security engine which destination network interface 250 is associated with the packet. Therefore, after the security engine completes the encryption of the packet, the security engine can directly forward the packet to its corresponding destination network interface 250 without returning the encapsulated packet to datapath processors 220 .
- the system will first perform a route and neighbor (e.g., ARP) lookup, which will return a MAC address and a VLAN identifier corresponding to the destination IP address in the packet.
- a route and neighbor e.g., ARP
- the system performs a bridge lookup, which will return a destination network interface that can be either a port identifier or a tunnel identifier.
- the system can determine whether the packet is a unicast packet or a multicast packet. If the packet is a unicast packet, the system can use a unicast key to encrypt the packet. On the other hand, if the packet is a multicast packet, the system can use a tunnel or multicast key to encrypt the packet.
- the system can determine whether the packet needs to encapsulated. For example, if the destination network interface returned from the bridge lookup is associated with a GRE tunnel, then the system can determine that the packet will need to be encapsulated with the GRE headers before being forwarded to its destination.
- the system needs to know the tunnel information for the packet, which includes the source and destination IP addresses (available in the header of the packet), the transmission protocol (which can be determined based on the tunnel identifier), and L4 attributes associated with the packet (which are usually cached in the tunnel). Therefore, upon successful bridge lookup, the system would be able to perform an encapsulation of the packet based on the information returned from the bridge lookup.
- the system can use the cached link to the session entry to retrieve the routing information, and thus avoiding feeding the packets through the session forwarding pipeline process.
- the present disclosure allows for the first packet in a flow to be sent through the session forwarding pipeline once whereby the encryption and encapsulation operations are combined into the pipeline process, and for any subsequent packets to bypass the session forwarding pipeline by providing a direct link from tunnel to the corresponding session entry, which caches the corresponding routing information returned from the route lookup performed for the first packet in the flow.
- FIGS. 10A-10B are flowcharts illustrating exemplary processes for session-based forwarding.
- FIG. 10A illustrates an exemplary session-based forwarding process in which route references are cached in the session to avoid per-packet based route lookup.
- the disclosed system receives a first data packet in a session (operation 1000 ). The system then performs a route lookup to determine a route for the first packet (operation 1005 ).
- the disclosed system caches a reference to the route and the neighbor in the session (operation 1010 ). Further, the disclosed system optionally caches a reference to the session and the neighbor in a tunnel in cases where tunnel-based forwarding mechanism is used (operation 1015 ).
- the reference to the route includes one or more of a route index, a route version number, a neighbor index, and a neighbor version number.
- the tunnel can be a GRE tunnel within which packets in the session are to be forwarded. Note that, caching the reference to the session in the tunnels allows for direct access to the route information from the tunnel.
- At least two paths with identical cost corresponding to the route are stored in the route table; and, each path is identified by a unique Equal Cost Multiple Path (ECMP) index.
- ECMP Equal Cost Multiple Path
- At least two next hop nodes use Virtual Router Redundancy Protocol (VRRP), the route is determined to be stale based on the difference between a first neighbor version number cached in the session and a second neighbor version number corresponding to the route in the neighbor table.
- VRRP Virtual Router Redundancy Protocol
- Shared memory 1120 can include storage components, such as, Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), etc.
- shared memory 1120 is a flat structure that is shared by all datapath processors (including, e.g., exception processing processor core 1130 , forwarding processor core 1142 , forwarding processor core 1144 , . . . , forwarding processor core 1148 , etc.), and not tied to any particular CPU or CPU cores. Any datapath processor can read any memory location within shared memory 1120 .
- Shared memory 1120 can be used to store various tables to assist session-based packet forwarding.
- Exception processing processor core 1130 typically includes a networking processor core that is capable of processing network data traffic. Exception processing processor core 1130 is a single dedicated CPU core that typically handles table managements. Note that, slowpath processor core 1130 only receives data packets from one or more forwarding processor cores, such as forwarding processor core 1142 , forwarding processor core 1144 , . . . , forwarding processor core 1148 . In other words, exception processing processor core 1130 does not receive data packets directly from any line cards or network interfaces. Only the plurality of forwarding processor cores can send data packets to exception processing processor core 1130 . Moreover, exception processing processor core 1130 is the only processor core having the write access to shared memory 1120 , and thereby will not cause any data integrity issues even without a locking mechanism in place for shared memory 1120 .
- Forwarding processor cores 1142 - 1148 also include networking processor cores that are capable of processing network data traffic. However, by definition, forwarding processor cores 1142 - 1148 only performs “fast” packet processing. Thus, forwarding processor cores 1142 - 1149 do not block themselves and wait for other components or modules during the processing of network packets. Any packets requiring special handling or wait by a processor core will be handed over by forwarding processor cores 1142 - 1148 to exception processing processor core 1130 .
- Each of forwarding processor cores 1142 - 1148 maintains one or more counters.
- the counters are defined as a regular data type, for example, unsigned integer, unsigned long long, etc., in lieu of an atomic data type.
- a forwarding processor core 1142 - 1148 may increment or decrement the values of the counters to reflect network traffic information, including but not limited to, the number of received frames, the number of received bytes, error conditions and/or error counts, etc.
- forwarding processor cores 1142 - 1148 each can maintain a fragment table. Upon receiving a data fragment without information necessary for session processing (e.g., a transport layer or L4 header), forwarding processor cores 1142 - 1148 will queue the data fragments in their own fragment table, and perform various fragment table management tasks.
- a data fragment without information necessary for session processing (e.g., a transport layer or L4 header)
- forwarding processor cores 1142 - 1148 will queue the data fragments in their own fragment table, and perform various fragment table management tasks.
- the present disclosure may be realized in hardware, software, or a combination of hardware and software.
- the present disclosure may be realized in a centralized fashion in one computer system or in a distributed fashion where different elements are spread across several interconnected computer systems coupled to a network.
- a typical combination of hardware and software may be an access point with a computer program that, when being loaded and executed, controls the device such that it carries out the methods described herein.
- the present disclosure also may be embedded in non-transitory fashion in a computer-readable storage medium (e.g., a programmable circuit; a semiconductor memory such as a volatile memory such as random access memory “RAM,” or non-volatile memory such as read-only memory, power-backed RAM, flash memory, phase-change memory or the like; a hard disk drive; an optical disc drive; or any connector for receiving a portable memory device such as a Universal Serial Bus “USB” flash drive), which comprises all the features enabling the implementation of the methods described herein, and which when loaded in a computer system is able to carry out these methods.
- a computer-readable storage medium e.g., a programmable circuit; a semiconductor memory such as a volatile memory such as random access memory “RAM,” or non-volatile memory such as read-only memory, power-backed RAM, flash memory, phase-change memory or the like; a hard disk drive; an optical disc drive; or any connector for receiving a portable memory device such as a Universal Serial Bus “USB”
- interconnect or used descriptively as “interconnected” is generally defined as a communication pathway established over an information-carrying medium.
- the “interconnect” may be a wired interconnect, wherein the medium is a physical medium (e.g., electrical wire, optical fiber, cable, bus traces, etc.), a wireless interconnect (e.g., air in combination with wireless signaling technology) or a combination of these technologies.
- wireless local area network generally refers to a communications network links two or more devices using some wireless distribution method (for example, spread-spectrum or orthogonal frequency-division multiplexing radio), and usually providing a connection through an access point to the Internet; and thus, providing users with the mobility to move around within a local coverage area and still stay connected to the network.
- some wireless distribution method for example, spread-spectrum or orthogonal frequency-division multiplexing radio
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
Description
- This application claims the benefit of priority on U.S. Provisional Patent Application 61/732,829, filed Dec. 3, 2012, the entire contents of which are incorporated by reference.
- Related patent applications to the subject application include the following: (1) U.S. Patent Application entitled “System and Method for Achieving Enhanced Performance with Multiple Networking Central Processing Unit (CPU) Cores” by Janakiraman, et al., U.S. application Ser. No. 13/692,622, filed Dec. 3, 2012, attorney docket reference no. 6259P186; (2) U.S. Patent Application entitled “Ingress Traffic Classification and Prioritization with Dynamic Load Balancing” by Janakiraman, et al., U.S. application Ser. No. 13/692,608, filed Dec. 3, 2012, attorney docket reference no. 6259P191; (3) U.S. Patent Application entitled “Method and System for Maintaining Derived Data Sets” by Gopalasetty, et al., U.S. application Ser. No. 13/692,920, filed Dec. 3, 2012, attorney docket reference no. 6259P192; (4) U.S. Patent Application entitled “System and Method for Message handling in a Network Device” by Palkar, et al., U.S. application Ser. No. ______, filed Jun. 14, 2013, attorney docket reference no. 6259P189; (5) U.S. Patent Application entitled “Rate Limiting Mechanism Based on Device Load/Capacity or Traffic Content” by Nambiar, et al., U.S. application Ser. No. ______ , filed Jun. 14, 2013, attorney docket reference no. 6259P185; (6) U.S. Patent Application entitled “Control Plane Protection for Various Tables Using Storm Prevention Entries” by Janakiraman, et al., U.S. application Ser. No. ______, filed Jun. 14, 2013, attorney docket reference no. 6259P188. The entire contents of the above applications are incorporated herein by reference.
- The present disclosure relates to networking processing performance of a symmetric multiprocessing (SMP) network architecture. In particular, the present disclosure relates to a system and method for providing session-based forwarding in a pipelined forwarding model.
- A symmetric multiprocessing (SMP) architecture generally is a multiprocessor computer architecture where two or more identical processors can connect to a single shared main memory. In the case of multi-core processors, the SMP architecture can apply to the CPU cores.
- In an SMP architecture, multiple networking CPUs or CPU cores can receive and transmit network traffic. While receiving and transmitting the network traffic, the system may maintain a flow-based engine that transmits the network traffic on a per-flow basis. Each flow is uniquely identified by a session key. To allow for efficient forwarding of flow-based network traffic, a network routing system typically uses longest prefix match to perform route lookup. Specifically, the routing system can look up in a route table for next hop information based on which Internet Protocol (IP) address provides the longest prefix match to the destination IP address.
- Nevertheless, the longest prefix match lookup may incur excessive cost when the packets have long IP addresses, e.g., in the scenario of IPv6 network. Moreover, because the network topology and conditions can change dynamically, updating the route table to reflect the route changes in the flow table can be costly too. As a result, the rate of network convergence in the event of route changes may be slow with the conventional routing mechanisms that update the route information in the flow table.
- The present disclosure may be best understood by referring to the following description and accompanying drawings that are used to illustrate embodiments of the present disclosure.
-
FIG. 1 is a diagram illustrating an exemplary wireless network environment according to embodiments of the present disclosure. -
FIG. 2 illustrates an exemplary architecture at multiple processing planes according to embodiments of the present disclosure. -
FIG. 3 illustrates an exemplary network forwarding process according to embodiments of the present disclosure. -
FIG. 4 is a diagram illustrating exemplary routing tables maintained in a shared memory according to embodiments of the present disclosure. -
FIG. 5 illustratesexemplary layer 3 and/orlayer 2 packet flow data structure according to embodiments of the present disclosure. -
FIG. 6 illustrates an exemplary route catch table according to embodiments of the present disclosure. -
FIGS. 7A-7C illustrates various routing tables according to embodiments of the present disclosure. -
FIGS. 8A-8C illustrates various scenarios in which a network route may need to be updated according to embodiments of the present disclosure. -
FIG. 9 illustrates an exemplary trie data structure used in session-based forwarding according to embodiments of the present disclosure. -
FIGS. 10A-10B illustrate processes for session-based forwarding according to embodiments of the present disclosure. -
FIG. 11 is a block diagram illustrating a system of session-based forwarding according to embodiments of the present disclosure. - In the following description, several specific details are presented to provide a thorough understanding. While the context of the disclosure is directed to SMP architecture performance enhancement, one skilled in the relevant art will recognize, however, that the concepts and techniques disclosed herein can be practiced without one or more of the specific details, or in combination with other components, etc. In other instances, well-known implementations or operations are not shown or described in details to avoid obscuring aspects of various examples disclosed herein. It should be understood that this disclosure covers all modifications, equivalents, and alternatives falling within the spirit and scope of the present disclosure.
- Embodiments of the present disclosure relate to networking processing performance. In particular, the present disclosure relates to a system and method for providing efficient session-based forwarding with multiple networking central processing unit (CPU) cores. Specifically, the system achieves efficient session-based forwarding by maintaining a version associated with each route in a session table and determining whether a route is stale based on the value of the version associated with each route.
- According to embodiments of the present disclosure, the conventional route cache table that enumerates all destinations on the shared memory is trimmed down to regular Neighbor table without the need for LPM based Route lookup. The packet forwarding pipeline process is optimized by performing route lookup only once per session flow (assuming that no route changes during the session). The present disclosure allows for caching a reference to a route in the session and caching a reference to the session in a tunnel or a logical interface, and thus not only enhancing the conventional per-packet based route lookup to per-flow based lookup, but also allowing direct access to route information from the tunnel or logical interface.
- Specifically, with the solution provided herein, a disclosed network device receives a first packet in a session, and performs a route lookup based on a header of the first packet to determine a route for the first packet. Further, the network device caches a reference to the route in the session such that subsequent packets in the session are routed based on the cached reference in lieu of subsequent route lookups. The reference to the route comprises one or more of a route index (which may additionally include an equal cost multiple path (ECMP) index), a route version number, a neighbor index, and a neighbor index number.
- For session based forwarding, the disclosed system compares a route's version number in the session against the version number in a route referred by the index in the session. Likewise, the disclosed system also compares the neighbor entry's version number in the session against the version number in a neighbor referred by the index in the session.
- For tunnel based forwarding, the disclosed system can validate reference to the session by comparing the source and destination IP addresses. Specifically, the disclosed system can checks the source and/or destination IP address in the tunnel against the source and/or destination IP address in the session.
- If the disclosed network device determines that the route is stale, the disclosed network device can perform another route lookup to update the route with one or more of an updated route index, an updated route version number, an updated neighbor index, and an updated neighbor version number. In some embodiments, however, if the disclosed network device determines that the route is stale and the session is inactive, it will delay route lookup until at least one packet is received in the session.
- In some embodiments, at least two paths with identical cost correspond to the route are stored in the route table. Each path is identified by a unique Equal Cost Multiple Path (ECMP) index. When a new ECMP index is added to the route table, a subsequent session uses the path associated with the new ECMP index, but an existing session continues to use an existing path associated with an existing ECMP index.
- In some embodiments, when at least two next hop nodes use Virtual Router Redundancy Protocol (VRRP), the route is determined to be stale based on difference between the first neighbor version number cached in the session and the second neighbor version number corresponding to the route in the neighbor table.
- In some embodiments, if the route determined to be stale, the disclosed network device performs another route lookup to update the session with an updated route index and an updated route version number. And if the updated route index and the updated route version corresponding to a shorter alternative route than the route, the disclosed network device forwards subsequent packets in the session using the shorter alternative route. In one embodiment, the shorter alternative route is stored in a patricia trie as a child node of a parent node. Specifically, the parent node corresponds to the route; and, a route version number of the route corresponding to the parent node is updated/incremented in response to the child node being inserted in the patricia trie.
- In some embodiments, the disclosed network device encapsulates the first packet based on information returned from a bridge lookup prior to encrypting the first packet.
- Furthermore, the disclosed network device identifies a network interface that the first packet is to be transmitted on. Then, the disclosed network device sends the first packet to a security engine of the network device to encrypt the first packet, and instructs the security engine to forward encrypted first packet to the identified network interface in lieu of returning the encrypted first packet to a processor within the network device.
-
FIG. 1 shows an exemplary wireless digital network environment according to embodiments of the present disclosure.FIG. 1 includes at least one or more network controller (such as controller 100), one or more access points (such as access point 160), one or more client devices (such as client 170), alayer 2 orlayer 3network 110, a routing device (such as router 120), agateway 130,Internet 140, and one or more web servers (such asweb server A 150,web server B 155, and web server C 158), etc. -
Controller 100 is a hardware device and/or software module that provide network managements, which include but are not limited to, controlling, planning, allocating, deploying, coordinating, and monitoring the resources of a network, network planning, frequency allocation, predetermined traffic routing to support load balancing, cryptographic key distribution authorization, configuration management, fault management, security management, performance management, bandwidth management, route analytics and accounting management, etc. - Moreover, assuming that a number of access points, such as
access point 160, are interconnected withnetwork controller 100. Each access points may be interconnected with zero or more client devices via either a wired interface or a wireless interface. In this example, for illustration purposes only, assuming thatclient 170 is associated withaccess point 160 via a wireless link. Access points generally refer to a network device that allows wireless clients to connect to a wired network. Access points usually connect to a router via a wired network or can be a part of a router in itself. - Furthermore,
controller 100 can be connected torouter 120 through zero or more hops in alayer 3 orlayer 2 network (such as L2/L3 Network 110).Router 120 can forward traffic to and receive traffic fromInternet 140 throughgateway 130.Router 160 generally is a network device that forwards data packets between different networks, and thus creating an overlay internetwork. A router is typically connected to two or more data lines from different networks. When a data packet comes in one of the data lines, the router reads the address information in the packet to determine its destination. Then, using information in its routing table or routing policy, the router directs the packet to the next/different network. A data packet is typically forwarded from one router to another router through the Internet until the packet gets to its destination. -
Gateway 130 is a network device that passes network traffic from local subnet to devices on other subnets. In the example inFIG. 1 ,gateway 130 is a default gateway that often connects a local network (such as L2/L3 Network 110) toInternet 140. In some embodiments,gateway 130 may be a part ofrouter 120 depending on the configuration ofrouter 120. -
Web servers Internet 140. For example,web server 150 may be assigned an IP address of 1.1.1.1 and used to host a first Internet website (e.g., www.yahoo.com);web server 155 may be assigned an IP address of 2.2.2.2 and used to host a second Internet website (e.g., www.google.com); and,web server 158 may be assigned an IP address of 3.3.3.3 and used to host a third Internet website (e.g., www.facebook.com). - In packet switching networks, a flow generally refers to a sequence of packets from a source network/client device to a destination network/client device, which may be another host, a multicast group, or a broadcast domain. A flow could consist of all packets in a specific session connection or media stream. Each
layer 2 orlayer 3 network session can be uniquely identified by a session key, which may be alayer 3 network session key or alayer 2 network session key. Alayer 3 network session key generally includes information, such as a source Internet Protocol (IP) address, a destination IP address, a protocol, a layer 4 source port, a layer 4 destination port, etc. Moreover, alayer 2 network session key generally includes a source Media Access Control (MAC) address, a destination MAC address, Ethernet type, etc. The above described session keys are maintained in a session table use for session management. -
FIG. 2 illustrates a general architecture including multiple processing planes according to embodiments of the present disclosure. Specifically,FIG. 2 includes at least acontrol plane process 210, two or more datapath processors 220, a lockless sharedmemory 260 accessible by the two or more datapath processors 220, and anetwork interface 250. -
Control plane process 210 may be running on one or more CPU or CPU cores, such asCP CPU 1 212,CP CPU 2 214, . . .CP CPU M 218. Furthermore,control plane process 210 typically handles network control or management traffic generated by and/or terminated at network devices as opposed to data traffic generated and/or terminated at client devices. - According to embodiments of the present disclosure, datapath processors 220 include a single exception processing CPU, such as a slowpath (SP) processor (e.g., Exception Processing CPU 230) and multiple forwarding CPU, such as fastpath (FP) processors (e.g., Forwarding
CPU 1 240,Forwarding CPU 2 242, . . . Forwarding CPU N 248). Only forwarding processors are able to receive data packets directly fromnetwork interface 250. Exception processing processor, on the other hand, only receives data packets from the forwarding processors. - Lockless shared
memory 260 is a flat structure that is shared by all datapath processors 220, and not tied to any particular CPU or CPUs. Any datapath processor 220 can read any memory location within lockless sharedmemory 260. Therefore, both the single exception processing processor (e.g., Exception Processing CPU 230) and the multiple forwarding processors (e.g., ForwardingCPU 1 240,Forwarding CPU 2 242, . . . Forwarding CPU N 248) have read access to lockless sharedmemory 260, but only the single exception processing processor (e.g., Exception Processing CPU 230) has write access to lockless sharedmemory 260. More specifically, any datapath processor 220 can have access to any location in lockless sharedmemory 260 in the disclosed system. - Also,
control plane process 210 is communicatively coupled to exception processing CPU 230, such as a slowpath (SP) CPU, but not forwarding CPU, such as fastpath (FP) processors (e.g., ForwardingCPU 1 240,Forwarding CPU 2 242, . . . Forwarding CPU N 248). Thus, whenevercontrol plane process 210 needs information from datapath processors 220,control plane process 210 will communicate with exception processing CPU 230, such as an SP processor. -
FIG. 3 illustrates an exemplary network forwarding process according to embodiments of the present disclosure. A typical pipeline process at a FP processor involves one or more of the following operations: - Port lookup;
- VLAN lookup;
- Port-VLAN table lookup;
- Bridge table lookup;
- Firewall session table lookup;
- Route table lookup;
- Packet encapsulation;
- Packet encryption;
- Packet decryption;
- Tunnel de-capsulation; and/or
- Forwarding; etc.
- Thus, the network forwarding process illustrated in
FIG. 3 includes at least aport lookup operation 300, a virtual local area network (VLAN)lookup operation 305, a port/VLAN lookup operation 310, abridge lookup operation 315, a firewallsession lookup operation 320, aroute lookup operation 325, aforward lookup operation 330, anencapsulation operation 335, anencryption operation 340, atunnel decapsulation operation 345, adecryption operation 350, and a transmitoperation 360. -
FIG. 4 is a diagram illustrating exemplary routing tables maintained in a shared memory according to embodiments of the present disclosure. Shared memory 380 can be used to store a variety of tables to assist software network packet forwarding. For example, the tables may include, but are not limited to, a bridge table, a session table, a user table, a station table, a tunnel table, a route table and/or route cache, etc. Specifically, in the example illustrated inFIG. 4 , sharedmemory 400 stores at least one or more of a port table 410, a VLAN table 420, a bridge table 430, a station table 440, a route table 450, aroute cache 460, a session policy table 470, a user table 480, etc. Each table is used during network forwarding operations illustrated inFIG. 3 for retrieving relevant information in order to perform proper network forwarding. For example, port table 410 is used during port lookup operation to look up a port identifier based on the destination address of a network packet. Likewise, VLAN table 420 is used during VLAN lookup operation to look up a VLAN identifier based on the port identifier and/or source/destination address(es). Note that, a table can be used by multiple network forwarding operations, and each network forwarding operation may need to access multiple routing tables. - In some embodiments, shared
memory 400 is a lockless shared memory. Thus, multiple tables in sharedmemory 400 can be accessed by multiple FP processors while the FP processors are processing packets received one or more network interfaces. If the FP processor determines that a packet requires any special handlings, the FP processor will hand over the packet processing to the SP processor. For example, the FP processor may find a table entry corresponding to the packet is missed; and therefore, handing over the packet processing to the SP processor. As another example, the FP processor may find that the packet is a fragmented packet, and thus hand over the packet processing to the SP processor. - A. Packet Flows
- As mentioned above, a flow generally refers to a sequence of packets from a source network/client device to a destination network/client device, which may be another host, a multicast group, or a broadcast domain. A flow could consist of all packets in a specific session connection or media stream.
FIG. 5 illustrates exemplary flow packets according to embodiments of the present disclosure. Note that, alayer 2 orlayer 3 packet flow may include multiple fragmented packets, which include, e.g., a first fragment (or a parent fragment) and one or more subsequent fragments (or data fragments). - Also, each packet may include multiple portions. For example, a packet with a
L3 packet key 500 may include at least a network layer (layer 3 or L3) header that includesL3 source IP 510,L3 destination IP 515, andprotocol 520, a transport layer (layer 4 or L4) header that includesL4 source port 525 andL4 destination port 530. As another example, a packet with aL2 packet key 550 may include at least a media access control layer (layer 2 or L2) header that include source media access control (MAC)address 560,destination MAC address 570, andEthernet type 580. - Subsequent fragments include at least a network layer (
layer 3 or L3) header, but do not include any transport (layer 4 or L4) header. Transport (layer 4 or L4) header is required for session-based forwarding, for example, when firewall policies need to be applied to the packet. Even though subsequent fragments do not include any transport (layer 4 or L4) header, they are typically applied with the same session policies as those applied to the first segment. - B. Route Cache
-
FIG. 6 illustrates an exemplary route catch table according to embodiments of the present disclosure. In the example shown, route cache table 600 includes fields such asdestination IP address 605,next hop interface 610,gateway MAC address 615, andneighbor information 620, which duplicates a corresponding neighbor entry in a neighbor table. To populate route catch table 600, a network device first performs a longest prefix match lookup in the route table based on the destination address (e.g., “1.1.1.1”) of a network packet to find out the next hop interface corresponding to the destination address (e.g., InterfaceNH1). Assuming, for example, the longest prefix match in the route table for “1.1.1.1” is “1.1.0.0,” which corresponds to next hop interface of InterfaceNH1. Note that, the next hop interface may include, but is not limited to, a VLAN, a tunnel, and/or a port. - Then, the network device inserts an entry in route cache table 600 with the destination IP address, the next hop MAC interface resulting from the route table lookup, and the default gateway MAC address (e.g., MACGW1) that is known to the network device (e.g., a network controller). The inserted entry will also include other information in its corresponding neighbor entry Entry1 from the neighbor table. In the example illustrated in
FIG. 6 , for destination IP address “2.2.2.2,” the next hop interface is InterfaceNH2, the default gateway MAC address is MACGW2, and the neighbor information includes neighbor entry Entry2; for destination IP address “3.3.3.3,” the next hop interface is InterfaceNH3, the default gateway MAC address is MACGW3, and the neighbor information includes neighbor entry Entry3. Note that, when multiple routes exist for a destination IP address, each route will correspond to a different next hop interface although the default gateway address may be the same. Thus, each route to the same destination IP address corresponds to a unique entry in the route cache table. - In some embodiments, route cache table 600 is maintained as a hash table by applying a hash function on the destination IP address of the packet. Route cache table 600 may introduce a few issues. First, the cost of matching longest prefix for each packet can be high. This is especially true in IPv6 network, where the IP addresses become longer than conventional IPv4 addresses. Second, as the number of hashed entries in route cache table increases, the cost for looking up route cache table 600 also increases accordingly. Third, maintaining the consistency of route cache table 600 may result in additional costs.
- For example, when the next hop address in a route corresponding to “1.1.0.0” changes in the routing table, the system would have to perform a reverse lookup to search for all destination IP addresses for which “1.1.0.0” is the longest prefix match, and update the next hop address in all of those entries. Therefore, the convergence after a route change is slow because of the costs involved in maintaining the consistency of route cache table 600.
- C. Routing Tables
-
FIGS. 7A-7C illustrate various routing tables according to embodiments of the present disclosure. The illustrated routing tables in combination provide an alternative and an enhancement to the route cache table describe above. Specifically,FIG. 7A illustrates an exemplary route table 700, which includes a field forversion 702, prefix/length 705 and a field fornext hop address 710 and also an optional next hop interface for routes through P2P interface (not shown). For example, according to route table 700, the next hop address for “1.0.0.0/8” is IPNH1) and the version of the route is 100; the next hop address for “0.0.0.0/0” is IPNH2, and the version of the route is 101; etc. -
FIG. 7B illustrates an exemplary session table 720, which includes at least the following fields:source IP address 725,destination IP address 730,route index 735,route version 740,neighbor index 745,neighbor version 750, etc.Route index 735 may also include a next hop index in cases where equal cost multiple paths (EMCP) apply. In the first example shown inFIG. 7B , the route index corresponding to a route from the source IP address “100.100.100.100” to the destination IP address “1.1.1.1” is route1. Also, the corresponding route version for route1 is 100; and, the corresponding neighbor index and neighbor version are ARP1 and 10 respectively. In the second example, due to a neighbor change in route1, the neighbor index, neighbor version, and route version are updated to ARP2, 20, and 101 respectively responsive to the next hop change for route1. - Note that, the
version number 100 for route1 is the route version number corresponding to route entry route1 in the route table at the time when the disclosed system performs the route lookup and insert the reference to route1 into session table 720. Likewise, theversion number 10 is neighbor ARP1 is the neighbor version number corresponding to the neighbor entry ARP1 in the neighbor table at the time when the disclosed system insert the reference to APR1 into session table 720. -
FIG. 7C illustrates an exemplary neighbor table 760, which includes at least the following fields:version 765,index 770,IP address 775,MAC address 780,VLAN identifier 790, etc. Neighbor table 760 provides a mapping between a destination IP address and MAC address. In some embodiments, information in neighbor table 760 can be obtained by transmitting an Address Resolution Protocol (ARP) request and analyze the corresponding ARP response. In the example shown inFIG. 7C , for the first neighbor withneighbor index number 1, the IP address is 10.10.10.10, which corresponds toVLAN 10; the corresponding MAC address is MAC1; and the version number is 10. Likewise, for the second neighbor withneighbor index number 2, the IP address is 18.18.18.18, which corresponds toVLAN 18; the corresponding MAC address is MAC2; and the version number is 20. Further, for the third neighbor withneighbor index number 3, the IP address is 15.15.15.15, which corresponds toVLAN 15; the corresponding MAC address is MAC2; and the version number is 30. The above examples are provided for illustration purposes only. Different neighbors may have the same version number, but their IP address and MAC address will be unique. - In addition, there exists a firewall session policy table, which includes information, such as permission (e.g., permit or deny access), destination network address translation (DNAT), source network address translation (SNAT), rate limiting, etc. In some embodiments, a flow table can be used for stateful firewall purposes in addition to firewall purposes. According to the present disclosure, the firewall session policy table and/or flow table can be modified to additionally include the next hop information and version information, and used for routing purposes.
- During operation, the system monitors every session based on flow-based destination IP address, which persists through the entire session. Because the value of the destination IP address does not change for a particular session, information such as those cached in the route cache can be cached in the session for easier access during the session instead of performing a lookup operation on a packet-by-packet basis. As mentioned previously in description regarding
FIG. 3 , a typical forwarding pipeline includes a bridge lookup operation, a firewall session policy lookup operation, and subsequent routing operations. The firewall session policy lookup operation checks the firewall policy based on the destination IP address of the packets. For example, a user may be redirected to a captive portal page when the user is trying to access a destination IP address of “1.1.1.1” according to the enterprise firewall policy configurations. - More specifically, the system will be forwarding packets to “1.1.1.1” in a session (or a flow). Accordingly, the system will initiate a route lookup based on the destination IP address of the session, e.g., “1.1.1.1.” For illustration purposes only, assuming that the route lookup returns a next hop IP address of “10.10.10.10.” The system will then perform a neighbor lookup based on the resulting IP address of the next hop. In this example, it is assumed that the neighbor lookup returns MAC1 (e.g., 01:02:03:04:05:06) and VLAN identifier V10.
- It is important to note that the firewall session policies include source and destination IP addresses along with other keys. Therefore, in every session for which the system performs session-based forwarding, if the session is determined to be a router session (which means that the session is not a client-to-client session that the network system can simply forward the packets by bridging the packets, but a session that requires a router to route the packets to the Internet), the system can then cache the routing lookup results in the session itself.
- In another example, one router is configured as the default router. Thus, every packet will be sent to the same MAC address corresponding to the default router, but the next hop address will be different depending on the destination IP address of each session. In this example, it is possible to eliminate all user VLANs and to use only one VLAN to route all packets to the default router. In addition, a guest VLAN may be configured to route all guest traffic to a network controller within the WLAN.
- Therefore, the disclosed system may optimize the forwarding pipeline by caching the routing information in each session. However, it is possible that during an active session, a route to the destination IP address may change. In such scenarios, the disclosed system will update the session table to reflect the route changes. To improve the efficiency in the updating operations, rather than maintaining a copy of the relevant route information in the session table, the disclosed system maintains a reference to an entry in the route table and a version number corresponding to the route reference, as well as a reference to an entry in the neighbor table and a version number corresponding to the neighbor reference.
- With this solution, the disclosed system no longer needs to perform a route lookup after a firewall session lookup, because the system can obtain route information directly from the sessions. Neither is it necessary to maintain a route cache in the system any longer, which reduces the cost for routing operations compared with other solutions.
- The disclosed system is also able to efficiently maintain the consistency of the route information in the session table (or flow table) and the route information in the route table and the neighbor table (or ARP table). Because the reference and version number to each route is maintained in the session, any time when a route changes, the system will be able to quickly detect the route change based on one or more of a change in the route reference, route version, neighbor reference, and/or neighbor version. Moreover, the system can easily update the session with the route change by updating one or more of the route reference, route version, neighbor reference, and/or neighbor version to reflect the route change.
- Specifically, to detect a route change, for every packet being forwarded in a session, the system de-references the route index and the neighbor index in the session entry to retrieve the corresponding entries in the route table and the neighbor table. The system then obtains the current version number corresponding to the route index in the route table and the current version number corresponding to the neighbor index in the neighbor table. Next, the system determines whether certain conditions that indicate that the route in the session table is stale have occurred. For example, the system can determine whether the route version number and the neighbor version number maintained in the session entry match the current version numbers and/or neighbor index obtained above. If either version number in the session table is different from its corresponding version number in the route table or the neighbor table or if the neighbor index in the session table is different from its corresponding neighbor index in the neighbor table, then the session entry is stable. Therefore, the system will perform a route lookup using longest prefix match of the destination IP address of the session, and update the route information based on the results from the route lookup.
- Note that, in the route table, a version number corresponding to a route index changes whenever there is a change in the route, e.g., a change in the next hop address. On the other hand, in the neighbor table, a version number corresponding to a neighbor index changes whenever the mapping between the IP address and the MAC address of a network node (e.g., a default gateway or a next hop for a particular VLAN) changes, for example, when the Ethernet interface changes.
- The following sections describe a few exemplary scenarios in which a route could be changed during an active session, and how the system will detect the route change in each scenario. These examples are provided for illustration only. They are not intended to be an exhaustive list of all possible scenarios. One skilled in the art can apply the techniques disclosed herein to detect other types of route changes without departing from the spirit of the invention.
- A. Route Change
- In this scenario, the default gateway's IP address may change during a session because the route gets modified, for example, from “10.10.10.10” at time point t1 to “18.18.18.18” at time point t2. In the route table, assuming that, at t1, the route entry has the version number of 100, index value of 1, prefix/length value of “1.0.0.0/8,” and next hop IP address of “10.10.10.10.”
- Accordingly, in the session table, at time point t1, the session entry has values as shown in
session entry 760 in session table 720, e.g., having a source IP address of “100.100.100.100,” a destination IP address of “1.1.1.1,” a route index corresponding to route1, a route version of 100, a neighbor index corresponding to ARP1, and a neighbor version of 10. - Based on the change above, at time point t2, the same route entry has the version number of 101, index value of 1, prefix/length value of “1.0.0.0/8,” and next hop IP address of “18.18.18.18.”
- When the system receives the first packet in the session after the time point t2, the system will detect that the route version in the session table (e.g., 100) does not match the route version in the route table (e.g., 101). Thus, the system will deem the session entry as stale and perform a route lookup to update the session entry.
- After the update, the session entry will have the values as shown in
session entry 765 in session table 720, e.g., having a source IP address of “100.100.100.100,” a destination IP address of “1.1.1.1,” a route index corresponding to route1, a route version of 101, a neighbor index corresponding to ARP2, and a neighbor version of 20. Note that, the route version has changed from 100 to 101; the neighbor index has changed from ARP1 (corresponding to “10.10.10.10” in neighbor table 760) to ARP2 (corresponding to “18.18.18.18” in neighbor table 760); and, the neighbor version has changed from 10 (corresponding to APR1 in neighbor table 760) to 20 (corresponding to ARP2 in neighbor table 760). - Similarly, when a route is deleted rather than modified, the system will also detect a mismatch in the version numbers between the session table and the route table, because the corresponding route entry in the route table is missing. Therefore, the system will initiate a route lookup to search for a new route to the destination IP address based on the longest prefix match to the current route table (in which the original route was deleted), and update the session table with the information regarding the new route.
- Also, note that, the route lookup is performed when the system receives a packet in the session after time point t2. Thus, if no packet is received which indicates that the client is in an idle state, then the session entry will remain to be stale despite that a change has occurred in the route table at time point t2. This is because when the client is idle, the client is not using the route, and thus there is no need to spend any resources on updating the route for an idle client. Furthermore, if the session entry remains to be stale for an excessive amount of time because no client is using the session, the session entry will eventually be removed without ever being updated with the route change at all.
- B. Equal Cost Multiple Paths (ECMP)
-
FIG. 8A illustrates a use case scenario of ECMP, where there exits multiple paths with equal cost. In this example, a packet in a session flow fromnode A 800 to a destination address in L2/L3 Network 880 needs to be forwarded by the disclosed system. Further,node A 800 is interconnected with two different next hop nodes, which arenext hop A 810 andnext hop B 820. Each of the two different next hop nodes corresponds to a unique path to the destination address with equal cost. - For illustration purposes, assuming that,
next hop A 810 is associated with the IP address of “10.10.10.10” and is pre-existing at time point t1. Thus, at time point t1, in the route table, the route entry has the version number of 101, index value of 1, prefix/length value of “1.0.0.0/8,” and next hop IP address of “10.10.10.10” corresponding tonext hop A 810. - In addition, assuming that, at time point t2, a new route with equal cost from the source address to the destination address through
next hop B 820 becomes available during the session. Assuming that,next hop B 820 is associated with the IP address of “18.18.18.18.” - Accordingly, the route table will be updated. Thus, the same route entry now has the version number of 101, index value of 1, prefix/length value of “1.0.0.0/8,” and next hop IP address of “10.10.10.10; 18.18.18.18” corresponding to both
next hop A 810 andnext hop B 820. In this example, each next hop IP address corresponds to a unique ECMP index. In addition to caching the route index, the session may also cache the ECMP index in the cases involving ECMPs. Note that, the version number remains the same, but the ECMP index is increased with the additional ECMP route becoming available. - Subsequently, any new sessions to a destination address for which “1.0.0.0/8” provides the longest prefix match will be using the new ECMP route corresponding to
next hop B 820 with the IP address of “18.18.18.18.” Nevertheless, any existing route will continue to usenext hop A 810 with the IP address of “10.10.10.10,” because the route version number has not changed. As a result, the system will determine that the route throughnext hop A 810 is not stale and does not need to be changed or updated. - This scheme can be particularly useful when traffic from a private IP network is to be forwarded to two or more networks corresponding to different uplink service providers (e.g., AT&T® and Verizon®) via two or more different IP addresses, such as IP1 and IP2. It is desirable that the traffic to the first service provider is only transmitted via IP1, and the traffic to the second service provider is only transmitted via IP2. Therefore, the traffic from users of different service providers will not get mixed with each other.
- C. Virtual Router Redundancy Protocol (VRRP)
- Virtual Router Redundancy Protocol (VRRP) is a computer networking protocol that provides for automatic assignment of available IP routers to participating hosts. This increases the availability and reliability of routing paths via automatic default gateway selections on an IP sub-network. The VRRP protocol achieves this by creation of virtual routers, which are an abstract representation of multiple routers, i.e., master and backup routers, acting as a group. The default gateway of a participating host is assigned to the virtual router instead of a physical router. If the physical router that is routing packets on behalf of the virtual router fails, another physical router is selected to automatically replace it. The physical router that is forwarding packets at any given time is called the master router. Thus, at any given time, there is only one physical router that is actively forwarding the traffic.
-
FIG. 8B illustrates a use case scenario of VRRP, where there exits two alternative paths with alternative next hop nodes. In this example, a packet in a session flow fromnode A 800 to a destination address in L2/L3 Network 880 needs to be forwarded by the disclosed system. Further,node A 800 is interconnected with two different next hop nodes, which arenext hop A 810 andnext hop B 820. Each of the two different next hop nodes corresponds to the same virtual router underVRRP 815. Therefore, at any given time, traffic fromnode A 800 will be able to reachnext hop C 830 via eithernext hop A 810 ornext hop B 820 but not both, and the traffic will continue to be forwarded tonext hop C 830 via L2/L3 network 880. - Assuming that, at time point t1,
next hop A 810 is active underVRRP 815 and corresponds to the IP address of “10.10.10.10.” Thus, in the neighbor table, the neighbor entry has the version number of 10, index value of 1, IP address of “10.10.10.10,” MAC address of MACA (corresponding to next hop A 810), and VLAN identifier value of V10. - At time point t2, assuming that
next hop A 810 fails, andnext hop B 820 starts to function as the virtual router. Therefore, in the neighbor table, the same neighbor entry now has the version number of 11, index value of 1, IP address of “10.10.10.10,” MAC address of MACB (corresponding to next hop B 820), and VLAN identifier value of V10. - Because the neighbor version has changed from 10 to 11, the system will determine that the route has become stale. Consequently, the system will perform a route lookup and update the session entry in the session table with the new neighbor version number.
- D. Shorter Alternative Route
-
FIG. 8C illustrates a use case scenario in which an alternative shorter route is added during the session. In this example, a packet in a session flow fromnode A 800 to adestination node D 890 is initially forwarded throughnext hop B 820 and L2/L3 Network 880. Subsequently, assuming thatnode A 800 is interconnected with an additional next hop node, which isnext hop A 810, and thatnext hop A 810 is further interconnected withdestination node D 890. Here, for illustration purposes only, it is assumed that next hop A is associated with an IP address of “1.1.0.0” and that next hop B is associated with an IP address of “1.0.0.0.” Therefore, there are two alternative routes betweennode A 800 anddestination node D 890. Specifically, traffic fromnode A 800 will be able to reachdestination node D 890 vianext hop A 810, which provides a shorter route than the original route vianext hop B 820 and L2/L3 Network 880. - In some embodiments, route information can be maintained in a patricia trie. A patricia trie generally refers a space-optimized trie data structure, where each node with only one child is merged with its child. As a result, every internal node has at least two children. Unlike in regular tries, edges can be labeled with sequences of elements as well as single elements. This makes them much more efficient for small sets (especially if the strings are long) and for sets of strings that share long prefixes.
-
FIG. 9 illustrates an exemplary patricia trie used in session-based forwarding according to the present disclosure. In this given example, patricia trie 900 includes atleast root node 920, node 940, andnode 960, which correspond to “0.0.0.0/0,” “1.0.0.0/8,” and “1.1.0.0/16” respectively. Note that, node 940 is a child node ofroot node 920. Also,node 960 is a child node of node 940 and a grandchild node ofroot node 920. Therefore, in the patricia trie illustrated inFIG. 9 , a child node always has a longer prefix match than its parent node. - Furthermore, when a new route is inserted into a patricia trie as a new node (e.g., assuming that
node 960 is inserted as a child node of node 940), the disclosed system performs at least two operations: First, the system will add the new route (e.g., “1.1.0.0/16”) to the route table with a new route index that is different from the route index of the original route corresponding to the parent node in the patricia trie. Second, the system will increase, in the route table, the version number of the route corresponding to the parent node of the inserted node (e.g., the version number of route “1.0.0.0/8” will be increased from 100 to 101; note that the route “1.0.0.0/8” corresponds to parent node 940 of the insertednode 960 in this example). - Because the version number of the route corresponding to the parent node in the patricia trie gets updated, the corresponding route entry (e.g., “1.0.0.0/8”) becomes stale due to the difference in the route version number in the session table (e.g., 100) and in the route table (e.g., 101). Thus, the system will perform a route lookup to update the route information. As a result, the route lookup will return the shorter route, e.g., “1.1.0.0/16”, with a new route index instead of the original route (e.g., “1.0.0.0/8”). Thus, subsequent traffic from the same source node to the same destination node will be forwarded through the updated shorter route.
- Note that, as mentioned above, when traffic from a private IP network is to be forwarded to two or more networks corresponding to different uplink service providers (e.g., AT&T® and Verizon®) via two or more different IP addresses, such as IP1 and IP2, it is desirable that the traffic to the first service provider is only transmitted via IP1, and the traffic to the second service provider is only transmitted via IP2. In such scenarios, typically a network address translation (NAT) of either source IP address or destination IP address of the packets is involved. Nevertheless, when no NAT operation is involved and a shorter route is found during a session as in the example illustrated above in the description of
FIG. 8C andFIG. 9 , it would be desirable to switch to a shorter route during an existing session. - Note that, the route lookup is performed only when the system receives a packet in a session. Thus, if in a second session where the new route “1.1.0.0/16” can be used, but no packet is received in the second session due to the client being idle, then the session entry will remain to be stale despite that a new and shorter route has been inserted in the route table. This is because when the client is idle, the client is not using the route, and thus there is no need to spend any resources on updating the route for an idle client. Furthermore, if the session entry remains to be stale for an excessive amount of time because no client is using the session, the session entry will eventually be removed without ever being updated with the route change at all.
- It is important to note that, in the present disclosure, only active purging is used, and there is not background purging involved. Therefore, a session is updated only when there are active traffic activities in the session. No background process is used to update the session entries, because there is no need to utilize the resource for a session when the session is idle.
- In some embodiments, a computing environment as illustrated in
FIG. 1 may have a L2/L3 network betweencontroller 100 andaccess point 160. In such embodiments, a L2 or L3 tunnel (e.g., a Generic Routing Encapsulation (GRE) tunnel) can be established betweencontroller 100 andaccess point 160 for transmission of packets to and fromclient 170. A tunnel is generally represented as (source IP address, destination IP address, protocol, L4 attributes), and is usually identified by a unique session key. - As illustrated in
FIG. 3 , a typical network forwarding process includes, inter alia, a bridge lookup 315 (e.g., on an Ethernet packet formatted as IEEE 802.3 packet), afirewall session lookup 320, aroute lookup 325, a forwardinglookup 330, etc. Then, if it is determined that the packet needs to be transmitted via a tunnel between a controller and an access point, the packet is further encapsulated with an outer header, e.g., a GRE header, to be converted to an IEEE 802.11 packet format. The encapsulated packet in IEEE 802.11 format again goes through the same series of network forwarding process, e.g., afirewall session lookup 320, aroute lookup 325, a forwardinglookup 330, etc., before it can be properly forwarded to its destination. - In a system as illustrated in
FIG. 2 , one of datapath processors 220 (e.g.,FP CPU 1 240,FP CPU 2 242, . . . , or FP CPU N 248) will perform a session and/or route lookup, then send the packet to a security engine (not shown) for encryption. The encrypted (and encapsulated) packet will be returned back to datapath processors 220, which will then forward the encrypted and encapsulated packet to itscorresponding network interface 250. - In some embodiments, datapath processors 220 may perform encapsulation prior to sending the packet to the security engine for encryption. In addition, datapath processors 220 may instruct the security engine which
destination network interface 250 is associated with the packet. Therefore, after the security engine completes the encryption of the packet, the security engine can directly forward the packet to its correspondingdestination network interface 250 without returning the encapsulated packet to datapath processors 220. - Specifically, the system will first perform a route and neighbor (e.g., ARP) lookup, which will return a MAC address and a VLAN identifier corresponding to the destination IP address in the packet. Next, based on the combination of MAC and VLAN identifier, the system performs a bridge lookup, which will return a destination network interface that can be either a port identifier or a tunnel identifier.
- Based on the MAC address corresponding to the destination IP address, the system can determine whether the packet is a unicast packet or a multicast packet. If the packet is a unicast packet, the system can use a unicast key to encrypt the packet. On the other hand, if the packet is a multicast packet, the system can use a tunnel or multicast key to encrypt the packet.
- Furthermore, based on the destination network interface, the system can determine whether the packet needs to encapsulated. For example, if the destination network interface returned from the bridge lookup is associated with a GRE tunnel, then the system can determine that the packet will need to be encapsulated with the GRE headers before being forwarded to its destination. Typically, in order to perform an encapsulation, the system needs to know the tunnel information for the packet, which includes the source and destination IP addresses (available in the header of the packet), the transmission protocol (which can be determined based on the tunnel identifier), and L4 attributes associated with the packet (which are usually cached in the tunnel). Therefore, upon successful bridge lookup, the system would be able to perform an encapsulation of the packet based on the information returned from the bridge lookup.
- Note that, if the system identifies that a packet needs to be encrypted and encapsulated, the system can perform the encapsulation prior to the encryption, and thereby avoiding the need for the packet to be returned to datapath processors after encryption. This simplified packet flow within the system, e.g., from the FP processors to security engine directly to network interface without the packet being returned to the FP processors by the security engine, allows for dramatic performance enhancement in a high performance controlling and switching system.
- After session entries are cached in a tunnel, the system can combine the tunnel encapsulation operations with the L2/L3 lookups (such as,
firewall session lookup 320,route lookup 325, forwardinglookup 330, etc.), and thereby avoid feeding the network forwarding process twice with the same packet (but differently formatted as IEEE 802.3 for the first time and IEEE 802.11 for the second time). In one embodiment, a link from the tunnel to the session (e.g., index value of the corresponding session entry in the session table) is maintained where the session further includes routing information as described above. The link will provide quick access to important routing information stored in session, and therefore allowing for determination of whether the system can leverage the session information for simplified session-based forwarding (e.g., where no complex firewall operations are required for the session). - Furthermore, for subsequent packets within the same session, the system can use the cached link to the session entry to retrieve the routing information, and thus avoiding feeding the packets through the session forwarding pipeline process. In summary, rather than feeding every packet through the session forwarding pipeline twice (first with IEEE 802.3 format and second with IEEE 802.11 format), the present disclosure allows for the first packet in a flow to be sent through the session forwarding pipeline once whereby the encryption and encapsulation operations are combined into the pipeline process, and for any subsequent packets to bypass the session forwarding pipeline by providing a direct link from tunnel to the corresponding session entry, which caches the corresponding routing information returned from the route lookup performed for the first packet in the flow.
-
FIGS. 10A-10B are flowcharts illustrating exemplary processes for session-based forwarding. Specifically,FIG. 10A illustrates an exemplary session-based forwarding process in which route references are cached in the session to avoid per-packet based route lookup. During operation, the disclosed system receives a first data packet in a session (operation 1000). The system then performs a route lookup to determine a route for the first packet (operation 1005). In addition, for session-based forwarding, the disclosed system caches a reference to the route and the neighbor in the session (operation 1010). Further, the disclosed system optionally caches a reference to the session and the neighbor in a tunnel in cases where tunnel-based forwarding mechanism is used (operation 1015). The reference to the route includes one or more of a route index, a route version number, a neighbor index, and a neighbor version number. In some embodiments, the tunnel can be a GRE tunnel within which packets in the session are to be forwarded. Note that, caching the reference to the session in the tunnels allows for direct access to the route information from the tunnel. - Moreover, the disclosed system compares a first route version number cached in the session with a second route version number cached in a route (operation 1020), and then determines whether the route is stale (operation 1025). In some embodiments, the system further compares a first neighbor index and version number cached in the session with a second neighbor index and version number corresponding to the route in a neighbor table, and determines that the route is stale if the first neighbor index or version number is different from the second neighbor index or version number.
- If the system determines that the route is stale, the system will perform another route lookup to update the route (operation 1030). Specifically, the system may update the route with one or more of an updated route index, an updated route version number, an updated neighbor index, and an updated neighbor index number. Nevertheless, in some embodiments, if the system determines that the route is stale but the session is inactive, the system will delay route lookup until at least one packet is received in the session.
- In some embodiments, at least two paths with identical cost corresponding to the route are stored in the route table; and, each path is identified by a unique Equal Cost Multiple Path (ECMP) index. When a new ECMP index is added to the route table, a subsequent session uses the path associated with the new ECMP index, but an existing session continues to use an existing path associated with an existing ECMP index.
- In some embodiments, at least two next hop nodes use Virtual Router Redundancy Protocol (VRRP), the route is determined to be stale based on the difference between a first neighbor version number cached in the session and a second neighbor version number corresponding to the route in the neighbor table.
- Next, when tunnel-based forwarding mechanism is used, the system can use the cached reference to the session in the tunnel for forwarding subsequent packets in the session (operation 1035). Thus, the system only needs to perform a route lookup for the first packet in a session unless there are route changes during the session that prompts for another route lookup to update the route.
- In other embodiments, when a route is determined to be stale, the system performs another route lookup to update the session with an updated route index and an updated route version number. Such updated route index and updated route version number may correspond to a shorter alternative route than the original route. If so, the system will forward subsequent packets in the session using the shorter alternative route. In one embodiment, the shorter alternative route is stored in a patricia trie as a child node of a parent node. Specifically, the parent node corresponds to the route; and, a route version number corresponding to the parent node is increased when a child node is inserted in the patricia trie.
-
FIG. 10B illustrates an exemplary session-based forwarding process in which a packet is encapsulated prior to being forwarded to a security engine such that the security engine can forward encrypted packet directly to the corresponding network interface. During operation, the disclosed system performs a bridge lookup based on a received packet (operation 1040). Then, the system encapsulates the packet based on information returned from the bridge lookup (operation 1045). Also, the system identifies a network interface that the packet is to be transmitted on (operation 1050). Then, the system sends the packet to a security engine for encryption (operation 1055). Furthermore, the system instructs the security engine to forward the encrypted packet to the identified network interface (operation 1060). Thus, unlike conventional forwarding process, the security engine does not need to return the packet to a process within the system and can directly forward the encrypted packets to a network via the identified network interface. -
FIG. 11 is a block diagram illustrating a network device system for session-based forwarding according to embodiments of the present disclosure.Network device 1100 includes at least anetwork interface 1110 capable of communicating to a wired network, a sharedmemory 1120 capable of storing data, a exceptionprocessing processor core 1130 capable of processing network data packets, and one or more forwarding processor cores, including forwardingprocessor core 1142, forwardingprocessor core 1144, . . . , forwardingprocessor core 1148, which are capable of processing network data packets. Moreover,network device 1100 may be used as a network switch, network router, network controller, network server, etc.Further network device 1100 may serve as a node in a distributed or a cloud computing environment. -
Network interface 1110 can be any communication interface, which includes but is not limited to, a modem, token ring interface, Ethernet interface, wireless IEEE 802.11 interface (e.g., IEEE 802.11n, IEEE 802.11ac, etc.), cellular wireless interface, satellite transmission interface, or any other interface for coupling network devices. In some embodiments,network interface 1110 may be software-defined and programmable, for example, via an Application Programming Interface (API), and thus allowing for remote control of thenetwork device 1100. - Shared
memory 1120 can include storage components, such as, Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), etc. In some embodiments, sharedmemory 1120 is a flat structure that is shared by all datapath processors (including, e.g., exceptionprocessing processor core 1130, forwardingprocessor core 1142, forwardingprocessor core 1144, . . . , forwardingprocessor core 1148, etc.), and not tied to any particular CPU or CPU cores. Any datapath processor can read any memory location within sharedmemory 1120. Sharedmemory 1120 can be used to store various tables to assist session-based packet forwarding. For example, the tables may include, but are not limited to, a bridge table, a session table, a user table, a station table, a tunnel table, a route table and/or route cache, etc. It is important to note that there is no locking mechanism associated with sharedmemory 1120. Any datapath processor can have access to any location in lockless shared memory innetwork device 1100. - Exception
processing processor core 1130 typically includes a networking processor core that is capable of processing network data traffic. Exceptionprocessing processor core 1130 is a single dedicated CPU core that typically handles table managements. Note that,slowpath processor core 1130 only receives data packets from one or more forwarding processor cores, such as forwardingprocessor core 1142, forwardingprocessor core 1144, . . . , forwardingprocessor core 1148. In other words, exceptionprocessing processor core 1130 does not receive data packets directly from any line cards or network interfaces. Only the plurality of forwarding processor cores can send data packets to exceptionprocessing processor core 1130. Moreover, exceptionprocessing processor core 1130 is the only processor core having the write access to sharedmemory 1120, and thereby will not cause any data integrity issues even without a locking mechanism in place for sharedmemory 1120. - Forwarding processor cores 1142-1148 also include networking processor cores that are capable of processing network data traffic. However, by definition, forwarding processor cores 1142-1148 only performs “fast” packet processing. Thus, forwarding processor cores 1142-1149 do not block themselves and wait for other components or modules during the processing of network packets. Any packets requiring special handling or wait by a processor core will be handed over by forwarding processor cores 1142-1148 to exception
processing processor core 1130. - Each of forwarding processor cores 1142-1148 maintains one or more counters. The counters are defined as a regular data type, for example, unsigned integer, unsigned long long, etc., in lieu of an atomic data type. When a forwarding processor core 1142-1148 receives a packet, it may increment or decrement the values of the counters to reflect network traffic information, including but not limited to, the number of received frames, the number of received bytes, error conditions and/or error counts, etc. A typical pipeline process at forwarding processor cores 1142-1148 includes one or more of: port lookup; VLAN lookup; port-VLAN table lookup; bridge table lookup; firewall session table lookup; route table lookup; packet encapsulation; packet encryption; packet decryption; tunnel de-capsulation; forwarding; etc.
- Moreover, forwarding processor cores 1142-1148 each can maintain a fragment table. Upon receiving a data fragment without information necessary for session processing (e.g., a transport layer or L4 header), forwarding processor cores 1142-1148 will queue the data fragments in their own fragment table, and perform various fragment table management tasks.
- Periodically, exception
processing processor core 1130 may receive a query corresponding to one or more forwarding processor cores 1142-1148 from a control plane process. Exceptionprocessing processor core 1130 identifies one or more memory locations in the shared memory storing data for the one or more forwarding processor cores 1142-1148 corresponding to the query, retrieves one or more data values at the identified memory locations, and responds to the query. In some embodiments, exceptionprocessing processor core 1130 can further aggregate retrieved data values to generate an aggregated data value, and respond to the query based on the aggregated data value. - According to embodiments of the present disclosure, network services provided by
network device 1100, solely or in combination with other wireless network devices, include, but are not limited to, an Institute of Electrical and Electronics Engineers (IEEE) 802.1x authentication to an internal and/or external Remote Authentication Dial-In User Service (RADIUS) server; an MAC authentication to an internal and/or external RADIUS server; a built-in Dynamic Host Configuration Protocol (DHCP) service to assign wireless client devices IP addresses; an internal secured management interface; Layer-3 forwarding; Network Address Translation (NAT) service between the wireless network and a wired network coupled to the network device; an internal and/or external captive portal; an external management system for managing the network devices in the wireless network; etc. - The present disclosure may be realized in hardware, software, or a combination of hardware and software. The present disclosure may be realized in a centralized fashion in one computer system or in a distributed fashion where different elements are spread across several interconnected computer systems coupled to a network. A typical combination of hardware and software may be an access point with a computer program that, when being loaded and executed, controls the device such that it carries out the methods described herein.
- The present disclosure also may be embedded in non-transitory fashion in a computer-readable storage medium (e.g., a programmable circuit; a semiconductor memory such as a volatile memory such as random access memory “RAM,” or non-volatile memory such as read-only memory, power-backed RAM, flash memory, phase-change memory or the like; a hard disk drive; an optical disc drive; or any connector for receiving a portable memory device such as a Universal Serial Bus “USB” flash drive), which comprises all the features enabling the implementation of the methods described herein, and which when loaded in a computer system is able to carry out these methods. Computer program in the present context means any expression, in any language, code or notation, of a set of instructions intended to cause a system having an information processing capability to perform a particular function either directly or after either or both of the following: a) conversion to another language, code or notation; b) reproduction in a different material form.
- As used herein, “digital device” generally includes a device that is adapted to transmit and/or receive signaling and to process information within such signaling such as a station (e.g., any data processing equipment such as a computer, cellular phone, personal digital assistant, tablet devices, etc.), an access point, data transfer devices (such as network switches, routers, controllers, etc.) or the like.
- As used herein, “access point” (AP) generally refers to receiving points for any known or convenient wireless access technology which may later become known. Specifically, the term AP is not intended to be limited to IEEE 802.11-based APs. APs generally function as an electronic device that is adapted to allow wireless devices to connect to a wired network via various communications standards.
- As used herein, the term “interconnect” or used descriptively as “interconnected” is generally defined as a communication pathway established over an information-carrying medium. The “interconnect” may be a wired interconnect, wherein the medium is a physical medium (e.g., electrical wire, optical fiber, cable, bus traces, etc.), a wireless interconnect (e.g., air in combination with wireless signaling technology) or a combination of these technologies.
- As used herein, “information” is generally defined as data, address, control, management (e.g., statistics) or any combination thereof. For transmission, information may be transmitted as a message, namely a collection of bits in a predetermined format. One type of message, namely a wireless message, includes a header and payload data having a predetermined number of bits of information. The wireless message may be placed in a format as one or more packets, frames or cells.
- As used herein, “wireless local area network” (WLAN) generally refers to a communications network links two or more devices using some wireless distribution method (for example, spread-spectrum or orthogonal frequency-division multiplexing radio), and usually providing a connection through an access point to the Internet; and thus, providing users with the mobility to move around within a local coverage area and still stay connected to the network.
- As used herein, the term “mechanism” generally refers to a component of a system or device to serve one or more functions, including but not limited to, software components, electronic components, electrical components, mechanical components, electro-mechanical components, etc.
- As used herein, the term “embodiment” generally refers an embodiment that serves to illustrate by way of example but not limitation.
- It will be appreciated to those skilled in the art that the preceding examples and embodiments are exemplary and not limiting to the scope of the present disclosure. It is intended that all permutations, enhancements, equivalents, and improvements thereto that are apparent to those skilled in the art upon a reading of the specification and a study of the drawings are included within the true spirit and scope of the present disclosure. It is therefore intended that the following appended claims include all such modifications, permutations and equivalents as fall within the true spirit and scope of the present disclosure.
- While the present disclosure has been described in terms of various embodiments, the present disclosure should not be limited to only those embodiments described, but can be practiced with modification and alteration within the spirit and scope of the appended claims. Likewise, where a reference to a standard is made in the present disclosure, the reference is generally made to the current version of the standard as applicable to the disclosed technology area. However, the described embodiments may be practiced under subsequent development of the standard within the spirit and scope of the description and appended claims. The description is thus to be regarded as illustrative rather than limiting.
Claims (27)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/918,748 US20140153577A1 (en) | 2012-12-03 | 2013-06-14 | Session-based forwarding |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201261732829P | 2012-12-03 | 2012-12-03 | |
US13/918,748 US20140153577A1 (en) | 2012-12-03 | 2013-06-14 | Session-based forwarding |
Publications (1)
Publication Number | Publication Date |
---|---|
US20140153577A1 true US20140153577A1 (en) | 2014-06-05 |
Family
ID=50825368
Family Applications (7)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/918,732 Active 2034-07-01 US10263916B2 (en) | 2012-12-03 | 2013-06-14 | System and method for message handling in a network device |
US13/918,770 Active 2034-03-17 US9800503B2 (en) | 2012-12-03 | 2013-06-14 | Control plane protection for various tables using storm prevention entries |
US13/918,748 Abandoned US20140153577A1 (en) | 2012-12-03 | 2013-06-14 | Session-based forwarding |
US13/918,760 Active 2033-12-01 US9467326B2 (en) | 2012-12-03 | 2013-06-14 | Rate limiting mechanism based on device load/capacity or traffic content |
US13/928,300 Active 2033-09-05 US9065701B2 (en) | 2012-12-03 | 2013-06-26 | Enhanced serialization mechanism |
US14/018,129 Active 2033-09-12 US9100242B2 (en) | 2012-12-03 | 2013-09-04 | System and method for maintaining captive portal user authentication |
US16/384,074 Abandoned US20190245809A1 (en) | 2012-12-03 | 2019-04-15 | System and method for message handling in a network device |
Family Applications Before (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/918,732 Active 2034-07-01 US10263916B2 (en) | 2012-12-03 | 2013-06-14 | System and method for message handling in a network device |
US13/918,770 Active 2034-03-17 US9800503B2 (en) | 2012-12-03 | 2013-06-14 | Control plane protection for various tables using storm prevention entries |
Family Applications After (4)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/918,760 Active 2033-12-01 US9467326B2 (en) | 2012-12-03 | 2013-06-14 | Rate limiting mechanism based on device load/capacity or traffic content |
US13/928,300 Active 2033-09-05 US9065701B2 (en) | 2012-12-03 | 2013-06-26 | Enhanced serialization mechanism |
US14/018,129 Active 2033-09-12 US9100242B2 (en) | 2012-12-03 | 2013-09-04 | System and method for maintaining captive portal user authentication |
US16/384,074 Abandoned US20190245809A1 (en) | 2012-12-03 | 2019-04-15 | System and method for message handling in a network device |
Country Status (1)
Country | Link |
---|---|
US (7) | US10263916B2 (en) |
Cited By (48)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20150117445A1 (en) * | 2011-08-17 | 2015-04-30 | Nicira, Inc. | Packet Conflict Resolution |
US20150281062A1 (en) * | 2014-03-31 | 2015-10-01 | Arista Networks, Inc. | System and method for route health injection using virtual tunnel endpoints |
US20160080261A1 (en) * | 2011-08-17 | 2016-03-17 | Nicira, Inc. | Last-Hop Processing for Reverse Direction Packets |
US9420607B1 (en) | 2014-05-28 | 2016-08-16 | Cisco Technology, Inc. | System and method for handling stray session requests in a network environment |
US20170168864A1 (en) * | 2015-12-09 | 2017-06-15 | Varmour Networks, Inc. | Directing Data Traffic Between Intra-Server Virtual Machines |
US9697030B2 (en) | 2011-11-15 | 2017-07-04 | Nicira, Inc. | Connection identifier assignment and source network address translation |
US9762599B2 (en) | 2016-01-29 | 2017-09-12 | Varmour Networks, Inc. | Multi-node affinity-based examination for computer network security remediation |
US20180034734A1 (en) * | 2016-07-28 | 2018-02-01 | Fortinet, Inc. | Network processing unit (npu) integrated layer 2 network device for layer 3 offloading |
US9923814B2 (en) * | 2015-02-17 | 2018-03-20 | Huawei Technologies Co., Ltd. | Media access control address resolution using internet protocol addresses |
US20180115470A1 (en) * | 2016-10-26 | 2018-04-26 | Arizona Board Of Regents On Behalf Of Arizona State University | Security policy analysis framework for distributed software defined networking (sdn) based cloud environments |
US9973472B2 (en) | 2015-04-02 | 2018-05-15 | Varmour Networks, Inc. | Methods and systems for orchestrating physical and virtual switches to enforce security boundaries |
US10009317B2 (en) | 2016-03-24 | 2018-06-26 | Varmour Networks, Inc. | Security policy generation using container metadata |
US10009381B2 (en) | 2015-03-30 | 2018-06-26 | Varmour Networks, Inc. | System and method for threat-driven security policy controls |
US10091238B2 (en) | 2014-02-11 | 2018-10-02 | Varmour Networks, Inc. | Deception using distributed threat detection |
US10193929B2 (en) | 2015-03-13 | 2019-01-29 | Varmour Networks, Inc. | Methods and systems for improving analytics in distributed networks |
CN109347623A (en) * | 2018-10-18 | 2019-02-15 | 盛科网络(苏州)有限公司 | Conversate the method and device of holding in a kind of application of balancing link load |
US10264025B2 (en) | 2016-06-24 | 2019-04-16 | Varmour Networks, Inc. | Security policy generation for virtualization, bare-metal server, and cloud computing environments |
US10333986B2 (en) | 2015-03-30 | 2019-06-25 | Varmour Networks, Inc. | Conditional declarative policies |
US10382467B2 (en) | 2016-01-29 | 2019-08-13 | Varmour Networks, Inc. | Recursive multi-layer examination for computer network security remediation |
US10454897B1 (en) * | 2016-01-21 | 2019-10-22 | Amazon Technologies, Inc. | Proxy captive portal traffic for input-limited devices |
US10484263B2 (en) * | 2017-01-16 | 2019-11-19 | International Business Machines Corporation | Route-cost acquisition from routers |
US10601832B1 (en) | 2016-03-30 | 2020-03-24 | Amazon Technologies, Inc. | Proxy captive portal traffic for input-limited devices |
US20200177548A1 (en) * | 2015-11-17 | 2020-06-04 | Zscaler, Inc. | Multi-tenant cloud-based firewall systems and methods |
CN111277518A (en) * | 2020-01-22 | 2020-06-12 | 盛科网络(苏州)有限公司 | Information processing method, Ethernet switching chip and storage medium |
US10755334B2 (en) | 2016-06-30 | 2020-08-25 | Varmour Networks, Inc. | Systems and methods for continually scoring and segmenting open opportunities using client data and product predictors |
US10880208B1 (en) * | 2019-02-11 | 2020-12-29 | Google Llc | Offloads for multicast virtual network packet processing in a network interface card |
CN112351250A (en) * | 2020-10-21 | 2021-02-09 | 杭州海康威视数字技术股份有限公司 | Encoding parameter adjusting method, device and equipment and storage medium |
CN113422722A (en) * | 2021-06-16 | 2021-09-21 | 锐捷网络股份有限公司 | Route processing method and device |
US20210357400A1 (en) * | 2018-09-19 | 2021-11-18 | Censhare Gmbh | Efficient in-memory multi-version concurrency control for a trie data structure based database |
CN113924762A (en) * | 2019-05-30 | 2022-01-11 | 诺基亚通信公司 | Activation of PDU sessions and QoS flows in 3 GPP-based Ethernet bridges |
US11233778B2 (en) * | 2018-08-15 | 2022-01-25 | Juniper Networks, Inc. | Secure forwarding of tenant workloads in virtual networks |
US11290494B2 (en) | 2019-05-31 | 2022-03-29 | Varmour Networks, Inc. | Reliability prediction for cloud security policies |
US11290493B2 (en) | 2019-05-31 | 2022-03-29 | Varmour Networks, Inc. | Template-driven intent-based security |
WO2022072083A1 (en) | 2020-09-29 | 2022-04-07 | Palo Alto Networks, Inc. | Enhanced sd-wan path quality measurement and selection |
US11310284B2 (en) | 2019-05-31 | 2022-04-19 | Varmour Networks, Inc. | Validation of cloud security policies |
US11329966B2 (en) | 2018-08-15 | 2022-05-10 | Juniper Networks, Inc. | System and method for transferring packets between kernel modules in different network stacks |
US11405775B2 (en) * | 2017-04-28 | 2022-08-02 | Hewlett Packard Enterprise Development Lp | Three-address scheme for forwarding frames in a wireless mesh network |
US11523319B2 (en) * | 2017-01-09 | 2022-12-06 | Lg Electronics Inc. | Method for managing PDU session in wireless communication system and device for same |
US11575563B2 (en) | 2019-05-31 | 2023-02-07 | Varmour Networks, Inc. | Cloud security management |
US11711374B2 (en) | 2019-05-31 | 2023-07-25 | Varmour Networks, Inc. | Systems and methods for understanding identity and organizational access to applications within an enterprise environment |
US11734316B2 (en) | 2021-07-08 | 2023-08-22 | Varmour Networks, Inc. | Relationship-based search in a computing environment |
US11777978B2 (en) | 2021-01-29 | 2023-10-03 | Varmour Networks, Inc. | Methods and systems for accurately assessing application access risk |
US11818152B2 (en) | 2020-12-23 | 2023-11-14 | Varmour Networks, Inc. | Modeling topic-based message-oriented middleware within a security system |
US11863580B2 (en) | 2019-05-31 | 2024-01-02 | Varmour Networks, Inc. | Modeling application dependencies to identify operational risk |
US11870691B2 (en) | 2015-07-07 | 2024-01-09 | Cisco Technology, Inc. | Intelligent wide area network (IWAN) |
US11876817B2 (en) | 2020-12-23 | 2024-01-16 | Varmour Networks, Inc. | Modeling queue-based message-oriented middleware relationships in a security system |
US11902876B2 (en) * | 2018-10-30 | 2024-02-13 | Huawei Technologies Co., Ltd. | Routing management method and apparatus |
US12050693B2 (en) | 2021-01-29 | 2024-07-30 | Varmour Networks, Inc. | System and method for attributing user behavior from multiple technical telemetry sources |
Families Citing this family (45)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9424159B2 (en) * | 2013-10-10 | 2016-08-23 | International Business Machines Corporation | Performance measurement of hardware accelerators |
EP2863597B1 (en) * | 2013-10-21 | 2016-01-06 | Accenture Global Services Limited | Computer-implemented method, computer system, computer program product to manage traffic in a network |
US10044612B2 (en) * | 2013-11-06 | 2018-08-07 | Citrix Systems, Inc. | Systems and methods for port allocation |
WO2015071888A1 (en) * | 2013-11-18 | 2015-05-21 | Telefonaktiebolaget L M Ericsson (Publ) | Multi-tenant isolation in a cloud environment using software defined networking |
US9480100B2 (en) * | 2014-01-15 | 2016-10-25 | Cisco Technology, Inc. | Wireless client device roaming among clustered access points |
CN104980412B (en) | 2014-04-14 | 2018-07-13 | 阿里巴巴集团控股有限公司 | A kind of applications client, server-side and corresponding portal authentication method |
US10102019B2 (en) * | 2014-06-09 | 2018-10-16 | Verizon Patent And Licensing Inc. | Analyzing network traffic for layer-specific corrective actions in a cloud computing environment |
US9383989B1 (en) | 2014-06-16 | 2016-07-05 | Symantec Corporation | Systems and methods for updating applications |
US10021028B2 (en) * | 2014-06-16 | 2018-07-10 | International Business Machines Corporation | Controlling incoming traffic |
US9596164B1 (en) * | 2014-06-26 | 2017-03-14 | Juniper Networks, Inc. | Application visibility in layer 3 networks |
WO2016061766A1 (en) | 2014-10-22 | 2016-04-28 | 华为技术有限公司 | Service flow control method, controller and system in object-based storage system |
CA2969713A1 (en) | 2014-12-05 | 2016-06-09 | Wal-Mart Stores, Inc. | System and method for generating globally-unique identifiers |
US9992223B2 (en) * | 2015-03-20 | 2018-06-05 | Nxp Usa, Inc. | Flow-based anti-replay checking |
US10078473B2 (en) * | 2015-03-23 | 2018-09-18 | Netapp, Inc. | Resource allocation in networked storage systems |
JP6332200B2 (en) * | 2015-08-26 | 2018-05-30 | 株式会社村田製作所 | Electronic components |
US10154062B2 (en) * | 2015-09-25 | 2018-12-11 | Nxp Usa, Inc. | Rule lookup using predictive tuples based rule lookup cache in the data plane |
CA3001987A1 (en) * | 2015-09-28 | 2017-04-06 | Walmart Apollo, Llc | Cloud based session management system |
US10404778B2 (en) | 2015-12-09 | 2019-09-03 | Walmart Apollo, Llc | Session hand-off for mobile applications |
US10230633B2 (en) * | 2016-01-21 | 2019-03-12 | Red Hat, Inc. | Shared memory communication in software defined networking |
US10348737B2 (en) * | 2016-03-08 | 2019-07-09 | International Business Machines Corporation | Login performance |
BR112019003675A2 (en) | 2016-08-24 | 2019-05-21 | Viasat Inc | method for device shaping traffic on a communications network, user-side network node communications system, communications system, and provider-side network node system |
US10735954B2 (en) | 2016-09-02 | 2020-08-04 | Blackberry Limited | Method and device for facilitating authentication over a wireless network |
FR3059500A1 (en) * | 2016-11-29 | 2018-06-01 | Orange | LIGHTING AND OPTICAL COMMUNICATION DEVICE COMBINED WITH VISUALIZATION OF THE FIELD OF COMMUNICATION |
CN106714164B (en) * | 2016-12-09 | 2020-10-30 | 上海斐讯数据通信技术有限公司 | Acquisition method of resource file in Portal page, wireless AP and Portal server |
US10263859B2 (en) * | 2017-01-11 | 2019-04-16 | Sony Interactive Entertainment LLC | Delaying new session initiation in response to increased data traffic latency |
US10855616B2 (en) * | 2017-01-11 | 2020-12-01 | Sony Interactive Entertainment LLC | Predicting wait time for new session initiation during increased data traffic latency |
US10834230B2 (en) | 2017-08-25 | 2020-11-10 | International Business Machines Corporation | Server request management |
US11593134B2 (en) * | 2018-01-26 | 2023-02-28 | Nicira, Inc. | Throttling CPU utilization by implementing a rate limiter |
GB2571576B (en) * | 2018-03-02 | 2022-06-15 | Ssh Communications Security Oyj | Processing packets in a computer system |
WO2019195086A1 (en) | 2018-04-03 | 2019-10-10 | Walmart Apollo, Llc | Customized service request permission control system |
US11063940B2 (en) * | 2018-04-27 | 2021-07-13 | Hewlett Packard Enterprise Development Lp | Switch authentication |
US10644970B2 (en) | 2018-07-11 | 2020-05-05 | Sony Interactive Entertainment LLC | Tracking application utilization of microservices |
US10942791B2 (en) * | 2018-09-17 | 2021-03-09 | Oracle International Corporation | Managing load in request processing environments |
CN109361714B (en) * | 2018-12-18 | 2021-11-16 | 中国移动通信集团江苏有限公司 | User login authentication method, device, equipment and computer storage medium |
US11171961B2 (en) | 2019-05-09 | 2021-11-09 | Cisco Technology, Inc. | Secure captive portal remediation |
US10922024B1 (en) * | 2019-06-28 | 2021-02-16 | Amazon Technologies, Inc. | Self-protection against serialization incompatibilities |
EP3767973B1 (en) * | 2019-07-18 | 2022-02-16 | neXenio GmbH | Method for broadcasting data |
US20220247719A1 (en) * | 2019-09-24 | 2022-08-04 | Pribit Technology, Inc. | Network Access Control System And Method Therefor |
US11483246B2 (en) | 2020-01-13 | 2022-10-25 | Vmware, Inc. | Tenant-specific quality of service |
US11599395B2 (en) | 2020-02-19 | 2023-03-07 | Vmware, Inc. | Dynamic core allocation |
US11539633B2 (en) * | 2020-08-31 | 2022-12-27 | Vmware, Inc. | Determining whether to rate limit traffic |
US11677717B2 (en) * | 2021-03-22 | 2023-06-13 | Cloudflare, Inc. | Unified network service that connects multiple disparate private networks and end user client devices operating on separate networks |
US11799784B2 (en) | 2021-06-08 | 2023-10-24 | Vmware, Inc. | Virtualized QoS support in software defined networks |
US11841871B2 (en) | 2021-06-29 | 2023-12-12 | International Business Machines Corporation | Managing extract, transform and load systems |
US12047440B2 (en) | 2021-10-05 | 2024-07-23 | International Business Machines Corporation | Managing workload in a service mesh |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030037042A1 (en) * | 1999-12-08 | 2003-02-20 | Nec Corporation | Table searching technique |
US20050105524A1 (en) * | 2003-11-17 | 2005-05-19 | Hughes Electronics Corporation | System and method for provisioning of route information in a meshed communications network |
US20100037311A1 (en) * | 2006-11-20 | 2010-02-11 | Liwen He | Secure network architecture |
US20110292933A1 (en) * | 2010-05-26 | 2011-12-01 | Alcatel-Lucent Usa, Inc. | Dynamic route cost adjustment of vrrp enabled subnets for routing protocols |
US20120057599A1 (en) * | 2010-09-03 | 2012-03-08 | Futurewei Technologies, Inc. | System and Method for Virtual Private Local Area Network Service to Use the Flow Aware Pseudowire |
US20130286846A1 (en) * | 2012-04-25 | 2013-10-31 | Juniper Networks, Inc. | Path weighted equal-cost multipath |
Family Cites Families (85)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5400325A (en) * | 1993-06-29 | 1995-03-21 | Synoptics Communications, Inc. | Method and apparatus providing for hunt groups in an ATM network of the like |
DE69507724T2 (en) * | 1995-06-19 | 1999-09-30 | Ibm Semea S.P.A., Mailand/Milano | METHOD AND METHOD FOR RECEIVING DATA PACKAGES IN A ONE-WAY TRANSMISSION DEVICE |
JPH10154995A (en) * | 1996-11-20 | 1998-06-09 | Fujitsu Ltd | Gateway system and method for relaying packet |
US5920566A (en) * | 1997-06-30 | 1999-07-06 | Sun Microsystems, Inc. | Routing in a multi-layer distributed network element |
US6118760A (en) * | 1997-06-30 | 2000-09-12 | Sun Microsystems, Inc. | Management of entries in a network element forwarding memory |
US6167450A (en) * | 1997-07-30 | 2000-12-26 | International Business Machines Corporation | Data communications management system and protocol replacement method for mobile communication environments |
US6098172A (en) * | 1997-09-12 | 2000-08-01 | Lucent Technologies Inc. | Methods and apparatus for a computer network firewall with proxy reflection |
US6158008A (en) * | 1997-10-23 | 2000-12-05 | At&T Wireless Svcs. Inc. | Method and apparatus for updating address lists for a packet filter processor |
US6118765A (en) * | 1998-01-13 | 2000-09-12 | Qualcomm Inc. | System method and computer program product for eliminating unnecessary retransmissions |
US6195688B1 (en) * | 1998-05-07 | 2001-02-27 | International Business Machines Corporation | Computer system, program product and method of communicating internetworking data over a master-slave communication link |
US6212195B1 (en) * | 1998-12-01 | 2001-04-03 | 3Com Corporation | Telecommunication apparatus and method for forwarding packets using separate collision domains |
US6535511B1 (en) * | 1999-01-07 | 2003-03-18 | Cisco Technology, Inc. | Method and system for identifying embedded addressing information in a packet for translation between disparate addressing systems |
US6651096B1 (en) | 1999-04-20 | 2003-11-18 | Cisco Technology, Inc. | Method and apparatus for organizing, storing and evaluating access control lists |
US6606316B1 (en) * | 1999-07-02 | 2003-08-12 | Cisco Technology, Inc. | Gathering network statistics in a distributed network service environment |
US20110258444A1 (en) | 1999-07-30 | 2011-10-20 | Intel Corporation | Network Controller Decryption |
US6728265B1 (en) | 1999-07-30 | 2004-04-27 | Intel Corporation | Controlling frame transmission |
US7120683B2 (en) * | 2000-04-03 | 2006-10-10 | Zarlink Semiconductor V.N. Inc. | Single switch image for a stack of switches |
US20040213237A1 (en) * | 2000-06-29 | 2004-10-28 | Toshikazu Yasue | Network authentication apparatus and network authentication system |
US7739308B2 (en) | 2000-09-08 | 2010-06-15 | Oracle International Corporation | Techniques for automatically provisioning a database over a wide area network |
US20020042875A1 (en) * | 2000-10-11 | 2002-04-11 | Jayant Shukla | Method and apparatus for end-to-end secure data communication |
US7031314B2 (en) * | 2001-05-16 | 2006-04-18 | Bytemobile, Inc. | Systems and methods for providing differentiated services within a network communication system |
US7117504B2 (en) | 2001-07-10 | 2006-10-03 | Microsoft Corporation | Application program interface that enables communication for a network software platform |
US6968389B1 (en) * | 2001-07-17 | 2005-11-22 | Cisco Technology, Inc. | System and method for qualifying requests in a network |
JP3990882B2 (en) * | 2001-07-25 | 2007-10-17 | 株式会社エヌ・ティ・ティ・ドコモ | Mobile packet communication system, mobile packet communication method, and radio control apparatus |
US20120027008A1 (en) * | 2001-10-12 | 2012-02-02 | Spice I2I Limited | Addressing Techniques For Voice Over Internet Protocol Router |
US7006436B1 (en) * | 2001-11-13 | 2006-02-28 | At&T Corp. | Method for providing voice-over-IP service |
KR100411446B1 (en) | 2001-12-24 | 2003-12-18 | 엘지전자 주식회사 | Method of Controlling Type 3 Packet in the AAL2 Signaling |
JP3878014B2 (en) | 2001-12-28 | 2007-02-07 | 富士通株式会社 | Packet switch for interfacing LAN and WAN |
US6985479B2 (en) * | 2002-03-04 | 2006-01-10 | Qualcomm Incorporated | Method and apparatus for processing internet protocol transmissions |
CA2390348A1 (en) | 2002-06-10 | 2003-12-10 | Ibm Canada Limited-Ibm Canada Limitee | Systems, methods and computer programs for implementing and accessing webservices |
US7716725B2 (en) * | 2002-09-20 | 2010-05-11 | Fortinet, Inc. | Firewall interface configuration and processes to enable bi-directional VoIP traversal communications |
US7483980B2 (en) * | 2002-11-07 | 2009-01-27 | Hewlett-Packard Development Company, L.P. | Method and system for managing connections in a computer network |
US7701863B2 (en) * | 2002-12-12 | 2010-04-20 | Alcatel Lucent | Decentralized SLS monitoring for throughput in a differentiated service environment |
US20040125812A1 (en) * | 2002-12-25 | 2004-07-01 | Meng-Hua Kao | Adapter for internetworking wwan and wlan |
US20040170181A1 (en) * | 2003-02-27 | 2004-09-02 | Padcom, Inc. | Prioritized alternate port routing |
US7245622B2 (en) * | 2003-03-27 | 2007-07-17 | Microsoft Corporation | Allowing IPv4 clients to communicate over an IPv6 network when behind a network address translator with reduced server workload |
US6985150B2 (en) | 2003-03-31 | 2006-01-10 | Sun Microsystems, Inc. | Accelerator control unit configured to manage multiple hardware contexts |
US7814310B2 (en) | 2003-04-12 | 2010-10-12 | Cavium Networks | IPsec performance optimization |
US7913294B1 (en) | 2003-06-24 | 2011-03-22 | Nvidia Corporation | Network protocol processing for filtering packets |
US7342916B2 (en) * | 2003-09-10 | 2008-03-11 | Intel Corporation | Method, apparatus and system for optimizing routing of mobile IP packets |
TWI235572B (en) * | 2003-12-19 | 2005-07-01 | Inst Information Industry | Method of IPsec packet routing, NAPT device and storage medium using the same |
US20050193429A1 (en) | 2004-01-23 | 2005-09-01 | The Barrier Group | Integrated data traffic monitoring system |
US8250150B2 (en) * | 2004-01-26 | 2012-08-21 | Forte Internet Software, Inc. | Methods and apparatus for identifying and facilitating a social interaction structure over a data packet network |
US20050201391A1 (en) * | 2004-03-11 | 2005-09-15 | Hung-Fang Ma | Network address translation router and related method |
US7474634B1 (en) * | 2004-03-12 | 2009-01-06 | West Corporation | System, methods, and computer-readable media for expedited access to conference calls |
US8176126B2 (en) * | 2004-08-26 | 2012-05-08 | International Business Machines Corporation | System, method and program to limit rate of transferring messages from suspected spammers |
US20060069782A1 (en) | 2004-09-16 | 2006-03-30 | Michael Manning | Method and apparatus for location-based white lists in a telecommunications network |
US7624263B1 (en) | 2004-09-21 | 2009-11-24 | Advanced Micro Devices, Inc. | Security association table lookup architecture and method of operation |
US7796579B2 (en) | 2004-12-03 | 2010-09-14 | Telefonaktiebolaget Lm Ericsson (Publ) | Technique for interconnecting intermediate network nodes |
JP4655903B2 (en) * | 2004-12-08 | 2011-03-23 | 株式会社日立製作所 | Packet transfer device |
US8787393B2 (en) * | 2005-04-11 | 2014-07-22 | International Business Machines Corporation | Preventing duplicate sources from clients served by a network address port translator |
KR20060117586A (en) * | 2005-05-11 | 2006-11-17 | 삼성전자주식회사 | Apparatus and method of packet processing in ipv4/ipv6 combination network |
US7313134B2 (en) * | 2005-05-12 | 2007-12-25 | Yahoo! Inc. | Proxy server for relaying VOIP messages |
US7505434B1 (en) | 2005-06-23 | 2009-03-17 | Autocell Laboratories, Inc. | VLAN tagging in WLANs |
US20060294588A1 (en) | 2005-06-24 | 2006-12-28 | International Business Machines Corporation | System, method and program for identifying and preventing malicious intrusions |
US7808985B2 (en) * | 2006-11-21 | 2010-10-05 | Gigle Networks Sl | Network repeater |
US7619993B2 (en) * | 2005-11-01 | 2009-11-17 | International Business Machines Corporation | Efficient probabilistic duplicate packet detector in computer networks |
US9021134B1 (en) * | 2006-03-03 | 2015-04-28 | Juniper Networks, Inc. | Media stream transport conversion within an intermediate network device |
US20070214265A1 (en) | 2006-03-07 | 2007-09-13 | Sbc Knowledge Ventures Lp | Scalable captive portal redirect |
US7743094B2 (en) * | 2006-03-07 | 2010-06-22 | Motorola, Inc. | Method and apparatus for redirection of domain name service (DNS) packets |
US8056115B2 (en) * | 2006-12-11 | 2011-11-08 | International Business Machines Corporation | System, method and program product for identifying network-attack profiles and blocking network intrusions |
JP4995590B2 (en) | 2007-02-14 | 2012-08-08 | 株式会社エヌ・ティ・ティ・ドコモ | Content distribution management device, communication terminal, program, and content distribution system |
US7864771B2 (en) | 2007-04-20 | 2011-01-04 | Cisco Technology, Inc. | Parsing out of order data packets at a content gateway of a network |
US8799547B2 (en) | 2007-07-09 | 2014-08-05 | Hewlett-Packard Development Company, L.P. | Data packet processing method for a multi core processor |
US8010522B2 (en) | 2007-12-07 | 2011-08-30 | International Business Machines Corporation | System, method and program product for detecting SQL queries injected into data fields of requests made to applications |
TW201021488A (en) | 2007-12-07 | 2010-06-01 | Interdigital Patent Holdings | Method and apparatus for supporting configuration and control of the RLC and PDCP sub-layers |
DE102008020205B4 (en) | 2008-04-22 | 2010-01-07 | Schenck Rotec Gmbh | Filling bell for filling a tubeless tire |
US8544080B2 (en) * | 2008-06-12 | 2013-09-24 | Telefonaktiebolaget L M Ericsson (Publ) | Mobile virtual private networks |
US8055286B1 (en) * | 2008-08-27 | 2011-11-08 | Sprint Spectrum L.P. | Modification of en-route message to add destination port number selected based at least in part on message originator |
US20100263022A1 (en) | 2008-10-13 | 2010-10-14 | Devicescape Software, Inc. | Systems and Methods for Enhanced Smartclient Support |
EP2340477B1 (en) | 2008-10-13 | 2014-08-06 | Devicescape Software, INC. | Systems and methods for identifying a network |
ATE525835T1 (en) * | 2009-06-29 | 2011-10-15 | Alcatel Lucent | METHOD FOR MANAGING TRAFFIC LOAD |
US20110023088A1 (en) * | 2009-07-23 | 2011-01-27 | Electronics And Telecommunications Research Institute | Flow-based dynamic access control system and method |
US8238244B2 (en) | 2009-08-10 | 2012-08-07 | Micron Technology, Inc. | Packet deconstruction/reconstruction and link-control |
WO2011068186A1 (en) | 2009-12-03 | 2011-06-09 | 日本電気株式会社 | Packet reception apparatus, packet communication system, and packet sequence control method |
US9137139B2 (en) | 2009-12-18 | 2015-09-15 | Cisco Technology, Inc. | Sender-specific counter-based anti-replay for multicast traffic |
US8452835B2 (en) | 2009-12-23 | 2013-05-28 | Citrix Systems, Inc. | Systems and methods for object rate limiting in multi-core system |
KR101670253B1 (en) * | 2010-02-16 | 2016-10-31 | 삼성전자 주식회사 | Method and device for controlling network access of ue in wireless communication system |
US20120281530A1 (en) * | 2010-11-08 | 2012-11-08 | Qualcomm Incorporated | System and method for radio access network overload control |
JP5630306B2 (en) * | 2011-02-10 | 2014-11-26 | 富士通株式会社 | Route generation method, relay device, and route generation program |
US8806573B2 (en) | 2011-08-09 | 2014-08-12 | Cisco Technology, Inc. | Authentication control in low-power lossy networks |
US20140010140A1 (en) | 2011-09-12 | 2014-01-09 | Intel Corporation | Group media access control message for machine-to-machine devices and method to update a group identifier |
US8767730B2 (en) * | 2012-02-10 | 2014-07-01 | Futurewei Technologies, Inc. | Virtual local area network identifier substitution as time to live method |
US9148343B2 (en) | 2012-03-27 | 2015-09-29 | Juniper Networks, Inc. | Methods and apparatus for improving compatibility between network devices |
US9258213B2 (en) * | 2012-05-30 | 2016-02-09 | Cisco Technology, Inc. | Detecting and mitigating forwarding loops in stateful network devices |
-
2013
- 2013-06-14 US US13/918,732 patent/US10263916B2/en active Active
- 2013-06-14 US US13/918,770 patent/US9800503B2/en active Active
- 2013-06-14 US US13/918,748 patent/US20140153577A1/en not_active Abandoned
- 2013-06-14 US US13/918,760 patent/US9467326B2/en active Active
- 2013-06-26 US US13/928,300 patent/US9065701B2/en active Active
- 2013-09-04 US US14/018,129 patent/US9100242B2/en active Active
-
2019
- 2019-04-15 US US16/384,074 patent/US20190245809A1/en not_active Abandoned
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030037042A1 (en) * | 1999-12-08 | 2003-02-20 | Nec Corporation | Table searching technique |
US20050105524A1 (en) * | 2003-11-17 | 2005-05-19 | Hughes Electronics Corporation | System and method for provisioning of route information in a meshed communications network |
US20100037311A1 (en) * | 2006-11-20 | 2010-02-11 | Liwen He | Secure network architecture |
US20110292933A1 (en) * | 2010-05-26 | 2011-12-01 | Alcatel-Lucent Usa, Inc. | Dynamic route cost adjustment of vrrp enabled subnets for routing protocols |
US20120057599A1 (en) * | 2010-09-03 | 2012-03-08 | Futurewei Technologies, Inc. | System and Method for Virtual Private Local Area Network Service to Use the Flow Aware Pseudowire |
US20130286846A1 (en) * | 2012-04-25 | 2013-10-31 | Juniper Networks, Inc. | Path weighted equal-cost multipath |
Cited By (73)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9602404B2 (en) * | 2011-08-17 | 2017-03-21 | Nicira, Inc. | Last-hop processing for reverse direction packets |
US20150117445A1 (en) * | 2011-08-17 | 2015-04-30 | Nicira, Inc. | Packet Conflict Resolution |
US9203703B2 (en) * | 2011-08-17 | 2015-12-01 | Nicira, Inc. | Packet conflict resolution |
US20160080261A1 (en) * | 2011-08-17 | 2016-03-17 | Nicira, Inc. | Last-Hop Processing for Reverse Direction Packets |
US11593148B2 (en) | 2011-11-15 | 2023-02-28 | Nicira, Inc. | Network control system for configuring middleboxes |
US10191763B2 (en) | 2011-11-15 | 2019-01-29 | Nicira, Inc. | Architecture of networks with middleboxes |
US10235199B2 (en) | 2011-11-15 | 2019-03-19 | Nicira, Inc. | Migrating middlebox state for distributed middleboxes |
US10922124B2 (en) | 2011-11-15 | 2021-02-16 | Nicira, Inc. | Network control system for configuring middleboxes |
US9697030B2 (en) | 2011-11-15 | 2017-07-04 | Nicira, Inc. | Connection identifier assignment and source network address translation |
US11740923B2 (en) | 2011-11-15 | 2023-08-29 | Nicira, Inc. | Architecture of networks with middleboxes |
US10884780B2 (en) | 2011-11-15 | 2021-01-05 | Nicira, Inc. | Architecture of networks with middleboxes |
US10977067B2 (en) | 2011-11-15 | 2021-04-13 | Nicira, Inc. | Control plane interface for logical middlebox services |
US10949248B2 (en) | 2011-11-15 | 2021-03-16 | Nicira, Inc. | Load balancing and destination network address translation middleboxes |
US11372671B2 (en) | 2011-11-15 | 2022-06-28 | Nicira, Inc. | Architecture of networks with middleboxes |
US10310886B2 (en) | 2011-11-15 | 2019-06-04 | Nicira, Inc. | Network control system for configuring middleboxes |
US10514941B2 (en) | 2011-11-15 | 2019-12-24 | Nicira, Inc. | Load balancing and destination network address translation middleboxes |
US10089127B2 (en) | 2011-11-15 | 2018-10-02 | Nicira, Inc. | Control plane interface for logical middlebox services |
US10091238B2 (en) | 2014-02-11 | 2018-10-02 | Varmour Networks, Inc. | Deception using distributed threat detection |
US20150281062A1 (en) * | 2014-03-31 | 2015-10-01 | Arista Networks, Inc. | System and method for route health injection using virtual tunnel endpoints |
US9509603B2 (en) * | 2014-03-31 | 2016-11-29 | Arista Networks, Inc. | System and method for route health injection using virtual tunnel endpoints |
US9936438B2 (en) | 2014-05-28 | 2018-04-03 | Cisco Technologies, Inc. | System and method for handling stray session requests in a network environment |
US9420607B1 (en) | 2014-05-28 | 2016-08-16 | Cisco Technology, Inc. | System and method for handling stray session requests in a network environment |
US9923814B2 (en) * | 2015-02-17 | 2018-03-20 | Huawei Technologies Co., Ltd. | Media access control address resolution using internet protocol addresses |
US10193929B2 (en) | 2015-03-13 | 2019-01-29 | Varmour Networks, Inc. | Methods and systems for improving analytics in distributed networks |
US10009381B2 (en) | 2015-03-30 | 2018-06-26 | Varmour Networks, Inc. | System and method for threat-driven security policy controls |
US10333986B2 (en) | 2015-03-30 | 2019-06-25 | Varmour Networks, Inc. | Conditional declarative policies |
US9973472B2 (en) | 2015-04-02 | 2018-05-15 | Varmour Networks, Inc. | Methods and systems for orchestrating physical and virtual switches to enforce security boundaries |
US11870691B2 (en) | 2015-07-07 | 2024-01-09 | Cisco Technology, Inc. | Intelligent wide area network (IWAN) |
US20200177548A1 (en) * | 2015-11-17 | 2020-06-04 | Zscaler, Inc. | Multi-tenant cloud-based firewall systems and methods |
US11582192B2 (en) * | 2015-11-17 | 2023-02-14 | Zscaler, Inc. | Multi-tenant cloud-based firewall systems and methods |
US20170168864A1 (en) * | 2015-12-09 | 2017-06-15 | Varmour Networks, Inc. | Directing Data Traffic Between Intra-Server Virtual Machines |
US10191758B2 (en) * | 2015-12-09 | 2019-01-29 | Varmour Networks, Inc. | Directing data traffic between intra-server virtual machines |
US10454897B1 (en) * | 2016-01-21 | 2019-10-22 | Amazon Technologies, Inc. | Proxy captive portal traffic for input-limited devices |
US10382467B2 (en) | 2016-01-29 | 2019-08-13 | Varmour Networks, Inc. | Recursive multi-layer examination for computer network security remediation |
US9762599B2 (en) | 2016-01-29 | 2017-09-12 | Varmour Networks, Inc. | Multi-node affinity-based examination for computer network security remediation |
US10009317B2 (en) | 2016-03-24 | 2018-06-26 | Varmour Networks, Inc. | Security policy generation using container metadata |
US10601832B1 (en) | 2016-03-30 | 2020-03-24 | Amazon Technologies, Inc. | Proxy captive portal traffic for input-limited devices |
US10264025B2 (en) | 2016-06-24 | 2019-04-16 | Varmour Networks, Inc. | Security policy generation for virtualization, bare-metal server, and cloud computing environments |
US10755334B2 (en) | 2016-06-30 | 2020-08-25 | Varmour Networks, Inc. | Systems and methods for continually scoring and segmenting open opportunities using client data and product predictors |
US10148576B2 (en) * | 2016-07-28 | 2018-12-04 | Fortinet, Inc. | Network processing unit (NPU) integrated layer 2 network device for layer 3 offloading |
US20180034734A1 (en) * | 2016-07-28 | 2018-02-01 | Fortinet, Inc. | Network processing unit (npu) integrated layer 2 network device for layer 3 offloading |
US10868737B2 (en) * | 2016-10-26 | 2020-12-15 | Arizona Board Of Regents On Behalf Of Arizona State University | Security policy analysis framework for distributed software defined networking (SDN) based cloud environments |
US20180115470A1 (en) * | 2016-10-26 | 2018-04-26 | Arizona Board Of Regents On Behalf Of Arizona State University | Security policy analysis framework for distributed software defined networking (sdn) based cloud environments |
US12041505B2 (en) | 2017-01-09 | 2024-07-16 | Lg Electronics Inc. | Method for managing PDU session in wireless communication system and apparatus therefor |
US11523319B2 (en) * | 2017-01-09 | 2022-12-06 | Lg Electronics Inc. | Method for managing PDU session in wireless communication system and device for same |
US10484263B2 (en) * | 2017-01-16 | 2019-11-19 | International Business Machines Corporation | Route-cost acquisition from routers |
US11405775B2 (en) * | 2017-04-28 | 2022-08-02 | Hewlett Packard Enterprise Development Lp | Three-address scheme for forwarding frames in a wireless mesh network |
US11329966B2 (en) | 2018-08-15 | 2022-05-10 | Juniper Networks, Inc. | System and method for transferring packets between kernel modules in different network stacks |
US11233778B2 (en) * | 2018-08-15 | 2022-01-25 | Juniper Networks, Inc. | Secure forwarding of tenant workloads in virtual networks |
US20210357400A1 (en) * | 2018-09-19 | 2021-11-18 | Censhare Gmbh | Efficient in-memory multi-version concurrency control for a trie data structure based database |
US11693866B2 (en) * | 2018-09-19 | 2023-07-04 | Censhare Gmbh | Efficient in-memory multi-version concurrency control for a trie data structure based database |
CN109347623A (en) * | 2018-10-18 | 2019-02-15 | 盛科网络(苏州)有限公司 | Conversate the method and device of holding in a kind of application of balancing link load |
US11902876B2 (en) * | 2018-10-30 | 2024-02-13 | Huawei Technologies Co., Ltd. | Routing management method and apparatus |
US11765081B2 (en) | 2019-02-11 | 2023-09-19 | Google Llc | Offloads for multicast virtual network packet processing in a network interface card |
US10880208B1 (en) * | 2019-02-11 | 2020-12-29 | Google Llc | Offloads for multicast virtual network packet processing in a network interface card |
US11463354B2 (en) | 2019-02-11 | 2022-10-04 | Google Llc | Offloads for multicast virtual network packet processing in a network interface card |
CN113924762A (en) * | 2019-05-30 | 2022-01-11 | 诺基亚通信公司 | Activation of PDU sessions and QoS flows in 3 GPP-based Ethernet bridges |
US11575563B2 (en) | 2019-05-31 | 2023-02-07 | Varmour Networks, Inc. | Cloud security management |
US11711374B2 (en) | 2019-05-31 | 2023-07-25 | Varmour Networks, Inc. | Systems and methods for understanding identity and organizational access to applications within an enterprise environment |
US11290494B2 (en) | 2019-05-31 | 2022-03-29 | Varmour Networks, Inc. | Reliability prediction for cloud security policies |
US11310284B2 (en) | 2019-05-31 | 2022-04-19 | Varmour Networks, Inc. | Validation of cloud security policies |
US11863580B2 (en) | 2019-05-31 | 2024-01-02 | Varmour Networks, Inc. | Modeling application dependencies to identify operational risk |
US11290493B2 (en) | 2019-05-31 | 2022-03-29 | Varmour Networks, Inc. | Template-driven intent-based security |
CN111277518A (en) * | 2020-01-22 | 2020-06-12 | 盛科网络(苏州)有限公司 | Information processing method, Ethernet switching chip and storage medium |
EP4222936A4 (en) * | 2020-09-29 | 2024-01-31 | Palo Alto Networks, Inc. | Enhanced sd-wan path quality measurement and selection |
WO2022072083A1 (en) | 2020-09-29 | 2022-04-07 | Palo Alto Networks, Inc. | Enhanced sd-wan path quality measurement and selection |
CN112351250A (en) * | 2020-10-21 | 2021-02-09 | 杭州海康威视数字技术股份有限公司 | Encoding parameter adjusting method, device and equipment and storage medium |
US11818152B2 (en) | 2020-12-23 | 2023-11-14 | Varmour Networks, Inc. | Modeling topic-based message-oriented middleware within a security system |
US11876817B2 (en) | 2020-12-23 | 2024-01-16 | Varmour Networks, Inc. | Modeling queue-based message-oriented middleware relationships in a security system |
US11777978B2 (en) | 2021-01-29 | 2023-10-03 | Varmour Networks, Inc. | Methods and systems for accurately assessing application access risk |
US12050693B2 (en) | 2021-01-29 | 2024-07-30 | Varmour Networks, Inc. | System and method for attributing user behavior from multiple technical telemetry sources |
CN113422722A (en) * | 2021-06-16 | 2021-09-21 | 锐捷网络股份有限公司 | Route processing method and device |
US11734316B2 (en) | 2021-07-08 | 2023-08-22 | Varmour Networks, Inc. | Relationship-based search in a computing environment |
Also Published As
Publication number | Publication date |
---|---|
US9100242B2 (en) | 2015-08-04 |
US20140156720A1 (en) | 2014-06-05 |
US20140153422A1 (en) | 2014-06-05 |
US10263916B2 (en) | 2019-04-16 |
US20140156765A1 (en) | 2014-06-05 |
US20140157365A1 (en) | 2014-06-05 |
US9800503B2 (en) | 2017-10-24 |
US9467326B2 (en) | 2016-10-11 |
US20190245809A1 (en) | 2019-08-08 |
US9065701B2 (en) | 2015-06-23 |
US20140157376A1 (en) | 2014-06-05 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20140153577A1 (en) | Session-based forwarding | |
EP2853070B1 (en) | Multi-tunnel virtual private network | |
US9118687B2 (en) | Methods and apparatus for a scalable network with efficient link utilization | |
US20150326478A1 (en) | Methods and devices for providing service insertion in a trill network | |
US9712649B2 (en) | CCN fragmentation gateway | |
US8737388B2 (en) | Method, apparatus and system for processing packets | |
US20130182651A1 (en) | Virtual Private Network Client Internet Protocol Conflict Detection | |
US20120254464A1 (en) | Accessing local network resources in a multi-interface system | |
US9060322B2 (en) | Method and system for preventing loops in mesh networks | |
CN103905284B (en) | A kind of flow load sharing method and apparatus based on EVI networks | |
US20220239629A1 (en) | Business service providing method and system, and remote acceleration gateway | |
US11012412B2 (en) | Method and system for network traffic steering towards a service device | |
CN112134776B (en) | Method for generating multicast forwarding table item and access gateway | |
US10700893B1 (en) | Multi-homed edge device VxLAN data traffic forwarding system | |
US9015438B2 (en) | System and method for achieving enhanced performance with multiple networking central processing unit (CPU) cores | |
CN114175583B (en) | System resource management in self-healing networks | |
US20120170581A1 (en) | Policy homomorphic network extension | |
US10986209B2 (en) | Secure and reliable on-demand source routing in an information centric network | |
EP3364624A1 (en) | A method of distributing a sub-flow associated with a session and a network apparatus | |
JP6718739B2 (en) | Communication device and communication method | |
US11218918B2 (en) | Fast roaming and uniform policy for wireless clients with distributed hashing | |
US9231862B2 (en) | Selective service based virtual local area network flooding | |
US11265320B2 (en) | Extended redirect mirror | |
US10148550B1 (en) | Methods and apparatus for a scalable network with efficient link utilization |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: ARUBA NETWORKS, INC., CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:JANAKIRAMAN, RAMSUNDAR;VERMA, RAVINDER;PALKAR, PRASAD;AND OTHERS;SIGNING DATES FROM 20130722 TO 20130730;REEL/FRAME:030916/0643 |
|
AS | Assignment |
Owner name: HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P., TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:ARUBA NETWORKS, INC.;REEL/FRAME:035814/0518 Effective date: 20150529 |
|
AS | Assignment |
Owner name: ARUBA NETWORKS, INC., CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P.;REEL/FRAME:036379/0274 Effective date: 20150807 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |
|
AS | Assignment |
Owner name: HEWLETT PACKARD ENTERPRISE DEVELOPMENT LP, TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:ARUBA NETWORKS, INC.;REEL/FRAME:045921/0055 Effective date: 20171115 |