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

Reminder

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

upgrade

Configuration Guide - IP Unicast Routing

S1720, S2700, S5700, and S6720 V200R011C10

This document describes IP Unicast Routing configurations supported by the switch, including the principle and configuration procedures of IP Routing Overview, Static Route, RIP, RIPng, OSPF, OSPFv3, IS-IS(IPv4), IS-IS(IPv6), BGP, Routing Policy ,and PBR, and provides configuration examples.
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 Design Deployment Case

OSPF Network Design Deployment Case

Figure 6-57 shows a typical campus network topology. This is a large campus network with the core, aggregation, and access layers and multiple egresses to the Internet. On this network, dual-link redundancy and cluster protection among core and aggregation switches have been deployed. Typically, on such a large campus network, Huawei NE series high-end routers are deployed as egress devices, and Huawei campus cluster-supporting modular switches are deployed as core and aggregation switches. User gateways are deployed on the aggregation layer, and aggregation switches are the boundary between Layer 2 and Layer 3 networks.

Figure 6-57  Typical campus network topology

Core and aggregation switches in the typical campus network belong to clusters, and one cluster functions like a single logical device. Multiple links are bundled together to form a single logical link. For simplicity, the preceding network topology is simplified into the logical topology shown in Figure 6-58. There may be multiple buildings in this campus network, and the following example uses three buildings.

Figure 6-58  Typical campus network logical topology

OSPF Network Stability: Router ID Design

The primary task of deploying OSPF is to design and deploy router IDs. In most situations, an appropriate private IP address segment can be used to design router IDs. This example uses IP addresses on the IP address segment 10.0.0.0/24 as router IDs.

After router IDs are designed, you need to create loopback interfaces on each OSPF device and configure an IP address 10.0.0.X/32 for each loopback interface.

The following example configures router IDs for a core modular switch cluster.

[HUAWEI] interface LoopBack 0
[HUAWEI-LoopBack0] ip address 10.0.0.3 32  //Configure an IP address with a 32-bit mask for LoopBack0.
[HUAWEI-LoopBack0] quit
[HUAWEI] ospf 1 router-id 10.0.0.3  //Create OSPF process 1 and set the router ID to 10.0.0.3.
NOTE:

If there are no special requirements, to reduce unnecessary OSPF packet exchanges, it is recommended not to advertise IP addresses of Loopback0 into OSPF processes.

Figure 6-59 shows the network topology after router IDs are designed.

Figure 6-59  Network topology after router IDs are designed

Hierarchical Network Design: OSPF Area Design

After router IDs are assigned to routers, you need to partition the OSPF network. To partition a hierarchical OSPF network, deploy egress routers and core switches in Area 0 and design non-backbone areas based on geographical locations. When designing area IDs for non-backbone areas, ensure that new areas are easy to add for network expansion. Based on geographical locations involved in this case, deploy egress routers and core switches in the backbone area and aggregation switches in each building in a non-backbone area. Figure 6-60 shows the OSPF network topology after area partitioning.

Figure 6-60  OSPF network topology after area partitioning

The following example configures Area 0 and Area 10 for the core switch cluster.

[HUAWEI] ospf 1  //Enter the OSPF process view.
[HUAWEI-ospf-1] area 0  //Enter the view of Area 0.
[HUAWEI-ospf-1-area-0.0.0.0] network 10.200.10.0 0.0.0.3  //Advertise the network segment where the uplink interface is located into Area 0.
[HUAWEI-ospf-1-area-0.0.0.0] network 10.200.20.0 0.0.0.3  //Advertise the network segment where the uplink interface is located into Area 0.
[HUAWEI-ospf-1-area-0.0.0.0] quit
[HUAWEI-ospf-1] area 10  //Enter the view of Area 10.
[HUAWEI-ospf-1-area-0.0.0.10] network 10.100.10.0 0.0.0.3  //Advertise the network segment where the downlink interface is located into Area 10.
[HUAWEI-ospf-1-area-0.0.0.10] quit

The preceding configuration commands show that an OSPF device is located at the border between OSPF areas. For example, the uplink and downlink interfaces of the core switch cluster belong to Area 0 and Area 10 respectively. That is, this cluster functions as an ABR.

NOTE:

It is a bad design to deploy many low-end routers or Layer 3 switches in a single OSPF area, and it is better to reduce the number of devices in a single OSPF area.

Routing Entry Optimization for Non-Backbone Areas: Special Areas

After the OSPF network is partitioned into multiple areas, you may find that the routing table size of devices in non-backbone areas is large. If devices in non-backbone areas have low performance and are expected not to maintain a large routing table, use special areas. In this case, non-backbone areas are designed as totally NSSAs. Figure 6-61 shows the network topology.

Figure 6-61  Network topology after non-backbone areas are designed as totally NSSAs

