cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1940
Views
0
Helpful
8
Replies

LAN Design

mistryj
Level 1
Level 1

We currently have a collapsed Core design with 6x 6500 Core switches distributed with WAN links to 2 data centers. Cisco 3850 User Switches connected to cores in main building. VM Enclosures and Servers connect directly to 6500 switches at Data Centers.

I need to create a pre-production LAN and a test lab. The test lab will be an isolated LAN but the pre-production LAN will have servers connecting to production AD / DNS servers.

What is the best practice for designing this type of environment ? Test lab is not a major problem , it's just the pre-production Lan which will have pre-production servers built before they get move to production.

How do you make the pre-production LAN secure and how do I connect to 6500 in main building as users?



2 Accepted Solutions

Accepted Solutions

devils_advocate
Level 7
Level 7

It depends on what the pre production servers need to access in order to be built and tested really.

Ideally I would use a seperate LAN switch for this pre production kit which is seperated from the main network via a (decent) firewall.

Main Network - Firewall - Pre Prod Switch

A static route on the Main Network L3 switch which points to the FW as its next hop for the Pre Prod Subnet which sits behind the FW.  If the FW can do dynamic routing, with the main network swich then use that obviously .

You may find you have to open a fair amount of ports and protocols on the FW however if the pre prod servers need to talk to live servers to pull down info like Windows Updates etc.

You could also stick the Pre Prod Vlan behind an ACL but having used these for 'Test' environments in the past, it can become unwieldly and complicated so I would invest in a decent FW.

View solution in original post

Imagine if someone accidentally assigns an IP that is used for a key production server to one in the setup environment and then it responds to arp requests, you could in effect take down a core service. Bear in mind the network engineers are not usually the ones who assign IPs to servers etc. but they are the ones who have to fix any issues that causes on the network.

So don't assume that everyone setting up the servers completely understands all the network issues. I have seen an entire DC taken down because a server engineer had setup the NICs wrong. If you simply connect to the production infrastructure you have no protection against this.

In an ideal world all the bugs are ironed out in the test environment you wouldn't face these problems but again, from experience, people often shortcut this.

There does come a point where a firewall is really not serving a useful purpose if you have to open that many ports but that is why i said in my original post it is just as important, if not more, to specify from the start what is allowed and what isn't and try to enforce that.

Jon

View solution in original post

8 Replies 8

Jon Marshall
Hall of Fame
Hall of Fame

This can be quite tricky. The key requirement is that nothing in the pre-production environment can interfere with your existing production environment.

Speaking from experience the problem is that once you have it in place unless you have very strict policies in terms of what is and is not allowed it testers and vendors etc. will start to request more and more access to more and more things. And cost always becomes an issue ie. we have all this infrastructure in production, surely it would be alright to link more of it to the pre-production environment and if you are not careful you end up with a complete mess with far too much visible to each enviroment.

That said i would recommend a firewall at the very least. You need to make sure there is no chance of production systems "accidentally" using pre-production systems so they must be kept as separate as they can. If at all possible you should use a separate switched infrastructure for your pre-production environment and the single connection to the production switch is via the firewall. 

That said though even a firewall will be of little use if you cannot refer to a policy guideline in terms of what is and is not allowed.

If you need to share infrastructure (\which isn't ideal) then you can look into using VRFs although how useful they are is again limited by how much access you allow between the two environments.

What i would first do is work out exactly what access you need between the two. DNS is relatively easy, AD (or anything Microsoft) can be a lot more challenging. Once you have this you then need, if you can, to get agreement as to what will and will not be allowed in the future.

I dont want to put you off doing this and it is certainl a valid requirement, it's just that having done this sort of thing before it is all too easy to find yourself allowing more and more access. And vendors/testers are not really concerned with security so it will always be down to you to try and justify why something shouldn't/can't be done.

Jon

mistryj
Level 1
Level 1

Thanks Jon.

The pre-production will be used but internal staff and one of my colleges believes it should not be a problem connecting directly to our Core switches in our main building where we work and where other users reside.

I disagreed with him and believe it will cause more issues , I also mentioned having a firewall but again yes your right , it's based on requirement and how much access it required.







Sent from Cisco Technical Support iPhone App

devils_advocate
Level 7
Level 7

It depends on what the pre production servers need to access in order to be built and tested really.

Ideally I would use a seperate LAN switch for this pre production kit which is seperated from the main network via a (decent) firewall.

Main Network - Firewall - Pre Prod Switch

A static route on the Main Network L3 switch which points to the FW as its next hop for the Pre Prod Subnet which sits behind the FW.  If the FW can do dynamic routing, with the main network swich then use that obviously .

You may find you have to open a fair amount of ports and protocols on the FW however if the pre prod servers need to talk to live servers to pull down info like Windows Updates etc.

You could also stick the Pre Prod Vlan behind an ACL but having used these for 'Test' environments in the past, it can become unwieldly and complicated so I would invest in a decent FW.

mistryj
Level 1
Level 1

Thank you.

I am just wondering what firewall and what benefits I would achieve from having a firewall as Internet. AD etc will still be required via production.

Looking at connecting a Cisco 3750 off the Core switch in main building so users can access servers from their desks.





Sent from Cisco Technical Support iPhone App

As this is a pre production environment as opposed to test, the risks should be less in terms of something cause an issue but there is still a risk.

At my old workplace we didn't have a pre production environment as such. Servers were built using base images and then a document was followed for the rest depending on its function and they were plugged into the live network when it was required, after a change form was completed.

Connecting a 3750 straight off the core for the pre prod kit without a FW means any servers connected to that switch would be able to communicate with the rest of the network but is that what you want anyway?

When building an AD server you will likely have to do a Windows Update which means Internet Access or access to your WSUS/SCCM server. You would need to add it to the live domain at some point anyway so are you going to gain anything by putting it behind a firewall whilst being built? How much of the build can be done without access to the live network?

I am not trying to convince you either way but you need to understand what you are actually trying to achieve here. A firewall between pre prod and live will allow you to control which ports/protocols are allowed back and forth but if you find you need to create a huge number of rules to a point where the FW becomes redundant, have you achieved anything?

Imagine if someone accidentally assigns an IP that is used for a key production server to one in the setup environment and then it responds to arp requests, you could in effect take down a core service. Bear in mind the network engineers are not usually the ones who assign IPs to servers etc. but they are the ones who have to fix any issues that causes on the network.

So don't assume that everyone setting up the servers completely understands all the network issues. I have seen an entire DC taken down because a server engineer had setup the NICs wrong. If you simply connect to the production infrastructure you have no protection against this.

In an ideal world all the bugs are ironed out in the test environment you wouldn't face these problems but again, from experience, people often shortcut this.

There does come a point where a firewall is really not serving a useful purpose if you have to open that many ports but that is why i said in my original post it is just as important, if not more, to specify from the start what is allowed and what isn't and try to enforce that.

Jon

Hi Jon

I have to admin, this is not something I had considered so its a good point!

My arguement would be that they would need to 'Re-Ip' the device before it went live anyway so there is a risk there as well. The downside of non network techies assigning IP addresses!

mistryj
Level 1
Level 1

Thanks guys few good points.


Sent from Cisco Technical Support iPhone App