Blog

BGP summary using PyEZ

Published by
October 16, 2017

Automation is all the rage these days and the good news is that when you are working with the Junos OS, you have a plethora of tools at your disposal. This article will provide you with a simple script that uses PyEZ to grab the output of the ‘show bgp summary’ command. After this, we will parse the XML output using jxmlease and then iterate the individual BGP peers to display their characteristics. 

python

Enabling the device for NETCONF.

Using the Junos PyEZ microframework allows  you to manage a device running Junos OS via a NETCONF session over SSH. But before this is possible, we need to  enable the service on the router. We can do this with the following configuration command:

set system services netconf ssh

After enabling the router for NETCONF, we should not forget to allow the service in the firewall filter that is used to protect the routing engine. By default, the service will be available through TCP port 830. When you examine the system connections after enabling the service, you should see the device listening to port 830:

lab@MX480-00-RE0-baseline> show system connections | match 830
tcp4       0      0  *.830                    *.*                      LISTEN

 

Determining the RPC

PyEZ offers a cli method that allows us to issue cli commands and scrape the screen. But that is not what we want. What we want to do is have the device return structured data. To get the device to do this, we issue an RPC (Remote Procedure Call). To issue the proper RPC, we first need to find out how we can translate the ‘show bgp summary’ command to an RPC. This is pretty straightforward. We simply log in to a router and add ‘| display xml rpc’ to the cli command that we are interested in:

 
lab@mx> show bgp summary | display xml rpc
<rpc-reply xmlns:junos="http://xml.juniper.net/junos/16.2R1/junos">
    <rpc>
        <get-bgp-summary-information>
        </get-bgp-summary-information>
    </rpc>
    <cli>
        <banner>{master}</banner>
    </cli>
</rpc-reply>

That’s it. The ‘get-bgp-summary-information’ is the part that is relevant to us. We can easily change this into a format that Python accepts. We replace the hyphens with underscores and add ‘()’ at the end like this:  get_bgp_summary_information().

Now that we know the RPC, let’s start examining the script.

 

The script

 

#!/usr/bin/python3
from jnpr.junos import Device
from lxml import etree
import jxmlease
 
username='said'
password='password123'
 
dev = Device(host='10.0.0.135', user=username, password=password, normalize=True)

dev.open()
 
rpc = dev.rpc.get_bgp_summary_information()
rpc_xml = etree.tostring(rpc, pretty_print=True, encoding='unicode')
dev.close()
 
print(rpc_xml)
 
xmlparser = jxmlease.Parser()
result = jxmlease.parse(rpc_xml)
 
print(result)
 
for neighbor in result['bgp-information']['bgp-peer']:
    print('Checking peer with IP address: ' + neighbor['peer-address'])
    print(neighbor['peer-as'])              
    print(neighbor['peer-state'])           
    print(neighbor['elapsed-time'])         
 
for neighbor in result.find_nodes_with_tag('bgp-peer'):
    print('Checking peer with IP address: ' + neighbor['peer-address'])
    print(neighbor['peer-as'])
    print(neighbor['peer-state'])
    print(neighbor['elapsed-time']) 

Let’s go over each section and see what is going on. The first thing we see is a shebang:

#!/usr/bin/python3

This line will indicates what interpreter Linux should use. A Windows machine will simply ignore this statement. 

After this, we encounter the imports. This example script imports three different modules:

from jnpr.junos import Device
from lxml import etree
import jxmlease

After importing the modules, we set the username and password variable:

username='said'
password='password123'

The username and password were set like this to make for an easy example. I suggest you look into a module called ‘getpass’ or use something else to protect your login credentials.

Next up is specifying the connection:

dev = Device(host='10.0.0.135', user=username, password=password, normalize=True)

After instantiating ‘dev’, we call the open method to open a connection to the device:

dev.open()

After opening a connection to the device, the script issues the RPC. Using etree, we place the result into a string. This string is stored in a variable called ‘rpc_xml’:

rpc = dev.rpc.get_bgp_summary_information()
rpc_xml = etree.tostring(rpc, pretty_print=True, encoding='unicode')

We are done getting the information, so we close the session we have with the device:

dev.close()

We have a look at the string we placed into the ‘rpc_xml’ variable. This is rather useless, but the point here is to examine the output before we use jxmlease to parse it:

print(rpc_xml)

The output would look something like this:

xml

Looks like XML to me! Now, we parse the XML string and place the resulting jxmlease object in a variable called result:

xmlparser = jxmlease.Parser()
result = jxmlease.parse(rpc_xml)

After parsing the XML, we print the result:

print(result)

This would look something like this:

jxmlease

This output is a lot more dictionary-like.

We could iterate this dictionary in the way we would iterate the keys of any Python dictionary. In this example script, we iterate the output at the peer level and access the values that we find interesting. This is done with the following piece of code: 

