Juniper Networks, Inc.

Kaliraj Vairavakkalai

Jeyananth Minto Jeganathan

Natrajan Venkataraman

Chandrasekar Ramachandran

Raghavendra Mallya

Babu Singarayan

Ashutosh K Grewal

Balaji Rajagopalan

Aman Kapoor

Jonathan C Barth

Rafal Jan Szarecki

Vasudevan Navaneetha Krishnan

Nitin Kumar

Shraddha Hegde

Zhaohui Zhang

Nitin Singh

Ashish Gupta

Srihari Ramachandra Sangli

Ryan Bickhart

Lili Wang

Sandesh Kumar Sodhi

Satya Praveen Kumar Pasalapudi

Jevananth M Jeganathan

Techniques are disclosed for disseminating network service-specific mapping information across administrative domains. In one example, a network device receives an indication of a route target and one or more underlay tunnels configured to support a service route. The service route is configured to transport network traffic associated with a first network service of a plurality of network services. The network device defines, based on the indication, a first transport class of a plurality of transport classes. The network device receives a service route for the first network service and stores a correspondence between the service route and the first transport class. The network device receives network traffic associated with the first network service and forwards, based on the correspondence, the network traffic along the underlay tunnels specified by the first transport class.

Service-based transport classes for mapping services to tunnels

Network operators can define port mappings for UDP destination ports and the encapsulated protocol/traffic type (X) in UDP. BGP may be used to notify the UDP destination port-to-traffic type mapping to an encapsulator. A generic UDP encapsulation mechanism (X-in-UDP), where UDP can be used to encapsulate packets of any user configured protocol/traffic type X (e.g., IPv4, IPv6, MPLS, etc.), is described. Primary benefits of using UDP for encapsulation are to leverage UDP port numbers for load-balancing. Generic UDP encapsulation of any protocol/traffic type using user defined port-maps provides flexibility to network operators in constructing different overlay networks. UDP encapsulation helps leverage fine-grade load balancing over Equal-Cost Multipath (ECMP).

X-over-Y tunnel signaling and configuration, and use of configured X-over-Y tunnel(s)

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

An auto-discovery route reflector (auto-discovery-RR) may obtain a route from an originating network device and may update a data structure to include at least some information contained in the route. The auto-discovery-RR may identify, based on the data structure, a plurality of target network devices, wherein the plurality of target network devices includes at least one route reflector (RR) and at least one route reflector client (RR-client). The auto-discovery-RR may send the route to the plurality of target network devices to facilitate establishment of a connection between the originating network device and at least one target network device of the plurality of target network devices.

Automatic discovery of route reflection peering end-points

This disclosure describes techniques for scaling resources that handle, participate, and/or control routing protocol sessions. In one example, this disclosure describes a method that includes instantiating a plurality of containerized routing protocol modules, each capable of storing routing information about a network having a plurality of routers; performing network address translation to enable each of the containerized routing protocol modules to communicate with each of the plurality of routers using a public address associated with the computing system; configuring each of the containerized routing protocol modules to peer with a different subset of the plurality of routers so that each of the containerized routing protocol modules share routing information with a respective different subset of the plurality of routers; and configuring each of the containerized routing protocol modules to peer with each other to share routing information received from the different subsets of the plurality of routers.

Scaling border gateway protocol services

A router configured as an autonomous system border router (ASBR) in a local autonomous system (AS), includes: (1) a control component for communicating and computing routing information, the control component running a Border Gateway Protocol (BGP) and peering with at least one BGP peer device in an outside autonomous system (AS) different from the local AS; and (2) a forwarding component for forwarding packets using forwarding information derived from the routing information computed by the control component, wherein the control component (i) receives reachability information for an external prefix corresponding to a device outside the local AS, and (ii) associates the external prefix, as a BGP next hop (B_NH), an abstract next hop (ANH) that identifies a set of BGP (eBGP) sessions that contains at least one eBGP session over which given external prefix has been learned, each of the at least one eBGP sessions being between the ASBR and a BGP peer device in an AS outside the AS, wherein the device located outside the local AS is reachable via the BGP peer device.

Minimizing or reducing traffic loss when an external border gateway protocol (eBGP) peer goes down

A first network device may generate a layer-3 virtual private network (L3VPN) route advertisement associated with the first network device. The L3VPN route advertisement may include a first portion, associated with a second network device included in an L3VPN with the first network device, for separate transport-layer tunnel and service-layer tunneling, and a second portion, associated with the second network device, for collapsed transport-layer and service-layer tunneling. The first network device may transmit the L3VPN route advertisement.

Interoperability between separate and collapsed service-layer and transport-layer tunnels

In some examples, a method includes receiving, by a first network device, a private label route message from a second network device, the private label route message specifying a private label as a destination, a route distinguisher of an egress network device for the private label, a context protocol next hop address that identifies a private Multiprotocol Label Switching (MPLS) forwarding layer, and a next hop for the private label, determining, by the first network device and based on the private label route message, a label stack having a plurality of labels to use for forwarding traffic to the next hop for the private label, and storing, in a context forwarding table associated with the private MPLS forwarding layer, a private label destination with the label stack as a next hop for reaching the private label.

Signaling private context forwarding tables for a private forwarding layer

The disclosed computer-implemented method for classifying uplink and downlink traffic in networks may include (1) maintaining a routing table that includes a plurality of routes that define paths to a plurality of network destinations in connection with a network, (2) receiving a packet to be routed toward a network destination based at least in part on a route that defines a path to the network destination in connection with the MPLS network, (3) identifying, within the routing table, the route that defines the path to the network destination, (4) determining, based at least in part on the route identified within the routing table, whether the packet represents uplink or downlink traffic, and then (5) classifying the packet as uplink or downlink traffic based at least in part on the determination. Various other methods, systems, and apparatuses are also disclosed.

Method, system, and apparatus for classifying uplink and downlink traffic in networks

A device may receive a set of border gateway protocol labels via a set of corresponding border gateway protocol messages. A border gateway protocol label, of the set of border gateway protocol labels, may be associated with a label descriptor attribute. The label descriptor attribute being associated with providing information regarding a forwarding semantic associated with the border gateway protocol label. The device may select the border gateway protocol label for routing network traffic toward a network device associated with the border gateway protocol label based on the label descriptor attribute. The device may route the network traffic toward the network device based on the border gateway protocol label and after selecting the border gateway protocol label.

Semantic information for labels in border gateway protocol

In one example, a management component executing on a single-chassis network device configures a virtual node with an abstract fabric interface having, as a destination address, identifiers of packet processors (e.g., PTFE-IDs) assigned to the virtual node on the other end of the abstract fabric interface. The management component of the single-chassis network device pre-creates an underlay network by using the fabric links at the packet processor. When the management component creates and connects an abstract fabric interface on the virtual nodes, the management component forms an overlay network and attaches the overlay network to the underlay network, e.g., by programming the forwarding plane packet processor, to connect the virtual nodes. However, users of the network device, external devices, and routing protocols will not view the abstract fabric interface as an overlay interface, but as a regular Ethernet interface (e.g., a Gigabit Ethernet interface).

Growing community of inventors

Fremont, CA, United States of America

Kaliraj Vairavakkalai