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
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