[112442] in North American Network Operators' Group
RE: Problem With E1
daemon@ATHENA.MIT.EDU (Durrani, Mo)
Thu Feb 26 11:03:27 2009
Date: Thu, 26 Feb 2009 10:03:13 -0600
In-Reply-To: <278488ECD81E6A42A7289E84524D2A257EE92E42@EVS20.ams.gblxint.com>
From: "Durrani, Mo" <mo.durrani@tdstelecom.com>
To: "Graham, Darel" <Darel.Graham@Globalcrossing.com>, <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
If the router is cisco , you also wanna check the code and see if there
are any known bugs on the code track. We had a simmiliar issu with an
IOS and BGP.=20
=20
But , I do agree with Darel , as well.=20
Mo Durrani
>TDS Telecom
>IP Network Engineering
>608-664-5698
mo.durrani@tdstelecom.com
-----Original Message-----
From: Graham, Darel [mailto:Darel.Graham@Globalcrossing.com]=20
Sent: Thursday, February 26, 2009 6:51 AM
To: nanog@nanog.org
Subject: RE: Problem With E1
Using an external CSU? Power cycle it.=20
Using Frame Relay? Have provider check card in Frame switch, if the port
reads 65535 the buffers are full. Have the provider reset the card
(shared memory cards are bad).=20
Without configuration info or other supporting info it will be difficult
to tell what the underlying issues are with OSPF/Ckt. Thanks Howard for
the push in the right direction.
DR Graham
-----Original Message-----
From: Howard C. Berkowitz [mailto:hcb@netcases.net]=20
Sent: Thursday, February 26, 2009 7:37 AM
To: nanog@nanog.org
Subject: RE: Problem With E1
> -----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
>=20
> Since morning I am facing a issue in which one of E1 is configured=20
> under OSPF. OSPF neighborship is up but not able to send and receive=20
> the data. The configuration is plain vanila. Why it is happening so; I
> donot know?
>=20
> --
> 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.=20
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.=20
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.
