| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 502.1 | | LEVERS::ANIL | | Mon Mar 16 1992 20:54 | 9 |
| DECconcentrator v3.1 sends traps to the community 'public'
(ie, this is the community name in the Trap PDU). I haven't set
up a trap sink on MCC but assuming that it allows you to enter
the expected community name in this process, it should be set up to
accept 'public'. Alternatively you could set up the DEFCN to
send traps to whatever community MCC likes. (look at the eauth
group in DEC-ELAN-MIB to see how)
Anil
|
| 502.2 | PUBLIC is being used | CSC32::WOESTEMEYER | Why??...Why not!!! | Tue Mar 17 1992 07:50 | 6 |
| I have been using the default community name, which according to the
release notes is 'public'. As I stated in .0 it does no seem that the
concentrator is even processing traps, the snmpintrap and snmpouttrap
counters being 0.
Any more ideas??
|
| 502.3 | Traps and Out of Band Management | MUSSEL::C_MCDONALD | | Tue Mar 17 1992 09:25 | 15 |
| Steve,
Did you say you had set up your hostIPAddress in the concentrator trap
table? Its possible that if there are no 'trap addresses' or hostIPAddresses
to notify in the event of a trap that our code will not bump the counters as
well.
Secondly, with the Out of Band management set the baud rate to 2400.
Then I believe either 7 or 8 bits with no parity should allow you to use it.
You can set hostIPAddresses for the trap table through Out of Band Management.
Give it a try and let me know what happens.
Charlie
|
| 502.4 | Still no success | CSC32::WOESTEMEYER | Why??...Why not!!! | Wed Mar 18 1992 10:50 | 423 |
| Well,
I seem to be able to get traps from a tranlan bridge, but not a
concentrator. Attached is a log from MCC which shows success for
the translan but not the concentrator.
Open to any further ideas/suggestions.
Steve
------------------------------------------------------------------
display
! Default Entity =
! Default Qualifier =
! Prompt = MCC>
! Indentation = 42
!
! Symbol Name Symbol Value
! ----------- ------------
! BR : bridge
! CN : concentrator
! N4 : node4
! SH : show
! ST : station
! TS : terminal_server
!
!No notify requests are currently in progress
!Command procedure verification is OFF
!Logging is ON, Logging file is snmp_trap.log
!
!>> set concentrator IP address
!
set concentrator nsu_con_1 ip address 16.63.16.187
!
!CONCENTRATOR KEROON_NS:.nsu_con_1
!AT 18-MAR-1992 06:03:46 Characteristics
!
!Modification completed successfully.
! IP Address = 16.63.16.187
!
!>> add concentrator trap address
!
add concentrator nsu_con_1 trap address 16.63.16.27
!
!CONCENTRATOR KEROON_NS:.nsu_con_1
!AT 18-MAR-1992 06:04:13 Characteristics
!
!The address was successfully added to the Trap Table.
!
!>> verify ip and trap addresses set
!
show concentrator nsu_con_1 all char
!
!CONCENTRATOR KEROON_NS:.nsu_con_1
!AT 18-MAR-1992 06:04:29 Characteristics
!
!Examination of attributes shows:
! Hardware Type = DEFCN DECconcentrator 500
! Firmware Version = V0.0.0
! ID = %X08002B168DD1
! Reset Defaults Switch = True
! IP Address = 16.63.16.187
! Trap Address Table = { 16.63.16.27 }
! Update Switch = False
! Software Version = "V3.1 "
!
!>> verify SNMP to nsu-con-1
!
show snmp nsu-con-1 snmp all char
!
!SNMP nsu-con-1 snmp
!AT 18-MAR-1992 06:04:55 Characteristics
!
!Examination of attributes shows:
! snmpEnableAuthenTraps = disabled
!
! > Enable authentification Traps
!
set snmp nsu-con-1 snmp snmpEnableAuthenTraps enabled, by pass 08002b168dd1
!
!SNMP nsu-con-1 snmp
!AT 18-MAR-1992 06:05:47 Characteristics
!
!Examination of Attributes Shows
! snmpEnableAuthenTraps = enabled
!
!>> Show SNMP counters for nsu-con-1
!>> note snmpOutTraps = 0
!
show snmp nsu-con-1 snmp all count
!
!SNMP nsu-con-1 snmp
!AT 18-MAR-1992 06:06:18 Counters
!
!Examination of attributes shows:
! snmpOutTraps = 0
! snmpOutGetResponses = 6
! snmpOutSetRequests = 0
! snmpOutGetNexts = 0
! snmpOutGetRequests = 0
! snmpOutGenErrs = 0
! snmpOutBadValues = 0
! snmpOutNoSuchNames = 0
! snmpOutTooBigs = 0
! snmpInTraps = 0
! snmpInGetResponses = 0
! snmpInSetRequests = 1
! snmpInGetNexts = 0
! snmpInGetRequests = 5
! snmpInTotalSetVars = 1
! snmpInTotalReqVars = 25
! snmpInGenErrs = 0
! snmpInReadOnlys = 0
! snmpInBadValues = 0
! snmpInNoSuchNames = 0
! snmpInTooBigs = 0
! snmpInASNParseErrs = 0
! snmpInBadCommunityUses = 0
! snmpInBadCommunityNames = 0
! snmpInBadVersions = 0
! snmpOutPkts = 7
! snmpInPkts = 8
! CounterCreationTime = 17-MAR-1992 15:08:52.05
!
!>> use SNMP to nsu-con-1 to verify communities
!>> note eauthTrapcommunity translates to 'public'
!
show snmp nsu-con-1 dec eauth1 all char, by pass 08002b168dd1
!
!SNMP nsu-con-1 dec eauth1
!AT 18-MAR-1992 06:07:34 Characteristics
!
!Examination of attributes shows:
! eauthTrapCommunity = %X7075626C6963
! eauthReadOnlyCommunity = %X7075626C6963
! eauthReadWriteCommunity = %X303830303262313638646431
!
!
!>> verify via SNMP that the trap address is set.
!
show snmp nsu-con-1 dec eauth1 EAUTHTRAPUSERTABLE * all char, by pass 08002b168dd1
!
!SNMP nsu-con-1 dec eauth1 eauthTrapUserTable 16.63.16.27
!AT 18-MAR-1992 06:10:00 Characteristics
!
!Examination of attributes shows:
! eauthTrapUserStatus = other
!
show snmp nsu-con-1 dec eauth1 EAUTHTRAPUSERTABLE * all iden, by pass 08002b168dd1
!
!SNMP nsu-con-1 dec eauth1 eauthTrapUserTable 16.63.16.27
!AT 18-MAR-1992 06:10:16 Identifiers
!
!Examination of attributes shows:
! eauthTrapUserAddr = 16.63.16.27
!
!
!>> show alrams rules for traps to 2 devices, nsu-con-1 and TL350-1
!>> note alarms enabled in an IMPM session
!
show mcc 0 alarms rule nsu-con-1_auth_file all char, in domain snmp
!
!MCC 0 ALARMS RULE nsu-con-1_auth_file
!AT 18-MAR-1992 06:31:41 Characteristics
!
!Examination of attributes shows:
! Procedure = SYS$COMMON:[MCC]MCC_ALARMS_MAIL_ALARM.
! COM;5
! Exception Handler = SYS$COMMON:[MCC]MCC_ALARMS_MAIL_EXCEPT
! ION.COM;1
! Description = " Authentification failure on
! NSU-CON-1 "
! Category = "NSU-CON-1 SNMP Auth Fail"
! Queue = "sys$batch"
! Parameter = "keroon::woestemeyer"
! Expression = (OCCURS (SNMP NSU-CON-1
! authenticationfailure))
! Perceived Severity = Warning
! Event Type = QualityofServiceAlarm
! Probable Cause = Unknown
!
!
show mcc 0 alarms rule tl350-1_devspec, in domain snmp
!Using default ALL IDENTIFIERS
!
!MCC 0 ALARMS RULE tl350-1_devspec
!AT 18-MAR-1992 06:32:24 Identifiers
!
!Examination of attributes shows:
! NAME = tl350-1_devspec
!
show mcc 0 alarms rule tl350-1_devspec all char, in domain snmp
!
!MCC 0 ALARMS RULE tl350-1_devspec
!AT 18-MAR-1992 06:32:33 Characteristics
!
!Examination of attributes shows:
! Procedure = SYS$COMMON:[MCC]MCC_ALARMS_MAIL_ALARM.
! COM;5
! Exception Handler = SYS$COMMON:[MCC]MCC_ALARMS_MAIL_EXCEPT
! ION.COM;1
! Description = "A DEVICE SPECIFIC trap has occured
! on TL350-1"
! Category = "TL350-1 entity specific trap"
! Queue = "sys$batch"
! Parameter = "keroon::woestemeyer"
! Expression = (OCCURS (SNMP TL350-1
! enterprisespecific))
! Perceived Severity = Minor
! Event Type = QualityofServiceAlarm
! Probable Cause = Unknown
!
!
!>> verify snmpEnableAuthenTraps enabled on nsu-con-1
!
show snmp nsu-con-1 snmp all char
!
!SNMP nsu-con-1 snmp
!AT 18-MAR-1992 06:33:56 Characteristics
!
!Examination of attributes shows:
! snmpEnableAuthenTraps = enabled
!
!>> verify sinks up and running
!
show mcc 0 tcpip_am sink all char
!
!MCC 0 TCPIP_AM SINK
!AT 18-MAR-1992 06:34:40 Characteristics
!
!Examination of attributes shows:
! Component Version = T1.2.4
! Component Identification = "MCC TCPIP/SNMP AM EVENT SINK"
! Sink Start Retries = 10
! Sink Start Wait Timer = 2
!
!>> note no traps received at this time
!
show mcc 0 tcpip_am sink all count
!
!MCC 0 TCPIP_AM SINK
!AT 18-MAR-1992 06:34:48 Counters
!
!Examination of attributes shows:
! Current Clients = 5
! coldStart Traps Received = 0
! warmStart Traps Received = 0
! linkDown Traps Received = 0
! linkUp Traps Received = 0
! authenticationFailure Traps Received = 0
! egpNeighborLoss Traps Received = 0
! enterpriseSpecific Traps Received = 0
! Total Traps Received = 0
! Counter Creation Time = 17-MAR-1992 10:18:18.26
!
show mcc 0 tcpip_am sink all status
!
!MCC 0 TCPIP_AM SINK
!AT 18-MAR-1992 06:34:58 Status
!
!Examination of attributes shows:
! Sink State = Running
! Time when Sink Started = 17-MAR-1992 10:18:18.26
! Time of Last Event = "not applicable"
! Type of Last Event = not applicable
!
!>> device specific trap generated on a translan bridge, TL350_1
!>> see alarm above
!>> Note sink counters and status indicate trap of expected type fired
!>> and was recieved, IMPM icon did change for TL350-1
!
show mcc 0 tcpip_am sink all count
!
!MCC 0 TCPIP_AM SINK
!AT 18-MAR-1992 06:39:09 Counters
!
!Examination of attributes shows:
! Current Clients = 5
! coldStart Traps Received = 0
! warmStart Traps Received = 0
! linkDown Traps Received = 0
! linkUp Traps Received = 0
! authenticationFailure Traps Received = 0
! egpNeighborLoss Traps Received = 0
! enterpriseSpecific Traps Received = 1
! Total Traps Received = 1
! Counter Creation Time = 17-MAR-1992 10:18:18.26
!
show mcc 0 tcpip_am sink all status
!
!MCC 0 TCPIP_AM SINK
!AT 18-MAR-1992 06:39:32 Status
!
!Examination of attributes shows:
! Sink State = Running
! Time when Sink Started = 17-MAR-1992 10:18:18.26
! Time of Last Event = 18-MAR-1992 06:37:55.80
! Type of Last Event = enterpriseSpecific
!
!
!>> Show SNMP counters on nsu-con-1, verify snmpOutTraps still "0"
!
show snmp nsu-con-1 snmp all count
!
!SNMP nsu-con-1 snmp
!AT 18-MAR-1992 06:40:52 Counters
!
!Examination of attributes shows:
! snmpOutTraps = 0
! snmpOutGetResponses = 33
! snmpOutSetRequests = 0
! snmpOutGetNexts = 0
! snmpOutGetRequests = 0
! snmpOutGenErrs = 0
! snmpOutBadValues = 0
! snmpOutNoSuchNames = 0
! snmpOutTooBigs = 0
! snmpInTraps = 0
! snmpInGetResponses = 0
! snmpInSetRequests = 1
! snmpInGetNexts = 4
! snmpInGetRequests = 28
! snmpInTotalSetVars = 1
! snmpInTotalReqVars = 116
! snmpInGenErrs = 0
! snmpInReadOnlys = 0
! snmpInBadValues = 0
! snmpInNoSuchNames = 0
! snmpInTooBigs = 0
! snmpInASNParseErrs = 0
! snmpInBadCommunityUses = 0
! snmpInBadCommunityNames = 0
! snmpInBadVersions = 0
! snmpOutPkts = 34
! snmpInPkts = 35
! CounterCreationTime = 17-MAR-1992 15:08:52.31
!
!>> try to cause authentification trap to fire by using wrong community
!>> name when trying to disable snmpEnableAuthenTraps, a set command.
!
set snmp nsu-con-1 snmp snmpEnableAuthenTraps disable, by pass 1234
!
!SNMP nsu-con-1 snmp
!AT 18-MAR-1992 07:00:17 Characteristics
!
!No response from entity.
!
!>> show sink status, last trap reveived as still for the previous device
!>> specific trap for TL350-1
!
show mcc 0 tcpip_am sink all status
!
!MCC 0 TCPIP_AM SINK
!AT 18-MAR-1992 07:08:44 Status
!
!Examination of attributes shows:
! Sink State = Running
! Time when Sink Started = 17-MAR-1992 10:18:18.26
! Time of Last Event = 18-MAR-1992 06:37:55.80
! Type of Last Event = enterpriseSpecific
!
!>> SNMP counter on nsu-con-1, snmpOutTraps, are still "0"
!>> no trap generated
!
show snmp nsu-con-1 snmp all count
!
!SNMP nsu-con-1 snmp
!AT 18-MAR-1992 07:12:48 Counters
!
!Examination of attributes shows:
! snmpOutTraps = 0
! snmpOutGetResponses = 51
! snmpOutSetRequests = 0
! snmpOutGetNexts = 0
! snmpOutGetRequests = 0
! snmpOutGenErrs = 0
! snmpOutBadValues = 0
! snmpOutNoSuchNames = 0
! snmpOutTooBigs = 0
! snmpInTraps = 0
! snmpInGetResponses = 0
! snmpInSetRequests = 1
! snmpInGetNexts = 4
! snmpInGetRequests = 46
! snmpInTotalSetVars = 1
! snmpInTotalReqVars = 165
! snmpInGenErrs = 0
! snmpInReadOnlys = 0
! snmpInBadValues = 0
! snmpInNoSuchNames = 0
! snmpInTooBigs = 0
! snmpInASNParseErrs = 0
! snmpInBadCommunityUses = 0
! snmpInBadCommunityNames = 6
! snmpInBadVersions = 0
! snmpOutPkts = 52
! snmpInPkts = 59
! CounterCreationTime = 17-MAR-1992 15:08:52.82
!
!>> try to disable snmpEnableAuthenTraps using default community name
!>> should give access to device for read, but note set
!
set snmp nsu-con-1 snmp snmpEnableAuthenTraps disable
!
!SNMP nsu-con-1 snmp
!AT 18-MAR-1992 07:27:55 Characteristics
!
!No response from entity.
!
!>> Again failed to produce trap event
!
show mcc 0 tcpip_am sink all status
!
!MCC 0 TCPIP_AM SINK
!AT 18-MAR-1992 07:33:26 Status
!
!Examination of attributes shows:
! Sink State = Running
! Time when Sink Started = 17-MAR-1992 10:18:18.26
! Time of Last Event = 18-MAR-1992 06:37:55.80
! Type of Last Event = enterpriseSpecific
!
exit
!
|
| 502.5 | Will check out in the lab here | MUSSEL::C_MCDONALD | | Wed Mar 18 1992 14:08 | 6 |
| Steve,
We'll try to verify that traps are being sourced in the lab here.
Charlie
|
| 502.6 | Lab results | QUIVER::P_SHORT | | Fri Mar 20 1992 17:23 | 53 |
|
Steve,
I have tried to duplicate your problem in the lab. I have done the following
and found that the concentrator does send out traps.
1. Set IP ADDRESS of my concentrator with ELMS
2. Set TRAP ADDRESS with ELMS to be our MCC station address
3. Used MCC SNMP AM to set snmpEnableAuthenTraps to enabled
4. Set community (password) in MCC to be ethernet address of my concentrator
5. Powered down and back up
+ Expect traps to be sent to the MCC station
6. Used MCC SNMP AM to read counters
- snmpouttraps = 2
+ Expected 2: 1 for cold start and 1 for link-up
7. Used MCC SNMP AM to change eauthReadWriteCommunity to a "new" value
8. Used MCC SNMP AM to show eauth1
- got No response from entity
+ This was expected since the eauthReadWriteCommunity in the concentrator
and that set in MCC no longer match. Traps should be sent, counters
bumped.
9. Set community (password) in MCC to be the "new" value
+ The MCC and concentrator's community match now, so I can read the counters
10. Used MCC SNMP AM to read counters
- snmpouttraps = 5 (original 2 from power-up, 1 from try, 2 retries)
snmpInBadCommunityName = 3 (1 try, 2 retries)
11. Set community (password) in MCC back to original value
+ This is now back to the mismatched value so expect that we cannot
access the concentrator.
12. Used MCC SNMP AM to read counters
- got No response from entity
+ This was the expected response; traps should be sent, counters bumped.
13. Used MCC SNMP AM to set snmpEnableAuthenTraps to be disabled.
- got No response from entity
+ This was the expected response; traps should be sent, counters bumped.
14. Set community (password) in MCC to be the "new" value again
+ The MCC and concentrator's community match now, so I can read the counters
15. Used MCC SNMP AM to read counters
- snmpouttraps = 11 (3 more for each access with the mismatched values)
- snmpInBadcommunityName = 9 "
We also looked out on the sniffer and saw the traps going out.
Now, the only thing I haven't tried is to use the ELMS AM to do the top
2 steps.
Any chance that you could do the power off/on and check to see that those
traps were sent? Be sure that you don't have the nvram reset to defaults
switch set when you do this. Also, be sure that your ip and trap address
are set and that authentication traps are enabled.
Pam
|
| 502.7 | NVRAM reset switch was enabled | CSC32::WOESTEMEYER | Why??...Why not!!! | Mon Mar 23 1992 13:47 | 11 |
| To all that responded thanks. I finally got this to work in our lab.
It seems that if the NVRAM reset switch is enabled and the TRAP address
is added then TRAPS are not sent. If the trap address is entered when
then the NVRAM reset switch is disabled, then traps are sent.
This raises the question of how sending traps and the NVRAM reset
switch are tied together. I would expect that has long and the
concentrator characteristies show an IP address and TRAP address, then
traps should be sent reguardless of the NVRAM reset switch position.
|
| 502.8 | Don't reset NVRAM if you don't mean it. | QUIVER::HARVELL | | Tue Mar 24 1992 12:52 | 10 |
| Nvram reset switch means reset the NVRAM back to its original shipping
state. Since all settable features are stored in NVRAM, when you reset
NVRAM you reset all those parameters back to defaults. Therefore IP
address, Trap address and of course EnableAuthenticationTraps switch
are set to their default values, which is not set.
If you don't want these and other values removed don't set the NVRAM
reset defaults switch to the enabled position.
Scott
|
| 502.9 | to NVRAM or not | CSC32::WOESTEMEYER | Why??...Why not!!! | Tue Mar 24 1992 15:40 | 28 |
| Scott,
Either I stated the problem incorrectly, or you misunderstood. I do
know the purpose of the NVRAM reset switch. In this case the NVRAM
reset switch is enabled, ELMS has been used to set the ip address and
trap address, and the SNMP access module used to enable
authentification traps.
Now the NVRAM reset switch is still enabled, ELMS can be used to
verify the IP and trap adresses, and SNMP AM to see that
authentification trap are enabled. If we generate an authentification
trap at this time, NVRAM reset switch still enabled, the concentrator
does not send it. Nor does the SNMPoutTrap counter increment.
If at this time we disable the NVRAM reset switch, reboot the bridge,
now we can still see that the ip address, trap address and
authentification traps are still in place. Now if we generate an
authentification trap the management station does receive it.
The question being, why even though the ip address, trap address and
authentification trap are enable/set will the concentrator not send
them until the concentrator is rebooted with the nvram reset switch
disabled. Its almost like the elms 'add trap address ....' does not
really take, if the nvram reset switch is enabled.
Just food for thought,
Steve
|
| 502.10 | | QUIVER::HARVELL | | Wed Mar 25 1992 09:44 | 7 |
| Steve,
You are correct, I did not understand your previous message. If what
you say is correct then there is a problem. Its being looked into by
the appropriate person.
Scott
|
| 502.11 | Question on how to get a DC500 to generate a link up/down trap | NSTG::RDAVIES | If God had meant us to be single, we would have been born that way | Sun Jun 05 1994 20:09 | 72 |
| I've just read through this note, and I still can't find the answer to the
original question (or at least the part of it that I'm interested in)
The Problem:
------------
I want my DECconcentrator500s to generate traps to DECmcc when links fail.
I don't care about authentication traps.
I have DECmcc on Ultrix with no ELMS, just SNMP. I have loaded the FDDI MIB and
the DEC_ELAN V2.7 MIB (even though the V2.7 MIB has never been officially
registered - the V2.0 MIB is the only registered version of the MIB, which
is what ships with DECmcc)
I have a terminal server connection to the OBM port, through which I can
configure the DC500 if I need to.
I have configured the correct TRAP addresses in the concentrator, and I can
power it up and down as many times as I like, and it keeps it's TRAP addresses,
so I don't think the NVRAM switch is a problem here.
I can talk to the concentrator using DECmcc/SNMP with no problem at all, using
the FDDI MIB, MIB-II and the DEC_ELAN MIB.
I have tried disconnecting the primary ring A/B ports AND various M-port
connections, and each time I can still reach the concentrator through SNMP, yet
it doesn't generate any TRAPs (the node running DECmcc is connected to an
M-port, through the default IP gateway configured into the concentrator)
DECmcc can receive traps from other devices with no problems. I have never seen
the snmpoutTraps variable on the concentrator increment, so I'm assuming that
the reason I've never received a trap is because it has never sent one!
EsysRomVersion returns the value 10 - how does this relate to the firmware
version of the concentrator?? The concentrators were purchased in late 1993, so
have whatever version of firmware that was shipping at that point (ie. whatever
version '10' means)
I found this really useful-sounding SNMP variable in the V2.7 DEC_ELAN MIB
> esysFddiPortTrapSwitch OBJECT-TYPE
> SYNTAX INTEGER {
> true(1),
> false(2)
> }
> ACCESS read-write
> STATUS mandatory
> DESCRIPTION
> "This is a switch to enable or diable FDDI port up and port
> down traps. When set to true, the concentrator will
> send a trap when one of its ports comes up or goes down."
> ::= { esysConcConfig 2 }
which sounds EXACTLY like what I need to set, however it returns 'attribute not
gettable'. There is no way to set anything like this from the OBM port, only the
TRAP addresses, and I've set those correctly. What would this value default to,
assuming it's in the firmware I have in the concentrators ?
I would very much appreciate any suggestions as to how I can get my
concentrators to generate traps whenever any of the links go up or down.
Also, if anyone has a complete list of the traps that a DECconcentrator 500 can
generate, that would be EXTREMELY useful.
Thanks
Rob Davies
NSTG / MCI-NASDAQ Project Team
|