Cisco Prime Fulfillment ユーザ ガイド 6.1
MPLS VPN のトラブルシューティング
MPLS VPN のトラブルシューティング
発行日;2012/05/08 | 英語版ドキュメント(2011/11/16 版) | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 18MB) | フィードバック

目次

MPLS VPN のトラブルシューティング

一般的トラブルシューティングのガイドライン

開発エンジニアリング用のログ収集

よくある質問

MPLS VPN のトラブルシューティング

この章では、MPLS VPN のトラブルシューティングに関する情報を示します。

一般的トラブルシューティングのガイドライン

プロビジョニング失敗の一般的トラブルシューティングには、次のステップを実行します。


ステップ 1 失敗したサービス要求を特定して [Details] に入ります。

a. 実行には、[Service Request Editor] に進み、[Details] をクリックします。

重要なのは、発生したことを正確に表示するステータス メッセージです。

b. ステータス メッセージに監査の失敗と表示される場合は、[Audit] ボタンをクリックして監査の正確にどの部分が失敗したのかを見つけます。

ステップ 2 トラブルシューティング シーケンスのステップ 1 によって発生したことを明確に把握できない場合は、Task Manager のログを使用して問題を特定します。

a. 実行には、[Monitoring] > [Task Manager] > [Logs] > [Task Name] を選択します。

b. このログには多くの情報があります。問題を切り分けるには、フィルタを使用できます。ログ レベルまたはコンポーネント、あるいはその両方でフィルタリングすると、通常は無関係な情報の量を減らして、問題を特定するために認識する必要がある情報に集中できます。

ステップ 3 よくある質問と問題に関する情報については、この付録の「よくある質問」の項も参照してください。


 

開発エンジニアリング用のログ収集

「一般的トラブルシューティングのガイドライン」に記載されたトラブルシューティングのステップに従って進みます。問題のトラブルシューティングまたは特定に失敗した場合のために、この項では開発エンジニアがトラブルシューティングするためにログを収集する方法について説明します。


ヒント ログは MPLS VPN およびレイヤ 2 VPN の両方に適用します。

DCPL には、 Provisioning.Service.mpls.saveDebugData と呼ばれるプロパティがあります。このプロパティが True に設定されている場合、サービス要求を展開するたびに、一時ディレクトリが PRIMEF_HOME/tmp/mpls に作成されます。

ディレクトリには、プレフィクスであるサービス要求のジョブ ID がタイム スタンプとともに含まれています。このディレクトリには、アップロードしたコンフィギュレーション ファイル、XML 形式のサービス パラメータ、ならびにプロビジョニングおよび監査の結果が含まれています。

デフォルトでは True に設定されています。

確認するには、次のステップを実行します。


ステップ 1 [Administration] > [Control Center] を選択してこのプロパティを見つけます。

[Control Center Hosts] ページが表示されます。

ステップ 2 目的のホストのチェックボックスをオンにします。

[Hosts] ページのメニューボタンがイネーブルになります。

ステップ 3 [Config] をクリックします。

[Host Configuration] ウィンドウが表示されます。

ステップ 4 [Provisioning] > [mpls] に移動します。

ステップ 5 [saveDebugData] をクリックします。


 

よくある質問

MPLS VPN プロビジョニングに関する FAQ のリストを次に示します。

MPLS プロビジョニング ワークフローとは何ですか。

次に一覧表示されたタスクは、MPLS プロビジョニング ワークフローを示しています。この項では、オペレータが Task Manager などの呼び出し元を使用してサービス要求を展開することを想定しています。

1. Provisioning Driver(ProvDrv)は、サービス要求を展開します。

2. Provisioning Driver は、関与するデバイスをサービス要求から推定します。

3. 最新のルータ コンフィギュレーションを取得する必要があるため、Provisioning Driver は、Generic Transport Library(GTL)/Device Configuration Service(DCS)に最新のルータ コンフィギュレーションをアップロードするように求めます。この結果はサービス モジュールによって使用されます。

4. Provisioning Driver は、サービスおよびデバイス タイプに基づいていずれのサービスモジュールが関与しているかを判別します。

5. Provisioning Driver は、サービス目的をリポジトリに問い合わせます。Provisioning Driver は、サービス目的をアップロードされたコンフィギュレーションとともにサービス モジュールに送信します。

