Source: http://www.google.com/patents/US7474666?dq=U.S.+Patent+No.+4,528,643)
Timestamp: 2016-02-10 21:22:44
Document Index: 204490770

Matched Legal Cases: ['Application No. 04781826', 'Application No. 03815236', 'Application No. 04781826', 'Application No. 200480020541', 'Application No. 200380108620', 'Application No. 2003301218', 'Application No. 200380108620']

Patent US7474666 - Switch port analyzers - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inPatentsMethods and devices are provided for non-disruptive monitoring of network traffic through one or more ports of a Fibre Channel network device. Preferred embodiments of the invention are used in conjunction with the switched port analyzer (“SPAN”) and/or remote SPAN (“RSPAN”) features. SPAN mode...http://www.google.com/patents/US7474666?utm_source=gb-gplus-sharePatent US7474666 - Switch port analyzersAdvanced Patent SearchPublication numberUS7474666 B2Publication typeGrantApplication numberUS 10/655,452Publication dateJan 6, 2009Filing dateSep 3, 2003Priority dateSep 3, 2003Fee statusPaidAlso published asCN1823496A, CN1823496B, EP1668826A1, US8170025, US20050053073, US20090103566, WO2005025134A1Publication number10655452, 655452, US 7474666 B2, US 7474666B2, US-B2-7474666, US7474666 B2, US7474666B2InventorsRaymond J. Kloth, Thomas James Edsall, Kalyan K. Ghosh, Gaurav Rastogi, Dinesh Ganapathy Dutt, Matthew CressaOriginal AssigneeCisco Technology, Inc.Export CitationBiBTeX, EndNote, RefManPatent Citations (38), Non-Patent Citations (29), Referenced by (40), Classifications (16), Legal Events (4) External Links: USPTO, USPTO Assignment, EspacenetSwitch port analyzers
US 7474666 B2Abstract
Methods and devices are provided for non-disruptive monitoring of network traffic through one or more ports of a Fibre Channel network device. Preferred embodiments of the invention are used in conjunction with the switched port analyzer (“SPAN”) and/or remote SPAN (“RSPAN”) features. SPAN mode operation allows traffic through any Fibre Channel interface of a network device to be replicated and delivered to a single port on the same network device. Ingress SPAN allows the monitoring of some or all packets that ingress a specified port or ports. Egress SPAN allows the monitoring of some or all packets that egress a specified port or ports. RSPAN allows the delivery of the replicated traffic to a port on a remote network device. Filtering may be applied, for example, to SPAN packets having selected virtual storage area network numbers.
at least one buffer associated with the ingress port;
at least one egress port; and
receive a first Fibre Channel packet from ingress port;
determining that a header of the first Fibre Channel packet indicates that the first Fibre Channel packet should be transmitted to a first egress port;
store a copy of the first Fibre Channel packet in a buffer associated with the ingress port;
transmit a first replica of the first Fibre Channel packet to the first egress port; and
transmit a second replica of the first Fibre Channel packet to a second egress port, the second egress port is not configured to participate in the buffer-to-buffer credit flow control mechanism of the Fibre Channel protocol, wherein the second egress port is not configured to act as an ingress port.
2. The network device of claim 1, wherein the second egress port is a port of the network device.
3. The network device of claim 1, wherein the second egress port is a port of another network device.
4. The network device of claim 1, wherein the network device is configured to transmit the second replica of the first Fibre Channel packet to the second egress port regardless of the identity of the first egress port.
5. The network device of claim 1, further configured to do the following:
receive a second Fibre Channel packet at the ingress port, a header of the second Fibre Channel packet indicating that the second Fibre Channel packet should be transmitted to a third egress port;
store a copy of the second Fibre Channel packet in a buffer associated with the ingress port;
transmit a first replica of the second Fibre Channel packet to the third egress port; and
transmit a second replica of the second Fibre Channel packet to the second egress port.
6. A method for use in a Fibre Channel network, the method comprising:
receiving a first Fibre Channel packet, a header of the first Fibre Channel packet indicating that the first Fibre Channel packet should be transmitted to a first egress port;
storing a copy of the first Fibre Channel packet;
transmitting a first replica of the first Fibre Channel packet to the first egress port; and
transmitting a second replica of the first Fibre Channel packet to a second egress port, the second egress port is not configured to participate in the buffer-to-buffer credit flow control mechanism of the Fibre Channel protocol, wherein the second egress port is not configured to act as an ingress port.
7. The method of claim 6, wherein the second egress port is a port of the network device.
8. The method of claim 6, wherein the second egress port is a port of another network device.
9. The method of claim 6, wherein the second replica of the first Fibre Channel packet is transmitted to the second egress port regardless of the identity of the first egress port.
receiving a second Fibre Channel packet, a header of the second Fibre Channel packet indicating that the second Fibre Channel packet should be transmitted to a third egress port;
storing a copy of the second Fibre Channel packet;
transmitting a first replica of the second Fibre Channel packet to the third egress port; and
11. A computer readable medium encoded with a computer program, the computer program comprising instructions for controlling a network device to perform the following steps:
receiving a first Fibre Channel packet at an ingress port of the network device, a header of the first Fibre Channel packet indicating that the first Fibre Channel packet should be transmitted to a first egress port of the network device;
storing a copy of the first Fibre Channel packet in a buffer associated with the ingress port;
transmitting a second replica of the first Fibre Channel packet to a second egress port, the second egress port is not configured to participate in the buffer-to-buffer credit flow control mechanism of the Fibre Channel protocol , wherein the second egress port is not configured to act as an ingress port.
12. The computer readable medium of claim 11, wherein the second egress port is a port of the network device.
13. The computer readable medium of claim 11, wherein the second egress port is a port of another network device.
14. A method for use in a Fibre Channel network, the method comprising:
receiving a Fibre Channel packet;
determining, based on a header of the Fibre Channel packet, that the Fibre Channel packet should be transmitted to a first egress port and that the Fibre Channel packet has been assigned a virtual storage area network number;
storing a copy of the Fibre Channel packet;
transmitting a first replica of the Fibre Channel packet to the first egress port; and
determining, based at least in part on the virtual storage area network number, whether to transmit a second replica of the Fibre Channel packet to a second egress port.
15. The method of claim 14, wherein the second egress port is a port of the network device.
16. The method of claim 14, wherein the second egress port is a port of another network device.
17. A computer readable medium encoded with a computer program, the computer program comprising instructions for controlling a network device to perform the following steps:
receive a Fibre Channel packet at an ingress port;
determine, based on a header of the Fibre Channel packet, that the Fibre Channel packet should be transmitted to a first egress port and that the Fibre Channel packet has been assigned a virtual storage area network number;
store a copy of the Fibre Channel packet in a buffer associated with the ingress port;
transmit a first replica of the Fibre Channel packet to the first egress port; and
determine, based at least in part on the virtual storage area network number, whether to transmit a second replica of the Fibre Channel packet to a second egress port.
18. The computer readable medium of claim 17, wherein the second egress port is a port of the network device.
19. The computer readable medium of claim 17, wherein the second egress port is a port of another network device.
receive a Fibre Channel packet at the ingress port;
determine that the Fibre Channel packet should be transmitted to a first egress port;
apply a rule to determine whether to rewrite, drop, decrypt or truncate a second replica of the Fibre Channel packet that is transmitted to a second egress port, wherein the second egress port is not configured to act as an ingress port.
21. The network device of claim 20, wherein the rule involves the ingress port.
22. The network device of claim 20, wherein the rule involves the first egress port.
23. The network device of claim 20, further configured to obtain a virtual storage area network number from the Fibre Channel packet and wherein the rule involves the virtual storage area network number.
24. The network device of claim 20, wherein the modifying of the second replica comprises dropping the second replica.
25. A method for use in a Fibre Channel network, the method comprising:
determining that the Fibre Channel packet should be transmitted to a first egress port;
applying a rule to determine whether to rewrite, drop, decrypt or truncate a second replica of the Fibre Channel packet that is transmitted to a second egress port, wherein the second egress port is not configured to act as an ingress port.
26. The method of claim 25, wherein the rule involves the ingress port.
27. The method of claim 25, wherein the rule involves the first egress port.
28. The method of claim 25, further comprising obtaining a virtual storage area network number from the Fibre Channel packet and wherein the rule involves the virtual storage area network number.
29. A computer readable medium encoded with a computer program, the computer program comprising instructions for controlling a network device to perform the following steps:
30. The computer readable medium of claim 29, wherein the rule involves the ingress port.
31. The computer readable medium of claim 29, wherein the rule involves the first egress port.
32. The computer readable medium of claim 29, further comprising instructions for controlling the network device to obtain a virtual storage area network number from the Fibre Channel packet and wherein the rule involves the virtual storage area network number.
33. A computer readable medium encoded with a computer program, the computer program comprising instructions for controlling a port of a network device for use in a Fibre Channel protocol network to perform the following steps:
ignore the buffer-to-buffer credit flow control mechanism of the Fibre Channel protocol for data traffic received at an egress port; and
allow the data traffic to be sent only in the egress port's egress direction.
34. The computer readable medium of claim 33, further comprising instructions for controlling the port to receive frames from within the network device.
35. The computer readable medium of claim 33, further comprising instructions for controlling the port to output frames with an extended inter-switch link header.
36. The computer readable medium of claim 33, further comprising instructions for controlling the port to output frames without an extended inter-switch link header.
37. A method for controlling a port of a network device for use in a Fibre Channel protocol network, the method comprising:
ignoring the buffer-to-buffer credit flow control mechanism of the Fibre Channel protocol for data traffic received at an egress port; and
allowing the data traffic to be sent only in the egress port's egress direction.
38. The method of claim 37, further comprising controlling the port to receive frames from within the network device.
39. The method of claim 37, further comprising controlling the port to output frames with an extended inter-switch link header.
40. The method of claim 37, further comprising controlling the port to output frames without an extended inter-switch link header.
41. A network device for use in a Fibre Channel network, the network device comprising:
an ingress port configured to receive a Fibre Channel packet, a header of the Fibre Channel packet indicating that the Fibre Channel packet should be transmitted to a first egress port, wherein the ingress port is further configured to:
transmit a second replica of the Fibre Channel packet;
a reflector port configured to:
receive the second replica of the Fibre Channel packet;
encapsulate the second replica of the Fibre Channel packet with routing information such that the Fibre Channel packet can traverse an intervening network to a second network device; and
transmit the encapsulated second replica of the Fibre Channel packet to a second egress port of the second network device, the second egress port is not configured to participate in the buffer-to-buffer credit flow control mechanism of the Fibre Channel protocol, wherein the second egress port is not configured to act as an ingress port.
42. The network device of claim 41, wherein the reflector port does not make a third replica of the Fibre Channel packet.
43. The network device of claim 41, wherein the reflector port makes a determination not to make a third replica of the Fibre Channel packet based on internal header information of the second replica of the Fibre Channel packet.
means for receiving a first Fibre Channel packet, a header of the first Fibre Channel packet indicating that the first Fibre Channel packet should be transmitted to a first egress port;
means for storing a copy of the first Fibre Channel packet;
means for transmitting a first replica of the first Fibre Channel packet to the first egress port; and
means for transmitting a second replica of the first Fibre Channel packet to a second egress port, the second egress port is not configured to participate in the buffer-to-buffer credit flow control mechanism of the Fibre Channel protocol, wherein the second egress port is not configured to act as an ingress port.
means for receiving a Fibre Channel packet;
means for determining, based on a header of the Fibre Channel packet, that the Fibre Channel packet should be transmitted to a first egress port and that the Fibre Channel packet has been assigned a virtual storage area network number;
means for storing a copy of the Fibre Channel packet;
means for transmitting a first replica of the Fibre Channel packet to the first egress port; and
means for determining, based at least in part on the virtual storage area network number, whether to transmit a second replica of the Fibre Channel packet to a second egress port.
46. The apparatus of claim 45, wherein the second egress port is a port of the network device.
47. The apparatus of claim 45, wherein the second egress port is a port of another network device. Description
This application is related to U.S. patent application Ser. Nos. 10/409,527 and 10/346,050, which are hereby incorporated by reference for all purposes.
In order to allow multiple VLANs to share a single inter-switch link on the underlying physical topology, the interswitch link protocol (“ISL”) was developed at Cisco Systems. See for example U.S. Pat. No. 5,742,604, entitled “Interswitch link mechanism for connecting high-performance network switches,” Edsall, et al., issued on Apr. 21, 1998 to Cisco Systems, Inc., which is hereby incorporated by reference for all purposes. ISL provides an encapsulation mechanism for transporting packets between ports of different switches in a network on the basis of VLAN associations among those ports. (The terms “frame” and “packet” are equivalent as used herein.)
FC protocol is increasingly used for storage area networks and similar networks. One such device used as a fabric network device for storage area networks is a Multi-layer Data Switch (“MDS”), manufactured by Cisco Systems, Inc. Data ingress and egress the MDS in FC protocol via FC ports. Accordingly, when a network manager needs to troubleshoot a problem with a network device that is using FC protocol, the device used by the network manager must be able to capture and analyze frames in FC protocol.
However, FC analyzers are normally interposed between two switches in an FC network. Therefore, connecting the FC analyzer causes disruption of the network and user “down time.” Moreover, network disruption can change the setup environment and consequently make a problem more difficult to debug. In addition, the people troubleshooting the FC network may not be at the same location as, for example, a switch believed to be causing a problem. It would be desirable to have more flexible devices and methods for the analysis of FC networks as compared to the prior passive FC Analyzer technology.
Methods and devices are provided for non-disruptive monitoring of network traffic through one or more ports of an FC network device. Preferred embodiments of the invention are used in conjunction with the switched port analyzer (“SPAN”) and/or remote SPAN (“RSPAN”) features. SPAN mode operation allows traffic through any FC interface of a network device to be replicated and delivered to a single port on the same network device. Ingress SPAN allows the monitoring of some or all packets that ingress a specified port or ports. Egress SPAN allows the monitoring of some or all packets that egress a specified port or ports. RSPAN allows the delivery of the replicated traffic to a port on a remote network device. Filtering may be applied, for example, to SPAN packets having selected virtual storage area network (VSAN) numbers.
FIG. 1 illustrates a conventional method of connecting an FC analyzer to an FC network.
FIG. 1 depicts a prior art configuration for analyzing and troubleshooting a network device. Network 100 includes fabric 105, which includes network devices 110, 115 and 120. Network devices 110, 115 and 120 may be any type of network device known in the art that may be used to form a fabric of an FC network. Nodes 125 and 130 represent personal computers or similar devices with which users may interact with fabric 105, for example to access data within storage device 135.
Some network devices may be configured to support a novel frame format, known as extended inter-switch link (“EISL”) format, which is the subject of other pending patent applications assigned to Andiamo Systems. The description of some embodiments and applications of EISL in U.S. patent application Ser. No. 10/034,160 is hereby incorporated by reference for all purposes. In one example, the EISL format allows a single network device to process frames or packets having different formats. For example, if network device 115 were configured to support EISL, network device 115 could process both FC frames and Ethernet frames. The EISL format also supports VLANs, VSANs and similar features.
An EISL format allows the implementation of an FC network with features and functionality beyond that provided by ISL format. In one example, the EISL format allows a port (known herein as a “trunking port”) to transport frames of more than one format. For example, a trunking port can switch Ethernet and FC frames and is adaptable to transmitting frames of other formats as they are developed. An EISL header is used on EISL links to enable this transportation of different frame types.
FIG. 3 depicts an apparatus for analyzing FC frames according to some embodiments of the present invention. In FIG. 3, ports 140 and 145 of network device 120 are configured to receive FC frames from and send FC frames to other network devices in fabric 105. However, in this embodiment, port 150 has been configured to receive copies of selected frames according to some version of switched port analyzer (“SPAN”) mode, a proprietary mode developed by Cisco Systems, Inc.
SPAN (also referred to herein as “local SPAN”) monitors network traffic though an FC interface. Traffic through any FC interface can be replicated to one or more specially-configured ports, called SPAN destination ports (SD ports). The SPAN feature is non-intrusive and does not affect switching of network traffic for any SPAN source ports; it may, however, in some cases slow down the traffic in source ports.
According to preferred embodiments, when a port is configured as an SD port, packets may be output from the SD port (egress), but the SD port cannot act as an ingress port. The SD port may or may not be flow-controlled. However, in preferred embodiments, an SD port does not participate in the “buffer-to-buffer” credit system of the FC protocol. In preferred embodiments, no FC link level control protocol (FC-1) is used with an external device (e.g., FC analyzer 155) that receives frames from an SD port. Instead, data are output from the SD port as if placed on the wire 205 and no handshaking is performed.
SPAN sources refer to the interfaces from which traffic can be monitored. In preferred embodiments, one can also specify a VSAN number (or a range of VSAN numbers) as a SPAN source, in which case all supported interfaces in the specified VSAN(s) are included as SPAN sources. In preferred implementations, one can choose to SPAN traffic in the ingress direction, the egress direction, or both directions for any source interface. Traffic entering the switch fabric through an ingress source interface is “spanned” or replicated to the SD port. Similarly, traffic exiting the switch fabric through an egress source interface is “spanned” or replicated to the SD port.
Remote SPAN (“RSPAN”)
FIG. 8A is a schematic diagram that indicates how to encapsulate packet 701 according to one implementation. Here, packet 701 is encapsulated by fields 810 and 815 to form encapsulated packet 820, suitable for transmission through intervening network 720. Field 815 is a routing field that may form a tunnel through intervening network 720. For example, routing field 815 may indicate an IP GRE, which indicates every “hop” through intervening network 720. Here, field 810 is reserved for a SPAN header. The SPAN header may be of the types described in the FC Over FC Encapsulation section, above. Alternatively, the SPAN header may have another format and/or include other information.
Ver: Version; T: Truncation bit; E: Extended SPAN header present; resv: reserved; ssn: Session id; resv: reserved; original frame length: length of the encapsulated frame.
The Extended header is preferably attached after the SPAN short header. The ‘E’ field in the short header indicates whether the extended header is present. There is only one set of EOF and CRC is sent in the Remote SPAN frame. This helps to minimize the cost of encapsulation.
For example, it is often desirable to filter by VSAN number, or by a range of VSAN numbers. The traffic flowing in different VSANs can be completely unrelated. So, for troubleshooting purposes it is more useful to see traffic on only a particular VSAN or selected few VSANs at a time. As noted above in the discussion of EISL, a “trunking port” or “TE” port can support multiple VSANs. In many networks, different clients are assigned one or more VSAN numbers. Accordingly, if port 140 were configured as a TE port, port 140 could be processing packets having a variety of VSAN numbers corresponding to numerous clients, only some of which (perhaps only one of which) are experiencing problems. There may be multiple ports supporting the same VSAN and one may need to monitor more than one port. An appropriate filter could select a particular VSAN or range of VSANs.
A VSAN filter can preferably be applied to a selected source or to all sources in a session. Only traffic in the selected VSANs is spanned when one configures VSAN filters. Some implementations allow two types of VSAN filters can be specified, known as “interface level filters” and “session filters.” Interface level VSAN filters can be applied for a specified TE port or trunking port channel to filter traffic in the ingress direction, the egress direction, or in both directions. A port channel is a logical interface including multiple FC-links that act as a single link. A trunking port channel can carry traffic on multiple VSANs in a manner similar to that of a trunking (TE) port.
Alternatively, one may wish to filter packets according to their FSPF (Find Shortest Path First) category. FSPF is the routing protocol for FC. The present assignee has developed unique extensions for FSPF, known as “FSPF2.” Filters for either or both of these routing protocols may be advantageously used to isolate traffic to or from destinations of interest. MDS supports filtering of SPAN traffic on any of the FC header fields in the Fibre Channel packet, classification information like access control, forwarding, QOS etc. as well.
Therefore, it may be useful to see traffic that does NOT fit this pattern, e.g., only packets that fail a CRC or packets that are from an unexpected domain (suspected security violators). Under this paradigm, one does not want to see any result that is normal, only the irregularities. Instead of giving thousands of examples of what to SPAN, one could indicate (e.g., with an exclusionary Boolean command) what one doesn't want to see. Alternatively, one could SPAN any command that is not allowed. For example: “SPAN [all commands other than SCSI READS].”
The rules may be in the general format of “IF [condition], then [action].”
Another example of applying rules to effect rewrites is shown in FIG. 5. Here, network device 500 is configured to SPAN packets egressing port 502 to SD port 503. Packet 510 comes to port 501 and line card 511. The forwarding engine 506 forwards packet 510 to port 502, which is resident in line card 522. After packet 520 goes to crossbar 505, packet 520 proceeds to port 502.
Reliable and “Unreliable” SPAN
During operation by “reliable SPAN,” packets come in and consume buffers within network device 600. When buffers allocated to a particular port (e.g., port 601) are full, no other packet will be sent to that port. Packets are released when they have completed transmission through the switch. The packet is replicated once to go to its intended destination and the packet is replicated a second time to go to the SD port. The buffer span is released only when all the required SPAN copies of the FC frame are completed. Then, another packet may come into port 601. Because of this delay, there may be some times when no additional packets may be sent to port 601.
With “unreliable SPAN,” it is recognized that input buffers are being used up by pending SPAN descriptors, corresponding with packets that will be sent to the SPAN port. Anything new that arrives will not be spanned. The packet is sent to its original destination port, but the SPAN descriptor is dropped. By dropping the SPAN packet descriptors that should have gone to the SD port when there is congestion, the system will not be slowed down and higher throughput can be maintained. However, not all packets will be spanned that would otherwise (with reliable SPAN) have been spanned.
Truncation has at least 2 advantages. First, in the above-described situation in which there is a faster connection to the input port than there is to the SD port, truncating the packets can allow all packets to be sent to the SD port. In other words, “unreliable SPAN” need not be invoked to drop packets in order to maintain throughput.
ST Port (“Reflector Port”)
There are other ways of spanning to a remote SD port via an intervening network such as an IP network or a non-Andiamo FC network, one of which will now be described with reference to FIG. 9. Suppose we want to “ingress SPAN” packet 901, which is arriving at port 911 and is intended to egress via port 922. In order to send a replica of packet 901 to remote SD port 933, packet 901 may be encapsulated with routing information so that it can go through network 950. The routing information may, for example, set up an MPLS FC tunnel.
A “tunnel” means that the entire route is configured. For example, switch 910 may be configured to send all traffic to switch 920. Switch 920 may be configured to send all traffic from switch 910 to switch 930. Switch 930 may be configured to output all packets received from switch 920 to SD port 933. In some implementations, EISL may be used to carry information regarding the pre-existing MPLS protocol, in order to set up the tunnel.
Here, the header is set up at ST port 944. The reason for creating the header at ST port 944 is that in some implementations, the SPAN copies are created before the routing encapsulation engine has engaged. In other words, first forwarding decision and SPAN logic on the packet 901 is completed and when the encapsulation needs to be done the opportunity to re-write packet 901 is over. As a result, the encapsulation cannot be put on at port 911. That is why packet 901 goes to a SPAN replicator where the packet again goes through the rewrite mechanism when it is encapsulated. Packet 901 has to look different for the remote SPAN than from the original packet. Therefore, an unmodified replica of packet 901 is sent to ST port 944 directly. At ST port 944, the desired routing information is encoded (the “tunnel” is created).
SPAN destination ports can be over subscribed, because more than one interface can be monitored at the same SD port. In such cases, the SPAN traffic requires more bandwidth than one port (e.g., more than an ASIC of one port) can deliver. In most implementations of “unreliable SPAN,” the SPAN traffic is delivered on a best-efforts basis, resulting in packet drops at the SPAN destination. In case of reliable SPAN, the sources will be slowed down to the bandwidth handled by one FC interface.
The interfaces 1068 are typically provided as interface cards (sometimes referred to as “line cards”). Generally, they control the sending and receiving of data packets over the network and sometimes support other peripherals used with the network device 1060. Among the interfaces that may be provided are Ethernet interfaces, frame relay interfaces, cable interfaces, DSL interfaces, token ring interfaces, and the like. In addition, various very high-speed interfaces may be provided, such as fast Ethernet interfaces, Gigabit Ethernet interfaces, ATM interfaces, HSSI interfaces, POS interfaces, FDDI interfaces, ASI interfaces, DHEI interfaces and the like. Generally, these interfaces may include ports appropriate for communication with the appropriate media. In some cases, they may also include an independent processor and, in some instances, volatile RAM. The independent processors may control such communications intensive tasks as packet switching, media control and management. By providing separate processors for the communications intensive tasks, these interfaces allow the master microprocessor 1062 to efficiently perform routing computations, network diagnostics, security functions, etc.
Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS5515376Jul 19, 1993May 7, 1996Alantec, Inc.Communication apparatus and methodsUS5610905Dec 13, 1994Mar 11, 1997Alantec CorporationCommunication apparatus and methodsUS5742604Mar 28, 1996Apr 21, 1998Cisco Systems, Inc.Interswitch link mechanism for connecting high-performance network switchesUS6499107Dec 29, 1998Dec 24, 2002Cisco Technology, Inc.Method and system for adaptive network security using intelligent packet analysisUS6704883Dec 22, 1999Mar 9, 2004Cisco Systems, Inc.Event-enabled distributed testing systemUS6959007Jun 25, 2001Oct 25, 2005Lsi Logic CorporationHigh speed network protocol stack in siliconUS7007208May 30, 2003Feb 28, 2006Finisar CorporationSystems and methods for data unit modificationUS7020715Aug 21, 2001Mar 28, 2006Adaptec, Inc.Protocol stack for linking storage area networks over an existing LAN, MAN, or WANUS7107328 *Dec 21, 2004Sep 12, 2006Veritas Operating CorporationStorage area network (SAN) device logical relationships managerUS7164657 *Jan 26, 2005Jan 16, 2007Inmon CorporationIntelligent collaboration across network systemsUS7206863 *Mar 26, 2004Apr 17, 2007Emc CorporationSystem and method for managing storage networks and providing virtualization of resources in such a networkUS7292567Oct 31, 2002Nov 6, 2007Qlogic CorporationRouter and methods for distributed virtualizationUS20010055274 *Feb 22, 2001Dec 27, 2001Doug HeggeSystem and method for flow mirroring in a network switchUS20020042866Aug 23, 2001Apr 11, 2002Robert GrantMethod and circuit for replicating data in a fibre channel network, or the likeUS20020046289Aug 21, 2001Apr 18, 2002Srinivasan VenkaramanProtocol stack for linking storage area networks over an existing LAN, MAN,or WAN Protocol stack for linking storage area networks over on existing , man, or wanUS20020116564Dec 20, 2001Aug 22, 2002Inrange Technologies CorporationFibre channel port adapterUS20020136223Dec 19, 2000Sep 26, 2002Ho Ka K.Method and apparatus for interworking PNNI with the signalling and routing protocols used in MPLS networksUS20020143849Dec 28, 2001Oct 3, 2002Newell Darren L.ATM over MPLS connection establishment mechanismUS20020156924Apr 23, 2001Oct 24, 2002Moshe CzeigerMethod for communicating between fibre channel systemsUS20020170004May 8, 2001Nov 14, 2002Shugart Technology, Inc.Storage area network monitor device and networked monitor systemUS20020171649Jul 22, 2002Nov 21, 2002Fogg Chad EdwardComputer system controller having internal memory and external memory controlUS20020191649 *Dec 27, 2001Dec 19, 2002Woodring Sherrie L.Port mirroring in channel directors and switchesUS20030053464Sep 3, 2002Mar 20, 2003Chen Xiaobao XMethod of sending data packets through a multiple protocol label switching MPLS network, and a MPLS networkUS20030091037Apr 30, 2002May 15, 2003Nishan Systems, Inc.Method and apparatus for transferring data between IP network devices and SCSI and fibre channel devices over an IP networkUS20030118053Dec 26, 2001Jun 26, 2003Andiamo Systems, Inc.Methods and apparatus for encapsulating a frame for transmission in a storage area networkUS20030137937 *Jan 21, 2003Jul 24, 2003Nippon Telegraph And Telephone Corp.Capacity variable link apparatus and capacity variable link setting methodUS20030152028May 2, 2001Aug 14, 2003Vilho RaisanenMethod and system for managing quality of service by feeding information into the packet networkUS20030202536Oct 26, 2001Oct 30, 2003Foster Michael S.Integrated analysis of incoming data transmissionsUS20030227876Jun 11, 2002Dec 11, 2003Nokia CorporationMultimode queuing system for DiffServ routersUS20040146063Jan 23, 2003Jul 29, 2004Cisco Technology, Inc.Methods and devices for transmitting data between storage area networksUS20040153854Apr 7, 2003Aug 5, 2004Andiamo Systems, Inc.Port analyzer adapterUS20050114710Oct 28, 2004May 26, 2005Finisar CorporationHost bus adapter for secure network devicesUS20050232269May 26, 2005Oct 20, 2005Maxxan Systems, Inc.System, apparatus and method for address forwarding for a computer networkUS20060274656Jun 28, 2006Dec 7, 2006Paul Harry VMethod and apparatus for rendering a cell-based switch useful for frame based protocolsUS20070208821Apr 2, 2007Sep 6, 2007Pittman Joseph CSystem and method for zero copy block protocol write operationsUS20070258457Jul 26, 2007Nov 8, 2007Kenichi SakamotoVpn composing method, interwork router, packet communication method, data communication apparatus, and packet relaying apparatusWO2001078308A2Apr 10, 2001Oct 18, 2001IbmMethod for defining and controlling the overall behavior of a network processor deviceWO2002082728A1Mar 7, 2002Oct 17, 2002Siemens AgMethod and telecommunications system for monitoring a data flow in a data network* Cited by examinerNon-Patent CitationsReference1EP Examiner's Communication pursuant to Article 96(2) EPC dated Sep. 18, 2006, from corresponding European Application No. 04781826.5, 11 pages.2Examiner's Communication pursuant to Article 96(2) EPC dated Jul. 26, 2007, received Aug. 6, 2007, from European Patent Application No. 03815236.9, Port Adapter Network-Analyzer, (4 pp.).3Examiner's Communication pursuant to Article 96(2) EPC dated Nov. 9, 2007, received Dec. 3, 2007, from European Patent Application No. 04781826.5, Switch Port Analyzers, (5 pp.).4First Office Action dated May 23, 2008 from Chinese Patent Application No. 200480020541.5. 7 pgs.5First Office Actionissued Feb. 9, 2007, for Chinese Patent Application No. 200380108620.7, filed Dec. 18, 2003, Port Adapter Network-Analyzer. in Chinese (7 pp.) and in English translation (7 pp.)6http://en.wikipedia.org/wiki/Generic-Routing-Encapsulation, considered in U.S. Appl. No. 10/346,050 on Feb. 1, 2007.7http://en.wikipedia.org/wiki/IP-protocol, considered in U.S. Appl. No. 10/346,050 on Feb. 1, 2007.8http://en.wikipedia.org/wiki/IPv4#Fragmentation, considered in U.S. Appl. No. 10/346,050 on Feb. 1, 2007.9http://en.wikipedia.org/wiki/MPLS, considered in U.S. Appl. No. 10/346,050 on Feb. 1, 2007.10http://en.wikipedia.org/wiki/Network-layer, considered in U.S. Appl. No. 10/346,050 on Feb. 1, 2007.11International Search Report dated Feb. 7, 2005, from International Application No. PCT/US2004/027217, including Notification of Transmittal.12International Search Report dated Jul. 2, 2005, from International Application No. PCT/US2004/027217.13International Search Report, dated Jun. 17, 2004, from related International Application No. PCT/US 03/20911, including Notification of Transmittal.14M. Rajagopal, et al., Fibre Channel Over TCP/IP (FCIP), IETF, Aug. 2002, pp. 1-68.15Non-Final Office Action dated Sep. 3, 2008 for U.S. Appl. No. 10/346,050.16Office Action dated Jul. 18, 2008 for AU Patent Application No. 2003301218.17PCT Invitation to Pay Additional Fees, with a Partial International Search Report, mailed Dec. 3, 2004, from International Application No. PCT/US2004/027217.18Second Chinese Office Action, issued Aug. 24, 2007, received Sep. 27, 2007, for Chinese Patent Application No. 200380108620.7, filed Dec. 18, 2003, Port Adapter Network-Analyzer, 16 pp. total (in English translation 8 pp. and in Chinese 8 pp.).19U.S. Appl. No. 11/114,257, filed Apr. 25, 2005, Sharma et al.20U.S. Office Action dated Jul. 21, 2008 from U.S. Appl. No. 11/114,257.21U.S. Office Action dated Sep. 15, 2008 from U.S. Appl. No. 10/409,427.22US Office Action mailed Apr. 17, 2008, from U.S. Appl. No. 10/346,050.23US Office Action mailed Apr. 30, 2008, from U.S. Appl. No. 10/409,427.24US Office Action mailed Feb. 8, 2007, from U.S. Appl. No. 10/346,050.25US Office Action mailed Nov. 14, 2007, from U.S. Appl. No. 10/409,427.26US Office Action mailed Nov. 27, 2007, from U.S. Appl. No. 10/346,050.27Walker, David S., et al., U.S. Appl. No. 10/346,050, "Method and Apparatus For Remotely Monitoring Network Traffic Through A Generic Network", filed Jan. 15, 2003.28Written Opinion of the International Searching Authority dated Feb. 7, 2005 from related International Application No. PCT/US2004/027217.29Written Opinion of the International Searching Authority, dated Jul. 2, 2005, from International Application No. PCT/US2004/027217.Referenced byCiting PatentFiling datePublication dateApplicantTitleUS7672318 *Oct 29, 2004Mar 2, 2010Telefonaktiebolaget L M Ericsson (Publ)Adaptable network bridgeUS7733855 *Jun 8, 2004Jun 8, 2010Oracle America, Inc.Community separation enforcementUS7782784Aug 24, 2010Cisco Technology, Inc.Port analyzer adapterUS7792047Sep 7, 2010Gigamon Llc.Asymmetric packet switch and a method of useUS7804832Feb 13, 2006Sep 28, 2010Cisco Technology, Inc.Method and system for simplified network wide traffic and/or flow monitoring in a data networkUS7860096Jun 8, 2004Dec 28, 2010Oracle America, Inc.Switching method and apparatus for use in a communications networkUS7876759 *Jul 11, 2007Jan 25, 2011Hewlett-Packard Development Company, L.P.Quality of service with control flow packet filteringUS7899048Jan 15, 2003Mar 1, 2011Cisco Technology, Inc.Method and apparatus for remotely monitoring network traffic through a generic networkUS7953086 *Mar 6, 2009May 31, 2011Broadcom CorporationCompression of datagram distribution informationUS8165136 *Apr 25, 2005Apr 24, 2012Cisco Technology, Inc.Virtual port based SPANUS8170025May 1, 2012Cisco Technology, Inc.Switch port analyzersUS8358591 *Jun 5, 2008Jan 22, 2013Hewlett-Packard Development Company, L.P.Network traffic monitoring in a server network environmentUS8391286Mar 5, 2013Gigamon LlcPacket switch methodsUS8542681 *Sep 16, 2010Sep 24, 2013Cisco Technology, Inc.Method and system for simplified network wide traffic and/or flow monitoring in a data networkUS8811214Apr 9, 2012Aug 19, 2014Cisco Technology, Inc.Virtual port based spanUS8942100Dec 7, 2012Jan 27, 2015Cisco Technology, Inc.Real time and high resolution buffer occupancy monitoring and recordingUS8964547Jun 8, 2004Feb 24, 2015Oracle America, Inc.Credit announcementUS9001830Dec 7, 2012Apr 7, 2015Cisco Technology, Inc.Ultra low latency multi-protocol network deviceUS9037670 *Dec 7, 2012May 19, 2015Cisco Technology, Inc.Ultra low latency network buffer storageUS9042230Dec 16, 2014May 26, 2015Cisco Technology, Inc.Real time and high resolution buffer occupancy monitoring and recordingUS9054967Dec 7, 2012Jun 9, 2015Cisco Technology, Inc.Timestamping packets in a networkUS9055004Feb 14, 2013Jun 9, 2015Cisco Technology, Inc.Scalable low latency multi-protocol networking deviceUS9065780Feb 14, 2013Jun 23, 2015Cisco Technology, Inc.Low latency networking device using header predictionUS9077619Dec 7, 2012Jul 7, 2015Cisco Technology, Inc.Exporting real time network traffic latency and buffer occupancyUS9077656Feb 12, 2013Jul 7, 2015Gigamon Inc.Packet switch methods and systemsUS9094307Dec 7, 2012Jul 28, 2015Cisco Technology, Inc.Measuring latency within a networking deviceUS9225669Nov 4, 2010Dec 29, 2015Gigamon Inc.Packet switch and method of useUS9231889May 25, 2012Jan 5, 2016Gigamon Inc.Packet switch and method of useUS20040153854 *Apr 7, 2003Aug 5, 2004Andiamo Systems, Inc.Port analyzer adapterUS20050111434 *Oct 29, 2004May 26, 2005Joacim HalenAdaptable network bridgeUS20060002385 *Jun 8, 2004Jan 5, 2006Johnsen Bjorn DSwitching method and apparatus for use in a communications networkUS20070189189 *Feb 13, 2006Aug 16, 2007Cisco Technology, Inc.Method and system for simplified network wide traffic and/or flow monitoring in a data networkUS20080304423 *Jun 5, 2008Dec 11, 2008Mike ChuangNetwork traffic monitoring in a server network environmentUS20090016348 *Jul 11, 2007Jan 15, 2009Hahn Vo NordenQuality of service with control flow packet filteringUS20090135835 *Oct 21, 2008May 28, 2009Gigamon Systems LlcAsymmetric packet switch and a method of useUS20090168777 *Mar 6, 2009Jul 2, 2009Broadcom CorporationCompression of datagram distribution informationUS20110010449 *Jan 13, 2011Cisco Technology, Inc.Method and system for simplified network wide traffic and/or flow monitoring in a data networkUS20110044349 *Nov 4, 2010Feb 24, 2011Gigamon Llc.Packet switch and method of useUS20110216771 *Aug 27, 2010Sep 8, 2011Gigamon Systems Llc.Asymmetric packet switch and a method of useUS20140082118 *Dec 7, 2012Mar 20, 2014Cisco Technology, Inc.Ultra Low Latency Network Buffer Storage* Cited by examinerClassifications U.S. Classification370/401, 370/235, 370/241, 370/392International ClassificationH04L12/56, H04L12/28, H04L12/26Cooperative ClassificationH04L49/555, H04L49/357, H04L43/18, H04L43/00, H04L12/2602, H04L2212/00European ClassificationH04L49/55C, H04L43/00, H04L12/26MLegal EventsDateCodeEventDescriptionSep 3, 2003ASAssignmentOwner name: ANDIAMO SYSTEMS, INC., CALIFORNIAFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:KLOTH, RAYMOND J.;EDSALL, THOMAS JAMES;GHOSH, KALYAN K.;AND OTHERS;REEL/FRAME:014490/0574Effective date: 20030827Jul 6, 2004ASAssignmentOwner name: CISCO SYSTEMS, INC.,CALIFORNIAFree format text: MERGER;ASSIGNOR:ANDIAMO SYSTEMS, INC.;REEL/FRAME:014849/0935Effective date: 20040219Jun 27, 2005ASAssignmentOwner name: CISCO TECHNOLOGY, INC.,CALIFORNIAFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:CISCO SYSTEMS, INC.;REEL/FRAME:016741/0616Effective date: 20040219Jul 6, 2012FPAYFee paymentYear of fee payment: 4RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services