Tag Archives: Junos

Juniper Config Backup on GITLAB

Hi All

In this blog, we will see how we can take the backup of router configs and push it to gitlab for version control.

We will take Juniper routers here for example and build the script in Python and run our task as a cronjob on CentOS 7 to automatically backup the configs onto GITLAB.
We will use power of Git here to store the differentials in configs and we can see the differences in Gitlab UI.

So let’s see how we can achieve it.
Before starting with config backup, let’s build the device store on which we will be running the script or in other words backup will be running. For this we are storing the values in YAML file http://yaml.org/ as dictionary. You can either store the values as list or Dictionary in YAML. You can use json also to store the same data instead of YAML.

Yaml file (.yml)
---
# Add devices here in form Hostname: 'ip address'
  Manchester_MX10003: '10.198.206.3'
  Glasgow_MX10003: '10.198.206.6'
  London_MX104: '10.198.206.9'
  Leeds_MX104: '10.198.206.12'
  Bristol_MX104: '10.198.206.15'

Above are the file contents, where we are storing the data as Key, Value pair where Key is hostname of device and Values are its IP Addresses.

Now our data store is done, we can start with Juniper PYez (https://www.juniper.net/documentation/en_US/junos-pyez/topics/concept/junos-pyez-overview.html) to get the configs first.

We will be importing the Pyez modules, set the .yml input file location and run ‘for’ loop on our dictionary. We will store the backup config files as .txt file with hostnames as Title for easy accessibility. Don’t forget to import yaml module as we will be working on yaml file.

from jnpr.junos import Device
from jnpr.junos.exception import ConnectError
import yaml

input_file = '/home/sun/gitlab/device_list.yml'

for key, value in yaml.load(open(input_file)).items():

    dev_username = test
    dev_password = test
    dev = Device(host=value, user=dev_username, passwd=dev_password, port='830')

    try:
        dev.open()
    except ConnectError as err:
        print ("Cannot connect to device: {0}".format(err))
        sys.exit(1)
    except Exception as err:
        print (err)
        sys.exit(1)

    config = str(dev.cli("show configuration | no-more", warning=False))

    #####Create/Write to Config to File

    file_name = key + '.txt'


   dev.close()

That was pretty simple. Let me know if you have any issues. Now let’s work out how to push it to GIT.

We will be using the subprocess module to do this work for us where we will be running series of commands in serial to put the files across the gitlab. You are starting by going into particular directory which is your starting git project directory. You are looking at each branch within your git project using ‘git branch’ command and then checking out a particular branch on which you to work or store the data. In our case it’s Core_Network. Once you have moved to that, you can move into other specific folders and ‘mv’ your backup .txt files into this folder.

Once that is done, you will use git commands, like ‘git add –all’ to add all files as part of staging. ‘git commit –m “some description”’ to commit the files and then use ‘git push’ to push them to remote gitlab server.

Code will be:

from subprocess import PIPE
from subprocess import Popen
import sys
import os
import yaml
cmds =['cd /home/sun/gitlab/athena-test', 'git branch', 'ls -l', 'git checkout " Core_Network"', 'cd "Core Network"', 'cd "Device backups"', 'mv /home/sun/gitlab/*.txt /home/sun/gitlab/athena-test/"Core Network"/"Device backups"/', 'git add --all', 'git commit -m "Updated config files"', 'git push' ]
encoding = 'utf8'
p = Popen('/bin/sh', stdin=PIPE, stdout=PIPE, stderr=PIPE)
for cmd in cmds:
p.stdin.write(cmd + "\n")
p.stdin.close()
#print p.stdout.read()
print "Push to GitLab Completed"

One main thing you have to keep in mind is that you won’t be able to push the files until unless you have some remote servers configured under your server.

For example, mine is below where I have removed certain values and replaced them with xxx, yyy and ip address.. xxx is username, yyy is password and hostname  is gitlab server address.

sun@ $ git remote -v
origin https://xxx:yyy@<hostname>/athena-test.git (fetch)
origin https://xxx:yyy@<hostname>/athena-test.git (push)

Let’s see this in action by changing the config on one of the router.

write@re0.Manchester.MX10003.uk> edit
Entering configuration mode

write@re0.Manchester.MX10003.uk# run show configuration system services ssh
root-login allow;
protocol-version v2;
max-sessions-per-connection 32;
connection-limit 20;
rate-limit 10;

[edit]
write@re0.Manchester.MX10003.uk# set system services ssh connection-limit 10

[edit]
write@re0.Manchester.MX10003.uk# show | compare
[edit system services ssh]
- connection-limit 20;
+ connection-limit 10;

[edit]
write@re0.Manchester.MX10003.uk# commit
commit complete

Run the script now from CentOS Server

sun@ pwd

/home/sun/gitlab

sun@ $ python git_config_backup.py

Successfully Collected Configuration from Device: Bristol_MX104

Successfully Collected Configuration from Device: Manchester_MX10003

Successfully Collected Configuration from Device: Glasgow_MX10003

Successfully Collected Configuration from Device: London_MX104

Successfully Collected Configuration from Device: Leeds_MX104

Push to GitLab Completed

 

You can see config was pushed and if we see the gitlab, it’s clearly showing the difference from the previous backup it had. Red one is one that is removed and Green one is what has been added.

So you can use this utility as version control of your configs and once you are happy with the configs you can push them to master for production use 🙂

 

Gitlab
GitLab side by side comparison

 

One last thing, if you have to run this as a cronjob on Centos, just edit the crontab file using ‘crontab –e’ and add the path to the script and at what particular time you want to run and that’s all.

I hope you liked this blog. Let me know if you have any queries.

 

Regards

Mohit

Advertisements

PCEP Initiated LSP using OpenDayLight and Juniper vMX

Hi All

In this post, we will look at Open day light controller working with Juniper vMXs and how we can use the controller to get the BGP, BGP-LS and PCEP working. Once everything is up and running we will use the Controller to initiate the PCEP initiated MPLS LSPs between 2 VMXs.

Sounds interesting? Let’s see how we can achieve this.

Before I go further, if you want to check anything on PCEP and some of its concept, I did a post on Juniper Northstar Controller some time ago which you can check.

https://networkzblogger.com/2017/03/17/juniper-northstar-wan-sdn-controller/

Below is the topology we will be using where all Juniper VMXs are loaded in Virtual Control Plane mode and they have fxp0 interface in 192.168.71.x subnet. Open day light controller version is Nitrogen and we have booted it on CentOS 7.5 version.

There is Windows VM in same subnet also from where we will run the REST APIs calls to Open day light using POSTMAN App.

Topology Diagram
Topology Diagram

 

We will divide the post into 3 parts.

  • Configuring BGP/BGP-Link state between ODL and 192.168.71.24 VMX-3.
  • Configuring PCEP session between all VMXs and ODL
  • Initiate MPLS LSP from ODL using PCEP

I am assuming that you already know how to start an ODL controller. However if you don’t know let me know and I can help you.

So lets start with 1) Configuring BGP/BGP-Link state between ODL and 192.168.71.24 VMX-3.

