Abstract: The disclosed technology provides a method for generating quantitative recommendations for healthcare benefits plans using hierarchical layered graphs. One or more nodes are identified in the hierarchical layered graphs. The hierarchical layered graphs store historical healthcare claims data. The one or more nodes are identified based on contextual data associated with an employee and on similarities between the contextual data associated with the employee and node contextual data associated with the node. One or more paths are identified among the one or more identified nodes. A plurality of healthcare plans are scored using the hierarchical layered graphs by applying contextual data associated with the plurality of healthcare plans to the identified paths. A subset of the plurality of scored healthcare plans are identified and recommended to the employer or the employee.

Abstract: Techniques for determining port-to-port connectivity in an extended bridge are provided. According to one set of embodiments, a port extender (PE) of the extended bridge (e.g., a base PE) can build a local database comprising connectivity information for one or more physical cascade ports of the PE. This building can be based on one or more messages received from another PE in the extended bridge (e.g., a transit PE) that is directly connected to the PE. The PE can then transmit, at a time of joining the extended bridge, the connectivity information to a controlling bridge (CB) of the extended bridge for storage thereon.

Abstract: Techniques for handling dynamic cascade port/LAG changes in an extended bridge are provided. According to one embodiment, a first network device in an extended bridge can maintain a shadow table that stores information regarding one or more ports and one or more LAGs used to interconnect the network devices in the extended bridge. The first network device can further receive, from a user via a device UI, a command relating to a change to a port or a LAG, update the shadow table based on the change, transmit a change message to one or more other network devices affected by the change, and start a timer associated with the one or more other network devices. In various embodiments, the updating and the transmitting can be performed without blocking the user from entering further commands via the device UI.

Abstract: Techniques for configuring/learning the link aggregation groups (LAGs) of a port extender (PE) at the time the PE joins an extended bridge are provided. According to one embodiment, a first network device in a system of network devices (e.g., an extended bridge) can receive a join message from a second network device in the system, where the join message includes a LAG configuration for one or more LAGs programmed on the second network device. The first network device can further determine whether a provisional LAG configuration for the one or more LAGs of the second network device exists on the first network device. If a provisional LAG configuration does not exist on the first network device, the first network device can learn the LAG configuration included in the join message and can integrate the second network device into the system based on the learned LAG configuration.

Abstract: Techniques for handling dynamic cascade port/LAG changes without breaking communication in an extended bridge are provided. According to one embodiment, a first network device (e.g., controlling bridge) in a system of network devices (e.g., extended bridge) can receive a command relating to a change to at least one port or LAG of the system. The first network device can then transmit change messages to one or more other network devices (e.g., port extenders) in the system that are affected by the change, where the change messages are transmitted in an order based on the distance of each of the one or more other network devices from the first network device.

Abstract: Techniques for handling connections between network devices that support multiple port communication modes are provided. In one embodiment, a first network device can detect a communication problem between a local port of the first network device and a peer port of a second network device, where the local port supports a plurality of communication modes including a default mode and one or more non-default modes. The first network device can further set the local port to operate in the default mode, receive on the local port a user-configured mode of the peer port from the second network device, and determine a communication mode for the local port from the plurality of communication modes, where the determining is based on the user-configured mode of the peer port and a user-configured mode of the local port. The first network device can then set the local port to operate in the determined communication mode.

Abstract: Techniques implementing redundancy in an extended bridge comprising a controller bridge (CB) unit and a plurality of port extender (PE) units are provided. In one embodiment, the CB unit can receive join requests from the plurality of PE units and can determine, based on the join requests, whether the plurality of PE units are physically connected to the CB unit and/or other CB units in the extended bridge according to a ring topology. If the plurality of PE units are physically connected to the CB unit or the other CB units according to a ring topology, the CB unit can select a link in the ring topology as being a standby link.

Abstract: Techniques for determining port-to-port connectivity in an extended bridge are provided. According to one set of embodiments, a port extender (PE) of the extended bridge (e.g., a base PE) can build a local database comprising connectivity information for one or more physical cascade ports of the PE. This building can be based on one or more messages received from another PE in the extended bridge (e.g., a transit PE) that is directly connected to the PE. The PE can then transmit, at a time of joining the extended bridge, the connectivity information to a controlling bridge (CB) of the extended bridge for storage thereon.

Abstract: Techniques for simplifying stacking trunk creation and management are provided. In one embodiment, a switch in a stacking system can receive first and second control packets from one or more other switches in the stacking system, where the first and second control packets are received on first and second stacking ports of the switch respectively. The switch can then determine, based on the first and second control packets, whether the first and second stacking ports can be configured as a single stacking trunk.

Abstract: Techniques for handling dynamic cascade port/LAG changes without breaking communication in an extended bridge are provided. According to one embodiment, a first network device (e.g., controlling bridge) in a system of network devices (e.g., extended bridge) can receive a command relating to a change to at least one port or LAG of the system. The first network device can then transmit change messages to one or more other network devices (e.g., port extenders) in the system that are affected by the change, where the change messages are transmitted in an order based on the distance of each of the one or more other network devices from the first network device.

