Cisco Technology, Inc.

Amitkumar V Patel

Ronak K Desai

Umesh Mahajan

Ramana Mellacheruvu

Umamaheswararao Karyampudi

Javed Asghar

Sridhar Vallepalli

Saad Malik

Dino Farinacci

Christian Sasso

Ankur Goyal

Siddharth Kasat

Tameen Khan

Akshya Kumar Singh

Kishan Kumar Kotari Uppunda

Sri Goli

Ravi Nag Chamarthy

Kishan Kumar Kotari Uppanda

Embodiments herein describe using translation mappings and security contracts to establish interconnects and policies between switching fabrics at different sites to create a unified fabric. In one embodiment, a multi-site controller can stretch endpoint groups (EPGs) between the sites so that a host or application in a first site can communicate with a host or application in a second site which is assigned to the same stretched EPG, despite the two sites have different namespaces. Further, the shadow EPGs can be formed to facilitate security contracts between EPGs in different sites. Each site can store namespace translation mapping that enable the site to convert namespace information in packets received from a different site into its own namespace values. As a result, independent bridging and routing segments in the various sites can be interconnected as well as providing application accessibility across different fabrics with independent and private namespaces.

Multisite interconnect and policy with switching fabrics

Techniques and mechanisms for managing workloads in compute clusters comprising compute nodes by managing the workloads at the resource level of the compute clusters. For example, virtual service contexts (VSCs) may be defined where the VSCs represent service classes. Policies may be defined with respect to each service class. These service classes are dynamically constructed based on business needs. Hence there is natural requirement for a user to construct and rebalance the compute resources for these service classes dynamically. The policies may be related to resources of the compute clusters for executing workload units in the compute clusters. Resources of the compute clusters may be allocated to each service class. Each workload unit may be assigned to a one of the service classes based on the service context or type of workload unit. The workload units may then be executed by the compute clusters using the resources in accordance with the policies.

Compute resources management via virtual service contexts (VSC) in compute clusters

In one embodiment, an indication of a fault condition is received relating to a first service running on a physical device in a computer network. The first service is associated with a first virtual device context defined on the physical device. Then, the first service is disabled without affecting operation of a second service on the physical device. The second service is associated with a second virtual device context defined on the physical device. In another embodiment, a first virtual device context is created on a physical device in a computer network. Then, a second virtual device context is created on the physical device. The first virtual device context may then be managed independently of the second virtual device context such that resources assigned to a virtual device context are managed without affecting management of another virtual device context.

Logical partitioning of a physical device

According to one aspect, a Fiber Channel (FC) switch that is currently serving as a Principal Switch among a plurality of FC switches in a FC Fabric sends an Exchange Fabric Parameters (EFP) frame having an empty domain identifier list to neighboring FC switches during a first portion a Principal Switch Selection phase. During a second portion of the Principal Switch Selection phase that is after the first portion, the first Fiber Channel switch sends to neighboring FC switches an EFP frame having a non-empty domain identifier list to indicate to the neighboring FC switches that the first FC switch is to remain serving as the Principal Switch in the FC Fabric.

Persistent principal switch for fibre channel fabric

A Fiber Channel (FC) switch and related methods are provided for merging the FC switch with an existing FC network. During a merge process of a stand-alone switch with an FC network, a first Exchange Fabric Parameters (EFP) frame is sent from the stand-alone switch to an FC switch in the existing FC network. The first EFP frame has an empty domain identifier (ID) list. The stand-alone switch receives a second EFP frame from the FC switch. The second EFP frame contains a domain ID list of domain IDs already in use in the FC network. The stand-alone switch compares the domain ID list in the second EFP frame with a stored list of one or more domain IDs associated with the stand-alone switch to determine if there is a domain ID overlap or conflict. If no conflict is detected, the stand-alone switch merges with the existing network without initiating a Build Fabric phase or a Principal Switch Selection phase that could cause disruption of traffic in the network.

Merging a stand-alone switch to a fibre channel network

Disclosed are methods and apparatus for restarting a first network device having a plurality of ports for receiving and transmitting layer 2 data. The first network device belongs to a network of network devices. When a restart of at least a portion of the first network device is imminent whereby the restarting network device portion can no longer alter a spanning tree protocol (STP) state of one or more of the ports and such ports that remain in a fixed state during the restart are referred to as restarting ports, a current state (such as forwarding) of each restarting port is maintained during the restart under predefined conditions. During the restart, each of the restarting ports of the restarting network device portion cooperate with its peer port of a second non-restarting network device that is a neighbor of the first network device so as to prevent layer 2 loops in the network.

Seamless spanning tree upgrade of a linecard

Disclosed are methods and apparatus for restarting a first network device having a plurality of ports for receiving and transmitting layer 2 data. The first network device belongs to a network of network devices. When a restart of at least a portion of the first network device is imminent whereby STP is no longer functioning for the first network device during the restart and can no longer alter a spanning tree protocol (STP) state of one or more of the ports and such ports that remain in a fixed state during the restart are referred to as restarting ports, a current state (such as forwarding) of each restarting port is maintained during the restart under predefined conditions. During the restart, each of the restarting ports of the restarting network device portion cooperate with its peer port of a second non-restarting network device that is a neighbor of the first network device so as to prevent layer 2 loops in the network.

Growing community of inventors

Fremont, CA, United States of America

Amitkumar V Patel