No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search


To have a better experience, please upgrade your IE browser.


S600-E V200R013C00 Configuration Guide - IP Unicast Routing

This document describes the configurations of IP Unicast Routing, including IP Routing, Static Route, RIP, RIPng, OSPF, OSPFv3, Routing Policy, IP Routing Table Management, and PBR.

Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
OSPF Network Planning and Design

OSPF Network Planning and Design

OSPF Network Stability: Router ID Design

Router ID selection is the first task in OSPF network design and implementation.

As a link-state routing protocol, OSPF calculates routes based on LSAs. All OSPF routers on an OSPF network send and flood LSAs to the entire network. In this way, each OSPF router on the network collects LSAs received from other routers, saves the LSAs in its LSDB, and uses an SPF algorithm to calculate an SPT to other networks with itself as the root. Therefore, ensuring the stability of the LSDB on each OSPF router is a prerequisite for ensuring the stability of the OSPF network. In an LSDB, LSAs received from different OSPF routers are distinguished by router ID. If the router ID of a router changes, the router floods its LSAs again. As a result, all the other OSPF routers on the network update their LSDBs and perform SPF calculation again, leading to OSPF network flapping. Therefore, selecting stable router IDs is the first task in OSPF network design.

Router IDs can be configured manually. If no router ID is specified for a router, the system automatically selects an interface IP address as the router's router ID. The router ID selection rules are as follows:

  1. The router preferentially selects the largest IP address among loopback interface addresses as the router ID.

  2. If no loopback interface is configured, the router selects the largest IP address among interface addresses as the router ID.

  3. The router reselects a router ID only when the interface address used as the router ID is deleted or changed.

On actual networks, it is recommended that router IDs of OSPF routers be specified manually. First, plan a private network segment such as for router ID selection. Before starting the OSPF process, create a loopback interface on each OSPF router, and use a private IP address with a 32-bit mask as the IP address of the loopback interface. The private IP address is then used as the router's router ID. If there is no special requirement, the address of this loopback interface does not need to be advertised to the OSPF network.

Hierarchical Network Design: OSPF Area Design

OSPF is a network protocol that requires hierarchical design. The concept of area is used on an OSPF network. From a hierarchical perspective, areas on an OSPF network are classified into backbone and non-backbone areas. The ID of the backbone area is 0 and that of a non-backbone area is in the range 1 to 4294967295. An OSPF router on the border between the backbone area and a non-backbone area is called ABR.

Actually, OSPF area design is the process of classifying OSPF routers on the network. The first consideration in OSPF area design is the network scale. You can only plan the backbone area for small networks such as a network with several routers as the core and aggregation devices. However, hierarchical network design is required on large OSPF networks.

For large OSPF networks, the core, aggregation, and access layers must be planned in OSPF area design. In addition, OSPF backbone routers are generally egress routers and core switches. These devices are typically high-end routing devices such as Huawei NE series high-end routers and Huawei S series modular switches. Non-backbone area design depends on the geographical locations and device performance. If many low-end Layer 3 switching devices with product positioning and performance limitations are deployed in a non-backbone area, the number of routes should be minimized using small-sized areas or special areas.

The IDs of non-backbone areas on an actual network should not be planned randomly. Consecutive IDs such as 1, 2, and 3 are not recommended. It is recommended that IDs in ascending order such as 10, 20, and 30 be used, facilitating area ID addition in future network capacity expansion.

Routing Entry Optimization for Non-Backbone Areas: Special Areas

Using special areas can optimize routing entries on routers in non-backbone areas. Generally, the number of routing entries on routers in a non-backbone area needs to be reduced in the following scenarios:

  • The non-backbone area has only one ABR as the egress router and all traffic for accessing external areas needs to pass through this egress router. In this case, non-ABR routers in this non-backbone area do not need to obtain detailed information about external areas, and only an egress is required to send traffic outside this area.

  • Low-end Layer 3 switches are deployed in the non-backbone area and their routing tables cannot contain too many routing entries due to performance limitations. Special areas can be configured to reduce the number of routing entries on the devices.

