CMTS config / CMTS output
interface Cable3/0
cable enable-trap cmonoff-notification
cable enable-trap cmonoff-interval 60
snmp-server trap-source Loopback0
snmp-server enable traps cable cm-onoff
snmp-server host x.x.x.x public-cmts
snmp-server host x.x.x.x public-cmts
But I saw that I have a problem with mac addresses .
With debug of snmp packets I recive this
Dec 19 14:41:23.327: SNMP: V1 Trap, ent ciscoDocsExtMIB.2, addr x.x.x.x, gentrap 6, spectrap 1
docsIfCmtsCmStatusEntry.2.4475717 = H{&65 <<<<------- Here should be MAC ??
docsIfCmtsCmStatusEntry.3.4475717 = 10.5.5.87
docsIfCmtsCmStatusEntry.4.4475717 = 0
docsIfCmtsCmStatusEntry.5.4475717 = 8113
cdxCmCpeEntry.5.6.200.251.38.182.53.157 = 2885
cdxCmtsCmStatusExtEntry.1.4475717 = 1
Dec 19 14:41:23.339: SNMP: Queuing packet to x.x.x.x
Dec 19 14:41:23.339: SNMP: V1 Trap, ent ciscoDocsExtMIB.2, addr x.x.x.x, gentrap 6, spectrap 1
docsIfCmtsCmStatusEntry.2.4475717 = H{&65
docsIfCmtsCmStatusEntry.3.4475717 = 10.5.5.87
docsIfCmtsCmStatusEntry.4.4475717 = 0
docsIfCmtsCmStatusEntry.5.4475717 = 8113
cdxCmCpeEntry.5.6.200.251.38.182.53.157 = 2885
cdxCmtsCmStatusExtEntry.1.4475717 = 1
Dec 19 14:41:23.379: SNMP: Packet sent via UDP to x.x.x.x
Dec 19 14:41:23.379: SNMP: Queuing packet to x.x.x.x
Like this one
#scm 10.5.5.87
D
MAC Address IP Address I/F MAC Prim RxPwr Timing Num I
State Sid (dBmv) Offset CPE P
c8fb.26b6.359d 10.5.5.87 C5/1/3/U0 online(pt) 2885!-2.00 823 0 N
Otherwise, normally it should be like this
Dec 19 14:42:36.836: SNMP: V1 Trap, ent ciscoDocsExtMIB.2, addr x.x.x.x, gentrap 6, spectrap 1
docsIfCmtsCmStatusEntry.2.4478568 = C8 FB 26 F8 D6 28 <<<<------- This MAC is ok
docsIfCmtsCmStatusEntry.3.4478568 = 10.5.26.57
docsIfCmtsCmStatusEntry.4.4478568 = 0
docsIfCmtsCmStatusEntry.5.4478568 = 0
cdxCmCpeEntry.5.6.200.251.38.248.214.40 = 5736
cdxCmtsCmStatusExtEntry.1.4478568 = 12
Dec 19 14:42:36.848: SNMP: Queuing packet to x.x.x.x
Looks to me that the debugs are simply printing the values in ASCII or EBCDIC instead of hex:
Mac = c8fb.26b6.359d.
c8= È in ASCII - H in EBCDIC
fb= û in ASCII and EBCDIC
26= & in ASCII
b6= ¶ in ASCII - Þ in EBCDIC
35= 5 in ASCII
9d= (blank space) in ASCII
I believe the IOS will not print special characters (or may replace them for some other characters).
The values above are pretty close to what is seen in the debug.
Also i done snmp walk and there is some ok MAC addresses and some not
SNMPv2-SMI::transmission.127.1.3.3.1.2.1641193 = Hex-STRING: 24 76 7D 99 49 F3
SNMPv2-SMI::transmission.127.1.3.3.1.2.1641199 = Hex-STRING: 10 5F 49 36 1E C1
SNMPv2-SMI::transmission.127.1.3.3.1.2.1641201 = STRING: "$v}J{R"
SNMPv2-SMI::transmission.127.1.3.3.1.2.1641243 = Hex-STRING: C8 FB 26 B5 D6 41
As you can see third in a row.
Why some are written as Hex-STRING: and some as STRING: ??
Anyone with same issue ? Some idea to fix this ?
Second and more important issue :
i also done next :
Resets number of modems and follow after off / on trap messages. Configured that CMTS is sending messages to server and my computer. Basically we had the same number of messages that are coming to my comuter and server. We went to the CMTS and there connected computer directly to the CMTS to force sending messages to that PC . We had again identical (although in this case arrived almost all the messages).
What is missing are the messages when the modem goes offline (which are more importantly)
For messages when modem comes online, we recive 99% of messages.
We observed is that for example in the first 10 modems when we reset the modem , CMTS send traps only for three modems (not consecutive). After the tenth modem , CMTS send all messages (for test we usually reset 20-30 modems). There is not any connection about the type of modem that sends the trap.
Suspicion fell on PRE card but the tests were tried on various PRE cards (2 CMTS with pre2, 2 with PRE4, and one with pre5). IOS were different from the SCF3 - SCH1.
maybe is there is a limitation with this setup?, and of course if you have any other solution that will give us info on whether modems go off / online ?
For mac address your snmp utility tries interpretation of the value:
it says "STRING" and not "Hex-STRING" in the walk command.
I am sure you can avoid this behavior with options : check man.
You can also add mibs to have the correct interpretation.
For CMTS that is not sending every traps you may change trap buffer value in your configuration (I don't remember how)
If you type "show snmp" you should see dropped traps counter not equal 0. By default they put a very small trap buffer and CMTS drops traps if too many have to be sent at the same time.
when your snmp utility is grabbing the value, it reads the first octet, if it is in visible ascii range 21-7f hex, it treats the whole string as an ascii string, otherwise it treats it as a binary string and shows hex representation of it. The best way to solve the issue is to load the mib associated with that OID, it has a textual convention that knows how to display the mac address. If that doesn't work, there is always a command line switch to show the value in the format you want.
Regarding missing traps, maybe try ramping up the "snmp-server queue-length x"
Hi ,
Done . it is solved with that command . Thanks.
Anyway , does anyone implemented this commands ?
cable event throttle-adminStatus
cable event throttle-interval
cable event throttle-threshold
How much influence will they have , and it is safe to put on ubr10k ?
BR