US20080137660A1 - Multicasting Unicast Packet/Multiple Classification of a Packet - Google Patents

Multicasting Unicast Packet/Multiple Classification of a Packet Download PDF

Info

Publication number
US20080137660A1
US20080137660A1 US11/776,661 US77666107A US2008137660A1 US 20080137660 A1 US20080137660 A1 US 20080137660A1 US 77666107 A US77666107 A US 77666107A US 2008137660 A1 US2008137660 A1 US 2008137660A1
Authority
US
United States
Prior art keywords
packet
vlan
mac address
routed
address
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.)
Granted
Application number
US11/776,661
Other versions
US7940766B2 (en
Inventor
Joseph Olakangil
Gregory G. Page
Robert Leon Sangroniz
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
RPX Corp
Nokia USA Inc
Original Assignee
Alcatel Lucent SAS
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Alcatel Lucent SAS filed Critical Alcatel Lucent SAS
Priority to US11/776,661 priority Critical patent/US7940766B2/en
Assigned to ALCATEL LUCENT reassignment ALCATEL LUCENT ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: OLAKANGIL, JOSEPH, PAGE, GREGORY G, SANGRONIZ, ROBERT LEON
Publication of US20080137660A1 publication Critical patent/US20080137660A1/en
Application granted granted Critical
Publication of US7940766B2 publication Critical patent/US7940766B2/en
Assigned to CORTLAND CAPITAL MARKET SERVICES, LLC reassignment CORTLAND CAPITAL MARKET SERVICES, LLC SECURITY INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: PROVENANCE ASSET GROUP HOLDINGS, LLC, PROVENANCE ASSET GROUP, LLC
Assigned to NOKIA USA INC. reassignment NOKIA USA INC. SECURITY INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: PROVENANCE ASSET GROUP HOLDINGS, LLC, PROVENANCE ASSET GROUP LLC
Assigned to PROVENANCE ASSET GROUP LLC reassignment PROVENANCE ASSET GROUP LLC ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: ALCATEL LUCENT SAS, NOKIA SOLUTIONS AND NETWORKS BV, NOKIA TECHNOLOGIES OY
Assigned to NOKIA US HOLDINGS INC. reassignment NOKIA US HOLDINGS INC. ASSIGNMENT AND ASSUMPTION AGREEMENT Assignors: NOKIA USA INC.
Assigned to PROVENANCE ASSET GROUP LLC, PROVENANCE ASSET GROUP HOLDINGS LLC reassignment PROVENANCE ASSET GROUP LLC RELEASE BY SECURED PARTY (SEE DOCUMENT FOR DETAILS). Assignors: NOKIA US HOLDINGS INC.
Assigned to PROVENANCE ASSET GROUP LLC, PROVENANCE ASSET GROUP HOLDINGS LLC reassignment PROVENANCE ASSET GROUP LLC RELEASE BY SECURED PARTY (SEE DOCUMENT FOR DETAILS). Assignors: CORTLAND CAPITAL MARKETS SERVICES LLC
Assigned to RPX CORPORATION reassignment RPX CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: PROVENANCE ASSET GROUP LLC
Expired - Fee Related legal-status Critical Current
Adjusted expiration legal-status Critical

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]
    • H04L12/4645—Details on frame tagging
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1836—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with heterogeneous network architecture
    • 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/4604—LAN interconnection over a backbone network, e.g. Internet, Frame Relay
    • H04L12/462—LAN interconnection over a bridge based backbone
    • H04L12/4625—Single bridge functionality, e.g. connection of two networks over a single bridge
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/16—Multipoint routing

