I am currently working on a SMB level design in which I need prepare and present a design to the customer. It is my first time to design a network, thus requesting some help here.
Here is the customer requirement..
Customer Scenario: *********************** It is a new design
There will be one primary Data center and one Disaster recovery site which will server 10 branch locations.
• At HQ where DC is located they plan for 400 users • At DR Location they plan for 120 Users • Branches users will vary from 10 to 20 • Customer will host application like ERP / Mail / Web / some other applications at DC & DR
Customer wanted an optimal cost effective solution to run the business with below features
• Connectivity to all locations with redundant paths • Routing and Switching required at all locations • Secure Network at LAN / WAN / Perimeter • In case of Primary DC fails users should be able to connect to DR and business should continue • Single Communication infrastructure across the organization (Unified Communications Solution) • 45 seats Contact center deployed at DC and 15 agents at DR location
Can someone help me designing a cost-effective solution along with the product specification to pitchin.
These forums are not really designed to provide complete designs from scratch. It is too big a subject and presumably either you or the company you work for are getting paid to do this work so you should at least be able to come up with a base design ?
So simply listing a set of requirements and then saying please design this network for me together with a specification list is not a reasonable request. If you come back with a design and ask for comments or get stuck while doing the design then we would be only too happy to help with any technical issues you have.
If you are struggling to get going then Cisco have a set of comprehensive design guides whch will get you started -
I did some search and designed the following network.
Please let me know, that I need to make any changes here.
Thanks and regards,
Very impressive. Overall looks very good. Some comments/questions to consder -(although by no means do you have to implement them -
1) Why use ISDN when you could use ADSL as the backup. If you wanted you could use the Internet as a backup using IPSEC tunnels then you wouldn't need the ISDN. Alternatively you could have a second ADSL line that goes across your providers network rather than the Internet so you could have either -
ADSL (over SP network) secondary for backup
or MPLS primary
ADSL over internet using IPSEC (DMVPN would be a good solution)
If you want to centralise Internet access which it looks like you do then perhaps ADSL over SP network would be a good choice. Your SP may or may not offer this but ISDN is an old technoology with limited bandwidth. Don't rule out ADSL over the internet because you can still centralise internet access by only using the internet connection at each branch site to send traffic to HQ.
Having said that if you are runnng Voice over the WAN and you need the backup and you can't get ADSL from your SP then ISDN could be used.
2) in your main HQ site you have both the ISDN and MPLS terminating into the same router which means if that router crashes then you have lost all your redundancy. If you are going to have dual WAN links then it makes sense at HQ to have 2 separate routers. Note the router for teh secondary link does not have to be that expensive as the bandwidth for that link will be quite low.
3) From the looks of your digram i assume you have redundant sups in the 4507 - can you confirm ? Also what supervisor are you planning to run in the 4507 and what linecards. Bear in mind the 4500 bandwidth capacity per slot varies greatly depending on the linecard/chassis/supervisor choice ?
4) it's not clear how the DR site works. Are you replicating between the servers at HQ and the servers at the DR ? If so how are you replicating ? ie. incrementally throughout the day or overnight. If throughout the day then make sure you have enough bandwidth at the HQ site on the MPLS link to cater for that and the branch sites.
5) On the point of DR, how do you envisage it working ? ie. are you going to try and failover if the server fails at HQ and if so how are you going to do this. Or is it a site that will only be used if the HQ site is unavailable ? Also IP addressing - see point 6.
6) IP addressing. There is no addressing on this diagram so you may already be doing this but make sure you can summarise each site, ideally with one supernet entry. Make sure you allocate any loopbacks, management addresses for each site from the same supernet.
DR addressing is particularly important. How is that going to work. It's a big topic but are you -
i) planning to use the same address as the HQ servers when you need to the DR site ? If so you need to think about how you are going to replicate the data between servers as if they both have the same IP it won't be possible to route between HQ and DR.
ii) use different IPs for the DR servers. If so you need to make sure all the applications use DNS to resolve IPs ie. some apps use hardcoded IPs and this can be a problem if you change the IP. There really shouldn't be apps using hardcoded IPs, it's not good coding to be honest, but i have been caught out before with this.
If you are going to use different IPs how will you update this info to the branch clients ? DNS is the way to do it but be aware clients cache DNS records so you may update the DNS but the clients still wants to go to the old address.
7) DR replication. I notice you have ERP servers in HQ. Using a DR site for ERP brings it's own challenges. How will you ensure the database is in sync ? ie. if you have to failover some of the last updates on the HQ ERP server may not have got written to DR so you know have inconsistent DBs. I have been involved with this sort of thing before and it is complicated. We ended up using a dedicated link between the HQ and DR site for replication but this can be costly and you may not have the budget. But you need to understand that if HQ is using the same link for these updates as it is to talk to the branches there is a potential for delays in the update. QOS could be helpful here.
So it's important to understand what the customer actually thinks is going to happen when they need to invoke DR. When faced with the cost involved to implement that they may choose to look at an alternative solution.
8) The voice side of things i can't really comment on too much as i am not a VOIP person. If you have any specific queries about the VOIP setup i suggest you also post this into the telephony forums.
So those are my initial comments. I've written a lot but from a High Level the design looks good. I appreciate that this is not an Enterprise design so the DR setup may be a lot simpler than i have anticipated but as already said i can't stress enough how important it is to fully understand what the customer is expecting from the DR solution. I also appreciate that cost as always is an issue so you may not be able to implement dual routers at the HQ site but i have included these considerations anyway.
Also we haven't covered bandwidth and scaling of the links but that is difficult without knowing anticipated bandwidth uses.
[toc:faq]The ProblemOn traditional switches whenever we have a trunk
interface we use the VLAN tag to demultiplex the VLANs. The switch needs
to determine which MAC Address table to look in for a forwarding
decision. To do this we require the switch to do...
[toc:faq]Introduction:Netdr is a tool available on a RSP720, Sup720 or
Sup32 that allows one to capture packets on the RP or SP inband. The
netdr command can be used to capture both Tx and Rx packets in the
software switching path. This is not a substitut...
IntroductionOSPF, being a link-state protocol, allows for every router
in the network to know of every link and OSPF speaker in the entire
network. From this picture each router independently runs the Shortest
Path First (SPF) algorithm to determine the b...