Juniper Networks, Inc.

Shraddha Hegde

Salih K A

Rajesh Shetty Manur

William Britto Arimboor Joseph

Kapil Arora

Pushpasis Sarkar

Ronald P Bonica

Hannes Gredler

Bharath RadhaKrishna Bhat

Sri Karthik Goud Gadela

Srihari Ramachandra Sangli

Russ White

Zhaohui Zhang

Harish Sitaraman

Samson P Ninan

Parag Kaneriya

Harish Raghuveer

Jonathan C Barth

Vishnu Pavan Beeram

Swamy Sadashivaiah Renu Kananda

Abhishek Chakraborty

Jeffrey M Haas

Swamy Sadashivaiah Kananda

Krzysztof Grzegorz Szarkowicz

Zhifang Zeng

Rajendra Prasad Bollam

Kiran Kushalad

Raveendra Torvi

Tarek Saad

John Galen Scudder

Anthony Joseph Li

Chandrasekar Ramachandran

Kaliraj Vairavakkalai

Santosh Pallagatti Kotrabasappa

Ravi I Singh

Yimin Shen

Antoni Bronislaw Przygienda

Harsha Lakshmikanth

Junan Chen

Deepti Nirmalkumarji Rathi

Sudharsana Venkataraman

Wai Tong Louis Chan

Rafal Jan Szarecki

Santosh S Kolenchery

Ahmed R Darwish

Vishnu Pavan Kumar Beeram

Leonard Anthony Giuliano

Antoni B Przygienda

Alampoondi Eswaran Natarajan

Abdul Majid Ansari

Steven M Kensil

Steven Kensil

K A Salih

A disclosed computing device may include (1) a storage device configured to store a database that identifies states of nodes included in a network and (2) circuitry configured to (A) receive one or more packet fragments that account for at least one change made to a state of one of the nodes in a transaction, (B) identify, among the packet fragments, a transaction identifier corresponding to the transaction and an indication of a total number of packet fragments representing the transaction, and (C) update the database to account for the change upon ensuring receipt of all the packet fragments representing the transaction based at least in part on the transaction identifier and the indication. Various other devices, systems, and methods are also disclosed.

Devices, systems, and methods for updating remote databases via flooded packet fragments

A first network device may receive a first advertisement of a network destination from a second network device and may detect multihoming with the second network device. The second network device may detect the multihoming with the first network device. The first network device and the second network may enable egress protection for the multihoming. The first network device may allocate, from a first pool, a protection group identifier for a group of multihomed network devices and may allocate, from a second pool, a network destination identifier for the network destination. The first network device may provide, to a network and the second network device, a second advertisement that includes the protection group identifier and the network destination identifier. The protection group identifier and the network destination identifier may cause the network to direct traffic for the network destination, via the group of multihomed network devices.

Dynamically detecting multihomed network devices and allocating protection group identifiers

A first network device may receive an advertisement that includes a prefix for a second network device, wherein the advertisement is destined for a third network device. The first network device may determine, based on a network topology, whether a next hop is one hop away or multiple hops away. The first network device may selectively modify the advertisement to include a first segment identifier, based on the next hop being one hop away and to generate a first modified advertisement, or may modify the advertisement to include a second segment identifier, based on the next hop being multiple hops away and to generate a second modified advertisement. The first network device may forward the first modified advertisement or the second modified advertisement toward the third network device.

Segment identifiers that support end-to-end segment routing with color extended community and border gateway protocol virtual private network option B

Techniques are described by which a routing protocol, such as border gateway protocol (BGP), is extended to control propagation and importation of information using route targets (RTs) specified as bitmasks that encode link administrative group information. For example, a network control device (e.g., controller) is configured to allocate one or more subset of resources (e.g., nodes or links) of an underlay network to each of one or more virtual networks established over the underlay network. The controller generates a bitmask encoded with link administrative group information of the one or more links. The controller then outputs, to a plurality of provider edge (PE) routers that are participating in a respective virtual network, a routing protocol message to advertise the one or more subset of resources, wherein the routing protocol message includes a route target specified as the bitmask.

Bitmask route target in targeted distribution of information using a routing protocol

A network device may receive topology data identifying a spine and leaf topology of network devices, and may set link metrics to a common value to generate modified topology data. The network device may remove data identifying connections from leaf network devices to any devices outside the topology from the modified topology data to generate further modified topology data, and may process the further modified topology data, with a model, to determine path data identifying paths to destinations. The network device may determine particular path data identifying shorter paths and longer paths to corresponding destinations, and may determine hop counts associated with the paths. The network device may determine whether the hop counts are all odd values, all even values, or odd and even values, and may perform actions based on whether the hop counts are all odd values, all even values, or odd and even values.

Detecting miswirings in a spine and leaf topology of network devices

