----- Original Message ----- From: "Priscilla Oppenheimer" To: Sent: 03 August 2002 7:48 pm Subject: Re: RIP/IGRP Routing Simulator? [7:50586]
> > is a bit larger. Both the simulator & the analyzer approach > > aren't much help > > with at least one part of the certification preparation process: > > > > altering configuration parameters on the cisco IS & verifying > > that the > > packet structure & content match the expectations you are > > developing. > > He can do that with a protocol analyzer. I don't see your point I guess. (He > did say he has some routers.) Changing Cisco IOS configs and capturing with > an analyzer is an excellent way to see how protcols really behave. The > packet strucutre won't change usually, but the contents will change. Agreed. The distinction is roughly as follows: 1. If you don't have enough routers, you can certainly simulate traffic directed towards those routers by using pc-based costware packet capturing tools, thus simulating environments where many routers are in play, transmitting the traffic you have captured. 2. However, any time you wish to verify what a cisco l3-capable device would do based on a particular type of configuration change, you must rely on output from the original router, not your retransmitted sniffer/etherpeek/whatever output. It's a question of verifying the spec, the vendor's statements on how their implementation behaves and how unspecified conditions are handled. If you wish to test how multiple misconfigurations on multiple devices exchanging information with each other behave, there's not really a substitute for multiple cisco routers, unless you're willing to capture the device from a target router and coordinate the retransmission. If he has enough routers, great, but if he already has a given number of routers and asks about available windows simulators, chances are, he is seeking to understand how large numbers of directly connected intermediate systems interoperate. >>(As > > usual, the > > proprietary specifications themselves remain closed). > > IGRP protocol specifications are easy to learn even it is technically > "proprietary." Of course, the protocol analyzer vendors have all learned it > (and EIGRP) quite well. Sniffer does a particulary good job of decoding EIGRP. This is encouraging, but anyone on the path towards understanding should verify these specifications and their resulting consequences for themselves. The danger with proprietary technologies is the tendency to assume that routers react to inbound packets with a specified header-content/payload as the vendor insists they would. > IGRP, by the way, is completely specified in this old paper from Rutgers, > which Cisco never objected to: > > http://www.cisco.com/warp/public/103/5.html > > EIGRP protocol specification info is harder to find, though from an > operations viewpoint, TAC has some terrific papers here: > > http://www.cisco.com/warp/public/103/eigrp3.html > In retrospect, it kind of makes sense that proprietary technologies would have a better chance of converging towards a more complete specification, since they don't have to leave any details to vendor discretion. In spite of that, it remains a valuable exercise to verify that these protocols behave according to vendor specification. > > Priscilla Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=50619&t=50586 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
