Now that I’ve had a chance to really put the virtual setup to the test, i’ve come across some problems with certain technologies that has forced me to look more toward rack sessions to study them. In case you haven’t read my previous posts, i’m running PEMU which is a variation of QEMU that emulates the physical platform to run ASA code 8.0(2).
When I was studying R&S which was almost entirely on dynamips I quickly learnt that if there was something that should be working that isnt, its probably dynamips being a pig. More often than not these issues we caused by the 16 port NM modules, and a restart of the topology was a quick fix – Maybe sometimes I would have to delete the working directory….but thats it, overall it was pretty solid and pretty much everything it supported worked beautifully.
Unfortunately with the ASA it ain’t the same. I’ve come across two main issues with it, one I have a workaround for, and the other I dont.
1. Multicast
The ASA is able to send multicast out of its interfaces which can be received by other devices in the topology, but it never sees multicast messages sent by other devices. Obviously this is a major problem with testing any multicast routing, but more importantly it affects RIP, EIGRP, and OSPF communication. Even though they aren’t a huge focus in the security lab, a lot of the Volume I labs, and no doubt the Volume II labs include them for obvious reasons. Its more annoying than anything….so to get around it i’ve been using neighbor statements on the routers and always using RIP as the routing protocol.
I’ll just have to make do for Volume I labs, but with this problem alone I dont want to be doing full scale labs with just RIP – It’s guaranteed that i’ll fall into some kind of habit that will work against me when I go for the real thing.
2. Certificates
I experienced a plethora of issues the other night with getting certificates working with the ASA and a simple L2L tunnel. Errors ranged from getting “Certificate not valid yet” from the CA when enrolling, to “Bad certificate received” on the IOS router when starting IKE P1 negotiations. Clock on the ASA was the same as the IOS router, configurations where scrapped multiple times, the Internetwork expert configurations didnt work, and an entirely new instance of ASA had no joy either. But every single time the IOS device was showing all the right messages. Jumping straight onto a rack I was able to get it running immediately which pretty much confirmed that something was up.
Even with these problems i’m still going to use the QEMU for as much as I possibly can. But just keep in the back of my mind that its far from a perfect study tool – and always maintaining the approach that if it looks right, but it still isnt working, its probably a good idea to try it on real equipment before spending hours troubleshooting something that isnt there :)
