iMCでSMIv2のTrap MIBをインポートできない場合の確認手順

対象と確認の順序

第三者の機器やシステムから送られるTrapをiMCで識別するには、対象のTrap定義が必要です。定義が登録されていない場合は、手動で定義を追加する方法や、Trapを定義したMIBをインポートする方法があります。本手順では、MIBのインポートに失敗するときに、実行環境、通知定義、依存関係、ファイルサイズの順で確認します。

画面例は iMC PLAT 7.3（E0705P12）を含む環境のものです。U-Centerの別コンポーネントも表示されていますが、すべてを同一リリースにそろえるという意味ではありません。別バージョンへの適用や、U-Center全般での同一動作は保証しません。実際に使用する製品・コンポーネントの組み合わせを確認してください。以下は既存の画面・MIB記述の例であり、新たに動作確認した結果ではありません。

MIBの確認方法は、例に示す SMIv2 の通知定義を対象にしています。NOTIFICATION-TYPE が見つからないことだけで、すべての形式のMIBにTrap定義がないとは判断できません。SMIv1など別形式の場合は、提供元に定義方式を確認してください。EPONの名称はMIB記述の例であり、ここで扱うのはiMCのインポート処理です。

MIBを編集する前に、提供された元ファイルを保管してください。不要と思われる定義を削除すると、その通知を解析できなくなったり、ほかの定義の参照先を失ったりするおそれがあります。削除はファイルが大きい場合に検討する限定的な切り分け方法です。必要性と残す通知を確認できない場合は編集せず、サポートへお問い合わせください。

1. コンポーネントの配備状態とプロセスを確認する

デプロイメント監視エージェント（画面名「智能部署监控代理」）を開き、「部署」タブで次を確認します。

• 使用するiMCコンポーネントが、対象リリースの組み合わせとして適切か。
• 必要なコンポーネントの状態が「已部署」（配備済み）になっているか。
• 同じiMC PLATのサブコンポーネントについて、更新前後のバージョンが意図せず混在していないか。

図1：コンポーネント名・バージョン・配備状態を確認する画面

図1の列は、コンポーネント名、説明、バージョン、状態、配備先です。iMC PLATの多くの行は7.3（E0705P12）、状態は「已部署」、配備先は「主服务器」です。ただし、「来宾接入管理」の行はiMC PLAT 7.3（E0705）かつ「未部署」です。この画面を、そのまま全コンポーネントが正常にそろった例とは扱わず、実環境で必要なコンポーネントか、想定するバージョン・状態かを確認してください。

また、同じ画面にはUCenter CIDB 7.3（E0707L06）、UCenter SSA 7.3（E0707L06）、UCenter API 7.3（E0707L06）なども表示されています。製品の異なるコンポーネントを、PLATと文字列が異なるという理由だけで不整合と判断しないでください。

続いて「进程」タブでプロセスの状態を確認します。特に、アラーム機能のバックエンドであるimcfaultdmと、フロントエンドであるjserverが「已经启动」（起動済み）になっていることを確認します。

図2：imcfaultdmとjserverの起動状態

図2には、プロセス、状態、場所、CPU使用率、メモリ、起動時刻、種類、起動方式が表示されています。例では両プロセスの状態が「已经启动」、場所が「本机」、種類が「可管理进程」、起動方式が「自动」です。これらは画面例の値であり、CPU使用率・メモリ量・起動時刻を正常値の基準にはしません。

環境に問題があれば、その状態を確認してからMIB側の調査へ進みます。本手順は、コンポーネントの再配備、アップグレードやプロセス再起動を一律に実行する指示ではありません。

2. 提供されたファイルに通知定義が含まれるか確認する

提供されたMIB一式を確認します。圧縮ファイルに多数のMIBが入っていても、その中に対象のTrap定義が含まれているとは限りません。

図3：MIBファイル一覧の例

図3ではComware MIB-20201013 > H3C New Style Private MIBの中に、hh3c-trap.mibが表示されています。このファイルの表示サイズは24 KB、更新日時は2018/6/29 12:48です。これはファイルを探す例であり、この名称やサイズをすべての機器の必須条件にするものではありません。

通知定義を一つのファイルにまとめる製品もあれば、機能別のMIBに分ける製品もあります。例ではhh3c-epon.mibにEPON関連の通知定義が記述されています。ファイル名だけで判断せず、テキストエディターで内容を確認します。