If you already don’t know, Open day light versions in recent times doesn’t come auto-installed with all the features. You have to manually add them. You don’t need to download them individually. It’s just you need to activate them.

We will be configure the BGP and BGP-LS on VMX-3 first

Standard BGP config with IPv4 Unicast address family however for BGP-LS we have to enable a separate family traffic-engineering additionally.

root@VMX-3> show configuration protocols bgp
group opendaylight {
 type internal;
 description Controller;
 local-address 192.168.71.24;
 family inet {
 unicast;
 }
 family traffic-engineering {
 unicast;
 }
 peer-as 2856;
 neighbor 192.168.71.22;
}

On ODL side, First install the BGP and restconf feature on karaf console using command

feature:install odl-restconf odl-bgpcep-bgp

Then using REST API we will enable the BGP Router-ID with Link State family

POST URL : 192.168.71.22:8181/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols

POST Request_BGP Router ID
POST Request_BGP Router ID

Then Configure the peer 192.168.71.24 with specific BGP Parameters and families

POST URL: 192.168.71.22:8181/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols/protocol/openconfig-policy-types:BGP/bgp-test-odl/bgp/neighbors

POST Request_BGP Peer
POST Request_BGP Peer

We can check the status of BGP peering off course from VMX side but let’s see what comes up from ODL side

GET URL: 192.168.71.22:8181/restconf/operational/bgp-rib:bgp-rib/rib/bgp-test-odl/peer/bgp:%2F%2F3.3.3.3

GET Request_BGP Peering
GET Request_BGP Peering

From VMX side:

root@VMX-3> show bgp neighbor
Peer: 192.168.71.22+27755 AS 2856 Local: 192.168.71.24+179 AS 2856
 Description: Controller
 Group: opendaylight Routing-Instance: master
 Forwarding routing-instance: master
 Type: Internal State: Established Flags: <Sync>
 Last State: OpenConfirm Last Event: RecvKeepAlive
 Last Error: None
 Options: <Preference LocalAddress LogUpDown AddressFamily PeerAS Refresh>
 Options: <VpnApplyExport DropPathAttributes>
 Address families configured: inet-unicast te-unicast
 Path-attributes dropped: 128
 Local Address: 192.168.71.24 Holdtime: 90 Preference: 170
 Number of flaps: 2
 Last flap event: RecvNotify
 Error: 'Cease' Sent: 0 Recv: 33
 Peer ID: 192.168.71.22 Local ID: 3.3.3.3 Active Holdtime: 90
 Keepalive Interval: 30 Group index: 0 Peer index: 0 SNMP index: 0
 I/O Session Thread: bgpio-0 State: Enabled
 BFD: disabled, down
 NLRI for restart configured on peer: inet-unicast te-unicast

 

BGP-LS configuration we did will be used to advertise the Traffic Engineering database to Controller. You can see the routes advertised using lsdist.0 table in juniper.

Snippet below:

root@VMX-3> show route table lsdist.0
lsdist.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
NODE { AS:2856 Area:0.0.0.0 IPv4:2.2.2.2 OSPF:0 }/1152
 *[OSPF/10] 02:02:38
 Fictitious
NODE { AS:2856 Area:0.0.0.0 IPv4:3.3.3.3 OSPF:0 }/1152
 *[OSPF/10] 02:02:43
 Fictitious
