Non-Interactive SSH use case with Python
Sometimes the best way to learn to do something useful with a scripting language is with a starting point and a real world use case. While I don’t consider myself a Python expert, I can usually figure out how to put things together and get a task accomplished. For this article I challenged myself to create a simple script that performs the following:
- Open a file for a list of devices and credentials
- Log in to each device in the file using the credentials found
- Remove the current NTP server (1.1.1.1)
- Add a new NTP server (2.2.2.2)
- Save the configuration
I am sharing the script below as an example. Note this Python file uses paramiko. Therefore that library needs to be installed (MAC users – sudo pip install paramiko)
NTPChange.py
import paramiko
####devices.txt format
#### username,password,host
#### username,password,host
qbfile = open("devices.txt", "r")
for aline in qbfile:
values = aline.split(",")
myuser = values[0]
mypass = values[1]
myhost = values[2].rstrip()
ssh = paramiko.SSHClient()
ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy())
ssh.connect(myhost, username=myuser, password=mypass)
channel = ssh.invoke_shell()
stdin = channel.makefile('wb')
stdout = channel.makefile('rb')
stdin.write('''
conf t
no ntp server Continue reading
Fighting CLI cowboys with Napalm – An Introduction
A lot of people who aren’t familiar with Napalm tend to laugh nervously when you suggest they use it in their network. The name Napalm is partly based on getting that perfect acronym and partly a desire to incinerate the old way of doing things and move to network automation. This article is about explaining what Napalm is and what lies behind the acronym.
Continue reading36 – VXLAN EVPN Multi-Fabrics – Path Optimisation (part 5)
Ingress/Egress Traffic Path Optimization
In the VXLAN Multi-fabric design discussed in this post, each data center normally represents a separate BGP autonomous system (AS) and is assigned a unique BGP autonomous system number (ASN).
Three types of BGP peering are usually established as part of the VXLAN Multi-fabric solution:
- MP internal BGP (MP-iBGP) EVPN peering sessions are established in each VXLAN EVPN fabric between all the deployed leaf nodes. As previously discussed, EVPN is the intrafabric control plane used to exchange reachability information for all the endpoints connected to the fabric and for external destinations.
- Layer 3 peering sessions are established between the border nodes of separate fabrics to exchange IP reachability information (host routes) for the endpoints connected to the different VXLAN fabrics and the IP subnets that are not stretched (east-west communication). Often, a dedicated Layer 3 DCI network connection is used for this purpose. In a multitenant VXLAN fabric deployment, a separate Layer 3 logical connection is required for each VRF instance defined in the fabric (VRF-Lite model). Although either eBGP or IGP routing protocols can be used to establish interfabric Layer 3 connectivity, the eBGP scenario is the most common and is the one discussed in Continue reading
36 – VXLAN EVPN Multi-Fabrics – Host Mobility (part 4)
Host Mobility across Fabrics
This section discusses support for host mobility when a distributed Layer 3 Anycast gateway is configured across multiple VXLAN EVPN fabrics.
In this scenario, VM1 belonging to VLAN 100 (subnet_100) is hosted by H2 in fabric 1, and VM2 on VLAN 200 (subnet_200) initially is hosted by H3 in the same fabric 1. Destination IP subnet_100 and subnet_200 are locally configured on leaf nodes L12 and L13 as well as on L14 and L15.
This example assumes that the virtual machines (endpoints) have been previously discovered, and that Layer 2 and 3 reachability information has been announced across both sites as discussed in the previous sections.
Figure 1 highlights the content of the forwarding tables on different leaf nodes in both fabrics before virtual machine VM2 is migrated to fabric 2.
Figure 1 : Content of Forwarding Tables before Host Mobility
The following steps show the process for maintaining communication between the virtual machines in a host mobility scenario, as depicted in Figure 2
Figure 2 : VXLAN EVPN Multi-Fabric and Host Mobility
- For operational purposes, virtual machine VM2 moves to host H4 located in fabric 2 and connected to leaf nodes L21 and L22.
- After Continue reading
36 – VXLAN EVPN Multi-Fabrics with Anycast L3 gateway (part 3)
VXLAN EVPN Multi-Fabric with Distributed Anycast Layer 3 Gateway
Layer 2 and Layer 3 DCI interconnecting multiple VXLAN EVPN Fabrics
A distributed anycast Layer 3 gateway provides significant added value to VXLAN EVPN deployments for several reasons:
- It offers the same default gateway to all edge switches. Each endpoint can use its local VTEP as a default gateway to route traffic outside its IP subnet. The endpoints can do so, not only within a fabric but across independent VXLAN EVPN fabrics (even when fabrics are geographically dispersed), removing suboptimal interfabric traffic paths. Additionally, routed flows between endpoints connected to the same leaf node can be directly routed at the local leaf layer.
- In conjunction with ARP suppression, it reduces the flooding domain to its smallest diameter (the leaf or edge device), and consequently confines the failure domain to that switch.
- It allows transparent host mobility, with the virtual machines continuing to use their respective default gateways (on the local VTEP), within each VXLAN EVPN fabric and across multiple VXLAN EVPN fabrics.
- It does not require you to create any interfabric FHRP filtering, because no protocol exchange is required between Layer 3 anycast gateways.
- It allows better distribution of state (ARP, Continue reading
36 – VXLAN EVPN Multi-Fabrics with External Routing Block (part 2)
VXLAN EVPN Multi-Fabric with External Active/Active Gateways
The first use case is simple. Each VXLAN fabric behaves like a traditional Layer 2 network with a centralized routing block. External devices (such as routers and firewalls) provide default gateway functions, as shown in Figure 1.
Figure 1: External Routing Block IP Gateway for VXLAN/EVPN Extended VLAN
In the Layer 2–based VXLAN EVPN fabric deployment, the external routing block is used to perform routing functions between Layer 2 segments. The same routing block can be connected to the WAN advertising the public networks from each data center to the outside and to propagate external routes to each fabric.
The routing block consists of a “router-on-a-stick” design (from the fabric’s point of view) built with a pair of traditional routers, Layer 3 switches, or firewalls that serve as the IP gateway. These IP gateways are attached to a pair of vPC border nodes that initiate and terminate the VXLAN EVPN tunnels.
Connectivity between the IP gateways and the border nodes is achieved through a Layer 2 trunk carrying all the VLANs that require routing services.
To improve performance with active default gateways in each data center, reducing the hairpinning of east-west traffic for Continue reading
36 – VXLAN EVPN Multi-Fabrics Design Considerations (part 1)
Notices
With my friend and respectful colleague Max Ardica, we have tested and qualified the current solution to interconnect multiple VXLAN EVPN fabric. We have developed this technical support to clarify the network design requirements when the function Layer 3 Anycast gateways is distributed among all server node platform and all VXLAN EVPN Fabrics. The whole article is organised in 5 different posts.
- This 1st one elaborates the design considerations to interconnect two VXLAN EVPN based fabrics.
- The 2nd post discusses the Layer 2 DCI requirements interconnecting Layer-2-based VXLAN EVPN fabrics with external routing block
- The 3rd covers the Layer 2 and Layer 3 DCI requirement interconnecting VXLAN EVPN fabrics with distributed Layer Anycast Gateway.
- The 4th post examines host mobility across two VXLAN EVPN Fabrics
- Finally the last section develops inbound and outbound path optimisation with VXLAN EVPN fabrics geographically dispersed.
Introduction
Recently, fabric architecture has become a common and popular design option for building new-generation data center networks. Virtual Extensible LAN (VXLAN) with Multiprotocol Border Gateway Protocol (MP-BGP) Ethernet VPN (EVPN) is essentially becoming the standard technology used for deploying network virtualization overlays in data center fabrics.
Data center networks usually require the interconnection of separate network fabrics, which may also be deployed across geographically dispersed Continue reading
Auto Network Diagram with Graphviz
One of the most useful and least updated pieces of network documentation is the network diagram. We all know this, and yet we still don’t have/make time to update this until something catastrophic happens and then we says to ourselves
Wow. I wish I had updated this sooner…
Graphviz
According to the website
Graphviz is open source graph visualization software. Graph visualization is a way of representing structural information as diagrams of abstract graphs and networks. It has important applications in networking, bioinformatics, software engineering, database and web design, machine learning, and in visual interfaces for other technical domains.
note: Lots of great examples and docs there BTW. Definitely check it out.
Getting started
So you’re going to have to first install graphviz from their website. Go ahead… I’l wait here.
Install the graphviz python binding
This should be easy assuming you’ve already got python and pip installed. I’m assuming that you do.
>>> pip install graphviz
Getting LLDP Neighbors from Arista Devices
You can use the Arista pyeapi library, also installable through pip as well. There’s a blog which introduces you to the basics here which you can check out. Essentially I followed that blog and then substituted the Continue reading
Cisco Clock Issue – This Is Really Bad
Check out this advisory from Cisco that came out a couple days ago. You need to read it and act on it immediately! I’ll summarize for you : Thanks to a faulty clock signal component, certain Cisco devices will stop functioning after about 18 months and become really expensive bricks! Reading through it, you’ll see phrases like “we expect product failures” and “is not recoverable.” Seriously, what the hell? This really warms the heart.
The fault affects a couple Meraki devices, the Nexus 9504, and some models of the ISR 4000s – the ISR4331, ISR4321, and ISR4351. The 4000s are part of Cisco’s flagship branch routers, and I know several people (including myself!) who have some of the affected units deployed in production. Some unnamed people on Twitter tell me that they have 50 and even 120 of these guys deployed in the field. That’s a lot of faulty clocks.
The fix is to open a TAC case and get a new device. Cisco is using the word “platform” when talking about replacement, meaning that they’ll send you a naked device. If you have cards or memory upgrades or a Continue reading
SSH is a BAD API
Okay, so its not meant to be an API. I get that. I’ve been watching a rather good video about executing interactive commands with Parimiko and two thoughts came to my mind.
- Very powerful/flexible way to do tasks across many devices
- This could be a LOT easier if we simply had the RESTful API’s we want everywhere
In any case, I think the video below is a worthwhile watch if you’re struggle to leverage Python and SSH to make a modification across a large number of devices.
Disclaimer: This article includes the independent thoughts, opinions, commentary or technical detail of Paul Stewart. This may or may does not reflect the position of past, present or future employers.
The post SSH is a BAD API appeared first on PacketU.
Automation: Build or Consume?
The question of “home grown vs. off the shelf” comes up a lot. It comes up both in a professional capacity and social.
Home grown, usually born out of frustration to solve an immediate problem, often is a path that leads to consuming something off the shelf either Open Source or commercial. Home grown can deliver rapid results for simple things but has an exponential learning growth curve to do something more complex.
Why learn the oddities and nuances of a full programming language to write a multi-threaded application that automates concurrently, when you can write simple instructions that makes something else takes care of all of that mucking about in parallelism, logging and worrying about covering every use case. If you like hacking and building things, is it not better to apply that yearning solving rapidly rewarded challenges or to work on building something that starts off fragile and like all babies, has to learn to crawl, walk and be weened off milk?
Good tools deal with things like input, decision making and invoking output. It’s always better to control the pipeline and write linkages than to build the whole thing. After all, the problem with software is, you Continue reading