US8824485B2 - Efficient software-based private VLAN solution for distributed virtual switches - Google Patents
Efficient software-based private VLAN solution for distributed virtual switches Download PDFInfo
- Publication number
- US8824485B2 US8824485B2 US13/621,219 US201213621219A US8824485B2 US 8824485 B2 US8824485 B2 US 8824485B2 US 201213621219 A US201213621219 A US 201213621219A US 8824485 B2 US8824485 B2 US 8824485B2
- Authority
- US
- United States
- Prior art keywords
- port
- vlan
- egress
- ingress
- bitmap
- 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.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4641—Virtual LANs, VLANs, e.g. virtual private networks [VPN]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L49/00—Packet switching elements
- H04L49/70—Virtual switches
Definitions
- the present invention relates in general to computer networks and in particular to virtualized local area networks (VLANs). Still more particularly, the present invention relates to private VLANs supported by distributed virtual switches.
- VLANs virtualized local area networks
- VLANs Virtual local area networks
- PVLANs Private VLANs
- VLANs represent an extension of this virtualized network paradigm, in which additional security is provided within the network to prevent monitoring of the traffic being communicated, among other benefits.
- Private VLANs (PVLAN) are a standard feature set supported on most hardware and software based Layer 2 switches.
- the introduction of distributed virtual switches (DVS) to the PVLAN implementation adds a new layer of complexity to the virtualized networking paradigm.
- VLS distributed virtual switch
- PVLANs virtual local area networks
- Packet processing logic of a host system's virtualization manager detects packets on the ingress or the egress path of a DVS to a virtual port having three VLAN bitmap arrays used for processing packets within a virtual local area network (VLAN).
- VLAN virtual local area network
- the logic checks the VLAN identifier (VID) of the packet to determine, based on an offset position within the corresponding bitmap array, whether the VLAN is supported by the port.
- VIP VLAN identifier
- Both the ingress VLAN bitmap array offset position and egress VLAN bitmap array offset position correspond to the value of a VID, and are set within the specific bitmap array during configuration of the VLAN on the port.
- the logic When the VLAN is supported by the port, the logic enables the packet to be processed by the port. Otherwise, the logic discards the packet.
- a strip bitmap array indicates when a packet's VID should be removed prior to forwarding the packet on the egress of the port.
- the method is performed within a host data processing system (host system) having a virtualization manager that configures and enables a virtualized computing environment.
- the virtualized computing environment includes one or more virtual machines and locally-accessible components of a layer 2 distributed virtual switch (DVS) including a plurality of virtual ports supporting packet transmission within at least one virtual local area network (VLAN).
- a processing resource of the virtualization manager executes packet processing logic/code of the virtualization manager which logic/code causes the virtualization manager to perform various functional processes that enable packet forwarding via the virtual port utilizing a VLAN ID retrieved from the packet and the ingress bitmap array for packets on the ingress path and the egress bitmap array for packets on the egress path of the virtual port.
- the packet is discarded.
- a detected packet on the ingress path or the egress path is only allowed to be processed by the port when the VID identifies a VLAN that has a corresponding offset position in the bitmap array set.
- the virtual port is one or more of an access port and an uplink port and each port comprises: an ingress VLAN bitmap containing set offset positions corresponding to VIDs of VLANs that are supported by the port in the ingress path to the port; an egress VLAN bitmap containing set offset positions corresponding to VIDs of VLANs that are supported by the port in the egress path to the port; and a strip VLAN bitmap containing set offset positions corresponding to VIDs identifying VLANS for which the VID is to be removed on the egress path before forwarding the received packet from the port.
- Each virtual port further comprises a port VLAN ID (PVID), which indicates a VLAN tag that is added to untagged packets on the ingress path.
- PVID port VLAN ID
- the method then comprises: in response to the received packet on the ingress path not having a VLAN tag, automatically tagging the packet with the PVID of the virtual port; and in response to the detected packet on the egress path having the PVID tagged thereto, automatically removing the PVID from the packet before forwarding the packet.
- One embodiment of the method further comprises: checking whether a strip array offset position within a strip bitmap array of the virtual port is set, indicating that the VLAN is supported by the port and that the VID should be removed before the packet is forwarded, where the strip array offset position corresponds to the value of the VID and is set within the strip bitmap array during configuration of the VLAN on the port; and responsive to the strip array offset position being set, removing the VID from the packet and forwarding the packet without the VID to a destination device of the VLAN identified by the packet.
- each of the ingress bitmap array, egress bitmap array and strip bitmap array is a single dimension array comprising N bit entries, with each bit corresponding to an offset position from 0 through N ⁇ 1, where N is an integer number representing a maximum number of individual VLANs that can be supported by the virtual port using globally unique identifiers (ID) ranging in value from 0 through N ⁇ 1; an offset position in one of the ingress bitmap array, egress bitmap array and strip bitmap array is set when a value of that bit position in the respective bitmap array has a value of one (1); and the process of checking whether the offset position is set comprises comparing the value at that offset position to one (1) and indicating the offset position is set when the value is equal to one (1).
- ID globally unique identifiers
- embodiments of the method enable the virtualization manager to generate the set of three bitmaps and assign the globally unique port ID when configuring a new virtual port and to modify/update the bitmaps of a virtual port to support multiple VLANS and vice versa.
- the set of three bitmaps is assigned to each virtual port configured and updated to support the addition of additional VLANs to enable efficient handling of packets detected on the ingress and egress paths to the virtual port.
- FIG. 1 is a diagram illustrating a topology of a virtualized computer network, which is configured with one or more virtual switches, according to one embodiment
- FIG. 2 is a layered illustration of the physical and virtualization components that make up an example virtualized computer network with distributed virtual switches, according to one embodiment
- FIG. 3 is a block diagram illustration of components of a physical server that is virtualized to provided multiple virtual machines and virtual server, according to one embodiment
- FIG. 4 is a block diagram illustration of an example distribution across multiple physical hosts of a layer 2 distributed virtual switch (DVS) in a virtual network comprising a private local area network (PVLAN) domain, according to one embodiment;
- DVD layer 2 distributed virtual switch
- FIG. 5A illustrates the different ports that exist within an example PVLAN configured with bitmap arrays, according to one embodiment
- FIG. 5B is a table that illustrates the transferability of packets from one type of port to another within the PVLAN of FIG. 5 , according to one embodiment
- FIG. 6 is a high-level logical flowchart illustrating the method of generating and updating the ingress bitmap, egress bitmap, and strip bitmap arrays for received VLAN identifiers (IDs) being added to a virtual port of a distributed virtual switch (DVS), according to one embodiment;
- IDs VLAN identifiers
- FIG. 7 illustrates example ingress, egress and strip bitmap arrays generated by the method of FIG. 4 and utilized to enable efficient routing within a PVLAN via the DVS, in accordance with one embodiment
- FIGS. 8A and 8B are high-level logical flowcharts respectively illustrating different embodiments of the method of processing a received packet through the DVS utilizing the VLAN ID of the packet and the bitmap arrays, such as the bitmap arrays of FIG. 7 , according to one embodiment;
- FIG. 9 is a process diagram illustrates processing of packets detected/received on an ingress path and on an egress path of a virtual port utilizing the bitmap arrays, according to one embodiment.
- the illustrative embodiments provide a method, data processing system, and a computer program product that enables efficient packet processing at a virtual network port of a distributed virtual switch (DVS) in a virtualized computing environment.
- the method is performed in a virtual platform in which packet processing logic is enhanced to enable more efficient packet processing within a virtual port of a private virtual local area network (PVLAN).
- the packet processing logic enables both virtual and physical client machines to more efficiently communicate with each other across the distributed virtual network utilizing a set of bitmaps and a PVID assigned to each virtual port.
- presented aspects of the method comprises: detecting an incoming transmission of a packet at a first virtual port of the DVS, where the first virtual port is assigned to enable routing of received packets to and from devices within one or more VLANs; retrieving a VLAN ID (VID) from the header of the packet, where the VLAN ID is a value assigned to uniquely identify the particular VLAN from other VLANs of a plurality of VLANs that can be supported by the first virtual port.
- the method then enables packet forwarding via the virtual port utilizing the VLAN ID retrieved from the packet and the ingress bitmap array for packets on the ingress path and the egress bitmap array for packets on the egress path of the virtual port.
- the packet is discarded.
- a detected packet on the ingress path or the egress path is only allowed to be processed by the port when the VID identifies a VLAN that has a corresponding offset position in the bitmap array set.
- the method comprises: checking whether a strip array offset position within a strip bitmap array of the virtual port is set, indicating that the VLAN is supported by the port and that the VID should be removed before the packet is forwarded, where the strip array offset position corresponds to the value of the VID and is set within the strip bitmap array during configuration of the VLAN on the port; and responsive to the strip array offset position being set, removing the VID from the packet and forwarding the packet without the VID to a destination device of the VLAN identified by the packet.
- One or more embodiments of the method enable the virtualization manager to generate the set of three bitmaps and assign the globally unique port ID when configuring a new virtual port and to modify/update the bitmaps of a virtual port to support multiple VLANS and vice versa.
- the set of three bitmaps is assigned to each virtual port configured and updated to support the addition of additional VLANs to enable efficient handling of packets detected on the ingress and egress paths to the virtual port.
- ingress refers to the packets coming into the switch (which is the DVS in the presented embodiments) on that port
- egress refers to the packets going out of the switch using that port.
- Ingress and egress are utilized to reference the ingress path of a port and the egress path of the port, respectively.
- implementation of the functional features of the invention is provided within processing devices/structures and involves use of a combination of hardware, firmware, as well as several software-level constructs (e.g., program code).
- the presented figures illustrate both hardware components and software components within a specific example of data processing architecture. The illustrative and described embodiments assume that the system architecture may be scaled to a much larger data processing system and/or network.
- Virtualization network structure 100 comprises an underlying physical network 105 .
- the physical network 105 can include a plurality of machines/devices (as generally illustrated within the physical network 105 ), including one or more physical servers, routers, adapters, databases, as well as physical switches that are interconnected to each other and communicate with each other via one or more types/forms of connecting fabric (indicated by the dashed lines).
- Virtualization network structure 100 also comprises network virtualization layer 120 which is generated by one or more network hypervisors 110 to support a plurality of virtual local area networks (VLANs) 130 .
- the virtual machines/devices are hosted on a virtualization platform (such as a server) having physical hardware resources (see FIGS. 2 and 3 ) that are provisioned via one or more implementations of a virtualization manager (see FIG. 3 ), such as Power Hypervisor (PHYP) of International Business Machines (IBM) Corporation.
- a virtualization platform such as a server
- PHYP Power Hypervisor
- IBM International Business Machines
- Physical network 105 consists of the physical forwarding elements.
- the forwarding elements can be traditional hardware switches (e.g., switches 107 ) with standard forwarding silicon, as well as virtual switches such as those included with hypervisors.
- the switches provide support for a protocol to allow their flow tables to be adjusted to support implementation of distributed virtual switches.
- Physical switches 107 can include any commercially available or proprietary switch that can include OpenFlow or other standard or proprietary protocol.
- the forwarding elements in physical network 105 are used by network hypervisor 110 to implement distributed virtual switches (DVS), such as DVS 145 a , 145 b .
- DVS distributed virtual switches
- a DVS provides a logical view of a switch, which is decoupled from the underlying hardware and can extend across multiple physical switches or multiple hypervisors.
- Virtual switches 145 a , 145 b communicate with virtual machines and can also have physical connectivity to physical NICs, while physical switches 107 communicate with physical hosts.
- DVS 145 is maintained by network hypervisor 110 and can extend across subnets. Each DVS 145 can include multiple physical hosts or physical network ports, and multiple DVSes can share the same physical hardware.
- the network hypervisor 110 provides the provisioning functionality that creates and maintains the network virtualization layer 120 and the hypervisor 120 also creates and maintains the logical forwarding elements and maps these elements to the underlying hardware.
- network hypervisor 110 can be implemented by a controller (e.g., management console 115 ) using a network operating system.
- Control of the network virtualization layer is provided by network control manager 150 , generally illustrated as associated with management console 115 .
- Network control manager 150 is a software utility that executes on management console 115 , which can be a physical or virtual device that connects to network hypervisor 110 , and network control manager 150 is utilized to set up the various virtual devices and provisioning of resources to these virtual devices.
- Network virtualization layer 120 enables virtual ports within a DVS 145 to be abstracted to and to utilize the physical network switches (within the physical network 105 ) to communicate packets between devices of a VLAN (e.g., PVLAN 140 ).
- network hypervisor 110 maintains mappings that enable routing of communication between the devices of the single VLAN and enables routing of packets from and to the VLAN to external devices.
- example private VLAN (PVLAN) 140 and VLAN 142 are illustrated. It is appreciated that these two VLANs represent only two of a potentially large number of VLANs, which can comprise multiple PVLANs 140 and multiple VLANs 142 . Both PVLAN 140 and VLAN 142 can be supported via respective distributed virtual switches (DVS) 145 that can span across multiple host devices and which each provide a plurality of virtual ports assigned to the various virtual machines that are interconnected within the PVLAN 140 or VLAN 142 .
- DVS distributed virtual switches
- DVS distributed virtual switches
- Each DVS 145 in turn provides a plurality of virtual ports utilized to support packet transmission to/from/within one or a plurality of VLANs 130 , including one or more private VLANs (PVLAN) 140 and/or one or more VLANs 142 .
- PVLAN private VLANs
- FIG. 2 illustrates an expanded view depicting some components of the physical hardware layer and of the network virtualization layer of FIG. 1 .
- computing resources, layers, and functions shown in FIG. 2 are intended to be illustrative only and embodiments of the claimed inventions are not limited thereto.
- physical layer 200 includes various physical hardware and software components that can be used to instantiate virtual entities for use within the virtualization network structure.
- the hardware components may include mainframes (e.g., IBM® zSeries® systems), reduced instruction set computer (RISC) architecture servers (e.g., IBM pSeries® systems), IBM xSeries® systems, IBM BladeCenter® systems, storage devices (e.g., flash drives, magnetic drives, optical drives, tape drives, etc.), physical networks, and networking components (e.g., routers, switches, etc.).
- the software components may include operating system software (e.g., AIX, Windows, Linux, etc.), network application server software (e.g., IBM WebSphere® application server software, which includes web server software), and database software (e.g., IBM DB2®, database software).
- operating system software e.g., AIX, Windows, Linux, etc.
- network application server software e.g., IBM WebSphere® application server software, which includes web server software
- database software e.g., IBM DB2®, database software
- IBM, zSeries, pSeries, xSeries, BladeCenter, WebSphere, and DB2 are trademarks of International Business Machines Corporation, registered in many jurisdictions worldwide.
- Windows is a trademark of Microsoft Corporation, and Linux is a trademark of Linux Torvalds.
- the computing resources residing in physical layer 205 are virtualized and managed by one or more virtual machine monitors (VMMs) or hypervisors (e.g., network hypervisor 110 ).
- virtualization layer 220 includes multiple virtual entities (e.g., virtual servers, virtual storage, virtual networks (including virtual private networks)), virtual applications, and virtual clients. These virtual entities, which are abstractions of the underlying resources in physical layer 200 , may be accessed by client devices 147 connected within the virtualized network environment.
- the client devices 147 can be real devices or virtual devices (e.g., virtual machines, VM).
- FIG. 3 illustrates an example computer server platform that has been virtualized to generate a plurality of virtual client devices, one or more of which is a client device within a VLAN or PVLAN that is supported by a DVS having multiple virtual ports.
- Server 300 is interchangeably referred to herein as a host or host device or host data processing system.
- host device 300 comprises hardware components and software/firmware/OS components that are logically partition to create a plurality of virtual machines (VMs) or operating system (OS) partitions, which can be configured as client logical partitions (LPARs) and/or virtual I/O servers (VIOSes).
- VMs virtual machines
- OS operating system
- VIPs virtual I/O servers
- Physical layer 310 comprises one or more processors 302 , one or more memories 304 , and local (data) storage 312 .
- the one or more processors 302 are interconnected with one or a plurality of memories 304 and with local storage 312 via a bus, interconnect/switch or an interconnect fabric, generally referenced as interconnect fabric 305 .
- interconnect fabric 305 The specific internal connectivity of components, which may be distributed across a large scale interconnect fabric, is not germane to the described embodiments, and no further detail is presented regarding the particular type of interconnectivity between the system hardware components.
- physical layer 310 Also included within physical layer 310 are one or more physical network interfaces (NI) 308 (also conventionally referred to as network adapters) which supports/enables the physical connection of host system 300 (and the VMs 220 a / 220 b and VIOS 230 ) to an external network (e.g., network 105 , FIG. 1 ). Additionally, physical layer 310 comprise a plurality of I/O adapters and I/O devices 306 , which provides the I/O interface for host system 300 . I/O adapters 306 are physical adapters that enable host system 300 to support I/O operations via an I/O interface with both locally connected and remotely (networked) connected I/O devices.
- NI physical network interfaces
- I/O adapters examples include Peripheral Component Interface (PCI), PCI-X, or PCI Express Adapter, and Small Computer System Interconnect (SCSI) adapters, among others.
- PCI Peripheral Component Interface
- PCI-X Peripheral Component Interface
- PCI Express Adapter PCI Express Adapter
- SCSI Small Computer System Interconnect
- Host system 300 is logically partitioned such that different I/O adapters 306 are virtualized and the virtual I/O adapters may then be uniquely assigned to different logical partitions (VMs and/or VIOSes).
- VMs and/or VIOSes logical partitions
- a virtualization manager 320 Logically located above the physical layer ( 310 ) is a virtualization manager 320 , which can be a Power Hypervisor (PHYP), a trademark of IBM Corporation), in one embodiment. While introduced as a PHYP, it is fully appreciated that other types of virtualization management components may be utilized and are equally applicable to the implementation of the various described embodiments.
- the virtualization manager 320 can have an associated service processor (not illustrated) within the physical layer 310 or located elsewhere relative to the virtualization manager 320 .
- the service processor can be used to provide various services for one or more logical partitions.
- hardware management controller (HMC) 315 which exists outside of the physical layer 310 , communicates with host system 300 via virtualization manager 320 . Operations of the different logical partitions can be controlled through HMC 315 , which can be a separate data processing system from which a system administrator can perform various functions, such as reallocation of resources to different logical partitions.
- Host system 300 further comprises a plurality of user-level logical partitions (LPARs), of which two virtual machines (VM1 220 a and VM2 220 b ) and one virtual I/O server (VIOS) 230 are shown.
- host system 300 supports multiple clients and other functional operating system (OS) partitions that are “created” within a virtualized environment.
- OS operating system
- Each LPAR receives an allocation of specific virtualized hardware and OS resources, including virtualized CPU resources, virtualized memory resources, virtual OS, and access to assigned local storage.
- Each LPAR includes a respective host operating system that controls low-level access to physical layer 310 and/or to virtualized I/O functions and/or services provided through VIOS 230 .
- the operating system(s) may be implemented using OS/400, which is designed to interface with a partition management firmware, such as PHYP, and is available from International Business Machines Corporation. It is appreciated that other types of operating systems (such as Advanced Interactive Executive (AIX) operating system, a trademark of IBM Corporation, Microsoft Windows®, a trademark of Microsoft Corp, or GNU®/Linux®, registered trademarks of the Free Software Foundation and Linux Torvalds) for example, may be utilized, depending on a particular implementation, and OS/400 is used only as an example.
- AIX Advanced Interactive Executive
- OS/400 is used only as an example.
- each logical partition is provided one or more virtual network interfaces, numbered as NI1 . . . NI4 for illustrative purposed only. These NIs allows the LPAR to communicate with other LPARs both on the host system and with other devices across a distributed network.
- at least one of the VMs 220 a / 220 b is a part of a PVLAN and is connected to a DVS that enables connectivity across the PVLAN.
- DVS 330 which can be a local portion of a larger DVS spanning multiple host systems, is provided within virtualization manager 320 .
- DVS 330 comprises a plurality of virtual ports, each assigned to one or more VMs within the PVLAN to enable transmission of packets to and from the associated device within the PVLAN.
- virtual manager 320 comprises a port controller 325 which is associated with one or more DVSes supported by the host system 300 .
- Port controller 325 comprises policy software component 342 , which defines port routing policies and connectivity policies, among others.
- Port controller also comprises port registration and bitmap setup (PRBS) utility 343 and Port packet handling (PPH) utility 344 .
- PRBS port registration and bitmap setup
- PPH Port packet handling
- port controller 325 comprises a plurality of individual PVIDs 345 associated with each port and corresponding sets of three VLAN arrays 340 , each set corresponding to one PVID and the associated port.
- the method by which the bitmap arrays 340 are generated and then utilized to provide more efficient packet processing through the virtual ports of a DVS will be described in greater details with reference to FIGS. 6-9 .
- data processing environment 400 includes an Internet protocol (IP) network 402 including a plurality of network segments 404 a , 404 b , each of which is coupled to a respective one of physical routers 406 a , 406 b .
- IP Internet protocol
- each of physical routers 406 a , 406 b includes a respective forwarding table 407 a , 407 b by which physical routers 406 a , 406 b route incoming data packets toward the packets' destinations based upon OSI Layer 3 (e.g., Internet Protocol (IP)) addresses contained in the packets.
- OSI Layer 3 e.g., Internet Protocol (IP)
- Physical host systems 410 a , 410 b are coupled to network segment 404 a
- physical host system 410 c is coupled to network segment 404 b .
- Physical hosts, such as physical host systems 410 a , 410 b optionally may be additionally coupled by a secondary host connection 408 , such as direct cabling or a private non-routed network.
- Each of physical host systems 410 a - 410 c can be implemented, for example, utilizing a host system 300 as depicted in FIG. 3 .
- Each of physical host systems 410 a - 410 c executes a respective one of virtualization manager 412 a - 412 c , which virtualizes and manages the resources of its respective physical host 410 , for example, under the direction of a human and/or automated administrator at a management console 415 coupled to physical host systems 410 a - 410 c by IP network 402 .
- Virtualization manager 412 a on physical host system 410 a supports the execution of VMs 414 a - 414 c
- virtualization manager 412 b on physical host system 410 b supports the execution of VMs 414 d - 414 f
- virtualization manager 412 c on physical host system 410 c supports the execution of VMs 414 g - 414 i .
- VMs 414 a - 414 i can include VMs of one or more cloud consumers and/or a cloud provider.
- each of VMs 414 has at least one (and in some cases multiple) virtual network interfaces NI1-NI11, which provide network connectivity at least at Layers 2 and 3 of the OSI model.
- each of virtualization managers 412 a - 412 c provides one or more (and in the depicted embodiment, at least two) virtual networks to which the manager's VMs 414 can attach.
- virtual networks are represented in FIG. 4 in dashed line illustration.
- virtualization managers 412 a - 412 c all provide a first distributed virtual network 420 a through the implementation of individual virtual switches 430 a 1 , 430 b 1 and 430 c 1 providing Layer 2 connectivity.
- Virtualization managers 412 a - 412 b similarly provide a second virtual network 420 b through the implementation of DVSs 430 a 2 and 430 b 2 .
- virtualization managers 412 c provides a third virtual network 420 c through the implementation of distributed switch 430 c 2 .
- each of virtual networks 420 a - 420 c can be, for example, a private network (e.g., a PVLAN) of a particular cloud consumer, a collaborative private network shared by multiple cloud consumers and/or a cloud provider, or a public network.
- network interfaces NI2, NI4, NI6, NI8, and NI10 are connected to first virtual network 420 a
- network interfaces NI1, NI3, NI5, and NI7 are connected to second virtual network 420 b
- network interfaces NI9 and NI11 are connected to third virtual network 420 c .
- Each virtualization manager 412 preferably records information regarding the virtual network(s) 420 the particular virtualization manager supports and the connection of the corresponding VMs 414 to the virtual network(s) 420 . This information is recorded as a respective one of network information 422 a , 422 b and 422 c .
- a first virtualization manager 412 a can create an entry in its network information 422 a for one of its VMs 414 a , 414 b , or 414 c when the particular VM 414 is provisioned, deployed or migrated in, and the first virtualization manager 412 a can remove the entry from the network information 422 a when the VM 414 is migrated out or destroyed.
- virtualization manager 412 a - 412 c can each implement a respective one of distributed routers 432 a - 432 c to provide OSI Layer 3 routing. In alternate embodiments, however, it is possible to not implement any routing functionality within a physical host.
- each distributed router 432 provides a respective network interface for each virtual network 420 instantiated by the router's virtualization manager 412 , as well as a network interface to the physical network segment 404 to which the physical host 410 is attached (e.g., through a software port of a physical network interface 304 ).
- Each distributed router 432 additionally includes a respective forwarding table 434 a , 434 b and 434 c for storing routing information.
- FIGS. 1-4 may vary.
- the illustrative components of the various figures are not intended to be exhaustive, but rather are representative to highlight some of the components that are utilized to implement certain of the described embodiments.
- different configurations of a data processing systems and/or host system can be provided, containing other devices/components, which can be used in addition to or in place of the hardware depicted, and may be differently configured.
- the illustrated examples are not meant to imply architectural or other limitations with respect to the presently described embodiments and/or the logical extensions thereof.
- PVLAN domain 500 comprises primary VLAN 505 , which in turn provides two community VLANs, named Community 1 VLAN 520 a and Community 2 VLAN 520 b , as well as Isolated VLAN 525 . These VLANs are interrelated and defined within a layer 2 (L2) switch.
- the community VLANs 520 a , 520 b and isolated VLAN 525 are collectively referred to herein as secondary VLANs (indicated by the dashed surrounding lines).
- Each VLAN has an associated VLAN ID, which uniquely identifies that VLAN within the DVS.
- Within PVLAN are three related ports, defined, respectively, as promiscuous ports, isolated ports and community ports.
- the promiscuous ports are connected to layer 3 (L3) or layer 4 (L4) devices (e.g., routers) that may in turn connect to the Internet or administrative work station or common network servers, e.g. a Dynamic Host Configuration Protocol (DHCP) server.
- L3 layer 3
- L4 layer 4
- DHCP Dynamic Host Configuration Protocol
- the isolated port and community ports connect to individual virtual and physical user devices or servers, such as VMs in FIGS. 3 and 4 , and the isolated ports and community ports carry traffic originating from or received for one of the devices within the PVLAN.
- the primary VLAN 505 connects the promiscuous ports 510 with community ports 522 a - d or isolated ports 526 a , 526 b . Specifically, primary VLAN 505 receives packets from L3/L4 devices at the promiscuous ports 510 and transfers the packets to one or more of the secondary VLANs.
- an isolated VLAN is defined as a VLAN that functionally connects isolated ports to promiscuous ports. In an isolated VLAN the traffic is only one way, i.e., packets are received at an isolated port and travel only from that isolated port to a promiscuous port. Packets are not available to other isolated or community ports.
- a community VLAN is defined as a VLAN that functionally connects community ports to promiscuous ports.
- traffic is only routed one way, i.e., packets are received at a community port and travel only from that community port to the promiscuous ports and to the other community ports on that community VLAN.
- packets do not travel from a community port to isolated ports, or to community ports on a different community VLAN that may exist on the same switch.
- an administrator can manually designate ports within the VLAN.
- the administrator defines a primary VLAN and one or more secondary VLANs.
- the DVS must support all of the three types of ports supported within a PVLAN, enforce the communication restrictions enforced by PVLANs (which can be defined by example policy software 342 , FIG. 4 ), and support multiple PVLAN domains.
- PVLAN 500 While existing within the layer 2 domain of communication, PVLAN 500 has multiple sub-domains. As defined herein, each PVLAN sub-domain consists of two VLAN IDs (VIDs), specifically a Primary VLAN ID and a secondary VLAN ID.
- the Primary VLAN represents the PVLAN communication domain, while the secondary VLANs are communication sub-domains with a PVLAN domain.
- a secondary VLAN ID is a globally unique ID amongst all PVLANs supported in a network.
- Each network port falls in one (and only one) of the 3 types of sub-domains within a single PVLAN, defined as follows:
- Each port enables communication to and from one or more end devices, of which end device 524 a - 524 d are illustrated, as two end devices (S1, S2) per community VLAN 520 a , 520 b .
- Isolated VLANs 525 also each include end devices 528 a , 528 b , with one end device (S4, S5, respectively) illustrated per isolated VLAN 525 .
- the table 500 of FIG. 5B summarizes the port actions within the Private VLAN illustrated by FIG. 5A .
- Supporting a PVLAN solution on a DVS depends on the software entities on each host enforcing the communication restrictions required by the PVLAN.
- the DVS solution typically consists of software entities in multiple hosts/machines.
- the software entity forwards packets amongst the DVS access ports (e.g., ports that connect to a Virtual Machine) within the host system and communicates with the outside network by forwarding (to and from the host) using network cards (uplink ports) on the host system.
- the software entity on a particular virtual machine is only aware of the ports supported on that virtual machine, which may only be a (small) subset of all the ports supported by the entire DVS solution. While it is possible that the software entity be made aware of ports on other hosts (within the same DVS), this configuration would add an unnecessary layer of complexity and size to the forwarding table in the software entity (i.e., the local DVS).
- Traffic Switched at layer 2 is based on frames of data with MAC headers.
- Layer 2 switches can contain hundreds of ports on a single switch.
- Private VLANs provide layer2 isolation between the ports within the same broadcast domain. Private VLANs partition a regular VLAN domain into sub domains, represented by a pair of VLANs, a primary VLAN and a secondary VLAN. Every port in a private VLAN is a member of the primary VLAN.
- the primary VLAN carries unidirectional traffic downstream from the promiscuous ports to the isolated and community ports and to other promiscuous ports.
- An isolated VLAN carries unidirectional traffic upstream from the isolated ports toward the promiscuous ports.
- Community VLANs carry upstream traffic from the community ports to the promiscuous port and to other host ports in the same community.
- a community port can also receive upstream traffic. Additionally, an port that receives upstream traffic can support more than one VLAN.
- an isolated port is a host port that belongs to an isolated secondary VLAN. The isolated port has the complete layer2 separation from other ports with in the same private VLAN except for the promiscuous ports. Private VLANs block all the traffic getting to the isolated ports except the traffic from the promiscuous ports, and traffic received from an isolated port is forwarded only to promiscuous ports.
- a community port is a host port that belongs to a community secondary VLAN. Community ports can communicate with other ports in the same community VLAN and with promiscuous ports. These interfaces are isolated at layer 2 from all other interfaces in other communities and from isolated ports within their private VLAN.
- a listing of these restrictions can include one or more of the following: (1) There can be only one isolated VLAN in a private VLAN; (2) An isolated port cannot be an uplink port; (3) Secondary VLAN ports cannot overlap other VLANs in the same Private VLAN domain; (4); (4) Default VLAN in the network cannot be a private-VLAN; (5) A primary VLAN that is mapped to a secondary VLAN need to be both created and enabled; (6) If a port is not tagged it cannot support more than one VLAN; (7) A port can either be a promiscuous port or a community port or an isolated port within a Private VLAN domain; (8) Up to 4095 PVLANs can be supported with identifier numbers 0 and 4095 being reserved; and (9) A private VLAN needs to be created and enabled in order for a port to support the PVLAN.
- aspects of the embodiments described herein provides an efficient algorithm for network packet processing in the DVS software.
- these embodiments provide an efficient, O(1), packet processing (data-path) PVLAN solution in a DVS.
- the described embodiments are built upon the fact that the VLAN ID of any sub-domain (whether promiscuous, isolated or communities) within a PVLAN is globally unique.
- one aspect of the embodiments involves the software entities (on a host system) implementing a specific PVLAN policy enforcement by tagging packets with the right VLAN ID in the outbound/ingress path from a port and validating the VLAN ID on packets on the inbound/egress and/or egress path to a port.
- This method ensures that multiple DVSs can support the same set of PVLAN and enforce the PVLAN policies uniformly.
- the efficiency of the described solution is based on how the ports validate the VLAN tags on the packets. While there may be multiple PVLANs domain within a DVS and each access port may belong to multiple PVLAN itself, the method presented by the described embodiment avoids walking any PVLAN lists during packet processing.
- each port (both access port and uplink port) in the DVS supports three VLAN bitmaps (also interchangeably referred to herein as bitmap arrays).
- the three bitmaps (or bitmap arrays) of each port are: ingress VLAN bitmap 742 , egress VLAN bitmap 744 , and strip VLAN bitmap 746 .
- Ingress VLAN Bitmap 742 contains VLANs that a port supports in the ingress path.
- Egress VLAN Bitmap contains VLANs that the port supports in the egress path.
- strip VLAN Bitmap contains VLANs that the software module must remove/strip on the egress path before sending the frame/packet to the port.
- the bitmap arrays are maintained within port bitmaps 340 , which in one embodiment maintains a plurality of port bitmaps 740 a . . . 740 m , for the M ports supported within the DVS, where M is an integer.
- each bitmap array has N entries corresponding to the maximum number of VLANs supported on the particular DVS.
- ingress VLAN bitmap 742 of Port 1 represents the N bits in sequential order ranging from 0 through N ⁇ 1.
- Egress VLAN bitmap 744 then illustrates that there is a corresponding VLAN present and allocated to locations 1, 3, 4 and N ⁇ 2 of egress VLAN bitmap 744 .
- strip VLAN bitmap 746 indicates that the packets being routed to VLANs 4 and the last VLAN (N ⁇ 1) should be stripped of the VLAN ID before routing a packet from that PVLAN to/from the virtual port.
- each port has a PVID VLAN ID 750 .
- the PVID 750 indicates the VLAN tag that must be added to un-tagged packets on the ingress path and also indicates which tags are to be removed on the egress path.
- the PVLANs (and VLANs) are set appropriately on each bitmap of a port when the port is initially added to a PVLAN (or a non-private VLAN) or vice-versa, which is an infrequent operation and thus not in the path of packet processing.
- FIG. 6 there is illustrated a method by which an administrator, using a management console and executing software thereon, completes the process of adding a port to a DVS. Once the port information is provided to the software, the controlling software subsequently generates the appropriate three bitmap arrays for that port. It is appreciated that some of these steps can be automated and performed by processing components of management console 315 and that most of the steps can also be performed manually by the network administrator working at the management console 115 . As described herein, the method is completed via/with port registration and bitmap setup (PRBS) utility 343 , which executes on one more processors (or virtual processors) of either management console 315 ( FIG. 3 ) or a processor of the virtualization manager on the host system itself.
- PRBS port registration and bitmap setup
- the various processes are thus described as being performed by the PRBS utility 343 , which may in turn be configured and/or instantiated by the network administrator. Execution of the utility can provide processing logic that performs the various described functions.
- the administrator can interact with the PRBS utility 343 via a command line interface (CLI) on the management console 315 , in one embodiment.
- CLI command line interface
- the method of FIG. 6 begins at block 602 at which the VLAN ID (VID) is added to a virtual machine port on a DVS.
- a determination is made at block 604 whether the VID is for a private VLAN. When the VLAN ID is for a private VLAN, the private VLAN is processed and treated as a secondary VLAN of the existing private VLAN (block 606 ).
- a next determination is made at block 608 whether the VID is the primary VLAN ID in the private VLAN. In response to the VID being the primary VLAN ID in the private VLAN, all VLAN IDs in the private VLAN are added to the port's ingress bitmap and all of the VLAN IDs in the private VLAN are also added to the port egress bitmap (block 610 ).
- the PRBS utility 343 ( FIG. 3 ) and/or the administrator determines whether the VID is the PVID of the port.
- the utility/administrator adds all VLAN IDs in the private VLAN to the port strip bitmap array/array (block 614 ). This path of registering the VID then completes (block 640 ).
- VID is not the primary VLAN ID in the PVLAN
- a check is made at block 616 whether the VID is a community VLAN ID in the PVLAN.
- the utility/administrator adds the VID to the port ingress bitmap array as well as to the port egress bitmap array and also adds the primary VID of the private VLAN to the port egress bitmap (block 618 ).
- the utility/administrator adds the VID to the port ingress bitmap and also adds the primary VID of the PVLAN to the port egress bitmap array (block 626 ).
- a next check is performed at block 628 of whether the VID is the PVID of the port.
- the utility/administrator adds the primary VID of the PVLAN to port strip bitmap (block 630 ).
- the utility/administrator processes the VID as a regular VID (block 632 ).
- the utility/administrator adds the VID to the port ingress bitmap and also adds the VID to the port egress bitmap (block 634 ).
- the utility checks at block 636 whether the VID is the PVID of the port, and in response to the VID being the PVID of the port, the utility adds the VID to the port strip bitmap (block 638 ).
- the non private-VLAN portion of the process of registering VLANS and updating the VLAN bitmaps when new VLANs are received for registering within the PVLAN completes at termination block 640 .
- the resulting bitmap of the port is a combined bitmap that is generated by simply merging the bitmaps as generated above. Since the set of VIDs supported by each PVLAN is globally unique, the same combination of ingress, egress and strip bitmaps can support multiple PVLANs on a single port. Also, the non-private VLAN IDs (i.e., regular VLANs) can be supported on the same bitmaps. In this scenario, where the VLAN is not a private VLAN, the ingress and egress VLAN bitmaps will both contain the same bit settings for regular VLANs.
- the uplink port bitmaps can be automatically generated by performing a merge or a union of the access port bitmaps. In one alternate embodiment, the administrator can explicitly configure the VLANs on the uplink ports.
- the methodology for handling the packets correctly requires accuracy with the configuration stages of the bitmaps.
- In the ingress part there is a check if the VLAN ID of the frame is supported by the port, and that check is performed against an Ingress bitmap.
- Within the forwarding part there is a check whether the destination port supports the VID of the frame. This check is performed against the Egress bitmap.
- a check is performed to determine whether or not to strip the frame's tag. This check is performed according to the strip bitmap.
- the packet forwarding logic can process/verify the VLANs of a received packet and respond appropriately.
- the methodology for performing this verification and processing of packets provides an O(1) solution because each packet must be verified via three (3) substantially constant bitmaps and the solution is constant regardless of (i.e., is not depend on) the number of VLANs in the system. Also, the algorithm thus enables one to check whether the packet VLAN ID is set in (belongs to) a particular Bitmap is also a O(1) algorithm.
- FIGS. 8A and 8B illustrates two embodiments of methods by which certain of the described features of the O(1) algorithm are implemented by the executing firmware or software controlling the relevant port. While the method of FIG.
- PPH utility 344 executes on one more processors (or virtual processors) of virtualization manager on the host system itself.
- the various processes can thus be described as being performed by the PPH utility 344 and/or by port forwarding logic, which may in turn be configured and/or instantiated by the network administrator.
- the administrator can interact with the PRBS utility 343 via a command line interface (CLI) on the management console 315 , in one embodiment.
- CLI command line interface
- the functionality of the PPH utility 334 can be integrated with that of the PRBS utility 343 to form a single combined utility, which presents itself as an executable code segment and/or logic implemented within the ports of the DVS supporting one or more PVLANs.
- FIG. 9 illustrates components of a virtual port and DVS involved in the forwarding and processing of a packet detected on an ingress path and on an egress path of an example virtual port.
- DVS 900 comprises one or more port controller logic (port controller) 905 , within which is maintained several components and utilities that enable and/or perform the various functions of the embodiments described herein.
- Port controller 905 comprises policy component 342 and PRBS utility 343 .
- port controller 905 comprises a plurality of sets of port VLAN arrays 340 a . . . n and associated PVIDs 345 a . . . n.
- each set of port VLAN arrays (e.g., arrays 340 a ) comprises three bitmap arrays, namely ingress bitmap array, egress bitmap array, and strip bitmap array.
- Port controller 905 also comprises port forwarding logic 910 (which can be generated via execution of the aforementioned PPH utility 344 ( FIG. 3 ). Port forwarding logic connects to and interfaces with receiving interfaces 932 and 942 (or receiving queues 934 and 944 , in an alternate embodiment) of ingress path 930 and egress path 940 , respectively, of virtual port 920 .
- both ingress path 930 and egress path 940 comprise a receiving queue 934 , 944 coupled to respective receiving interface 932 , 942 .
- both paths ( 930 , 940 ) comprise a transmit queue 936 , 946 coupled to a respective transmit interface 938 , 948 .
- Packet processing logic 935 , 945 are also provided within each path ( 930 , 940 ). It is appreciated that packet processing logic 935 , 945 can simply be an extension of port forwarding logic 910 abstracted to the location within the respective paths ( 930 , 940 ) at which processing of the received packets occurs.
- the virtual port 920 can also maintain a copy of the port's port VLAN arrays 340 a and associated PVID 345 a.
- the method begins at block 802 at which an ingress packet handler for the source port is instantiated to handle a packet with a VLAN ID (VID).
- VID VLAN ID
- the VLAN ID is retrieved from the packet header when the port detects/receives the packet for processing.
- the PPH utility determines at block 804 whether the VID of the packet is set. In response to the VID of the packet not being set, the PPH utility tags the packet with the PVID of the source port (block 806 ). Once the VID of the packet is set or following the PPH utility tagging the packet with the PVID of the source port, the PPH utility determines at block 808 whether the source port's ingress bitmap supports the VID.
- the packet is dropped (block 810 ).
- the PPH utility enables the source port to process the packet (block 812 ).
- the PPH utility instantiates a forwarding function for the packet and determines the destination port for the packet. With the destination port identified, the PPH utility checks at block 816 whether the packet's VID is in the destination port's egress bitmap. In response to the packet VID not being in the destination port's egress bitmap, the PPH utility drops the packet (block 818 ).
- the PPH utility processes the packet on the destination port (block 820 ).
- PPH utility checks whether the packet's VID is in the destination port's strip bitmap. In response to the packet's VID being in the destination port's strip bitmap, the PPH utility removes the VID from the packet (block 824 ). The PPH utility then completes processing the packet (block 826 ).
- the method begins at block 830 and proceeds to block 832 which indicate the port forwarding logic 910 detecting an incoming transmission of a packet at a virtual port (e.g., port 920 ) of the DVS 900 .
- the virtual port is assigned to enable routing of received packets to and from devices within one or more VLANs.
- Process block 834 then provides the port forwarding logic retrieving a VLAN ID (VID) from the header of the packet.
- VLAN ID is a value assigned to uniquely identify the particular VLAN from other VLANs of a plurality of VLANs that can be supported by the first virtual port.
- the method process thus comprises: the port forwarding logic checking at block 840 whether a received packet does not have a PVID.
- the port forwarding logic 910 In response to the received packet on the ingress path not having a PVID, the port forwarding logic 910 automatically tags the packet with the PVID of the virtual port (block 842 ).
- the port forwarding logic 910 receives the packet at the port and initiates processing (via packet processing logic 935 ) of the received packet by the port (block 844 ). However, in response to the ingress array offset position not being set, the port forwarding logic 905 discards the packet ( 846 ).
- the detected packet on the ingress path is only allowed to be processed by the port when the VID identifies a VLAN that has a corresponding offset position in the ingress bitmap array set. Processing of the packet on the ingress path then ends and the next packets received at the port are similarly processed, which processing can be completed concurrently for efficiency.
- the port forwarding logic 910 checks (block 848 ) whether an egress array offset position within an egress bitmap array of the virtual port is set, which would indicates that the VLAN is supported by the port.
- the egress array offset position corresponds to the value of the VID and is set within the egress bitmap array during configuration of the VLAN on the port.
- the port forwarding logic 910 receives the packet at the port and initiates processing of the received packet by the port (block 850 ).
- the port forwarding logic 910 discards the packet (block 842 ). Again, the detected packet on the egress path is only allowed to be processed by the port when the VID identifies a VLAN that has a corresponding offset position in the egress bitmap array set.
- the method process further comprises the port forwarding logic 910 checking at block 852 whether a strip array offset position within a strip bitmap array of the virtual port is set, which would indicate that the VLAN is supported by the port and that the VID should be removed before the packet is forwarded.
- the strip array offset position corresponds to the value of the VID and is set within the strip bitmap array during configuration of the VLAN on the port.
- the port forwarding logic automatically removes the PVID from the packet before forwarding the packet (block 858 ).
- the port forwarding logic 910 removes the VID from the packet and forwards the packet without the VID to a destination device of the VLAN identified by the packet (block 856 ). Processing of the packet on the ingress path then ends and the next packets received at the port are similarly processed, which processing can be completed concurrently for efficiency.
- the above described illustrative embodiments present a method for efficiently handling packets within virtual ports of a DVS supporting one or more PVLANs configured with community, isolated and promiscuous sub-domains.
- the method is performed within a host data processing system (host system) having a virtualization manager that configures and enables a virtualized computing environment.
- the virtualized computing environment includes one or more virtual machines and locally-accessible components of a layer 2 distributed virtual switch (DVS) including a plurality of virtual ports supporting packet transmission within at least one virtual local area network (VLAN).
- a processing resource of the virtualization manager executes code (e.g., the PPH utility 344 ) which generates processing logic (e.g., port forwarding logic 910 ) that performs the method.
- each of the ingress bitmap array, egress bitmap array and strip bitmap array is a single dimension array comprising N bit entries, with each bit corresponding to an offset position from 0 through N ⁇ 1, where N is an integer number representing a maximum number of individual VLANs that can be supported by the virtual port using globally unique identifiers (ID) ranging in value from 0 through N ⁇ 1;
- ID globally unique identifiers
- an offset position in one of the ingress bitmap array, egress bitmap array and strip bitmap array is set when a value of that bit position in the respective bitmap array has a value of one (1);
- the process of checking whether the offset position is set comprises comparing the value at that offset position to one (1) and indicating the offset position is set when the value is equal to one (1).
- the virtual port can be an access port or an uplink port and each port comprises: an ingress VLAN bitmap containing set offset positions corresponding to VIDs of VLANs that are supported by the port in the ingress path to the port; an egress VLAN bitmap containing set offset positions corresponding to VIDs of VLANs that are supported by the port in the egress path to the port; and a strip VLAN bitmap containing set offset positions corresponding to VIDs identifying VLANS for which the VID is to be removed on the egress path before forwarding the received packet from the port.
- the method comprises: receiving a request (including but not limited to receiving the request via a command line interface (CLI) or a GUI) to add a new VLAN to the virtual port; assigning a globally unique ID to the new VLAN as a new VID; identifying an offset position in each of the bitmap arrays generated for the new VLAN, where the offset positions corresponds to a value of the new VID; updating the respective offset position within each of the bitmap arrays with a value indicating the association of the new VLAN, based on a type characteristic of the virtual port.
- a request including but not limited to receiving the request via a command line interface (CLI) or a GUI
- the method further provides: associating properties to the new VLAN, based on received input from the CLI; and storing the properties of the new VLAN and instantiating the port to process packets to and from devices of the new VLAN, whose packet communication is supported by the port.
- the method further comprises: in response to receiving a request to add a new port to a PVLAN: assigning a unique Port VLAN ID (PVID) to the new port; autonomously generating an ingress bitmap array, an egress bitmap array, and a strip bitmap array for the new port; setting appropriate offset positions of each of the ingress bitmap array, the egress bitmap array, and the strip bitmap array corresponding to each VLAN and each PVLAN that are supported by the port; storing the ingress bitmap array, the egress bitmap array, and the strip bitmap array for use when processing packets received on the ingress path and the egress path of the new port; and storing the assigned PVID VLAN ID along with the bitmap arrays.
- PVID Port VLAN ID
- the autonomously generating and the setting of appropriate offset positions of each of the ingress bitmap array, the egress bitmap array, and the strip bitmap array comprises: identifying which one of an isolated sub-domain, a community sub-domain and a promiscuous sub-domain of a PVLAN the new port is associated with, where the isolated sub-domain has an isolated VLAN ID (VID), the community sub-domain has a community VID that is unique for that community sub-domain among multiple community sub-domains, and the promiscuous sub-domain shares the primary VLAN ID as the promiscuous VID.
- VID isolated VLAN ID
- the community sub-domain has a community VID that is unique for that community sub-domain among multiple community sub-domains
- the promiscuous sub-domain shares the primary VLAN ID as the promiscuous VID.
- the method further provides: in response to the new port being associated with an isolated sub-domain, setting a bit value at an ingress offset position within the ingress bitmap array corresponding to the isolated VID, setting a bit value at an egress offset position within the egress bitmap array corresponding to the promiscuous VID, wherein the promiscuous VID is the same as the primary VLAN ID, and setting a bit value at a strip offset position within the strip bitmap corresponding to the promiscuous VID if the PVID of the new port is set to the isolated VID; in response to the new port being associated with a community sub-domain, setting an ingress offset position within the ingress bitmap array corresponding to the community VID, setting a first bit value at a first egress offset position within the egress bitmap array corresponding to the promiscuous VID and setting a second bit value at a second egress offset position within the egress bitmap array corresponding to the community VID, and setting both a first bit value at a first strip offset position and
- the above embodiment provides: in response to the new port being associated with multiple PVLANs with each having a set of globally unique VIDs, the autonomously generating and the setting of appropriate offset positions of each of the ingress bitmap array, the egress bitmap array, and the strip bitmap array comprises: merging respective ones of each set of three bitmaps generated for each PVLAN into a single set of three combined bitmaps, wherein multiple ingress bitmap arrays are merged into a single combined ingress bitmap array, multiple egress bitmap arrays are merged into a single combined egress bitmap array, and multiple strip bitmap arrays are merged into a single combined strip bitmap array.
- the method in response to receipt of a request to add a VLAN to the DVS, the method comprises: generating the ingress bitmap array and the egress bitmap array with a same bit setting for access port bitmaps of non-private VLANs; and automatically generating an ingress bitmap and an egress bitmap for an uplink port by merging all of the egress bitmaps and ingress bitmaps that belong to the VLAN.
- the VLAN bitmap of an uplink port can be generated by an alternate method that involves the following processes: (a) for the ingress bitmap, merge VLAN bitmaps of all access ports (ingress and egress) that are supported by the uplink port; for the egress bitmap, merge VLAN bitmaps of all access ports (ingress and egress) that are supported by the uplink port. Finally, the strip bitmap depends on the PVID assigned to the uplink port.
- One embodiment of the invention provides a computer program product comprising: a computer readable storage medium; and program code on the computer readable medium that when executed by a processor associated with a virtualization manager executing on a data processing system to generate a virtualized computing environment having one or more distributed virtual switches (DVS), causes the virtualization manager to perform each of the above recited method functions.
- a computer program product comprising: a computer readable storage medium; and program code on the computer readable medium that when executed by a processor associated with a virtualization manager executing on a data processing system to generate a virtualized computing environment having one or more distributed virtual switches (DVS), causes the virtualization manager to perform each of the above recited method functions.
- DVD distributed virtual switches
- another embodiment of the invention provides a data processing system comprising: one or more processors providing processing resources; one or more memories coupled to the one or more processors; one or more network interfaces that enables communication with other devices via a physical network; and a virtualization manager that configures the data processing system as a virtualized machine having a distributed virtual switch (DVS) and one or more virtual machines that communicate within a virtual local area network (VLAN) via ports associated with the DVS within a virtualized environment, and wherein the virtualization manager comprises one or more executable utilities, including packet processing logic, that execute on a processing resource and causes the virtualization manager to: assign a globally unique VLAN identifier (ID) to each sub-domain of a PVLAN established within the virtualized environment on the host system; tag packets in the outbound path from and the inbound path to a virtual port of the DVS within the PVLAN with a correct VID; and dynamically validate a VID of a received packet on the inbound and the egress path to the virtual port by performing the various functions of
- the virtual port is one or more of an access port and an uplink port and each port comprises: an ingress VLAN bitmap containing set offset positions corresponding to VIDs of VLANs that are supported by the port in the ingress path to the port; an egress VLAN bitmap containing set offset positions corresponding to VIDs of VLANs that are supported by the port in the egress path to the port; and a strip VLAN bitmap containing set offset positions corresponding to VIDs identifying VLANS for which the VID is to be removed on the egress path before forwarding the received packet from the port;
- the VLAN is a private VLAN (PVLAN) and each virtual port further comprises a PVID VLAN ID, which indicates a VLAN tag that is added to untagged packets on the ingress path; multiple distributed virtual switches are supported by a same set of PVLANs, multiple PVLAN domains are provided within a single DVS, and PVLAN policies are uniformly enforced by packet handling logic of the virtualization manager;
- each block in the flowcharts or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s).
- the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved.
- one or more of the methods are embodied in a computer program product having a computer readable medium containing computer readable/program code/instructions such that a series of steps are performed when the computer readable/program code/instructions are executed (by a processing unit/processor) on a computing device/machine.
- certain processes of the methods are combined, performed simultaneously or in a different order, or perhaps omitted, without deviating from the spirit and scope of the invention.
- the method processes are described and illustrated in a particular sequence, use of a specific sequence of processes is not meant to imply any limitations on the invention. Changes may be made with regards to the sequence of processes without departing from the spirit or scope of the present invention. Use of a particular sequence is therefore, not to be taken in a limiting sense, and the scope of the present invention extends to the appended claims and equivalents thereof.
- aspects of the present invention may be embodied as a system, method or computer program product. Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.
- the computer readable medium may be a computer readable signal medium or a computer readable storage medium.
- a computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing.
- a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.
- a computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof.
- a computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.
- Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, R.F, etc., or any suitable combination of the foregoing.
- Computer program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages.
- the program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server.
- the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
- LAN local area network
- WAN wide area network
- Internet Service Provider an Internet Service Provider
- These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.
- the computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
- the processes in embodiments of the present invention may be implemented using any combination of software, firmware or hardware.
- the programming code (whether software or firmware) will typically be stored in one or more machine readable storage mediums such as fixed (hard) drives, diskettes, optical disks, magnetic tape, semiconductor memories such as ROMs, PROMs, etc., thereby making an article of manufacture in accordance with the invention.
- the article of manufacture containing the programming code is used by either executing the code directly from the storage device, by copying the code from the storage device into another storage device such as a hard disk, RAM, etc., or by transmitting the code for remote execution using transmission type media such as digital and analog communication links.
- the methods of the invention may be practiced by combining one or more machine-readable storage devices containing the code according to the present invention with appropriate processing hardware to execute the code contained therein.
- An apparatus for practicing the invention could be one or more processing devices and storage systems containing or having network access to program(s) coded in accordance with the invention.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Packet processing logic of a host system's virtualization manager detects packets on the ingress or the egress path to/from a virtual port having three bitmap arrays for processing packets within a virtual local area network (VLAN). The logic checks the VLAN identifier (VID) of the packet to determine, based on an offset position within the corresponding bitmap array, whether the port supports the VLAN. Both the ingress array offset position and egress array offset positions correspond to the value of the VID, and are set within the specific bitmap array during configuration of the VLAN on the port. When the VLAN is supported by the port, the logic enables the packet to be processed by the port. Otherwise, the logic discards the packet. A strip bitmap array indicates when a packet's VID should be removed prior to forwarding the packet on the egress of a port (or destination port).
Description
The present application is a continuation of and claims priority from U.S. patent application Ser. No. 13/107,554, filed on May 13, 2011, titled “Efficient Software-Based Private VLAN Solution for Distributed Virtual Switches,” which is incorporated by reference herein in its entirety and for all purposes.
1. Technical Field
The present invention relates in general to computer networks and in particular to virtualized local area networks (VLANs). Still more particularly, the present invention relates to private VLANs supported by distributed virtual switches.
2. Description of the Related Art
Virtual local area networks (VLANs) are known in the art and represent a broadcast domain in which a client (typically a virtual client) can send frames to other clients that exist within the same VLAN. Private VLANs (PVLANs) represent an extension of this virtualized network paradigm, in which additional security is provided within the network to prevent monitoring of the traffic being communicated, among other benefits. Private VLANs (PVLAN) are a standard feature set supported on most hardware and software based Layer 2 switches. The introduction of distributed virtual switches (DVS) to the PVLAN implementation adds a new layer of complexity to the virtualized networking paradigm.
Disclosed is a method that provides for efficient handling of packets within virtual ports of a distributed virtual switch (DVS) supporting one or more private virtual local area networks (PVLANs) configured with community, isolated and promiscuous sub-domains. Packet processing logic of a host system's virtualization manager detects packets on the ingress or the egress path of a DVS to a virtual port having three VLAN bitmap arrays used for processing packets within a virtual local area network (VLAN). The logic checks the VLAN identifier (VID) of the packet to determine, based on an offset position within the corresponding bitmap array, whether the VLAN is supported by the port. Both the ingress VLAN bitmap array offset position and egress VLAN bitmap array offset position correspond to the value of a VID, and are set within the specific bitmap array during configuration of the VLAN on the port. When the VLAN is supported by the port, the logic enables the packet to be processed by the port. Otherwise, the logic discards the packet. A strip bitmap array indicates when a packet's VID should be removed prior to forwarding the packet on the egress of the port.
In the described embodiment, the method is performed within a host data processing system (host system) having a virtualization manager that configures and enables a virtualized computing environment. The virtualized computing environment includes one or more virtual machines and locally-accessible components of a layer 2 distributed virtual switch (DVS) including a plurality of virtual ports supporting packet transmission within at least one virtual local area network (VLAN). A processing resource of the virtualization manager executes packet processing logic/code of the virtualization manager which logic/code causes the virtualization manager to perform various functional processes that enable packet forwarding via the virtual port utilizing a VLAN ID retrieved from the packet and the ingress bitmap array for packets on the ingress path and the egress bitmap array for packets on the egress path of the virtual port. When the VLAN ID is not identified within the specific bitmap array, the packet is discarded. A detected packet on the ingress path or the egress path is only allowed to be processed by the port when the VID identifies a VLAN that has a corresponding offset position in the bitmap array set.
The virtual port is one or more of an access port and an uplink port and each port comprises: an ingress VLAN bitmap containing set offset positions corresponding to VIDs of VLANs that are supported by the port in the ingress path to the port; an egress VLAN bitmap containing set offset positions corresponding to VIDs of VLANs that are supported by the port in the egress path to the port; and a strip VLAN bitmap containing set offset positions corresponding to VIDs identifying VLANS for which the VID is to be removed on the egress path before forwarding the received packet from the port. Each virtual port further comprises a port VLAN ID (PVID), which indicates a VLAN tag that is added to untagged packets on the ingress path. The method then comprises: in response to the received packet on the ingress path not having a VLAN tag, automatically tagging the packet with the PVID of the virtual port; and in response to the detected packet on the egress path having the PVID tagged thereto, automatically removing the PVID from the packet before forwarding the packet.
One embodiment of the method further comprises: checking whether a strip array offset position within a strip bitmap array of the virtual port is set, indicating that the VLAN is supported by the port and that the VID should be removed before the packet is forwarded, where the strip array offset position corresponds to the value of the VID and is set within the strip bitmap array during configuration of the VLAN on the port; and responsive to the strip array offset position being set, removing the VID from the packet and forwarding the packet without the VID to a destination device of the VLAN identified by the packet.
In one embodiment, each of the ingress bitmap array, egress bitmap array and strip bitmap array is a single dimension array comprising N bit entries, with each bit corresponding to an offset position from 0 through N−1, where N is an integer number representing a maximum number of individual VLANs that can be supported by the virtual port using globally unique identifiers (ID) ranging in value from 0 through N−1; an offset position in one of the ingress bitmap array, egress bitmap array and strip bitmap array is set when a value of that bit position in the respective bitmap array has a value of one (1); and the process of checking whether the offset position is set comprises comparing the value at that offset position to one (1) and indicating the offset position is set when the value is equal to one (1).
Finally, embodiments of the method enable the virtualization manager to generate the set of three bitmaps and assign the globally unique port ID when configuring a new virtual port and to modify/update the bitmaps of a virtual port to support multiple VLANS and vice versa. The set of three bitmaps is assigned to each virtual port configured and updated to support the addition of additional VLANs to enable efficient handling of packets detected on the ingress and egress paths to the virtual port.
The above summary contains simplifications, generalizations and omissions of detail and is not intended as a comprehensive description of the claimed subject matter but, rather, is intended to provide a brief overview of some of the functionality associated therewith. Other systems, methods, functionality, features and advantages of the claimed subject matter will be or will become apparent to one with skill in the art upon examination of the following figures and detailed written description.
The above as well as additional objectives, features, and advantages of the present invention will become apparent in the following detailed written description.
The described embodiments are to be read in conjunction with the accompanying drawings, wherein:
The illustrative embodiments provide a method, data processing system, and a computer program product that enables efficient packet processing at a virtual network port of a distributed virtual switch (DVS) in a virtualized computing environment. The method is performed in a virtual platform in which packet processing logic is enhanced to enable more efficient packet processing within a virtual port of a private virtual local area network (PVLAN). According to the one or more aspects of the described embodiments, the packet processing logic enables both virtual and physical client machines to more efficiently communicate with each other across the distributed virtual network utilizing a set of bitmaps and a PVID assigned to each virtual port. Specifically, presented aspects of the method comprises: detecting an incoming transmission of a packet at a first virtual port of the DVS, where the first virtual port is assigned to enable routing of received packets to and from devices within one or more VLANs; retrieving a VLAN ID (VID) from the header of the packet, where the VLAN ID is a value assigned to uniquely identify the particular VLAN from other VLANs of a plurality of VLANs that can be supported by the first virtual port. The method then enables packet forwarding via the virtual port utilizing the VLAN ID retrieved from the packet and the ingress bitmap array for packets on the ingress path and the egress bitmap array for packets on the egress path of the virtual port. When the VLAN ID is not identified within the specific bitmap array, the packet is discarded. A detected packet on the ingress path or the egress path is only allowed to be processed by the port when the VID identifies a VLAN that has a corresponding offset position in the bitmap array set.
Additionally, in one embodiment described in greater detail below, when the packet is detected on the egress of the port, the method comprises: checking whether a strip array offset position within a strip bitmap array of the virtual port is set, indicating that the VLAN is supported by the port and that the VID should be removed before the packet is forwarded, where the strip array offset position corresponds to the value of the VID and is set within the strip bitmap array during configuration of the VLAN on the port; and responsive to the strip array offset position being set, removing the VID from the packet and forwarding the packet without the VID to a destination device of the VLAN identified by the packet.
One or more embodiments of the method enable the virtualization manager to generate the set of three bitmaps and assign the globally unique port ID when configuring a new virtual port and to modify/update the bitmaps of a virtual port to support multiple VLANS and vice versa. The set of three bitmaps is assigned to each virtual port configured and updated to support the addition of additional VLANs to enable efficient handling of packets detected on the ingress and egress paths to the virtual port.
In the following detailed description of exemplary embodiments of the invention, specific exemplary embodiments in which the invention may be practiced are described in sufficient detail to enable those skilled in the art to practice the invention, and it is to be understood that other embodiments may be utilized and that logical, architectural, programmatic, mechanical, electrical and other changes may be made without departing from the spirit or scope of the present invention. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope of the present invention is defined by the appended claims and equivalents thereof.
Within the descriptions of the different views of the figures, similar elements are provided similar names and reference numerals as those of the previous figure(s). The specific numerals assigned to the elements are provided solely to aid in the description and are not meant to imply any limitations (structural or functional or otherwise) on the described embodiment.
It is understood that the use of specific component, device and/or parameter names (such as those of the executing utility/logic/firmware described herein) are for example only and not meant to imply any limitations on the invention. The invention may thus be implemented with different nomenclature/terminology utilized to describe the components/devices/parameters herein, without limitation. References to any specific protocol or proprietary name in describing one or more elements, features or concepts of the embodiments are provided solely as examples of one implementation, and such references do not limit the extension of the invention to embodiments in which different element, feature or concept names are utilized. Thus, each term utilized herein is to be given its broadest interpretation given the context in which that terms is utilized. As utilized herein, the term ingress refers to the packets coming into the switch (which is the DVS in the presented embodiments) on that port, while the term egress refers to the packets going out of the switch using that port. Ingress and egress are utilized to reference the ingress path of a port and the egress path of the port, respectively.
As further described below, implementation of the functional features of the invention is provided within processing devices/structures and involves use of a combination of hardware, firmware, as well as several software-level constructs (e.g., program code). The presented figures illustrate both hardware components and software components within a specific example of data processing architecture. The illustrative and described embodiments assume that the system architecture may be scaled to a much larger data processing system and/or network.
With specific reference now to FIG. 1 , there is depicted a block diagram of an example virtualization network structure, such as a data center or an enterprise network, and which can be also be conventionally referred to as a “cloud”. Virtualization network structure 100 comprises an underlying physical network 105. The physical network 105 can include a plurality of machines/devices (as generally illustrated within the physical network 105), including one or more physical servers, routers, adapters, databases, as well as physical switches that are interconnected to each other and communicate with each other via one or more types/forms of connecting fabric (indicated by the dashed lines). Virtualization network structure 100 also comprises network virtualization layer 120 which is generated by one or more network hypervisors 110 to support a plurality of virtual local area networks (VLANs) 130. The virtual machines/devices are hosted on a virtualization platform (such as a server) having physical hardware resources (see FIGS. 2 and 3 ) that are provisioned via one or more implementations of a virtualization manager (see FIG. 3 ), such as Power Hypervisor (PHYP) of International Business Machines (IBM) Corporation.
The network hypervisor 110 provides the provisioning functionality that creates and maintains the network virtualization layer 120 and the hypervisor 120 also creates and maintains the logical forwarding elements and maps these elements to the underlying hardware. In one embodiment, network hypervisor 110 can be implemented by a controller (e.g., management console 115) using a network operating system. Control of the network virtualization layer is provided by network control manager 150, generally illustrated as associated with management console 115. Network control manager 150 is a software utility that executes on management console 115, which can be a physical or virtual device that connects to network hypervisor 110, and network control manager 150 is utilized to set up the various virtual devices and provisioning of resources to these virtual devices. Network virtualization layer 120 enables virtual ports within a DVS 145 to be abstracted to and to utilize the physical network switches (within the physical network 105) to communicate packets between devices of a VLAN (e.g., PVLAN 140). Thus network hypervisor 110 maintains mappings that enable routing of communication between the devices of the single VLAN and enables routing of packets from and to the VLAN to external devices.
Within the above described virtualization network structure, example private VLAN (PVLAN) 140 and VLAN 142 are illustrated. It is appreciated that these two VLANs represent only two of a potentially large number of VLANs, which can comprise multiple PVLANs 140 and multiple VLANs 142. Both PVLAN 140 and VLAN 142 can be supported via respective distributed virtual switches (DVS) 145 that can span across multiple host devices and which each provide a plurality of virtual ports assigned to the various virtual machines that are interconnected within the PVLAN 140 or VLAN 142.
Those skilled in the art are aware that with the rapid expansion of the virtualization computing paradigm and move towards cloud computing, large hosting services or enterprise networks can maintain multiple data centers, or networks at several sites, which may be geographically dispersed (e.g. San Francisco, N.Y., etc.). Connecting client machines/devices from within these geographically dispersed sites into a single virtual local area network (VLAN) thus requires utilization of one or more distributed virtual switches (DVS). These DVS (e.g., DVS 145) are supported via network virtualization layer 120, generated by network hypervisor 110. Each DVS 145 in turn provides a plurality of virtual ports utilized to support packet transmission to/from/within one or a plurality of VLANs 130, including one or more private VLANs (PVLAN) 140 and/or one or more VLANs 142.
Referring now to FIG. 2 , which illustrates an expanded view depicting some components of the physical hardware layer and of the network virtualization layer of FIG. 1 . It should be understood that the computing resources, layers, and functions shown in FIG. 2 are intended to be illustrative only and embodiments of the claimed inventions are not limited thereto. As depicted, physical layer 200 includes various physical hardware and software components that can be used to instantiate virtual entities for use within the virtualization network structure. As an example, the hardware components may include mainframes (e.g., IBM® zSeries® systems), reduced instruction set computer (RISC) architecture servers (e.g., IBM pSeries® systems), IBM xSeries® systems, IBM BladeCenter® systems, storage devices (e.g., flash drives, magnetic drives, optical drives, tape drives, etc.), physical networks, and networking components (e.g., routers, switches, etc.). The software components may include operating system software (e.g., AIX, Windows, Linux, etc.), network application server software (e.g., IBM WebSphere® application server software, which includes web server software), and database software (e.g., IBM DB2®, database software). IBM, zSeries, pSeries, xSeries, BladeCenter, WebSphere, and DB2 are trademarks of International Business Machines Corporation, registered in many jurisdictions worldwide. Windows is a trademark of Microsoft Corporation, and Linux is a trademark of Linux Torvalds.
The computing resources residing in physical layer 205 are virtualized and managed by one or more virtual machine monitors (VMMs) or hypervisors (e.g., network hypervisor 110). As shown, virtualization layer 220 includes multiple virtual entities (e.g., virtual servers, virtual storage, virtual networks (including virtual private networks)), virtual applications, and virtual clients. These virtual entities, which are abstractions of the underlying resources in physical layer 200, may be accessed by client devices 147 connected within the virtualized network environment. The client devices 147 can be real devices or virtual devices (e.g., virtual machines, VM).
Also included within physical layer 310 are one or more physical network interfaces (NI) 308 (also conventionally referred to as network adapters) which supports/enables the physical connection of host system 300 (and the VMs 220 a/220 b and VIOS 230) to an external network (e.g., network 105, FIG. 1 ). Additionally, physical layer310 comprise a plurality of I/O adapters and I/O devices 306, which provides the I/O interface for host system 300. I/O adapters 306 are physical adapters that enable host system 300 to support I/O operations via an I/O interface with both locally connected and remotely (networked) connected I/O devices. Examples of I/O adapters include Peripheral Component Interface (PCI), PCI-X, or PCI Express Adapter, and Small Computer System Interconnect (SCSI) adapters, among others. Host system 300 is logically partitioned such that different I/O adapters 306 are virtualized and the virtual I/O adapters may then be uniquely assigned to different logical partitions (VMs and/or VIOSes).
Logically located above the physical layer (310) is a virtualization manager 320, which can be a Power Hypervisor (PHYP), a trademark of IBM Corporation), in one embodiment. While introduced as a PHYP, it is fully appreciated that other types of virtualization management components may be utilized and are equally applicable to the implementation of the various described embodiments. The virtualization manager 320 can have an associated service processor (not illustrated) within the physical layer 310 or located elsewhere relative to the virtualization manager 320. The service processor can be used to provide various services for one or more logical partitions. As illustrated, hardware management controller (HMC) 315, which exists outside of the physical layer 310, communicates with host system 300 via virtualization manager 320. Operations of the different logical partitions can be controlled through HMC 315, which can be a separate data processing system from which a system administrator can perform various functions, such as reallocation of resources to different logical partitions.
Additionally, according to the illustrative embodiment, each logical partition is provided one or more virtual network interfaces, numbered as NI1 . . . NI4 for illustrative purposed only. These NIs allows the LPAR to communicate with other LPARs both on the host system and with other devices across a distributed network. In the described embodiments, at least one of the VMs 220 a/220 b is a part of a PVLAN and is connected to a DVS that enables connectivity across the PVLAN. DVS 330, which can be a local portion of a larger DVS spanning multiple host systems, is provided within virtualization manager 320. DVS 330 comprises a plurality of virtual ports, each assigned to one or more VMs within the PVLAN to enable transmission of packets to and from the associated device within the PVLAN.
According to one embodiment, packet transmission across the virtual ports of the DVS is made more efficient with the utilization of port routing bitmap arrays. As further shown within host system 300, virtual manager 320 comprises a port controller 325 which is associated with one or more DVSes supported by the host system 300. Port controller 325 comprises policy software component 342, which defines port routing policies and connectivity policies, among others. Port controller also comprises port registration and bitmap setup (PRBS) utility 343 and Port packet handling (PPH) utility 344. The functions provided by PRBS utility 343 and PPH utility 344 are described in detail below within the descriptions of FIGS. 6-8 . Additionally, port controller 325 comprises a plurality of individual PVIDs 345 associated with each port and corresponding sets of three VLAN arrays 340, each set corresponding to one PVID and the associated port. The method by which the bitmap arrays 340 are generated and then utilized to provide more efficient packet processing through the virtual ports of a DVS will be described in greater details with reference to FIGS. 6-9 .
Referring now to FIG. 4 , there is illustrated a view of a data processing environment comprising real and virtual connections between multiple physical host systems supporting virtual machines interconnected within a virtual networking topology/environment comprising distributed virtual switches. In the depicted embodiment, data processing environment 400 includes an Internet protocol (IP) network 402 including a plurality of network segments 404 a, 404 b, each of which is coupled to a respective one of physical routers 406 a, 406 b. As is known in the art, each of physical routers 406 a, 406 b includes a respective forwarding table 407 a, 407 b by which physical routers 406 a, 406 b route incoming data packets toward the packets' destinations based upon OSI Layer 3 (e.g., Internet Protocol (IP)) addresses contained in the packets. Physical host systems 410 a, 410 b are coupled to network segment 404 a, and physical host system 410 c is coupled to network segment 404 b. Physical hosts, such as physical host systems 410 a, 410 b, optionally may be additionally coupled by a secondary host connection 408, such as direct cabling or a private non-routed network. Each of physical host systems 410 a-410 c can be implemented, for example, utilizing a host system 300 as depicted in FIG. 3 .
Each of physical host systems 410 a-410 c executes a respective one of virtualization manager 412 a-412 c, which virtualizes and manages the resources of its respective physical host 410, for example, under the direction of a human and/or automated administrator at a management console 415 coupled to physical host systems 410 a-410 c by IP network 402. Virtualization manager 412 a on physical host system 410 a supports the execution of VMs 414 a-414 c, virtualization manager 412 b on physical host system 410 b supports the execution of VMs 414 d-414 f, and virtualization manager 412 c on physical host system 410 c supports the execution of VMs 414 g-414 i. In various embodiments, VMs 414 a-414 i can include VMs of one or more cloud consumers and/or a cloud provider. In the depicted embodiment, each of VMs 414 has at least one (and in some cases multiple) virtual network interfaces NI1-NI11, which provide network connectivity at least at Layers 2 and 3 of the OSI model.
As depicted, each of virtualization managers 412 a-412 c provides one or more (and in the depicted embodiment, at least two) virtual networks to which the manager's VMs 414 can attach. To visually distinguish them from physical sub-networks 404 a-404 b, virtual networks are represented in FIG. 4 in dashed line illustration. For example, in the depicted embodiment, virtualization managers 412 a-412 c all provide a first distributed virtual network 420 a through the implementation of individual virtual switches 430 a 1, 430 b 1 and 430 c 1 providing Layer 2 connectivity. Virtualization managers 412 a-412 b similarly provide a second virtual network 420 b through the implementation of DVSs 430 a 2 and 430 b 2. In addition, virtualization managers 412 c provides a third virtual network 420 c through the implementation of distributed switch 430 c 2. In various embodiments, each of virtual networks 420 a-420 c can be, for example, a private network (e.g., a PVLAN) of a particular cloud consumer, a collaborative private network shared by multiple cloud consumers and/or a cloud provider, or a public network. In the depicted example, network interfaces NI2, NI4, NI6, NI8, and NI10 are connected to first virtual network 420 a, network interfaces NI1, NI3, NI5, and NI7, are connected to second virtual network 420 b, and network interfaces NI9 and NI11 are connected to third virtual network 420 c. Each virtualization manager 412 preferably records information regarding the virtual network(s) 420 the particular virtualization manager supports and the connection of the corresponding VMs 414 to the virtual network(s) 420. This information is recorded as a respective one of network information 422 a, 422 b and 422 c. For example, a first virtualization manager 412 a can create an entry in its network information 422 a for one of its VMs 414 a, 414 b, or 414 c when the particular VM 414 is provisioned, deployed or migrated in, and the first virtualization manager 412 a can remove the entry from the network information 422 a when the VM 414 is migrated out or destroyed.
In one optional implementation, in order to support communication between virtual networks 420 a-420 c and between virtual networks 420 and physical networks 402 and/or 404, virtualization manager 412 a-412 c can each implement a respective one of distributed routers 432 a-432 c to provide OSI Layer 3 routing. In alternate embodiments, however, it is possible to not implement any routing functionality within a physical host. In the depicted embodiment, each distributed router 432 provides a respective network interface for each virtual network 420 instantiated by the router's virtualization manager 412, as well as a network interface to the physical network segment 404 to which the physical host 410 is attached (e.g., through a software port of a physical network interface 304). Each distributed router 432 additionally includes a respective forwarding table 434 a, 434 b and 434 c for storing routing information.
Those of ordinary skill in the art will appreciate that the hardware, firmware/software utility, and software components and basic configuration thereof depicted in FIGS. 1-4 may vary. The illustrative components of the various figures are not intended to be exhaustive, but rather are representative to highlight some of the components that are utilized to implement certain of the described embodiments. For example, different configurations of a data processing systems and/or host system can be provided, containing other devices/components, which can be used in addition to or in place of the hardware depicted, and may be differently configured. The illustrated examples are not meant to imply architectural or other limitations with respect to the presently described embodiments and/or the logical extensions thereof.
With reference now to FIG. 5A , there is illustrated a port view of a PVLAN domain. PVLAN domain 500 comprises primary VLAN 505, which in turn provides two community VLANs, named Community 1 VLAN 520 a and Community 2 VLAN 520 b, as well as Isolated VLAN 525. These VLANs are interrelated and defined within a layer 2 (L2) switch. The community VLANs 520 a, 520 b and isolated VLAN 525 are collectively referred to herein as secondary VLANs (indicated by the dashed surrounding lines). Each VLAN has an associated VLAN ID, which uniquely identifies that VLAN within the DVS. Within PVLAN are three related ports, defined, respectively, as promiscuous ports, isolated ports and community ports. As provided herein, the promiscuous ports are connected to layer 3 (L3) or layer 4 (L4) devices (e.g., routers) that may in turn connect to the Internet or administrative work station or common network servers, e.g. a Dynamic Host Configuration Protocol (DHCP) server. The isolated port and community ports connect to individual virtual and physical user devices or servers, such as VMs in FIGS. 3 and 4 , and the isolated ports and community ports carry traffic originating from or received for one of the devices within the PVLAN.
During packet routing, the primary VLAN 505 connects the promiscuous ports 510 with community ports 522 a-d or isolated ports 526 a, 526 b. Specifically, primary VLAN 505 receives packets from L3/L4 devices at the promiscuous ports 510 and transfers the packets to one or more of the secondary VLANs. As provided herein, an isolated VLAN is defined as a VLAN that functionally connects isolated ports to promiscuous ports. In an isolated VLAN the traffic is only one way, i.e., packets are received at an isolated port and travel only from that isolated port to a promiscuous port. Packets are not available to other isolated or community ports. A community VLAN is defined as a VLAN that functionally connects community ports to promiscuous ports. Within a community VLAN, traffic is only routed one way, i.e., packets are received at a community port and travel only from that community port to the promiscuous ports and to the other community ports on that community VLAN. In the described routing protocol, packets do not travel from a community port to isolated ports, or to community ports on a different community VLAN that may exist on the same switch.
When configuring a VLAN within an L2 switch, an administrator can manually designate ports within the VLAN. However, when configuring PVLANs, the administrator defines a primary VLAN and one or more secondary VLANs. With the described embodiment, for a software-enabled DVS (as presented by FIG. 4 ) to support the PVLAN feature, the DVS must support all of the three types of ports supported within a PVLAN, enforce the communication restrictions enforced by PVLANs (which can be defined by example policy software 342, FIG. 4 ), and support multiple PVLAN domains.
While existing within the layer 2 domain of communication, PVLAN 500 has multiple sub-domains. As defined herein, each PVLAN sub-domain consists of two VLAN IDs (VIDs), specifically a Primary VLAN ID and a secondary VLAN ID. The Primary VLAN represents the PVLAN communication domain, while the secondary VLANs are communication sub-domains with a PVLAN domain. Thus, a secondary VLAN ID is a globally unique ID amongst all PVLANs supported in a network. Each network port falls in one (and only one) of the 3 types of sub-domains within a single PVLAN, defined as follows:
-
- (1) Promiscuous Ports—These ports can communicate with all ports in a PVLAN domain. The promiscuous port supports a
secondary VLAN ID 547 that is the same as theprimary VLAN ID 545 ofPVLAN 500. - (2) Community Ports—These ports can communicate with promiscuous ports and other ports within the same community (e.g.,
community port 522 a can exchange communication withcommunity port 522 b withinCommunity 1VLAN 520 a). As presented byFIG. 5 , there can be multiple communities within a single/same PVLAN 500. Each community is represented by aunique VLAN ID primary VLAN ID 545, theisolated VLAN ID 550 and the VLAN IDs of other communities. - (3) Isolated Ports—These ports can only talk to the promiscuous ports. The secondary VLAN ID of an
isolated port primary VLAN ID 545. In one embodiment, only one isolated VLAN ID (550) is supported withinPVLAN 500.
- (1) Promiscuous Ports—These ports can communicate with all ports in a PVLAN domain. The promiscuous port supports a
Each port enables communication to and from one or more end devices, of which end device 524 a-524 d are illustrated, as two end devices (S1, S2) per community VLAN 520 a, 520 b. Isolated VLANs 525 also each include end devices 528 a, 528 b, with one end device (S4, S5, respectively) illustrated per isolated VLAN 525.
The table 500 of FIG. 5B summarizes the port actions within the Private VLAN illustrated by FIG. 5A . Supporting a PVLAN solution on a DVS depends on the software entities on each host enforcing the communication restrictions required by the PVLAN. In DVS related applications, the DVS solution typically consists of software entities in multiple hosts/machines. The software entity forwards packets amongst the DVS access ports (e.g., ports that connect to a Virtual Machine) within the host system and communicates with the outside network by forwarding (to and from the host) using network cards (uplink ports) on the host system. The software entity on a particular virtual machine is only aware of the ports supported on that virtual machine, which may only be a (small) subset of all the ports supported by the entire DVS solution. While it is possible that the software entity be made aware of ports on other hosts (within the same DVS), this configuration would add an unnecessary layer of complexity and size to the forwarding table in the software entity (i.e., the local DVS).
Traffic Switched at layer 2 is based on frames of data with MAC headers. Layer 2 switches can contain hundreds of ports on a single switch. Private VLANs provide layer2 isolation between the ports within the same broadcast domain. Private VLANs partition a regular VLAN domain into sub domains, represented by a pair of VLANs, a primary VLAN and a secondary VLAN. Every port in a private VLAN is a member of the primary VLAN. The primary VLAN carries unidirectional traffic downstream from the promiscuous ports to the isolated and community ports and to other promiscuous ports. An isolated VLAN carries unidirectional traffic upstream from the isolated ports toward the promiscuous ports. Community VLANs carry upstream traffic from the community ports to the promiscuous port and to other host ports in the same community. Multiple community VLANs can be configured in a private VLAN. In one embodiment, a community port can also receive upstream traffic. Additionally, an port that receives upstream traffic can support more than one VLAN. As provided herein, an isolated port is a host port that belongs to an isolated secondary VLAN. The isolated port has the complete layer2 separation from other ports with in the same private VLAN except for the promiscuous ports. Private VLANs block all the traffic getting to the isolated ports except the traffic from the promiscuous ports, and traffic received from an isolated port is forwarded only to promiscuous ports. A community port is a host port that belongs to a community secondary VLAN. Community ports can communicate with other ports in the same community VLAN and with promiscuous ports. These interfaces are isolated at layer 2 from all other interfaces in other communities and from isolated ports within their private VLAN.
Within a PVLAN, several configuration restrictions apply. A listing of these restrictions can include one or more of the following: (1) There can be only one isolated VLAN in a private VLAN; (2) An isolated port cannot be an uplink port; (3) Secondary VLAN ports cannot overlap other VLANs in the same Private VLAN domain; (4); (4) Default VLAN in the network cannot be a private-VLAN; (5) A primary VLAN that is mapped to a secondary VLAN need to be both created and enabled; (6) If a port is not tagged it cannot support more than one VLAN; (7) A port can either be a promiscuous port or a community port or an isolated port within a Private VLAN domain; (8) Up to 4095 PVLANs can be supported with identifier numbers 0 and 4095 being reserved; and (9) A private VLAN needs to be created and enabled in order for a port to support the PVLAN.
With the increased need of software-based Layer 2 switches in the virtualization solutions, aspects of the embodiments described herein provides an efficient algorithm for network packet processing in the DVS software. As defined hereinafter, these embodiments provide an efficient, O(1), packet processing (data-path) PVLAN solution in a DVS. The described embodiments are built upon the fact that the VLAN ID of any sub-domain (whether promiscuous, isolated or communities) within a PVLAN is globally unique. Thus, one aspect of the embodiments involves the software entities (on a host system) implementing a specific PVLAN policy enforcement by tagging packets with the right VLAN ID in the outbound/ingress path from a port and validating the VLAN ID on packets on the inbound/egress and/or egress path to a port. This method ensures that multiple DVSs can support the same set of PVLAN and enforce the PVLAN policies uniformly. According to the presented embodiments, the efficiency of the described solution is based on how the ports validate the VLAN tags on the packets. While there may be multiple PVLANs domain within a DVS and each access port may belong to multiple PVLAN itself, the method presented by the described embodiment avoids walking any PVLAN lists during packet processing.
Under the optimized solution provided by the embodiments, each port (both access port and uplink port) in the DVS supports three VLAN bitmaps (also interchangeably referred to herein as bitmap arrays). As now described with reference to FIG. 7 , the three bitmaps (or bitmap arrays) of each port are: ingress VLAN bitmap 742, egress VLAN bitmap 744, and strip VLAN bitmap 746. Ingress VLAN Bitmap 742 contains VLANs that a port supports in the ingress path. Egress VLAN Bitmap contains VLANs that the port supports in the egress path. Finally, strip VLAN Bitmap contains VLANs that the software module must remove/strip on the egress path before sending the frame/packet to the port. The bitmap arrays are maintained within port bitmaps 340, which in one embodiment maintains a plurality of port bitmaps 740 a . . . 740 m, for the M ports supported within the DVS, where M is an integer. As shown by FIG. 7 and example bitmap arrays (740) for Port 1, each bitmap array has N entries corresponding to the maximum number of VLANs supported on the particular DVS. Each of the three VLAN Bitmaps is a single dimension array of N bits. In one embodiment, N=4096 bits (512 Bytes); However the value of N is a system parameter that can be a different number in alternate embodiments. As provided herein, a bit can be set when its value is toggled from a zero (0) to a 1. All bits that are not set therefore contain a value of zero. When a bit is set in the Mth position (offset relative to the beginning of the array) of the array, then VLAN M is present in the bitmap. The numbers illustrated within ingress VLAN bitmap 742 of Port 1 represents the N bits in sequential order ranging from 0 through N− 1. Egress VLAN bitmap 744 then illustrates that there is a corresponding VLAN present and allocated to locations 1, 3, 4 and N−2 of egress VLAN bitmap 744. Also, strip VLAN bitmap 746 indicates that the packets being routed to VLANs 4 and the last VLAN (N−1) should be stripped of the VLAN ID before routing a packet from that PVLAN to/from the virtual port.
In addition to the bitmap arrays 742, 744, and 746, each port has a PVID VLAN ID 750. The PVID 750 indicates the VLAN tag that must be added to un-tagged packets on the ingress path and also indicates which tags are to be removed on the egress path. According to one embodiment and as illustrated by the method of FIG. 6 , the PVLANs (and VLANs) are set appropriately on each bitmap of a port when the port is initially added to a PVLAN (or a non-private VLAN) or vice-versa, which is an infrequent operation and thus not in the path of packet processing.
Referring now to FIG. 6 , there is illustrated a method by which an administrator, using a management console and executing software thereon, completes the process of adding a port to a DVS. Once the port information is provided to the software, the controlling software subsequently generates the appropriate three bitmap arrays for that port. It is appreciated that some of these steps can be automated and performed by processing components of management console 315 and that most of the steps can also be performed manually by the network administrator working at the management console 115. As described herein, the method is completed via/with port registration and bitmap setup (PRBS) utility 343, which executes on one more processors (or virtual processors) of either management console 315 (FIG. 3 ) or a processor of the virtualization manager on the host system itself. The various processes are thus described as being performed by the PRBS utility 343, which may in turn be configured and/or instantiated by the network administrator. Execution of the utility can provide processing logic that performs the various described functions. When initiated by the network administrator, the administrator can interact with the PRBS utility 343 via a command line interface (CLI) on the management console 315, in one embodiment.
The method of FIG. 6 begins at block 602 at which the VLAN ID (VID) is added to a virtual machine port on a DVS. A determination is made at block 604 whether the VID is for a private VLAN. When the VLAN ID is for a private VLAN, the private VLAN is processed and treated as a secondary VLAN of the existing private VLAN (block 606). A next determination is made at block 608 whether the VID is the primary VLAN ID in the private VLAN. In response to the VID being the primary VLAN ID in the private VLAN, all VLAN IDs in the private VLAN are added to the port's ingress bitmap and all of the VLAN IDs in the private VLAN are also added to the port egress bitmap (block 610). At decision block 612, the PRBS utility 343 (FIG. 3 ) and/or the administrator determines whether the VID is the PVID of the port. In response to the VID being the PVID of the port, the utility/administrator adds all VLAN IDs in the private VLAN to the port strip bitmap array/array (block 614). This path of registering the VID then completes (block 640).
Returning to decision block 608, if the VID is not the primary VLAN ID in the PVLAN, then a check is made at block 616 whether the VID is a community VLAN ID in the PVLAN. In response to the VID being a community VLAN ID in the PVLAN, the utility/administrator adds the VID to the port ingress bitmap array as well as to the port egress bitmap array and also adds the primary VID of the private VLAN to the port egress bitmap (block 618). A next check is made at block 620 whether the VID is the PVID of the port, and when the VID is the PVID of the port, the utility/administrator adds the VID and the primary VID of the PVLAN to the port strip bitmap array (block 622). This path of the registering the VID then completes (block 640).
At decision block 616, if the VID is not a community VLAN ID in the PVLAN, a check is made at block 624 whether the VID is an/the isolated VLAN ID in the PVLAN. In response to the determination that the VID is that of the isolated VLAN ID (isolated port) in the PVLAN, the utility/administrator adds the VID to the port ingress bitmap and also adds the primary VID of the PVLAN to the port egress bitmap array (block 626). Then, a next check is performed at block 628 of whether the VID is the PVID of the port. In response to the VID being he PVID of the port (while the VID is also the isolated VLAN ID in the PVLAN), the utility/administrator adds the primary VID of the PVLAN to port strip bitmap (block 630).
Returning back to decision block 604, in response to the VID not being that of a private VLAN, the utility/administrator processes the VID as a regular VID (block 632). The utility/administrator adds the VID to the port ingress bitmap and also adds the VID to the port egress bitmap (block 634). The utility then checks at block 636 whether the VID is the PVID of the port, and in response to the VID being the PVID of the port, the utility adds the VID to the port strip bitmap (block 638). The non private-VLAN portion of the process of registering VLANS and updating the VLAN bitmaps when new VLANs are received for registering within the PVLAN completes at termination block 640.
The above method can also be described from the specific viewpoint of the type of access port for which the bitmap generation is being performed. Thus, for example, when performing generation and/or update of the various ports, the following conditions become applicable.
-
- (1) For an isolated port, where the port is in an isolated sub-domain of a PVLAN, the ingress VLAN Bitmap contains the Isolated VLAN ID, the egress VLAN Bitmap contains the promiscuous (primary) VLAN ID, and the strip VLAN bitmap contains the promiscuous VLAN ID if the PVID of the port is set to the Isolated VID.
- (2) For a community port, where the port belongs to a community sub-domain of a PVLAN, the ingress VLAN Bitmap contains the community VLAN ID, the egress VLAN Bitmap contains the community and promiscuous VLAN ID, and the strip VLAN Bitmap contains both the community and promiscuous VLAN ID, if the PVID of the port is set to the community VID.
- (3) For the promiscuous port, where the port belongs to the promiscuous sub-domain of a PVLAN, the ingress VLAN Bitmap contains the promiscuous VLAN ID, the egress VLAN Bitmap contains all the VIDs in the PVLAN, i.e. all community, isolated and primary VIDs, and the strip VLAN Bitmap contains all the VIDs in the PVLAN (similar to the Egress), if the PVID of the port is set to the promiscuous VID.
Additionally, if a port belongs to multiple PVLANs, the resulting bitmap of the port is a combined bitmap that is generated by simply merging the bitmaps as generated above. Since the set of VIDs supported by each PVLAN is globally unique, the same combination of ingress, egress and strip bitmaps can support multiple PVLANs on a single port. Also, the non-private VLAN IDs (i.e., regular VLANs) can be supported on the same bitmaps. In this scenario, where the VLAN is not a private VLAN, the ingress and egress VLAN bitmaps will both contain the same bit settings for regular VLANs. The uplink port bitmaps can be automatically generated by performing a merge or a union of the access port bitmaps. In one alternate embodiment, the administrator can explicitly configure the VLANs on the uplink ports.
Within the embodiments presented herein, the methodology for handling the packets correctly requires accuracy with the configuration stages of the bitmaps. In the ingress part, there is a check if the VLAN ID of the frame is supported by the port, and that check is performed against an Ingress bitmap. Within the forwarding part, there is a check whether the destination port supports the VID of the frame. This check is performed against the Egress bitmap. In the Egress part, a check is performed to determine whether or not to strip the frame's tag. This check is performed according to the strip bitmap.
Once the bitmaps and the corresponding PVID value are set correctly, the packet forwarding logic can process/verify the VLANs of a received packet and respond appropriately. The methodology for performing this verification and processing of packets provides an O(1) solution because each packet must be verified via three (3) substantially constant bitmaps and the solution is constant regardless of (i.e., is not depend on) the number of VLANs in the system. Also, the algorithm thus enables one to check whether the packet VLAN ID is set in (belongs to) a particular Bitmap is also a O(1) algorithm. FIGS. 8A and 8B illustrates two embodiments of methods by which certain of the described features of the O(1) algorithm are implemented by the executing firmware or software controlling the relevant port. While the method of FIG. 6 has been described as being implemented via execution of PBRS utility 343 within port controller 340, the present methods are completed via/with one or more of a port forwarding logic, which can be implemented via execution of port packet handling (PPH) utility 344 (FIG. 3 ). PPH utility 344 executes on one more processors (or virtual processors) of virtualization manager on the host system itself. The various processes can thus be described as being performed by the PPH utility 344 and/or by port forwarding logic, which may in turn be configured and/or instantiated by the network administrator. When initiated by the network administrator, the administrator can interact with the PRBS utility 343 via a command line interface (CLI) on the management console 315, in one embodiment. It is further appreciated that the functionality of the PPH utility 334 can be integrated with that of the PRBS utility 343 to form a single combined utility, which presents itself as an executable code segment and/or logic implemented within the ports of the DVS supporting one or more PVLANs.
To enable a better understanding of the methods of FIGS. 8A and 8B , reference is made to FIG. 9 , which illustrates components of a virtual port and DVS involved in the forwarding and processing of a packet detected on an ingress path and on an egress path of an example virtual port. As provided, DVS 900 comprises one or more port controller logic (port controller) 905, within which is maintained several components and utilities that enable and/or perform the various functions of the embodiments described herein. Port controller 905 comprises policy component 342 and PRBS utility 343. Additionally, port controller 905 comprises a plurality of sets of port VLAN arrays 340 a . . . n and associated PVIDs 345 a . . . n. As described herein, each set of port VLAN arrays (e.g., arrays 340 a) comprises three bitmap arrays, namely ingress bitmap array, egress bitmap array, and strip bitmap array. Port controller 905 also comprises port forwarding logic 910 (which can be generated via execution of the aforementioned PPH utility 344 (FIG. 3 ). Port forwarding logic connects to and interfaces with receiving interfaces 932 and 942 (or receiving queues 934 and 944, in an alternate embodiment) of ingress path 930 and egress path 940, respectively, of virtual port 920. In the illustrative embodiment, both ingress path 930 and egress path 940 comprise a receiving queue 934, 944 coupled to respective receiving interface 932, 942. Similarly, both paths (930, 940) comprise a transmit queue 936, 946 coupled to a respective transmit interface 938, 948. Packet processing logic 935, 945 are also provided within each path (930, 940). It is appreciated that packet processing logic 935, 945 can simply be an extension of port forwarding logic 910 abstracted to the location within the respective paths (930, 940) at which processing of the received packets occurs. Also, in one embodiment, the virtual port 920 can also maintain a copy of the port's port VLAN arrays 340 a and associated PVID 345 a.
Referring again to FIG. 8A , the method begins at block 802 at which an ingress packet handler for the source port is instantiated to handle a packet with a VLAN ID (VID). The VLAN ID is retrieved from the packet header when the port detects/receives the packet for processing. The PPH utility determines at block 804 whether the VID of the packet is set. In response to the VID of the packet not being set, the PPH utility tags the packet with the PVID of the source port (block 806). Once the VID of the packet is set or following the PPH utility tagging the packet with the PVID of the source port, the PPH utility determines at block 808 whether the source port's ingress bitmap supports the VID. If the source port ingress bitmap does not support the VID of the packet, the packet is dropped (block 810). However, in response to the source port's ingress bitmap supporting the VID, the PPH utility enables the source port to process the packet (block 812). At block 814, the PPH utility instantiates a forwarding function for the packet and determines the destination port for the packet. With the destination port identified, the PPH utility checks at block 816 whether the packet's VID is in the destination port's egress bitmap. In response to the packet VID not being in the destination port's egress bitmap, the PPH utility drops the packet (block 818). However, in response to the packet VID being in the destination port's egress bitmap, the PPH utility processes the packet on the destination port (block 820). At decision block 822, PPH utility checks whether the packet's VID is in the destination port's strip bitmap. In response to the packet's VID being in the destination port's strip bitmap, the PPH utility removes the VID from the packet (block 824). The PPH utility then completes processing the packet (block 826).
With reference now to FIG. 8B , there is provided a specific implementation of the method defined with reference also to the port forwarding logic of FIG. 9 . The method begins at block 830 and proceeds to block 832 which indicate the port forwarding logic 910 detecting an incoming transmission of a packet at a virtual port (e.g., port 920) of the DVS 900. The virtual port is assigned to enable routing of received packets to and from devices within one or more VLANs. Process block 834 then provides the port forwarding logic retrieving a VLAN ID (VID) from the header of the packet. The VLAN ID is a value assigned to uniquely identify the particular VLAN from other VLANs of a plurality of VLANs that can be supported by the first virtual port. Then, a determination is made at block 836 whether the packet is detected on the ingress path (versus the egress path) of the virtual port. Responsive to detecting the packet on an ingress path of the virtual port, the port forwarding logic 910 checks (at block 838) whether an ingress array offset position within an ingress bitmap array of the virtual port is set, which would indicate that the VLAN is supported by the port. The ingress array offset position corresponds to the value of the VID and is set within the ingress bitmap array during configuration of the VLAN on the port. Additionally, each virtual port further comprises a PVID VLAN ID, which indicates a VLAN tag that is added to untagged packets on the ingress path. The method process thus comprises: the port forwarding logic checking at block 840 whether a received packet does not have a PVID. In response to the received packet on the ingress path not having a PVID, the port forwarding logic 910 automatically tags the packet with the PVID of the virtual port (block 842). In response to the ingress array offset position being set and indicating the VLAN is supported by the port, the port forwarding logic 910 receives the packet at the port and initiates processing (via packet processing logic 935) of the received packet by the port (block 844). However, in response to the ingress array offset position not being set, the port forwarding logic 905 discards the packet (846). Thus, the detected packet on the ingress path is only allowed to be processed by the port when the VID identifies a VLAN that has a corresponding offset position in the ingress bitmap array set. Processing of the packet on the ingress path then ends and the next packets received at the port are similarly processed, which processing can be completed concurrently for efficiency.
Returning to decision block 836, responsive to detecting the packet transmission on an egress path 940 of the port (i.e., the packet is not detected on the ingress path 930), the port forwarding logic 910 checks (block 848) whether an egress array offset position within an egress bitmap array of the virtual port is set, which would indicates that the VLAN is supported by the port. The egress array offset position corresponds to the value of the VID and is set within the egress bitmap array during configuration of the VLAN on the port. In response to the egress array offset position being set and indicating the VLAN is supported by the port, the port forwarding logic 910 receives the packet at the port and initiates processing of the received packet by the port (block 850). In response to the egress array offset position not being set, the port forwarding logic 910 discards the packet (block 842). Again, the detected packet on the egress path is only allowed to be processed by the port when the VID identifies a VLAN that has a corresponding offset position in the egress bitmap array set.
For packets detected and/or received on the egress path, the method process further comprises the port forwarding logic 910 checking at block 852 whether a strip array offset position within a strip bitmap array of the virtual port is set, which would indicate that the VLAN is supported by the port and that the VID should be removed before the packet is forwarded. The strip array offset position corresponds to the value of the VID and is set within the strip bitmap array during configuration of the VLAN on the port. In response to the detected packet on the egress path having the PVID tagged thereto, the port forwarding logic automatically removes the PVID from the packet before forwarding the packet (block 858). Responsive to the strip array offset position being set, the port forwarding logic 910 removes the VID from the packet and forwards the packet without the VID to a destination device of the VLAN identified by the packet (block 856). Processing of the packet on the ingress path then ends and the next packets received at the port are similarly processed, which processing can be completed concurrently for efficiency.
The above described illustrative embodiments present a method for efficiently handling packets within virtual ports of a DVS supporting one or more PVLANs configured with community, isolated and promiscuous sub-domains. The method is performed within a host data processing system (host system) having a virtualization manager that configures and enables a virtualized computing environment. The virtualized computing environment includes one or more virtual machines and locally-accessible components of a layer 2 distributed virtual switch (DVS) including a plurality of virtual ports supporting packet transmission within at least one virtual local area network (VLAN). A processing resource of the virtualization manager executes code (e.g., the PPH utility 344) which generates processing logic (e.g., port forwarding logic 910) that performs the method.
In one embodiment of the method: each of the ingress bitmap array, egress bitmap array and strip bitmap array is a single dimension array comprising N bit entries, with each bit corresponding to an offset position from 0 through N−1, where N is an integer number representing a maximum number of individual VLANs that can be supported by the virtual port using globally unique identifiers (ID) ranging in value from 0 through N−1; an offset position in one of the ingress bitmap array, egress bitmap array and strip bitmap array is set when a value of that bit position in the respective bitmap array has a value of one (1); and the process of checking whether the offset position is set comprises comparing the value at that offset position to one (1) and indicating the offset position is set when the value is equal to one (1).
In one implementation, the virtual port can be an access port or an uplink port and each port comprises: an ingress VLAN bitmap containing set offset positions corresponding to VIDs of VLANs that are supported by the port in the ingress path to the port; an egress VLAN bitmap containing set offset positions corresponding to VIDs of VLANs that are supported by the port in the egress path to the port; and a strip VLAN bitmap containing set offset positions corresponding to VIDs identifying VLANS for which the VID is to be removed on the egress path before forwarding the received packet from the port.
In one embodiment, the method comprises: receiving a request (including but not limited to receiving the request via a command line interface (CLI) or a GUI) to add a new VLAN to the virtual port; assigning a globally unique ID to the new VLAN as a new VID; identifying an offset position in each of the bitmap arrays generated for the new VLAN, where the offset positions corresponds to a value of the new VID; updating the respective offset position within each of the bitmap arrays with a value indicating the association of the new VLAN, based on a type characteristic of the virtual port. The method further provides: associating properties to the new VLAN, based on received input from the CLI; and storing the properties of the new VLAN and instantiating the port to process packets to and from devices of the new VLAN, whose packet communication is supported by the port.
In one embodiment, the method further comprises: in response to receiving a request to add a new port to a PVLAN: assigning a unique Port VLAN ID (PVID) to the new port; autonomously generating an ingress bitmap array, an egress bitmap array, and a strip bitmap array for the new port; setting appropriate offset positions of each of the ingress bitmap array, the egress bitmap array, and the strip bitmap array corresponding to each VLAN and each PVLAN that are supported by the port; storing the ingress bitmap array, the egress bitmap array, and the strip bitmap array for use when processing packets received on the ingress path and the egress path of the new port; and storing the assigned PVID VLAN ID along with the bitmap arrays. Further, in one implementation, the autonomously generating and the setting of appropriate offset positions of each of the ingress bitmap array, the egress bitmap array, and the strip bitmap array comprises: identifying which one of an isolated sub-domain, a community sub-domain and a promiscuous sub-domain of a PVLAN the new port is associated with, where the isolated sub-domain has an isolated VLAN ID (VID), the community sub-domain has a community VID that is unique for that community sub-domain among multiple community sub-domains, and the promiscuous sub-domain shares the primary VLAN ID as the promiscuous VID. The method further provides: in response to the new port being associated with an isolated sub-domain, setting a bit value at an ingress offset position within the ingress bitmap array corresponding to the isolated VID, setting a bit value at an egress offset position within the egress bitmap array corresponding to the promiscuous VID, wherein the promiscuous VID is the same as the primary VLAN ID, and setting a bit value at a strip offset position within the strip bitmap corresponding to the promiscuous VID if the PVID of the new port is set to the isolated VID; in response to the new port being associated with a community sub-domain, setting an ingress offset position within the ingress bitmap array corresponding to the community VID, setting a first bit value at a first egress offset position within the egress bitmap array corresponding to the promiscuous VID and setting a second bit value at a second egress offset position within the egress bitmap array corresponding to the community VID, and setting both a first bit value at a first strip offset position and a second bit value at a second strip offset position within the strip bitmap corresponding respectively to the community VID and the promiscuous VID, if the PVID of the new port is set to the community VID; and in response to the new port being associated with a promiscuous sub-domain, setting an ingress offset position within the ingress bitmap array corresponding to the promiscuous VID, setting bit values at one or more egress offset positions within the egress bitmap array corresponding to VIDs of each community sub-domain, the isolated sub-domain and the primary domain in the PVLAN, and setting bit values at one or more egress offset positions within the egress bitmap array corresponding to VIDs of each community sub-domain, the isolated sub-domain and the primary domain in the PVLAN.
Additionally, the above embodiment provides: in response to the new port being associated with multiple PVLANs with each having a set of globally unique VIDs, the autonomously generating and the setting of appropriate offset positions of each of the ingress bitmap array, the egress bitmap array, and the strip bitmap array comprises: merging respective ones of each set of three bitmaps generated for each PVLAN into a single set of three combined bitmaps, wherein multiple ingress bitmap arrays are merged into a single combined ingress bitmap array, multiple egress bitmap arrays are merged into a single combined egress bitmap array, and multiple strip bitmap arrays are merged into a single combined strip bitmap array.
According to one implementation, in response to receipt of a request to add a VLAN to the DVS, the method comprises: generating the ingress bitmap array and the egress bitmap array with a same bit setting for access port bitmaps of non-private VLANs; and automatically generating an ingress bitmap and an egress bitmap for an uplink port by merging all of the egress bitmaps and ingress bitmaps that belong to the VLAN. In one embodiment, the VLAN bitmap of an uplink port can be generated by an alternate method that involves the following processes: (a) for the ingress bitmap, merge VLAN bitmaps of all access ports (ingress and egress) that are supported by the uplink port; for the egress bitmap, merge VLAN bitmaps of all access ports (ingress and egress) that are supported by the uplink port. Finally, the strip bitmap depends on the PVID assigned to the uplink port.
One embodiment of the invention provides a computer program product comprising: a computer readable storage medium; and program code on the computer readable medium that when executed by a processor associated with a virtualization manager executing on a data processing system to generate a virtualized computing environment having one or more distributed virtual switches (DVS), causes the virtualization manager to perform each of the above recited method functions.
Also, another embodiment of the invention provides a data processing system comprising: one or more processors providing processing resources; one or more memories coupled to the one or more processors; one or more network interfaces that enables communication with other devices via a physical network; and a virtualization manager that configures the data processing system as a virtualized machine having a distributed virtual switch (DVS) and one or more virtual machines that communicate within a virtual local area network (VLAN) via ports associated with the DVS within a virtualized environment, and wherein the virtualization manager comprises one or more executable utilities, including packet processing logic, that execute on a processing resource and causes the virtualization manager to: assign a globally unique VLAN identifier (ID) to each sub-domain of a PVLAN established within the virtualized environment on the host system; tag packets in the outbound path from and the inbound path to a virtual port of the DVS within the PVLAN with a correct VID; and dynamically validate a VID of a received packet on the inbound and the egress path to the virtual port by performing the various functions of the above described embodiments of the method.
Additionally, in one embodiment of the data processing system: the virtual port is one or more of an access port and an uplink port and each port comprises: an ingress VLAN bitmap containing set offset positions corresponding to VIDs of VLANs that are supported by the port in the ingress path to the port; an egress VLAN bitmap containing set offset positions corresponding to VIDs of VLANs that are supported by the port in the egress path to the port; and a strip VLAN bitmap containing set offset positions corresponding to VIDs identifying VLANS for which the VID is to be removed on the egress path before forwarding the received packet from the port; the VLAN is a private VLAN (PVLAN) and each virtual port further comprises a PVID VLAN ID, which indicates a VLAN tag that is added to untagged packets on the ingress path; multiple distributed virtual switches are supported by a same set of PVLANs, multiple PVLAN domains are provided within a single DVS, and PVLAN policies are uniformly enforced by packet handling logic of the virtualization manager; and the one or more executable utilities further causes the virtualization manager to: automatically tag the packet with the PVID of the virtual port, in response to the received packet on the ingress path not having a VID; and automatically remove the VID from the packet before forwarding the packet, in response to the detected packet on the egress path having the PVID tagged thereto.
The flowcharts and block diagrams in the various figures presented and described herein illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
In the flow charts above, one or more of the methods are embodied in a computer program product having a computer readable medium containing computer readable/program code/instructions such that a series of steps are performed when the computer readable/program code/instructions are executed (by a processing unit/processor) on a computing device/machine. In some implementations, certain processes of the methods are combined, performed simultaneously or in a different order, or perhaps omitted, without deviating from the spirit and scope of the invention. Thus, while the method processes are described and illustrated in a particular sequence, use of a specific sequence of processes is not meant to imply any limitations on the invention. Changes may be made with regards to the sequence of processes without departing from the spirit or scope of the present invention. Use of a particular sequence is therefore, not to be taken in a limiting sense, and the scope of the present invention extends to the appended claims and equivalents thereof.
As will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a system, method or computer program product. Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.
Any combination of one or more computer readable medium(s) may be utilized. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.
A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.
Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, R.F, etc., or any suitable combination of the foregoing. Computer program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
Aspects of the present invention are described below with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks. The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
As will be further appreciated, the processes in embodiments of the present invention may be implemented using any combination of software, firmware or hardware. As a preparatory step to practicing the invention in software, the programming code (whether software or firmware) will typically be stored in one or more machine readable storage mediums such as fixed (hard) drives, diskettes, optical disks, magnetic tape, semiconductor memories such as ROMs, PROMs, etc., thereby making an article of manufacture in accordance with the invention. The article of manufacture containing the programming code is used by either executing the code directly from the storage device, by copying the code from the storage device into another storage device such as a hard disk, RAM, etc., or by transmitting the code for remote execution using transmission type media such as digital and analog communication links. The methods of the invention may be practiced by combining one or more machine-readable storage devices containing the code according to the present invention with appropriate processing hardware to execute the code contained therein. An apparatus for practicing the invention could be one or more processing devices and storage systems containing or having network access to program(s) coded in accordance with the invention.
Thus, it is important that while an illustrative embodiment of the present invention is described in the context of a fully functional computer (server) system with installed (or executed) software, those skilled in the art will appreciate that the software aspects of an illustrative embodiment of the present invention are capable of being distributed as a program product in a variety of forms, and that an illustrative embodiment of the present invention applies equally regardless of the particular type of media used to actually carry out the distribution.
While the invention has been described with reference to exemplary embodiments, it will be understood by those skilled in the art that various changes may be made and equivalents may be substituted for elements thereof without departing from the scope of the invention. In addition, many modifications may be made to adapt a particular system, device or component thereof to the teachings of the invention without departing from the essential scope thereof. Therefore, it is intended that the invention not be limited to the particular embodiments disclosed for carrying out this invention, but that the invention will include all embodiments falling within the scope of the appended claims. Moreover, the use of the terms first, second, etc. do not denote any order or importance, but rather the terms first, second, etc. are used to distinguish one element from another.
The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
The corresponding structures, materials, acts, and equivalents of all means or step plus function elements in the claims below are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the invention. The embodiment was chosen and described in order to best explain the principles of the invention and the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.
Claims (20)
1. In a host data processing system having a virtualization manager that configures and enables a virtualized computing environment that includes one or more virtual machines and locally-accessible components of a layer 2 distributed virtual switch (DVS) including a plurality of virtual ports supporting packet transmission within at least one virtual local area network (VLAN), a processing resource of the virtualization manager executing packet processing logic of the virtualization manager to perform a method comprising:
detecting an incoming transmission of a packet at an ingress receiving interface of an ingress path to a first virtual port of the plurality of virtual ports of the layer 2 DVS, wherein the first virtual port is assigned to enable routing of received packets to and from one or more devices within one or more VLANs;
retrieving a VLAN identifier (VID) from a header of the packet, wherein the VID comprises a value that is used to uniquely identify a particular VLAN from among a plurality of VLANs supported by the first virtual port; and
in response to detecting the packet on the ingress path to the first virtual port:
determining whether an ingress array offset position within an ingress bitmap array of the first virtual port is set, indicating that the particular VLAN is supported by the first virtual port, and wherein the ingress array offset position corresponds to the value of the VID and is set within the ingress bitmap array during configuration of the VLAN on the first virtual port;
in response to the ingress array offset position is set, receiving the packet at the first virtual port and initiating processing of the received packet by the first virtual port; and
in response to the ingress array offset position not being set, discarding the packet;
wherein a detected packet on the ingress path is only allowed to be processed by the first virtual port when a VID within a header of the detected packet identifies a VLAN from among the plurality of VLANs that has a corresponding offset position within the ingress bitmap array that is set.
2. The method of claim 1 , further comprising in response to detecting the packet transmission at an egress receiving interface of an egress path to the first virtual port:
determining whether an egress array offset position within an egress bitmap array of the first virtual port is set, indicating that the VLAN is supported by the first virtual port, wherein the egress array offset position corresponds to the VID and is set within the egress bitmap array during configuration of the VLAN on the first virtual port;
in response to determining the egress array offset position is set, receiving the packet at the first virtual port and initiating processing of the received packet by the first virtual port; and
in response to the egress array offset position not being set, discarding the packet;
wherein a detected packet on the egress path is only allowed to be processed by the first virtual port when the VID identifies a VLAN that has a corresponding offset position in the egress bitmap array set.
3. The method of claim 2 , further comprising:
checking whether a strip array offset position within a strip bitmap array of the first virtual port is set, wherein the strip bitmap array when set indicates that the VLAN is supported by the first virtual port and that the VID should be removed before the packet is forwarded, and wherein the strip array offset position corresponds to the value of the VID and is set within the strip bitmap array during configuration of the VLAN on the first virtual port; and
in response to the strip array offset position being set, removing the VID from the packet and forwarding the packet without the VID to a destination device of the VLAN identified by the packet.
4. The method of claim 3 , wherein:
each of the ingress bitmap array, the egress bitmap array, and the strip bitmap array is a single dimension array comprising N bit entries, with each bit corresponding to an offset position from 0 through N−1, where N is an integer number representing a maximum number of individual VLANs that can be supported by the first virtual port using globally unique identifiers (ID) ranging in value from 0 through N−1;
an offset position in one of the ingress bitmap array, the egress bitmap array, and the strip bitmap array is set when a value of a bit position in the respective bitmap array has a value of one (1); and
the checking whether the offset position is set further comprises comparing the value at that offset position to one (1) and indicating the offset position is set when the value is equal to one (1).
5. The method of claim 3 , wherein the first virtual port is one or more of an access port and an uplink port and each virtual port of the plurality of virtual ports comprises:
an ingress VLAN bitmap containing set offset positions corresponding to VIDs of VLANs that are supported by the virtual port in the ingress path to the virtual port;
an egress VLAN bitmap containing set offset positions corresponding to VIDs of VLANs that are supported by the virtual port in the egress path to the virtual port; and
a strip VLAN bitmap containing set offset positions corresponding to VIDs identifying VLANS for which the VID is to be removed on the egress path to the virtual port before forwarding the received packet from that virtual port.
6. The method of claim 5 , wherein the VLAN is a private VLAN (PVLAN), and wherein each virtual port further comprises a port VLAN identifier (PVID) which indicates a VLAN tag that is added to untagged packets on the ingress path, the method further comprising:
in response to the received packet on the ingress path not having a PVID, automatically tagging the packet with the PVID of the first virtual port; and
in response to the detected packet on the egress path having the PVID tagged thereto, automatically removing the PVID from the packet before forwarding the packet.
7. The method of claim 3 , further comprising:
receiving a request to add a new VLAN to the first virtual port;
assigning a globally unique ID to the new VLAN as a new VID;
identifying an offset position in each of the bitmap arrays generated for the new VLAN, wherein the offset position corresponds to a new value of the new VID;
based on a type characteristic of the first virtual port, updating the respective offset position within each of the bitmap arrays to indicate the association of the new VLAN.
8. The method of claim 7 , further comprising:
associating one or more properties to the new VLAN based on an input received from the CLI;
storing the properties of the new VLAN and instantiating the first virtual port to process packets to and from one or more devices on the new VLAN.
9. The method of claim 1 , further comprising:
in response to receiving a request to add a new port to a private VLAN (PVLAN):
assigning a unique port VLAN identifier (PVID) to the new port;
autonomously generating an ingress bitmap array, an egress bitmap array, and a strip bitmap array for the new port;
setting appropriate offset positions of each of the ingress bitmap array, the egress bitmap array, and the strip bitmap array corresponding to each VLAN and each PVLAN that is supported by the new port;
storing the ingress bitmap array, the egress bitmap array, and the strip bitmap array for use when processing packets received on the ingress path and the egress path of the new port; and
storing the assigned PVID along with the bitmap arrays.
10. The method of claim 9 , wherein the autonomously generating and the setting of appropriate offset positions of each of the ingress bitmap array, the egress bitmap array, and the strip bitmap array further comprises:
identifying which one of an isolated sub-domain, a community sub-domain and a promiscuous sub-domain of the PVLAN the new port is associated with, wherein the isolated sub-domain has an isolated VID, the community sub-domain, has a community VID that is unique for that community sub-domain among multiple community sub-domains, and the promiscuous sub-domain shares a primary VID as the promiscuous VID;
in response to the new port being associated with the isolated sub-domain:
setting a bit value at an ingress offset position within the ingress bitmap array corresponding to the isolated VIDA;
setting a bit value at an egress offset position within the egress bitmap array corresponding to the promiscuous VID, wherein the promiscuous VID is the same as the primary VID; and
setting a bit value at a strip offset position within the strip bitmap corresponding to the promiscuous VID if the PVID of the new port is set to the isolated VID;
in response to the new port being associated with a community sub-domain:
setting an ingress offset position within the ingress bitmap array corresponding to the community VID;
setting a first bit value at a first egress offset position within the egress bitmap array corresponding to the promiscuous VID;
setting a second bit value at a second egress offset position within the egress bitmap array corresponding to the community VIDA; and
setting both a first bit value at a first strip offset position and a second bit value at a second strip offset position within the strip bitmap corresponding respectively to the community VID and the promiscuous VID, if the PVID of the new port is set to the community VID; and
in response to the new port being associated with a promiscuous sub-domain:
setting an ingress offset position within the ingress bitmap array corresponding to the promiscuous VID;
setting bit values at one or more egress offset positions within the egress bitmap array corresponding to VIDs of each community sub-domain, the isolated sub-domain and the primary domain in the PVLAN; and
setting bit values at one or more egress offset positions within the egress bitmap array corresponding to VIDs of each community sub-domain, the isolated sub-domain and the primary domain in the PVLAN.
11. The method of claim 9 , wherein in response to the new port being associated with multiple PVLANs with each having at least one globally unique VID, the autonomously generating and the setting of appropriate offset positions of each of the ingress bitmap array, the egress bitmap array, and the strip bitmap array further comprises:
merging respective ones of each set of three bitmaps generated for each PVLAN into a single set of three combined bitmaps, wherein multiple ingress bitmap arrays are merged into a single combined ingress bitmap array, multiple egress bitmap arrays are merged into a single combined egress bitmap array, and multiple strip bitmap arrays are merged into a single combined strip bitmap array.
12. The method of claim 9 , the method further comprising:
in response to receipt of a command line interface request to add a non-private VLAN to the layer 2 DVS:
generating the ingress bitmap array and the egress bitmap array with a same bit setting for access port bitmaps of non-private VLANs; and
automatically generating an uplink port ingress bitmap and an uplink port egress bitmap by merging all the access port bitmaps (ingress and egress) of the VLAN.
13. In a host data processing system having a virtualization manager that configures and enables a virtualized computing environment that includes one or more virtual machines and locally-accessible components of a layer 2 distributed virtual switch (DVS) including a plurality of virtual ports supporting packet transmission within at least one virtual local area network (VLAN), a processing resource of the virtualization manager performing a method comprising:
generating a set of port VLAN bitmaps in response to receiving a request to assign one of a VLAN and a private VLAN (PVLAN) to a port of the plurality of virtual ports;
storing the set of port VLAN bitmaps along with a port VLAN identifier (ID) (PVID); and
in response to detection of a packet traversing on one of an ingress path to the port and an egress path to the port:
checking a VID of the packet;
setting and matching the VID of the packet to the set of port VLAN bitmaps for the port; and
enabling packet transmission when the VID matches within the set of port VLAN bitmaps, wherein packet ingress can be completed for the source port using an ingress bitmap, and wherein the packet egress can be completed for the destination port using an Egress bitmap and Strip bitmap of the destination port.
14. The method of claim 2 , wherein:
the egress path comprises the egress receiving interface, one or more egress receiving queues coupled to the egress receiving interface, an egress packet processing logic, and one or more egress transmit queues that are coupled to an egress transmit interface; and
the ingress path comprises the ingress receiving interface, one or more ingress receiving queues coupled to the ingress receiving interface, an ingress packet processing logic, and one or more ingress transmit queues that are coupled to an ingress transmit interface.
15. The method of claim 1 , wherein:
each virtual port of the plurality of virtual ports comprises a set of bitmap arrays, located within a virtualization manager, that are specific to that virtual port; and
the set of bitmap arrays comprise each of an ingress bitmap array, an egress bitmap array, and a strip bitmap array.
16. The method of claim 15 , wherein:
the ingress bitmap array identifies a first one or more VLANs that an associated virtual port supports in the ingress path;
the egress bitmap array identifies a second one or more VLANs that the associated virtual port supports in the egress path; and
strip VLAN bitmap array identifies a third one or more VLANs that are removed before traffic from the third one or more VLANs is sent to the associated virtual port.
17. The method of claim 1 , wherein:
the layer 2 DVS provides a logical view of a plurality of physical switches across one or more hypervisors; and
the layer 2 DVS is communicatively coupled to the one or more virtual machines and a plurality of network interface cards.
18. The method of claim 17 , wherein the layer 2 DVS extends across a plurality of subnets, and wherein the layer 2 DVS shares hardware with a second layer 2 DVS.
19. The host data processing system of claim 13 , wherein:
each virtual port of the plurality of virtual ports comprises a set of bitmap arrays, located within a virtualization manager, that are specific to that virtual port;
the set of bitmap arrays comprise each of an ingress bitmap array, an egress bitmap array, and a strip bitmap array, wherein the ingress bitmap array identifies a first one or more VLANs that an associated virtual port supports in the ingress path, wherein the egress bitmap array identifies a second one or more VLANs that the associated virtual port supports in the egress path, and wherein strip VLAN bitmap array identifies a third one or more VLANs that are removed before traffic from the third one or more VLANs is sent to the associated virtual port;
the egress path comprises the egress receiving interface, one or more egress receiving queues coupled to the egress receiving interface, an egress packet processing logic, and one or more egress transmit queues that are coupled to an egress transmit interface; and
the ingress path comprises the ingress receiving interface, one or more ingress receiving queues coupled to the ingress receiving interface, an ingress packet processing logic, and one or more ingress transmit queues that are coupled to an ingress transmit interface.
20. The host data processing system of claim 13 , wherein the layer 2 DVS:
provides a logical view of a plurality of physical switches across one or more hypervisors;
is communicatively coupled to the one or more virtual machines and a plurality of network interface cards;
extends across a plurality of subnets; and
shares hardware with a second layer 2 DVS.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/621,219 US8824485B2 (en) | 2011-05-13 | 2012-09-15 | Efficient software-based private VLAN solution for distributed virtual switches |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/107,554 US8670450B2 (en) | 2011-05-13 | 2011-05-13 | Efficient software-based private VLAN solution for distributed virtual switches |
US13/621,219 US8824485B2 (en) | 2011-05-13 | 2012-09-15 | Efficient software-based private VLAN solution for distributed virtual switches |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/107,554 Continuation US8670450B2 (en) | 2011-05-13 | 2011-05-13 | Efficient software-based private VLAN solution for distributed virtual switches |
Publications (2)
Publication Number | Publication Date |
---|---|
US20130010799A1 US20130010799A1 (en) | 2013-01-10 |
US8824485B2 true US8824485B2 (en) | 2014-09-02 |
Family
ID=47125370
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/107,554 Expired - Fee Related US8670450B2 (en) | 2011-05-13 | 2011-05-13 | Efficient software-based private VLAN solution for distributed virtual switches |
US13/621,219 Expired - Fee Related US8824485B2 (en) | 2011-05-13 | 2012-09-15 | Efficient software-based private VLAN solution for distributed virtual switches |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/107,554 Expired - Fee Related US8670450B2 (en) | 2011-05-13 | 2011-05-13 | Efficient software-based private VLAN solution for distributed virtual switches |
Country Status (2)
Country | Link |
---|---|
US (2) | US8670450B2 (en) |
CN (1) | CN102780608B (en) |
Cited By (32)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20120096211A1 (en) * | 2009-10-30 | 2012-04-19 | Calxeda, Inc. | Performance and power optimized computer system architectures and methods leveraging power optimized tree fabric interconnect |
US20140254373A1 (en) * | 2013-03-08 | 2014-09-11 | Tellabs Operations, Inc. | Method and Apparatus for Improving LTE Enhanced Packet Core Architecture Using Openflow Network Controller |
US20140280738A1 (en) * | 2013-03-15 | 2014-09-18 | Rackspace Us, Inc. | Software-defined multinetwork bridge |
US9008079B2 (en) | 2009-10-30 | 2015-04-14 | Iii Holdings 2, Llc | System and method for high-performance, low-power data center interconnect fabric |
US9054990B2 (en) | 2009-10-30 | 2015-06-09 | Iii Holdings 2, Llc | System and method for data center security enhancements leveraging server SOCs or server fabrics |
US9059922B2 (en) | 2011-10-06 | 2015-06-16 | International Business Machines Corporation | Network traffic distribution |
US9069929B2 (en) | 2011-10-31 | 2015-06-30 | Iii Holdings 2, Llc | Arbitrating usage of serial port in node card of scalable and modular servers |
US9077654B2 (en) | 2009-10-30 | 2015-07-07 | Iii Holdings 2, Llc | System and method for data center security enhancements leveraging managed server SOCs |
US20150295730A1 (en) * | 2013-02-20 | 2015-10-15 | Fujitsu Limited | Switch and setting method |
US9311269B2 (en) | 2009-10-30 | 2016-04-12 | Iii Holdings 2, Llc | Network proxy for high-performance, low-power data center interconnect fabric |
US20160269318A1 (en) * | 2015-03-11 | 2016-09-15 | Vmware, Inc. | Network bandwidth reservations for system traffic and virtual computing instances |
US9465771B2 (en) | 2009-09-24 | 2016-10-11 | Iii Holdings 2, Llc | Server on a chip and node cards comprising one or more of same |
US9585281B2 (en) | 2011-10-28 | 2017-02-28 | Iii Holdings 2, Llc | System and method for flexible storage and networking provisioning in large scalable processor installations |
US9648102B1 (en) | 2012-12-27 | 2017-05-09 | Iii Holdings 2, Llc | Memcached server functionality in a cluster of data processing nodes |
US9680770B2 (en) | 2009-10-30 | 2017-06-13 | Iii Holdings 2, Llc | System and method for using a multi-protocol fabric module across a distributed server interconnect fabric |
US10140245B2 (en) | 2009-10-30 | 2018-11-27 | Iii Holdings 2, Llc | Memcached server functionality in a cluster of data processing nodes |
US10877695B2 (en) | 2009-10-30 | 2020-12-29 | Iii Holdings 2, Llc | Memcached server functionality in a cluster of data processing nodes |
US11467883B2 (en) | 2004-03-13 | 2022-10-11 | Iii Holdings 12, Llc | Co-allocating a reservation spanning different compute resources types |
US11496415B2 (en) | 2005-04-07 | 2022-11-08 | Iii Holdings 12, Llc | On-demand access to compute resources |
US11494235B2 (en) | 2004-11-08 | 2022-11-08 | Iii Holdings 12, Llc | System and method of providing system jobs within a compute environment |
US11522952B2 (en) | 2007-09-24 | 2022-12-06 | The Research Foundation For The State University Of New York | Automatic clustering for self-organizing grids |
US11630704B2 (en) | 2004-08-20 | 2023-04-18 | Iii Holdings 12, Llc | System and method for a workload management and scheduling module to manage access to a compute environment according to local and non-local user identity information |
US11641321B2 (en) | 2010-07-06 | 2023-05-02 | Nicira, Inc. | Packet processing for logical datapath sets |
US11650857B2 (en) | 2006-03-16 | 2023-05-16 | Iii Holdings 12, Llc | System and method for managing a hybrid computer environment |
US11652706B2 (en) | 2004-06-18 | 2023-05-16 | Iii Holdings 12, Llc | System and method for providing dynamic provisioning within a compute environment |
US11658916B2 (en) | 2005-03-16 | 2023-05-23 | Iii Holdings 12, Llc | Simple integration of an on-demand compute environment |
US11720290B2 (en) | 2009-10-30 | 2023-08-08 | Iii Holdings 2, Llc | Memcached server functionality in a cluster of data processing nodes |
US11743123B2 (en) * | 2010-07-06 | 2023-08-29 | Nicira, Inc. | Managed switch architectures: software managed switches, hardware managed switches, and heterogeneous managed switches |
US11882030B1 (en) * | 2022-09-14 | 2024-01-23 | Realtek Semiconductor Corporation | Network packet transmission device and network packet transmission method thereof |
US11960937B2 (en) | 2004-03-13 | 2024-04-16 | Iii Holdings 12, Llc | System and method for an optimizing reservation in time of compute resources based on prioritization function and reservation policy parameter |
US12068979B2 (en) * | 2020-05-01 | 2024-08-20 | EMC IP Holding Company, LLC | System and method for dividing a physical ethernet port |
US12120040B2 (en) | 2005-03-16 | 2024-10-15 | Iii Holdings 12, Llc | On-demand compute environment |
Families Citing this family (58)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8619771B2 (en) | 2009-09-30 | 2013-12-31 | Vmware, Inc. | Private allocated networks over shared communications infrastructure |
US8195774B2 (en) | 2008-05-23 | 2012-06-05 | Vmware, Inc. | Distributed virtual switch for virtualized computer systems |
US20110252208A1 (en) * | 2010-04-12 | 2011-10-13 | Microsoft Corporation | Express-full backup of a cluster shared virtual machine |
JP5720324B2 (en) * | 2011-03-11 | 2015-05-20 | 日本電気株式会社 | Thin client environment providing system, server, thin client environment management method, and thin client environment management program |
US8837499B2 (en) | 2011-05-14 | 2014-09-16 | International Business Machines Corporation | Distributed fabric protocol (DFP) switching network architecture |
US9363207B2 (en) * | 2011-06-24 | 2016-06-07 | Cisco Technology, Inc. | Private virtual local area network isolation |
US20130034015A1 (en) * | 2011-08-05 | 2013-02-07 | International Business Machines Corporation | Automated network configuration in a dynamic virtual environment |
US8767529B2 (en) | 2011-09-12 | 2014-07-01 | International Business Machines Corporation | High availability distributed fabric protocol (DFP) switching network architecture |
JP5747997B2 (en) * | 2011-10-28 | 2015-07-15 | 日本電気株式会社 | Control device, communication system, virtual network management method and program |
US9036636B1 (en) * | 2012-02-06 | 2015-05-19 | Big Switch Networks, Inc. | System and methods for managing network packet broadcasting |
US9264295B1 (en) | 2012-03-02 | 2016-02-16 | Big Switch Networks, Inc. | Systems and methods for forwarding broadcast network packets with a controller |
US10103980B1 (en) * | 2012-03-14 | 2018-10-16 | Juniper Networks, Inc. | Methods and apparatus for maintaining an integrated routing and bridging interface |
WO2013138977A1 (en) * | 2012-03-19 | 2013-09-26 | Intel Corporation | Techniques for packet management in an input/output virtualization system |
US9331872B2 (en) * | 2012-05-22 | 2016-05-03 | Cisco Technology, Inc. | Implementing PVLANs in a large-scale distributed virtual switch |
US8958340B2 (en) * | 2012-06-15 | 2015-02-17 | Dell Products L.P. | System and methods for open fabric management |
CN103001953B (en) * | 2012-11-21 | 2015-09-09 | 北京航空航天大学 | Virtual machine network resource allocation methods and device |
CN103051529B (en) * | 2012-12-20 | 2016-03-30 | 华为技术有限公司 | A kind of processing method of message and device |
CN103152256B (en) * | 2013-02-22 | 2017-05-03 | 浪潮电子信息产业股份有限公司 | Virtual routing network design method based on cloud computing data center |
CN104022960B (en) * | 2013-02-28 | 2017-05-31 | 新华三技术有限公司 | Method and apparatus based on OpenFlow protocol realizations PVLAN |
JP6079426B2 (en) * | 2013-05-16 | 2017-02-15 | 富士通株式会社 | Information processing system, method, apparatus, and program |
US9749231B2 (en) * | 2013-07-02 | 2017-08-29 | Arista Networks, Inc. | Method and system for overlay routing with VXLAN on bare metal servers |
CN104348757B (en) * | 2013-07-31 | 2018-03-16 | 华为技术有限公司 | A kind of flow table exchange method, interchanger and system |
EP3017641B1 (en) * | 2013-11-12 | 2019-10-02 | Huawei Technologies Co., Ltd. | System and method for high efficiency wireless local area network communications |
CN104660506B (en) * | 2013-11-22 | 2018-12-25 | 华为技术有限公司 | A kind of method, apparatus and system of data packet forwarding |
US9612854B2 (en) * | 2013-12-18 | 2017-04-04 | Telefonaktiebolaget Lm Ericsson (Publ) | System and method for virtualizing a remote device |
CN104883325B (en) | 2014-02-27 | 2018-02-06 | 国际商业机器公司 | PVLAN interchangers and its method for being connected to non-PVLANs device |
CN103812752B (en) * | 2014-03-03 | 2018-10-09 | 国家电网公司 | In a kind of power telecom network between VLAN resource-sharing method |
US9509527B2 (en) * | 2014-06-30 | 2016-11-29 | Arista Networks, Inc. | Method and system for VXLAN encapsulation offload |
CN104092684B (en) * | 2014-07-07 | 2017-10-03 | 新华三技术有限公司 | A kind of OpenFlow agreements support VPN method and apparatus |
US10015023B2 (en) * | 2014-09-08 | 2018-07-03 | Quanta Computer Inc. | High-bandwidth chassis and rack management by VLAN |
US9838337B1 (en) * | 2014-09-30 | 2017-12-05 | Juniper Networks, Inc. | Automatic virtual local area network (VLAN) provisioning in data center switches |
WO2016122570A1 (en) * | 2015-01-30 | 2016-08-04 | Hewlett Packard Enterprise Development Lp | Sending information in a network controlled by a controller |
US9813323B2 (en) * | 2015-02-10 | 2017-11-07 | Big Switch Networks, Inc. | Systems and methods for controlling switches to capture and monitor network traffic |
CN104753820B (en) * | 2015-03-24 | 2019-06-14 | 福建星网锐捷网络有限公司 | Method, equipment and the interchanger of the asymmetric forwarding of Business Stream in aggregated links |
US10747564B2 (en) * | 2015-04-02 | 2020-08-18 | Vmware, Inc. | Spanned distributed virtual switch |
EP3300318B1 (en) * | 2015-06-30 | 2021-06-23 | Huawei Technologies Co., Ltd. | Methods for communicating by using remote network element port, and apparatuses |
CN105939309B (en) * | 2015-07-28 | 2019-08-06 | 杭州迪普科技股份有限公司 | A kind of virtual machine partition method and device |
CN105407082A (en) * | 2015-10-23 | 2016-03-16 | 上海斐讯数据通信技术有限公司 | Host isolation apparatus in VLAN and method thereof |
CN105376231A (en) * | 2015-11-18 | 2016-03-02 | 浪潮(北京)电子信息产业有限公司 | Method and device for realizing service isolation |
CN105592089B (en) * | 2015-12-29 | 2018-11-27 | 中国银联股份有限公司 | A kind of tenant security isolation method under cloud computing |
US9846602B2 (en) * | 2016-02-12 | 2017-12-19 | International Business Machines Corporation | Migration of a logical partition or virtual machine with inactive input/output hosting server |
CN109074330B (en) | 2016-08-03 | 2020-12-08 | 华为技术有限公司 | Network interface card, computing device, and data packet processing method |
CN112217747A (en) | 2016-08-03 | 2021-01-12 | 华为技术有限公司 | Network interface card, computing device, and data packet processing method |
US10554494B1 (en) | 2017-01-04 | 2020-02-04 | Juniper Networks, Inc. | Automatic ICCP provisioning and VLAN provisioning on an inter-chassis link in a MC-LAG |
CN106685788B (en) * | 2017-01-10 | 2019-10-11 | 盛科网络(苏州)有限公司 | The chip implementing method of PVLAN under stacking mode |
CN106685789B (en) * | 2017-01-13 | 2019-10-08 | 盛科网络(苏州)有限公司 | The chip implementing method of PVLAN under stacking mode |
US10666606B2 (en) * | 2017-06-28 | 2020-05-26 | Amazon Technologies, Inc. | Virtual private network service endpoints |
US10587510B2 (en) | 2017-12-01 | 2020-03-10 | International Business Machines Corporation | Network function virtualization using tagged access ports |
US11245644B2 (en) * | 2018-01-19 | 2022-02-08 | Super Micro Computer, Inc. | Automatic multi-chassis link aggregation configuration |
CN109302466B (en) * | 2018-09-18 | 2021-10-26 | 华为技术有限公司 | Data processing method, related device and computer storage medium |
US11494212B2 (en) * | 2018-09-27 | 2022-11-08 | Intel Corporation | Technologies for adaptive platform resource assignment |
US10880124B2 (en) | 2018-12-28 | 2020-12-29 | Alibaba Group Holding Limited | Offload controller control of programmable switch |
CN109905336B (en) * | 2019-03-13 | 2021-04-16 | 武汉星耀科技有限公司 | SuperVLAN implementation method and system of distributed virtual switch |
US11295135B2 (en) * | 2020-05-29 | 2022-04-05 | Corning Research & Development Corporation | Asset tracking of communication equipment via mixed reality based labeling |
US11374808B2 (en) | 2020-05-29 | 2022-06-28 | Corning Research & Development Corporation | Automated logging of patching operations via mixed reality based labeling |
KR20220133716A (en) * | 2021-03-25 | 2022-10-05 | 삼성전자주식회사 | Apparatus and method for building virtual enterprise network |
CN113703789B (en) * | 2021-08-04 | 2024-07-26 | 德邦证券股份有限公司 | Method, device and storage medium for deploying micro-service program |
CN115604167A (en) * | 2022-08-25 | 2023-01-13 | 紫光云技术有限公司(Cn) | Public cloud mac address learning optimization method |
Citations (106)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5394402A (en) | 1993-06-17 | 1995-02-28 | Ascom Timeplex Trading Ag | Hub for segmented virtual local area network with shared media access |
US5515359A (en) | 1994-08-26 | 1996-05-07 | Mitsubishi Electric Research Laboratories, Inc. | Credit enhanced proportional rate control system |
US5617421A (en) | 1994-06-17 | 1997-04-01 | Cisco Systems, Inc. | Extended domain computer network using standard links |
US5633859A (en) | 1994-09-16 | 1997-05-27 | The Ohio State University | Method and apparatus for congestion management in computer networks using explicit rate indication |
US5633861A (en) | 1994-12-19 | 1997-05-27 | Alcatel Data Networks Inc. | Traffic management and congestion control for packet-based networks |
US5742604A (en) | 1996-03-28 | 1998-04-21 | Cisco Systems, Inc. | Interswitch link mechanism for connecting high-performance network switches |
EP0853405A3 (en) | 1997-01-06 | 1998-09-16 | Digital Equipment Corporation | Ethernet network with credit based flow control |
US5893320A (en) | 1997-05-20 | 1999-04-13 | Demaree; Michael S. | Device for cooking fowl |
US6147970A (en) | 1997-09-30 | 2000-11-14 | Gte Internetworking Incorporated | Quality of service management for aggregated flows in a network system |
US6304901B1 (en) | 1996-01-02 | 2001-10-16 | Cisco Technology, Inc. | Multiple VLAN architecture system |
US6347337B1 (en) | 1999-01-08 | 2002-02-12 | Intel Corporation | Credit based flow control scheme over virtual interface architecture for system area networks |
US20020191628A1 (en) | 2001-06-12 | 2002-12-19 | Actue Communications Corporation | Apparatus for multicast forwarding in a virtual local area network environment |
US6567403B1 (en) | 1998-04-30 | 2003-05-20 | Hewlett-Packard Development Company, L.P. | Virtual-chassis switch network topology |
US20030185206A1 (en) | 2002-03-29 | 2003-10-02 | Bhaskar Jayakrishnan | Destination device bit map for delivering an information packet through a switch fabric |
US6646985B1 (en) | 1999-06-03 | 2003-11-11 | Fujitsu Network Communications, Inc. | Congestion control mechanism in a network access device |
US20040031030A1 (en) | 2000-05-20 | 2004-02-12 | Equipe Communications Corporation | Signatures for facilitating hot upgrades of modular software components |
US20040088451A1 (en) | 2002-11-01 | 2004-05-06 | Samsung Electronics Co., Ltd. | Device and method for controlling packet flow |
US20040243663A1 (en) | 2003-04-08 | 2004-12-02 | Johanson Bradley E. | Event heap: a coordination infrastructure for dynamic heterogeneous application interactions in ubiquitous computing environments |
US20040255288A1 (en) | 2003-05-27 | 2004-12-16 | Shinya Hashimoto | Software update processor, system, method, program for the same, and recording medium with the program recorded therein |
US6839768B2 (en) | 1997-06-13 | 2005-01-04 | At&T Corp. | Startup management system and method for rate-based flow and congestion control within a network |
US20050047334A1 (en) | 2001-06-13 | 2005-03-03 | Paul Harry V. | Fibre channel switch |
US6901452B1 (en) | 2000-03-02 | 2005-05-31 | Alcatel | Selectable prioritization for data communication switch |
US20060029072A1 (en) | 2003-10-14 | 2006-02-09 | Raptor Networks Technology, Inc. | Switching system for virtual LANs |
US7035220B1 (en) | 2001-10-22 | 2006-04-25 | Intel Corporation | Technique for providing end-to-end congestion control with no feedback from a lossless network |
US20060251067A1 (en) | 2004-10-22 | 2006-11-09 | Cisco Technology, Inc., A Corporation Of California | Fibre channel over ethernet |
CN1897567A (en) | 2005-07-15 | 2007-01-17 | 华为技术有限公司 | Method for improving transmission reliability in virtual exchange system |
US7173934B2 (en) | 2001-09-10 | 2007-02-06 | Nortel Networks Limited | System, device, and method for improving communication network reliability using trunk splitting |
US20070036178A1 (en) | 2005-02-02 | 2007-02-15 | Susan Hares | Layer 2 virtual switching environment |
US7263060B1 (en) | 2001-06-28 | 2007-08-28 | Network Appliance, Inc. | Multiple switch protected architecture |
CN101030959A (en) | 2006-02-27 | 2007-09-05 | 中兴通讯股份有限公司 | Telecommunication for determining realtime Ethernet transmission |
US20070263640A1 (en) | 2006-05-10 | 2007-11-15 | Finn Norman W | Technique for efficiently managing bandwidth for multipoint-to-multipoint services in a provider network |
US20080205377A1 (en) | 2007-02-22 | 2008-08-28 | Blade Network Technologies, Inc. | System and methods for providing server virtualization assistance |
US20080225712A1 (en) | 2007-03-13 | 2008-09-18 | Lange Andrew S | Policy enforcement points |
US20080228897A1 (en) | 2007-03-12 | 2008-09-18 | Ko Michael A | Layering serial attached small computer system interface (sas) over ethernet |
US7483370B1 (en) | 2003-12-22 | 2009-01-27 | Extreme Networks, Inc. | Methods and systems for hitless switch management module failover and upgrade |
US7508763B2 (en) | 2003-09-04 | 2009-03-24 | Hewlett-Packard Development Company, L.P. | Method to regulate traffic congestion in a network |
US20090129385A1 (en) | 2004-09-17 | 2009-05-21 | Hewlett-Packard Development Company, L. P. | Virtual network interface |
US7561517B2 (en) | 2001-11-02 | 2009-07-14 | Internap Network Services Corporation | Passive route control of data networks |
US20090185571A1 (en) | 2008-01-23 | 2009-07-23 | Francois Edouard Tallet | Translating mst instances between ports of a bridge in a computer network |
US20090213869A1 (en) | 2008-02-26 | 2009-08-27 | Saravanakumar Rajendran | Blade switch |
US7593320B1 (en) | 2004-04-30 | 2009-09-22 | Marvell International, Ltd. | Failover scheme for stackable network switches |
US20090252038A1 (en) | 2004-10-22 | 2009-10-08 | Cisco Technology, Inc. | Fibre channel over ethernet |
US7668966B2 (en) | 2001-11-02 | 2010-02-23 | Internap Network Services Corporation | Data network controller |
US20100054129A1 (en) | 2008-08-27 | 2010-03-04 | Cisco Technology, Inc. | Virtual switch quality of service for virtual machines |
US20100054260A1 (en) | 2008-08-28 | 2010-03-04 | Blade Network Technologies, Inc. | Method and Apparatus to Switch Packets between Virtual Ports |
US20100097926A1 (en) | 2008-10-21 | 2010-04-22 | Liquid Computing Corporation | Methods and systems for providing network access redundancy |
US20100158024A1 (en) | 2008-12-23 | 2010-06-24 | Ali Sajassi | Optimized forwarding for provider backbone bridges with both i&b components (ib-pbb) |
US20100183011A1 (en) | 2007-06-11 | 2010-07-22 | Blade Network Technologies, Inc. | Sequential frame forwarding |
CN101087238B (en) | 2003-10-21 | 2010-08-04 | 华为技术有限公司 | Dynamic bandwidth allocation device and method of passive optical network |
US20100223397A1 (en) | 2009-02-27 | 2010-09-02 | Uri Elzur | Method and system for virtual machine networking |
US20100226368A1 (en) | 2009-03-06 | 2010-09-09 | Futurewei Technologies, Inc. | Transport Multiplexer - Mechanisms to Force Ethernet Traffic From One Domain to Be Switched in a Different (External) Domain |
US20100246388A1 (en) | 2009-03-26 | 2010-09-30 | Brocade Communications Systems, Inc. | Redundant host connection in a routed network |
US20100257263A1 (en) * | 2009-04-01 | 2010-10-07 | Nicira Networks, Inc. | Method and apparatus for implementing and managing virtual switches |
US20100265824A1 (en) | 2007-11-09 | 2010-10-21 | Blade Network Technologies, Inc | Session-less Load Balancing of Client Traffic Across Servers in a Server Group |
US7830793B2 (en) | 2004-10-22 | 2010-11-09 | Cisco Technology, Inc. | Network device architecture for consolidating input/output and reducing latency |
US7839777B2 (en) | 2007-09-27 | 2010-11-23 | International Business Machines Corporation | Method, system, and apparatus for accelerating resolution of network congestion |
US20100303075A1 (en) | 2009-05-29 | 2010-12-02 | Sun Microsystems, Inc. | Managing traffic on virtualized lanes between a network switch and a virtual machine |
US7848226B2 (en) | 2007-03-28 | 2010-12-07 | Fujitsu Limited | Communication system, switch |
US20110007746A1 (en) | 2009-07-10 | 2011-01-13 | Jayaram Mudigonda | Establishing Network Quality of Service for a Virtual Machine |
US20110019678A1 (en) | 2009-07-24 | 2011-01-27 | Juniper Networks, Inc. | Routing frames in a shortest path computer network for a multi-homed legacy bridge node |
US20110026527A1 (en) | 2007-06-11 | 2011-02-03 | Blade Network Technologies, Inc. | Tag-based interface between a switching device and servers for use in frame processing and forwarding |
US20110026403A1 (en) | 2007-11-09 | 2011-02-03 | Blade Network Technologies, Inc | Traffic management of client traffic at ingress location of a data center |
US20110035494A1 (en) | 2008-04-15 | 2011-02-10 | Blade Network Technologies | Network virtualization for a virtualized server data center environment |
US20110032944A1 (en) | 2009-08-06 | 2011-02-10 | Uri Elzur | Method and System for Switching in a Virtualized Platform |
US7912003B2 (en) | 2007-06-27 | 2011-03-22 | Microsoft Corporation | Multipath forwarding algorithms using network coding |
US20110103389A1 (en) | 2009-11-03 | 2011-05-05 | Blade Network Technologies, Inc. | Method and apparatus for switching traffic between virtual machines |
US20110134793A1 (en) | 2009-12-03 | 2011-06-09 | Christian Elsen | Preventing loops on network topologies built with virtual switches and vms |
US7974223B2 (en) | 2004-11-19 | 2011-07-05 | Corrigent Systems Ltd. | Virtual private LAN service over ring networks |
US20110235523A1 (en) | 2010-03-24 | 2011-09-29 | Brocade Communications Systems, Inc. | Method and system for extending routing domain to non-routing end stations |
US20110280572A1 (en) | 2010-05-11 | 2011-11-17 | Brocade Communications Systems, Inc. | Converged network extension |
US20110299406A1 (en) | 2010-06-02 | 2011-12-08 | Brocade Communications Systems, Inc. | Path detection in trill networks |
US20110299532A1 (en) | 2010-06-08 | 2011-12-08 | Brocade Communications Systems, Inc. | Remote port mirroring |
US20110299533A1 (en) | 2010-06-08 | 2011-12-08 | Brocade Communications Systems, Inc. | Internal virtual network identifier and internal policy identifier |
US20110299536A1 (en) | 2010-06-08 | 2011-12-08 | Brocade Communications Systems, Inc. | Method and system for link aggregation across multiple switches |
US20110299409A1 (en) | 2010-06-02 | 2011-12-08 | Brocade Communications Systems, Inc. | Reachability detection in trill networks |
US8085657B2 (en) | 2005-04-01 | 2011-12-27 | Sony Corporation | Flow control in a cellular communication system |
US20120014387A1 (en) | 2010-05-28 | 2012-01-19 | Futurewei Technologies, Inc. | Virtual Layer 2 and Mechanism to Make it Scalable |
US20120014261A1 (en) | 2010-07-14 | 2012-01-19 | Cisco Technology, Inc. | Monitoring A Flow Set To Detect Faults |
US20120027017A1 (en) | 2010-07-30 | 2012-02-02 | Cisco Technology, Inc. | Multi-destination forwarding in network clouds which include emulated switches |
US20120033541A1 (en) | 2010-08-04 | 2012-02-09 | Alcatel-Lucent Usa Inc. | System and method for transport control protocol in a multi-chassis domain |
US8139358B2 (en) | 2007-09-25 | 2012-03-20 | International Business Machines Corporation | Apparatus for externally changing the direction of air flowing through electronic equipment |
US20120117228A1 (en) | 2010-11-09 | 2012-05-10 | International Business Machines Corporation | Dynamic traffic management in a data center |
US20120131662A1 (en) * | 2010-11-23 | 2012-05-24 | Cisco Technology, Inc. | Virtual local area networks in a virtual machine environment |
US8194534B2 (en) | 2005-02-28 | 2012-06-05 | International Business Machines Corporation | Blade server system with at least one rack-switch having multiple switches interconnected and configured for management and operation as a single virtual switch |
US8194674B1 (en) * | 2007-12-20 | 2012-06-05 | Quest Software, Inc. | System and method for aggregating communications and for translating between overlapping internal network addresses and unique external network addresses |
US8204061B1 (en) | 2009-07-23 | 2012-06-19 | Cisco Technology, Inc. | Virtual port channel switches with distributed control planes |
US20120163164A1 (en) | 2010-12-27 | 2012-06-28 | Brocade Communications Systems, Inc. | Method and system for remote load balancing in high-availability networks |
US20120177045A1 (en) | 2011-01-07 | 2012-07-12 | Berman Stuart B | Methods, systems and apparatus for the interconnection of fibre channel over ethernet devices using a trill network |
US20120226866A1 (en) | 2011-03-02 | 2012-09-06 | International Business Machines Corporation | Dynamic migration of virtual machines based on workload cache demand profiling |
US8265075B2 (en) | 2009-03-16 | 2012-09-11 | International Business Machines Corporation | Method and apparatus for managing, configuring, and controlling an I/O virtualization device through a network switch |
US20120228780A1 (en) | 2011-03-08 | 2012-09-13 | Ji Hwang Kim | Semiconductor device and method of manufacturing the same |
US8271680B2 (en) | 1998-12-24 | 2012-09-18 | Ericsson Ab | Domain isolation through virtual network machines |
US20120243544A1 (en) | 2011-03-21 | 2012-09-27 | Avaya Inc. | Usage of masked bmac addresses in a provider backbone bridged (pbb) network |
US20120243539A1 (en) | 2011-03-21 | 2012-09-27 | Avaya Inc. | Usage of masked ethernet addresses between transparent interconnect of lots of links (trill) routing bridges |
US20120287939A1 (en) | 2011-05-14 | 2012-11-15 | International Business Machines Corporation | Distributed fabric protocol (dfp) switching network architecture |
US20120287787A1 (en) | 2011-05-14 | 2012-11-15 | International Business Machines Corporation | Priority based flow control in a distributed fabric protocol (dfp) switching network architecture |
US8325598B2 (en) | 2009-05-20 | 2012-12-04 | Verizon Patent And Licensing Inc. | Automatic protection switching of virtual connections |
US20120320749A1 (en) | 2011-05-14 | 2012-12-20 | International Business Machines Corporation | Data traffic handling in a distributed fabric protocol (dfp) switching network architecture |
US8345697B2 (en) | 2010-08-17 | 2013-01-01 | Dell Products, Lp | System and method for carrying path information |
US20130051235A1 (en) | 2011-08-29 | 2013-02-28 | Brocade Communications Systems, Inc. | End-to-end lossless ethernet in ethernet fabric |
US20130064067A1 (en) | 2011-09-12 | 2013-03-14 | International Business Machines Corporation | High availability distributed fabric protocol (dfp) switching network architecture |
US8406128B1 (en) | 2010-06-29 | 2013-03-26 | Amazon Technologies, Inc. | Efficient highly connected data centers |
US8498284B2 (en) | 2007-02-02 | 2013-07-30 | Interdigital Technology Corporation | Method and apparatus for enhancing RLC for flexible RLC PDU size |
US8498299B2 (en) | 2010-08-19 | 2013-07-30 | Juniper Networks, Inc. | Flooding-based routing protocol having average-rate and burst-rate control |
US8514857B2 (en) * | 2009-10-27 | 2013-08-20 | Electronics And Telecommunications Research Institute | Virtualization-supporting programmable platform device and method of transferring packet |
US8625427B1 (en) | 2009-09-03 | 2014-01-07 | Brocade Communications Systems, Inc. | Multi-path switching with edge-to-edge flow control |
Family Cites Families (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN100454890C (en) * | 2004-04-01 | 2009-01-21 | 华为技术有限公司 | Data exchange method based on virtual local area network |
CN100382541C (en) * | 2005-09-13 | 2008-04-16 | 中兴通讯股份有限公司 | Virtual circuit exchanging method based on MAC studying |
-
2011
- 2011-05-13 US US13/107,554 patent/US8670450B2/en not_active Expired - Fee Related
-
2012
- 2012-05-11 CN CN201210145615.4A patent/CN102780608B/en not_active Expired - Fee Related
- 2012-09-15 US US13/621,219 patent/US8824485B2/en not_active Expired - Fee Related
Patent Citations (110)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5394402A (en) | 1993-06-17 | 1995-02-28 | Ascom Timeplex Trading Ag | Hub for segmented virtual local area network with shared media access |
US5617421A (en) | 1994-06-17 | 1997-04-01 | Cisco Systems, Inc. | Extended domain computer network using standard links |
US5515359A (en) | 1994-08-26 | 1996-05-07 | Mitsubishi Electric Research Laboratories, Inc. | Credit enhanced proportional rate control system |
US5633859A (en) | 1994-09-16 | 1997-05-27 | The Ohio State University | Method and apparatus for congestion management in computer networks using explicit rate indication |
US5633861A (en) | 1994-12-19 | 1997-05-27 | Alcatel Data Networks Inc. | Traffic management and congestion control for packet-based networks |
US6304901B1 (en) | 1996-01-02 | 2001-10-16 | Cisco Technology, Inc. | Multiple VLAN architecture system |
US5742604A (en) | 1996-03-28 | 1998-04-21 | Cisco Systems, Inc. | Interswitch link mechanism for connecting high-performance network switches |
EP0853405A3 (en) | 1997-01-06 | 1998-09-16 | Digital Equipment Corporation | Ethernet network with credit based flow control |
US5893320A (en) | 1997-05-20 | 1999-04-13 | Demaree; Michael S. | Device for cooking fowl |
US6839768B2 (en) | 1997-06-13 | 2005-01-04 | At&T Corp. | Startup management system and method for rate-based flow and congestion control within a network |
US6147970A (en) | 1997-09-30 | 2000-11-14 | Gte Internetworking Incorporated | Quality of service management for aggregated flows in a network system |
US6567403B1 (en) | 1998-04-30 | 2003-05-20 | Hewlett-Packard Development Company, L.P. | Virtual-chassis switch network topology |
US8271680B2 (en) | 1998-12-24 | 2012-09-18 | Ericsson Ab | Domain isolation through virtual network machines |
US6347337B1 (en) | 1999-01-08 | 2002-02-12 | Intel Corporation | Credit based flow control scheme over virtual interface architecture for system area networks |
US6646985B1 (en) | 1999-06-03 | 2003-11-11 | Fujitsu Network Communications, Inc. | Congestion control mechanism in a network access device |
US6901452B1 (en) | 2000-03-02 | 2005-05-31 | Alcatel | Selectable prioritization for data communication switch |
US20040031030A1 (en) | 2000-05-20 | 2004-02-12 | Equipe Communications Corporation | Signatures for facilitating hot upgrades of modular software components |
US20020191628A1 (en) | 2001-06-12 | 2002-12-19 | Actue Communications Corporation | Apparatus for multicast forwarding in a virtual local area network environment |
US20050047334A1 (en) | 2001-06-13 | 2005-03-03 | Paul Harry V. | Fibre channel switch |
US7263060B1 (en) | 2001-06-28 | 2007-08-28 | Network Appliance, Inc. | Multiple switch protected architecture |
US7173934B2 (en) | 2001-09-10 | 2007-02-06 | Nortel Networks Limited | System, device, and method for improving communication network reliability using trunk splitting |
US7035220B1 (en) | 2001-10-22 | 2006-04-25 | Intel Corporation | Technique for providing end-to-end congestion control with no feedback from a lossless network |
US7668966B2 (en) | 2001-11-02 | 2010-02-23 | Internap Network Services Corporation | Data network controller |
US7561517B2 (en) | 2001-11-02 | 2009-07-14 | Internap Network Services Corporation | Passive route control of data networks |
US20030185206A1 (en) | 2002-03-29 | 2003-10-02 | Bhaskar Jayakrishnan | Destination device bit map for delivering an information packet through a switch fabric |
US20040088451A1 (en) | 2002-11-01 | 2004-05-06 | Samsung Electronics Co., Ltd. | Device and method for controlling packet flow |
US20040243663A1 (en) | 2003-04-08 | 2004-12-02 | Johanson Bradley E. | Event heap: a coordination infrastructure for dynamic heterogeneous application interactions in ubiquitous computing environments |
US20040255288A1 (en) | 2003-05-27 | 2004-12-16 | Shinya Hashimoto | Software update processor, system, method, program for the same, and recording medium with the program recorded therein |
US7508763B2 (en) | 2003-09-04 | 2009-03-24 | Hewlett-Packard Development Company, L.P. | Method to regulate traffic congestion in a network |
US20060029072A1 (en) | 2003-10-14 | 2006-02-09 | Raptor Networks Technology, Inc. | Switching system for virtual LANs |
CN101087238B (en) | 2003-10-21 | 2010-08-04 | 华为技术有限公司 | Dynamic bandwidth allocation device and method of passive optical network |
US7483370B1 (en) | 2003-12-22 | 2009-01-27 | Extreme Networks, Inc. | Methods and systems for hitless switch management module failover and upgrade |
US7593320B1 (en) | 2004-04-30 | 2009-09-22 | Marvell International, Ltd. | Failover scheme for stackable network switches |
US20090129385A1 (en) | 2004-09-17 | 2009-05-21 | Hewlett-Packard Development Company, L. P. | Virtual network interface |
US8213429B2 (en) | 2004-09-17 | 2012-07-03 | Hewlett-Packard Development Company, L.P. | Virtual network interface |
US20060251067A1 (en) | 2004-10-22 | 2006-11-09 | Cisco Technology, Inc., A Corporation Of California | Fibre channel over ethernet |
US7830793B2 (en) | 2004-10-22 | 2010-11-09 | Cisco Technology, Inc. | Network device architecture for consolidating input/output and reducing latency |
US20090252038A1 (en) | 2004-10-22 | 2009-10-08 | Cisco Technology, Inc. | Fibre channel over ethernet |
US7974223B2 (en) | 2004-11-19 | 2011-07-05 | Corrigent Systems Ltd. | Virtual private LAN service over ring networks |
US20070036178A1 (en) | 2005-02-02 | 2007-02-15 | Susan Hares | Layer 2 virtual switching environment |
US8194534B2 (en) | 2005-02-28 | 2012-06-05 | International Business Machines Corporation | Blade server system with at least one rack-switch having multiple switches interconnected and configured for management and operation as a single virtual switch |
US8085657B2 (en) | 2005-04-01 | 2011-12-27 | Sony Corporation | Flow control in a cellular communication system |
CN1897567A (en) | 2005-07-15 | 2007-01-17 | 华为技术有限公司 | Method for improving transmission reliability in virtual exchange system |
CN101030959A (en) | 2006-02-27 | 2007-09-05 | 中兴通讯股份有限公司 | Telecommunication for determining realtime Ethernet transmission |
US20070263640A1 (en) | 2006-05-10 | 2007-11-15 | Finn Norman W | Technique for efficiently managing bandwidth for multipoint-to-multipoint services in a provider network |
US8498284B2 (en) | 2007-02-02 | 2013-07-30 | Interdigital Technology Corporation | Method and apparatus for enhancing RLC for flexible RLC PDU size |
US20080205377A1 (en) | 2007-02-22 | 2008-08-28 | Blade Network Technologies, Inc. | System and methods for providing server virtualization assistance |
US20080228897A1 (en) | 2007-03-12 | 2008-09-18 | Ko Michael A | Layering serial attached small computer system interface (sas) over ethernet |
US20080225712A1 (en) | 2007-03-13 | 2008-09-18 | Lange Andrew S | Policy enforcement points |
US7848226B2 (en) | 2007-03-28 | 2010-12-07 | Fujitsu Limited | Communication system, switch |
US20100183011A1 (en) | 2007-06-11 | 2010-07-22 | Blade Network Technologies, Inc. | Sequential frame forwarding |
US20110026527A1 (en) | 2007-06-11 | 2011-02-03 | Blade Network Technologies, Inc. | Tag-based interface between a switching device and servers for use in frame processing and forwarding |
US7912003B2 (en) | 2007-06-27 | 2011-03-22 | Microsoft Corporation | Multipath forwarding algorithms using network coding |
US8139358B2 (en) | 2007-09-25 | 2012-03-20 | International Business Machines Corporation | Apparatus for externally changing the direction of air flowing through electronic equipment |
US7839777B2 (en) | 2007-09-27 | 2010-11-23 | International Business Machines Corporation | Method, system, and apparatus for accelerating resolution of network congestion |
US20100265824A1 (en) | 2007-11-09 | 2010-10-21 | Blade Network Technologies, Inc | Session-less Load Balancing of Client Traffic Across Servers in a Server Group |
US20110026403A1 (en) | 2007-11-09 | 2011-02-03 | Blade Network Technologies, Inc | Traffic management of client traffic at ingress location of a data center |
US8194674B1 (en) * | 2007-12-20 | 2012-06-05 | Quest Software, Inc. | System and method for aggregating communications and for translating between overlapping internal network addresses and unique external network addresses |
US20090185571A1 (en) | 2008-01-23 | 2009-07-23 | Francois Edouard Tallet | Translating mst instances between ports of a bridge in a computer network |
US20090213869A1 (en) | 2008-02-26 | 2009-08-27 | Saravanakumar Rajendran | Blade switch |
US20110035494A1 (en) | 2008-04-15 | 2011-02-10 | Blade Network Technologies | Network virtualization for a virtualized server data center environment |
US20100054129A1 (en) | 2008-08-27 | 2010-03-04 | Cisco Technology, Inc. | Virtual switch quality of service for virtual machines |
US20100054260A1 (en) | 2008-08-28 | 2010-03-04 | Blade Network Technologies, Inc. | Method and Apparatus to Switch Packets between Virtual Ports |
US20100097926A1 (en) | 2008-10-21 | 2010-04-22 | Liquid Computing Corporation | Methods and systems for providing network access redundancy |
US20100158024A1 (en) | 2008-12-23 | 2010-06-24 | Ali Sajassi | Optimized forwarding for provider backbone bridges with both i&b components (ib-pbb) |
US20100223397A1 (en) | 2009-02-27 | 2010-09-02 | Uri Elzur | Method and system for virtual machine networking |
US20100226368A1 (en) | 2009-03-06 | 2010-09-09 | Futurewei Technologies, Inc. | Transport Multiplexer - Mechanisms to Force Ethernet Traffic From One Domain to Be Switched in a Different (External) Domain |
US8265075B2 (en) | 2009-03-16 | 2012-09-11 | International Business Machines Corporation | Method and apparatus for managing, configuring, and controlling an I/O virtualization device through a network switch |
US20100246388A1 (en) | 2009-03-26 | 2010-09-30 | Brocade Communications Systems, Inc. | Redundant host connection in a routed network |
US20100257263A1 (en) * | 2009-04-01 | 2010-10-07 | Nicira Networks, Inc. | Method and apparatus for implementing and managing virtual switches |
US8325598B2 (en) | 2009-05-20 | 2012-12-04 | Verizon Patent And Licensing Inc. | Automatic protection switching of virtual connections |
US20100303075A1 (en) | 2009-05-29 | 2010-12-02 | Sun Microsystems, Inc. | Managing traffic on virtualized lanes between a network switch and a virtual machine |
US20110007746A1 (en) | 2009-07-10 | 2011-01-13 | Jayaram Mudigonda | Establishing Network Quality of Service for a Virtual Machine |
US8204061B1 (en) | 2009-07-23 | 2012-06-19 | Cisco Technology, Inc. | Virtual port channel switches with distributed control planes |
US20110019678A1 (en) | 2009-07-24 | 2011-01-27 | Juniper Networks, Inc. | Routing frames in a shortest path computer network for a multi-homed legacy bridge node |
US20110032944A1 (en) | 2009-08-06 | 2011-02-10 | Uri Elzur | Method and System for Switching in a Virtualized Platform |
US8625427B1 (en) | 2009-09-03 | 2014-01-07 | Brocade Communications Systems, Inc. | Multi-path switching with edge-to-edge flow control |
US8514857B2 (en) * | 2009-10-27 | 2013-08-20 | Electronics And Telecommunications Research Institute | Virtualization-supporting programmable platform device and method of transferring packet |
US20110103389A1 (en) | 2009-11-03 | 2011-05-05 | Blade Network Technologies, Inc. | Method and apparatus for switching traffic between virtual machines |
US20110134793A1 (en) | 2009-12-03 | 2011-06-09 | Christian Elsen | Preventing loops on network topologies built with virtual switches and vms |
US20110235523A1 (en) | 2010-03-24 | 2011-09-29 | Brocade Communications Systems, Inc. | Method and system for extending routing domain to non-routing end stations |
US20110280572A1 (en) | 2010-05-11 | 2011-11-17 | Brocade Communications Systems, Inc. | Converged network extension |
US20120014387A1 (en) | 2010-05-28 | 2012-01-19 | Futurewei Technologies, Inc. | Virtual Layer 2 and Mechanism to Make it Scalable |
US20110299409A1 (en) | 2010-06-02 | 2011-12-08 | Brocade Communications Systems, Inc. | Reachability detection in trill networks |
US20110299406A1 (en) | 2010-06-02 | 2011-12-08 | Brocade Communications Systems, Inc. | Path detection in trill networks |
US20110299532A1 (en) | 2010-06-08 | 2011-12-08 | Brocade Communications Systems, Inc. | Remote port mirroring |
US20110299533A1 (en) | 2010-06-08 | 2011-12-08 | Brocade Communications Systems, Inc. | Internal virtual network identifier and internal policy identifier |
US20110299536A1 (en) | 2010-06-08 | 2011-12-08 | Brocade Communications Systems, Inc. | Method and system for link aggregation across multiple switches |
US8406128B1 (en) | 2010-06-29 | 2013-03-26 | Amazon Technologies, Inc. | Efficient highly connected data centers |
US20120014261A1 (en) | 2010-07-14 | 2012-01-19 | Cisco Technology, Inc. | Monitoring A Flow Set To Detect Faults |
US20120027017A1 (en) | 2010-07-30 | 2012-02-02 | Cisco Technology, Inc. | Multi-destination forwarding in network clouds which include emulated switches |
US20120033541A1 (en) | 2010-08-04 | 2012-02-09 | Alcatel-Lucent Usa Inc. | System and method for transport control protocol in a multi-chassis domain |
US8345697B2 (en) | 2010-08-17 | 2013-01-01 | Dell Products, Lp | System and method for carrying path information |
US8498299B2 (en) | 2010-08-19 | 2013-07-30 | Juniper Networks, Inc. | Flooding-based routing protocol having average-rate and burst-rate control |
US20120117228A1 (en) | 2010-11-09 | 2012-05-10 | International Business Machines Corporation | Dynamic traffic management in a data center |
US20120131662A1 (en) * | 2010-11-23 | 2012-05-24 | Cisco Technology, Inc. | Virtual local area networks in a virtual machine environment |
US20120163164A1 (en) | 2010-12-27 | 2012-06-28 | Brocade Communications Systems, Inc. | Method and system for remote load balancing in high-availability networks |
US20120177045A1 (en) | 2011-01-07 | 2012-07-12 | Berman Stuart B | Methods, systems and apparatus for the interconnection of fibre channel over ethernet devices using a trill network |
US20120226866A1 (en) | 2011-03-02 | 2012-09-06 | International Business Machines Corporation | Dynamic migration of virtual machines based on workload cache demand profiling |
US20120228780A1 (en) | 2011-03-08 | 2012-09-13 | Ji Hwang Kim | Semiconductor device and method of manufacturing the same |
US20120243539A1 (en) | 2011-03-21 | 2012-09-27 | Avaya Inc. | Usage of masked ethernet addresses between transparent interconnect of lots of links (trill) routing bridges |
US20120243544A1 (en) | 2011-03-21 | 2012-09-27 | Avaya Inc. | Usage of masked bmac addresses in a provider backbone bridged (pbb) network |
US20130022050A1 (en) | 2011-05-14 | 2013-01-24 | International Business Machines Corporation | Distributed fabric protocol (dfp) switching network architecture |
US20120287939A1 (en) | 2011-05-14 | 2012-11-15 | International Business Machines Corporation | Distributed fabric protocol (dfp) switching network architecture |
US20120320749A1 (en) | 2011-05-14 | 2012-12-20 | International Business Machines Corporation | Data traffic handling in a distributed fabric protocol (dfp) switching network architecture |
US20120287786A1 (en) | 2011-05-14 | 2012-11-15 | International Business Machines Corporation | Priority based flow control in a distributed fabric protocol (dfp) switching network architecture |
US20120287787A1 (en) | 2011-05-14 | 2012-11-15 | International Business Machines Corporation | Priority based flow control in a distributed fabric protocol (dfp) switching network architecture |
US20130051235A1 (en) | 2011-08-29 | 2013-02-28 | Brocade Communications Systems, Inc. | End-to-end lossless ethernet in ethernet fabric |
US20130064067A1 (en) | 2011-09-12 | 2013-03-14 | International Business Machines Corporation | High availability distributed fabric protocol (dfp) switching network architecture |
US20130064068A1 (en) | 2011-09-12 | 2013-03-14 | International Business Machines Corporation | High availability distributed fabric protocol (dfp) switching network architecture |
Non-Patent Citations (92)
Title |
---|
Brocade, "BCEFE in a Nutshell First Edition", Global Education Services Rev. 0111, pp. 1-70, Copyright 2011, Brocade Communications Systems, Inc. |
Cisco Systems Inc., "Cisco FabricPath Overview", pp. 1-20, Copyright 2009. |
D.E. Eastlake, "Rbridges and the IETF TRILL Protocol", pp. 1-39, TRILL Protocol, Dec. 2009. |
De-Leon, "Flow Control for Gigabit", Digital Equipment Corporation (Digital), IEEE 802.3z Task Force, Jul. 9, 1996. |
Dobre, Multi-Architecture Operating Systems, pp. 1-82, Oct. 4, 2004. |
Guha et al., ShutUp: End-to-End Containment of Unwanted Traffic, pp. 1-14, (2008). |
Hunter et al., BladeCenter, IBM Journal of Research and Development, vol. 49, No. 6, p. 905. Nov. 2005. |
Int'l Searching Authority; Int. Appln. PCT/IB2012/051803; Int'l Search Report dated Sep. 13, 2012 (7 pg.). |
Jo et al., "Internet Traffic Load Balancing using Dynamic Hashing with Flow Volume", Conference Title: Internet Performance and Control of Network Systems III, Boston, MA pp. 1-12, Jul. 30, 2002. |
Kandula, et al., "Dynamic Load Balancing Without Packet Reordering", ACM SIGCOMM Computer Communication Review, vol. 37, No. 2, pp. 53-62, Apr. 2007. |
Kinds, et al., "Advanced Network Monitoring Brings Life to the Awareness Plane", IBM Research Spyros Denazis, Univ. of Patras Benoit Claise, Cisco Systems, IEEE Communications Magazine, pp. 1-7, Oct. 2008. |
Leu, Dar-Ren, "dLAG-DMLT over TRILL", BLADE Network Technologies, pp. 1-20, Copyright 2009. |
Manral, et al., "Rbridges: Bidirectional Forwarding Detection (BFD) support for TRILL draft-manral-trill-bfd-encaps-01", pp. 1-10, Trill Working Group Internet-Draft, Mar. 13, 2011. |
Martin, et al., "Accuracy and Dynamics of Multi-Stage Load Balancing for Multipath Internet Routing", Institute of Computer Science, Univ. of Wurzburg Am Hubland, Germany, IEEE Int'l Conference on Communications (ICC) Glasgow, UK, pp. 1-8, Jun. 2007. |
Papadopoulos et al.,"NPACI Rocks: Tools and Techniques for Easily Deploying Manageable Linux Clusters", The San Diego Supercomputer Center, University of California San Diego, La Jolla, CA 92093-0505-Issue Date: 2001, Date of Current Version: Aug. 7, 2002. |
Perla, "Profiling User Activities on Guest OSes in a Virtual Machine Environment." (2008). |
Perlman, et al., "Rbridges: Base Protocol Specification", pp. 1-117, TRILL Working Group Internet-Draft, Mar. 3, 2010. |
Pettit et al., Virtual Switching in an Era of Advanced Edges, pp. 1-7, Nicira Networks, Palo Alto, California. Version date Jul. 2010. |
Pfaff et al., Extending Networking into the Virtualization Layer, pp. 1-6, Oct. 2009, Proceedings of the 8th ACM Workshop on Hot Topics in Networks (HotNets-VIII), New York City, New York. |
Posted by Mike Fratto, "Cisco's FabricPath and IETF TRILL: Cisco Can't Have Standards Both Ways", Dec. 17, 2010; http://www.networkcomputing.com/data-networking-management/229500205. |
Recio et al., Automated Ethernet Virtual Bridging, pp. 1-11, IBM 2009. |
Rouiller, Virtual Lan Security: weaknesses and countermeasures, pp. 1-49, GIAC Security Essentials Practical Assignment Version 1.4b (2006). |
Ruth et al., Virtual Distributed Environments in a Shared Infrastructure, pp. 63-69, IEEE Computer Society, May 2005. |
Schlansker, et al., "High-Performance Ethernet-Based Communications for Future Multi-Core Processors", Proceedings of the 2007 ACM/IEEE conference on Supercomputing, Nov. 10-16, 2007. |
Schueler et al., "TCP-Splitter: A TCP/IP Flow Monitor in Reconfigurable Hardware", Appl. Res. Lab., Washington Univ. pp. 54-59, Feb. 19, 2003. |
Sherwood et al., FlowVisor: A Network Virtualization Layer, pp. 1-14, Oct. 14, 2009, Deutsche Telekom Inc. R&D Lab, Stanford University, Nicira Networks. |
Shi et al., Architectural Support for High Speed Protection of Memory Integrity and Confidentiality in Multiprocessor Systems, pp. 1-12, Proceedings of the 13th International Conference on Parallel Architecture and Compilation Techniques (2004). |
Skyrme et al., Exploring Lua for Concurrent Programming, pp. 3556-3572, Journal of Universal Computer Science, vol. 14, No. 21 (2008), submitted: Apr. 16, 2008, accepted: Jun. 5, 2008, appeared: Dec. 1, 2008. |
Soule, et al., "Traffic Matrices: Balancing Measurements, Interference and Modeling", vol. 33, Issue: 1, Publisher: ACM, pp. 362-373, Year 2005. |
Sproull et al., "Control and Configuration Software for a Reconfigurable Networking Hardware Platform", Applied Research Laboratory, Washington University, Saint Louis, MO 63130; pp. 1-10 (or 45-54)-Issue Date: 2002, Date of Current Version: Jan. 6, 2003. |
Tolmie, "HIPPI-6400-Designing for speed", 12th Annual Int'l Symposium on High Performance Computing Systems and Applications (HPCSt98), May 20-22, 1998. |
U.S. Appl. No. 13/107,397, Final Office Action Dated May 29, 2013. |
U.S. Appl. No. 13/107,397, Non-Final Office Action Dated Jan. 4, 2013. |
U.S. Appl. No. 13/107,433, Final Office Action Dated Jul. 10, 2013. |
U.S. Appl. No. 13/107,433, Non-Final Office Action Dated Jan. 28, 2013. |
U.S. Appl. No. 13/107,554 entitled "Efficient Software-Based Private VLAN Solution for Distributed Virtual Switches"; Non-final office action dated Jan. 8, 2013. (19 pg.). |
U.S. Appl. No. 13/107,554, Final Office Action Dated Jul. 3, 2013. |
U.S. Appl. No. 13/107,554, Non-Final Office Action Dated Jan. 8, 2013. |
U.S. Appl. No. 13/107,554, Notice of Allowance Dated Oct. 18, 2013. |
U.S. Appl. No. 13/107,893, Non-Final Office Action Dated Apr. 1, 2013. |
U.S. Appl. No. 13/107,893, Notice of Allowance Dated Jul. 10, 2013. |
U.S. Appl. No. 13/107,894, Final Office Action Dated Nov. 1, 2013. |
U.S. Appl. No. 13/107,894, Non-Final Office Action Dated Jun. 20, 2013. |
U.S. Appl. No. 13/107,894, Notice of Allowance Dated Feb. 19, 2014. |
U.S. Appl. No. 13/107,894, Notice of Allowance Dated Jan. 10, 2014. |
U.S. Appl. No. 13/107,896, Non-Final Office Action Dated Mar. 7, 2013. |
U.S. Appl. No. 13/107,896, Notice of Allowance Dated Jul. 29, 2013. |
U.S. Appl. No. 13/107,903, Final Office Action Dated Jul. 19, 2013. |
U.S. Appl. No. 13/107,903, Non-Final Office Action Dated Feb. 22, 2013. |
U.S. Appl. No. 13/107,903, Notice of Allowance Dated Sep. 11, 2013. |
U.S. Appl. No. 13/107,985, Non-Final Office Action Dated Feb. 28, 2013. |
U.S. Appl. No. 13/107,985, Notice of Allowance Dated Jul. 18, 2013. |
U.S. Appl. No. 13/229,867, Non-Final Office Action Dated May 24, 2013. |
U.S. Appl. No. 13/229,867, Notice of Allowance Dated Dec. 30, 2013. |
U.S. Appl. No. 13/229,891, Final Office Action Dated Nov. 21, 2013. |
U.S. Appl. No. 13/229,891, Non-Final Office Action Dated May 9, 2013. |
U.S. Appl. No. 13/229,891, Notice of Allowance Dated Feb. 19, 2014. |
U.S. Appl. No. 13/267,459, Final Office Action Dated Oct. 23, 2013. |
U.S. Appl. No. 13/267,459, Non-Final Office Action Dated May 2, 2013. |
U.S. Appl. No. 13/267,578, Non-Final Office Action Dated Apr. 5, 2013. |
U.S. Appl. No. 13/267,578, Non-Final Office Action Dated Aug. 6, 2013. |
U.S. Appl. No. 13/267,578, Notice of Allowance Dated Jan. 24, 2014. |
U.S. Appl. No. 13/314,455, Non-Final Office Action Dated Apr. 24, 2013. |
U.S. Appl. No. 13/314,455, Non-Final Office Action Dated Aug. 30, 2013. |
U.S. Appl. No. 13/315,443, Non-Final Office Action Dated Feb. 20, 2014. |
U.S. Appl. No. 13/466,754, Non-Final Office Action Dated Sep. 25, 2013. |
U.S. Appl. No. 13/466,790, Final Office Action Dated Jul. 12, 2013. |
U.S. Appl. No. 13/466,790, Non-Final Office Action Dated Feb. 15, 2013. |
U.S. Appl. No. 13/472,964, Non-Final Office Action Dated Mar. 29, 2013. |
U.S. Appl. No. 13/472,964, Notice of Allowance Dated Jul. 12, 2013. |
U.S. Appl. No. 13/585,446, Final Office Action Dated Jul. 19, 2013. |
U.S. Appl. No. 13/585,446, Non-Final Office Action Dated Feb. 16, 2013. |
U.S. Appl. No. 13/585,446, Notice of Allowance Dated Sep. 12, 2013. |
U.S. Appl. No. 13/594,970, Final Office Action Dated Dec. 4, 2013. |
U.S. Appl. No. 13/594,970, Final Office Action Dated Sep. 25, 2013. |
U.S. Appl. No. 13/594,970, Non-Final Office Action Dated May 29, 2013. |
U.S. Appl. No. 13/594,993, Non-Final Office Action Dated Oct. 25, 2013. |
U.S. Appl. No. 13/594,993, Notice of Allowance Dated Feb. 19, 2014. |
U.S. Appl. No. 13/595,047, Non-Final Office Action Dated May 24, 2013. |
U.S. Appl. No. 13/595,047, Notice of Allowance Dated Dec. 23, 2013. |
U.S. Appl. No. 13/595,405, Final Office Action Dated Nov. 19, 2013. |
U.S. Appl. No. 13/595,405, Non-Final Office Action Dated May 9, 2013. |
U.S. Appl. No. 13/621,219, Non-Final Office Action Dated Nov. 26, 2013. |
U.S. Appl. No. 13/655,975, Notice of Allowance Dated Feb. 19, 2014. |
U.S. Appl. No. 13/780,530, Non-Final Office Action Dated Feb. 20, 2014. |
Vazhkudai, et al., "Enabling the Co-Allocation of Grid Data Transfers", Department of Computer and Information Sciences, The Univ. of Mississippi, pp. 44-51, Nov. 17, 2003. |
VMware, Inc., "VMware Virtual Networking Concepts", pp. 1-12, Latest Revision: Jul. 29, 2007. |
Walters et al., An Adaptive Heterogeneous Software DSM, pp. 1-8, Columbus, Ohio, Aug. 14-Aug. 18. |
Xiao, et al. "Internet QoS: A Big Picture", Michigan State University, IEEE Network, pp. 8-18, Mar./Apr. 1999. |
Yan et al., Tesseract: A 4D Network Control Plane, pp. 1-15, NSDI'07 Proceedings of the 4th USENIX conference on Networked systems design & implementation USENIX Association Berkeley, CA, USA 2007. |
Yemini et al., "Towards Programmable Networks"; Dept. of Computer Science Columbia University, pp. 1-11, Apr. 15, 1996. |
Yoshigoe, et al., "Rate Control for Bandwidth Allocated Services in IEEE 802.3 Ethernet", Proceedings of the 26th Annual IEEE Conference on Local Computer Networks, Nov. 14-16, 2001. |
Cited By (70)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11960937B2 (en) | 2004-03-13 | 2024-04-16 | Iii Holdings 12, Llc | System and method for an optimizing reservation in time of compute resources based on prioritization function and reservation policy parameter |
US12124878B2 (en) | 2004-03-13 | 2024-10-22 | Iii Holdings 12, Llc | System and method for scheduling resources within a compute environment using a scheduler process with reservation mask function |
US11467883B2 (en) | 2004-03-13 | 2022-10-11 | Iii Holdings 12, Llc | Co-allocating a reservation spanning different compute resources types |
US11652706B2 (en) | 2004-06-18 | 2023-05-16 | Iii Holdings 12, Llc | System and method for providing dynamic provisioning within a compute environment |
US12009996B2 (en) | 2004-06-18 | 2024-06-11 | Iii Holdings 12, Llc | System and method for providing dynamic provisioning within a compute environment |
US11630704B2 (en) | 2004-08-20 | 2023-04-18 | Iii Holdings 12, Llc | System and method for a workload management and scheduling module to manage access to a compute environment according to local and non-local user identity information |
US11709709B2 (en) | 2004-11-08 | 2023-07-25 | Iii Holdings 12, Llc | System and method of providing system jobs within a compute environment |
US11537435B2 (en) | 2004-11-08 | 2022-12-27 | Iii Holdings 12, Llc | System and method of providing system jobs within a compute environment |
US11861404B2 (en) | 2004-11-08 | 2024-01-02 | Iii Holdings 12, Llc | System and method of providing system jobs within a compute environment |
US11494235B2 (en) | 2004-11-08 | 2022-11-08 | Iii Holdings 12, Llc | System and method of providing system jobs within a compute environment |
US11762694B2 (en) | 2004-11-08 | 2023-09-19 | Iii Holdings 12, Llc | System and method of providing system jobs within a compute environment |
US11537434B2 (en) | 2004-11-08 | 2022-12-27 | Iii Holdings 12, Llc | System and method of providing system jobs within a compute environment |
US12008405B2 (en) | 2004-11-08 | 2024-06-11 | Iii Holdings 12, Llc | System and method of providing system jobs within a compute environment |
US11886915B2 (en) | 2004-11-08 | 2024-01-30 | Iii Holdings 12, Llc | System and method of providing system jobs within a compute environment |
US11656907B2 (en) | 2004-11-08 | 2023-05-23 | Iii Holdings 12, Llc | System and method of providing system jobs within a compute environment |
US12039370B2 (en) | 2004-11-08 | 2024-07-16 | Iii Holdings 12, Llc | System and method of providing system jobs within a compute environment |
US12120040B2 (en) | 2005-03-16 | 2024-10-15 | Iii Holdings 12, Llc | On-demand compute environment |
US11658916B2 (en) | 2005-03-16 | 2023-05-23 | Iii Holdings 12, Llc | Simple integration of an on-demand compute environment |
US11765101B2 (en) | 2005-04-07 | 2023-09-19 | Iii Holdings 12, Llc | On-demand access to compute resources |
US11533274B2 (en) | 2005-04-07 | 2022-12-20 | Iii Holdings 12, Llc | On-demand access to compute resources |
US11522811B2 (en) | 2005-04-07 | 2022-12-06 | Iii Holdings 12, Llc | On-demand access to compute resources |
US11831564B2 (en) | 2005-04-07 | 2023-11-28 | Iii Holdings 12, Llc | On-demand access to compute resources |
US11496415B2 (en) | 2005-04-07 | 2022-11-08 | Iii Holdings 12, Llc | On-demand access to compute resources |
US11650857B2 (en) | 2006-03-16 | 2023-05-16 | Iii Holdings 12, Llc | System and method for managing a hybrid computer environment |
US11522952B2 (en) | 2007-09-24 | 2022-12-06 | The Research Foundation For The State University Of New York | Automatic clustering for self-organizing grids |
US9465771B2 (en) | 2009-09-24 | 2016-10-11 | Iii Holdings 2, Llc | Server on a chip and node cards comprising one or more of same |
US9454403B2 (en) | 2009-10-30 | 2016-09-27 | Iii Holdings 2, Llc | System and method for high-performance, low-power data center interconnect fabric |
US9405584B2 (en) | 2009-10-30 | 2016-08-02 | Iii Holdings 2, Llc | System and method for high-performance, low-power data center interconnect fabric with addressing and unicast routing |
US9876735B2 (en) * | 2009-10-30 | 2018-01-23 | Iii Holdings 2, Llc | Performance and power optimized computer system architectures and methods leveraging power optimized tree fabric interconnect |
US9929976B2 (en) | 2009-10-30 | 2018-03-27 | Iii Holdings 2, Llc | System and method for data center security enhancements leveraging managed server SOCs |
US9008079B2 (en) | 2009-10-30 | 2015-04-14 | Iii Holdings 2, Llc | System and method for high-performance, low-power data center interconnect fabric |
US9075655B2 (en) | 2009-10-30 | 2015-07-07 | Iii Holdings 2, Llc | System and method for high-performance, low-power data center interconnect fabric with broadcast or multicast addressing |
US9977763B2 (en) | 2009-10-30 | 2018-05-22 | Iii Holdings 2, Llc | Network proxy for high-performance, low-power data center interconnect fabric |
US9866477B2 (en) | 2009-10-30 | 2018-01-09 | Iii Holdings 2, Llc | System and method for high-performance, low-power data center interconnect fabric |
US10050970B2 (en) | 2009-10-30 | 2018-08-14 | Iii Holdings 2, Llc | System and method for data center security enhancements leveraging server SOCs or server fabrics |
US10135731B2 (en) | 2009-10-30 | 2018-11-20 | Iii Holdings 2, Llc | Remote memory access functionality in a cluster of data processing nodes |
US10140245B2 (en) | 2009-10-30 | 2018-11-27 | Iii Holdings 2, Llc | Memcached server functionality in a cluster of data processing nodes |
US9054990B2 (en) | 2009-10-30 | 2015-06-09 | Iii Holdings 2, Llc | System and method for data center security enhancements leveraging server SOCs or server fabrics |
US10877695B2 (en) | 2009-10-30 | 2020-12-29 | Iii Holdings 2, Llc | Memcached server functionality in a cluster of data processing nodes |
US11720290B2 (en) | 2009-10-30 | 2023-08-08 | Iii Holdings 2, Llc | Memcached server functionality in a cluster of data processing nodes |
US9749326B2 (en) | 2009-10-30 | 2017-08-29 | Iii Holdings 2, Llc | System and method for data center security enhancements leveraging server SOCs or server fabrics |
US9680770B2 (en) | 2009-10-30 | 2017-06-13 | Iii Holdings 2, Llc | System and method for using a multi-protocol fabric module across a distributed server interconnect fabric |
US9262225B2 (en) | 2009-10-30 | 2016-02-16 | Iii Holdings 2, Llc | Remote memory access functionality in a cluster of data processing nodes |
US9311269B2 (en) | 2009-10-30 | 2016-04-12 | Iii Holdings 2, Llc | Network proxy for high-performance, low-power data center interconnect fabric |
US11526304B2 (en) | 2009-10-30 | 2022-12-13 | Iii Holdings 2, Llc | Memcached server functionality in a cluster of data processing nodes |
US9077654B2 (en) | 2009-10-30 | 2015-07-07 | Iii Holdings 2, Llc | System and method for data center security enhancements leveraging managed server SOCs |
US9509552B2 (en) | 2009-10-30 | 2016-11-29 | Iii Holdings 2, Llc | System and method for data center security enhancements leveraging server SOCs or server fabrics |
US9479463B2 (en) | 2009-10-30 | 2016-10-25 | Iii Holdings 2, Llc | System and method for data center security enhancements leveraging managed server SOCs |
US20120096211A1 (en) * | 2009-10-30 | 2012-04-19 | Calxeda, Inc. | Performance and power optimized computer system architectures and methods leveraging power optimized tree fabric interconnect |
US11641321B2 (en) | 2010-07-06 | 2023-05-02 | Nicira, Inc. | Packet processing for logical datapath sets |
US11743123B2 (en) * | 2010-07-06 | 2023-08-29 | Nicira, Inc. | Managed switch architectures: software managed switches, hardware managed switches, and heterogeneous managed switches |
US9065745B2 (en) | 2011-10-06 | 2015-06-23 | International Business Machines Corporation | Network traffic distribution |
US9059922B2 (en) | 2011-10-06 | 2015-06-16 | International Business Machines Corporation | Network traffic distribution |
US9585281B2 (en) | 2011-10-28 | 2017-02-28 | Iii Holdings 2, Llc | System and method for flexible storage and networking provisioning in large scalable processor installations |
US10021806B2 (en) | 2011-10-28 | 2018-07-10 | Iii Holdings 2, Llc | System and method for flexible storage and networking provisioning in large scalable processor installations |
US9069929B2 (en) | 2011-10-31 | 2015-06-30 | Iii Holdings 2, Llc | Arbitrating usage of serial port in node card of scalable and modular servers |
US9792249B2 (en) | 2011-10-31 | 2017-10-17 | Iii Holdings 2, Llc | Node card utilizing a same connector to communicate pluralities of signals |
US9092594B2 (en) | 2011-10-31 | 2015-07-28 | Iii Holdings 2, Llc | Node card management in a modular and large scalable server system |
US9965442B2 (en) | 2011-10-31 | 2018-05-08 | Iii Holdings 2, Llc | Node card management in a modular and large scalable server system |
US9648102B1 (en) | 2012-12-27 | 2017-05-09 | Iii Holdings 2, Llc | Memcached server functionality in a cluster of data processing nodes |
US20150295730A1 (en) * | 2013-02-20 | 2015-10-15 | Fujitsu Limited | Switch and setting method |
US9515846B2 (en) * | 2013-02-20 | 2016-12-06 | Fujitsu Limited | Switch and setting method |
US9173158B2 (en) * | 2013-03-08 | 2015-10-27 | Tellabs Operations, Inc. | Method and apparatus for improving LTE enhanced packet core architecture using openflow network controller |
US20140254373A1 (en) * | 2013-03-08 | 2014-09-11 | Tellabs Operations, Inc. | Method and Apparatus for Improving LTE Enhanced Packet Core Architecture Using Openflow Network Controller |
US9967111B2 (en) * | 2013-03-15 | 2018-05-08 | Rackspace Us, Inc. | Software-defined multinetwork bridge |
US20140280738A1 (en) * | 2013-03-15 | 2014-09-18 | Rackspace Us, Inc. | Software-defined multinetwork bridge |
US20160269318A1 (en) * | 2015-03-11 | 2016-09-15 | Vmware, Inc. | Network bandwidth reservations for system traffic and virtual computing instances |
US10693806B2 (en) * | 2015-03-11 | 2020-06-23 | Vmware, Inc. | Network bandwidth reservations for system traffic and virtual computing instances |
US12068979B2 (en) * | 2020-05-01 | 2024-08-20 | EMC IP Holding Company, LLC | System and method for dividing a physical ethernet port |
US11882030B1 (en) * | 2022-09-14 | 2024-01-23 | Realtek Semiconductor Corporation | Network packet transmission device and network packet transmission method thereof |
Also Published As
Publication number | Publication date |
---|---|
US20120287936A1 (en) | 2012-11-15 |
CN102780608A (en) | 2012-11-14 |
US8670450B2 (en) | 2014-03-11 |
US20130010799A1 (en) | 2013-01-10 |
CN102780608B (en) | 2015-06-24 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8824485B2 (en) | Efficient software-based private VLAN solution for distributed virtual switches | |
US10911397B2 (en) | Agent for implementing layer 2 communication on layer 3 underlay network | |
US20210344692A1 (en) | Providing a virtual security appliance architecture to a virtual cloud infrastructure | |
US9965317B2 (en) | Location-aware virtual service provisioning in a hybrid cloud environment | |
US11177978B2 (en) | Connecting virtual computer networks with overlapping IP addresses using transit virtual computer network | |
CN107113219B (en) | System and method for supporting VLAN tagging in a virtual environment | |
US9729578B2 (en) | Method and system for implementing a network policy using a VXLAN network identifier | |
US8612744B2 (en) | Distributed firewall architecture using virtual machines | |
US10887361B2 (en) | Port mirroring in overlay networks | |
EP2905930B1 (en) | Processing method, apparatus and system for multicast | |
CN116210204A (en) | System and method for VLAN switching and routing services | |
US11522763B2 (en) | Agent-based network scanning in software-defined networking (SDN) environments | |
US9535730B2 (en) | Communication apparatus and configuration method | |
US20110035494A1 (en) | Network virtualization for a virtualized server data center environment | |
US20140137109A1 (en) | Virtual device context (vdc) integration for network services | |
US11258729B2 (en) | Deploying a software defined networking (SDN) solution on a host using a single active uplink | |
US11671358B2 (en) | Disambiguating traffic in networking environments with multiple virtual routing and forwarding (VRF) logical routers | |
US10567344B2 (en) | Automatic firewall configuration based on aggregated cloud managed information | |
US9407459B2 (en) | Communication apparatus, communication system, and communication method to transmit and receive Ethernet frames | |
US9716688B1 (en) | VPN for containers and virtual machines in local area networks | |
US11546242B2 (en) | Logical overlay tunnel monitoring | |
US11444836B1 (en) | Multiple clusters managed by software-defined network (SDN) controller |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
FEPP | Fee payment procedure |
Free format text: MAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.) |
|
LAPS | Lapse for failure to pay maintenance fees |
Free format text: PATENT EXPIRED FOR FAILURE TO PAY MAINTENANCE FEES (ORIGINAL EVENT CODE: EXP.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
STCH | Information on status: patent discontinuation |
Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362 |
|
FP | Lapsed due to failure to pay maintenance fee |
Effective date: 20180902 |