Definitions

  • the present invention relates to a switch that receives a unicast packet (which has a routed Media Access Control (MAC) address) in a first Virtual Local Area Network (VLAN) and then multicasts/floods/bridges copies of the packet (after it has been modified to have a multicast MAC address) from a second VLAN.
  • MAC Media Access Control
  • the ability to multicast a unicast packet (e.g., traffic, data stream) in this manner would be desirable in a wide variety of applications including, for example, server farms and redundant firewalls.
  • a user can have their switch multicast the received unicast packet to multiple servers because each of the servers need to receive a redundant backup of the unicast packet.
  • the traditional switches cannot receive unicast packets at one VLAN and then multicast the packets at a second VLAN because: (1) the packet is routed; (2) the packet does not have a broadcast MAC address as the destination MAC address; (3) the packet does not have a multicast MAC address as the destination MAC address; and (4) the packet does not have a multicast IP address as the destination IP address. Accordingly, there has been and is a need to address this particular shortcoming and other shortcomings which are associated with the traditional switches. This need and other needs are satisfied by the present invention.
  • the present invention provides a switch and method for multicasting a unicast packet by: (a) receiving the unicast packet which is a L3 routed packet at a port in a first VLAN; (b) routing the received packet to a loopback port in a second VLAN; (c) receiving the routed packet which is now a L2 multicast packet from the loopback port in the second VLAN; and (d) bridging the routed packet to multiple ports in the second VLAN.
  • the present invention provides a switch and method for multicasting a unicast packet by receiving the unicast packet which is a L3 routed packet at a port in a first VLAN. Then, the switch and method route the received unicast packet to a loopback port in a second VLAN, where the routing operation further includes: (1) looking-up a destination MAC address of the received unicast packet within a L2 table and determining that the destination MAC address is a router MAC address; (2) looking-up a destination IP address of the received unicast packet within a L3 table and after a match is found modifying the received unicast packet as follows: (i) replacing the router MAC address with a multicast MAC address; (ii) modifying a VLAN tag from the first VLAN to the second VLAN; and (iii) decrementing a TTL value.
  • the switch and method receive the routed packet which is now a L2 multicast packet from the loopback port in the second VLAN. Finally, the switch and method bridge the routed packet to multiple ports in the second VLAN, where the bridging operation further includes: (1) looking-up a destination MAC address of the received routed packet within the L2 table and determining that the destination MAC address is not present within the L2 table because the destination MAC address is a multicast MAC address; and (2) flooding copies of the routed packet to the multiple ports in the second VLAN.
  • FIG. 1 is a block diagram illustrating the basic components of a switch that has been configured to multicast a received unicast packet in accordance with the present invention
  • FIG. 2 is a flowchart illustrating the basic steps of a method for multicasting a unicast packet in accordance with the present invention.
  • FIGS. 3A-3D are diagrams which illustrate the different fields of a packet when it is received, routed and multicast by the switch in accordance with the present invention.
  • FIGS. 1 and 2 there are respectively shown a block diagram of a switch 100 and a flowchart of a method 200 that can be implemented by the switch 100 to multicast a unicast packet in accordance with the present invention (note: a packet is also considered to be traffic by those skilled in the art and as such the two terms may be used interchangeably herein).
  • the switch 100 receives a unicast packet 102 (which has a router MAC address and is a L3 routed packet 102 ) at a front panel port 104 in a first VLAN A (see point 1 and step 202 ).
  • the switch 100 has an ingress/forwarding logic unit 106 that routes the received packet 102 ′ (which has been modified to have a multicast MAC address) to a loopback port 108 (e.g., programmed to be in a PHY loopback mode) in a second VLAN D (see point 2 and step 204 ) (note: the loopback port 108 can occur in, for example, chip logic, PHY, MAC or even be externally cabled). Then, the switch 100 and in particular the ingress/forwarding logic unit 106 receives the routed packet 102 ′ (which is now a L2 multicast packet) from the loopback port 108 in the second VLAN D (see point 3 and step 206 ).
  • a loopback port 108 e.g., programmed to be in a PHY loopback mode
  • the switch 100 and in particular the ingress/forwarding logic unit 106 receives the routed packet 102 ′ (which is now a L2 multicast packet) from the loopback port 108 in the
  • the switch 100 and in particular the ingress/forwarding logic unit 106 multicasts/bridges/floods copies of the routed packet 102 ′′ to multiple ports 110 a , 110 b . . . 110 n in the second VLAN D (see point 4 and step 208 ).
  • An exemplary scenario is described next to help further explain how the switch 100 by implementing method 200 can receive the unicast packet 102 (which has a router MAC address) in a first VLAN A and then multicast the received packet 102 ′′ (after it has been routed and modified to have a multicast MAC address) from a second VLAN D in accordance with the present invention.
  • the switch 100 has a free port (e.g., port 108 ) which is then configured to be in a PHY loopback mode (via internal programming of software).
  • the loopback port 108 is configured to be an 8021Q port and is tagged in all of the VLANs within the switch 100 (via internal programming of software) (note: an 8021Q port sends tagged packets which also indicate the originating VLAN A and the traversing VLAN D).
  • the switch 100 has a NI 112 which an operator can use a CLI to configure a L2 table 114 and a L3 table 116 located therein which makes it possible to implement the present invention (note: how these particular tables are used will be discussed in detail below).
  • the L2 table 114 e.g., the L2_Entry_Table 114
  • the L2 table 114 is configured as follows:
  • L3 table 116 e.g., the L3_Entry_IPV4 Unicast_Table 116 , the L3 DEFIP_Table 116 , the EGR_L3_NEXT_HOP_Table 116 , the ING_L3_NEXT_HOP_Table 116 and the EGR_L3_INTF_Table 116 ) has entries which are configured as follows:
  • 01:00:00:00:00:02 is the multicast MAC address for the modified routed packet 102′.
  • the next hop port is identified as Port L (26) which is the loopback port 108.
  • FIG. 3A illustrates the relevant fields that are associated with an exemplary incoming packet 102 which include: (1) Destination MAC address (which is a Router MAC address); (2) SA MAC address; (3) VLAN tag (which is VLAN A); (4) IP Type; TTL (which is set at 64); (5) Src IP address (which is Src IP A); and (6) Dst IP address (which is Dst IP D).
  • the ingress/forwarding logic unit 106 takes the Destination MAC address (in this example 00:d0:95:81:bb:00) from packet 102 and looks-up the L2-Entry-Table 114 .
  • the L2-Entry Table 114 has this Destination MAC address with the L3 bit set which indicates that this Destination MAC address is a router MAC address.
  • the ingress/forwarding logic unit 106 forwards the packet 102 through the L3 Routing Process where the Dst IP address D (in this example 128.251.40.22) is looked-up in the L3-Entry-IPV4-Unicast-Table 116 or L3-DEFIP_Table 116 .
  • the packet 102 is modified as follows: (1) replace the router MAC address (00:d0:95:81:bb:00) with a multicast MAC address (01:00:00:00:00:02) (see the EGR_L3_NEXT_HOP field in the L3 table 116 ); (2) change the VLAN tag from the VLAN A to VLAN D (see the EGR_L3 INTF field in the L3 table 116 ) (note: the router MAC address is needed in this field because whenever a packet is routed the source MAC address of the packet is changed to the MAC address of the current switch which routed the packet); and (3) decrement the TTL from 64 to 63.
  • 3B illustrates the relevant fields that are associated with an exemplary modified incoming packet 102 ′ which include: (1) Destination MAC address (which is a multicast MAC address); (2) SA MAC address; (3) VLAN tag (which is VLAN D); (4) IP Type; TTL (which is set at 63); (5) Src IP address (which is Src IP A); and (6) Dst IP address (which is Dst IP D).
  • the packet 102 is determined to be routed. This implies that the destination of the packet 102 is not explicitly obtained from the packet 102 but from the routing L3 table 116 (e.g., L3_Entry_IPV4_Unicast_Table 116 , next hop table 116 , LPM table 116 ).
  • the routing L3 table 116 is looked up by using the destination IP address within the packet 102 . If a match is found in the routing L3 table 116 , then the packet 102 is routed to the destination port 108 as indicated by the ING-L3-NEXT_HOP field in the L3 table 116 .
  • the packet 102 When the packet 102 is routed, the packet 102 is modified so that its destination MAC address becomes the next hop MAC address (or the multicast MAC address).
  • the VLAN tag of the packet 102 is also changed from the ingress VLAN A to the egress VLAN D. Plus, the TTL on the packet 102 is also decremented by one as required by ARP to prevent loops.
  • the packet 102 is considered a L3 packet when it first ingresses the switch 100 and when it is routed it is still considered a L3 packet.
  • the routed packet 102 ′ has egressed out the loopback port 108 or if one looked at this from a different view point the routed packet 102 ′ has ingressed the switch 100 via the loopback port 108 (note: recall that loopback port 108 is also associated with VLAN D).
  • the routed packet 102 ′ is now considered a L2 packet within the log of the switch 100 .
  • 3C illustrates the relevant fields that are associated with an exemplary loopbacked packet 102 ′ which include: (1) Destination MAC address (which is a multicast MAC address); (2) SA MAC address (3) VLAN tag (which is VLAN D); (4) IP Type; TTL (which is set at 63); (5) Src IP address (which is Src IP A); and (6) Dst IP address (which is Dst IP D).
  • the loopbacked packet 102 ′ is the same as the modified packet 102 ′ but the fact is that the packet 102 ′ has egressed the loopback port 108 at point 2 and again ingressed the loopback port 108 at point 3 .
  • the loopbacked packet 102 ′ is a new packet and as such goes through the forwarding logic again as will be discussed in detail in the following paragraph.
  • the ingress/forwarding logic unit 106 takes the Destination MAC address (in this example 01:00:00:00:00:02) from the loopbacked packet 102 ′ and looks-up the L2_Entry_Table 114 .
  • the Destination MAC address is a multicast MAC address which would not be present in the L2_Entry_Table 114 .
  • the ingress/forwarding logic unit 106 floods copies of the loopbacked packet 102 ′ in Vlan D.
  • FIG. 3D illustrates the relevant fields that are associated with an exemplary bridged packet 102 ′′ which include: (1) Destination MAC address (which is a multicast MAC address); (2) SA MAC address; (3) VLAN tag (which is VLAN D); (4) IP Type; TTL (which is set at 63); (5) Src IP address (which is Src IP A); and (6) Dst IP address (which is Dst IP D).
  • Destination MAC address which is a multicast MAC address
  • SA MAC address which is VLAN D
  • VLAN tag which is VLAN D
  • IP Type which is set at 63
  • Src IP address which is Src IP A
  • Dst IP address which is Dst IP D
  • the destination MAC address does not need to be a multicast MAC address instead any MAC address which does not exist in the MAC table could be used.
  • the multicast MAC address was used in this exemplary implementation so that the software can easily determine when to provide the desired multicasting behavior.
  • the L2 Multicast table 114 can be programmed to multicast the packet 102 out selective ports of the second VLAN D.
  • the L2MC_PTR can be programmed to point to an entry in the L2MC table.
  • the PORT_BITMAP field in the L2MC table indicates the ports the packet is to be multicast out on and is referenced when the destination MAC is a MULTICAST MAC (note: flooding and multicasting are the same when the packet is sent to all of the ports in a VLAN but the term multicasting and not flooding is used to indicate the forwarding of the packet to selected ports in a VLAN).
  • the present invention has several different applications in which it could be used and two of those applications are as follows (for example).
  • Server Farms can have multiple servers which require redundant backup of the data stream (packets).
  • the servers could reside on separate ports (output ports of VLAN D) of the switch 100 but they each would receive the same data (packets) simultaneously, at wire rate, with very little configuration and very little resource overhead.
  • Redundant Firewalls Redundant firewalls need to see the same traffic (packets), so that they can provide redundancy. With the present invention, the switch 100 can route the data (packets) out to both firewalls simultaneously with no CPU overhead, as the routing is done in hardware.
  • the present invention has several different alternatives where a switch can receive a unicast packet (which has a router MAC address) in a first VLAN and then multicast/flood copies of the packet (after it had been routed and modified to have a multicast MAC address) from a second VLAN.
  • a switch can receive a unicast packet (which has a router MAC address) in a first VLAN and then multicast/flood copies of the packet (after it had been routed and modified to have a multicast MAC address) from a second VLAN.
  • the present invention could be expanded to cover multi-chip systems, where the switch 100 can use a loopback port that is located on another chip (note: the switch 100 described above was assumed to have one chip that was associated with the aforementioned VLANS, ports, loopback port, ingress/forwarding logic unit, and routing tables).
  • the routing tables in one chip can be configured to route the packet to a loopback port on a remote chip, if the local chip does not have a free loopback port. The packet would traverse from the local chip to the remote chip, using the same mechanism it does for normal routing, viz. fabric/HiGig ports of the switch 100 .
  • the current implementation of the switch 100 uses a single loopback port 108 to route packets 102 that are received at all of the front panel ports 104 which are associated with VLAN A.
  • This implementation where only one loopback port is used can reduce the bandwidth available to individual data streams (packets 102 ) because there are multiple front panel ports 104 associated with VLAN A which can receive the data streams.
  • the switch 100 can have multiple loopback ports which are configured as a single linkagg. This results in the switch 100 essentially having a loobacked Linkagg. In this case, the routing tables would now be configured to route the traffic (packets) to the linkagg, as opposed to a single loopback port.
  • the switch 100 could be configured to have multiple ports to be in a loopback mode, and configured to have the routing tables point to an ECMP table which would cause the packets 102 to use an ECMP route (based on a hashing scheme) where different loopback ports would be selected based on different hashings.
  • the present invention can also be extended since it is now possible for a FFP (Fast Filter Processor) to classify/process a packet twice because it ingresses the switch 100 two different times (see point 1 and 3 ).
  • the FFP can now classify the packet twice and thus apply multiple rules to the same packet (pre-routing and post routing rules).
  • the FFP/TCAM on Firebolt chips currently process packets on the ingress, pre-routing.
  • the present invention enables an operator to use the FFP to process a packet a second time if desired after it has been routed. As a result, the operator could now apply policies which, for example, prioritize or rate-limit the traffic (packet) if it is destined to a certain next hop. Without the loopback method 200 of the present invention this is not possible to do today.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Small-Scale Networks (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

A switch and a method are described herein that are capable of performing the following steps: (a) receiving the unicast packet which is a L3 routed packet at a port in a first Virtual Local Area Network (VLAN); (b) routing the received packet to a loopback port in a second VLAN; (c) receiving the routed packet which is now a L2 multicast packet from the loopback port in the second VLAN; and (d) bridging the routed packet to multiple ports in the second VLAN.

Description

    CLAIMING BENEFIT OF PRIOR FILED U.S. APPLICATION
  • This application claims the benefit of U.S. Provisional Application Ser. No. 60/869,164 filed on Dec. 8, 2006 and entitled “Multicasting Unicast Traffic/Multiple Classification of a Packet”. The contents of this document are hereby incorporated by reference herein.
    • TECHNICAL FIELD
  • The present invention relates to a switch that receives a unicast packet (which has a routed Media Access Control (MAC) address) in a first Virtual Local Area Network (VLAN) and then multicasts/floods/bridges copies of the packet (after it has been modified to have a multicast MAC address) from a second VLAN.
    • BACKGROUND
  • The following abbreviations are herewith defined, at least some of which are referred to in the following description associated with the prior art and the present invention.
    • ARP Address Resolution Protocol CLI Command Line Interface CPU Central Processing Unit ECMP Equal Cost Multi-Path IP Internet Protocol LPM Lowest Prefix Match MAC Media Access Control NI Network Interface Card SA Source Address TTL Time to Live VLAN Virtual Local Area Network
  • It would be desirable to have a switch that can receive a unicast packet (which has a router MAC address) in a first VLAN and then multicast/flood copies of that packet from a second VLAN. The ability to multicast a unicast packet (e.g., traffic, data stream) in this manner would be desirable in a wide variety of applications including, for example, server farms and redundant firewalls. In the first case, it would be desirable if a user can have their switch multicast the received unicast packet to multiple servers because each of the servers need to receive a redundant backup of the unicast packet. In the second case, it would be desirable if a user can have their switch multicast the received unicast packet to redundant firewalls because each of the firewalls need to receive the same packets so that they can provide the necessary redundancy.
  • The traditional switches cannot receive unicast packets at one VLAN and then multicast the packets at a second VLAN because: (1) the packet is routed; (2) the packet does not have a broadcast MAC address as the destination MAC address; (3) the packet does not have a multicast MAC address as the destination MAC address; and (4) the packet does not have a multicast IP address as the destination IP address. Accordingly, there has been and is a need to address this particular shortcoming and other shortcomings which are associated with the traditional switches. This need and other needs are satisfied by the present invention.
    • SUMMARY
  • In one aspect, the present invention provides a switch and method for multicasting a unicast packet by: (a) receiving the unicast packet which is a L3 routed packet at a port in a first VLAN; (b) routing the received packet to a loopback port in a second VLAN; (c) receiving the routed packet which is now a L2 multicast packet from the loopback port in the second VLAN; and (d) bridging the routed packet to multiple ports in the second VLAN.
  • In another aspect, the present invention provides a switch and method for multicasting a unicast packet by receiving the unicast packet which is a L3 routed packet at a port in a first VLAN. Then, the switch and method route the received unicast packet to a loopback port in a second VLAN, where the routing operation further includes: (1) looking-up a destination MAC address of the received unicast packet within a L2 table and determining that the destination MAC address is a router MAC address; (2) looking-up a destination IP address of the received unicast packet within a L3 table and after a match is found modifying the received unicast packet as follows: (i) replacing the router MAC address with a multicast MAC address; (ii) modifying a VLAN tag from the first VLAN to the second VLAN; and (iii) decrementing a TTL value. Thereafter, the switch and method receive the routed packet which is now a L2 multicast packet from the loopback port in the second VLAN. Finally, the switch and method bridge the routed packet to multiple ports in the second VLAN, where the bridging operation further includes: (1) looking-up a destination MAC address of the received routed packet within the L2 table and determining that the destination MAC address is not present within the L2 table because the destination MAC address is a multicast MAC address; and (2) flooding copies of the routed packet to the multiple ports in the second VLAN.
  • Additional aspects of the invention will be set forth, in part, in the detailed description, figures and any claims which follow, and in part will be derived from the detailed description, or can be learned by practice of the invention. It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention as disclosed.
    • BRIEF DESCRIPTION OF THE DRAWINGS
  • A more complete understanding of the present invention may be obtained by reference to the following detailed description when taken in conjunction with the accompanying drawings wherein:
  • FIG. 1 is a block diagram illustrating the basic components of a switch that has been configured to multicast a received unicast packet in accordance with the present invention;
  • FIG. 2 is a flowchart illustrating the basic steps of a method for multicasting a unicast packet in accordance with the present invention; and
  • FIGS. 3A-3D are diagrams which illustrate the different fields of a packet when it is received, routed and multicast by the switch in accordance with the present invention.
    •  DETAILED DESCRIPTION
  • Referring to FIGS. 1 and 2, there are respectively shown a block diagram of a switch 100 and a flowchart of a method 200 that can be implemented by the switch 100 to multicast a unicast packet in accordance with the present invention (note: a packet is also considered to be traffic by those skilled in the art and as such the two terms may be used interchangeably herein). In operation, the switch 100 receives a unicast packet 102 (which has a router MAC address and is a L3 routed packet 102) at a front panel port 104 in a first VLAN A (see point 1 and step 202). The switch 100 has an ingress/forwarding logic unit 106 that routes the received packet 102′ (which has been modified to have a multicast MAC address) to a loopback port 108 (e.g., programmed to be in a PHY loopback mode) in a second VLAN D (see point 2 and step 204) (note: the loopback port 108 can occur in, for example, chip logic, PHY, MAC or even be externally cabled). Then, the switch 100 and in particular the ingress/forwarding logic unit 106 receives the routed packet 102′ (which is now a L2 multicast packet) from the loopback port 108 in the second VLAN D (see point 3 and step 206). Thereafter, the switch 100 and in particular the ingress/forwarding logic unit 106 multicasts/bridges/floods copies of the routed packet 102″ to multiple ports 110 a, 110 b . . . 110 n in the second VLAN D (see point 4 and step 208). An exemplary scenario is described next to help further explain how the switch 100 by implementing method 200 can receive the unicast packet 102 (which has a router MAC address) in a first VLAN A and then multicast the received packet 102″ (after it has been routed and modified to have a multicast MAC address) from a second VLAN D in accordance with the present invention.
  • In the exemplary scenario, assume the switch 100 has a free port (e.g., port 108) which is then configured to be in a PHY loopback mode (via internal programming of software). In addition, the loopback port 108 is configured to be an 8021Q port and is tagged in all of the VLANs within the switch 100 (via internal programming of software) (note: an 8021Q port sends tagged packets which also indicate the originating VLAN A and the traversing VLAN D). Moreover, the switch 100 has a NI 112 which an operator can use a CLI to configure a L2 table 114 and a L3 table 116 located therein which makes it possible to implement the present invention (note: how these particular tables are used will be discussed in detail below). Assume the L2 table 114 (e.g., the L2_Entry_Table 114) is configured as follows:
  • L2 TABLE
    L2 Entry1
    00:d0:95:81:bb:00 L3 = 1
  • And, assume the L3 table 116 (e.g., the L3_Entry_IPV4 Unicast_Table 116, the L3 DEFIP_Table 116, the EGR_L3_NEXT_HOP_Table 116, the ING_L3_NEXT_HOP_Table 116 and the EGR_L3_INTF_Table 116) has entries which are configured as follows:
  • L3 TABLE2
    L3_ENTRY_IPV4 UNICAST
    IP Addr. = IP D 128.251.40.22
    Next Hop Index = 1
    EGR_L3_NEXT_HOP3
    MAC ADDRESS = 01:00:00:00:00:02
    INTF_NUM = 1
    ING_L3_NEXT_HOP4
    MODULEID, PORT_TGID = Port L (26)
    EGR_L3_INTF
    MAC ADDRESS FOR SA replacement = Router MAC
    00:d0:95:81:bb:00
    VID = VLAN D
    Note 1: 00:d0:95:81:bb:00 is the Destination MAC address (router MAC address) of incoming packet 102.
    Note 2: To populate the L3 table 116, the operator configures the ARP for IP address D using the CLI as follows: arp 128.251.40.22 01:00:00:00:00:02 (where IP D = 128.251.40.22 and multicast MAC = 01:00:00:00:00:02).
    Note 3: 01:00:00:00:00:02 is the multicast MAC address for the modified routed packet 102′.
    Note 4: The next hop port is identified as Port L (26) which is the loopback port 108.
  • At point 1, the packet 102 (which is destined to IP address D) originally ingresses the switch 100 at port 104 in VLAN A (see FIG. 1). FIG. 3A illustrates the relevant fields that are associated with an exemplary incoming packet 102 which include: (1) Destination MAC address (which is a Router MAC address); (2) SA MAC address; (3) VLAN tag (which is VLAN A); (4) IP Type; TTL (which is set at 64); (5) Src IP address (which is Src IP A); and (6) Dst IP address (which is Dst IP D).
  • At point 2, the ingress/forwarding logic unit 106 takes the Destination MAC address (in this example 00:d0:95:81:bb:00) from packet 102 and looks-up the L2-Entry-Table 114. The L2-Entry Table 114 has this Destination MAC address with the L3 bit set which indicates that this Destination MAC address is a router MAC address. As a result, the ingress/forwarding logic unit 106 forwards the packet 102 through the L3 Routing Process where the Dst IP address D (in this example 128.251.40.22) is looked-up in the L3-Entry-IPV4-Unicast-Table 116 or L3-DEFIP_Table 116. A match is found for Dst IP address D in the L3 routing table, at which point, the ingress/forwarding logic unit 106 modifies the packet 102 and egresses the modified packet 102′ out the next hop port 108 (loopback port 108). The packet 102 is modified as follows: (1) replace the router MAC address (00:d0:95:81:bb:00) with a multicast MAC address (01:00:00:00:00:02) (see the EGR_L3_NEXT_HOP field in the L3 table 116); (2) change the VLAN tag from the VLAN A to VLAN D (see the EGR_L3 INTF field in the L3 table 116) (note: the router MAC address is needed in this field because whenever a packet is routed the source MAC address of the packet is changed to the MAC address of the current switch which routed the packet); and (3) decrement the TTL from 64 to 63. FIG. 3B illustrates the relevant fields that are associated with an exemplary modified incoming packet 102′ which include: (1) Destination MAC address (which is a multicast MAC address); (2) SA MAC address; (3) VLAN tag (which is VLAN D); (4) IP Type; TTL (which is set at 63); (5) Src IP address (which is Src IP A); and (6) Dst IP address (which is Dst IP D).
  • In point 2, it should be appreciated that when a packet like incoming packet 102 is destined to the router MAC address, the packet 102 is determined to be routed. This implies that the destination of the packet 102 is not explicitly obtained from the packet 102 but from the routing L3 table 116 (e.g., L3_Entry_IPV4_Unicast_Table 116, next hop table 116, LPM table 116). The routing L3 table 116 is looked up by using the destination IP address within the packet 102. If a match is found in the routing L3 table 116, then the packet 102 is routed to the destination port 108 as indicated by the ING-L3-NEXT_HOP field in the L3 table 116. When the packet 102 is routed, the packet 102 is modified so that its destination MAC address becomes the next hop MAC address (or the multicast MAC address). The VLAN tag of the packet 102 is also changed from the ingress VLAN A to the egress VLAN D. Plus, the TTL on the packet 102 is also decremented by one as required by ARP to prevent loops. The packet 102 is considered a L3 packet when it first ingresses the switch 100 and when it is routed it is still considered a L3 packet.
  • At point 3, the routed packet 102′ has egressed out the loopback port 108 or if one looked at this from a different view point the routed packet 102′ has ingressed the switch 100 via the loopback port 108 (note: recall that loopback port 108 is also associated with VLAN D). The routed packet 102′ is now considered a L2 packet within the log of the switch 100. FIG. 3C illustrates the relevant fields that are associated with an exemplary loopbacked packet 102′ which include: (1) Destination MAC address (which is a multicast MAC address); (2) SA MAC address (3) VLAN tag (which is VLAN D); (4) IP Type; TTL (which is set at 63); (5) Src IP address (which is Src IP A); and (6) Dst IP address (which is Dst IP D). As can be seen, the loopbacked packet 102′ is the same as the modified packet 102′ but the fact is that the packet 102′ has egressed the loopback port 108 at point 2 and again ingressed the loopback port 108 at point 3. Thus, even though the contents of the modified packet 102′ and the loopbacked packet 102′ are the same, technically the loopbacked packet 102′ is a new packet and as such goes through the forwarding logic again as will be discussed in detail in the following paragraph.
  • At point 4, the ingress/forwarding logic unit 106 takes the Destination MAC address (in this example 01:00:00:00:00:02) from the loopbacked packet 102′ and looks-up the L2_Entry_Table 114. In this case, the Destination MAC address is a multicast MAC address which would not be present in the L2_Entry_Table 114. As the destination MAC address is not present in the L2_Entry_Table 114 and the ingress/forwarding logic unit 106 is unable to determine the final destination, then the ingress/forwarding logic unit 106 floods copies of the loopbacked packet 102′ in Vlan D. Thus, ports 110 a, 110 b . . . 110 n being members of VLAN D receive a copy of the loopbacked packet 102′ (which is now technically a bridged packet 102″). FIG. 3D illustrates the relevant fields that are associated with an exemplary bridged packet 102″ which include: (1) Destination MAC address (which is a multicast MAC address); (2) SA MAC address; (3) VLAN tag (which is VLAN D); (4) IP Type; TTL (which is set at 63); (5) Src IP address (which is Src IP A); and (6) Dst IP address (which is Dst IP D). At this point, the packet 102 has been routed once and bridged once within the switch 100 but the user perceives the packet 102 has having only been routed once by the switch 100.
  • It should be appreciated that the destination MAC address does not need to be a multicast MAC address instead any MAC address which does not exist in the MAC table could be used. The multicast MAC address was used in this exemplary implementation so that the software can easily determine when to provide the desired multicasting behavior. Plus, if the MAC address is a L2 multicast MAC address then the L2 Multicast table 114 can be programmed to multicast the packet 102 out selective ports of the second VLAN D. In particular, if the MAC address is a L2 multicast MAC, then the L2MC_PTR can be programmed to point to an entry in the L2MC table. And, the PORT_BITMAP field in the L2MC table indicates the ports the packet is to be multicast out on and is referenced when the destination MAC is a MULTICAST MAC (note: flooding and multicasting are the same when the packet is sent to all of the ports in a VLAN but the term multicasting and not flooding is used to indicate the forwarding of the packet to selected ports in a VLAN).
  • The present invention has several different applications in which it could be used and two of those applications are as follows (for example).
  • 1. Server Farms: Server farms can have multiple servers which require redundant backup of the data stream (packets). In this case, the servers could reside on separate ports (output ports of VLAN D) of the switch 100 but they each would receive the same data (packets) simultaneously, at wire rate, with very little configuration and very little resource overhead.
  • 2. Redundant Firewalls: Redundant firewalls need to see the same traffic (packets), so that they can provide redundancy. With the present invention, the switch 100 can route the data (packets) out to both firewalls simultaneously with no CPU overhead, as the routing is done in hardware.
  • In addition, the present invention has several different alternatives where a switch can receive a unicast packet (which has a router MAC address) in a first VLAN and then multicast/flood copies of the packet (after it had been routed and modified to have a multicast MAC address) from a second VLAN. These alternative embodiments are as follows (for example):
  • 1. The present invention could be expanded to cover multi-chip systems, where the switch 100 can use a loopback port that is located on another chip (note: the switch 100 described above was assumed to have one chip that was associated with the aforementioned VLANS, ports, loopback port, ingress/forwarding logic unit, and routing tables). In this alternative embodiment, the routing tables in one chip can be configured to route the packet to a loopback port on a remote chip, if the local chip does not have a free loopback port. The packet would traverse from the local chip to the remote chip, using the same mechanism it does for normal routing, viz. fabric/HiGig ports of the switch 100.
  • 2. The current implementation of the switch 100 uses a single loopback port 108 to route packets 102 that are received at all of the front panel ports 104 which are associated with VLAN A. This implementation where only one loopback port is used can reduce the bandwidth available to individual data streams (packets 102) because there are multiple front panel ports 104 associated with VLAN A which can receive the data streams. To increase the bandwidth, the switch 100 can have multiple loopback ports which are configured as a single linkagg. This results in the switch 100 essentially having a loobacked Linkagg. In this case, the routing tables would now be configured to route the traffic (packets) to the linkagg, as opposed to a single loopback port. In another alternative embodiment, the switch 100 could be configured to have multiple ports to be in a loopback mode, and configured to have the routing tables point to an ECMP table which would cause the packets 102 to use an ECMP route (based on a hashing scheme) where different loopback ports would be selected based on different hashings.
  • 3. The present invention can also be extended since it is now possible for a FFP (Fast Filter Processor) to classify/process a packet twice because it ingresses the switch 100 two different times (see point 1 and 3). In particular, the FFP can now classify the packet twice and thus apply multiple rules to the same packet (pre-routing and post routing rules). For instance, the FFP/TCAM on Firebolt chips currently process packets on the ingress, pre-routing. In some cases it would also be desirable to process the packet after it is routed, after the packet has been modified by the routing process, so as to possibly identify traffic going to different next hops. The present invention enables an operator to use the FFP to process a packet a second time if desired after it has been routed. As a result, the operator could now apply policies which, for example, prioritize or rate-limit the traffic (packet) if it is destined to a certain next hop. Without the loopback method 200 of the present invention this is not possible to do today.
  • Although several embodiments of the present invention has been illustrated in the accompanying Drawings and described in the foregoing Detailed Description, it should be understood that the present invention is not limited to the disclosed embodiments, but is capable of numerous rearrangements, modifications and substitutions without departing from the spirit of the invention as set forth and defined by the following claims.

Claims (22)

1. A method for multicasting a unicast packet, said method comprising the steps of:
receiving the unicast packet which is a L3 routed packet at a port in a first Virtual Local Area Network (VLAN);
routing the received unicast packet to a loopback port in a second VLAN;
receiving the routed packet which is now a L2 multicast packet from the loopback port in the second VLAN; and
bridging the routed packet to multiple ports in the second VLAN.
2. The method of claim 1, wherein said routing step further includes:
looking-up a destination Media Access Control (MAC) address of the received unicast packet within a L2 table and determining that the destination MAC address is a router MAC address;
looking-up a destination Internet Protocol (IP) address of the received unicast packet within a L3 table and after a match is found modifying the received unicast packet as follows:
replacing the router MAC address with a multicast MAC address;
modifying a VLAN tag from the first VLAN to the second VLAN; and
decrementing a Time to Live (TTL) value.
3. The method of claim 1, wherein said bridging step further includes:
looking-up a destination Media Access Control (MAC) address of the received routed packet within a L2 table and determining that the destination MAC address is not present within the L2 table because the destination MAC address is a multicast MAC address; and
flooding copies of the routed packet to the multiple ports in the second VLAN.
4. The method of claim 1, wherein said bridging step further includes multicasting copies of the routed packet to selected multiple ports within the second VLAN if the destination Media Access Control (MAC) address within the received routed packet is a L2 multicast MAC address.
5. The method of claim 1, wherein said loopback port is a tagged loopback port.
6. The method of claim 1, wherein said loopback port is a member of a loopback port linkagg.
7. The method of claim 1, wherein said loopback port is selected from multiple loopback ports by an equal cost multi-path (ECMP) table.
8. The method of claim 1, further comprising a step of processing the routed packet prior to performing the step of bridging the routed packet to multiple ports in the second VLAN.
9. A switch, comprising:
a port that receives an unicast packet which is a L3 routed packet;
said port is in a first Virtual Local Area Network (VLAN);
an ingress/forwarding logic unit that routes the received unicast packet to a loopback port in a second VLAN;
said ingress/forwarding logic unit also receives the routed packet which is now a L2 multicast packet from the loopback port in the second VLAN; and
said ingress/forwarding logic unit also bridges the routed packet to multiple ports in the second VLAN.
10. The switch of claim 9, wherein said ingress/forwarding logic unit routes the received unicast packet to the loopback port in the second VLAN by:
looking-up a destination Media Access Control (MAC) address of the received unicast packet within a L2 table and determining that the destination MAC address is a router MAC address;
looking-up a destination Internet Protocol (IP) address of the received unicast packet within a L3 table and after a match is found modifying the received unicast packet as follows:
replacing the router MAC address with a multicast MAC address;
modifying a VLAN tag from the first VLAN to the second VLAN; and
decrementing a Time to Live (TTL) value.
11. The switch of claim 9, wherein said ingress/forwarding logic unit bridges the routed packet to multiple ports in the second VLAN by:
looking-up a destination Media Access Control (MAC) address of the received routed packet within a L2 table and determining that the destination MAC address is not present within the L2 table because the destination MAC address is a multicast MAC address; and
flooding copies of the routed packet to the multiple ports in the second VLAN.
12. The switch of claim 9, wherein said ingress/forwarding logic unit is able to bridge copies of the routed packet to selected multiple ports within the second VLAN if the destination Media Access Control (MAC) address within the received routed packet is a L2 multicast MAC address.
13. The switch of claim 9, wherein said loopback port is a tagged loopback port.
14. The switch of claim 9, wherein said loopback port is a member of a loopback port linkagg.
15. The switch of claim 9, wherein said ingress/forwarding logic unit interfaces with an equal cost multi-path (ECMP) table to select the loopback port from multiple loopback ports.
16. The switch of claim 9, wherein said ingress/forwarding logic unit is located on a local chip and selects the loopback port which is located on a remote chip if the local chip does not have an available loopback port.
17. The switch of claim 9, further comprising a fast filter processor that processes the routed packet prior to said ingress/forwarding logic unit bridging the routed packet to the multiple ports in the second VLAN.
18. A method for multicasting a unicast packet, said method comprising the steps of:
(a) receiving the unicast packet which is a L3 routed packet at a port in a first Virtual Local Area Network (VLAN);
(b) routing the received unicast packet to a loopback port in a second VLAN, where said routing step further includes:
(1) looking-up a destination Media Access Control (MAC) address of the received unicast packet within a L2 table and determining that the destination MAC address is a router MAC address;
(2) looking-up a destination Internet Protocol (IP) address of the received unicast packet within a L3 table and after a match is found modifying the received unicast packet as follows:
(i) replacing the router MAC address with a multicast MAC address;
(ii) modifying a VLAN tag from the first VLAN to the second VLAN; and
(iii) decrementing a Time to Live (TTL) value; and
(c) receiving the routed packet which is now a L2 multicast packet from the loopback port in the second VLAN; and
(d) bridging the routed packet to multiple ports in the second VLAN, where said bridging step further includes:
(1) looking-up a destination MAC address of the received routed packet within the L2 table and determining that the destination MAC address is not present within the L2 table because the destination MAC address is a multicast MAC address; and
(2) flooding copies of the routed packet to the multiple ports in the second VLAN.
19. The method of claim 18, wherein said loopback port is a tagged loopback port.
20. The method of claim 18, wherein said loopback port is a member of a loopback port linkagg.
21. The method of claim 18, wherein said loopback port is selected from multiple loopback ports by an equal cost multi-path (ECMP) table.
22. The method of claim 18, further comprising a step of processing the routed packet prior to performing the step of bridging the routed packet to multiple ports in the second VLAN.
US11/776,661 2006-12-08 2007-07-12 Multicasting unicast packet/multiple classification of a packet Expired - Fee Related US7940766B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US11/776,661 US7940766B2 (en) 2006-12-08 2007-07-12 Multicasting unicast packet/multiple classification of a packet

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US86916406P 2006-12-08 2006-12-08
US11/776,661 US7940766B2 (en) 2006-12-08 2007-07-12 Multicasting unicast packet/multiple classification of a packet

Publications (2)

Publication Number Publication Date
US20080137660A1 true US20080137660A1 (en) 2008-06-12
US7940766B2 US7940766B2 (en) 2011-05-10

Family

ID=39497944

Family Applications (1)

Application Number Title Priority Date Filing Date
US11/776,661 Expired - Fee Related US7940766B2 (en) 2006-12-08 2007-07-12 Multicasting unicast packet/multiple classification of a packet

Country Status (1)

Country Link
US (1) US7940766B2 (en)

Cited By (38)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7649904B1 (en) * 2008-02-20 2010-01-19 Juniper Networks, Inc. Seamless split-horizon flooding of layer two (L2) network traffic on non-native and mixed architectures
US20100150155A1 (en) * 2008-12-12 2010-06-17 Maria Napierala Methods and apparatus to dynamically store network routes for a communication network
US20100296396A1 (en) * 2009-05-19 2010-11-25 Fujitsu Network Communications, Inc. Traffic Shaping Via Internal Loopback
US7990993B1 (en) * 2008-02-20 2011-08-02 Juniper Networks, Inc. Platform-independent control plane and lower-level derivation of forwarding structures
US20110286393A1 (en) * 2010-05-24 2011-11-24 Broadcom Corporation Communications device
US20130003736A1 (en) * 2011-06-29 2013-01-03 Juniper Networks, Inc. Variable-based forwarding path construction for packet processing within a network device
CN102916893A (en) * 2012-11-14 2013-02-06 迈普通信技术股份有限公司 Device and method for setting internet protocol (IP) multicast retransmission port in three-layer switchboard
CN102916845A (en) * 2011-08-01 2013-02-06 中兴通讯股份有限公司 Multi-path loopback detecting method and exchanger equipment
US8488588B1 (en) * 2008-12-31 2013-07-16 Juniper Networks, Inc. Methods and apparatus for indexing set bit values in a long vector associated with a switch fabric
CN103416026A (en) * 2011-03-04 2013-11-27 日本电气株式会社 Network system, packet processing method, and storage medium
CN104079464A (en) * 2013-03-27 2014-10-01 杭州华三通信技术有限公司 Data transmission method and equipment
US8908686B1 (en) 2010-12-08 2014-12-09 Juniper Networks, Inc. Distributed generation of hierarchical multicast forwarding structures
US20150163140A1 (en) * 2013-12-09 2015-06-11 Edward J. Rovner Method and system for dynamic usage of multiple tables for internet protocol hosts
US20150244543A1 (en) * 2012-08-28 2015-08-27 Mitsubishi Electric Corporation Network system and communication apparatus
US20160043935A1 (en) * 2013-03-08 2016-02-11 Dell Products L.P. Processing of multicast traffic in computer networks
US9281954B2 (en) * 2014-04-29 2016-03-08 Arista Networks, Inc. Method and system for protocol independent multicasting in multichassis link aggregation domains
US20160087887A1 (en) * 2014-09-22 2016-03-24 Hei Tao Fung Routing fabric
US9306804B2 (en) 2013-04-16 2016-04-05 Arista Networks, Inc. Method and system for multichassis link aggregation in-service software update
US20160112301A1 (en) * 2013-05-30 2016-04-21 Nec Corporation Control apparatus, communication system, relay apparatus control method, and program
US9479415B2 (en) * 2007-07-11 2016-10-25 Foundry Networks, Llc Duplicating network traffic through transparent VLAN flooding
US9565138B2 (en) 2013-12-20 2017-02-07 Brocade Communications Systems, Inc. Rule-based network traffic interception and distribution scheme
US9648542B2 (en) 2014-01-28 2017-05-09 Brocade Communications Systems, Inc. Session-based packet routing for facilitating analytics
US9736045B2 (en) 2011-09-16 2017-08-15 Qualcomm Incorporated Systems and methods for network quality estimation, connectivity detection, and load management
US9843520B1 (en) * 2013-08-15 2017-12-12 Avi Networks Transparent network-services elastic scale-out
CN107508773A (en) * 2016-06-14 2017-12-22 景略半导体(上海)有限公司 Port winding method, system and interchanger
US9866478B2 (en) 2015-03-23 2018-01-09 Extreme Networks, Inc. Techniques for user-defined tagging of traffic in a network visibility system
CN107659899A (en) * 2016-07-26 2018-02-02 华为技术有限公司 A kind of multicast service handling method and access point
US10057126B2 (en) 2015-06-17 2018-08-21 Extreme Networks, Inc. Configuration of a network visibility system
US10091075B2 (en) 2016-02-12 2018-10-02 Extreme Networks, Inc. Traffic deduplication in a visibility network
US10129088B2 (en) 2015-06-17 2018-11-13 Extreme Networks, Inc. Configuration of rules in a network visibility system
US10530688B2 (en) 2015-06-17 2020-01-07 Extreme Networks, Inc. Configuration of load-sharing components of a network visibility router in a network visibility system
US10567259B2 (en) 2016-10-19 2020-02-18 Extreme Networks, Inc. Smart filter generator
US10771475B2 (en) 2015-03-23 2020-09-08 Extreme Networks, Inc. Techniques for exchanging control and configuration information in a network visibility system
US10868875B2 (en) 2013-08-15 2020-12-15 Vmware, Inc. Transparent network service migration across service devices
US10880208B1 (en) * 2019-02-11 2020-12-29 Google Llc Offloads for multicast virtual network packet processing in a network interface card
US10911353B2 (en) 2015-06-17 2021-02-02 Extreme Networks, Inc. Architecture for a network visibility system
US10999200B2 (en) 2016-03-24 2021-05-04 Extreme Networks, Inc. Offline, intelligent load balancing of SCTP traffic
US11283697B1 (en) 2015-03-24 2022-03-22 Vmware, Inc. Scalable real time metrics management

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8248928B1 (en) 2007-10-09 2012-08-21 Foundry Networks, Llc Monitoring server load balancing
US9634927B1 (en) 2015-03-13 2017-04-25 Cisco Technology, Inc. Post-routed VLAN flooding
CN108156066B (en) * 2017-12-29 2021-06-29 杭州迪普科技股份有限公司 Message forwarding method and device

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020009083A1 (en) * 2000-06-09 2002-01-24 Broadcom Corporation Gigabit switch with multicast handling
US6760776B1 (en) * 2000-04-10 2004-07-06 International Business Machines Corporation Method and apparatus for processing network frames in a network processor by embedding network control information such as routing and filtering information in each received frame
US20040264380A1 (en) * 2003-06-27 2004-12-30 Broadcom Corporation Distributing information across equal-cost paths in a network
US20050254490A1 (en) * 2004-05-05 2005-11-17 Tom Gallatin Asymmetric packet switch and a method of use
US7298705B2 (en) * 2003-02-05 2007-11-20 Broadcom Corporation Fast-path implementation for a double tagging loopback engine
US20080095160A1 (en) * 2006-10-24 2008-04-24 Cisco Technology, Inc. Subnet Scoped Multicast / Broadcast Packet Distribution Mechanism Over a Routed Network
US7408883B2 (en) * 2004-09-01 2008-08-05 Nettest, Inc. Apparatus and method for performing a loopback test in a communication system
US7792100B2 (en) * 2004-01-16 2010-09-07 Nippon Telegraph And Telephone Corporation User MAC frame transfer method edge transfer device, and program
US7826481B2 (en) * 2004-11-30 2010-11-02 Broadcom Corporation Network for supporting advance features on legacy components

Patent Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6760776B1 (en) * 2000-04-10 2004-07-06 International Business Machines Corporation Method and apparatus for processing network frames in a network processor by embedding network control information such as routing and filtering information in each received frame
US20020009083A1 (en) * 2000-06-09 2002-01-24 Broadcom Corporation Gigabit switch with multicast handling
US20020018489A1 (en) * 2000-06-09 2002-02-14 Broadcom Corporation Gigabit switch supporting improved layer 3 switching
US7298705B2 (en) * 2003-02-05 2007-11-20 Broadcom Corporation Fast-path implementation for a double tagging loopback engine
US20040264380A1 (en) * 2003-06-27 2004-12-30 Broadcom Corporation Distributing information across equal-cost paths in a network
US7792100B2 (en) * 2004-01-16 2010-09-07 Nippon Telegraph And Telephone Corporation User MAC frame transfer method edge transfer device, and program
US20050254490A1 (en) * 2004-05-05 2005-11-17 Tom Gallatin Asymmetric packet switch and a method of use
US7408883B2 (en) * 2004-09-01 2008-08-05 Nettest, Inc. Apparatus and method for performing a loopback test in a communication system
US7826481B2 (en) * 2004-11-30 2010-11-02 Broadcom Corporation Network for supporting advance features on legacy components
US20080095160A1 (en) * 2006-10-24 2008-04-24 Cisco Technology, Inc. Subnet Scoped Multicast / Broadcast Packet Distribution Mechanism Over a Routed Network

Cited By (61)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9479415B2 (en) * 2007-07-11 2016-10-25 Foundry Networks, Llc Duplicating network traffic through transparent VLAN flooding
US7990993B1 (en) * 2008-02-20 2011-08-02 Juniper Networks, Inc. Platform-independent control plane and lower-level derivation of forwarding structures
US7649904B1 (en) * 2008-02-20 2010-01-19 Juniper Networks, Inc. Seamless split-horizon flooding of layer two (L2) network traffic on non-native and mixed architectures
US7936754B2 (en) * 2008-12-12 2011-05-03 At&T Intellectual Property I, L.P. Methods and apparatus to dynamically store network routes for a communication network
US20100150155A1 (en) * 2008-12-12 2010-06-17 Maria Napierala Methods and apparatus to dynamically store network routes for a communication network
US8488588B1 (en) * 2008-12-31 2013-07-16 Juniper Networks, Inc. Methods and apparatus for indexing set bit values in a long vector associated with a switch fabric
US7990873B2 (en) * 2009-05-19 2011-08-02 Fujitsu Limited Traffic shaping via internal loopback
US20100296396A1 (en) * 2009-05-19 2010-11-25 Fujitsu Network Communications, Inc. Traffic Shaping Via Internal Loopback
US20110286393A1 (en) * 2010-05-24 2011-11-24 Broadcom Corporation Communications device
US9225551B2 (en) * 2010-05-24 2015-12-29 Broadcom Corporation Communications device
US9838327B1 (en) 2010-12-08 2017-12-05 Juniper Networks, Inc. Distributed generation of hierarchical multicast forwarding structures
US8908686B1 (en) 2010-12-08 2014-12-09 Juniper Networks, Inc. Distributed generation of hierarchical multicast forwarding structures
US9203758B2 (en) 2011-03-04 2015-12-01 Nec Corporation Network system, packet processing method and recording medium
CN103416026A (en) * 2011-03-04 2013-11-27 日本电气株式会社 Network system, packet processing method, and storage medium
EP2683120A4 (en) * 2011-03-04 2014-09-10 Nec Corp NETWORK SYSTEM, PACKET PROCESSING METHOD, AND STORAGE MEDIUM
US9736036B2 (en) * 2011-06-29 2017-08-15 Juniper Networks, Inc. Variable-based forwarding path construction for packet processing within a network device
US8948174B2 (en) * 2011-06-29 2015-02-03 Juniper Networks, Inc. Variable-based forwarding path construction for packet processing within a network device
US20150146731A1 (en) * 2011-06-29 2015-05-28 Juniper Networks, Inc. Variable-based forwarding path construction for packet processing within a network device
US20130003736A1 (en) * 2011-06-29 2013-01-03 Juniper Networks, Inc. Variable-based forwarding path construction for packet processing within a network device
CN102916845A (en) * 2011-08-01 2013-02-06 中兴通讯股份有限公司 Multi-path loopback detecting method and exchanger equipment
US9736045B2 (en) 2011-09-16 2017-08-15 Qualcomm Incorporated Systems and methods for network quality estimation, connectivity detection, and load management
US9923733B2 (en) * 2012-08-28 2018-03-20 Mitsubishi Electric Corporation Network system and communication apparatus for performing communication among networks having different VLAN settings
US20150244543A1 (en) * 2012-08-28 2015-08-27 Mitsubishi Electric Corporation Network system and communication apparatus
CN102916893A (en) * 2012-11-14 2013-02-06 迈普通信技术股份有限公司 Device and method for setting internet protocol (IP) multicast retransmission port in three-layer switchboard
US20160043935A1 (en) * 2013-03-08 2016-02-11 Dell Products L.P. Processing of multicast traffic in computer networks
US9847931B2 (en) * 2013-03-08 2017-12-19 Dell Products L.P. Processing of multicast traffic in computer networks
CN104079464A (en) * 2013-03-27 2014-10-01 杭州华三通信技术有限公司 Data transmission method and equipment
US9306804B2 (en) 2013-04-16 2016-04-05 Arista Networks, Inc. Method and system for multichassis link aggregation in-service software update
US20160112301A1 (en) * 2013-05-30 2016-04-21 Nec Corporation Control apparatus, communication system, relay apparatus control method, and program
US10742539B2 (en) * 2013-05-30 2020-08-11 Nec Corporation Control apparatus, communication system, relay apparatus control method, and program
US10225194B2 (en) * 2013-08-15 2019-03-05 Avi Networks Transparent network-services elastic scale-out
US9843520B1 (en) * 2013-08-15 2017-12-12 Avi Networks Transparent network-services elastic scale-out
US11689631B2 (en) 2013-08-15 2023-06-27 Vmware, Inc. Transparent network service migration across service devices
US10868875B2 (en) 2013-08-15 2020-12-15 Vmware, Inc. Transparent network service migration across service devices
US20150163140A1 (en) * 2013-12-09 2015-06-11 Edward J. Rovner Method and system for dynamic usage of multiple tables for internet protocol hosts
US9565138B2 (en) 2013-12-20 2017-02-07 Brocade Communications Systems, Inc. Rule-based network traffic interception and distribution scheme
US10069764B2 (en) 2013-12-20 2018-09-04 Extreme Networks, Inc. Ruled-based network traffic interception and distribution scheme
US10728176B2 (en) 2013-12-20 2020-07-28 Extreme Networks, Inc. Ruled-based network traffic interception and distribution scheme
US9648542B2 (en) 2014-01-28 2017-05-09 Brocade Communications Systems, Inc. Session-based packet routing for facilitating analytics
US9281954B2 (en) * 2014-04-29 2016-03-08 Arista Networks, Inc. Method and system for protocol independent multicasting in multichassis link aggregation domains
US20160087887A1 (en) * 2014-09-22 2016-03-24 Hei Tao Fung Routing fabric
US10771475B2 (en) 2015-03-23 2020-09-08 Extreme Networks, Inc. Techniques for exchanging control and configuration information in a network visibility system
US9866478B2 (en) 2015-03-23 2018-01-09 Extreme Networks, Inc. Techniques for user-defined tagging of traffic in a network visibility system
US10750387B2 (en) 2015-03-23 2020-08-18 Extreme Networks, Inc. Configuration of rules in a network visibility system
US11283697B1 (en) 2015-03-24 2022-03-22 Vmware, Inc. Scalable real time metrics management
US10129088B2 (en) 2015-06-17 2018-11-13 Extreme Networks, Inc. Configuration of rules in a network visibility system
US10530688B2 (en) 2015-06-17 2020-01-07 Extreme Networks, Inc. Configuration of load-sharing components of a network visibility router in a network visibility system
US10911353B2 (en) 2015-06-17 2021-02-02 Extreme Networks, Inc. Architecture for a network visibility system
US10057126B2 (en) 2015-06-17 2018-08-21 Extreme Networks, Inc. Configuration of a network visibility system
US10855562B2 (en) 2016-02-12 2020-12-01 Extreme Networks, LLC Traffic deduplication in a visibility network
US10091075B2 (en) 2016-02-12 2018-10-02 Extreme Networks, Inc. Traffic deduplication in a visibility network
US10243813B2 (en) 2016-02-12 2019-03-26 Extreme Networks, Inc. Software-based packet broker
US10999200B2 (en) 2016-03-24 2021-05-04 Extreme Networks, Inc. Offline, intelligent load balancing of SCTP traffic
US12267241B2 (en) 2016-03-24 2025-04-01 Extreme Networks, Inc. Offline, intelligent load balancing of SCTP traffic
CN107508773A (en) * 2016-06-14 2017-12-22 景略半导体(上海)有限公司 Port winding method, system and interchanger
CN107659899A (en) * 2016-07-26 2018-02-02 华为技术有限公司 A kind of multicast service handling method and access point
US10567259B2 (en) 2016-10-19 2020-02-18 Extreme Networks, Inc. Smart filter generator
US10880208B1 (en) * 2019-02-11 2020-12-29 Google Llc Offloads for multicast virtual network packet processing in a network interface card
US11463354B2 (en) 2019-02-11 2022-10-04 Google Llc Offloads for multicast virtual network packet processing in a network interface card
US11765081B2 (en) 2019-02-11 2023-09-19 Google Llc Offloads for multicast virtual network packet processing in a network interface card
US12255813B2 (en) 2019-02-11 2025-03-18 Google Llc Offloads for multicast virtual network packet processing in a network interface card

Also Published As

Publication number Publication date
US7940766B2 (en) 2011-05-10

Similar Documents

Publication Publication Date Title
US7940766B2 (en) Multicasting unicast packet/multiple classification of a packet
US7292573B2 (en) Methods and apparatus for selection of mirrored traffic
US9419817B2 (en) Stitching multicast trees
US6553028B1 (en) Method and apparatus for multicast switching using a centralized switching engine
US6570875B1 (en) Automatic filtering and creation of virtual LANs among a plurality of switch ports
US9130774B2 (en) Data mirroring in a service
US9258219B1 (en) Multi-unit switch employing virtual port forwarding
EP2580894B1 (en) Switch, system and method for forwarding packets
EP1351438A1 (en) IP multicast replication process and apparatus therefore
US11329845B2 (en) Port mirroring over EVPN VXLAN
US20070025276A1 (en) Congruent forwarding paths for unicast and multicast traffic
US10284471B2 (en) AIA enhancements to support lag networks
CN106789759B (en) Message uploading method and exchange chip
US8670320B2 (en) Quality of service routing architecture
US20140044129A1 (en) Multicast packet forwarding in a network
US11233741B1 (en) Replication mode selection for EVPN multicast
US11575541B1 (en) Mapping of virtual routing and forwarding (VRF) instances using ethernet virtual private network (EVPN) instances
EP3465982B1 (en) Bidirectional multicasting over virtual port channel
US20140023074A1 (en) System and method for layer-2 network routing
EP3896902B1 (en) Transfer of secure multicast data traffic over a computing network
US20140177641A1 (en) Satellite Controlling Bridge Architecture
US8111702B1 (en) Configuring route properties for use in transport tree building
US20060176880A1 (en) Mesh mirroring with path tags
Komolafe IP multicast in virtualized data centers: Challenges and opportunities
US20080240114A1 (en) Data Frame Forwarding Method By Data Relay Entity And Data Relay Entity

Legal Events

Date Code Title Description
AS Assignment

Owner name: ALCATEL LUCENT, FRANCE

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:OLAKANGIL, JOSEPH;SANGRONIZ, ROBERT LEON;PAGE, GREGORY G;REEL/FRAME:019548/0402

Effective date: 20070710

FEPP Fee payment procedure

Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

STCF Information on status: patent grant

Free format text: PATENTED CASE

FPAY Fee payment

Year of fee payment: 4

AS Assignment

Owner name: PROVENANCE ASSET GROUP LLC, CONNECTICUT

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:NOKIA TECHNOLOGIES OY;NOKIA SOLUTIONS AND NETWORKS BV;ALCATEL LUCENT SAS;REEL/FRAME:043877/0001

Effective date: 20170912

Owner name: NOKIA USA INC., CALIFORNIA

Free format text: SECURITY INTEREST;ASSIGNORS:PROVENANCE ASSET GROUP HOLDINGS, LLC;PROVENANCE ASSET GROUP LLC;REEL/FRAME:043879/0001

Effective date: 20170913

Owner name: CORTLAND CAPITAL MARKET SERVICES, LLC, ILLINOIS

Free format text: SECURITY INTEREST;ASSIGNORS:PROVENANCE ASSET GROUP HOLDINGS, LLC;PROVENANCE ASSET GROUP, LLC;REEL/FRAME:043967/0001

Effective date: 20170913

FEPP Fee payment procedure

Free format text: MAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

AS Assignment

Owner name: NOKIA US HOLDINGS INC., NEW JERSEY

Free format text: ASSIGNMENT AND ASSUMPTION AGREEMENT;ASSIGNOR:NOKIA USA INC.;REEL/FRAME:048370/0682

Effective date: 20181220

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: 20190510

AS Assignment

Owner name: PROVENANCE ASSET GROUP LLC, CONNECTICUT

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CORTLAND CAPITAL MARKETS SERVICES LLC;REEL/FRAME:058983/0104

Effective date: 20211101

Owner name: PROVENANCE ASSET GROUP HOLDINGS LLC, CONNECTICUT

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CORTLAND CAPITAL MARKETS SERVICES LLC;REEL/FRAME:058983/0104

Effective date: 20211101

Owner name: PROVENANCE ASSET GROUP LLC, CONNECTICUT

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:NOKIA US HOLDINGS INC.;REEL/FRAME:058363/0723

Effective date: 20211129

Owner name: PROVENANCE ASSET GROUP HOLDINGS LLC, CONNECTICUT

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:NOKIA US HOLDINGS INC.;REEL/FRAME:058363/0723

Effective date: 20211129

AS Assignment

Owner name: RPX CORPORATION, CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:PROVENANCE ASSET GROUP LLC;REEL/FRAME:059352/0001

Effective date: 20211129

OSZAR »