Cisco Technology, Inc.

Balaji Pitta Venkatachalapathy

Sanjay Kumar Hooda

Ali Sajassi

Dhananjaya Rao

Neeraj Malhotra

Krishnaswamy Muddenahally Ananthamurthy

Keyur Patel

Anantha Ramaiah

Isidor Kouvelas

Victor Manuel Moreno

Prakash C Jain

Rajeev Kumar

Marc Portoles Comeras

Roberto Mitsuo Kobo

Rajagopal Venkatraman

In one embodiment, a method includes receiving, by a route reflector, a subscription request from a first provider edge node in a network and generating a subscription policy for the first provider edge node. The method also includes receiving a first Ethernet Virtual Private Network (EVPN) Type 2 Route from a second provider edge node, assigning a sequence number to the first EVPN Type 2 Route, and communicating the first EVPN Type 2 Route with the sequence number to the first provider edge node. The method further includes receiving a second EVPN Type 2 Route from a third provider edge node, generating an updated sequence number in response to receiving the second EVPN Type 2 Route from the third provider edge node, and communicating the second EVPN Type 2 Route with the updated sequence number to the first provider edge node and the second provider node.

Systems and methods for subscription based selective EVPN route distribution

Methods and devices configure edge nodes of a virtual network overlay to continuously forward data plane traffic flows between client devices of a common subnet over the course of at least some of the edge nodes being EF-configured. TF-configured edge nodes and EF-configured edge nodes both play roles in unilaterally inducing address discovery by sending to client devices address discovery responses that were not prompted by address discovery requests. TF-configured edge nodes then handle ensuing address discovery requests by proxy, and subsequently handle certain traffic flows according to an EF-compatible forwarding mode, while EF-configured edge nodes continue to forward traffic flows by IP routing normally. This averts throughput of data plane traffic over the network overlay being reduced as a side effect of the heterogeneously configured edge nodes, and averts the possibility of client devices broadcasting address discovery protocol requests as a result of remote client devices being unreachable.

Inter-compatible forwarding modes in network fabric overlays

Techniques and apparatus for allowing a network fabric to accept network devices associated with other fabric networks are described. An example technique involves establishing a communication session between a first network node and a first control plane of the network fabric, wherein the first network node supports a second control plane different from the first control plane; First routing information from the first network node is imported into a first routing table of the first control plane. Second routing information from a second network node is imported into a second routing table of the first network node.

Techniques for allowing software defined (SD) network fabrics to accept network devices from other fabric technologies

Techniques for dynamically adapting a router capacity to system needs in a network. The border router may receive a list of summarized prefixes for endpoint devices associated with the router from control-plane nodes. The router may store the list of summarized prefixes in memory of the border router. Once the router receives traffic that is destined for endpoint devices associated with the border router, it may determine that the destination address is included in the summarized prefixes. In some examples, the router may download complete prefixes from the control-plane nodes, and forward the traffic to the destination address indicated by the complete prefixes.

Control plane driven summarization in a network

In one embodiment, a router selects a particular peer from an original update group used with an Exterior Gateway Protocol (EGP) such as Border Gateway Protocol (BGP). The original update group includes a plurality of peers of the router that share a same outbound policy and that receive common update messages, from the router, of routing table information. The router determines that the particular peer is a potential slow peer based on a first type of indicia, wherein a slow peer is a peer that cannot keep up with a rate at which the router generates update messages over a prolonged period of time. The router confirms that one or more second types of indicia are consistent with the particular peer being a slow peer. In response to the confirmation, the router determines that the particular peer is a slow peer.

BGP slow peer detection

Growing community of inventors

Sunnyvale, CA, United States of America

Balaji Pitta Venkatachalapathy