The following example configures a core switch cluster and an aggregation switch cluster in Area 10 as a reference for configuring totally NSSAs.

Configure a totally NSSA on the core switch cluster.

[HUAWEI] ospf 1  //Enter the OSPF process view.
[HUAWEI-ospf-1] area 10  //Enter the view of Area 10.
[HUAWEI-ospf-1-area-0.0.0.10] nssa no-summary  //Configure nssa no-summary for the ABR.
[HUAWEI-ospf-1-area-0.0.0.10] quit

Configure a totally NSSA on the aggregation switch cluster.

[HUAWEI] ospf 1  //Enter the OSPF process view.
[HUAWEI-ospf-1] area 10  //Enter the view of Area 10.
[HUAWEI-ospf-1-area-0.0.0.10] nssa  //Configure nssa for the non-ABR.
[HUAWEI-ospf-1-area-0.0.0.10] quit

Before a totally NSSA is configured, routing entries from the aggregation switch cluster to non-backbone areas are as follows:

<HUAWEI> display ip routing-table
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Tables: Public
         Destinations : 21        Routes : 21        

Destination/Mask    Proto   Pre  Cost      Flags NextHop         Interface

      10.0.0.4/32   Direct  0    0           D   127.0.0.1       LoopBack0
     10.10.1.0/24   Direct  0    0           D   10.10.1.1       Vlanif100
     10.10.1.1/32   Direct  0    0           D   127.0.0.1       Vlanif100
     10.10.2.0/24   Direct  0    0           D   10.10.2.1       Vlanif200
     10.10.2.1/32   Direct  0    0           D   127.0.0.1       Vlanif200
     10.10.3.0/24   Direct  0    0           D   10.10.3.1       Vlanif300
     10.10.3.1/32   Direct  0    0           D   127.0.0.1       Vlanif300
     10.20.1.0/24   OSPF    10   3           D   10.100.10.1     Vlanif10
     10.20.2.0/24   OSPF    10   3           D   10.100.10.1     Vlanif10
     10.20.3.0/24   OSPF    10   3           D   10.100.10.1     Vlanif10
     10.30.1.0/24   OSPF    10   3           D   10.100.10.1     Vlanif10
     10.30.2.0/24   OSPF    10   3           D   10.100.10.1     Vlanif10
     10.30.3.0/24   OSPF    10   3           D   10.100.10.1     Vlanif10
   10.100.10.0/30   Direct  0    0           D   10.100.10.2     Vlanif10
   10.100.10.2/32   Direct  0    0           D   127.0.0.1       Vlanif10
   10.100.20.0/30   OSPF    10   2           D   10.100.10.1     Vlanif10
   10.100.30.0/30   OSPF    10   2           D   10.100.10.1     Vlanif10
   10.200.10.0/30   OSPF    10   2           D   10.100.10.1     Vlanif10
   10.200.20.0/30   OSPF    10   2           D   10.100.10.1     Vlanif10
      127.0.0.0/8   Direct  0    0           D   127.0.0.1       InLoopBack0
      127.0.0.1/32  Direct  0    0           D   127.0.0.1       InLoopBack0

After a totally NSSA is configured, routing entries from the aggregation switch cluster to non-backbone areas are as follows:

<HUAWEI> display ip routing-table
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Tables: Public
         Destinations : 12        Routes : 12        

Destination/Mask    Proto   Pre  Cost      Flags NextHop         Interface

       0.0.0.0/0    OSPF    10   2           D   10.100.10.1     Vlanif10
      10.0.0.4/32   Direct  0    0           D   127.0.0.1       LoopBack0
     10.10.1.0/24   Direct  0    0           D   10.10.1.1       Vlanif100
     10.10.1.1/32   Direct  0    0           D   127.0.0.1       Vlanif100
     10.10.2.0/24   Direct  0    0           D   10.10.2.1       Vlanif200
     10.10.2.1/32   Direct  0    0           D   127.0.0.1       Vlanif200
     10.10.3.0/24   Direct  0    0           D   10.10.3.1       Vlanif300
     10.10.3.1/32   Direct  0    0           D   127.0.0.1       Vlanif300
   10.100.10.0/30   Direct  0    0           D   10.100.10.2     Vlanif10
   10.100.10.2/32   Direct  0    0           D   127.0.0.1       Vlanif10
      127.0.0.0/8   Direct  0    0           D   127.0.0.1       InLoopBack0
      127.0.0.1/32  Direct  0    0           D   127.0.0.1       InLoopBack0

The preceding outputs show that after a totally NSSA is configured, the IP routing table size of Area 10 is reduced significantly. This indicates that configuring a non-backbone area as a totally NSSA can reduce the routing table size.

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

