--- Begin Message ---
------- Original Message -------
On Monday, October 2nd, 2023 at 14:26, Michael Sims via uknof
<[email protected]> wrote:
Hey Mick,
> I am new to network design, I have mainly come from an operational
> background. Honestly I’m struggling to wrap my head around all the parts you
> need to consider in all designs. I feel I’m back to square one and need
> mentoring. How did you all get confident with the designing role overall?
This is such a huge topic I’m not sure how to address it in an email but, here
are some starting points...
Firstly I tried to get a good understanding of the technology I was using:
1. I spent a lot of time in the lab (still do) really getting to know whatever
technology I would have to work with. By “lab” I mean that sometimes I’m
working at a company with a lab I can freely test stuff with, sometimes I’m
working somewhere with no lab and have to “test in production”, sometimes I’m
able to test on my home lab (which these days can just mean some virtual
machines or containers on my laptop, gone are the days of physical home labs).
2. It meant (still does) reading the RFCs to understand how the technology is
supposed to work. When I started out I found them intimidating but, you quickly
got used to them, and now they are usually the first place I look.
3. It also meant (still does) reading the vendor documentation in great detail
(because, they don’t always follow the RFCs, and because, RFCs are the theory
but, vendor docs are how you implement it). The first time I had to set up some
L2TP tunnels and terminate some ADSL subscribers on a Cisco 7200 during a
maintenance window, I feel asleep several nights in a row in the run-up, with
my laptop balanced on my chest, reading the Cisco documentation in bed until my
brain couldn't take any more.
Having said all that, you can never know everything about a specific
technology, you just need to get to a point where you feel you know what is
needed to make something work, and that you can recognise when something
probably isn’t going to work. Then you can flag it with your vendor, or during
lab testing, and make it clear to all that need to know, this needs further
clarifying.
Secondly, you need to gather the requirements for whatever you have to design.
Requirements gathering and confirming is a key step; kick out much as you can
to simplify the design (simplicity scales better, is easier to deploy, easier
to support, easier to upgrade/migrate/decommission, etc). This also helps to
meet your probably unrealistic due date and/or financial target. Whatever
requirements you’re left with, apply your technical know-how to come up with a
design that meets those requirements. Many customers and sales people like to
overestimate what’s “needed”, and by when. You can usually either remove
requirements entirely or stagger them, so that your initial design doesn’t need
to be so burdening.
Thirdly, use every resource that is available to you; ask your vendor if your
idea will work, ask your vendor if they have case studies from customers who
have done something similar, ask your steak-holders (the support teams,
deployment teams, your customer), try to test it in the lab, ask if others have
done this before, if anyone sees any problems. Don’t think of design work as “I
need to produce a perfect design, on my own”. No one person can know everything
or foresee everything. I think of it as some sort of technical project manager
type role (even though I’m the one configuring and deploying the devices), I
try to get eyes from all the steak-holders/customers/vendors on the design, to
find faults, and then address them together. So eventually I bring to the table
this mature design but, it took input from many to get there (and I usually
write that in there somewhere too, that the on-call engineers/the NOC/the field
engineers/the vendor/the customer, have all seen and approved this design).
> And any suggestions for home revision?
If you work somewhere with existing designs for other “stuff”, start by reading
those. At every company I have ever worked at, I have spent a non-trivial
amount of time reading through the designs of stuff I’m not working on, to get
an idea of how other networks work, to expand my horizons, to see if there is
anything I can re-use in my own work. I also contact those people to hear their
thoughts.
Also, do some Googling, you can find network designs freely available for
download on the Internet. Also search for content related to the Cisco CCDE
course, people publish their practice designs. You also don’t need to see “full
designs” (whatever that means), if you’re working with technology X but, you
don’t understand it, I’ve found some great blog posts over the years that
helped me to understand it better than the RFCs or vendor docs. They blog post
might be based on someone's real life experiences which means they open your
eyes to issues you wouldn’t have foreseen until deploying in production, so
there can be great lessons to learn from blog posts.
Interact with communities like UKNOF, NetLdn, NetMcr, LONAP meetings, LINX
meetings, RIPE meetings (either by attending the events, or watching the
presentations online, or joining the mailing lists, I’ve had some truly
enlightening exchanges with people on the c-nsp and j-nsp mailing lists over
the years).
> I feel operational you can fix problems but when it comes to designs and you
> need to build a full hld/lld it’s a whole different world.
If you need to produce a HLD and then LLD, then the HLD is where I would try to
identify all of my customer’s requirements / my business requirements. Try to
gather as much detail for the requirements as possible, the more detailed
requirements you gather, the fewer options you have for meeting the
requirements, which I find makes things easier. Then you can provide a high
level design in the HLD which meets the requirements, without going into the
nitty gritty of how it’s implemented. Once that is agreed upon, the LLD really
just becomes the implementation details. If possible in your scenario, get both
documents peer reviewed as early and as often as you can, don’t wait until
you’re 95% done because, your own mistakes are always the hardest to spot.
> Commercial variance of designs? For an example how did you all learn how to
> approach these in designs?
The same as the technical side of things; by getting repeated input and
validation from my vendor/supplier of their prices, by getting repeated input
from my customer if these options are viable for them, and from anyone else
with an interesting in the cost of the project (such as sales and finance).
People are rarely pissed off because you gave them a chance to check something
which affects them, before going ahead and doing it :)
I will stop there because, this is turning into an essay. I hope some of my
ramblings are helpful somehow.
Cheers,
James.
--- End Message ---