for neighbor in result['bgp-information']['bgp-peer']:
    print('Checking peer with IP address: ' + neighbor['peer-address'])
    print(neighbor['peer-as'])              
    print(neighbor['peer-state'])           
    print(neighbor['elapsed-time'])         

This code will print the IP, the AS, the peer state and the amount of time that the peer is in that state. When I ran the script, the output of this part of the code was as follows:

Checking peer with IP address: 10.10.255.6
65000
Established
25w5d 9:18:01

Checking peer with IP address: 10.255.255.2
65000
Active
46w4d 16:14:42 

Instead of iterating the keys, we can also use the jxmlease ‘find_nodes_with_tag’ method to iterate over whatever we want. In the example script, we iterate the ‘bgp-peer’ again:

for neighbor in result.find_nodes_with_tag('bgp-peer'):
    print('Checking peer with IP address: ' + neighbor['peer-address'])
    print(neighbor['peer-as'])
    print(neighbor['peer-state'])
    print(neighbor['elapsed-time'])

The main idea was to show you different ways on how to iterate the output. This part of the code generates exactly the same output as the previous part of the code:

Checking peer with IP address: 10.10.255.6
65000
Established
25w5d 9:18:01

Checking peer with IP address: 10.255.255.2
65000
Active
46w4d 16:14:42

We just used a for loop and printed some facts about the BGP sessions, woohoo! Even though that is already pretty neat, it is easy to add some additional logic to the program. Really, all you need is just a little bit of flow control and some additional familiarity with Python. For instance, if you only wanted to print the BGP peers that are not in the ‘Established’ state, you could consider the following:

for neighbor in result.find_nodes_with_tag('bgp-peer'):
    if neighbor['peer-state'] != 'Established':

To understand more about flow control, and to get some extra insight into what is possible with Python, I recommend the following book:

automate_the_boring_stugg

The book does not offer you any networking related examples, but it is amazing at explaining the basics of the Python programming language. I think Al Sweigart has done a fantastic job explaining things, even to those with little or no programming experience (me included).

Another thing worth looking into is the Junos PyEZ Developer Guide. It is a pretty comprehensive guide that will show you how to use PyEZ.

pyez_developer_guide

 

Connecting to a Juniper device and parsing structured data is not that hard. My goal was to explain to you how to map a CLI command to an RPC and to walk you through a simple example script. Hopefully, you will be able to use this article as a reference and start doing some automation of your own.

Many thanks to Ben Dale for proofreading this post!

 

EVPN-VXLAN INTER-TENANT ROUTING ON JUNIPER QFX / MX

Published by
July 18, 2017

evpn-vxlan-title

I’ve recently started working on a project focused on EVPN-VXLAN based on Juniper technology. I figured I’d take the opportunity to share some experiences specifically around inter-VXLAN routing. Inter-VXLAN routing can be useful when passing traffic between different tenants. For example, you may have a shared-services tenant that needs to be accessed by a number of different customer tenants whilst not allowing reachability between customer tenants. By enabling inter-VXLAN routing on the MX we can use various route-leaking techniques and policy to provide a technical point of control. 

View article

Unified Threat Management – deeper dive of traffic inspection

Published by
April 29, 2017

Unified Threat Management (or short UTM) belongs to the advanced security capabilities on all SRX devices (support for high-end devices is from 12.1X46 release). Following features are members of the UTM:

  • antispam (Local or with Spam Block server)
  • antivirus (Kaspersky also called Full, Sophos, Juniper Express)
  • web filtering (Juniper Enhanced, Local, Surf-Control Integrated, WebSense redirect)
  • content filtering

Please note the list above applies to Junos release 12.1X47. In older Junos releases some feature options (for example Juniper Enhanced web filtering) might not be available as they were introduced later.

View article

JNCIE-SP journey: the preparations

Published by
January 11, 2017

The JNCIE-SP journey is a long one. It is time consuming, requires dedication and a lot of hard work. During my preparations, I often looked at the exam blue print and wondered exactly how well versed and proficient I should be in all these different areas. Where should I put my focus? How can I train to better prepare myself for this exam? What would be the best approach? In this article, I want to share with you what resources I used to pass the exam as well as the method that seemed to work best for me.  

The pre-requisite for the JNCIE-SP exam is that you are JNCIP-SP certified. The topics covered on the JNCIP-SP are pretty extensive. I ordered all of the available course material and made sure that I really knew and understood everything that was covered. Instead of simply reading and rereading the courseware, I created summaries and studied those. For the JNCIE, I also supplemented the courseware with the reading list which is posted at the bottom of the article.

