On Wed, Oct 25, 2023 at 8:39 PM James Bensley via uknof < [email protected]> wrote:
> ------- 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. > Ivan Pepelnjak has been building relevant design resources for years at https://blog.ipspace.net/ conveniently sorted by topic. Anne
