[112432] in North American Network Operators' Group
RE: Problem With E1
daemon@ATHENA.MIT.EDU (Howard C. Berkowitz)
Thu Feb 26 07:36:46 2009
From: "Howard C. Berkowitz" <hcb@netcases.net>
To: <nanog@nanog.org>
Date: Thu, 26 Feb 2009 07:36:31 -0500
In-Reply-To: <be2a1c900902260104r52587f83g1d7c54223cec2734@mail.gmail.com>
Errors-To: nanog-bounces@nanog.org
> -----Original Message-----
> From: Shivlu Jain [mailto:shivlu.jain@gmail.com]
> Sent: Thursday, February 26, 2009 4:05 AM
> To: nanog@nanog.org
> Subject: Problem With E1
>
> Since morning I am facing a issue in which one of E1 is configured under
> OSPF. OSPF neighborship is up but not able to send and receive the data.
> The
> configuration is plain vanila. Why it is happening so; I donot know?
>
> --
> Thanks & Regards
> shivlu jain
> http://shivlu.blogspot.com/
> 09312010137
If this is an operational circuit, this is a good example of why it can
extremely useful to document the working configuration of a resource, so you
can compare the malfunctioning configuration. The document may well be
stored as a file, and the comparison could be made with diff or a similar
utility.
Don't forget SNMP and NetFlow, both on the router, but also SNMP on the
access device, modem, multiplexer, etc.
When that circuit first came up, I probably would have captured the
information from the router's equivalent of the Cisco commands:
* show interface
* show ip interface
* show ip ospf interface
* show ip ospf neigbors
Possibly show ip ospf database and show ip ospf database neighbors; perhaps
save the routing table when storing those displays.
Even more displays could be useful, such as subinterfaces.
Electrical tests, such as verifying the signal clocking and amplitude, are
usually last resorts -- although do verify that no one has moved the cabling
among router/CSU ports, and that everything has power.
