Dictionary: friendor
Friendor – a vendor person who pretends to be your friend but all they really want is your money / purchase order.
(Brutal)
The post Dictionary: friendor appeared first on EtherealMind.
Updated: Using Ansible Playbooks with Cisco VIRL
Some of the engineers building Ansible-with-VIRL lab in my Building Network Automation Solutions online course experienced interesting challenges, so I made the how-to instructions more explicit and added a troubleshooting section to the Using Ansible Playbooks with Cisco VIRL document. Hope you’ll find them useful.
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 readingSpousetivities at DockerCon 2017
DockerCon 2017 is coming up in mid-April in Austin, TX, and Spousetivities will once again be offering activities for folks traveling to Austin with conference attendees. This is Spousetivities’ second time at DockerCon, and Crystal has a great lineup of activities planned.
Here’s a quick preview of the activities organized for DockerCon:
- Trip to Magnolia Market (from HGTV’s “Fixer Upper”)
- Tour of LBJ State Park
- Visit to Fredricksburg
- Sightseeing through the Hill Country around Austin
- Lunch at the Salt Lick BBQ
Austin in the spring should be a great place to visit, and Crystal has some really enjoyable activities planned—it’s a great reason to bring your spouse, girlfriend/boyfriend, significant other, or family member with you to Austin when you come for DockerCon. Of course, the chance to win some great prizes is nice too…
Crystal’s blog post on the Spousetivities site has a few more details, and registration is open right now.
36 – 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