NODE { AS:2856 Area:0.0.0.0 IPv4:4.4.4.4 OSPF:0 }/1152
 *[OSPF/10] 02:02:38
 Fictitious
NODE { AS:2856 Area:0.0.0.0 IPv4:4.4.4.4-192.168.71.26 OSPF:0 }/1152
 *[OSPF/10] 02:02:31
 Fictitious
LINK { Local { AS:2856 Area:0.0.0.0 IPv4:2.2.2.2 }.{ IPv4:192.168.71.23 } Remote { AS:2856 Area:0.0.0.0 IPv4:4.4.4.4-192.168.71.26 }.{ } OSPF:0 }/1152
 *[OSPF/10] 02:02:31
 Fictitious
..
…
…

 

2) Now let’s configure the PCEP

On VMX (This will be repeated on all with change in local address)

root@VMX-3> show configuration protocols pcep
pce odl {
 local-address 192.168.71.24;
 destination-ipv4-address 192.168.71.22;
 destination-port 4189;
 pce-type active stateful;
 lsp-provisioning;
 p2mp-lsp-report-capability;
}

If you have any firewall, make sure to allow port 4189 between Controller and VMXs.

On ODL, we need to install odl-bgpcep-pcep feature

There is no other config to do. As soon as you install this feature, you should see PCEP status up.

Let’s see it from VMX-4

 

root@VMX-4> show path-computation-client status
Session Type            Provisioning Status
odl     Stateful Active On           Up

LSP Summary
 Total number of LSPs : 0
 Static LSPs : 0
 Externally controlled LSPs : 0
 Externally provisioned LSPs : 0/16000 (current/limit)
 Orphaned LSPs : 0

odl (main)
 Delegated : 0
 Externally provisioned : 0

From ODL side:

GET Request_PCEP Status
GET Request_PCEP Status

3)      PCEP Initiated LSP

Now, we will configure the LSP from VMX-3 to VMX-4 between their Loopback IPs.

POST URL: 192.168.71.22:8181/restconf/operations/network-topology-pcep:add-lsp

You can see we haven’t given any ERO while provisioning the LSP. ODL has auto calculated the path and you can verify in VMX-3

PCEP LSP ADD with No Ero
PCEP LSP ADD with No Ero
root@VMX-3> show mpls lsp name test-pcep-2 extensive
Ingress LSP: 1 sessions

4.4.4.4
 From: 3.3.3.3, State: Up, ActiveRoute: 0, LSPname: test-pcep-2
 ActivePath: (primary)
 LSPtype: Externally provisioned, Penultimate hop popping
 LSP Control Status: Externally controlled
 LoadBalance: Random
 Encoding type: Packet, Switching type: Packet, GPID: IPv4
 LSP Self-ping Status : Enabled
 *Primary State: Up, Preference: 200
 Priorities: 0 0
 External Path CSPF Status: external
 SmartOptimizeTimer: 180
 Flap Count: 0
 MBB Count: 0
 Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
 192.168.71.26(Label=0)
 12 May 24 12:10:08.334 Self-ping ended successfully
 11 May 24 12:10:07.830 EXTCTRL LSP: Sent Path computation request and LSP status
 10 May 24 12:10:07.830 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 0 hold 0
 9 May 24 12:10:07.829 Selected as active path
 8 May 24 12:10:07.828 EXTCTRL LSP: Sent Path computation request and LSP status
 7 May 24 12:10:07.828 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 0 hold 0
 6 May 24 12:10:07.828 Up
 5 May 24 12:10:07.828 Self-ping started
 4 May 24 12:10:07.828 Self-ping enqueued
 3 May 24 12:10:07.828 Record Route: 192.168.71.26(Label=0)
 2 May 24 12:10:07.824 Originate Call
 1 May 24 12:10:07.824 EXTCTRL_LSP: Received setup parameters ::
 Created: Thu May 24 12:10:07 2018
Total 1 displayed, Up 1, Down 0

 

You can do various operations like Deleting LSP, Modifying LSP etc from REST API.

One thing which we can’t do at the moment using PCEP is configuring Point to Multipoint LSP as standard is still being drafted for this but I hope it will come out soon.

So that’s all for now, I hope you enjoyed it and let me know your feedback.

 

Regards

Mohit

 

JunOS Automation using PyEZ and Northstar REST APIs

Hi All, in this session lets discuss some Automation.

During past few days, I was looking at some REST APIs for Juniper Northstar Controller. Now Northstar is good for LSP creation/deletion/modification but it cant configure the service E2E. Offcourse that tool is not meant to do all this but Juniper has recently released one beta version of it which can bind your LSP to some service which is excellent step forward. We will see that in a moment. Juniper is leveraging Jinja templates in NS to achieve this binding.

However as I said still service creation is not E2E and for that I thought of adding one more layer of automation and for this I have used Juniper own PyEZ framework which is basically Juniper Python library for automating tasks. Brilliant lets see how this work.

Juniper PyEZ is a framework which is easily grasped by Network engineers and you don’t need to be programmer to fully understand it.

https://www.juniper.net/documentation/en_US/junos-pyez/topics/concept/junos-pyez-overview.html

REST (REpresentational State Transfer) is a set of useful conventions and principals about transfer of information over the World Wide Web.

Many Web services are now using the principals of REST in their design.

