Archive
Juniper Employee , Juniper Employee Juniper Employee
Archive
Northstar at 2016 MPLS World Congress demonstration in support of SPRING based forwarding
Mar 16, 2016

Introduction

 

During the 2016 MPLS WC conference in Paris, FR this past week we gave a demonstration of the Northstar TE ControllerTM learning, controlling and creating SPRING based Traffic Engineering LSPs across a Juniper Network. The Network consisted of seven Juniper vMX routers running ISIS and BGP.

 

The demonstration highlighted several pieces of technology and a number of Northstar’s existing applications such as:

 

  • Dynamic learning of SPRING Adjacency and Node SIDs via ISIS
  • Display of per Link Adjacency SIDs
  • Creation of SPRING TE LSPs via the Path Computation Protocol(PCEP)
  • Creation of diverse pairs of SPRING TE LSPs from different ingress routers using SRLG exclusion via the PCEP
  • Northstar’s maintenance application

 

Demonstration Highlights

 

The following figures and brief explanations will walk you through the demonstration. Figure 1 below shows the SPRING topology of the network. Notice that the user interface allows the operator to see the learned adjacency SIDs via the link table along with the topology display.

 

Figure1.png

                                                  Figure 1: Link Table displaying Adjacency SIDs

 

Creating a SPRING TE LSP is enabled through re-use of Northstar’s existing provisioning application. You simply click on “Provision LSP” and enter source and destination of the LSP along with any other attribute or constraints you want Northstar to consider during its path computation. The figure 2a below shows the UI for creating a SPRING LSP between vmx101 and vmx104 with a bandwidth(BW) of 500Mb. It’s worth noting that Northstar maintains these constraints, such as BW, locally since SPRING does not provide any Connection Admission Control(CAC) within the network.

 

Figure2.png

                                                     Figure 2a: Creating a single SPRING TE LSP

 

As you can see in figure 2b & c below, we now have an active SPRING-TE LSP shown in the Northstar Tunnel table along with an active SPRING-TE LSP to the BGP route, 11.255.0.104, known via vmx104 installed in the inet.3 RIB on vmx101. The SPRING label stack is 299872, 300064 which corresponds to the adjacency SIDs for the path that Northstar computed.

 

figure3.png

                                                         Figure 2b: An active SPRING-TE LSP

 

figure4.png

                                         Figure 2c: Verification on the SPRING TE LSP ingress router

 

Creating diverse pairs of LSPs is also enabled by re-using one of Northstar’s existing applications. An operator simply clicks on the “Provision Diverse LSPs”, enters the desired ingress and egress pairs of routers and any desired constraints as shown in figure 3a below. This example is showing the creation of LSPs between VMX101, vmx103 and vmx102, vmx104 that are site diverse from one another.

 

figure5.png

                                         Figure 3a: Creating Diverse Pairs of SPRING-TE LSPs

 

Verification of the newly created LSPs is similar to the first example with the only difference being that multiple LSPs have been created instead of just one. Figure 3b shows the Northstar console with the two new diverse LSPs while figure 3c shows a slightly different view from the router than the previous example. This figure shows the PCEP’s perspective of the SPRING TE LSPs on the ingress router vmx101. As you can see, the PCEP session is UP and is reporting that 2 LSPs have been externally provisioned. Furthermore, you can see that the LSPs have a SPRING-TE path setup type.

 

figure6.png

                               Figure 3b: Northstar Tunnel table displaying diverse pairs of LSPs

 

figure7.png

                                                 Figure 3c: Ingress router verification via PCEP

 

Last but certainly not least; Northstar’s maintenance application can also be used with SPRING-TE LSPs. If you’re not familiar with this application it enables a user to schedule one or more topology entities for “maintenance”. During the scheduled event time frame, Northstar moves any affected LSPs away from the entities under going maintenance until the event is completed. There are many figures that would be required to show the work flow of a maintenance event so in the interest of brevity, figure 4 below shows the maintenance tab with a completed event.

 

figure8.png

                            Figure 4: Completed maintenance event for the SPRING TE Network

 

For additional information regarding Juniper Network’s Northstar TE Controller and the associated technology that enables this demonstration please see the following links:

 

 

Acknowledgments

Ben Tsai, Sudhir Cheruathur, Balaji Rajagopalan, WuShu Ouyang, Naresh Kumar, Didier Bousser

Apr 13, 2016
ankost403

In figure 2c BGP route has a preference of 5. Is it configured intentionally under protocol BGP and how it avoids recursion that case considering that BGP sessions are established between loopbacks? Or is it a BGP-LS and it's default preference is 5?