Even though the focus for the JNCIP-SP exam was mostly on the theory, I still tried to put everything into practice at least once. By doing so, I made sure I had a thorough understanding of all the different technologies listed on the exam blueprint. I took my time solidifying this knowledge and throughout my preparation for the lab exam and I experienced this as a great plus.

After obtaining the JNCIP-SP, my focus shifted from theory to practice. Knowing is one thing, doing is something completely different. Looking back now, these were three things that I consider the most valuable.

 

  1. Practice scenarios.

After the JNCIP-SP, I started doing some iNET ZERO labs. I scheduled a rack session and I was amazed:

I totally got my ass handed to me.

The scenarios are extremely challenging. The first time I went through the lab preparation workbook, I actually started to lose some of the confidence I gained by passing the JNCIP-SP. I was confronted with the fact that knowing the theory about an Interprovider VPN option C is something completely different from actually building one and integrating it into a hub and spoke VPN. I learned that activating technologies I never worked with before were difficult to combine with other technologies, let alone implement them in an already complex network. From the detailed walkthrough guide, I learned that the verification I was doing just paled in comparison to what was possible. I learned that it is about the bigger picture as much as it is about the little details.

After completing the iNET ZERO scenarios again (and again and again) my skillset improved dramatically. I got more confident, more skilled at verifying and troubleshooting and more aware of the different ways to solve a problem.

The book also gave me some ideas that I actually implemented in a live network.

 

  1. Practice and collaborate with others.

Finding someone to work with can be beneficial for a whole multitude of reasons. First of all, you can motivate each other. A second benefit comes from seeing someone else do the same scenario you practiced. This will often offer some insight into different solutions and different approaches to certain networking problems. A third advantage is that when you are stuck on a tough topic, you can ask for help and investigate things together. And last, but certainly not least, it can add to the fun!

 

  1. Explain it to others.

This can be through blogging, participating in forums or by explaining things to others. When you explain something in your own words, you deepen your understanding of the subject. For me personally, it is also something that greatly added to the fun.

 

Reading list:

  • All of the official JNCIS and JNCIP SP courseware
    • Junos Intermediate Routing
    • Junos Service provider Switching
    • Advanced Junos Service Provider Routing
    • Junos Class of Service
    • Junos Multicast Routing
    • Junos MPLS and VPNs
  • Day One: Deploying basic QoS
  • This week: Deploying BGP multicast VPNs (2nd edition)
  • This week: deploying MPLS
  • MPLS in the SDN Era
  • Tech note: Understanding RIB Groups
  • MPLS enabled applications
  • QoS enabled networks: tools and foundations, 2nd Edition
  • Junos Enterprise Routing
  • Network mergers and migrations
  • MX Series
  • iNET ZERO tech workbook
  • iNET ZERO lab preparation workbook

Even though there were some occasions where I found that some RFCs clarified my understanding on certain topics, I rarely found the need to consult them. There is one last thing that I do want to mention. For some reason it seems to be overlooked by some, but the last thing worth mentioning is the official Juniper documentation. Check what version of Junos OS will be running on the lab exam and consult the Juniper configuration guides. Several of those guides (MPLS configuration guide, Layer 3 VPNs configuration guide) are pretty well written and can be of great value. The documents are especially useful when you are labbing, to look something up, glance over examples etc.

 

Last word of advice: remember to have fun during your JNCIE SP journey.

Good luck!

The longest day: JNCIE-SP attempt no. 1

Published by
December 20, 2016

On a Tuesday, December 13 2016, after about 3 hours of sleep I woke up just before 5:30 AM. After a quick breakfast, I got into my car and drove off to Amsterdam. My destination; Juniper Networks Amsterdam. The purpose of my visit; to sit the JNCIE-SP exam.

After studying for more than 300 hours, this was the day where I would get to prove my worth.

 

jncie-sp-lab

 

The lab.

 

After the proctor explained the rules of the exam, I began reading through the assignments that were handed out to me. When I was done reading the documents, I logged in to the routers and familiarized myself with the environment.
During my first run through the exam, I did not permit myself to be stuck troubleshooting a single task or issue for more than 10 minutes. This was to make sure that I would finish all of the tasks on time.
After finishing the last question, I had another go at the more challenging questions, but not for too long this time either. Instead of staring at several tasks until the end of the exam, I wanted to make sure I had enough time for the most important part of the exam: the verification.
During this part of the exam, I reread all the questions and verified my solution to all of the questions at least twice. I verified my work in the most thorough way I knew. During this verification, I spotted some of my own fat fingering, saw some things I simply forgot to configure and most importantly, I discovered that some of the easy assignments were not so easy after all. There either was a catch, or the solution I initially configured was not fulfilling the requirements exactly.
During the exam, I experienced ups and downs. Some of the assignments were pretty easy, bolstering my confidence. However, this confidence was shattered when I encountered several of the more complicated task. Thorough and lengthy preparations pulled me through the moments of doubt I experienced.

 