6. サービス モジュールは、コンフィギュレーションおよびサービス目的に基づいてコンフィグレットを生成し、適切なコンフィグレットを Provisioning Driver に返します。

7. Provisioning Driver は、コンフィグレットをターゲット ルータにダウンロードするように GTL/DCS に合図します。

8. Provisioning Driver は、ダウンロード結果を含む更新結果をリポジトリに送信します。その後リポジトリは、その状態を更新します。

前のステップで使用した用語の定義。

Device Configuration Service(DCS) :コンフィギュレーション ファイルのアップロードおよびダウンロードを担当します。

Generic Transport Library(GTL) :ターゲット デバイスにコンフィグレットをダウンロード、ターゲット デバイスからコンフィギュレーション ファイルをアップロード、ターゲット デバイスでのコマンド実行、およびターゲット デバイスをリロードするための API を提供します。

このライブラリは、トランスポート プロバイダー(DCS)と Provisioning Driver、Auditor、Collect Config 動作、Exec コマンドなどのクライアント アプリケーション間にレイヤを提供します。GTL の主な役割は、リポジトリおよび プロパティ ファイルからターゲット固有の情報を収集して、情報をトランスポート プロバイダー(DCS)に渡すことです。

Provisioning Driver(ProvDrv) :ProvDrv は、複数のデバイスで 1 つ以上のサービスを展開するタスクを担当します。

ProvDrv は、すべてのサービスに共通のタスクを実行します。共通のタスクとは、デバイスからのコンフィギュレーション ファイルのジャストインタイム アップロード、Data Driven Provisioning(DDP)エンジンの呼び出し、DDP エンジンからの生成したコンフィグレットまたは監査レポートの取得、およびデバイスへのコンフィグレットのダウンロードなどです。

リポジトリ :リポジトリは、各種 IP Solution Center データを格納します。Prime Fulfillment リポジトリは、Sybase または Oracle を使用します。

サービス モジュール :サービス タイプに基づいてコンフィグレットを生成します。

タスクがすぐに展開されるようにスケジュールを設定したにもかかわらずタスクが実行されない場合は、どうすればいいですか。

この問題は、Prime Fulfillment サーバの 1 台が停止したかディセーブルになっていることが原因の可能性が高いです。

すべての Prime Fulfillment サーバのステータスを確認するには、次のステップを実行します。


ステップ 1 [Administration] > [Control Center] に進み [Host Configuration] ダイアログを開きます。

[Control Center Hosts] ページが表示されます。

ステップ 2 目的のホストのチェックボックスをオンにします。

[Hosts] ページのメニューボタンがイネーブルになります。

ステップ 3 [Servers] を選択します。

[Server Status] ページが表示されます(図 34-1 を参照)。

図 34-1 Prime Fulfillment [Server Status]

 

ステップ 4 Prime Fulfillment サーバで、 wdclient status コマンドを使用してサーバ ステータスの詳細を確認します。


 

サービス要求が [Wait Deployed] 状態のときはどうすればいいですか。

これは、Cisco Configuration Engine をアクセス方式として使用するように設定されているデバイスが関係しています。デバイスがオフラインであり、コンフィグレットがデバイス用に生成された場合は、サービス要求は [Wait Deployed] 状態に移行します。デバイスがオンラインになるとすぐに、コンフィグレットのリストがダウンロードされて、デバイスのステータスが変更されます。

サービス要求が [Failed Audit] 状態のときはどうすればいいですか。

少なくとも 1 つのコマンドがデバイスに不足しています。次のステップを実行します。


ステップ 1 Prime Fulfillment ユーザ インターフェイスから、[Service Request Editor] > [Audit] > [Audit Config] に進みます。

ステップ 2 コマンドのリストを確認して各デバイスで不足しているコマンドがないか確認します。

ステップ 3 デフォルト値の属性を持つ不足しているコマンドがないか探します。


 

サービス要求が展開前と同じ状態の場合はどうすればいいですか。

サービス要求の状態が展開後も以前の非展開状態([Request]、[Invalid]、または [Pending])のままの場合は、プロビジョニング タスクが正常に完了しなかったことを示しています。「一般的トラブルシューティングのガイドライン」に記載されたステップを実行して、サービス要求失敗の原因を見つけます。

OutOfMemoryError というメモリ不足エラーが表示された場合は、どうすればいいですか。

次のステップを実行します。


