ルーティング設定

Routing Information Base and Routing Protocol Interaction
Administrative distance If a router learns of a network from multiple sources (routing protocols or static configurations), it uses the administrative distance value to determine which route to install in the routing (forwarding) table. The default administrative distance values are listed here.
Source Administrative Distance Connected interface 0 Static route 1 EIGRP summary route 5 External BGP 20 Internal EIGRP 90 IGRP 100 OSPF 110 IS-IS 115 RIP 120 Exterior Gateway Protocol 140 On-Demand Routing 160 External EIGRP 170 Internal BGP 200 Unknown 255
[ 6 ]
© 2007 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 132 for more details.
CCIE Routing and Switching Exam Quick Reference Sheets by Anthony Sequeira
Administrators can create static routes that “float.”A floating static route means the administrator increases the administrative distance of the static route to be greater than the administrative distance of the dynamic routing protocol in use. This means the static route is relied on only when the dynamic route does not exist.
Routing table The routing table has been the principal element of IP routing and the primary goal of routing protocols to build and maintain for most of modern internetworking. The main routing table model, the hop-by-hop routing paradigm, has the routing table list for each destination network the next-hop address to reach that destination. As long as the routing tables are consistent and accurate, with no misinformation, this simple hop-by-hop paradigm works well enough to deliver data to anywhere from anywhere in the network. In recent practice, this simple hop-byhop model is being abandoned for new technologies such as Multiprotocol Label Switching (MPLS). These technologies allow a simple and efficient label lookup to dictate the next hop that data should follow to reach a specific destination. Although this determination can be based on the routing table information, it can easily be based on other parameters, such as quality of service or other traffic engineering considerations. Note that MPLS is explored in its own chapter of this Short Cut.
CHAPTER 1
Routing information base and forwarding information base interaction The routing and forwarding architecture in Cisco routers and multilayer switches used to be a centralized, cache-based system that combined what is called a control plane and a data plane. The control plane refers to the resources and technologies used to create and maintain the routing table. The data plane refers to those resources and technologies needed to actually move data from the ingress port to the egress port on the device. This centralized architecture has migrated so that the two planes can be separated to enhance scalability and availability in the routing environment.
The separation of routing and forwarding tasks has created the Routing Information Base (RIB) and the Forwarding Information Base (FIB). The RIB operates in software, and the control plane resources take the best routes from the RIB and place them in the FIB. The FIB resides in much faster hardware resources. The Cisco implementation of this enhanced routing and forwarding architecture is called Cisco Express Forwarding (CEF).
Redistribution
Redistribution between routing protocols Route redistribution might be required in an internetwork because multiple routing protocols must coexist in the first place. Multiple
[ 7 ]
© 2007 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 132 for more details.
CCIE Routing and Switching Exam Quick Reference Sheets by Anthony Sequeira
routing protocols might be a necessity because of an interim period during conversion from one to another, application-specific protocol requirements, political reasons, or a lack of multivendor interoperability.
A major issue with redistribution is the seed metric to be used when the routes enter the new routing protocol. Normally, the seed metric is generated from the originating interface. For example, EIGRP would use the bandwidth and delay of the originating interface to seed the metric. With redistributed routes, however, these routes are not connected to the router. Some routing protocols feature a default seed metric for redistribution, whereas others do not. Here is a list of the defaults for the various protocols. Note that Infinity indicates a seed metric must be configured; otherwise, the route will not be used by the receiving protocol.
Protocol Default Seed Metric OSPF 20; except BGP, which is 1 IS-IS 0 RIP Infinity IGRP/EIGRP Infinity
CHAPTER 1
Redistribution into RIP Remember to set a default metric, using either the redistribute command or the default-metric command. The command to redistribute routes into RIP is as follows:
redistribute protocol [process-id] [match route-type] [metric metric-value] [route-map map-tag]
The match keyword allows you to match certain route types when redistributing OSPF. For example, you can specify internal, or external 1, or external 2. The route-map keyword allows you to specify a route map for controlling or altering the routes that are being redistributed.
Redistribution into OSPF The default seed metric is 20. The default metric type for redistributed routes is Type 2. Subnets are not redistributed by default. The command for redistribution into OSPF is as follows:
redistribute protocol [process-id] [metric metric-value] [metric-type type-value] [route-map map-tag] [subnets] [tag tag-value]
The subnets keyword is critical in this command and specifies that subnets should indeed be redistributed. The tag value allows the administrator to configure an optional tag value that can be used later to easily identify these routes.
[ 8 ]
© 2007 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 132 for more details.
CCIE Routing and Switching Exam Quick Reference Sheets by Anthony Sequeira
Redistribution into EIGRP Remember that like RIP, you must set a default seed metric when redistributing into EIGRP. The command for redistribution into EIGRP is as follows:
redistribute protocol [process-id] [match {internal | external 1 | external 2}] [metric metric-value] [route-map map-tag]
Troubleshooting routing loops You can perform one-way or two-way redistributions. Redistribution can also be performed in multiple locations throughout the topology.
With one-way redistribution, you typically pass a default route into the “edge” protocol, and take all the edge protocol routes and redistribute them into the core protocol of the network.
With two-way redistribution, all routes from each routing protocol are passed into each other. If two-way redistribution is performed in multiple areas in the network, there is an excellent chance for route “feedback” and routing loops. Routing loops are highly likely to occur because routing information from one autonomous system can easily be passed back into that same autonomous system.
CHAPTER 1
The safest way to eliminate the chance for a loop is to redistribute only in one direction (one-way redistribution). If this is not possible, and two-way redistribution is desired, try these techniques to ensure a lack of loops:
Redistribute from the core protocol into the edge with filtering to block routes that are native to the edge.
Apply two-way redistribution on all routes, and manipulate administrative distance associated with the external routes so that they are not selected when multiple routes exist for the same destination.
An excellent technique to detect a routing loop during redistribution is to use the debug ip routing command. This command shows all routing table activity as it occurs and demonstrates a loop condition through routing table instability.

