Abstract: Techniques for generating and utilizing overlay-based Border Gateway Protocol (BGP) Operations, Administration, and Maintenance (OAM) packets to detect issues with an underlay network. The techniques may include receiving, from a BGP peer device via a control plane path, an OAM probe indicating a forwarding path to be used for sending the traffic to a destination associated with a prefix. The techniques may also include determining, based at least in part on the OAM probe, that a next-hop device is incapable of being utilized to forward the traffic to the destination, the next-hop device determined based on an origination of the prefix. The techniques may further include performing a policy-based action based at least in part on determining that the next-hop device is incapable of being utilized to forward the traffic to the destination.

Abstract: A method includes generating a visual representation of one or more multicast data trees over a service provider network, each multicast data tree exchanging data between two or more of a plurality of nodes of an entity operating over the service provider network; determining a respective network bandwidth usage over each of the one or more multicast data trees and a network bandwidth waste based on current bandwidth usage of existing data tunnels of one or more multicast data trees and replication distances associated with the plurality of nodes; modifying the one or more multicast data trees based on at least the respective network bandwidth usage over each of the one or more multicast data trees to yield a modification; generating a traffic routing policy to implement the modification; and transmitting a notification to a subset of the plurality of nodes affected by the traffic routing policy.

Abstract: Methods are provided for ensuring that a service node selects a local leaf node to reach remote destinations by leveraging reverse metric to inform the active service node of the topology of the leaf nodes. The methods involve obtaining connection information about a service node. The connection information indicates whether the service node is locally connected or connected via a virtual private network (VPN) tunnel. The methods further involve generating a reverse metric signaling based on the connection information. The reverse metric signaling includes a different metric value for the service node when the service node is locally connected than when the service node is connected via the VPN tunnel. The methods further involve providing the reverse metric signaling to the service node to cause the service node to select an intermediate network device from among a plurality of intermediate network devices to forward data traffic to a destination.

Abstract: Devices and methods are provided for exchanging route type capabilities between peer network devices, for example, Border Gateway Protocol (BGP) speakers, to prevent a BGP session reset when a particular route type is not supported by one of the peer network devices. A network device, that supports a set of route types, receives an announcing message indicating a route type capability of a peer network device. The network device selects a subset of route types supported by the peer network device from the set of route types based on the route type capability of the peer network device. The network device transmits an update message that advertises the subset of route types to the peer network device. Thus, a route type supported by the network device is not included in the update message if the route type is not advertised in the announcing message by the peer network device.

Abstract: Existing Equal Cost Multi-path (ECMP) grouping strategies in a multi-homing network have scalability issues due to limited hardware resources. To address this, devices, systems, methods, and processes for adaptive optimization of ECMP groups are described herein. An optimization logic, coupled to a plurality of network devices, receives a set of route advertisements of the plurality of network devices and allocates a shared ECMP group, including two or more network devices of the plurality of network devices, for at least two ESs based on the set of route advertisements. A next hop list is generated in which the at least two ESs point to the shared ECMP group. The optimization logic may update the next hop list based on link failures or route withdrawal advertisements associated with the two or more network devices included in the shared ECMP group. The ES may be removed from pointing to the shared ECMP group.

Abstract: A method includes generating a visual representation of one or more multicast data trees over a service provider network, each multicast data tree exchanging data between two or more of a plurality of nodes of an entity operating over the service provider network; determining a respective network bandwidth usage over each of the one or more multicast data trees and a network bandwidth waste based on current bandwidth usage of existing data tunnels of one or more multicast data trees and replication distances associated with the plurality of nodes; modifying the one or more multicast data trees based on at least the respective network bandwidth usage over each of the one or more multicast data trees to yield a modification; generating a traffic routing policy to implement the modification; and transmitting a notification to a subset of the plurality of nodes affected by the traffic routing policy.

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: In one embodiment, a device may receive a multicast path trace request for a multicast tree, wherein the device is a mid-node in the multicast tree. The device may perform, based on the device being a mid-node in the multicast tree, an upstream trace of network topology of the multicast tree from the device to a head-node of the multicast tree and a downstream trace of network topology of the multicast tree from the device to at least one tail-node. The device may generate an end-to-end visible topology of the multicast tree based on the upstream trace and the downstream trace. The device may provide the end-to-end visible topology of the multicast tree to an observability manager.