SMIv2の場合は、NOTIFICATION-TYPEを検索し、次のように通知名に続く通知定義の宣言があるかを確認します。

hh3cEponPortAlarmBerTrap NOTIFICATION-TYPE

図4：NOTIFICATION-TYPEを検索した結果

図4の検索結果には、6590行のhh3cEponPortAlarmBerTrapのほか、hh3cEponPortAlarmFerTrapや、障害の復旧を表す複数の通知定義が表示されています。一方、131行に表示されるNOTIFICATION-TYPEは取り込み宣言の一部です。キーワードの検索ヒットだけでは、その箇所が通知定義とは限りません。 宣言本体と、その通知が目的の機器・機能に対応していることを確認してください。

3. IMPORTSに記載された依存関係を確認する

MIBモジュールの冒頭にあるDEFINITIONS ::= BEGINを確認します。DEFINITIONSの前にある名前が、MIBモジュール名です。ファイル名と同じものとして扱わず、記述されたモジュール名を確認します。

HH3C-EPON-MIB DEFINITIONS ::= BEGIN

図5：モジュール名とIMPORTSの例

例のモジュール名はHH3C-EPON-MIBです。続くIMPORTSには、使用する定義と、その定義を取り込む元のモジュールが記述されています。図5の対応は次のとおりです。

これらの定義を持つMIBファイルが、提供された一式に含まれているかを確認します。名前は大文字・小文字を含めて照合します。例えば、依存先としてif-mibと記述されているのに、提供ファイル内のモジュール名がIF-MIBであれば、ファイル名が似ていても同じモジュール名とはみなせません。

依存するファイルが不足している場合や、記述が一致しない場合は、提供元に必要なファイルと正しい組み合わせを確認してください。依存エラーを消すために、モジュール名を推測で書き換えないでください。

4. 大きなMIBファイルの扱いを検討する

環境と依存関係に問題がないのに失敗し、MIBファイルが数MBある場合は、ファイルサイズも切り分け対象にします。大きなファイルのコンパイル時にバッファーあふれが原因候補となる場合がありますが、Javaの例外が出たという情報だけで、バッファー不足やファイルサイズが原因と断定しないでください。 この手順では、すべてのiMC環境に共通するファイルサイズ上限は示していません。

不要な通知定義を除いた小さいファイルで確認する方法を検討する場合は、元ファイルを残し、作業用コピーを使用します。提供元またはサポートと、削除対象、残す通知、参照関係への影響を確認してください。通知が不要と判断できない場合や、定義の境界が分からない場合は削除せず、手順5へ進みます。

図6：削減を検討する通知定義の範囲の例

図6の枠は、hh3cEponPortAlarmBerTrapという一つの通知定義の範囲です。この通知はBERのしきい値超過イベントを通知するものです。例の定義は次のとおりです。

hh3cEponPortAlarmBerTrap NOTIFICATION-TYPE
    OBJECTS
        {
            ifIndex,
            ifDescr,
            hh3cOltPortAlarmBerDirect,
            hh3cOltPortAlarmBer,
            hh3cOltPortAlarmBerThreshold
        }
    STATUS current
    DESCRIPTION
        "
        A hh3cEponPortAlarmBerTrap notification is sent when
        a BER threshold crossing event is detected.
        "
    ::= { hh3cEponTrapPrefix 1 }

その前には、通知用のOID階層が次のように定義されています。

hh3cEponTrap OBJECT IDENTIFIER ::= { hh3cEponMibObjects 8 }
hh3cEponTrapPrefix OBJECT IDENTIFIER ::= { hh3cEponTrap 0 }

図6は、この通知をどの環境でも削除してよいという意味ではありません。作業用コピーで削減を検討する際にも、必要な通知、OBJECTSの参照先、依存する定義やOID階層を壊さないようにします。削減後は構文・依存関係とインポート結果を確認し、残すべき通知が失われていないことを確認してください。適切な削減範囲を判断できない場合は、編集前のファイルとエラー情報を添えてサポートへお問い合わせください。

5. 解決しない場合

MIBの内容と依存関係を確認しても解決しない場合、または削減が不要・不適切な場合は、次の情報を整理してH3Cテクニカルサポートへお問い合わせください。

• jserverのログ。
• iMCのバージョン情報が分かる画面。

お問い合わせ：h3cts@h3c.com