how to find my way in the 'network' jungle' ?

I'm in a fairly new network environment and it's a really complex network environment with routers, switches, firewalls, DNS, DHCP and many other production firewalls. I have problem understanding the flow of traffic and understanding different subnets, especially when I look at the firewall configuration.

There are hundreds of subnets, NAT-ed address, partners connections. I just hate subnets; no thanks to whoever created them

The DNS servers is so complex, I can't even begin to explain it

What's the best way to know the network? Should I start from DNS servers, firewall, routers or something else. Also, there are no documentations except a few high level diagrams.

Find more posts tagged with

Free for TechExams community: Cybersecurity salary guide

Compare cert salaries and plan your next career move

Button

Comments

georgemc

Other than being the person who designed and installed it all, there's no better way to get to know the network than to be the guy who documents/diagrams all of it.

Since the diagrams/documentation doesn't already exist, the other techs that work on the network will probably appreciate it also.

georgemc

Other than being the person who designed and installed it all, there's no better way to get to know the network than to be the guy who documents/diagrams all of it.

Since the diagrams/documentation doesn't already exist, the other techs that work on the network will probably appreciate it also.

George

Pash

Start with your lower levels and work your way up. This way you can see physically what sits where on the network, vlans/zones etc. This wasy you can see which servers can service which subnets by looking at firewall policies.

GL.

TechJunky

Documentation.

The best advise around.

binarysoul

TechJunky wrote:

Documentation.

The best advise around.

That's one part of the equation. The other part is hands-on. For those who remember, I started a thread arguing against theory and voting in favor of practicality. It seems to me that after knowing a bit about the basics, the only way one can be successful in IT is through hands-on. This is why employers look for experience than for certifications (I'm certainly not discounting certificates, but expereince counts.

Unfortunately, hands-on isn't always feasible. I can't do some intrusive testing on the production network.

leefdaddy

binarysoul wrote:

TechJunky wrote:

Documentation.

The best advise around.

That's one part of the equation. The other part is hands-on. For those who remember, I started a thread arguing against theory and voting in favor of practicality. It seems to me that after knowing a bit about the basics, the only way one can be successful in IT is through hands-on. This is why employers look for experience than for certifications (I'm certainly not discounting certificates, but expereince counts.

Unfortunately, hands-on isn't always feasible. I can't do some intrusive testing on the production network.

lol, you just asked what that meant yesterday, now you're using it in posts...

binarysoul

leefdaddy wrote:

lol, you just asked what that meant yesterday, now you're using it in posts...

Things are much more complex than what I stated above. The environment is heterogenous, comprised of hundreds of routers, switches, different firewalls, vendors, partners, different ISP's and you name it. Maybe I'm looking for that magic solution that may happen in Science fiction movies

But I hope to get more input on this...

I'm not the 'know it all' type of person, but I do try to find answer for things I don't know.

empc4000xl

I would start with big block diagrams 1st. Like having a server farm, but just one box representing all servers. Then what is that conncted in another box and so on. So a big large overview 1st. Then each area like that server farm for instance, I would have how each box is setup in that area and what its ip is and what's its function. So all in all in the end you would have a binder or drawing and informantion. Then I would have another binder that has each piece of gear, the part number and its function and a brief write up. Thats how it was done on the missle systems i worked on and its done here at the NOC also. This is not a 1 day plan however. This will take a few weeks and then rechecks to make sure its all right.

Netstudent

empc4000xl wrote:

This is not a 1 day plan however. This will take a few weeks and then rechecks to make sure its all right.

All in good time man. Nobody should expect you to totally conceptualize the whole network all at once. You are going to have to study it with documentation and you will have to work with each part a few times before it all starts coming together. In a network like you describe, it might take 6 months before all the peices start to fit together. Just take the advice already given here and be patient. When things start going wrong and your in knee deep, you will start to remember the network. My best learning experiences have been from network outages.

binarysoul

Thanks folks for the feedback. I agree that this isn't an overnight process. I also agree with Netstudent 100% that experience comes from outages. Actually,yesterday I thought of looking at incident tickets logged over the past few months to see how things broke and what fixed them.

Working with firewalls is probably the toughest, not because firewalls are difficult to learn, but because the network is very complex. So, if I'm told to change a rule or add a rule in firewall, first I would have to understand the networks/subnets involved and then make the change.

mikej412

It's probably easiest to start with a high level view, and then drill down into those areas that you may be responsible for or work with.

Check out some of the Cisco Design Guides to get an idea what could be in your network -- which could give you some ideas what to search for.

Ahriakin

I had to do something similar when I started my current position. There was a simple Visio drawing that showed each site in the US linked together and those in Europe similarly, no mention of HOW they were linked.
My advice is nail your subnets first, in blocks as the guys have suggested. Make sure you have a solid map of subnets to sites. When that's in place head to your routers and do a simple lookup of the route table, take it branch by branch and follow each through to the end site then head back and start again. The last(ish) piece of the puzzle would be to delve into the access lists on your routers and end devices, particularly those terminating VPNs. Don't presume a route statement means that the traffic is actually cleared to go across a tunnel, it might be a remnant from an old config.