DARPA

衛星軌道上に機材とロボットを打ち上げれば、あとは人工衛星のできあがり。米国防高等研究計画局(DARPA)の新たなプロジェクトが実現すれば、そんな未来図が現実のものとなる。
そのプロジェクト、Phoenix計画においてDARPAは、人工衛星群をいかに増設し維持していくのかを根本から見直す作業を続けてきた(日本語版記事)。内容はこうだ。ロボットを利用し人工衛星の小型モジュール「Satlets」を組み上げる。パーツはそれぞれ15ポンド程度で、それぞれ電源や制御機構、センサーなどの機能別に分かれている。すべてのパーツは、簡単に、かつ素早く展開できるよう「Payload Orbital Delivery (POD) system」によって運ばれる。
計画は、試作第1フェーズが終了。DARPAでプログラムマネジャーを務めるデヴィッド・バーンハートは声明において、「ロボットツールが有効であること、組み立て技術が実現可能だということが明らかになった。また、それだけでなく、宇宙空間での物理的な組み立て作業によって、新たな人工衛星をつくることができるというコンセプトを立証した」と語った。「これらの成功によって、軌道上につくりあげたシステムを、コストを大幅に抑えて運用できるようになるだろう」
現在のところ、人工衛星はとても高額で、開発には時間もかかる。また、惑星軌道上では修理・改修も期待できないため、長期使用に耐えられるようデザインしなければならない。コストもサイズも限られたなかで、高度約35786kmの静止軌道上に送り出された人工物に対し、いまわれわれがもてる技術では文字通り、手が届かないのだ。
Phoenix計画からなる技術は「人工衛星を新たに軌道上に送り出すときにも、また、正しい軌道にのせるのも助けてくれる。何かトラブルがあれば、軌道上に残された古いパーツで補うなどして、衛星を改修できるようになるだろう。そうした作業が当たり前になるのだ」

アメリカ

EUREKAプロメテウス計画(英語: The EUREKA Prometheus Project、PROgraMme for a European Traffic of Highest Efficiency and Unprecedented Safety、1987-1995、欧州における最高度の効率性と前例のない安全性を持つ交通のためのプログラム)とは欧州にて1987年から1995年まで実施された、交通効率ならびに安全性向上を目的とした無人自動車分野におけるかつてない大規模な研究開発プロジェクトである。今日まで欧州委員会により10億ドル以上の資金が投入され、自立型自動車(autonomous cars)の実用化が視野に入った。多数の大学や自動車製造企業がこの汎欧州的計画に参加している。


プロメテウスは無人自動車分野の先駆者であるエルンスト・ディックマンズ(英語版)が1980年代にミュンヘン連邦軍大学の彼のチームを率いダイムラー・ベンツと共同で無人自動車の開発を始めた事から始まった。プロジェクト最初の全盛期に到達したのは1994年であり、1組の無人自動車、VaMP(英語版)とVITA-2がパリにある複線の高速道路を130 km/h以上の速度を保ち、いつも通り激しい交通量でありながらも、1,000km以上駆け抜けることに成功した。双方の車両は他車両が通行していない道路での自立走行、続いてコンボイ走行、他車両の自動追従、他車両の自立的追い越し運転において車線変更を行うなどの実地検証を行った。
次のプロジェクトの最盛期は、1995年であり、ディックマンズが自立走行可能なように改造したメルセデス・ベンツ・Sクラスを用いてバイエルン州ミュンヘンからデンマークのコペンハーゲンまでの往復1000マイルを走破した。この自動車には、リアルタイムでの応答性を保持するため断続性運動(英語版)型コンピュータ視覚技術ならびにトランスピュータが利用されている。この無人自動車はドイツのアウトバーン上で175 km/h以上の速度に到達した。この間人間が操作に介在したのは距離にして9 kmだった。走行中他車両を追い抜くこともできた。もとより同車は長距離の走行に信頼性を置いていない研究システムであったにもかかわらず、同車は人手を介することなく158 km以上の速度で走行した。
プロメテウス計画達成の報はその他多くの無人自動車の業績の基礎となっている。