Abstract: An example network access control system includes a memory storing one or more security policies for an enterprise network; and one or more processors coupled to the memory and configured to: receive a request to connect to the enterprise network from a client device of a user, in response to the receipt of the request, determine one or more user attributes associated with the user and one or more endpoint attributes of the client device, identify a security policy of the one or more security policies based on the one or more user attributes and the one or more endpoint attributes, and configure an access control module of a network device of the enterprise network in accordance with the security policy.

Abstract: A multi-tenant, cloud-hosted Network Access Control (NAC) system may receive an indicator from a Network Access Server (NAS) device to identify the tenant with which the NAS device is associated. The NAS device may put the identifier in the Transport Layer Security (TLS)/Secure Sockets Layer (SSL) extension Server Name Indication (SNI) field. The NAC system may use the identifier to obtain tenant-specific configuration information for setting up a secure tunnel with the NAS device.

Abstract: Techniques are described for configuration and application of intent-based network access control (NAC) policies for authentication and authorization of multi-tenant, network access server (NAS) devices to access enterprise networks of organizations. A network management system configures intent-based NAC policies for an organization. A cloud-based NAC system may apply an appropriate intent-based NAC policy in response to an authentication request from a NAS device. The NAC system identifies a vendor of the NAS device, matches incoming attributes in the authentication request to a set of normalized match rules of the intent-based NAC policy, and translates a set of abstracted policy results corresponding to the set of normalized match rules into a vendor-specific set of return attributes based on the vendor of the NAS device. The NAC system sends the vendor-specific set of return attributes to the NAS device to enable the NAS device to access the enterprise network of the organization.

Abstract: InfiniBand transport protocol today supports RDMA operations such as read and write with each operation having an opcode defined in the InfiniBand standard. Currently, new RDMA operations require extending the transport protocol by defining a new opcode, its respective header and enhancing InfiniBand implementations to support this new behavior. A more robust way of extending RDMA without requiring an expanding set of opcodes is to register computer code by associating it with a code key similar to a memory key. An InfiniBand channel adapter receiving an RDMA request that includes a code key executes the associated computer code, perhaps compiling it first, in response to receiving the RDMA request. The RDMA response returned to the requester includes an execution result indicating an outcome of executing the executable computer code.

Abstract: Techniques are described for providing network provisioning by a network management system (NMS) based on fingerprint information determined by a network access control (NAC) system. An example method includes receiving, by the NAC system, a network access request for a client device to access an enterprise network; obtaining, by the NAC system, fingerprint information of the client device associated with the network access request, wherein the fingerprinting information comprises information specifying one or more attributes associated with the client device; authenticating, by the NAC system, the client device to access the enterprise network; sending, by the NAC system and to the NMS, the fingerprint information of the client device; and provisioning, by the NMS, one or more network resources associated with the client device based on the fingerprint information of the client device.

Abstract: InfiniBand transport protocol today supports RDMA operations such as read and write with each operation having an opcode defined in the InfiniBand standard. Currently, new RDMA operations require extending the transport protocol by defining a new opcode, its respective header and enhancing InfiniBand implementations to support this new behavior. A more robust way of extending RDMA without requiring an expanding set of opcodes is to register computer code by associating it with a code key similar to a memory key. An InfiniBand channel adapter receiving an RDMA request that includes a code key executes the associated computer code, perhaps compiling it first, in response to receiving the RDMA request. The RDMA response returned to the requester includes an execution result indicating an outcome of executing the executable computer code.

Abstract: A method for managing network congestion is provided. The method comprises: receiving, at a receiver, a packet comprising a timestamp provided by a first clock of a sender; deriving, by the receiver, a latency value based at least in part on the timestamp provided by the first clock and a receipt time provided by a second clock of the receiver; determining a latency change by comparing the latency value with a previous latency value; and determining a state of network congestion based at least in part on the latency change.

Abstract: A method for managing network congestion is provided. The method comprises: receiving, at a receiver, a packet comprising a timestamp provided by a first clock of a sender; deriving, by the receiver, a latency value based at least in part on the timestamp provided by the first clock and a receipt time provided by a second clock of the receiver; determining a latency change by comparing the latency value with a previous latency value; and determining a state of network congestion based at least in part on the latency change.

Abstract: A plurality of line cards with each line card having a respective network forwarding engine and a respective outgoing interface (OIF) list and at least one fabric module communicatively coupled with each line card with each fabric module can have a respective network forwarding engine. The local OIF list can be asymmetrically programmed. The network forwarding engine of a line card can be configured to receive a multicast packet, compare a multicast address associate with the received multicast packet with entries in the local OIF list of the line card and forward the received multicast packet to at least one interface associated with the multicast address in response to the comparison resulting in a match.