ステップ 1 [Administration] > [Control Center] を選択して [Host Configuration] ダイアログを開きます。

[Control Center Hosts] ページが表示されます。

ステップ 2 目的のホストのチェックボックスをオンにします。

[Hosts] ページのメニューボタンがイネーブルになります。

ステップ 3 [Config] をクリックします。

[Host Configuration] ウィンドウが表示されます。

ステップ 4 [watchdog] > [servers] > [worker] > [java] > [flags] に移動します。

ステップ 5 次の属性を変更します。

[Xmx256M] 属性を Xmx384M または Xmx512M に変更します。


 

Prime Fulfillment が VPN のルート ターゲット インポート/エクスポートを削除しない場合は、どうすればいいですか。

シナリオ:MPLS サービス要求が新しい VPN に関連付けられるように編集されたとき、古い VPN は 1 つのインターフェイスだけと関連付けられている場合に限り削除されます。サービス要求とカスタマー間の関係は VPN を介して成立しています。サービス要求のオプションの [Customer] フィールドはコンフィギュレーションと何も関連がありません。たとえば、 custA の MPLS サービス要求が vpnB/cercB を伴って存在するときに、 vpnA/cercA を反映するように変更する必要がある場合、 vpnA/cercA を使用するようにサービス要求を変更しても、同じ VRF に複数のインターフェイスが関連付けられている場合は、 vpnB のルート ターゲットは vrfB から削除されません。

推奨される処理のとおり、同じシナリオを 1 つのインターフェイスだけが vrfB を参照して実行している場合は、Prime Fulfillment によって vrfB が削除されて、ルート ターゲット A vrfA が適切に追加されます。

余分な CE ループバック インターフェイスのプロビジョニングを選択したときに、サービス要求が [Invalid] に移行するのはなぜですか。

IP アドレスの自動選択オプションをサービス要求に対して選択したのに、/32 IP アドレス プールが定義されていない可能性があります。このサービス要求に対して定義した IP アドレスと IP アドレス プールに確実に互換性があることを確認します。

サービス要求を保存するときに、「CERC not initialized」と表示されるのはなぜですか。

リンクの参加する CERC を選択する必要があります。CERC が選択されたかどうかをサービス要求で確認します。

VLAN ID プール作成にアクセス ドメインが必要なのはなぜですか。

VLAN ID プールは、アクセス ドメインに関連付けられています。アクセス ドメインは、ブリッジド ドメインをモデル化します。VLAN ID は、ブリッジド ドメイン全体で一意である必要があります。

PE-POP は、アクセス ドメインと関連付けられている必要があります。アクセス ドメインは、複数の PE-POP と関連付けることができます。

[Paging] テーブルで、1 つのチェックボックスだけがオンであるにもかかわらず、[Edit] および [Delete] オプションがディセーブルなのはなぜですか。

前のウィンドウで 1 つ以上のチェックボックスがオンであった場合は、このようになる可能性があります。

MPLS VPN または L2VPN ポリシーが編集できないのはなぜですか。

サービス要求をポリシーに関連付けた場合、そのポリシーは編集できなくなります。

CERC を作成できません。これはなぜですか。

ルート ターゲットを手動で指定する場合を除き、CERC の作成前にルート ターゲット プールを定義する必要があります。

PE、CE、および PE-CLE デバイス間のコンフィグレット ダウンロードの順序を変更する方法を教えてください。

Provisioning.Services.mpls.DownloadWeights.* と呼ばれるプロパティを使用すると、PE、CE、PE-CLE、および MVRF CE デバイス タイプのダウンロードの順序を指定できます。

たとえば、コンフィグレットが CE にダウンロードされる前に PE に確実にダウンロードされるようにするには、 Provisioning.Services.mpls.DownloadWeights.weightForPE プロパティに CE の重み値を超える重み値を設定します。

Provisioning.Service.mpls.reapplyIpAddress プロパティは何をするものですか。

プロパティが True に設定されている場合、デコミッションされたサービス要求の展開中に、このプロパティは CE への IPv4 接続を維持するために、ルータ上の CE および PE の IP アドレスをそのまま保持します。

少なくとも 1 つの PE-CLE デバイスを介した CE と PE 間のマルチホップ NPC を作成すると余分な NPC が作成されるのはなぜですか。

