Ansible is one of the powerful tools providing us an automation of recurring tasks. In the current world, it is impossible to manage infrastructure manually efficiently. Many people still do this but the world has already changed and we need to progress otherwise our business will be cost ineffective. You can provide static inventory – list of the devices where you want to execute the playbook. But in dynamic environments, such as Cisco VIRL simulations you don’t want to edit inventory file manually. That is why I use Python script that will generate Dynamic VIRL inventory for Ansible playbook for me.
Cisco VIRL is powerful network simulation tool. There are weeks when I run simulations 24/7 because of some projects or learning are ongoing. With VIRL you get almost the latest firmware for supported platforms. Almost – sometimes you have to wait for next release for a new firmware to be available. I experienced it a few months ago when with ASA 9.7(1) release Cisco introduced the route-based VPNs (VTIs). At this point VIRL users got the 9.6(2) release bundled into latest simulator release. In other simulation, you may want to use different ASAv firmware versions for various nodes, so your simulation is more similar to your production network.
Cisco VIRL uses real firmware in the simulations. I will show you how you can add different ASAv firmware and use it in parallel with the software available on VIRL repository.
Last week Cisco released the VIRL PE 1.3 (previously called just VIRL). This version includes major technology upgrade to the underlying infrastructure; only minor adjustments are visible to the users. That was something everyone expected as old Ubuntu used for VIRL 1.2 regularly asked for packages updates.
I worked with new VIRL for few hours. I must say I am not impressed. Some old problems got back, at least in my installation. Frequent snapshots of the VIRL VM are something required again. Here is my quick summary of my thoughts and experience so far
The IGMP Snooping is a nice feature to limit propagation of multicast traffic in Layer 2 Ethernet network. It listens to IGMP (Internet Group Management Protocol) messages traversing the network to learn about source and receivers. Using this information switch builds a map of links where it replicates the multicast frames. What if we do not have this feature enabled? The switch will treat multicast frames as an unknown type and will broadcast over all active ports no matter is there is receiver interested in frames from the particular multicast group or not.
IGMP Snooping on a single switch is useful to limit propagation of multicast frames when source and receivers are in same layer 2 broadcast domain, in the same VLAN. IGMP Snooping is enabled on Cisco switches by default, but it does not mean it will work out-of-box.
Ostinato is a traffic generator. You can use it to craft packets and send flow into your network. You can even send multiple streams if required. It is a tool that network admins and developers should use for testing the system or application against various scenarios. Ostinato is by default available on Cisco VIRL so we can use it as a packet generator in our simulations.
Ostinato consists of two components – the LXC image run in a simulation that generates the traffic and GUI frontend. In this article, I will show you how to use it to generate a multicast stream in VIRL simulation.
I’ve been using Cisco VIRL for over two years for both learning technologies and testing new solutions as PoC. Accessing devices in simulation via embedded console link is easy but not efficient. I always wanted to manage simulation in VIRL from my laptop not desktop PC. Also in many scenarios you may want to connect external servers like netflow collector or IPAM software you wanna test. Also it’s quite handy to have access to running simulation form Internet, isn’t it?
Let me show you how I connect Cisco VIRL running simulation to other devices in my network and to Internet. In this tutorial I assume that you didn’t change default VIRL networking configuration.
One reader asked me few days ago following question when he had problem establishing the failover in his lab: “I’ve tried to create ASA failover pair on VIRL and it was not working. I’ve looked through manual and VIRL forum for the solution. I believe that failover is supported configuration on VIRL. I think my configuration is correct, nodes can ping each other but I still cannot establish failover relationship”. Configuration he made was correct except he forgot about one thing – interfaces numbers are important when you setup failover using ASAv.
Cisco VIRL uses ASAv image for virtual firewalls. This is same image that you use in production on ESXi. That means all restrictions applies also to virtual firewall if you run it on VIRL. In this image we must configure failover link using interfaces GigabitEthernet0/8. It’s clearly stated in documentation. If we use any other interface the configuration will be accepted but failover never established.
failover lan unit primary failover lan interface Fail-link GigabitEthernet0/8 failover replication http failover link State-link GigabitEthernet0/7 failover interface ip Fail-link 192.168.255.253 255.255.255.252 standby 192.168.255.254 failover interface ip State-link 192.168.254.253 255.255.255.252 standby 192.168.254.254 failover ipsec pre-shared-key 0 FailoverKey failover
We also need to remember we can’t configure Active-Active failover. This mode is not supported so we have to stick to Active-Standby model. It’s direct result of lack of support for virtual contexts so remember about it as well.
Why Swift? Because I got bored one evening 🙂 Well, that’s partially true. I’ve heard good opinions about Swift language from professional developers. It’s now open language available for many platforms, not only Apple products. I also like to try new things and was curious if learning at least basics of new language by myself would be hard and how quick I can do that. Also Apple was very helpful because of nice tutorial from Apple Developers which show step by step how to use XCode, build application interface and connect code to objects. There are many examples on Internet, I think the hardest thing at the beginning was to understand some language semantic constructions and get familiar with API of system libraries. Also, if you ever start programming in Swift remember that current version is Swift 3.0, but many examples on the web are from older versions and won’t work without minor or major changes to the code.
So what was my concept of an application? Easy, I just wanted to get information about firmware version installed on ASA. But of course if you have idea of other apps then sky is the limit 😉
I was not planning this chapter and putting away Perl for even a moment, but I have some talk with my VeriFone colleague on scripting, REST API and how creating web server which uses REST API back end to control certain parameters of firewall is not that easy and straightforward. We both have some programming and scripting experience but neither of us is a programmer. We both know more or less several programming languages but we are not proficient. But we both have (at least we thing we have) good fundamental knowledge about programming.
The topic circulated around web page that will let display and manipulate ACL entries on firewall in non-SDN data center. Feature quite simple that most independent firewall management platforms can do. The problem is that most of those applications are using CLI via SSH to send commands and parse output, that’s exactly how Cisco ASDM is working in example, but we wanted something maybe a little more flexible, reliable… We both agreed that JSON is flexible structure that should be easy to use. So how to write a comprehensive script?
First published: 09/Jan/2017
Last update: 09/Jan/2017
In chapter Cisco ASA REST API – Part I: Getting started primary configuration for REST API has been done on firewalls then in chapter Cisco ASA REST API – Part III: Checking if prefix is directly connected first script in Perl has been created. Let’s now look at ways we can troubleshoot REST API calls and status on Cisco ASA. This may be crucial to detect cause of the problem. Troubleshooting requires command line access to firewall in enabled mode.
In this chapter I will use script I presented previously and also will execute some REST API methods using Firefox RESTClient extension mentioned if first chapter. Because output of debug can be extensive listings will contain only crucial parts.
Debugging REST API means checking particular component for errors or other logs that might be interested for us. Command execution require in first place declaration which component will be debugged.
asav-1# debug rest-api ? agent Rest-API Agent cli Rest-API cli handling client Rest-API client request handling daemon Rest-API debug/syslog handling process Starting/Stopping of Rest-API Agent token-auth Rest-API Token authentication