Abstract: In an example method, a head node connected to a source device transmits a multicast data flow from the source device to receiving devices connected to tail nodes using Default MDT. The example method further includes determining that requirements have been met to begin transmitting the multicast data flow using Data MDT. The method may further include determining whether the tail nodes are able to receive the multicast data flow using Data MDT. In response to determining that all the tail nodes are able to receive the multicast data flow using Data MDT, switch to transmitting the multicast data flow to the tail nodes using Data MDT. In response to determining that at least one of the tail nodes is unable to receive the multicast data flow using the Data MDT, continue transmitting the multicast data flow using Data MDT.

Abstract: In one embodiment, a device may receive a multicast path trace request for a multicast tree, wherein the device is a mid-node in the multicast tree. The device may perform, based on the device being a mid-node in the multicast tree, an upstream trace of network topology of the multicast tree from the device to a head-node of the multicast tree and a downstream trace of network topology of the multicast tree from the device to at least one tail-node. The device may generate an end-to-end visible topology of the multicast tree based on the upstream trace and the downstream trace. The device may provide the end-to-end visible topology of the multicast tree to an observability manager.

Abstract: A method includes generating a visual representation of one or more multicast data trees over a service provider network, each multicast data tree exchanging data between two or more of a plurality of nodes of an entity operating over the service provider network; determining a respective network bandwidth usage over each of the one or more multicast data trees and a network bandwidth waste based on current bandwidth usage of existing data tunnels of one or more multicast data trees and replication distances associated with the plurality of nodes; modifying the one or more multicast data trees based on at least the respective network bandwidth usage over each of the one or more multicast data trees to yield a modification; generating a traffic routing policy to implement the modification; and transmitting a notification to a subset of the plurality of nodes affected by the traffic routing policy.

Abstract: Techniques for using more-specific routing to perform scalable Layer-2 (L2) stretching of subnets across hybrid-cloud environments. Routing tables in a public cloud may allow for routes that are more specific than the default local route, and the more-specific routes may be used to send all traffic to a dedicated, cloud router. The more-specific routes are set up for a VPC where a subnet resides such that the more specific-routes cover at least a portion of subnet range. The next hop for the more-specific routes point to the cloud router which is capable of doing host routing and segmentation extension. Thus, traffic originating from endpoints in a VPC is routed to the cloud router, and the cloud router determines whether the traffic is to be re-routed back to a destination endpoint in the VPC (or another cloud location), or sent to a destination endpoint residing in the on-premises site.

Abstract: Techniques for generating and utilizing overlay-based Border Gateway Protocol (BGP) Operations, Administration, and Maintenance (OAM) packets to detect issues with an underlay network. The techniques may include receiving, from a BGP peer device via a control plane path, an OAM probe indicating a forwarding path to be used for sending the traffic to a destination associated with a prefix. The techniques may also include determining, based at least in part on the OAM probe, that a next-hop device is incapable of being utilized to forward the traffic to the destination, the next-hop device determined based on an origination of the prefix. The techniques may further include performing a policy-based action based at least in part on determining that the next-hop device is incapable of being utilized to forward the traffic to the destination.

Abstract: Systems and techniques are provided for synchronizing DHCP snoop information. In some examples, a method can include, performing, by a first PE device from a plurality of PE devices, DHCP snooping of a first plurality of DHCP messages between a DHCP client and a DHCP server, wherein the plurality of PE devices is part of an ethernet segment for multihoming the DHCP client. In some aspects, the method includes determining, based on snooping the first plurality of DHCP messages, an association between an IP address corresponding to the DHCP client and a MAC address corresponding to the DHCP client. In some examples, the method includes sending, by the first PE device to at least one other PE device from the plurality of PE devices, a first route advertisement that includes the association between the IP address corresponding to the DHCP client and the MAC address corresponding to the DHCP client.

