IP : IP ルーテッド プロトコル

ループ防止のための Null0 インターフェイスへのスタティック ルートの使用

2016 年 10 月 27 日 - 機械翻訳について
その他のバージョン: PDFpdf | ライター翻訳版 (2004 年 10 月 14 日) | 英語版 (2015 年 8 月 22 日) | フィードバック


目次


概要

ヌル インターフェイスは一般に、ルーティング ループを避ける目的で使用されます。 たとえば Enhanced Interior Gateway Routing Protocol(EIGRP)では、ルート グループを集約する際に必ず Null0 インターフェイスへのルートが作成されます。 このことは、ルーティング プロトコルが集約されるときには常に、集約内のすべての IP アドレスに対するトラフィックをルータが受信する可能性があるということになります。 すべての IP アドレスが常に使用されているわけではないので、集約対象のトラフィックを受信するルータでデフォルト ルートが使用されている場合にはパケットがループする危険性があります。

前提条件

要件

このドキュメントに関する固有の要件はありません。

使用するコンポーネント

このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づくものです。

  • Cisco IOS(R) ソフトウェア リリース 12.3。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。 このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。 対象のネットワークが実稼働中である場合には、どのような作業についても、その潜在的な影響について確実に理解しておく必要があります。

表記法

ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。

コマンドの構文

Null0 へのスタティック ルートは、仮想 IOS インターフェイスである Null0 インターフェイスをポイントしているという点以外は通常のスタティック ルートと同じです。 『IP ルーティング プロトコル コマンド:』を参照してください。 『Cisco IOS IP コマンド リファレンス、ボリューム 2/4:』の「I 」セクション ip route コマンドの詳細は、『ルーティング プロトコル、リリース 12.3』を参照してください。 ip route コマンドを使用して Null0 へのスタティック ルートを作成する方法の例を次のセクションに示します。

Null0 へのスタティック ルートの追加が必要になる場合がある一般的なシナリオとして、多くのクライアントがダイヤルインするアクセス サーバが考えられます。 このシナリオでは、ホスト ルートがアクセス サーバ ルーティング テーブルにインストールされます。 ホスト ルートのあるネットワーク全体にフラッディングを発生させずに、これらのクライアントへの到達可能性を確保するためには、ネットワーク内の他のルータにアクセス サーバをポイントする集約ルートを設定するのが一般的です。 このタイプの設定では、アクセス サーバの Null0 インターフェイスをポイントする同じ集約ルートをアクセス サーバに設定する必要があります。 そうしないと、ダイヤルイン クライアントに現在割り当てられていないが、集約ルートの一部である IP アドレスに外部のホストがアクセスしようとすると、ルーティングのループが発生する可能性があります。 これは、その宛先に対する特定のホスト ルートがアクセス サーバにないために、アクセス サーバのデフォルト ルートを経由して、アクセス サーバがコア ネットワークにパケットをバウンス バックするためです。

次の例を検討します。

/image/gif/paws/14956/route_to_null_interface_01.gif

小規模の ISP(ISP-R1)によって、そのいずれかの顧客に 192.168.0.0/16 のネットワーク ブロックが提供されます。 この例で、顧客は /24 ネットワークに 192.168.0.0/16 を分割し、現時点で 192.168.1.0/24 と 192.168.2.0/24 のみを使用しています。 ルータ ISP-R1 では、192.168.0.0/16 用のスタティック ルートを顧客のルータ(cust-R2)に向けて ISP が設定します。 次に ISP は BB-R3 というルータで表されるバックボーン ISP に接続します。 ルータ BB-R3 はデフォルト ルートを ISP-R1 に送信し、ISP-R1 から BGP 経由で 192.168.0.0/16 というネットワークを受信します。

cust-R2 には ISP-R1 をポイントするデフォルト ルートが設定されているので、この時点でインターネット(ISP のバックボーン ルータ BB-R3)から顧客のルータ cust-R2 への到達可能性が保障されます。 しかし、192.168.0.0/16 の範囲のうちで使用中ではないネットワーク ブロックにパケットの宛先が指定されていると、cust-R2 ルータは ISP-R1 へのデフォルト ルートを使用してそれらのパケットを転送します。 その結果、パケットは TTL の期限が切れるまで ISP-R1 と cust-R2 の間をループすることになります。 これにより、ルータの CPU とリンクの使用率に重大な影響が及ぶ可能性があります。 未使用の IP アドレスを宛先としたこのようなトラフィックの発信元の例としては、DoS 攻撃(サービス拒絶攻撃)や脆弱なホストを見つけるための IP ブロックのスキャニングなどが考えられます。

関連する設定を次に示します。

cust-R2
version 12.3
!
hostname cust-R2
!
ip subnet-zero
!
interface Loopback0
 ip address 10.2.2.2 255.255.255.255