A network device may receive, from a transmission network device, a link state message associated with an origination network device. The network device may determine an order of a set of one-hop neighbor network devices from the transmission network device. The network device may determine, based on the link state message and the order of the set of one-hop neighbor network devices, whether the network device is to send a copy of the link state message to at least one one-hop neighbor network device of the network device. The network device may send, or refraining from sending, by the network device and based on determining whether the network device is to send the copy of the link state message to the at least one one-hop neighbor network device of the network device, the link state message to the at least one one-hop neighbor network device of the network device.

Distributed flooding technique

In some implementations, a first network device may receive an advertisement from a second network device. The advertisement may be associated with indicating that the second network device is configured to support a particular flex-algorithm. The first network device may identify, in the advertisement, an address of the second network device. The first network device may configure a routing table of the first network device to indicate that the second network device is capable of receiving traffic associated with the particular flex-algorithm based on the address. The first network device may perform, using the routing table, an action associated with routing the traffic associated with the particular flex-algorithm.

Configuration of a network using a flex-algorithm routing mechanism

Techniques are described for using route target constraint to filter routes advertised to a node in a seamless Multiprotocol Label Switching (MPLS) network. For example, a first router of a first network may generate a first border gateway protocol (BGP) message to advertise routing information for a first node of the first network, the first BGP message indicating a transport class and specifying an address-specific route target, the transport class comprising one or more tunnels to the first node that share common characteristics. In response to receiving a second BGP message originated by second node of a second network, the second BGP message comprising the address-specific route target, the first router sends the first BGP message to a second router of the second network for sending to the second node to cause the second node to import the routing information.

Route target constraint to filter routes advertised to a node in a seamless MPLS or seamless SR network

A network device may receive policy data identifying a first segment routing (SR) policy and a second SR policy. The first SR policy may be associated with a first path through a network and a first next hop, and the second SR policy may be associated with a second path through the network and a second next hop. The network device may advertise, to another device, reachability associated with the first next hop and the second next hop, and may receive, from the other device, a packet with a header. The network device may determine, from the header, data identifying the first next hop or the second next hop, without performing a lookup, and may cause the packet to be routed to a destination address, via the first path or the second path, based on the policy data associated with the first next hop or the second next hop.

Seamless segment routing for multiprotocol label switching (MPLS) interworking

Echo or traceroute functionality is supported in a path spanning multiple autonomous systems (ASes) having segment routing (SR) enabled, the path including an ingress node and an egress node, by: (a) obtaining a return label stack to reach the ingress node from either (A) the egress node, or (B) a transit node in the path; (b) obtaining a label stack to reach, from the ingress node, either (A) the egress node, or (B) the transit node; (c) generating a request message including the return label stack; and (d) sending the request message towards either (A) the egress node, or (B) the transit node using the label stack. The example method may further include: (e) receiving, by either (A) the egress node, or (B) the transit node, the request message, wherein the request message includes information for performing a validity check; (f) performing a validity check using the information included in the request message to generate validity information; (g) generating a reply message including the validity information and information from the return label stack; and (h) sending the reply message towards the ingress node using information from the return label stack included in the request message.

Path monitoring system (PMS) controller or ingress node based multiprotocal label switching (MPLS) ping and traceroute in inter-autonomous system (AS) segment routing (SR) networks

A secure IGP topology or other link state topology can be implemented by a network security unit that runs in a centralized environment on servers separate from a network associated with the IGP topology. The network security unit acquires the topology information, such as by participating in IGP or through border gateway protocol with link state (BGP-LS). The network security unit detects possible network problems, such as indicators of potential network attacks. Once an indicator of a potential network attack is detected, the network security unit identifies the node that is compromised. Once the compromised node is identified, the network security unit can report the node for manual or automated intervention. In some aspects, the network security unit can isolate the compromised node by shutting down links connected to the compromised node.

Secure network topology

Ping or traceroute functionality is supported in a path spanning multiple autonomous systems (ASes) having segment routing (SR) enabled, the path including an ingress node in a first autonomous system (AS) and an egress node in an AS other than the first AS, using a reverse path label pair including (1) a node segment identifier (SID) corresponding to an AS Border Router (ASBR) of the second AS (second ASBR), and (2) an egress peer engineering (EPE) SID corresponding to a segment between the second ASBR to an ASBR of the first AS (first ASBR). Responsive to receiving a ping or traceroute request by a router in the second AS, the router generates a ping or traceroute reply including the reverse path label pair. The ping or traceroute reply is forwarded to the second ASBR using the node SID of the reverse path label pair. The ping or traceroute reply is then forwarded from the second ASBR to the first ASBR using the EPE SID of the reverse path label pair. Finally, the ping or traceroute reply can be forwarded (e.g., using standard IP forwarding) from the first ASBR to the headend router.

Ping and traceroute in inter-autonomous system (AS) segment routing (SR) networks without requiring headend router or path monitoring system (PMS) controller knowledge of topology outside of origin AS

Segment identifiers that support end-to-end segment routing with color extended community and border gateway protocol virtual private network option b

Growing community of inventors

Bengaluru, India

Shraddha Hegde