没有合适的资源?快使用搜索试试~ 我知道了~
首页从EIGRP迁移到OSPF
资源详情
资源推荐
WHITE PAPER
Copyright © 2010, Juniper Networks, Inc. 1
MIGRATING EIGRP
NETWORKS TO OSPF
Motivations and Tactics for Moving from Cisco EIGRP to a
More Scalable and Manageable Open Standards Network
2 Copyright © 2010, Juniper Networks, Inc.
WHITE PAPER - Migrating EIGRP Networks to OSPF
Table of Contents
Executive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
The Multi-Vendor Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Overview of EIGRP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Problems with EIGRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
SIAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Proprietary Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Overview of OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Advantages of OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Topological Rigor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Open Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Widespread Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Broad Vendor Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Easier to Troubleshoot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Migrating from EIGRP to OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Logical Inventory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Changing the Network Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Using Administrative Distance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Enabling and Testing OSPF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Cutover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Disabling EIGRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Junos Space Route Insight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
About Juniper Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Table of Figures
Figure 1: EIGRP functional modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Figure 2: EIGRP Query messages can diffuse to the edges of a network; each router passing on a
Query must then wait for a corresponding Reply message to each query. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Figure 3: OSPF uses a hierarchical area structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Figure 4: The EIGRP network used in the example migration to OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Figure 5: If the EIGRP topology is well organized, the OSPF area structure can be directly superimposed. . . . . . . . . . . . . . . . . . . . 14
Figure 6: Route Insight can gather EIGRP information by using adjacencies in each EIGRP AS boundary router. . . . . . . . . . . . . . 25
Figure 7: Route Insight uses automatically gathered information to form a topological map of the EIGRP network. . . . . . . . . . 26
Figure 8: A Route Insight adjacency list display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Figure 9: A prefix list further supports the premigration inventory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Figure 10: A network model can be used both for evaluating the effects of premigration EIGRP topology changes
and the overlay of the OSPF topology. Here, a new link through the EIGRP network is modeled. . . . . . . . . . . . . . . . . . . 27
Table of Figures
Table 1: Default Administrative Distances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Copyright © 2010, Juniper Networks, Inc. 3
WHITE PAPER - Migrating EIGRP Networks to OSPF
Executive Summary
OSPF is the routing protocol of choice for almost all large IP networks. No other Interior Gateway Protocol (IGP) provides the
combination of speed, scalability, reliability, and flexibility of OSPF. And because OSPF is an open standard, it is an essential
component of large, scalable, innovative networks. Yet many network operators have locked themselves into the proprietary
Extended Interior Gateway Routing Protocol (EIGRP).
As their networks grow large, this once simple protocol begins to present scaling problems that can be increasingly disruptive
to the network and are notoriously difficult to troubleshoot. Interestingly, the very characteristics that make EIGRP simple
to use in small networks are the same characteristics that become liabilities in large networks: No requirements to build
an ordered or hierarchical network, thus allowing the network to expand in random patterns; no inherent capabilities to
break a network into manageable areas without resorting to multiple EIGRP processes; no need to think about your network
topology. And, stuck in active (SIA) conditions, regularly encountered in larger EIGRP networks, cause abrupt, unpredictable
adjacency drops that can have severe effects throughout the network.
As a proprietary Cisco protocol, EIGRP locks you into a single vendor—an economic liability for large network operators. Perhaps
most important of all, EIGRP locks you out of the versatility and agility that distinguish today’s innovative business networks.
Almost all EIGRP network operators eventually encounter these problems. Most realize the need to move to the more
scalable, more widely supported OSPF. But in many cases, the network’s logical topology has run out of control to such an
extent that conducting an EIGRP-to-OSPF migration appears daunting and risky.
Juniper Networks provides the expertise and the products to help you plan, model, and execute such a protocol migration
safely and successfully. This paper gives you the key steps and strategy of a protocol migration project, and shows you what
to be aware of as that project progresses.
Introduction
Modern enterprise networks are fundamental to business operations, competitiveness, growth, and innovation. With almost
all business critical applications dependent on the network, a multi-vendor strategy is essential to selecting the network
products that best fit your business needs—at the best cost and with the least risk. Most importantly, a multi-vendor strategy
allows you to develop innovative network capabilities that keep you ahead of your competition.
The success of a multi-vendor strategy is dependent on open standards throughout the network, and OSPF is the foundation
of that strategy. Supported by all significant router manufacturers, backed by years of experience, and matured by an
enormous body of developers, OSPF is by far the most widely deployed and well understood IGP in the industry.
Many operators of small to medium enterprise networks, however, have locked themselves into a single vendor and thus
locked themselves out of a multi-vendor strategy by selecting, early in their network deployments, the proprietary EIGRP.
Generally this selection is due to an outdated, misguided perception that EIGRP is a simpler protocol to deploy and maintain
than OSPF. The reality is quite the opposite. OSPF is no more difficult to configure than EIGRP, and as your network becomes
large, the scaling features of OSPF can make it easier to configure. Nor are modern OSPF implementations any more
resource intensive than EIGRP. And, as this paper discusses, OSPF is easier to troubleshoot in large networks than is EIGRP.
The perceived simplicity of EIGRP becomes a liability as EIGRP approaches its scaling limits in large networks. Key to
this phenomenon is the fact that EIGRP does not force you to think about your network topology; you just add a router,
enable the protocol, and it works. As a result, many large EIGRP networks can be “spaghetti networks” with links placed
more for convenience than for control. Operators and engineers are forced to dig deep into the behavior of the protocol to
troubleshoot problems, and quickly discover that “under the hood,” EIGRP is much more complex than it appears in smaller
networks. The troubleshooting is complicated by a network that has grown without any disciplined topological rules.
Operators of large EIGRP networks almost always face a threshold at which they are forced to consider converting their
network to OSPF to gain the inherent scaling properties of that protocol. But by the time they reach that point, the task of
“untangling” their network can be daunting.
This paper provides a basic framework for planning an EIGRP-to-OSPF conversion. To begin, we look at the basics of both
protocols and the reasons that so many network operators find themselves needing to move to OSPF.
4 Copyright © 2010, Juniper Networks, Inc.
WHITE PAPER - Migrating EIGRP Networks to OSPF
The Multi-Vendor Strategy
Avoiding technical or contractual lock-ins to a single vendor is a proven and widely employed strategy for holding down cost,
reducing risk, and maximizing network flexibility. A multi-vendor strategy does not necessarily mean that you always choose
multiple vendors for every network component. Rather, it means that you avoid anything that prevents you from seeking out
the best solutions at the best price.
By insisting on open standards in your network and avoiding exclusive contractual obligations, your business realizes
multiple benefits:
• Lower capital expense. A vendor who knows you cannot easily incorporate a competitor’s products into your network is
much less motivated at the bargaining table.
• Best-in-class solutions. Committing yourself to a single vendor sharply reduces your ability to seek out the best product
on the market for each function of your network.
• Focused expertise. A vendor specializing in a certain area of networking can often offer much deeper development and
support expertise than a vendor supporting a wide range of products.
• Lower risk. By diversifying your suppliers, you are less vulnerable to a single software malfunction affecting your entire
network. Your network is also less at risk of product obsolescence, vendor buyouts, or business failures.
• Innovation. The most competitive enterprises see their network as a fundamental tool for business innovation. Agility,
adaptation, and flexibility are the key qualities that keep your network ahead of your competitors.
Overview of EIGRP
EIGRP is a distance vector protocol—that is, each EIGRP-speaking router updates its neighbors by sending a list of prefixes
it can reach along with a distance (metric) and direction (vector) for each. The superior performance of EIGRP compared to
other distance vector protocols lies in the fact that its updates are non-periodic, partial, and bounded:
• Non-periodic means that updates are not sent on a regular schedule, but only when a metric or topology change occurs.
• Partial means that rather than sending all known prefixes, the updates contain only the prefixes that have changed.
• Bounded means that the updates are only sent to affected routers.
EIGRP consists of four functional components:
• Protocol-dependent modules support the unique characteristics and behaviors of each of the network-layer protocols it
can route, and encapsulate its messages in the correct protocol packet format. In addition to IP, EIGRP can route IPX and
AppleTalk. Given that the networking world is rapidly evolving to an “everything over IP” model, the ability to route IPX and
AppleTalk along with IP is much less of a selling factor for EIGRP than it was in the early to mid 1990s.
• Neighbor discovery and recovery uses a simple Hello protocol to discover neighbors, record the information from a
neighbor’s Hello messages in a neighbor table, and detect the loss of a neighbor.
• Reliable transport protocol defines the EIGRP message formats and manages the reliable delivery of messages. EIGRP
messages include Hellos, Acknowledgements, Updates, Queries, and Replies. As we will see shortly, Queries and Replies are
essential to EIGRP’s unique route resolution algorithm and are also behind one of the problems that begin to arise when
EIGRP approaches its scaling limits. Reliable transport of messages is accomplished through a combination of multicast
transmission and unicast acknowledgements. Ordered message delivery is accomplished through sequence numbers.
• Diffusing Update Algorithm (DUAL) is the most distinctive difference between EIGRP and other distance vector IP
routing protocols. When an EIGRP router receives a route from a neighbor, it calculates the distance of the route by
adding its distance to the neighbor to that route’s distance advertised by the neighbor. If there are multiple routes to
the same destination, the router selects the route with the shortest distance. This additive distance calculation is no
different from other distance vector protocols. What makes DUAL different is the way it treats other routes it learns to the
same destination. The distance of the selected shortest route becomes the feasible distance (FD) for that destination.
If a neighbor advertises a route to the destination with a distance that is less than the FD, that neighbor becomes a
feasible successor for the destination.
1
If the current route becomes invalid, the router can immediately choose a feasible
successor’s route.
1
This assumes that the router’s distance to the feasible successor plus the successor’s distance to the destination is greater than the FD. If the sum is less, the successor’s
route becomes the new best route to the destination, and the distance to the neighbor plus the neighbor’s distance to the destination becomes the new FD.
Copyright © 2010, Juniper Networks, Inc. 5
WHITE PAPER - Migrating EIGRP Networks to OSPF
DUAL’s “feasibility” mechanisms enable both EIGRP’s loop free route calculations and its very fast reconvergence:
• By disqualifying as a feasible successor any neighbor whose route to a destination is higher than the FD, no looping routes
are accepted (the distance of a neighbor’s route that loops through the local router will always have a distance higher than
the FD).
• By preselecting feasible successors, the local router often—although, as we will see shortly, not always—knows of any
alternate routes that might exist to a destination and can quickly switch to that route if the shortest route fails.
Figure 1: EIGRP functional modules
Traditional distance vector protocols calculate a new route only after an existing route fails. Although they can eventually
determine if the new route contains a loop, they have no means of avoiding all loops before the route is selected.
While EIGRP’s feasibility mechanisms ensure that no looped routes are considered for reconvergence, they do not ensure that
all rejected routes have loops. When an existing route fails, there might be a legitimate next best route to the destination that
was rejected because the distance from the neighbor is greater than the feasible distance. So if a route becomes invalid and
it has no feasible successor, EIGRP will actively search for another route to the destination.
The router changes the state of the route from passive to active, which “locks down” changes to the route while it looks for a
new route. The router then sends Query messages to its neighbors asking if the neighbor has a route to the destination. The
neighbor receiving the Query will react in one of four ways:
• If the neighbor has no route to the queried destination, it will send a Reply message indicating that the route is unreachable
from this neighbor.
• If the neighbor has a different successor from the querying router, it sends a Reply message indicating that it has a route to
the destination.
• If the querying router was the next hop (successor) for the route and the neighbor has another feasible successor, it will
switch its route to the feasible successor and send a Reply indicating that it has a route to the queried destination.
• If the querying router was the successor for the route and the neighbor does not have a feasible successor, the neighbor will
change its own route to active and send Query messages to all of its own neighbors (except for the router that queried it).
It does not send a reply to the querying router until it has received replies from all of the neighbors it has queried.
Eventually, either a successor for the route is discovered, or the Query messages reach the boundaries of the network and
Reply messages indicating no successors make their way back to the original querying router. This diffusing of queries
through the network (Figure 2) is where the DUAL algorithm gets its name.
IPX
Protocol Dependent
Modules
Network-Layer
Encapsulation
IP APPLETALK
IPX IP APPLETALK
Diusing Update Algorithm (DUAL)
Neighbor Discovery/Recovery
Reliable Transport Protocol
剩余27页未读,继续阅读
小草大神
- 粉丝: 0
- 资源: 3
上传资源 快速赚钱
- 我的内容管理 收起
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
会员权益专享
最新资源
- zigbee-cluster-library-specification
- JSBSim Reference Manual
- c++校园超市商品信息管理系统课程设计说明书(含源代码) (2).pdf
- 建筑供配电系统相关课件.pptx
- 企业管理规章制度及管理模式.doc
- vb打开摄像头.doc
- 云计算-可信计算中认证协议改进方案.pdf
- [详细完整版]单片机编程4.ppt
- c语言常用算法.pdf
- c++经典程序代码大全.pdf
- 单片机数字时钟资料.doc
- 11项目管理前沿1.0.pptx
- 基于ssm的“魅力”繁峙宣传网站的设计与实现论文.doc
- 智慧交通综合解决方案.pptx
- 建筑防潮设计-PowerPointPresentati.pptx
- SPC统计过程控制程序.pptx
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功