In July, we released Ansible Tower 3. In this blog series, we will take a deeper dive into Tower changes designed to make our product simpler and easier to scale Ansible automation across your environments. In our last post, our Principal Software Engineer Matt Jones highlighted what’s new for Tower 3 notifications.
If you’d like to learn more about the release, our Director of Product Bill Nottingham wrote a complete overview of the Tower 3 updates.
Tower gives you the ability to manage the use of Ansible for an entire enterprise, allowing you to potentially manage hundreds of Playbooks and thousands of hosts in a single place. Tower also gives you the ability to audit all types of usage through its integrated activity stream, which can be verbose. One of the goals of Tower 3 was to provide a consistent and full-featured user interface for dealing with these large collections of data.
In Tower 2, searching these collections was pretty limited. You could only make a single query for a particular collection. In Tower 3, we developed and implemented a tag-based searching system throughout the app, allowing you to chain multiple queries together so that you can quickly Continue reading
We did a podcast describing NAPALM, an open-source multi-vendor abstraction library, a while ago, and as the project made significant progress in the meantime, it was time for a short update.
NAPALM started as a library that abstracted the intricacies of network device configuration management. Initially it supported configuration replace and merge; in the meantime, they added support for diffs and rollbacks
Read more ... Public cloud is so good, it's almost boring.
SNMP was not designed with VRFs in mind. Querying the routing table via SNMP did not take into account the idea of having multiple routing tables. But clearly it’s something people want to do, so some clever engineers figured out how to shoe-horn VRF contexts in. This week a customer asked me how to query the routing table for the non-default VRF on Brocade VDX switches. Here’s how to do it:
For this lab I have Loopback 1 in the default VRF, with an IP of 50.50.50.50/32. I’ve created another VRF called “internet”, and put Loopback 2 in that VRF, with IP 60.60.60.60/32. Now I have two different routing tables:
VDX6940-204063# sh run rb 1 int loop 1
rbridge-id 1
interface Loopback 1
no shutdown
ip address 50.50.50.50/32
!
!
VDX6940-204063# sh ip route
Total number of IP routes: 1
Type Codes - B:BGP D:Connected O:OSPF S:Static U:Unnumbered +:Leaked route; Cost - Dist/Metric
BGP Codes - i:iBGP e:eBGP
OSPF Codes - Continue reading
SNMP was not designed with VRFs in mind. Querying the routing table via SNMP did not take into account the idea of having multiple routing tables. But clearly it’s something people want to do, so some clever engineers figured out how to shoe-horn VRF contexts in. This week a customer asked me how to query the routing table for the non-default VRF on Brocade VDX switches. Here’s how to do it:
For this lab I have Loopback 1 in the default VRF, with an IP of 50.50.50.50/32. I’ve created another VRF called “internet”, and put Loopback 2 in that VRF, with IP 60.60.60.60/32. Now I have two different routing tables:
VDX6940-204063# sh run rb 1 int loop 1 rbridge-id 1 interface Loopback 1 no shutdown ip address 50.50.50.50/32 ! ! VDX6940-204063# sh ip route Total number of IP routes: 1 Type Codes - B:BGP D:Connected O:OSPF S:Static U:Unnumbered +:Leaked route; Cost - Dist/Metric BGP Codes - i:iBGP e:eBGP OSPF Codes - Continue reading
Cisco says SD-WAN should be viewed as an addition to MPLS, not a replacement.
Fortinet recently restructured its sales team.
The combination of these two telecom firms could create some interesting strengths in virtualized networking.
Defining the problem – unused capacity
One of the single greatest challenges if you have ever owned, operated or designed a WISP (Wireless Internet Service Provider) is using all of the available bandwidth across multiple PtP links in the network. It is very common for two towers to have multiple RF PtP (Point-to-Point) links between them and run at different speeds. It is not unusual to have a primary link that runs at near-gigabit speeds and a backup link that may range anywhere from 50 Mbps to a few hundred Mbps.
This provides a pretty clean HA routing architecture, but it leaves capacity in the network unused until there is a failure. One of the headaches WISP designers always face is how to manage and engineer traffic for sub-rate ethernet links – essentially links that can’t deliver as much throughput as the physical link to the router or switch. In the fiber world, this is pretty straightforward as two links between any two points can be the exact same speed and either be channeled together with LACP or rely on ECMP with OSPF or BGP.
However, in the WISP world, this becomes problematic, as the links are unequal and Continue reading
Defining the problem – unused capacity
One of the single greatest challenges if you have ever owned, operated or designed a WISP (Wireless Internet Service Provider) is using all of the available bandwidth across multiple PtP links in the network. It is very common for two towers to have multiple RF PtP (Point-to-Point) links between them and run at different speeds. It is not unusual to have a primary link that runs at near-gigabit speeds and a backup link that may range anywhere from 50 Mbps to a few hundred Mbps.
This provides a pretty clean HA routing architecture, but it leaves capacity in the network unused until there is a failure. One of the headaches WISP designers always face is how to manage and engineer traffic for sub-rate ethernet links – essentially links that can’t deliver as much throughput as the physical link to the router or switch. In the fiber world, this is pretty straightforward as two links between any two points can be the exact same speed and either be channeled together with LACP or rely on ECMP with OSPF or BGP.
However, in the WISP world, this becomes problematic, as the links are unequal and Continue reading