After non-backbone areas are configured as totally NSSAs, the routing table size of routers in non-backbone areas are reduced significantly and the amount of information exchanged between these routers is also reduced. Consider how to achieve the same purpose in the backbone area. That is, use IP subnetting and perform route summarization on ABRs in non-backbone areas.

Figure 6-62 shows summarized routes advertised from Area 10 to Area 0 after IP subnetting is performed.

Figure 6-62  Using route summarization to optimize routing entries in the backbone area

Route summarization will prevent specific routes from being advertised. The ABR in Area 10 advertises only one summarized route 10.10.0.0/16 into Area 0, reducing the routing entries on the backbone router and number of OSPF packets exchanged with Area 0 and ensuring routing table stability. To facilitate route summarization, proper IP addressing is recommended during OSPF network design.

The following example configures route summarization on the ABR (core switch cluster) in Area 10.

[HUAWEI] ospf 1  //Enter the OSPF process view.
[HUAWEI-ospf-1] area 10  //Enter the view of Area 10.
[HUAWEI-ospf-1-area-0.0.0.10] abr-summary 10.10.0.0 255.255.0.0  //Summarize routes on the ABR.
[HUAWEI-ospf-1-area-0.0.0.10] quit
NOTE:

The abr-summary command can only be configured on an ABR. Do not configure this command on non-ABR routers in an area. Otherwise, incorrect routing entries will be generated.

Before routes are summarized, the IP routing table of NE40E-1 is as follows:

<NE40E-1> display ip routing-table
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Tables: Public
         Destinations : 12        Routes : 12        

Destination/Mask    Proto   Pre  Cost      Flags NextHop         Interface

      10.0.0.1/32   Direct  0    0           D   127.0.0.1       LoopBack0
     10.10.1.0/24   OSPF    10   3           D   10.200.10.2     GigabitEthernet0/0/1
     10.10.2.0/24   OSPF    10   3           D   10.200.10.2     GigabitEthernet0/0/1
     10.10.3.0/24   OSPF    10   3           D   10.200.10.2     GigabitEthernet0/0/1

After routes are summarized, the IP routing table of NE40E-1 is as follows:

<NE40E-1> display ip routing-table
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Tables: Public
         Destinations : 12        Routes : 12        

Destination/Mask    Proto   Pre  Cost      Flags NextHop         Interface

      10.0.0.1/32   Direct  0    0           D   127.0.0.1       LoopBack0
     10.10.0.0/16   OSPF    10   3           D   10.200.10.2     GigabitEthernet0/0/1

The preceding outputs show that NE40E-1 in the backbone area has specific routes to users' network segments before routes are summarized. After route summarization is configured on the ABR, NE40E-1 has only one summarized route with the 16-bit mask to users' network segments. If there are many user network segments, route summarization can significantly reduce routing entries in the backbone areas, decrease the number of LSAs exchanged between the backbone and non-backbone areas, and improve network stability.

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

Most traffic of a campus network is destined for the Internet. Therefore, on a campus network with multiple egresses, you must consider importing default routes and load balancing traffic among these egresses.

Multiple methods are available to import default routes. The recommended method is to configure non-forcible delivery of default routes on an ABR. Non-forcible delivery of default routes indicates that the default route can be advertised only when it exists in the IP routing table of this ABR. This prevents loops and suboptimal routes in special scenarios.

In this case, after two ABRs advertise the default route, the core switch cluster receives two default routes with their next hops pointing to two egress routers respectively. The core switch cluster can choose one link as the uplink or two uplinks for load balancing. You can flexibly configure traffic direction based on network requirements. Figure 6-63 shows uplink traffic direction using default routes on the core switch cluster.

Figure 6-63  Using default routes for uplink traffic direction on the core switch cluster

The following example configures non-forcible delivery of default routes on NE40E-1. The configuration of NE40E-2 is similar to that of NE40E-1.

[NE40E-1] ip route-static 0.0.0.0 0.0.0.0 202.10.10.1  //On NE40E-1, configure a default route with the next hop pointing to the public address of the telecom carrier.
[NE40E-1] ospf 1  //Enter the OSPF process view.
[NE40E-1-ospf-1] default-route-advertise  //Advertise the default route without specifying the always parameter. That is, the default route is delivered non-forcibly.

After the preceding configurations are complete, the core switch cluster learns two equal-cost default routes. Uplink traffic of the core switch cluster will be forwarded in load balancing mode.

<HUAWEI> display ip routing-table
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Tables: Public
         Destinations : 23        Routes : 24        

Destination/Mask    Proto   Pre  Cost      Flags NextHop         Interface

      0.0.0.0/0     O_ASE   150  1           D   10.200.10.1     Vlanif40
                    O_ASE   150  1           D   10.200.20.1     Vlanif50
......