Abstract: Techniques for configuring/learning the link aggregation groups (LAGs) of a port extender (PE) at the time the PE joins an extended bridge are provided. According to one embodiment, a first network device in a system of network devices (e.g., an extended bridge) can receive a join message from a second network device in the system, where the join message includes a LAG configuration for one or more LAGs programmed on the second network device. The first network device can further determine whether a provisional LAG configuration for the one or more LAGs of the second network device exists on the first network device. If a provisional LAG configuration does not exist on the first network device, the first network device can learn the LAG configuration included in the join message and can integrate the second network device into the system based on the learned LAG configuration.

Abstract: Techniques for handling dynamic cascade port/LAG changes in an extended bridge are provided. According to one embodiment, a first network device in an extended bridge can maintain a shadow table that stores information regarding one or more ports and one or more LAGs used to interconnect the network devices in the extended bridge. The first network device can further receive, from a user via a device UI, a command relating to a change to a port or a LAG, update the shadow table based on the change, transmit a change message to one or more other network devices affected by the change, and start a timer associated with the one or more other network devices. In various embodiments, the updating and the transmitting can be performed without blocking the user from entering further commands via the device UI.

Abstract: Techniques for handling connections between network devices that support multiple port communication modes are provided. In one embodiment, a first network device can detect a communication problem between a local port of the first network device and a peer port of a second network device, where the local port supports a plurality of communication modes including a default mode and one or more non-default modes. The first network device can further set the local port to operate in the default mode, receive on the local port a user-configured mode of the peer port from the second network device, and determine a communication mode for the local port from the plurality of communication modes, where the determining is based on the user-configured mode of the peer port and a user-configured mode of the local port. The first network device can then set the local port to operate in the determined communication mode.

Abstract: Techniques implementing redundancy in an extended bridge comprising a controller bridge (CB) unit and a plurality of port extender (PE) units are provided. In one embodiment, the CB unit can receive join requests from the plurality of PE units and can determine, based on the join requests, whether the plurality of PE units are physically connected to the CB unit and/or other CB units in the extended bridge according to a ring topology. If the plurality of PE units are physically connected to the CB unit or the other CB units according to a ring topology, the CB unit can select a link in the ring topology as being a standby link.

Abstract: A method of configuring a stack includes: connecting stacking ports of a plurality of stackable devices using one or more stacking links; connecting a user console to a first one of the stackable devices; transmitting a stack setup command from the user console to the first stackable device; and establishing a stack in response to the stack setup command. The stack is established by initiating a discovery process with the first stackable device in response to the stack setup command, wherein the first stackable device requests and receives identifying information from the stackable devices over the stacking links during the discovery process. The topology of the stackable devices is displayed with the user console in response to the identifying information. The stackable devices are authenticated during the discovery process such that the stack setup is secure. The first stackable device becomes the active controller of the stack by default.

Abstract: A stackable device having a plurality of data ports, wherein each of the data ports is capable of operating as a regular data port or a stacking port. A first set of one or more of the data ports is specified as a first flexible stacking port, and a second set of one or more of the data ports is specified as a second flexible stacking port. Each flexible stacking port can be individually configured to operate as an actual stacking port, if required by the configuration of an associated stack. If a flexible stacking port is not configured to operate as an actual stacking port, then the data port(s) included in the flexible stacking port are available to operate as regular data port(s).

Abstract: A stackable device having a plurality of data ports, wherein each of the data ports is capable of operating as a regular data port or a stacking port. A first set of one or more of the data ports is specified as a first flexible stacking port, and a second set of one or more of the data ports is specified as a second flexible stacking port. Each flexible stacking port can be individually configured to operate as an actual stacking port, if required by the configuration of an associated stack. If a flexible stacking port is not configured to operate as an actual stacking port, then the data port(s) included in the flexible stacking port are available to operate as regular data port(s).

Abstract: Techniques for simplifying stacking trunk creation and management are provided. In one embodiment, a switch in a stacking system can receive first and second control packets from one or more other switches in the stacking system, where the first and second control packets are received on first and second stacking ports of the switch respectively. The switch can then determine, based on the first and second control packets, whether the first and second stacking ports can be configured as a single stacking trunk.

Abstract: Techniques for simplifying stacking trunk creation and management are provided. In one embodiment, a switch in a stacking system can receive first and second control packets from one or more other switches in the stacking system, where the first and second control packets are received on first and second stacking ports of the switch respectively. The switch can then determine, based on the first and second control packets, whether the first and second stacking ports can be configured as a single stacking trunk.

Abstract: A method of configuring a stack includes: connecting stacking ports of a plurality of stackable devices using one or more stacking links; connecting a user console to a first one of the stackable devices; transmitting a stack setup command from the user console to the first stackable device; and establishing a stack in response to the stack setup command. The stack is established by initiating a discovery process with the first stackable device in response to the stack setup command, wherein the first stackable device requests and receives identifying information from the stackable devices over the stacking links during the discovery process. The topology of the stackable devices is displayed with the user console in response to the identifying information. The stackable devices are authenticated during the discovery process such that the stack setup is secure. The first stackable device becomes the active controller of the stack by default.