Thoughts after lab.

 

All in all, sitting the exam until the proctor kicked me out was the best thing. I must have made at least 8 configuration corrections. without which I would have most surely failed the exam.
Looking back now, I have to say that the exam was fun. It was no easy exam. It was challenging, but fair. On my way home after completing the lab, it really felt like I got something of my chest. Even before knowing the outcome, I felt a sense of relief. After all this time, I finally did it and I did well. I figured that there was a chance that I had actually passed the exam.
Then the waiting started. The waiting brought doubts, slowly nibbling away my initial confidence.
People used to wait for several weeks to get the result of their lab attempt. I now fully understand how long this period of time must have felt for them. Luckily for me, the result came in after several days.
A pass!

 

Conclusion.

 

To me personally, the whole JNCIE-SP was a journey, and what a journey it was! If forced me to go deep into a lot of service provider technologies. Constantly challenging myself with all sorts of networking topologies that combine everything I had learned up until that point. Going over the iNET ZERO content again and again, rereading the more complicated topics, building some ridiculous labs of my own. It was an absolute delight.
Apart from the fun I had, another reason for taking the journey was because I felt like I needed to prove something. I wanted to prove that I am ‘all in’. I wanted to prove that I could do it, go deep and get into the nitty gritty. To show that I am dedicated and willing to put in the time. To show that I am willing and not afraid to submit myself to a full day practical lab exam.

 

jncie-sp-saidvandeklundert

Closer look at static NAT

Published by
December 17, 2016

Address translation is one of the main things keeping the IPv4 still alive. Nowadays it is considered as one of the basic router or firewall functionalities. On SRXs address translation is divided into three main types:

  • source NAT – the source address is translated in the initial flow
  • destination NAT – the destination address is translated in the initial flow
  • static NAT – combines source and destination NAT. The address translated in the initial flow depends on the flow direction (inbound flows have the destination address translated and outbound flows have the source address translated)

For source and destination NAT the port translation can be enabled or disabled through configuration. In static NAT the ports are not translated. Let’s look closer at the static NAT and its operation, configuration and troubleshooting.

View article

In control with RSVP

Published by
October 26, 2016

Controlling traffic flows is one of the benefits you get when using RSVP to signal LSPs. Using Junos OS, you are able to do this in quite a number of ways. This article aims to explain some of these options. After a brief CSPF recap, we’ll have a look at how we can exercise control over the path an LSP takes.

 

When an RSVP signaled LSP needs to be set up, the ingress LSR computes the path the LSP should take. This path is computed using information that is stored inside the Traffic Engineering Database, or TED. Information inside the TED is provided by an IGPs traffic engineering extensions. These traffic engineering extensions can be provided by OSPF or IS-IS.

The computation of the LSPs is done using the Constrained Shortest Path First algorithm, or CSPF. When an LSR computes an LSP using this CSPF, it takes into account what the constraints of an LSP are. The LSR first prunes the links that do not meet these constraints from the TED. After all relevant links are pruned, the shortest path is computed based on the remaining links still present in the TED.  

An LSR will compute LSPs one at a time, starting with the highest priority LSP (equal priority LSPs are computed in alphabetical order). For every LSP, CSPF will follow these steps:

  1. Prune the TED of links that do not have enough bandwidth available
  2. Prune the TED of links that lack the necessary colors
  3. Prune the TED of links that contain a color that should be excluded
  4. If the remaining paths are equal cost paths, choose the one whose last-hop address is the same as the LSPs destination
  5. If several paths remain, select the path with the fewest hops
  6. If multiple equal-cost paths remain, apply the CSPF load-balancing rule to the LSPs

View article

6PE and 6VPE

Published by
August 23, 2016

In a nutshell, both 6PE and 6VPE enable you to multiplex IPv6 as a service across an IPv4-only MPLS core using dual-stack PE routers. BGP is used to distribute IPv6 routing-information and IPv4 signaled MPLS LSPs are used to forward the IPv6 traffic across an IPv6-free-core.

Originally, the technology was developed to enable a network for IPv6 without upgrading all the routers at once. And even though most routers offer support for IPv6 by now, 6PE and 6VPE can still offer some benefits. For instance, a service provider with a very comprehensive RSVP TE scheme in place can use a single set of LSPs for all IPv4 and IPv6 traffic (as well as all the other MPLS applications). This way, all traffic can use the same RSVP signaled tunnels with the corresponding backup facilities.

Apart from the whys, you’ll find that when you’re working on a Juniper device, the configuration and verification of either of these technologies is pretty straightforward. Let’s go over the following scenario: 

6pe_6vpe_1

View article