| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1101.1 | for note 1083 | WARABI::CHIUANDREW | | Fri Jun 10 1994 05:09 | 3 |
| Sorry this should be in 1083.
Andrew
|
| 1101.2 | Port traps and link traps. | NACAD::GALLAGHER | | Fri Jun 10 1994 11:54 | 19 |
| > It works after I set ip address for DR900TM, but it did not give any
> traps when port is disabled/enabled.
How did you enable/disable ports? What traps did you expect to see?
(The reason I ask is that I'm wondering if you expect to see linkUp and
linkDown traps when you enable/disable repeater ports. Repeater ports
are not "links" or "interfaces", they are "ports". Therefore you should
not see linkUp or linkDown traps when you enable/disable ports.
"Port" traps are supported on the DECcnocentrator thru enterprise specific
traps. We hope to provide "port" traps using RMON Alarms and Events on
future versions of the DECrepeater products.)
Where can we find the traps sent from our HUB900 modules?
The next reply will contain a list of traps supported on current products.
-Shawn
|
| 1101.3 | Traps supported. | NACAD::GALLAGHER | | Fri Jun 10 1994 11:56 | 72 |
| The following table shows which generic (aka "standard") traps are
supported by which DEChub900 MAX modules by the April-94 release:
+-----------------+--------+--------+-------+-------+-------+
| | Bridge | Concen | Rprtr | Srvr | Mgmt |
| Trap Type | 900MX | 900MX | 900TM | 900TM | Agent |
+-----------------+--------+--------+-------+-------+-------|
| ColdStart | x | x | x | x | x |
| WarmStart | | x | | | |
| LinkUp | | x | | x | x |
| LinkDown | | x | | x | x |
| AuthenFailure | x | x | x | x | x |
| EGPNeighbor | | | | | |
+-----------------+--------+--------+-------+-------+-------+
This table shows what traps will be supported by the wave 3 release:
+-----------------+--------+--------+-------+-------+-------+
| | Bridge | Concen | Rprtr | Srvr | Mgmt |
| Trap Type | 900MX | 900MX | 900TM | 900TM | Agent |
+-----------------+--------+--------+-------+-------+-------|
| ColdStart | x | x | x | x | x |
| WarmStart | | x | | | |
| LinkUp | x | x | x | x | x |
| LinkDown | x | x | x | x | x |
| AuthenFailure | x | x | x | x | x |
| EGPNeighbor | | | | | |
+-----------------+--------+--------+-------+-------+-------+
In addition to the generic traps shown above:
- The DECrepeater900TM (and the "next wave" repeaters) support
the following repeater MIB traps:
o rptrResetEvent - sent when the repeater's state machine
is reset, and
o rptrHealthTrap - sent when the value of rptrOperStatus
changes, or upon completion of a non-disruptive test.
(RFC1516 provides further detail about these traps.)
- The DECconcentrator900MX supports an "Enterprise Specific" port
trap. "Enterprise Specific" traps are non-standard traps.
The port trap conveys information about the change of an FDDI
port's state. For example, a "disconnecting" port causes a
port trap to be sent. Another trap is sent when the port is
"connecting".
The port traps is disabled by default. It may be enabled by
setting the esysFddiPortTrapSwitch. The release notes for the
DECconcentrator900MX provide additional detail.
Also of note:
- Most products don't have the capability of warm-starting.
When reset they re-initialize completely. WarmStart traps
need only be supported if warm-start capability is supported.
- None of the products listed are routers which support the
Exterior Gateway Protocol (EGP). Therefore, none of the
products support the EGP Neighbor Loss trap.
-Shawn
|
| 1101.4 | | TKTVFS::NEMOTO | no facts, only interpretations | Fri Jul 15 1994 12:34 | 20 |
| >This table shows what traps will be supported by the wave 3 release:
>
> +-----------------+--------+--------+-------+-------+-------+
> | | Bridge | Concen | Rprtr | Srvr | Mgmt |
> | Trap Type | 900MX | 900MX | 900TM | 900TM | Agent |
> +-----------------+--------+--------+-------+-------+-------|
> | ColdStart | x | x | x | x | x |
> | WarmStart | | x | | | |
> | LinkUp | x | x | x | x | x |
> | LinkDown | x | x | x | x | x |
> | AuthenFailure | x | x | x | x | x |
> | EGPNeighbor | | | | | |
> +-----------------+--------+--------+-------+-------+-------+
What do the LinkUp and LinkDown mean, except for the server case?
Ref: For the server case, it means a creation and disconnection of a SLIP/PPP
session on a (server) port accroding to the TS notes file.
_Tak
|
| 1101.5 | defined in RFC 1157 | LEVERS::WILSON | | Fri Jul 15 1994 15:57 | 23 |
|
>>What do the LinkUp and LinkDown mean, except for the server case?
>>Ref: For the server case, it means a creation and disconnection of a SLIP/PPP
>> session on a (server) port accroding to the TS notes file.
First of all, the traps listed in the table (coldStart, warmStart, linkUp,
linkDown, authenticationFailure, EGPNeighborLoss) are defined in the
RFC 1157 (RFC = Request For Comments). These have been defined as generic
traps by this mib and the SNMP community.
linkDown = "A linkDown(2) trap signifies that the sending protocol
entity is recognizes a failure in one of the communication links represented
in the agent's configuration."
linkUp = "A linkUp(3) trap signifies that the sending protocol entity
recognizes that one of the communication links represented in the agent's
configuration has come up."
Therefore, the meaning should be the same no matter what type of SNMP
agent you are talking about (Repeater, Hub, Terminal server, etc..)
Karen
|
| 1101.6 | | TKTVFS::NEMOTO | no facts, only interpretations | Tue Jul 26 1994 07:20 | 8 |
|
Can anyone from Concentrator900 engineering let me know what linkUp
and linkDown actually means in its agent implementation?? What is
your definition of "link" in FDDI environment?
I just need this imformation asap.
_Tak
|
| 1101.7 | DECconcentrator traps. | NACAD::GALLAGHER | | Tue Jul 26 1994 10:44 | 31 |
|
LinkUp and LinkDown aren't very useful in the DECconcentrator.
The concentrator has two links when it's standalone: the MAC and
the SLIP port. "Links" are *always* associated with MACs. If the
MAC is affected, traps are sent out the SLIP port. (If the SLIP port
could be affected, traps would be sent out the MAC.)
LinkUp traps are sent out the MAC:
- after initializing,
- when an IP address is assigned to the concentrator's SLIP port, and
- when a new IP address is assigned to the SLIP port.
LinkDown traps are sent out the MAC when the SLIP port's IP address is
deleted.
People often expect LinkUp and LinkDown traps to be sent when a concentrator
port is affected. This isn't done because of the distinction between a
'link' and a 'port'. To address this concern the concentrator implements
"enterprise specific port traps".
Port traps must be explicitly enabled by setting esysFddiPortTrapSwitch to
true(1). Once enabled, port traps are sent whenever "xPORTConnectState"
changes. "xPORTConnectState" changes as port connections are created and
destroyed (per the SMT spec). Refer to the fddi mib for details about
xPORTConnectState. Port traps are enterprise specific 1 traps (generic-
trap-type = 5, specific-trap-type = 1). Details about which port was
affected, and the new connect state are carried in the "interesting
information" field of the trap message. I believe the concentrator's
release notes describe the details.
-Shawn
|
| 1101.8 | | TKTVFS::NEMOTO | no facts, only interpretations | Tue Jul 26 1994 11:57 | 29 |
| Thanks Shawn!
>LinkUp and LinkDown aren't very useful in the DECconcentrator.
>The concentrator has two links when it's standalone: the MAC and
>the SLIP port. "Links" are *always* associated with MACs. If the
>MAC is affected, traps are sent out the SLIP port. (If the SLIP port
>could be affected, traps would be sent out the MAC.)
>
>LinkUp traps are sent out the MAC:
>
> - after initializing,
> - when an IP address is assigned to the concentrator's SLIP port, and
> - when a new IP address is assigned to the SLIP port.
>
>LinkDown traps are sent out the MAC when the SLIP port's IP address is
>deleted.
I see.
Then linkUp traps are out only after initializing when it's in a HUB?
I've already looked at esysFddiPortTrapSwitch, so I know the port trap.
What I didn't was the real meanings of generic trap types of the HUB modules
since it depends on how agent implements them (if my understaning is correct).
Do you have a complete list of 900's generic trap types(eg, you show above)?
If you don't, could you go on to MAM linkUp/Down meanings? That's not urgent
need but one of "need to know".
_Tak
|
| 1101.9 | See note 860.5 for description DEChub900 traps. | LEVERS::SKABO | Expect Nothing: You'll never be disappointed | Tue Jul 26 1994 14:25 | 8 |
| reply -.1
>>> Do you have a complete list of 900's generic trap types(eg, you show above)?
See note 860.5 for a brief description of DEChub900 traps.
Regards,
Tom
|
| 1101.10 | MAM Traps. | NACAD::GALLAGHER | | Tue Jul 26 1994 15:05 | 53 |
| Hi Takashi,
>Then linkUp traps are out only after initializing when it's in a HUB?
Yep. (And as you surmise, there's no linkDown trap when installed in
a hub because there's no other link in which to send the trap.)
>If you don't, could you go on to MAM linkUp/Down meanings? That's not urgent
>need but one of "need to know".
The MAM currently has up to two interfaces: the SLIP interface (aka
"OBM channel") and the IP services interface. (There's talk of having more
than one IP server, but that's just talk right now.)
If only the SLIP interface has been assigned an IP address then linkUp
traps are sent out the SLIP interface after initialization. No linkDown
traps are sent.
If only the IP services interface has been assigned an IP address then
linkUp traps are sent out the IP services interface after initialization.
Again, no linkDown traps are sent.
If both the SLIP and IP services interfaces have been assigned IP addresses
then traps get kinda weird. Lets assume the SLIP interface is assigned
IP address 1.1.1.1 and the IP services interface is assigned 2.2.2.2.
After initialization, two linkUp traps are sent out each interface,
as follows:
Interface Trap Type IP Source Address IP Addr in the Trap Msg
---------- ---------- ------------------ -----------------------
1) SLIP LinkUp 1.1.1.1 1.1.1.1
2) SLIP LinkUp 1.1.1.1 2.2.2.2
3) IP Srvs LinkUp 2.2.2.2 1.1.1.1
4) IP Srvs LinkUp 2.2.2.2 2.2.2.2
"IP Source Address" refers to the source address field of the IP header.
"IP Addr in the Trap Msg" refers to the IP address field of the SNMP Message.
(When I say that traps are sent, I mean that they're attempted to be sent.
After initialization the ARP cache is empty so the MAM has to ARP for the
trap-sink. The trap is sent only if the sink responds to the ARP.)
If the SLIP and IPS interfaces are connected to a routed network, then the
trap-sink (receiver) gets all four traps.
LinkUp traps are also sent whenever an IP address is assigned.
LinkDown traps are sent whenever one of the IP addresses is changed or
deleted. LinkDown traps are also sent when the IP server module is removed
or reset.
-Shawn
|
| 1101.11 | rptrOperStatus? | TKTVFS::NEMOTO | no facts, only interpretations | Fri Aug 12 1994 06:08 | 48 |
|
> o rptrHealthTrap - sent when the value of rptrOperStatus
> changes, or upon completion of a non-disruptive test.
>
> (RFC1516 provides further detail about these traps.)
rptrOperStatus has 4 failure types as shown below. What do they actually
mean in Repeater900? Any clues from Repeater900 engineering?
Thank you,
_Tak
! rptrOperStatus OBJECT-TYPE
!
! SYNTAX INTEGER {
! other(1), -- undefined or unknown status
! ok(2), -- no known failures
! rptrFailure(3), -- repeater-related failure
! groupFailure(4), -- group-related failure
! portFailure(5), -- port-related failure
! generalFailure(6) -- failure, unspecified type
! }
! ACCESS read-only
! STATUS mandatory
! DESCRIPTION
! "The rptrOperStatus object indicates the
! operational state of the repeater. The
! rptrHealthText object may be consulted for more
! specific information about the state of the
! repeater's health.
!
! In the case of multiple kinds of failures (e.g.,
! repeater failure and port failure), the value of
! this attribute shall reflect the highest priority
! failure in the following order, listed highest
! priority first:
!
! rptrFailure(3)
! groupFailure(4)
! portFailure(5)
! generalFailure(6)."
! REFERENCE
! "Reference IEEE 802.3 Rptr Mgt, 19.2.3.2,
! aRepeaterHealthState."
! ::= { rptrRptrInfo 2 }
!
|
| 1101.12 | ok and generalFailure only | LEVERS::PAGLIARO | Rich Pagliaro, Hub Products Group | Fri Aug 12 1994 09:21 | 15 |
| The short answer to your question is that the current DECrepeater 900
implementations (DECrepeater 900TM/900GM/900FP/90FS/90TS) will only
ever report rptrOperStatus as ok(2) or generalFailure(6). In the
current implementations, a repeater will report a generalFailure(6) if
there is some non-fatal environmental fault condition, such as a fan
failure or over temperature conditions. A fatal fault condition causes
the module to reset and run diagnostics. The repeater reports ok(2)
otherwise.
Regards,
Rich
|
| 1101.13 | non-disruptive test? | TKTVFS::NEMOTO | no facts, only interpretations | Fri Aug 12 1994 11:16 | 14 |
|
Re: .-1
Thanks a lot.
> o rptrHealthTrap - sent when the value of rptrOperStatus
> changes, or upon completion of a non-disruptive test.
^^^^^^^^^^^^^^^^^^^^^
I read "non-disruptive test" as "self-test upon a power up or reset by
a mamagemet command".
Correct? (I hope I didn't jump..)
_Tak
|
| 1101.14 | Power-up resets are very disruptive | LEVERS::PAGLIARO | Rich Pagliaro, Hub Products Group | Fri Aug 12 1994 12:26 | 51 |
| >> I read "non-disruptive test" as "self-test upon a power up or reset by
>> a mamagemet command"
>>
>> Correct?
Diagnostics performed after a power-cyle or management reset are quite
disruptive. The power cycle or management reset causes network
connectivity to be interrupted and the module is not manageable during
these times.
For a description of non-disruptive test, reference the
rptrNonDisruptTest object defined in RFC 1516.
rptrNonDisruptTest OBJECT-TYPE
SYNTAX INTEGER {
noSelfTest(1),
selfTest(2)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Setting this object to selfTest(2) causes the
repeater to perform a agent-specific, non-
disruptive self-test that has the following
characteristics: a) The nature of the tests is
not specified. b) The test does not change the
state of the repeater or management information
about the repeater. c) The test does not inject
packets onto any segment. d) The test does not
prevent the relay of any packets. e) The test
does not interfere with management functions.
After performing this test, the agent will update
the repeater health information (including
rptrOperStatus and rptrHealthText) and send a
rptrHealth trap.
** Note that this definition allows returning an
** 'okay' result after doing a trivial test.
Setting this object to noSelfTest(1) has no
effect. The agent will always return the value
noSelfTest(1) when this object is read."
The DECrepeaters perform only a very trivial non-disruptive test when this
object is set to selfTest(2). The fact that the repeater responds at
all indicates that the repeater is "OK".
-Rich
|