オペレータが同じ情報を再入力する必要をなくすために、IP Solution Center によって余分な NPC が作成されます。CE は PE-CLE デバイスに接続できるようになります。また、新しい NPC が作成され、これによって新しい CE から PE に PE-CLE-to-PE NPC リンクを介して接続されます。

サービス要求のプロビジョニング中に、[Interface selection] リスト ボックスにデバイス上のインターフェイスのリスト全体が表示されないのはなぜですか。

これは、サービス ポリシーに指定されている特定のインターフェイス タイプが原因の可能性があります。この場合、指定したインターフェイス タイプのインターフェイスだけが表示されます。

サービス要求が「loopback address missing」というメッセージを表示して [Invalid] に移行するのはなぜですか。

これはレイヤ 2 VPN の問題です。

PE 間の擬似回線のピアに必要なループバック アドレスが Prime Fulfillment の PE-POP オブジェクトに定義されていないことが原因です。

MPLS ポリシーの [Allocate New Route Distinguisher] チェックボックスの目的は何ですか。

Prime Fulfillment には動作変更が実装されたため、レガシー製品の「VPNSC」とは異なっています。VPNSC では、VRF は PE 中心でした。このため、新しい VRF が PE ルータ上の各 VPN に設定される動作でした。この動作は、Prime Fulfillment で変更されて VRF は VPN 中心になりました。ほとんどのルーティングでは、VRF/Route Distinguisher(RD; ルート識別子)は、IBGP ロード バランシング実行中を除き、PE のみで重要です。このため、すべての PE ルータ上の単一の VPN で同じ値を使用できます。これにより、トラブルシューティングやレポートの状況にいるユーザにとって利便性が高くなりました。

IBGP ロード バランシングを使用するユーザに対する柔軟性を高めるため、またカスタムのソリューションとニーズに対応するために、Prime Fulfillment には使用可能なオプションが 2 つあります。1 つは [VRF and RD Overwrite] であり、もう 1 つは [Allocate New Route Distinguisher] です。[VRF and RD Overwrite] は、まさにその名のとおりです。これを使用すると、ユーザはプロビジョニング中のリンクに VRF 名および RD 値を強制できます。この機能は、Prime Fulfillment によってプロビジョニングされていない既存の VRF に参加する場合に便利です。


) [VRF and RD Overwrite] 属性のサブ属性(つまり、[VRF Name] および [RD Value] 属性)に値を指定して MPLS サービス要求を保存すると、これら両方のフィールドがディセーブルになって編集できなくなります。[VRF Name] および [RD Value] のデフォルト値を変更すると、現在実行中のサービス要求を変更またはディセーブルにする可能性があるために、この動作は導入されました。したがって、展開済みサービス要求でこれらの値を変更する必要がある場合の回避策は、そのサービス要求をデコミッションおよび削除し、新規サービス要求を作成することです。まだ展開されていない新規サービス要求の場合、サービス要求を強制的に削除してから新規値を使用して新規サービスを作成する必要があります。


2 番めのオプションである [Allocate New Route Distinguisher] は、初めて PE ルータに新しい VRF および RD を設定する場合に限り有効です。これは、PE ルータごとの個別の VRF の VPNSC 動作に類似しています。既存の VPNSC リポジトリが含まれていないときの新しい RD のルールを次に示します。

[Allocate New Route Distinguisher] がイネーブルのときのルールは、次のとおりです。

その PE に一致する VRF コンフィギュレーションがない場合は、新しい VRF を作成します。

その PE に一致する VRF コンフィギュレーションがある場合は再使用します。

[Allocate New Route Distinguisher] がディセーブルのときのルールは、次のとおりです。

PE に関係なく PE の範囲全体から一致する最初の VRF コンフィギュレーションを見つけます。この VRF が設定中の PE で見つかった場合は再使用します。PE で見つからない場合は、VRF を作成します。

注:サービス要求は、別の PE ルータにすでに設定された VRF を取得する可能性があります。

VPNSC で設定された既存の VRF の問題は、VPNSC では [Allocate New Route Distinguisher] フラグが常にオンであったことです。このため、このフラグを再び適用するときは、Prime Fulfillment はまず PE で既存の VRF を検索します。この VRF(この場合は、VPNSC にプロビジョニングされた VRF)を使用します。VRF が見つからない場合は、Prime Fulfillment は新しい VRF を作成します。新しいリンクを古い VPNSC リンクに追加するときに、[Allocate New Route Distinguisher] フラグがオンではない場合は、Prime Fulfillment はネットワーク全体に設定された最初に一致する VRF を見つけます。PE がこの VRF を持たない場合は、Prime Fulfillment はルータに VRF を作成します。

