Hi Howard,
I'm not suggesting that one should write a book on network management.
Instead, it seems that most network routing books don't spend anytime
reviewing some of the key MIB objects relevant to the routing protocol
that should be considered when configuring the relevant NM tools.
It does seem naive thinking that one could "design it right in the first
place" and then not have to worry about network operations as if it's
not needed. Maybe this is possible, if the gear being deployed never
has a
hardware failure, the OS never fails, your fiber never gets dug up, and
device misconfigurations never happen. If you are seeing gear which
never fails, a carrier which never loses fiber, and operations folks who
never
make mistakes, let me know what vendors I should be switching too or
entity I should be hiring from... :-)
In a post yesterday, you mentioned CALEA and E911. Good, lets think
about primary line VOIP and OSPF as your IGP. Lets assume that
customer
downtime for VOIP is a bad thing and something the operator is tryng to
avoid. Thus, it's crucial for the NM folks to be able to detect problems
before
pagers start buzzing and before the call center gets whacked....
Given this, how can NM tools determine that all links which should have
OSPF adjacencies active in fact do? I've seen situations where this
sort of
problem doesn't get realized until there's a failure in one part of the
network. The backup path with the adjcancey problem, but which wasn't
needed used during normal operation, then causes an outage. There are
OIDs in the OSPF MIB or syslog messages which one can use to help
determine
when an adjacency is improperly down, but this information is not
covered in
the standard network book. Sure, knowing "debug ip ospf XYZ" commands
is a
start, and useful for newbies, but there's more to support than running
debug
commands, and there's always the risk that you've just blown up the
router you
turned debug on....
And as you mention, there are things that would be useful to know
through the MIB, but which aren't currently supported. Doesn't mean
they're not
worth talkng about. One item that I ran into was related to the use of
"auto-cost reference bandwidth" to change the metric used to cost out
links. It's important that all devices use the same reference bandwidth
in
order for costs to be properly computed. How does one verify all
devices,
across vendors, are using the same reference bandwidth? Turns out that
this
one is not possible via the OSPF MIB as it stands today as the reference
bandwidth is not an object in the MIB, but is just a *comment* in the
MIB
definition.
Much like NRF mentioned which lead me to spin this new thread-- as NM
tools get more sophisticated, there will be less need for the CCNX
support
engineer who carries a pager to figure out problems in the middle of the
night.
Instead more and more of the opertional support work will be done up
front as
part of the design engineering and this will include the OIDs and
thresholds
the NM folks and tools should be monitoring.
"Howard C. Berkowitz" wrote:
>
> At 4:31 PM ?? 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=60236&t=60220
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