When you type a URL into your browser, like http://example.net, your browser software creates an HTTP header that identifies:

  • a desired action: GET (“get me this resource”).
  • a target machine (www.domain-name.com).

The NorthStar RESTful APIs are designed to enable access over HTTP to most of the same data and analytics that are available to you from both the NorthStar GUI and the NorthStar CLI.

https://www.juniper.net/documentation/en_US/northstar3.1.0/information-products/api-ref/api-ref.html

Below is the pictorial representation of what we will be doing. I have used a Windows server on which we will write a script which will talk to Northstar using REST APIs and other components of Juniper Pes using PyEZ.

L2VPN CCC
Automation Model

 

Our Script will be written in Python and you can write the variables value in excel and pass it to the script.

Our excel format:

L2VPN_CCC_Data

import httplib
import json
import time
import re
import sys
import pandas as pd
from jnpr.junos import Device
from jnpr.junos.utils.config import Config
from pprint import pprint

df = pd.read_excel("L2VPN_CCC_Data.xlsx","Sheet1")

PE1 = str((df['PE1'].values.tolist())[0])
PE2 = str((df['PE2'].values.tolist())[0])
Interface_PE1 = str((df['Interface_PE1'].values.tolist())[0])
Unit_PE1 = str((df['Unit_PE1'].values.tolist())[0])
Vlan_PE1 = str((df['Vlan_PE1'].values.tolist())[0])
Interface_PE2 = str((df['Interface_PE2'].values.tolist())[0])
Unit_PE2 = str((df['Unit_PE2'].values.tolist())[0])
Vlan_PE2 = str((df['Vlan_PE2'].values.tolist())[0])
LSP_Name_PE1 = str((df['LSP_Name_PE1'].values.tolist())[0])
LSP_Name_PE2 = str((df['LSP_Name_PE2'].values.tolist())[0])
VPN_CCC_PE1 = str((df['VPN_CCC_PE1'].values.tolist())[0])
VPN_CCC_PE2 = str((df['VPN_CCC_PE2'].values.tolist())[0])

dev1 = Device(host=''+PE1+'', user='demo', password='password', port='22')
dev1.open()
dev1.timeout = 300

with Config(dev1, mode='private') as cu: 
cu.load('set interfaces '+Interface_PE1+' unit '+Unit_PE1+' description L2VPN-CCC encapsulation vlan-ccc vlan-id '+Vlan_PE1+' family ccc', format='set')
cu.pdiff() #Printing the difference in the configuration after the load
cu.commit()

dev1.close()
dev2 = Device(host=''+PE2+'', user='demo', password='password', port='22')
dev2.open()
dev2.timeout = 300

with Config(dev2, mode='private') as cu: 
cu.load('set interfaces '+Interface_PE2+' unit '+Unit_PE2+' description L2VPN-CCC encapsulation vlan-ccc vlan-id '+Vlan_PE2+' family ccc', format='set')
cu.pdiff() #Printing the difference in the configuration after the load#
cu.commit() #commit#

dev2.close()
conn = httplib.HTTPConnection('10.198.123.180:8091')
Bandwidth = raw_input('Please enter LSP Bandwidth on '+PE1+' (e.g 100k): ')
Setup_Pri = raw_input('Please enter Set up Priority: ')
Hold_Pri = raw_input('Please enter Hold Priority: ')
payload = str('{\r\n\"name\": \"'+LSP_Name_PE1+'\",\r\n\"creationConfigurationMethod\": \"NETCONF\",\r\n\"provisioningType\": \"RSVP\",\r\n  \"pathType\": \"primary\",\r\n  \"from\": {\r\n\"topoObjectType\": \"ipv4\",\r\n\"address\": \"'+PE1+'\"\r\n },\r\n  \"to\": {\r\n\"topoObjectType\": \"ipv4\",\r\n\"address\": \"'+PE2+'\"\r\n},\r\n\"plannedProperties\": {\r\n\"bandwidth\": \"'+Bandwidth+'\",\r\n\"setupPriority\": '+Setup_Pri+',\r\n\"holdingPriority\": '+Hold_Pri+',\r\n\"userProperties\": {\r\n \"ccc-vpn-name\": \"'+VPN_CCC_PE1+'\",\r\n \"ccc-interface\": \"'+Interface_PE1+'.'+Unit_PE1+'\",\r\n\"transmit-lsp\": \"'+LSP_Name_PE1+'\",\r\n\"receive-lsp\": \"'+LSP_Name_PE2+'\"\r\n    }\r\n  }\r\n}\r\n')
headers = {
 'content-type': "application/json",
'cache-control': "no-cache",
 }