使用例:

1. レガシー(VPNSC)VRF を使用する既存の PE にリンクを追加するときは、[Allocate New Route Distinguisher] オプションを選択する必要があります。

2. 新しい PE にリンクを追加するときに、この VPN にまだ設定されていない VRF/RD 値を使用する場合は、[Allocate New Route Distinguisher] オプションを選択する必要があります。

3. 新しい PE に新しいリンクを追加するときに、ネットワークの別の場所ですでに使用された VRF/RD 値を再使用する場合は、[VRF and RD Overwrite] オプションを選択する必要があります。

4. 間違った VRF/RD 値を持つリンクをプロビジョニングした場合は(つまり、VPNSC によって以前にプロビジョニングされた一致しないもの)、リンクを変更して再展開する必要があります。変更中に、[VRF and RD Overwrite] オプションを選択して、VPNSC で使用されたのと同じ VRF/RD 値を指定する必要があります。

5. IBGP ロード バランシングを複数の PE 全体で展開する場合は、[Allocate New Route Distinguisher] オプションは常にイネーブルである必要があります。これは、ロード バランシング要件を満たすために、一意の RD を使用するという条件を確実に満たすためです。

標準 UNI ポートを使用する MPLS サービス要求に CDP パケットを許可する方法を教えてください。

デフォルトでは、MPLS サービス要求はレイヤ 2 コントロール プレーンの BPDU 処理のアクセスを制限する標準 UNI に MAC ACL を作成します。次のような ACL が作成されます。

interface FastEtherent0/15
mac access-group ISC-$name in
mac access-list extended ISC-$name
 
deny any host 0180.c200.0000 ===> PVST, MSTP, RSTP, and STP
deny any host 0100.0ccc.cccd ===> PVST+
deny any host 0100.0ccc.cccc ===> CDP, VTP, DTP, UDLD, PAgP
deny any host 0100.0ccd.cdd0 ===> CDP,VTP,STP
permit any any
 

) 「===>」の後に表示されているテキストは、MAC ACL の一部ではありません。これは、各 MAC アドレスによってブロックされるプロトコルのリストです。


代わりに、MPLS サービス要求が作成されたときに、リンク属性を編集してから次のステップを実行することもできます。


ステップ 1 [Use Existing ACL Name] をイネーブルにします。

これにより、[Port-Based ACL Name] オプションがイネーブルになっていることを確認します。

ステップ 2 空にする、または存在しない MAC ACL 名を入力します。


 

MPLS サービス要求が展開されたとき、デフォルト BPDU フィルタリング MAC ACL を発行しなくなります。代わりに、 access-group コマンドを空の ACL をポイントする UNI インターフェイスに作成します。例:

interface FastEthernet0/15 mac access-group {$PACL_NAME} in
 

MAC ACL は作成されません。

L3 VPN を作成するときに、2 つまたは 3 つのアドレス プールを使用できますか。

リージョンに割り当てられた IP プール 10.10.10.0/24 をユーザが持っていて、PE がこのリージョンに割り当てられていると想定します。ここで、1 人のカスタマーが自身の LAN 範囲内で同じサブネットを使用すると仮定します。これにより、ユーザは PE-CE リンクに別のサブネットを使用するように強制されます。これを Prime Fulfillment は次のように処理します。自動選択せずに手動で実行するのが唯一の方法です。Prime Fulfillment は、異なるカスタマーに対する異なるアドレス プールの使用をサポートしていません。

その他の関連する問題は次のとおりです。Prime Fulfillment の IP アドレス プールで使用されているのと同じ IP アドレスをカスタマーが LAN セグメント内で使用している場合は、問題が生じます。このため、PE-CE IP アドレスに対して複数のサブネットを持ち、適切なもの(カスタマーが使用する IP アドレスと競合しないもの)を使用する必要があります。IP アドレス プールを作成するとき、リポジトリは範囲を認識しているために、プールの一部として重複する IP アドレスは使用できません。Prime Fulfillment では、同じ PE 内で異なるプールの使用をいっさいサポートしていません。Prime Fulfillment では、複数のプールを作成できますが、プロバイダー リージョンに応じて 1 つのプールだけが使用できます。最初のプールの IP アドレスがなくなった場合は、Prime Fulfillmentは対応する次のプールを選択します。自動選択するプールを選択するための選択メカニズムはありません。手動で追加された IP アドレスは、プールの IP アドレスと重複しない限り使用できます。

