I do this because the 3640 has the slowest CPU of all the models simulated, and since dynamips has to emulate each CPU cycle, the fewer cycles that need to be emulated, the less work dynamips has to do. Simple tip, more based on feeling than fact, but I try to run simulations on the slowest old dog routers available (Cisco 3640) where possible, rather than running a more powerful, newer model. Quite often that’s a reasonable compromise though. VPCS is pretty memory and CPU efficient so it’s a good solution to the problem of simulating users, but the pay back is that it’s pretty limited in what it can do. It’s incredibly unintuitive to use, but once you get to grips with adding hosts for VPCS, you can ping and traceroute to your heart’s content from real LAN-connected endpoints. If you want to move to a true end point connected to an interface, check out the VPCS (Virtual PC simulator) capabilities now in GNS3. ![]() This is a little bit of a cheat, but it can suffice for basic testing. The first involves using loopbacks on routers. There are two easy ways to simulate end points for ‘traffic testing’. You can also inject BGP routes from external sources Jeremy Gaddis has an excellent post on getting BGP routes into dynamips using perl, which is great especially if you need huge numbers of routes. But it was important that I could manipulate the BGP to OSPF redistribution and see the result – again, it’s about knowing what you are testing. The fact that I didn’t have two different ASNs for the simulated MPLS didn’t matter because the network I was testing only cared about the OSPF. I then used a single router and appropriate route-maps to peer with two simulated CE routers that would then redistribute the routes into OSPF so they were injected into the network. Rather than using two routers, I used route tags to allow me to distinguish routes that were unique to CarrierA, unique to CarrierB, and those carried by both. In a recent simulation I had to simulate the MPLS service for two service providers. I use route tags to mark similar routes, then redistribute static into BGP via a route-map that can set appropriate parameters on the routes based on the tags. If I’m injecting BGP routes my approach is usually to configure static routes to null0 on the router that will act as the route source. If you can, you quickly build up a library of little scripts to process configurations and generate commands to inject routes. If you can’t script (I’m a perl addict) this can be tricky. You can’t easily simulate the entirety of the rest of the network, so instead I’ll grab a copy of the routing table from the production device, and I’ll reverse engineer it so that I can inject the same routes with, as best I can, the same metrics. If your network change involves manipulating routing, you need the routing tables to as accurately as possible replicate reality. If I’m not testing the firewall itself, and it’s just a transit device, why not simulate it with a router instead and keep your simulation simpler? You may have a redundant pair of edge routers, but if that isn’t an important part of your simulation, do you need both routers in the simulation? Could you suffice with a single router? Injecting Routes ![]() For example, I may have a firewall in a simulation, running OSPF. Think about what you are actually testing. Doing so makes it so easy to migrate configurations from lab to production via your change script, so it’s worth the extra effort up front. Similarly, take a moment and also match things like OSPF process IDs, BGP ASNs, and so on. IP addressing should match production wherever possible (you don’t want to have to convert IPs from lab configs to production, as that usually introduces errors). receive dynamic routes, process them, have similar configs to production), and which parts of the network I can simulate with a single router that just injects routes. So wherever possible, I’ll figure out which routers need to be realistic in the simulation (i.e. Using dynamips for a while has taught me to simulate as little of the network as possible, because CPU is a valuable commodity and simulating routers eats up CPU pretty quickly. I’ve been running IOS simulations in Dynamips for a number of years now, and over the last few years in both dynagen and the ever-expanding GNS3, I’ve found a few guidelines that have remained useful in any situation in terms of maximizing the number of routers you can simulate on a given host machine.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |