At 4:31 PM +0000 1/3/03, bergenpeak wrote: >NRF makes a very good point below about OSS systems. Pulling this >off from the original thread to take the discussion in a differnent >direction. > >As we probably all would agree, the largest cost in running a >network is not the engineering cost or the capital costs, but >rather the cost of operating the network (NOC, call center, >tier 1-(N-1) support, etc.) > >In the world I live in, the engineering group, when introducing >new gear, design, service, or architecture, is reponsible to also >provide the OIDs to monitor, how often to poll, what each OID means, >what are key thresholds, and what it means (or one should do) when >an OID value passes one of these thresholds. The NM folks than update >their tools (OSSs) and processes based on this information.
This brings up interesting issues of basic software architecture. From all I know, IOS is not built on an OID structure. Nortel, in many of its products -- certainly the derivatives of Bay RS -- used the OID structure as its fundamental internal data structuring. Not all products -- Passport isn't just spaghettti code--it needs angel hair pasta to get even more twisty. > >The engineering involved in this portion of the design can either make >or break the cost effectiveness of a design. Another aspect is that there is constant confusion among station, layer, and system management. People with a proper understanding of layer management rarely struggle with where ARP fits. Frankly, this is extremely valuable to understanding the context even for basic certifications. > >So two points: > >1) It would seem that any CCIE-type training/testing should include NM >information into the material to be learned. From what I can tell, it >does >not. I'm not suggesting that one would need to memorize every OID >in every MIB, but it would seem important to know key OIDs in each >functional area and what useful information they provide. A question: how much OO experience does someone need to enter the OID space? I kind of grew up with it (well, more OSI management), so it's hard for me to judge what it's like for a newbie. Conceptually, it's very different than teaching configuration and troubleshooting, so I would be really interested in good ways to introduce it to non-programmers. > >2) For the folks on this list that write books in this space, it would >seem very appropriate if NM topics where covered as well. Take a >book which talks about the many different routing protocols. All of >them >explain how the protocol operates, the format of messages, and and how >to configure and debug a router running the protocol. There's >only so many ways one can explain OSPF type 1-4,5 and 7 LSAs and >stub/TSA/NSSAs. One way to differentiate the contents of a book would >be to include key OIDs one should consider putting in their NM systems >to make sure OSPF/IS-IS/BGP/etc. is operating as expected (or not). Having done some design in that area, first, we don't necessarily have OIDs defined for the information always needed. Second, we don't have halfway user-friendly pattern recognizers to deal with these issues. There are conceptual things that don't get mentioned, yet are amazingly simplifying once you understand that. We go on and on about the various LSA types and where they are permitted, but I've found relatively few people that can explain why intra-area is preferable to inter-area, inter-area to external, and why both external type 1 and 2 are there. In a third aspect, I'd rather design it right in the first place than be stuck in infinite troubleshooting purgatory. The night of BGP turned into a bright dawn when I started first defining routing policies in RPSL, and then configuring from the policy definition. There are even tools that automate some of this, such as RtConfig. (see www.radb.net) To be fair about it, RPSL isn't very user-friendly to people without substantial programming experience, especially at an abstract level. A graphic, object-oriented front end, with extensions to IGPs and defining NM points, would be tremendously helpful. > >My $0.02. > > > > > >nrf wrote: >> >> Yet at the same time we have the opposite phenomena - guys who can >configure >> routers in a Sunday minute, but can't even spell RFC. What I'm talking >> about is guys who might know what all the commands are, but have no >> grounding in routing protocol theory or any such higher concepts. All they >> know is - they see this problem, they type in this command. Such guys are >> useful if you need to troubleshoot your network at 3 in the morning, not so >> useful if you want to do something that isn't in a textbook. And besides, >I >> hate to say it, but these guys are destined to be replaced by a good OSS. Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=60220&t=60220 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