Switches support four types of special areas defined in OSPF: stub area, totally stub area, NSSA, and totally NSSA.

In most cases, routers in non-backbone areas on a typical OSPF network only need to know the outbound interface of the default route. Therefore, it is recommended that non-backbone areas be planned as totally NSSAs. This can significantly reduce the number of routing entries on internal routers in the non-backbone areas and the number of OSPF packets to be exchanged among these routers. For some networks with special requirements, the four types of special areas can be used flexibly based on actual requirements.

Routing Entry Optimization for the Backbone Area: IP Subnetting and Route Summarization in Non-Backbone Areas

Because routers in the backbone area are responsible for route exchange among areas, these routers have large routing tables. You can properly plan IP subnets for non-backbone areas and summarize routes on the routers residing on area borders to optimize routing entries on routers in the backbone area.

It is recommended that an IP network facilitating route summarization be used as a new OSPF network, and that IP addresses be planned again for expanded OSPF networks. Route summarization can reduce the number of routing entries in the routing tables of routers in the backbone area and the number of OSPF packets to be exchanged among these routers. After routes are summarized, a single-point link failure or network flapping will not affect route update on the entire network. Therefore, route summarization also improves the network stability.

Uplink Traffic Diversion: Default OSPF Route Import and Route Selection Optimization

Most service traffic on a large OSPF network is not transmitted inside the network, but is forwarded to the Internet egress. Therefore, default route design is a key design point for an OSPF network.

An actual OSPF network may have more than one egress. Configuring multiple links to load balance egress traffic is a difficult task in OSPF network design. Although there are many load balancing methods, the most simple and secure method is to use the internal route selection mechanism of OSPF. An OSPF router determines whether a route is optimal by calculating its cost, and preferentially adds a route with a smaller cost to its routing table. Therefore, you can adjust the costs of OSPF interfaces to make a router select different outbound interfaces for load balancing.

OSPFv2 was developed earlier and rapid bandwidth development was not considered at that time. By default, the reference bandwidth for OSPF cost calculation is 100 Mbit/s. Therefore, by default, OSPF considers that the cost of an interface with bandwidth greater than 100 Mbit/s is 1. The reference bandwidth is outdated because the network backbone bandwidth develops towards 10 Tbit/s. Switches provide the function of changing the reference bandwidth. In OSPF network construction, you can run the bandwidth-reference command to configure a proper reference bandwidth. In summary, to optimize route selection on an OSPF network, you are advised to select a proper reference bandwidth to adjust the costs of OSPF interfaces.

Loop Prevention in Route Summarization Scenarios: Blackhole Route

Route summarization can reduce the number of routes and improve the network stability in many scenarios. However, routing loops may occur in route summarization. Blackhole routes can solve this problem. A router discards packets that match a blackhole route, and does not send any error information to the packet sender. Therefore, route summarization and blackhole routes are often used together in OSPF network design.

OSPF Network Security: Silent Interface

Security must be the first consideration for large OSPF networks. In OSPF network design, OSPF packets are often prohibited from being sent to users, preventing end users from obtaining OSPF packet information. If a user can intercept OSPF packets, the user will know how to connect to the OSPF network, making the OSPF network prone to attacks or damages. For example, if the user connects a router to the OSPF network and makes the router's OSPF process unstable, the OSPF network will flap or even break down.

To ensure security and stability of an OSPF network, it is recommended that silent interfaces be configured on edge devices of the OSPF network to prevent OSPF packets from being sent to users. These silent interfaces are prohibited from receiving and sending OSPF packets. These interfaces can still advertise direct routes, but cannot establish neighbor relationships because Hello packets are blocked on the interfaces.

Updated: 2019-04-08

Document ID: EDOC1100066165

Views: 34309

Downloads: 3

Average rating:
This Document Applies to these Products

Related Version

Related Documents

Previous Next