!         
interface Ethernet0/0
 ip address 192.168.1.1 255.255.255.0
!
interface Ethernet1/0
 ip address 192.168.2.1 255.255.255.0
!
interface Serial2/0
 ip address 10.0.0.2 255.255.255.252

!--- This interface leads to ISP-R1.

!
ip classless
ip route 0.0.0.0 0.0.0.0 10.0.0.1

!--- Default route going to ISP-R1.

!
end

ISP-R1
version 12.3
!
hostname ISP-R1
!
ip subnet-zero
!
interface Loopback0
 ip address 10.1.1.1 255.255.255.255
!
interface Serial0/0
 ip address 10.0.0.1 255.255.255.252

!--- Interface to cust-R2.

!
interface Serial1/0
 ip unnumbered Loopback0

!--- Interface going to BB-R3.

!
router bgp 65501
 no synchronization
 network 192.168.0.0 mask 255.255.0.0

!--- ISP-R1 injects 192.168.0.0/16 into BGP to 
!--- advertise it to BB-R3.

 neighbor 10.3.3.3 remote-as 65503
 neighbor 10.3.3.3 ebgp-multihop 255
 no auto-summary
!
ip classless
ip route 10.3.3.3 255.255.255.255 Serial1/0
ip route 192.168.0.0 255.255.0.0 Serial0/0

!--- The first route is necessary for the eBGP 
!--- session to BB-R3 to come up.


!--- The route to 192.168.0.0/16 points towards cust-R2.

!
!
end

BB-R3
version 12.3
!
hostname BB-R3
!
ip subnet-zero
!
!
interface Loopback0
 ip address 10.3.3.3 255.255.255.255
!
interface Serial2/0
 ip unnumbered Loopback0

!--- This interface goes to ISP-R1.

!
router bgp 65503
 no synchronization
 bgp log-neighbor-changes
 neighbor 10.1.1.1 remote-as 65501
 neighbor 10.1.1.1 ebgp-multihop 255
 neighbor 10.1.1.1 default-originate 

!--- BB-R3 injects a default route into BGP and 
!--- sends it to ISP-R1.

 no auto-summary
!
ip classless
ip route 10.1.1.1 255.255.255.255 Serial2/0

!--- This route points to ISP-R1 and is 
!--- used to establish the eBGP peering.

!
end

パケット フローを次に示します。

パケット フローをよりわかりやすく示すために、ルータで一部の debug コマンド、具体的には debug ip packetdebug ip icmp を有効にしました。 その影響を十分に理解しているのでない限り、実稼働環境ではこれらのコマンドを有効にしないでください。

BB-R3# ping ip 192.168.20.1 repeat 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 192.168.20.1, timeout is 2 seconds:

*Oct  6 09:36:45.355: IP: tableid=0, s=10.3.3.3 (local), d=192.168.20.1 (Serial2/0), routed via FIB
*Oct  6 09:36:45.355: IP: s=10.3.3.3 (local), d=192.168.20.1 (Serial2/0), len 100, sending.
Success rate is 0 percent (0/1)
BB-R3#
*Oct  6 09:36:50.943: ICMP: time exceeded rcvd from 10.0.0.1

cust-R2 で使用中ではない 192.168.0.0/16 のブロック内の IP アドレスに BB-R3 が 1 つの ICMP 要求を送信します。 BB-R3 が ICMP 時間超過を ISP-R1 から返信として受信します。

ISP-R1 では次のように処理されます。

18:50:22: IP: tableid=0, s=10.3.3.3 (Serial1/0), d=192.168.20.1 (Serial0/0), routed via RIB
18:50:22: IP: s=10.3.3.3 (Serial1/0), d=192.168.20.1 (Serial0/0), g=192.168.20.1, len 100, forward
18:50:22: IP: tableid=0, s=10.3.3.3 (Serial0/0), d=192.168.20.1 (Serial0/0), routed via RIB
18:50:22: IP: s=10.3.3.3 (Serial0/0), d=192.168.20.1 (Serial0/0), g=192.168.20.1, len 100, forward
18:50:22: IP: tableid=0, s=10.3.3.3 (Serial0/0), d=192.168.20.1 (Serial0/0), routed via RIB
18:50:22: IP: s=10.3.3.3 (Serial0/0), d=192.168.20.1 (Serial0/0), g=192.168.20.1, len 100, forward
18:50:22: IP: tableid=0, s=10.3.3.3 (Serial0/0), d=192.168.20.1 (Serial0/0), routed via RIB

期待通り、シリアル 1/0 で BB-R3 からの最初のパケットが受信され、シリアル 0/0 から cust-R2 に転送されます。 同じパケットが ISP-R1 のシリアル 0/0 に返送され、次のようなルートがあるので、すぐに同じインターフェイスから cust-R2 に送出されます。