conn.request ("POST", "/NorthStar/API/v2/tenant/1/topology/1/te-lsps", payload, headers
res = conn.getresponse()
data = res.read()
print 'Please wait while we get the status of LSP you created :)'
for i in xrange(25,0,-1):
 time.sleep(1)
 sys.stdout.write(str(i)+' ') 
 sys.stdout.flush()
 conn.request("GET", str('/NorthStar/API/v2/tenant/1/topology/1/te-lsps/search?name=' + LSP_Name_PE1), headers=headers
 res = conn.getresponse()
 data = res.read()

LSP_Status = re.search('operationalStatus":(.*?),', data).group(1)
if LSP_Status == '"Active"':
  print ('\nSuccess: LSP "'+LSP_Name_PE1+'" is Created and Active')
elif LSP_Status == "Down":
   print ('\nFailed: LSP "'+LSP_Name_PE1+'" is created however Down')
else:
  print ('\nFailed: LSP "'+LSP_Name_PE1+'" is not created and is in Unknown State on Northstar')

time.sleep(10)

conn = httplib.HTTPConnection('10.198.123.180:8091')
Bandwidth = raw_input('Please enter LSP Bandwidth on '+PE2+' (e.g 100k): ')
Setup_Pri = raw_input('Please enter Set up Priority: ')
Hold_Pri = raw_input('Please enter Hold Priority: ')

payload = str('{\r\n\"name\": \"'+LSP_Name_PE2+'\",\r\n\"creationConfigurationMethod\": \"NETCONF\",\r\n\"provisioningType\": \"RSVP\",\r\n  \"pathType\": \"primary\",\r\n  \"from\": {\r\n\"topoObjectType\": \"ipv4\",\r\n\"address\": \"'+PE2+'\"\r\n },\r\n  \"to\": {\r\n\"topoObjectType\": \"ipv4\",\r\n\"address\": \"'+PE1+'\"\r\n},\r\n\"plannedProperties\": {\r\n\"bandwidth\": \"'+Bandwidth+'\",\r\n\"setupPriority\": '+Setup_Pri+',\r\n\"holdingPriority\": '+Hold_Pri+',\r\n\"userProperties\": {\r\n \"ccc-vpn-name\": \"'+VPN_CCC_PE2+'\",\r\n \"ccc-interface\":\"'+Interface_PE2+'.'+Unit_PE2+'\",\r\n\"transmit-lsp\": \"'+LSP_Name_PE2+'\",\r\n\"receive-lsp\": \"'+LSP_Name_PE1+'\"\r\n    }\r\n  }\r\n}\r\n')
headers = {
 'content-type': "application/json",
 'cache-control': "no-cache",
   }

conn.request ("POST", "/NorthStar/API/v2/tenant/1/topology/1/te-lsps", payload, headers)
res = conn.getresponse()
data = res.read()
print 'Please wait while we get the status of LSP you created :)'
for i in xrange(25,0,-1):
   time.sleep(1)
   sys.stdout.write(str(i)+' ')
   sys.stdout.flush()

conn.request("GET", str('/NorthStar/API/v2/tenant/1/topology/1/te-lsps/search?name=' + LSP_Name_PE2), headers=headers)
res = conn.getresponse()
data = res.read()
LSP_Status = re.search('operationalStatus":(.*?),', data).group(1)
if LSP_Status == '"Active"':
    print ('\nSuccess: LSP "'+LSP_Name_PE2+'" is Created and Active')
elif LSP_Status == "Down":
    print ('\nFailed: LSP "'+LSP_Name_PE2+'" is created however Down')
else:
    print ('\nFailed: LSP "'+LSP_Name_PE2+'" is not created and is in Unknown State on Northstar')

time.sleep(5)

dev1.open()
dev2.open()

print (dev1.cli('show connections remote-interface-switch '+VPN_CCC_PE1+'', warning=False))

print (dev2.cli('show connections remote-interface-switch '+VPN_CCC_PE2+'', warning=False))

dev1.close()
dev2.close()

In this script we are making reading the values from the excel and using it as variables in or script.

After that using PyEZ, making a SSH connection to PE1 and PE2 and configuring the layer 2 sub-interfaces with vpn-ccc encapsulations. Once that is done, connection to Northstar server 10.198.123.180 using httplib libraris/modules is made and waiting for Northstar to configure the LSP. At this stage Northstar is also binding that LSPs in connections using Jinja template. Once Northstar has created the LSPs we are using regular expression to get the LSP Index from Northstar and checking whether LSP creating in Success or failed.

At last we are printing the show command output to find out if everything is up and running 🙂

Lets see by running the script

C:\Program Files (x86)\Python\Northstar_Scripts\Working\Juniper\L2VPN_CCC>python
 E2E_L2VPN_CCC_Script.py
[edit interfaces xe-2/0/0]
+ unit 601 {
+ description L2VPN-CCC;
+ encapsulation vlan-ccc;
+ vlan-id 601;
+ family ccc;
+ }
[edit interfaces xe-2/0/0]
+ unit 601 {
+ description L2VPN-CCC;
+ encapsulation vlan-ccc;
+ vlan-id 601;
+ family ccc;
+ }
Please enter LSP Bandwidth on 10.198.123.100 (e.g 100k): 70m
Please enter Set up Priority: 5
Please enter Hold Priority: 0
Please wait while we get the status of LSP you created :)
25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
Success: LSP "l2vpn-ccc-1" is created and is Active
Please enter LSP Bandwidth on 10.198.123.205 (e.g 100k): 70m
Please enter Set up Priority: 5
Please enter Hold Priority: 0
Please wait while we get the status of LSP you created :)
25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
Success: LSP "l2vpn-ccc-2" is created and is Active
CCC and TCC connections [Link Monitoring On]
Legend for status (St): Legend for connection types:
 UN -- uninitialized if-sw: interface switching
 NP -- not present rmt-if: remote interface switching
 WE -- wrong encapsulation lsp-sw: LSP switching
 DS -- disabled tx-p2mp-sw: transmit P2MP switching
 Dn -- down rx-p2mp-sw: receive P2MP switching
 -> -- only outbound conn is up Legend for circuit types:
 <- -- only inbound conn is up intf -- interface
 Up -- operational oif -- outgoing interface
 RmtDn -- remote CCC down tlsp -- transmit LSP
 Restart -- restarting rlsp -- receive LSP