Abstract: A method includes creating a first routing table at each of a plurality of provider edge nodes in a first data center, the first routing table including a first sequence number tracking intra-data center movement of the host connected to one of the plurality of provider edge nodes; creating a second routing table at a corresponding gateway of each of a plurality of data centers, the plurality of data centers including the first data center, the second routing table including the first sequence number for the host and a second sequence number for tracking inter-data center movement of the host between the plurality of data centers host; and updating one of (1) the first sequence number when the host makes an intra-data center move, or (2) the second sequence number in the second routing table when the host makes an inter-data center move.

Abstract: Systems and techniques are provided for synchronizing DHCP snoop information. In some examples, a method can include, performing, by a first PE device from a plurality of PE devices, DHCP snooping of a first plurality of DHCP messages between a DHCP client and a DHCP server, wherein the plurality of PE devices is part of an ethernet segment for multihoming the DHCP client. In some aspects, the method includes determining, based on snooping the first plurality of DHCP messages, an association between an IP address corresponding to the DHCP client and a MAC address corresponding to the DHCP client. In some examples, the method includes sending, by the first PE device to at least one other PE device from the plurality of PE devices, a first route advertisement that includes the association between the IP address corresponding to the DHCP client and the MAC address corresponding to the DHCP client.

Abstract: Techniques for using more-specific routing to perform scalable Layer-2 (L2) stretching of subnets across hybrid-cloud environments. Routing tables in a public cloud may allow for routes that are more specific than the default local route, and the more-specific routes may be used to send all traffic to a dedicated, cloud router. The more-specific routes are set up for a VPC where a subnet resides such that the more specific-routes cover at least a portion of subnet range. The next hop for the more-specific routes point to the cloud router which is capable of doing host routing and segmentation extension. Thus, traffic originating from endpoints in a VPC is routed to the cloud router, and the cloud router determines whether the traffic is to be re-routed back to a destination endpoint in the VPC (or another cloud location), or sent to a destination endpoint residing in the on-premises site.

Abstract: The present technology provides a framework for user-guided end-to-end automation of network deployment and management, that enables a user to guide the automation process for any kind of network deployment from the ground up, as well as offering network management, visibility, and compliance verification. The disclosed technology accomplishes this by creating a stateful and interactive virtual representation of a fabric using a customizable underlay fabric template instantiated with user-provided parameter values and network topology data computed from one or more connected network devices. A set of expected configurations corresponding to the user-specified underlay and overly fabric policies is then generated for deployment onto the connected network devices.

Abstract: In one embodiment, a device may receive a multicast path trace request for a multicast tree, wherein the device is a mid-node in the multicast tree. The device may perform, based on the device being a mid-node in the multicast tree, an upstream trace of network topology of the multicast tree from the device to a head-node of the multicast tree and a downstream trace of network topology of the multicast tree from the device to at least one tail-node. The device may generate an end-to-end visible topology of the multicast tree based on the upstream trace and the downstream trace. The device may provide the end-to-end visible topology of the multicast tree to an observability manager.

Abstract: Techniques for using more-specific routing to perform scalable Layer-2 (L2) stretching of subnets across hybrid-cloud environments. Routing tables in a public cloud may allow for routes that are more specific than the default local route, and the more-specific routes may be used to send all traffic to a dedicated, cloud router. The more-specific routes are set up for a VPC where a subnet resides such that the more specific-routes cover at least a portion of subnet range. The next hop for the more-specific routes point to the cloud router which is capable of doing host routing and segmentation extension. Thus, traffic originating from endpoints in a VPC is routed to the cloud router, and the cloud router determines whether the traffic is to be re-routed back to a destination endpoint in the VPC (or another cloud location), or sent to a destination endpoint residing in the on-premises site.