Monday, July 18, 2016

My Third Step towards Automation: How to map Junos Commands to PyEZ RPC


In JUNOS, it’s very easy to find any RPC equivalent of the existing command by running “show route | display xml rpc”. This helps to find what is equivalent RPC command of show route as per below output.

get-route-information

It’s very difficult to find every time on cli what is equivalent of RPC of any Junos command. So we can leverage PyEZ to find the same and in the upcoming posts, you can check how it can be leverage to pass the different values directly in the RPC calls. In PyEZ we can call display_xml_rpc library to get the information of any RPC equivalent Junos Command.

from jnpr.junos import Device
from jnpr.junos.exception import ConnectError
dev = Device(host='192.168.1.1', user='lab', passwd=’lab')
try:
dev.open()
except ConnectError as err:
print "Cannot connect to device: {0}".format(err)
sys.exit(1)
print dev.display_xml_rpc('show route',format='text')
print dev.display_xml_rpc('show interface',format='text')
print dev.display_xml_rpc('show ospf neighbor',format='text')
dev.close()
The output of above file is given below:-
C:\Python27>python.exe testing\connect_device_rpc.py
RPC of show route is:
get-route-information

RPC of show interface is:
get-interface-information

RPC of show ospf neighbor is:
get-ospf-neighbor-information

Click Here To Read Rest Of The Post...

Tuesday, July 12, 2016

My Second Step towards Automation: Install the PyEZ Library and Connect Your Remote Device


Junos PyEZ micro framework has been built and tested tested with Python 2.6 and 2.7. So before moving ahead you must install Python 2.6 or 2.7.

Use:- “pip install junos-eznc” on your ubuntu or linux laptop to install PyEZ library or simply clone it from GIT hub “pip install git+https://github.com/Juniper/py-junos-eznc.git”

. You can install GIT on windows and start playing with it also. This library can be easily installed on your working laptop and you can connect any of your physical or virtual juniper device. Verify Your Installation
In your root directory make sure you have correct folders under python directory as below listed:-
1. C:\Python27\Lib\site-packages\junos_eznc
2. C:\Python27\Lib\site-packages\jnpr\junos

You can work with python in interactive mode or simple by creating a python files and run it from the python shell directly. Interactive shell is real time and generates the output immediately. First PyEZ Program from intractive shell to capture the facts of the device.
1. from jnpr.junos import Device
2. dev = Device(host='192.168.1.1', user='lab', passwd='lab')
Above command is Creating the device instance and provide the hostname, any parameters required for authentication, and any optional parameters.
3. Dev.open()
Above Command is Connecting to the device by calling the open() method.
4. print dev.facts
Above command is Printing the device facts, which are automatically retrieved when the connection and NETCONF session are established.
5. dev.close()
Above command is used to close the NETCONF session

If you are looking for to extract the particular information from the facts. In that case you can change the dev.facts to dev.facts['serialnumber']. By executing this command you will get the serial number of chassis.

Click Here To Read Rest Of The Post...

Sunday, July 10, 2016

My First Step towards Automation: Controlling Junos with Python & PyEZ


You can manage or automate routers by using python. But writing long codes in python is tedious task when it comes for non-programmers. But leveraging PyEZ, Python micro framework can help dev-ops engineers to automate the routers on the fly. Having an XML API is the benefit of using a Juniper router as it is easier than other routers to manage it with python PyEZ library. Moreover Juniper wrote a Python library, which is actually a "micro-framework", called PyEZ and it makes easier for non-programmers like me to manage a Junos OS router. Juniper devices comes with SLAX which can be leverage for on box automation. But PyEZ comes with OFF box solution and for onbox JET framework is required. PyEZ micro frame used NETCONF to communicate with the boxes.

PyEZ library is built for two type of users:-
1. Non-Programmers - Python as a Power Shell: Non-programmers, such as Network Engineers, can use the native Python shell on their management server (laptop, tablet, phone, and so on) as their point-of-control to remotely manage Junos OS devices.
2. Programmers - Open and Extensible: There is a growing interest and need to automate the network infrastructure into larger IT systems. To do so, traditional software programmers, DevOps, hackers, and so on, need an abstraction library of code to further those activities. Junos PyEZ is designed for extensibility so that the programmer can quickly and easily add new widgets to the library in support of their specific project requirements. There is no need to "wait on the vendor" to provide new functionality. Junos PyEZ is not specifically tied to any version of Junos OS or any Junos OS product family.

Junos PyEZ Features
Junos PyEZ is designed to provide the same capabilities as the Junos OS CLI, but in an environment built for automation tasks. These capabilities include, but are not limited to:
• Provide "facts" about the device such as software version, serial number, and so on
• Retrieve the "operational" or "run-state" information (think "show" commands) using Tables/Views
• Retrieve the configuration using Tables/Views
• Make unstructured configuration changes with "snippets" and "templates"
• Make structured configuration changes with modeled abstractions
• Provide common utilities for tasks such as secure copy of files and software updates

Closing Comments:
Currently PyEZ is used to control only Juniper Devices but as it is open and available on GIT hub, I think the same functionality can be extended to multi-vendor environment also. Still my research is on, how PyEZ can be used for multi-vendors environment so that we can leverage the open community rather depending on any OEM lock-in.

Stay tune for the next post of PyEZ installation.

Click Here To Read Rest Of The Post...

Wednesday, July 6, 2016

SDN NFV Considerations For Customers


What is NFV?

Network Functions Virtualization (NFV) is an alternative design approach for building complex IT applications, particularly in the telecommunications and service provider industries, that virtualizes entire classes of function into building blocks that may be connected, or chained, together to create services.

Various NFV Use Cases

Below are some sample NFV use cases can be evaluated and implemented: 1. virtual Provider Edge (vPE)
2. virtual Customer Premise Equipment (vCPE)
3. virtual Security
4. virtual Router
5. virtual BNG
6. Service Chaining
7. virtual Packet Core

What Does All This Mean For Customer?

NFV should be viewed as a transformative technology for Customer. The potential applicability for NFV solutions, as well as potential benefits, are almost endless:
Start Farm as a Consumer of NFV Solutions and Services – There is little doubt that Service Provider offerings will be changing dramatically in the coming years and what used to be table stakes for incumbent Tier 1 TELCOs, Cable MSOs and other traditional providers will be up for grabs. Traditional providers realize this and are moving quickly to embrace SDN, NFV and other disruptive technologies. The end result will be increased competition in the market and downward pressure on pricing. Customer should look to partner with traditional SPs (or other SPs) on innovative NFV based product and service offerings while keeping in mind the potential barriers for successful technology adoption.

NFV Deployment Models

The number of potential NFV deployment models is extensive and will likely grow over time. DC-based NFV is the first likely be the deployment model. The potential value of NFV extends beyond the DC. For providers, NFV solutions will extend beyond the DC to the point of presence (POP) and customer premise.

NFV enablers:
1. Improved x86 hardware performance

2. Maturity level of hypervisor technology

3. Automation and orchestration solutions

NFV Value Proposition
1. Reduce CAPEX/OPEX
2. Increase service agility
3. Accelerate service creation (hardware abstracted cloud based delivery)
4. Reduce energy costs, and
5. Enable dynamic service driven platforms

Click Here To Read Rest Of The Post...