All I managed to get done tonight was to put the initial configs on the routers and switches, and read the entire scenario through. If I had to guess, I’d say this lab was written by someone at NMC different from whoever wrote the first two. The lab’s focus is quite different; in my opinion, it’s more thought-provoking and challenging. This lab has more “core” issues – more meat – than the first two. So I’m pretty excited. This is the sort of challenge I like, and the kind of thing that I anticipate the actual lab might feature.
There’s lots of tweaking within OSPF to make the database appear a certain way, and routes appear a certain way. Lots of mutual redistribution. Lots of complexity in how the routing tables are supposed to look when you’re done configuring the 3 IGPs and BGP. Router X is supposed to prefer Router Y to get to subnet Z – that sort of thing. There’s no way I could sit down and crank out the scenario just blindly following one step at a time. I’m going to have to have a plan of attack first, or the whole thing is going to spiral out of control.
So my intention is to write down after each requirement how I’m going to accomplish it. In this part I’ll use a distribute list. To meet this requirement, I’ll redistribute with this access-list. I’ll use a route-map to set administrative distance in this part. I’ll have to disable split-horizon on this interface. And so on. I think the hard part is really getting the strategy down to meet what seems like a really long list of requirements. Once I know WHAT I’m going to do, writing the code and testing should be a whole lot easier, and less confusing if things go awry.
Getting through all of that will be a big accomplishment. Getting through the rest of the scenario requires less planning, although I can already tell you that I don’t know how to do everything that’s being asked. There’s a big QoS section focused on the 3560 that I’m not 100% on…probably not even 50% on. I can probably get part of the way down the road. I’ve spent so much time with class-based weighted fair queueing that I haven’t paid enough attention to the other QoS techniques that have their place in the world. So if CBWFQ isn’t the right answer to a given QoS problem, my knowledge thins out.
There’s a bizarre security section, where what they are asking me to do to secure a particular interface doesn’t even make sense. I’m sure I’m overlooking something, so I’ll get back to it in a few days and look again. The IPv6 section looks straightforward enough, except that I have not done IPv6 BGP before, which is called for in this scenario. So that’ll be new. There’s a DHCP server config called for…and they threw in a requirement to support Microsoft clients of hybrid NetBIOS node type. “Hybrid node” – man, THAT takes me back a long ways, back to when I was an MCSE. I’m pretty sure all that means is that they want a WINS server served up in the DHCP options, and I’m pretty sure there’s a flag I have to set to tell the Windows DHCP client that he’s a hybrid-node type.
There’s a funky section on setting up local logging to a file stored in flash. That I’m not sure of, since pretty much anywhere I’ve ever worked, I’ve set up logging to a remote syslog server. I can see how logging to flash might be nice in a pinch, but nothing I’d really want to do considering how valuable flash real estate is. Although I guess that’s why they also want me to limit the size of the log file. :-) If it’s do-able, that’s a task I can probably hack my way through with my friend the question-mark.
The multicast part of the config doesn’t look too bad – it’s a dense-mode config, although with that last nasty requirement of “make sure you get a ping back from everybody”. I haven’t looked at it in detail to see how the tree will flood/prune, but I have a feeling I’ll be reviewing PIM dense-mode forwarding logic to resolve some router or another that doesn’t seem to be a part of the multicast tree.
So, more to come tomorrow and Friday, with scenario completion on Saturday. (Here’s hopin’, anyway…)