Connection/Circuit Type St Time last up # Up tran
s
l2vpn-ccc rmt-if Up Nov 25 12:52:10
1
 xe-2/0/0.601 intf Up
 l2vpn-ccc-1 tlsp Up
 l2vpn-ccc-2 rlsp Up

CCC and TCC connections [Link Monitoring On]
Legend for status (St): Legend for connection types:
 UN -- uninitialized if-sw: interface switching
 NP -- not present rmt-if: remote interface switching
 WE -- wrong encapsulation lsp-sw: LSP switching
 DS -- disabled tx-p2mp-sw: transmit P2MP switching
 Dn -- down rx-p2mp-sw: receive P2MP switching
 -> -- only outbound conn is up Legend for circuit types:
 <- -- only inbound conn is up intf -- interface
 Up -- operational oif -- outgoing interface
 RmtDn -- remote CCC down tlsp -- transmit LSP
 Restart -- restarting rlsp -- receive LSP

Connection/Circuit Type St Time last up # Up tran
s
l2vpn-ccc rmt-if Up Nov 25 12:52:11
1
 xe-2/0/0.601 intf Up
 l2vpn-ccc-2 tlsp Up
 l2vpn-ccc-1 rlsp Up

C:\Program Files (x86)\Python\Northstar_Scripts\Working\Juniper\L2VPN_CCC>

 

So that’s all for today.. You can see the possibility of using this framework in so many tasks in your daily networking journey. I hope you like this blog and will try to use it in your network 🙂

Regards

Mohit

Juniper Northstar SDN Controller – Part 2

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.

Pic-1

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.

Pic-2

We will choose Netconf and fill other bits.

Pic-3

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.

Pic-4

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.

Pic-5

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.

Pic-6

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.

Pic-7

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.

Pic-8

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.

Pic-9

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

 

Ansible on JunOS

Hi All, first of all sorry for coming out late with next blog. Was busy in some personal and official stuff.

Also during past few days, I have been exploring having Ansible set up in our network for ease of configuring and having a centralised place to do some configuration on single or all boxes at once.

Ansible if you don’t know is Configuration Management, software provisioning tool. Ansible is in same league as Puppet, Chef, Salt provisioning tool but its different from them in some sense like Pull vs Push, Stateless vs Stateful etc. We will discuss these difference below but Ansible on top provides configuration/provisioning support for Network engineers in a sense that it has modules from different vendors like Cisco, Huawei, Arista, Nokia and Juniper. We will specifically discuss about Junos here.

Juniper provides support for using Ansible to deploy devices running the Junos operating system (Junos OS). The Juniper Networks Ansible library, which is hosted on the Ansible Galaxy website under the role junos, enables you to use Ansible to perform specific operational and configuration tasks on devices running Junos OS, including installing and upgrading, deploying specific devices in the network, loading configuration changes, retrieving information, and resetting, rebooting, or shutting down managed devices.

I have just started to explore Ansible so I am really Amateur in this area however may be after some months of work I will be in position to provide more details on this 🙂 . Before we dive into some examples let’s review what I said before regarding differences.

Push vs Pull –> Puppet basically works on Pull mechanism where its hosts periodically pulls the configurations from server which is good for some things but not if you want change to deployed asap. On the other hand Ansible works in Push model where config is applied instantly to nodes/hosts.

Stateless vs Stateful –> Ansible works in stateless mode where to use Ansible, nothing needs to be installed on Hosts i.e. switches/routers. Ansible and other libraries are installed on Server which is controller and it connects to nodes/hosts via SSH/Netconf.

For Ansible to work with Junos, 3 requirements needs to be fulfilled first on server.

1)      pip install ncclient  (this is python lib for netconf)

2)      pip install junos-eznc (this is python lib for Junos)

3)      Install Juniper.junos Galaxy role using command:

ansible-galaxy install Juniper.junos

Once this is done, we can run raw modules from Ansible server as Ad-hoc commands which basically uses SSH instead of netconf.

I am running ansible on CentOS 6.9

 

mmittal@ANS01$ cat /etc/redhat-release
CentOS release 6.9 (Final)

So basically here we will be using raw module to check the version on host and we will provide the username with it and –k option will invoke us to put password.

