Following on my earlier blog on Northstar here: https://networkzblogger.com/2017/03/17/juniper-northstar-wan-sdn-controller, recently I got chance to work on next release of it which has among other things is ability to initiate P2MP (Point to Multipoint) LSPs. P2MPs are big use case in Media and Broadcast network and ability to create them via controller would be too helpful. However there is a catch. As discussed in my earlier blog, the NorthStar (NS) Controller relies on PCEP (Path Computation Element Protocol) to deploy a path between the PCC router and PCE (Controller). Currently P2MPs are not initiated by PCEP or its standard is not ratified. So Juniper have come up with another way of configuring it and that’s via Netconf. NETCONF provides mechanisms to install, manipulate, and delete the configuration of network devices. Its operations are realized on top of a simple Remote Procedure Call (RPC) layer. The protocol messages are exchanged on top of a secure transport protocol like SSH etc.

In this blog, instead of looking at PCEP based LSPs from Northstar we will explore netconf functionality and what other features have been introduced in new ns version.

Below is our current model which is built using TED (Traffic Engineering Database) by Northstar and if you look closely there are 2 devices which have PCEP session up because they have correct Junos code on it (15.1F6 and later) however all others are having netconf session Up even if they are on Junos 10, 12, 14 etc. which is cool thing. So as long as you have netconf stanza added in Junos config and have ssh connectivity that is all Northstar need to connect to devices.

Lets start by configuring a P2MP LSP via Northstar

You can see 2 options here for provisioning method. One is PCEP and other is Netconf.

We will choose Netconf and fill other bits.

We have kept Path as dynamic however we can choose required path to TE it more. Under Advanced Tab, you will see P2MP Name field, in which we have added the P2MP name.

All others field you can pretty much keep default.

Once you submit it, Northstar will open a netconf session on port 830 towards headend router which is M320 in our case and push and commit the config to it.

You can see above LSP has become Active and its showing the path as well which this LSP is taking. Now one of the biggest difference between PCEP created LSP and one created from Netconf is that Netconf LSPs will be part of startup-config in Junos as the configs are committing to it so it can be slow process getting your LSP up based upon commit time. Also all Netconf created LSPs are basically shown as PCC Controlled. However PCEP just sent LSP state to network to build E2E path rather than config. PCEP LSP config still resides in NS database and LSPs are created within seconds and are PCE Initiated.

M320> show configuration protocols mpls label-switched-path demo-0610
from 10.198.123.203;
to 10.198.123.103;
p2mp demo-0610-p2p;
primary demo-0610.p0 {
 apply-groups demo-0610-p2p;
}

M320> show configuration groups demo-0610-p2p
protocols {
 mpls {
 label-switched-path <*> {
 primary <*> {
 bandwidth 10m;
 priority 7 7;
 }
 }
 }
}

Ok so that’s for P2MP LSPs which is clean. In 3.1.0 one of the issue we found was related to commit process. Suppose you have 10 LSPs to be created from one source to destination. With Netconf, NS will commit 10 times individually for those LSPs which can be time consuming on some of the MX104s, MX80s with less CPU power. Juniper is looking to change this and putting the commit in batches to decrease the overall time and commit process which would be excellent J

So we have seen now how P2MP LSPs are created via Netconf however we haven’t seen how Netconf parameters are configured on NS as with netconf you can see the analytics data as well which is populated by Telemetry. We will see Telemetry in some other blog.

Under Administration -> Device Profiles we have to set the parameters for individual device.

We enable Netconf and add login details and password. You can test the connectivity as well from NS before actually trying to provision the network.

Apart from P2MP, another thing which has been introduced is while provisioning the LSP you can select which routing method you need to choose. There are many methods starting from default to routebyPCC, etc. default means that NS will calculate the path and routebyPCC means routers will calculate the path and NS won’t be having any say in it.

Another new feature which has been introduced in release 3.1.0 is setting the current path as explicit.

So above P2MP LSP I created was just dynamic however if we want to explicitly make this path as Strict so that LSP doesn’t change path based upon the network conditions we can configure it as below.

If we see the CLI now, NS has filled strict path in it.

M320> show configuration protocols mpls path demo-0610.p0
10.177.177.5 strict;
10.0.0.245 strict;

Ok that’s all for this blog. I hope you like it and let me know your views if you are looking at using NS for your network and if you are already, what are your use cases J

 

R

Mohit Mittal