<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.2627" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Verdana color=#0000ff size=2><SPAN
class=915255111-24112005>Without knowing the number of users/servers involved, I
can comment generally. They are suggesting what I believe are best
practices.</SPAN></FONT></DIV>
<DIV><FONT face=Verdana color=#0000ff size=2><SPAN
class=915255111-24112005></SPAN></FONT> </DIV>
<DIV><FONT face=Verdana color=#0000ff size=2><SPAN
class=915255111-24112005>1. If you have capabilities on the switches to do
intervlan routing, it is best to configure them that way. Likely if you have
dual core switches, you should set-up HSRP. If not, you can still
configure HSRP with the 3845 as standby, however you should look at "sh process
cpu" to ensure that your current routing process is not eating up more than
75%. Consider EIGRP on the whole network if you are not running it
already. Business benefit: Faster routing, better redundancy, less
susceptibility to storm based DoS, more capability to do
broadcast-control.</SPAN></FONT></DIV>
<DIV><FONT face=Verdana color=#0000ff size=2><SPAN
class=915255111-24112005></SPAN></FONT> </DIV>
<DIV><FONT face=Verdana color=#0000ff size=2><SPAN
class=915255111-24112005>2. This is the ONLY setup that will provide you
with clear delineation between the naturally "different" roles of these
devices and therefore the capability to put ACLs or VACLs (which you should put)
that disallow access to all voip services from user data subnets to voice
subnets except for only the needed ports. Users and in some cases servers
should not access voice vlan to manage or perform normal windows based
transactions to VoIP servers. This should be VERY selective, only serving
the validated needs, for example Port 80 for CCM user and Admin, port 80 for any
internet app access to a proxy, etc. You will also prevent a broadcast
issue or DoS in data VLANs in affecting the voice vlans. Voice to voice
vlan communications should not be restricted as they are trusted devices to each
other. Business benefits: Better security and robustness for voice
applications, more admission control base don business
needs.</SPAN></FONT></DIV>
<DIV><FONT face=Verdana color=#0000ff size=2><SPAN
class=915255111-24112005></SPAN></FONT> </DIV>
<DIV><FONT face=Verdana color=#0000ff size=2><SPAN class=915255111-24112005>3.
Where possible it's advised to reduce the arp broadcast domain, i.e. use smaller
chunks of IP addressing. Easiest way to accomplish is divide floors or
sections of floors into chunks of Class C. In almost all general cases,
users should all be trying to access the server vlan and voice vlan anyway, not
each other. That routing load is there already once those vlans are
separated out, however setting the L2/L3 architecture this way segments the
network for better performance as all PCs do not have to process large amounts
of broadcast arps, and also allow better identification of where data is coming
from or problem might be.</SPAN></FONT></DIV>
<DIV><FONT face=Verdana color=#0000ff size=2><SPAN
class=915255111-24112005></SPAN></FONT> </DIV>
<DIV><FONT face=Verdana color=#0000ff size=2><SPAN
class=915255111-24112005>There is good reference in Cisco CCIE fundamentals
for network design and case studies if you can find it on the web or at a book
store.</SPAN></FONT></DIV>
<DIV><FONT face=Verdana color=#0000ff size=2><SPAN
class=915255111-24112005></SPAN></FONT><FONT face=Verdana color=#0000ff
size=2><SPAN class=915255111-24112005></SPAN></FONT> </DIV>
<DIV><FONT face=Verdana color=#0000ff size=2><SPAN class=915255111-24112005>Hope
this helps.</SPAN></FONT></DIV><BR>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> cisco-voip-bounces@puck.nether.net
[mailto:cisco-voip-bounces@puck.nether.net] <B>On Behalf Of
</B>TechGuy<BR><B>Sent:</B> Wednesday, November 23, 2005 7:04 PM<BR><B>To:</B>
cisco-voip@puck.nether.net<BR><B>Subject:</B> [cisco-voip] Network Change
Recommendations<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV>We have some engineers in helping with a new callmanager and IPCC
implementation at a secondary company of ours.</DIV>
<DIV> </DIV>
<DIV>They have made some recommendations on some network changes and I wanted to
ask others about the changes and what you think would be the pro's and con's of
doing so and why do you think they are suggesting these changes. </DIV>
<DIV> </DIV>
<DIV>1. Move the inter-VLAN routing to the switches. (This office
has a maxed out 3845 acting as the core router and voice gateway, it currently
does all routing)</DIV>
<DIV> </DIV>
<DIV>2. Seperate VLANs for servers, pc's, callmanagers, phones
(Currently we have one vlan for servers and pc's, and one VLAN for callmanagers
and phones)</DIV>
<DIV> </DIV>
<DIV>3. Remove class B addressing and utilize Class C addressing (The
internal network was originally configured with Class B addressing
throughout)</DIV>
<DIV> </DIV>
<DIV>Thats the bigger changes that I really just want to understand the various
pro's for why they would recommend them. They make sense and I don't
question that these are not best practices but I want to really understand why
the changes to sell it to management. Their philosophy is "if its not
broke dont fix it" and feel that the network has been working fine so why all
the changes. </DIV>
<DIV> </DIV>
<DIV>Thanks for your time!</DIV></BODY></HTML>