Flat networks and benifits of segmenting them..

How long is a piece of string?  I think Martin's point was that "your network may vary".  In fact, this is one of the areas in which I offer advice to companies all the time, so I'll try to give you a more thorough explanation, even though you may not like it.

First off, you must look at the number of broadcasts being seen on the network every second, and also look at the broadcast bandwidth.  (Use a good network analyzer, like Sniffer or Etherpeek to get much better statistics.)  This gives you an idea of the amount of "background noise" that you are seeing.  Having a broadcast rate of 40 packets per second (pps) is no big deal.  In fact, NICs are often capable of thousands of pps with no discernable load, especially of they have a TCP Offload Engine (TOE) on the NIC.  (Most cheaper cards do not, of course.)  Of course, each broadcast packet inbound must be processed, so it'll generate a CPU interrupt, and more.  Again, faster computers will see no discernable performance penalty, but older, slower boxes could definitely see it.  To get a feel for it, try using Sniffer to transmit broadcast packets at a varying rates and see how much it impacts various computers.

Second, you must know if you current have hubs or switches (which your post did not specify).  Although, since you seem to only be worried about broadcast traffic, then I am suspecting that you have switches.  In this case, you have already segmented the ethernet network into smaller collision domains, which is a huge gain right there in limiting the amount of traffic that is seen by each workstation.  Switches will also limit the amount of data traffic across various segments, which is especially important when placing servers -- try to place each server closest to the users who primarily access it to avoid crossing into another switch if you can avoid it.  This means that only broadcast packets are getting to each workstation.  If you are only seeing 40 pps, then I would honestly stop worrying about it.  Your last post mentions "collision domains", but this is in reference to the MS paper.  Of course, collisions are related to the old (i.e. flat) ethernet segments with hubs/repeaters, and NOT switches.  If you do indeed have a single-segment Ethernet network, then you'd be seeing a LOT more than 40 packets per second.

Next, you must examine the type of traffic on the wire.  If you are constantly seeing "burst" traffic, such as file transfers, in which a small request is made, and data streams from the server down to the workstation, then adding a router to the network will definitely improve performance.  On the other hand, if you are running database traffic that is request/reply based (i.e. it sends a small request, then waits for a small reply to come back from the server), then please note that adding ANY device to the network path will increase round trip time (RTT) and overall latency.

Case in point -- I have a single workstation and a single server communicating client/server for a database.  The typical response time for the database server is 0.01ms.  Now, I add a series of 10 switches into the mix.  Each switch adds its own latency to the network path.  A cut-through switch has a latency of about 6 bytes (since it can start forwarding the packet as soon as the destination MAC address has been read off the wire), and performs very well in this environment.  Even having 10 switches causes an increased latency of about 60 bytes of transmission time.  However, most switches today are configured as store&forward.  This means that the entire packet is read into each switch FIRST (to make sure that the packet is good), and THEN the switch starts transmitting downstream.  This means that having 10 switches on a tiny 100-byte packet will increase the latency time to 1000 bytes.  

Why do we care?  A request/reply protocol (like a database) will often generate MANY round trip times for a given process.  Let's examine simple numbers -- I want to read 1000 records from the database.  If my RTT is 0.01ms, then the time it takes me to do this is 0.01 * 1000 or 10ms.  Nice & fast, right?  However, if I add many switches, routers, and other devices to the network path, and I increase the RTT to just 1ms, then I now have a "user response time" to read those same 1000 records of 1000ms, or 1 second.  Still reasonable?  Run the same app over a long distance, with more devices and a latency of 20ms, and your application response time now jumps to 20 seconds -- completely unreasonable for the human sitting there.


So, back to your original question.  You are proposing to add a "slow" device, i.e. a router, to the environment to segment the broadcast traffic.  Routers are slower than switches (though not so much any more, with advanced hardware).  I agree that this will reduce the broadcast traffic, especially ARP traffic, which is probably most of it.  I also agree that it may make troubleshooting easier, since each network will be segmented into smaller areas.  

I also believe that adding another device will make it SLOWER for users of some applications using request/reply traffic.  I also think that adding another device to manage may have the opposite effect and increase the workload -- but this depends on the hardware chosen and if YOU have to manage it or not.  Remember that a router will have to be configured, maintained, patched, and possibly repaired at some time.  (Which may require a hot spare, too.)  You may also have to duplicate all segment services, such as DHCP, and possibly set up new routing rules, new firewall rules, and more.