Cristiano,
from my point of view linkflap can be used for
- generating syslog messages or traps in case of a link failure
- keeping a port down for a defined timegap after a spurious fink failure.
One way for solving this could be in enabling auto negotiation on this link (if
the attached devices will allow this!).
If you can discover the failing situation by a script, you can disable and
re-enable the port by snmp:
switch(rw)->show port status fe.1.3
Alias Oper Admin Speed
Port (truncated) Status Status (bps) Duplex Type
--------- ------------ ------- ------- --------- ------- ------------
fe.1.3 Down Up N/A N/A BaseT RJ45
snmpset -v1 -c <rw-community> -t 5 -r 3 anz-164-16a ifAdminStatus.3 i 2
interfaces.ifTable.ifEntry.ifAdminStatus.3 = down(2)
switch(rw)->show port status fe.1.3
Alias Oper Admin Speed
Port (truncated) Status Status (bps) Duplex Type
--------- ------------ ------- ------- --------- ------- ------------
fe.1.3 Down Down N/A N/A BaseT RJ45
snmpset -v1 -c <rw-community> -t 5 -r 3 anz-164-16a ifAdminStatus.3 i 1
interfaces.ifTable.ifEntry.ifAdminStatus.3 = up(1)
switch(rw)->show port status fe.1.3
Alias Oper Admin Speed
Port (truncated) Status Status (bps) Duplex Type
--------- ------------ ------- ------- --------- ------- ------------
fe.1.3 Down Up N/A N/A BaseT RJ45
Kind regards,
Reinhard
Cristiano Rodrigues schrieb:
Does anyone have experience with the Linkflap function?
We currently have a problem that is difficult to identify source. There is a optical
wireless link between a C2 Stack and an E1. The Link often fails due to atmospheric
factors, and the end-to-end link goes unusable even after the link gets back up. By our
experience, the link at first drops a few packets (doing a "PING -T x.x.x.x")
then goes completely unusable, dropping every packet. The logging buffer doesn't record
anything useful regarding the specific port. The firmware installed is 03.07.29.0000 on
the E1 and 05.01.03.0003 on the C2.
Until now, the only way we have devised to get the link back up is by doing a manual reset to the
link, either disconnecting the cable physically and plugging it back in or doing a "set port
disable ge.x.x" and "set port enable ge.x.x".
If the Linkflap could solve the problem I would be off the hook. Anyone has experience on these
kind of issues? Another option is maybe having a script executing the port disable/enable on its
own. Does anyone know how to run commands on a switch automatically, or through
"unmanned" telnet sessions? Any kind of software that could accept scripts and run them
in a telnet session automatically in case the links goes "flapping" again...
Thanks everyone!
Cristiano Rodrigues
Técnico
Direcção de Estudos e Planeamento
[EMAIL PROTECTED]
-
Rua do Repouso, n10, 8000-302 Faro
T: +351 289 899 070
F: +351 289 899 079
W: http://www.aguasdoalgarve.pt
--------------------------------------------------------------------
* Antes de imprimir este e-mail pense bem se tem mesmo de o fazer. *
* Before printing this e-mail, assess if it is really needed. *
--------------------------------------------------------------------
---
To unsubscribe from enterasys, send email to [EMAIL PROTECTED] with the body:
unsubscribe enterasys [EMAIL PROTECTED]
--
Dipl.-Ing. Reinhard Strebler, Rechenzentrum der Universitaet Karlsruhe
Leiter der Abteilung Netze und Kommunikation
Zirkel 2, D-76128 Karlsruhe
Tel.: +49 721 608-2068 Fax.: +49 721 32550
http://www.uni-karlsruhe.de
mailto:[EMAIL PROTECTED]
---
To unsubscribe from enterasys, send email to [EMAIL PROTECTED] with the body:
unsubscribe enterasys [EMAIL PROTECTED]
