Eswara S Chinthalapati

20130124707, May 16, 2013

Nov 5, 2012

13/669313

Vivek Agarwal - San Jose CA, US
Eswara S.P. Chinthalapati - San Jose CA, US

BROCADE COMMUNICATIONS SYSTEMS, INC. - San Jose CA

G06F 15/173

709223

One embodiment of the present invention provides a system for facilitating flow definition management in a switch. During operation, the system identifies a generic flow definition which specifies a flow that is not specific to any input port of a switch. The system further stores in a flow lookup data structure one or more port-specific flow rules based on the generic flow definition, wherein each port-specific flow rule corresponds to a respective port capable of processing data flows.

20130100854, Apr 25, 2013

Oct 19, 2012

13/656438

Rahul Vir - Cupertino CA, US
Eswara S.P. Chinthalapati - San Jose CA, US
Vivek Agarwal - San Jose CA, US
Lok Yan Hui - Milpitas CA, US

BROCADE COMMUNICATIONS SYSTEMS, INC. - San Jose CA

H04L 12/28

370254

One embodiment of the present invention provides a switch. The switch includes a link aggregation database, an arbitration module, a packet processor, and a logical connection management module. The link aggregation database stores information regarding a plurality of switches participating in a multi-chassis trunk. The plurality of switches includes the switch as well. The arbitration module selects a switch of the plurality of switches as an active switch based on the information in the link aggregation database. The packet processor constructs a packet for a remote switch forwardable via a logical connection. The logical connection management module operates in conjunction with the packet processor and constructs a message containing instructions for creating a second logical connection to a second switch of the plurality of switches.

20190116133, Apr 18, 2019

Aug 31, 2018

16/120151

- San Jose CA, US
Ivy Pei-Shan Hsu - Dublin CA, US
Eswara Chinthalapati - San Jose CA, US
Sanjeev Chhabria - Castro Valley CA, US

H04L 12/935
H04L 12/803
H04L 12/931
H04L 29/08
H04L 12/46

Using a hash function, an L2/L3 switch can produce an FID for a data packet. The L2/L3 switch can select, from among potentially several stored VLAN flooding tables, a particular VLAN flooding table that is associated with a particular VLAN on which the data packet is to be carried. The rows of the particular VLAN flooding table can specify different combinations of the particular VLAN's egress ports. The L2/L3 switch can locate, in the particular VLAN flooding table, a particular row that specifies the FID. The L2/L3 switch can read, from the particular row, a specified subset of the egress ports that are associated with the particular VLAN. The L2/L3 switch can transmit copies of the data packet out each of the egress ports specified in the subset, toward analytic servers connected to those egress ports.

20170187649, Jun 29, 2017

Feb 6, 2017

15/425777

- San Jose CA, US
Ivy Pei-Shan Hsu - Dublin CA, US
Eswara Chinthalapati - San Jose CA, US
Sanjeev Nand Chhabria - Castro Valley CA, US

H04L 12/935
H04L 12/931
H04L 29/08
H04L 12/46

Using a hash function, an LL switch can produce an FID for a data packet. The LL switch can select, from among potentially several stored VLAN flooding tables, a particular VLAN flooding table that is associated with a particular VLAN on which the data packet is to be carried. The rows of the particular VLAN flooding table can specify different combinations of the particular VLAN's egress ports. The LL switch can locate, in the particular VLAN flooding table, a particular row that specifies the FID. The LL switch can read, from the particular row, a specified subset of the egress ports that are associated with the particular VLAN. The LL switch can transmit copies of the data packet out each of the egress ports specified in the subset, toward analytic servers connected to those egress ports.

20160285750, Sep 29, 2016

Oct 27, 2015

14/923738

- San Jose CA, US
Eswara Chinthalapati - San Jose CA, US
Dilip Kumar - Royal Oak MI, US

H04L 12/703
H04L 12/707
H04L 12/715
H04L 12/26

Techniques for performing efficient topology failure detection in SDN networks are provided. In one embodiment, a computer system (e.g., an SDN controller) can transmit a first message to a first network device, where the first message instructs the first network device to begin sending probe packets to a second network device at a predetermined rate. The computer system can further transmit a second message to the second network device, where the second message instructs the second network device to monitor for the probe packets sent by the first network device and to notify the computer system when one or more of the probe packets are not received by the second network device. If the computer system receives such a notification from the second network device, the computer system can determine that that a port, link, or node failure has occurred between the first and second network devices.

20150350077, Dec 3, 2015

May 26, 2015

14/721978

- San Jose CA, US
Syed Natif Nawaz - Santa Clara CA, US
Eswara Chinthalapati - San Jose CA, US
Yi Zhang - Saratoga CA, US
Sindhu Payankulath - Fremont CA, US

H04L 12/741
H04L 12/717
H04L 29/08
H04L 12/715

Techniques for transforming a legacy network into a Software Defined Networking (SDN) enabled network are provided. In one embodiment, a route server can receive one or more routing protocol packets originating from a network device, where the one or more routing protocol packets are forwarded to the route server via a cross connect configured on a network router. The route server can further establish a routing protocol session between the route server and the network device based on the one or more routing protocol packets, and can add a routing entry to a local routing table. Upon adding the routing entry, the route server can automatically invoke an application programming interface (API) for transmitting the routing entry to a Software Defined Networking (SDN) controller.

20150180802, Jun 25, 2015

Jun 30, 2014

14/320138

- San Jose CA, US
Ivy Pei-Shan Hsu - Dublin CA, US
Eswara Chinthalapati - San Jose CA, US
Sanjeev Chhabria - Castro Valley CA, US

H04L 12/935
H04L 12/931
H04L 12/46

Using a hash function, an L/L switch can produce an FID for a data packet. The L/L switch can select, from among potentially several stored VLAN flooding tables, a particular VLAN flooding table that is associated with a particular VLAN on which the data packet is to be carried. The rows of the particular VLAN flooding table can specify different combinations of the particular VLAN's egress ports. The L/L switch can locate, in the particular VLAN flooding table, a particular row that specifies the FID. The L/L switch can read, from the particular row, a specified subset of the egress ports that are associated with the particular VLAN. The L/L switch can transmit copies of the data packet out each of the egress ports specified in the subset, toward analytic servers connected to those egress ports.

20140204760, Jul 24, 2014

Oct 7, 2013

14/047278

- San Jose CA, US
Mukhtiar Shaikh - San Jose CA, US
Eswara Chinthalapati - San Jose CA, US
Yi Zhang - Saratoga CA, US
Michael William Chen - Los Gatos CA, US
Sadashiv Kudlamath - Cupertino CA, US
Matthew Robert Eclavea - Pleasanton CA, US

Brocade Communications Systems, Inc. - San Jose CA

H04L 12/803

370236

Techniques for optimizing traffic flows via MAC synchronization when server virtualization is used with dynamic routing are provided. In one embodiment, a first network device can store an interface MAC address of a second network device in an L2 forwarding table, where the first network device and the second network device are peer nodes in an MC-LAG cluster. Further, the first network device can enable a flag for the interface MAC address in the L2 forwarding table. When the first network device receives a data packet that includes the interface MAC address of the second network device as a destination MAC address, the first network device can determine that the interface MAC address is included in the L2 forwarding table with the flag enabled. The first network device can then perform a lookup into its L3 routing table, identify a next hop destination for the data packet, and route the packet to the destination.