Abstract: Techniques are provided for mitigating the effects of slow or no drain devices on a fabric. One or more of the described embodiments can be used alone or in combination to address problems associated with inter-switch link blocking and to address the situation where flows which are not associated with slow/no drain devices suffer the negative impacts of slow or no drain devices on a fabric.

Abstract: A plurality of line cards with each line card having a respective network forwarding engine and a respective outgoing interface (OIF) list and at least one fabric module communicatively coupled with each line card with each fabric module can have a respective network forwarding engine. The local OIF list can be asymmetrically programmed. The network forwarding engine of a line card can be configured to receive a multicast packet, compare a multicast address associate with the received multicast packet with entries in the local OIF list of the line card and forward the received multicast packet to at least one interface associated with the multicast address in response to the comparison resulting in a match.

Abstract: Techniques are disclosed for zoning information to be shared with an NPIV proxy device or an NPV device such as a blade switch in a blade chassis. Doing so allows the NPV device to enforce zoning locally for the attached server blades and virtualized systems. The NPV device may learn zoning rules using Fiber Channel name server queries and registered state change notifications. Additionally, the NPV device may snoop name server queries to retrieve zoning information (or state change messages) without using the zoning change protocols and without consuming a Fiber Channel domain from the Fiber Channel fabric.

Abstract: Techniques are provided for mitigating the effects of slow or no drain devices on a fabric. One or more of the described embodiments can be used alone or in combination to address problems associated with inter-switch link blocking and to address the situation where flows which are not associated with slow/no drain devices suffer the negative impacts of slow or no drain devices on a fabric.

Abstract: Techniques are provided for mitigating the effects of slow or no drain devices on a fabric. One or more of the described embodiments can be used alone or in combination to address problems associated with inter-switch link blocking and to address the situation where flows which are not associated with slow/no drain devices suffer the negative impacts of slow or no drain devices on a fabric.

Abstract: Techniques are provided for mitigating the effects of slow or no drain devices on a fabric. One or more of the described embodiments can be used alone or in combination to address problems associated with inter-switch link blocking and to address the situation where flows which are not associated with slow/no drain devices suffer the negative impacts of slow or no drain devices on a fabric.

Abstract: A technique is disclosed for managing load balancing operations in a storage area network. A frame is received at a switch in the fibre channel fabric. According to a specific implementation, the frame includes header information including a source device identity and a destination device identity. Zone and/or flow information relating to the identity of the zone/flow which is associated with the frame is identified. Using the identified information, a load balancing mechanism to be used for handling the frame is selected. According to a specific implementation, the selection of the load balancing mechanism is based at least in part upon the identity of the zone and/or flow which is associated with the frame.

Abstract: Techniques are disclosed for zoning information to be shared with an NPIV proxy device or an NPV device such as a blade switch in a blade chassis. Doing so allows the NPV device to enforce zoning locally for the attached server blades and virtualized systems. The NPV device may learn zoning rules using Fibre Channel name server queries and registered state change notifications. Additionally, the NPV device may snoop name server queries to retrieve zoning information (or state change messages) without using the zoning change protocols and without consuming a Fibre Channel domain from the Fibre Channel fabric.

Abstract: A method of monitoring network traffic in a fabric and a Fibre Channel network are provided. The method includes: transmitting a monitoring configuration message to a plurality of fabric elements in a Fibre Channel network, said monitoring configuration message including classification criteria identifying packets to be monitored; receiving copies of identified packets from the plurality of fabric elements; and analyzing the copies of identified packets to determine data transmission status in the Fibre Channel network.

Abstract: A technique is disclosed for managing in-order-delivery of data traffic in a storage area network which includes at least one host device adapted to communicate with at least one storage device via a fiber channel fabric. When a change in at least one route in the fiber channel fabric is detected, a first zone, flow and/or device in the network which is affected by the route change is identified, and frames associated with the first zone/flow/device are temporarily dropped for a temporary time period T. In one embodiment, the first zone/flow/device includes at least one device which is sensitive to the order in which data traffic is received. According to a specific implementation, a second zone/flow/device in the network which is affected by the route change, and which is not sensitive to the order in which data traffic is received may also be identified, and frames associated with the second zone/flow/device forwarded to their destination address during the temporary time period T.

Abstract: Disclosed are apparatus and methods for facilitating communication between two devices from two different VSANs by propagating each device's presence from a first VSAN to the other device's different VSAN using a network address translation (NAT) mechanism. For instance, a first device, such as a host H1, from VSAN_A is allowed to access data from a second device, such as disk D1, of VSAN_B by propagating D1's presence into VSAN_A and H1's presence into VSAN_B. This awareness is accomplished by propagating an identifier for each device into the edge VSAN of the other device, as well as into any transit VSAN. So as to not duplicate identifiers in any one of the VSANs, a device's presence is propagated into a particular VSAN by assigning an unused domain for use by such device in the particular VSAN.