If you want two uplinks of the core switch cluster work in active/standby mode, the simplest method is to change their OSPF costs. In this situation, uplink traffic is first sent to NE40E-1. If NE40E-1 is faulty, the traffic is automatically switched to NE40E-2.

To implement route backup, change the OSPF cost of the link from the core switch cluster to NE40-2 to be higher than that of the link from the cluster to NE40-1.

Configure the core switch cluster.

[HUAWEI] interface vlanif 50  //Enter the OSPF interface view.
[HUAWEI-Vlanif50] ospf cost 10  //Change the OSPF cost of this interface to 10.

Configure NE40E-2.

[NE40E-2] interface gigabitethernet 0/0/1  //Enter the OSPF interface view.
[NE40E-2-GigabitEthernet0/0/1] ospf cost 10  //Change the OSPF cost of this interface to 10.
NOTE:

To adjust the link cost to affect OSPF route selection, you need to adjust the cost on the devices on both ends of this link. Otherwise, asymmetric routing occurs, which results in network faults.

The OSPF cost of links providing more than 100M bandwidth is 1 by default. After the OSPF cost of the link from the core switch cluster to NE40-2 is changed to 10, the cluster transmits its uplink traffic over the link from itself to NE40-1. The IP routing table of the cluster has only one default route pointing to NE40E-1.

<HUAWEI> display ip routing-table
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Tables: Public
         Destinations : 23        Routes : 23        

Destination/Mask    Proto   Pre  Cost      Flags NextHop         Interface

      0.0.0.0/0     O_ASE   150  1           D   10.200.10.1     Vlanif40
......

Loop Prevention in Route Summarization Scenarios: Blackhole Route

After the preceding design and deployment, this campus network has basic OSPF functions and routing entries have been optimized. However, this network has the risk of loops because route summarization may easily cause loops.

It is common that a campus network is under internal network attacks. Assume that a host in Building 1 is attacked by viruses, which will make the host access all IP addresses on the network segment 10.0.0.0. In this situation, a loop may easily occur.

If the host accesses the IP address 10.10.50.1 (this address does not exist in Building 1), a routing loop occurs:

  1. When the host sends a packet, the packet is sent to its gateway, namely, aggregation switch cluster 1 of Building 1.

  2. Aggregation switch cluster 1 does not have specific routes to the destination address of this packet, so sends this packet to the core switch cluster through a default route.

  3. The IP address 10.10.50.1 does not exist on this campus network. Therefore, after the packet reaches the core switch cluster, it matches only a default route and then is sent to NE40E-1.

  4. The route learned by NE40E-1 is summarized and then advertised by the core switch cluster, so the packet matches the route 10.10.0.0/16 and is sent back to the core switch cluster.

A routing loop occurs between the core switch cluster and NE40E-1, as shown in Figure 6-64. This loop will seriously affect network operation and even cause network crash. Therefore, you need to avoid routing loops in route summarization scenarios.

Figure 6-64  Routing loop

The main reason for this routing loop is that the core switch cluster uses a default route to forward a packet with a destination address that does not exist in the campus network to the backbone area, and the backbone area sends the packet back to the cluster through a summarized return route.

To address this problem, configure a blackhole route on the core switch cluster to block such a packet. Perform the following configuration:

[HUAWEI] ip route-static 10.10.0.0 255.255.0.0 NULL0

After a blackhole route is configured, the packet to be returned to the network segment 10.10.0.0 will be directed to the user network segment through a specific route. If such specific route cannot be found, this host address does not exist in the campus network. The packet will match this blackhole route and be dropped to prevent routing loops. When configuring route summarization in other areas, you also need to configure a blackhole route to prevent routing loops.

OSPF Network Security: Silent Interface

After the preceding deployment is completed, the entire OSPF network can run properly. However, this network has a large security vulnerability. That is, user-side interfaces can receive OSPF Hello packets, so basic network information can be easily obtained through a network sniffing tool for launching attacks.

To ensure OSPF network security, you are advised to configure silent interfaces to block OSPF packets sent to users, as shown in Figure 6-65.

Figure 6-65  Configuring silent interfaces to block OSPF packets sent to users

The following example configures silent interfaces in the core switch cluster 1 in Area 10.

[HUAWEI] ospf 1
[HUAWEI-ospf-1] silent-interface vlanif100
[HUAWEI-ospf-1] silent-interface vlanif200
[HUAWEI-ospf-1] silent-interface vlanif300
NOTE:

The silent-interface command prohibits specified interfaces from receiving and sending OSPF packets and is typically configured on user-side interfaces. Configuring this command on the link between two OSPF routers will cause a failure to establish an OSPF neighbor relationship between the two routers.

Translation
Download
Updated: 2019-10-21

Document ID: EDOC1000178171

Views: 315394

Downloads: 1112

Average rating:
This Document Applies to these Products
Related Version
Related Documents
Share
Previous Next