ISP-R1# show ip route 192.168.20.1
Routing entry for 192.168.0.0/16, supernet
  Known via "static", distance 1, metric 0 (connected)
  Advertised by bgp 65501
  Routing Descriptor Blocks:
  * directly connected, via Serial0/0
      Route metric is 0, traffic share count is 1

このトラフィックを ISP-R1 に返送する cust-R2 では何が起こっているのでしょうか。

cust-R2 では次のように処理されます。

*Oct  6 09:41:43.495: IP: s=10.3.3.3 (Serial2/0), d=192.168.20.1 (Serial2/0), g=10.0.0.1, len 100, forward
*Oct  6 09:41:43.515: IP: tableid=0, s=10.3.3.3 (Serial2/0), d=192.168.20.1 (Serial2/0), routed via RIB
*Oct  6 09:41:43.515: IP: s=10.3.3.3 (Serial2/0), d=192.168.20.1 (Serial2/0), g=10.0.0.1, len 100, forward
*Oct  6 09:41:43.555: IP: tableid=0, s=10.3.3.3 (Serial2/0), d=192.168.20.1 (Serial2/0), routed via RIB

cust-R2 には次のルートがあるので、これらのパッケージが ISP-R1 に返送されていることがわかります。

cust-R2# show ip route 192.168.20.1 longer-prefixes 
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is 10.0.0.1 to network 0.0.0.0

cust-R2#

192.168.20.1 は顧客のネットワークで使用されていないので、ルータ cust-R2 にはそのネットワークへのルートがありません。そのため、192.168.20.1 への最善のルートは ISP-R1 をポイントしているデフォルト ルートになります。

その結果、パケットは TTL の期限が切れるまで ISP-R1 と cust-R2 の間をループすることになります。

ICMP 要求が使用中のネットワーク内の IP アドレスに到達していれば、このような結果にはならなかったことに注意してください。 たとえば、cust-R2 に直接接続されている 192.168.1.x に対する ICMP 要求であれば、ループは発生していませんでした。

cust-R2# show ip rou 192.168.1.1
Routing entry for 192.168.1.0/24
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Routing Descriptor Blocks:
  * directly connected, via Ethernet0/0
      Route metric is 0, traffic share count is 1

この問題は、cust-R2 で 192.168.0.0/16 を Null0 へのスタティック ルートに設定すれば解決します。

cust-R2# conf t
Enter configuration commands, one per line.  End with CNTL/Z.
cust-R2(config)# ip route 192.168.0.0 255.255.0.0 Null0
cust-R2(config)# end
cust-R2#
*Oct  6 09:53:18.015: %SYS-5-CONFIG_I: Configured from console by console
cust-R2# show ip route 192.168.20.1
Routing entry for 192.168.0.0/16, supernet
  Known via "static", distance 1, metric 0 (connected)
  Routing Descriptor Blocks:
  * directly connected, via Null0
      Route metric is 0, traffic share count is 1

この時点で BB-R3 から 192.168.20.1 へ ICMP 要求を再送すれば、cust-R2 はこのトラフィックを Null0 に送信し、その結果 ICMP 到達不能が生成されます。

BB-R3# p ip 192.168.20.1 repeat 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 192.168.20.1, timeout is 2 seconds:
U
Success rate is 0 percent (0/1)
BB-R3#
*Oct  6 09:54:33.051: ICMP: dst (10.3.3.3) host unreachable rcv from 10.0.0.2

Null0 への集約スタティック ルートが使用できない場合もあります。 たとえば、前述の例が次のようになっている場合には使用できません。

  • ISDN 経由で cust-R2 にダイヤル接続する別のルータに 192.168.1.0/24 のブロックが接続されている場合

  • ISP-R1 で 192.168.0.0/16 が割り当てられておらず、192.168.1.0/24 だけが割り当てられている場合

  • ISDN リンクの接続解除が発生する場合

これらの場合には、この IP アドレス ブロックに到達しようとしている伝送中のパケットまたはアプリケーションで、前述のルーティング ループが発生します。

このルーティング ループを修正するには、ip route 192.168.1.0 255.255.255.0 Null0 200 コマンドを使用して、フローティング スタティック ルートを 192.168.1.0/24 に対して Null0 に設定する必要があります。 コマンド内の 200 はアドミニストレーティブ ディスタンスです。 『What Is Administrative Distance?』を参照してください。 参照してください。

他のルーティング プロトコルよりも高いアドミニストレーティブ ディスタンスを使用しているので、ISDN リンク経由の 192.168.1.0/24 へのルートがアクティブでなくなると、cust-R2 ではフローティング スタティック ルートがインストールされます。 そのため、ISDN リンクがアクティブになるまでは、パケットは Null0 に送信されます。


関連情報


Document ID: 14956