Abstract: This disclosure describes techniques for enabling interoperability between asymmetric and symmetric Integrated Routing and Bridging (IRB) modes. An interfacing component may be configured to receive a first route advertisement from a first edge node in a Layer-2 (L2) fabric. The first route advertisement may correspond to an asymmetric format route, for instance. The interfacing component may be further configured to receive a second route advertisement from a second edge node in a L2/Layer-3 (L3) fabric. The second edge node may be configured for symmetric integrated routing and bridging (IRB). The interfacing component may be configured to re-originate the first route and the second route such that the interfacing component is included as a hop in the resultant routes between the L2 fabric and the L2/L3 fabric.

Abstract: A method is provided in one example embodiment and includes receiving at a controller an Address Resolution Protocol (“ARP”) packet from a source VXLAN Tunnel End Point (“VTEP”) serving a source host and identifying a destination, the source VTEP having assigned thereto a Virtual Network Identifier (“VNI”) identifying a VXLAN network to which the source VTEP and a plurality of other VTEPs belong, the ARP packet being received by the controller via a control plane; determining whether the received ARP packet is a request message; and, if the received ARP packet is a request message, determining whether address information for the identified destination is stored in a cache of the controller.

Abstract: A method is provided in one example embodiment and includes receiving at a controller an Address Resolution Protocol (“ARP”) packet from a source VXLAN Tunnel End Point (“VTEP”) serving a source host and identifying a destination, the source VTEP having assigned thereto a Virtual Network Identifier (“VNI”) identifying a VXLAN network to which the source VTEP and a plurality of other VTEPs belong, the ARP packet being received by the controller via a control plane; determining whether the received ARP packet is a request message; and, if the received ARP packet is a request message, determining whether address information for the identified destination is stored in a cache of the controller.

Abstract: A method is provided in one example embodiment and includes receiving at a controller an Address Resolution Protocol (“ARP”) packet from a source VXLAN Tunnel End Point (“VTEP”) serving a source host and identifying a destination, the source VTEP having assigned thereto a Virtual Network Identifier (“VNI”) identifying a VXLAN network to which the source VTEP and a plurality of other VTEPs belong, the ARP packet being received by the controller via a control plane; determining whether the received ARP packet is a request message; and, if the received ARP packet is a request message, determining whether address information for the identified destination is stored in a cache of the controller.

Abstract: In one embodiment, a method includes obtaining, at a first provider edge (PE) included a plurality of PEs multi-homed to a first customer edge (CE), traffic intended for the first CE, wherein the traffic includes a first indication, the first indication being configured to identify the traffic as flood traffic. A forwarding PE included in the plurality of PEs suitable to use to forward the traffic to the first CE is identified based on identifying traffic as the flood traffic. The method also includes determining whether the first PE is the forwarding PE, and providing the traffic to the first CE using the first PE when it is determined that the first PE is the forwarding PE. When it is determined that the first PE is not the forwarding PE, the traffic is filtered using the first PE.

Abstract: A method is provided in one example embodiment and includes receiving at a controller an Address Resolution Protocol (“ARP”) packet from a source VXLAN Tunnel End Point (“VTEP”) serving a source host and identifying a destination, the source VTEP having assigned thereto a Virtual Network Identifier (“VNI”) identifying a VXLAN network to which the source VTEP and a plurality of other VTEPs belong, the ARP packet being received by the controller via a control plane; determining whether the received ARP packet is a request message; and, if the received ARP packet is a request message, determining whether address information for the identified destination is stored in a cache of the controller.

Abstract: In one embodiment, a packet switching device creates multiple virtual packet switching devices within the same physical packet switching device using virtual machines and sharing particular physical resources of the packet switching device. One embodiment uses this functionality to change the operating version (e.g., upgrade or downgrade) of the packet switching device by originally operating according to a first operating version, operating according to both a first and second operating version, and then ceasing operating according to the first operating version. Using such a technique, a packet switching device can be upgraded or downgraded while fully operating (e.g., without having to reboot line cards and route processing engines).

Abstract: In one embodiment, a method includes obtaining, at a first provider edge (PE) included a plurality of PEs multi-homed to a first customer edge (CE), traffic intended for the first CE, wherein the traffic includes a first indication, the first indication being configured to identify the traffic as flood traffic. A forwarding PE included in the plurality of PEs suitable to use to forward the traffic to the first CE is identified based on identifying traffic as the flood traffic. The method also includes determining whether the first PE is the forwarding PE, and providing the traffic to the first CE using the first PE when it is determined that the first PE is the forwarding PE. When it is determined that the first PE is not the forwarding PE, the traffic is filtered using the first PE.

Abstract: In one embodiment, a packet switching device creates multiple virtual packet switching devices within the same physical packet switching device using virtual machines and sharing particular physical resources of the packet switching device. One embodiment uses this functionality to change the operating version (e.g., upgrade or downgrade) of the packet switching device by originally operating according to a first operating version, operating according to both a first and second operating version, and then ceasing operating according to the first operating version. Using such a technique, a packet switching device can be upgraded or downgraded while fully operating (e.g., without having to reboot line cards and route processing engines).

Abstract: In one embodiment, a packet switching device creates multiple virtual packet switching devices within the same physical packet switching device using virtual machines and sharing particular physical resources of the packet switching device. One embodiment uses this functionality to change the operating version (e.g., upgrade or downgrade) of the packet switching device by originally operating according to a first operating version, operating according to both a first and second operating version, and then ceasing operating according to the first operating version. Using such a technique, a packet switching device can be upgraded or downgraded while fully operating (e.g., without having to reboot line cards and route processing engines).

Abstract: In one embodiment, a packet switching device creates multiple virtual packet switching devices within the same physical packet switching device using virtual machines and sharing particular physical resources of the packet switching device. One embodiment uses this functionality to change the operating version (e.g., upgrade or downgrade) of the packet switching device by originally operating according to a first operating version, operating according to both a first and second operating version, and then ceasing operating according to the first operating version. Using such a technique, a packet switching device can be upgraded or downgraded while fully operating (e.g., without having to reboot line cards and route processing engines).