[cisco-voip] Network Change Recommendations

[Kazmi, Zeeshan]

Without knowing the number of users/servers involved, I can comment
generally.  They are suggesting what I believe are best practices.
 
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.
 
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.
 
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.
 
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.
 
Hope this helps.

________________________________

From: cisco-voip-bounces at puck.nether.net
[mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of TechGuy
Sent: Wednesday, November 23, 2005 7:04 PM
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] Network Change Recommendations


We have some engineers in helping with a new callmanager and IPCC
implementation at a secondary company of ours.
 
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. 
 
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)
 
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)
 
3.  Remove class B addressing and utilize Class C addressing (The
internal network was originally configured with Class B addressing
throughout)
 
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. 
 
Thanks for your time!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://puck.nether.net/pipermail/cisco-voip/attachments/20051124/9fc892c9/attachment.html