ansible -v 10.198.123.103 -m raw -a "show version" -u mmittal –k
SSH password:
10.198.123.103 | SUCCESS | rc=0 >>
Hostname: MX-104-PE-Volvo
Model: mx104
Junos: 15.1F6.9
JUNOS Base OS boot [15.1F6.9]
JUNOS Base OS Software Suite [15.1F6.9]
JUNOS Crypto Software Suite [15.1F6.9]
JUNOS Packet Forwarding Engine Support (MX104) [15.1F6.9]
JUNOS Web Management [15.1F6.9]
JUNOS Online Documentation [15.1F6.9]
JUNOS Services Application Level Gateways [15.1F6.9]
JUNOS Services Jflow Container package [15.1F6.9]
JUNOS Services Stateful Firewall [15.1F6.9]
JUNOS Services NAT [15.1F6.9]
JUNOS Services RPM [15.1F6.9]
JUNOS Services Captive Portal and Content Delivery Container package [15.1F6.9]
JUNOS Macsec Software Suite [15.1F6.9]
JUNOS Services Crypto [15.1F6.9]
JUNOS Services IPSec [15.1F6.9]
JUNOS Kernel Software Suite [15.1F6.9]
JUNOS Routing Software Suite [15.1F6.9]
Shared connection to 10.198.123.103 closed.

This adhoc commands lets you check things without having to do any real programming however real use of Ansible comes via way of playbooks which are basically scripts in layman term. Under playbook we will mention the module which want to run and tasks to be performed. Before running Ansible playbook it is better to talk about one important file name called ansible.cfg which basically resides in etc/ansible/ansible.cfg

However ansible.cfg is picked up in following order and it is recommended to have our own ansible.cfg in current/home directory so that we can control the parameters we want to have.

* ANSIBLE_CONFIG (an environment variable)
* ansible.cfg (in the current directory)
* .ansible.cfg (in the home directory)
* .ansible.cdg (in /etc/ansible/ansible.cfg)

Example from my ansible.cfg which apart from standard defaults is also pointing to hostfile where all IP Addresses of routers/switches will reside.

mmittal@ANS01$ cat ansible.cfg
[defaults]
hostfile = ./ansible_hosts
host_key_checking = false
timeout = 5
log_path=./ansible.log

Lets see one example of playbook.

So in this playbook we are adding a task of running multiple commands on 2 hosts and module we have used in junos_command and we are printing the output on session.

mmittal@ANS01$ cat ansible_multiplecommands.yml
---
- name: show version and other user level commands
 hosts: 10.198.123.100, 10.198.123.103
 roles:
 - Juniper.junos
 gather_facts: no
 connection: local
tasks:
 - name: run multiple commands on remote nodes
 junos_command:
 commands:
 - show version
 - show interfaces

register: print_output

- debug: var=print_output.stdout_lines

To run this playbook we have to use the following command:

mmittal@ANS01$ ansible-playbook ansible_multiplecommands.yml -u mmittal -k
SSH password:

PLAY [show version and other user level commands] *************************************************************************************************************************************************************

TASK [run multiple commands on remote nodes] ******************************************************************************************************************************************************************
ok: [10.198.123.103]
ok: [10.198.123.100]

TASK [debug] **************************************************************************************************************************************************************************************************
ok: [10.198.123.100] => {
 "print_output.stdout_lines": [
 [
 "Hostname: re1.MX104_PE_Pagani",
 "Model: mx104",
 "Junos: 15.1F6.9",
 "JUNOS Base OS boot [15.1F6.9]",
 "JUNOS Base OS Software Suite [15.1F6.9]",
 "JUNOS Crypto Software Suite [15.1F6.9]",
 "JUNOS Packet Forwarding Engine Support (MX104) [15.1F6.9]",
 "JUNOS Web Management [15.1F6.9]",
 "JUNOS Online Documentation [15.1F6.9]",
 "JUNOS Services Application Level Gateways [15.1F6.9]",
 "JUNOS Services Jflow Container package [15.1F6.9]",
 "JUNOS Services Stateful Firewall [15.1F6.9]",
 "JUNOS Services NAT [15.1F6.9]",
 "JUNOS Services RPM [15.1F6.9]",
 "JUNOS Services Captive Portal and Content Delivery Container package [15.1F6.9]",
 "JUNOS Macsec Software Suite [15.1F6.9]",
 "JUNOS Services Crypto [15.1F6.9]",
 "JUNOS Services IPSec [15.1F6.9]",
 "JUNOS Kernel Software Suite [15.1F6.9]",
 "JUNOS Routing Software Suite [15.1F6.9]"
 ],
 [
 "Physical interface: ge-0/0/0, Enabled, Physical link is Up",
 " Interface index: 154, SNMP ifIndex: 512",
 " Description: Connected to MX104 RR-3_ge-0/1/0",
 " Link-level type: Ethernet, MTU: 1600, MRU: 1608, LAN-PHY mode,",
 " Speed: 1000mbps, BPDU Error: None, MAC-REWRITE Error: None,",
 " Loopback: Disabled, Source filtering: Disabled, Flow control: Enabled,",
 " Auto-negotiation: Enabled, Remote fault: Online",
 " Pad to minimum frame size: Disabled",
 " Device flags : Present Running",
 " Interface flags: SNMP-Traps Internal: 0x0",
 " CoS queues : 8 supported, 8 maximum usable queues",
 " Current address: 54:1e:56:f7:78:00, Hardware address: 54:1e:56:f7:78:00",
 " Last flapped : 2017-08-18 13:32:41 GMT (2w3d 21:51 ago)",
 .
.
(o/p trunacated)
.
.
.
.
 ]
 ]
}
ok: [10.198.123.103] => {
 "print_output.stdout_lines": [
 [
 "Hostname: MX-104-PE-Volvo",
 "Model: mx104",
 "Junos: 15.1F6.9",
 "JUNOS Base OS boot [15.1F6.9]",
 "JUNOS Base OS Software Suite [15.1F6.9]",
 "JUNOS Crypto Software Suite [15.1F6.9]",
 "JUNOS Packet Forwarding Engine Support (MX104) [15.1F6.9]",
 "JUNOS Web Management [15.1F6.9]",
 "JUNOS Online Documentation [15.1F6.9]",
 "JUNOS Services Application Level Gateways [15.1F6.9]",
 "JUNOS Services Jflow Container package [15.1F6.9]",
 "JUNOS Services Stateful Firewall [15.1F6.9]",
 "JUNOS Services NAT [15.1F6.9]",
 "JUNOS Services RPM [15.1F6.9]",
 "JUNOS Services Captive Portal and Content Delivery Container package [15.1F6.9]",
 "JUNOS Macsec Software Suite [15.1F6.9]",
 "JUNOS Services Crypto [15.1F6.9]",
 "JUNOS Services IPSec [15.1F6.9]",
 "JUNOS Kernel Software Suite [15.1F6.9]",
 "JUNOS Routing Software Suite [15.1F6.9]"
 ],
 [
 "Physical interface: lc-0/0/0, Enabled, Physical link is Up",
 " Interface index: 142, SNMP ifIndex: 506",
 " Speed: 800mbps",
 " Device flags : Present Running",
 " Link flags : None",
 " Last flapped : Never",
 " Input packets : 0",
 " Output packets: 0",
 "",
 " Logical interface lc-0/0/0.32769 (Index 329) (SNMP ifIndex 507)",
 " Flags: Encapsulation: ENET2",
 " Bandwidth: 0",
 " Input packets : 0",
 " Output packets: 0",
 " Protocol vpls, MTU: Unlimited",
 " Flags: Is-Primary",
 "",
(o/p trunacated)
.
.
.
 ]
 ]
}

