I can't say for certain with 6.2 as I'm only familiar with 6.3+ but this is how you would usually do it.
access-list dmz-in permit tcp host 192.168.254.50 host 192.168.1.10 eq 1433
access-group dmz-in in interface dmz
This will basically put an access-list on the DMZ interface and allow the traffic that you have mentioned.
Be aware that if you don't already have one applied that when you put an access-group on an interface it changes the traffic behaviours of existing traffic and you will need to add these to the same ACL.
Well, you're hitting that space where emulation and physical world interconnect.
First, let us cover the basics: 3725 is a router, and it has some limited switching capabilities, because it could (in real world) use switching modules, and the switching code was needed in IOS.
When you write 'standard GNS3 switch' I assume you mean NM-16ESW module emulated by the dynamips? If so, that's exactly the module and code you're using anyway with 3725.
For any security type of testing, including CAM exhaust attacks and even port security, I'd do testing only in real environment. Emulated/interpreted in run time setup doesn't always provide the same (or repetable) results for multiple of reasons, and it's plainly visible in any time-bound features, like QoS and some parts of security mechanisms (that count on proper timing and order of events triggering in IOS).
Now, going back to your question: there are two parts of answer:
- First, the code that manages the CLI output for "software switching" IOS code that was added back when the NM-16ESW was introduced, underwent a lot of changes during the product lifetime. One of the extensions was to add 'backpressure' to allow faster MAC aging when there's flood of new addresses, the same code was also present in the standalone switches of that time (Catalyst 2950 and later models - 2960, 3560 and 3750). You may be hitting this exact feature, as you're using pretty new IOS (12.4(15)T). So, the switch may simply fast-age old MACs that it didn't saw any traffic to/from, and install new entries you're flooding - how fast BTW is your flood?
- The other part of the answer is that this command was fixed multiple times as it wasn't always giving current situation, but some older, cached one gathered from the ASICs.
Again, doing that kind of testing with simulated environment just pushes it too far, I'd go back to some hardware setup and test/lab it to reflect real scenario. Even if you hit success, you may not be able to repeat it in predictable manner later on.
Best Answer
You can do a PIX emulation if you need to, and there is still a demand for this functionality in spite of there no longer being "official" support for PIX within GNS3.
Jason Neumann explains the process on the GNS3 community web site at https://community.gns3.com/message/8432#8432