サービス要求がデコミッションされた後で、MPLS IP アドレス プールからの IP アドレスは使用可能なプールにいつ戻されますか。

サービス要求がデコミッションされたとき、サービス要求が [DEPLOYED] 状態に移行した後で IP アドレスは使用可能なプールに戻されます。Prime Fulfillment は、戻された IP アドレスが新しいサービス要求によって約 24 時間再使用できないようにします。サービス要求がデコミッションされてから削除されたときも同じ動作が適用されます。

サービス要求がデコミッションされたときに、Prime Fulfillment がルータ BGP/EIGRP コマンドの一部を削除しないのはなぜですか。

Prime Fulfillment は、VRF が削除された場合、かつその場合に限り、ルータ BGP または EIGRP コンフィギュレーションからアドレス ファミリ CLI を削除します。ルータ EIGRP の場合、Prime Fulfillment によって設定された他の CLI が存在する可能性があるため、このプロセスは削除されません。これは、特にネットワーク ステートメントが Prime Fulfillment の外で追加されたときに当てはまります。Prime Fulfillment は、EIGRP を使用する場合に他のルーティング プロトコルからの再配布を削除しません。これは、再配布コマンドがリンク専用で作成されていない可能性があるためです。

Prime Fulfillment は、VRF が削除された場合、ルータ OSPF プロセスだけを削除します。これは、PE にだけ適用されます。CE の場合、ネットワーク ステートメントが削除されたとき、ルータ OSPF が削除されます。Prime Fulfillment は、ルータ BGP もルータ EIGRP も削除しません。

プラットフォームまたは IOS(もしくは IOS XR)バージョンが Q-in-Q(たとえば WS-X6724-SFP)をサポートしていない場合はどうなりますか。

サービス要求は [Failed Deploy] 状態になり、ログ ファイルは次のようになります。

IOS の場合:

SEVERE Provisioning.ProvDrvDownload failed for device NPE-1: 315 : Error downloading cmd=[encapsulation dot1Q 158 second-dot1q 1510], response=[encapsulation dot1Q 158 second-dot1q 1510^
% Invalid input detected at '^' marker.NPE-1(config-subif)#]
 

IOS XR の場合:

SEVERE Provisioning.ProvDrvDownload failed for device NPE-1: 315 : Error downloading cmd=[encapsulation dot1Q 158 1510], response=[encapsulation dot1Q 158 1510^
% Invalid input detected at '^' marker.NPE-1(config-subif)#]
 

サービス要求を編集し、2 番めの VLAN ID をディセーブルにしてから再展開します。

ハードウェア/IOS は Q-in-Q を確かにサポートしているのに、Prime Fulfillment が Q-in-Q をプロビジョニングしないのはなぜですか。

予想されるエラー:

ポートがスイッチポート モードに設定されています。解決策:ポート設定を確認し、必要に応じて、 no switchport を実行します。

SVI フラグがイネーブルです。解決策:SVI をディセーブルにします。

既存のサブインターフェイス(Q-in-Q)および SVI が同じインターフェイス上にあるポートを使用すると [INVALID] になるのはなぜですか。

サブインターフェイスが 1 つだけあるサービス要求を SVI イネーブルに変更すると、サービス要求は [Deployed] 状態に移行します(IOS デバイスの場合)。新しいサービス要求を同じインターフェイス(つまり、既存のサブインターフェイス)で作成して SVI イネーブルにした場合、サービス要求は [Invalid] 状態に移行します。

単一の dot1q および Q-in-Q サービス要求を同じインターフェイス/ポートで展開できますか。

はい。

2 番めの VLAN ID を Q-in-Q で展開されたサービス要求から削除する方法を教えてください。

サービス要求を編集/変更し、2 番めの VLAN ID エントリを削除してから、サービス要求を再展開する必要があります。次のようなコンフィグレットが作成されます。

interface GigabitEthernet2/0/15.158
no encapsulation dot1Q
encapsulation dot1Q 158

ip address 10.1.1.105 255.255.255.252