PLAY RECAP ****************************************************************************************************************************************************************************************************
10.198.123.100 : ok=2 changed=0 unreachable=0 failed=0
10.198.123.103 : ok=2 changed=0 unreachable=0 failed=0

 


So that’s all for today.. Its very basic intro to Ansible on Junos however I hope you get an idea and will try to use it in your network 🙂

Regards

Mohit




 

 

JUNIPER JUNOS COMMAND SERIES – 3

Hi All, lets continue our useful Junos command series by looking at 2 more interesting commands. One is another flexibility which Juniper provides and 2nd is to see the command structure in way which can be directly pasted on CLI.

So this is our example policy config from MX104:

MX104-PE> show configuration policy-options policy-statement test
term 1 {
 from community test;
 then accept;
}
term 2 {
 from neighbor 1.1.1.1;
 then accept;
}
term 3 {
 then reject;

Now lets suppose you need to add one term (term 4) between before term 3 so that it doesn’t get reject by last reject term. Lets puts a term 4 and see what’s the result.

[edit policy-options policy-statement test]
MX104-PE# set term 4 from family inet

[edit policy-options policy-statement test]
MX104-PE# set term 4 then accept
[edit policy-options policy-statement test]
MX104-PE# show
term 1 {
 from community test;
 then accept;
}
term 2 {
 from neighbor 1.1.1.1;
 then accept;
}
term 3 {
 then reject;
}
term 4 {
 from family inet;
 then accept;
}

Now if you see above Junos has added the term 4 at the end which won’t be useful to us if we commit now as term 3 is reject and term 4 won’t be validated at all because of reject term 3 above it. So to get away with this problem Junos provides us one command “insert” which will insert the term 4 before term 3. Let’s see it in action.

[edit policy-options policy-statement test]
MX104-PE# insert term 4 before term 3

[edit policy-options policy-statement test]
MX104-PE# show
term 1 {
 from community test;
 then accept;
}
term 2 {
 from neighbor 1.1.1.1;
 then accept;
}
term 4 {
 from family inet;
 then accept;
}
term 3 {
 then reject;
}

Now lets check the another command which is very easy hack

Sometimes you need the configuration from Juniper in set form so that you can paste it directly on the other or same box after some modifications.

This is our example configuration:

show configuration interfaces ge-0/1/8
vlan-tagging;
mtu 1522;
encapsulation vlan-ccc;
unit 601 {
 encapsulation vlan-ccc;
 vlan-id 601;
 family ccc;
}

Now to get the set form of this configuration, Junos gives us this command:
show configuration interfaces ge-0/1/8 | display set
set interfaces ge-0/1/8 vlan-tagging
set interfaces ge-0/1/8 mtu 1522
set interfaces ge-0/1/8 encapsulation vlan-ccc
set interfaces ge-0/1/8 unit 601 encapsulation vlan-ccc
set interfaces ge-0/1/8 unit 601 vlan-id 601
set interfaces ge-0/1/8 unit 601 family ccc

This is exact same config but in separate form and can be easily copy pasted from top edit mode on other device.

In next blogs we will see more commands to copy paste the config without set form.

So that’s all, I hope you liked this article as well and will make use of these commands in your day to day operational work or troubleshooting.

Regards

Mohit Mittal