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 Routing 01

NE05E and NE08E V300R003C10SPC500

This is NE05E and NE08E V300R003C10SPC500 Configuration Guide - IP Routing
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).
Configuring a BGP Route Reflector

Configuring a BGP Route Reflector

By configuring a BGP route reflector (RR), you can avoid fully meshed connections between multiple IBGP peers.

Usage Scenario

Fully meshed connections need to be established between IBGP peers to ensure the connectivity between IBGP peers. If there are n routers in an AS, n x (n-1)/2 IBGP connections need to be established. When there are a lot of IBGP peers, network resources and CPU resources are greatly consumed. Route reflection can solve the problem.

RRs can reduce the total number of IBGP connections. On a large network, to reduce the number of clients of each route reflector, you need to configure multiple RRs. Because fully meshed connections need to be established between RRs, there are still a large number of IBGP connections on the network. In this situation, configure hierarchical RRs to further reduce the number of IBGP connections.

Figure 10-5 shows typical networking with hierarchical RRs. In this networking, R1, R2, R3, and R4 function as Level-1 RRs; R5, R6, R7, and R8 function as level-2 RRs and the clients of level-1 RRs. Level-1 RRs are not the clients of any RR and must be fully meshed. Level-2 RRs function as the clients of Level-1 RRs and do not need to be fully meshed.

Figure 10-5 Typical networking with hierarchical RRs

Pre-configuration Tasks

Before configuring a BGP route reflector, configure basic BGP functions.

Configuration Procedures

Figure 10-6 Flowchart for configuring a BGP route reflector

Configuring a Route Reflector and Specifying Clients

RRs can reflect routes between clients, and clients do no need to establish IBGP connections.

Context

In an AS, one NE functions as an RR, the other NEs function as clients. IBGP connections are established between the RR and its clients. The RR and its clients form a cluster. The RR transmits (or reflects) routes between clients, and clients do not need to establish IBGP connections.

An RR simplifies configurations because all configurations need to be configured only on the RR and clients do not need to know that they are clients.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run bgp as-number

    The BGP view is displayed.

  3. Run ipv4-family unicast

    The IPv4 unicast address family view is displayed.

  4. Run peer { ipv4-address | group-name } reflect-client

    An RR and its client are configured.

    The NE on which the peer reflect-client command is run serves as the RR, and the specified peer or peer group functions as a client.

    NOTE:

    The configurations of RRs and clients in an address family are valid only in this address family and cannot be inherited by other address families. Therefore, configure RRs and clients in the required address family.

  5. Run commit

    The configuration is committed.

(Optional) Disabling Route Reflection Between Clients Through the RR

If the clients of a route reflector are fully connected, you need to disable route reflection among them through the RR to reduce bandwidth consumption.

Context

On some networks, if fully meshed IBGP connections have been established between clients, they can directly exchange routing information. Therefore, route reflection between clients through the RR is unnecessary, which also occupies bandwidth. In this case, disable route reflection among them through the RR.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run bgp as-number

    The BGP view is displayed.

  3. Run ipv4-family unicast

    The IPv4 unicast address family view is displayed.

  4. Run undo reflect between-clients

    Route reflection is disabled among clients through the RR.

    By default, route reflection among clients through the RR is enabled.

    If the clients of the route reflector are fully connected, you can use the undo reflect between-clients command to disable route reflection among the clients through the RR. This command is applicable to only the route reflector.

  5. Run commit

    The configuration is committed.

(Optional) Setting the Cluster ID of a Route Reflector

When there are multiple route reflectors in a cluster, you need to configure the same cluster ID for all the route reflectors in this cluster to avoid routing loops.

Context

To enhance network reliability and avoid single points of failure, more than one route reflector can be configured in a cluster. In this case, you need to set the same cluster ID for all the route reflectors in the same cluster. This can reduce the number of routes to be received by each route reflector and save the memory.

NOTE:

To ensure that a client can learn the routes reflected by a route reflector, the cluster ID of the route reflector must be different from the router ID of the client. If they are the same, the client discards the received routes.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run bgp as-number

    The BGP view is displayed.

  3. Run ipv4-family unicast

    The IPv4 unicast address family view is displayed.

  4. Run reflector cluster-id cluster-id

    The cluster ID of a route reflector is set.

    When there are multiple route reflectors in a cluster, you need to run the command to configure the same cluster-id for all the route reflectors in this cluster.

    The reflector cluster-id command can be configured on only route reflectors.

  5. Run commit

    The configuration is committed.

(Optional) Preventing a Device from Adding BGP Routes to the IP Routing Table

After you prevent an RR from adding BGP routes to the IP routing table, the RR no longer forwards traffic, which improves route advertisement efficiency.

Context

In most cases, BGP routes are added to the IP routing table of the NE for traffic forwarding. If the NE does not need to forward traffic, prevent it from adding BGP routes to the IP routing table.

RRs need to be prevented from adding BGP routes to the IP routing table. An RR no only transmits routes but also forwards traffic. If the RR is connected to many clients and non-clients, the route transmission task will consume a lot of CPU resources of the RR, and as a result, the RR cannot forward traffic. To improve the route transmission efficiency, prevent the RR from adding BGP routes to the IP routing table so that the RR only transmits routes.

Perform the following steps on the NE that runs BGP:

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run bgp as-number

    The BGP view is displayed.

  3. Run ipv4-family unicast

    The IPv4 unicast address family view is displayed.

  4. Run routing-table rib-only [ route-policy route-policy-name | route-filter route-filter-name ]

    The device is prevented from adding BGP routes to the IP routing table.

    By default, optimal BGP routes are added to the IP routing table.

    If route-policy route-policy-name or route-filter route-filter-name is configured in the routing-table rib-only command, routes matching the policy are not added to the IP routing table, and routes that do not match the policy are added to the IP routing table, with the route attributes unchanged.

    NOTE:

    The routing-table rib-only command and the active-route-advertise command are mutually exclusive.

  5. Run commit

    The configuration is committed.

(Optional) Enabling an RR to Modify Route Attributes Using an Export Policy

You can enable an RR to modify route attributes using an export policy to control BGP route selection.

Context

The route attributes on an RR cannot be modified using an export policy. This is because it may cause route loops. By default, the RR is disabled from modifying the route attributes using an export policy. But if you need to re-plan the network traffic, you can enable the RR to modify the route attributes using an export policy.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run bgp as-number

    The BGP view is displayed.

  3. Run ipv4-family unicast

    The IPv4 unicast address family view is displayed.

  4. Run reflect change-path-attribute

    You can enable the RR to modify BGP route attributes using an export policy.

    By default, you can disable the RR from modifying route attributes using an export policy.

    After you enable the reflect change-path-attribute command on an RR, the configurations of the RR attributes modified using the export policy takes effect immediately. Perform the following operations:
    • Run the apply as-path command to modify the AS-Path attributes of BGP routes.
    • Run the apply comm-filter delete command to delete all community attributes from a BGP route.
    • Run the apply community command modifies the community attributes of BGP routes.
    • Run the apply cost command to modify the cost of BGP routes, that is, to modify its MED.
    • Run the apply ip-address nexthop command to modify the next hop of the BGP routes.
    • Run the apply local-preference command to modify the local preference of BGP routes.
    • Run the apply origin command to modify the Origin attributes of BGP routes.
    • Run the apply extcommunity command to modify the VPN-Target extended community attributes of BGP routes.
    • Run the apply extcommunity soo { Site-of-origin &<1-16> } additive command to modify the SoO extended community attributes of BGP routes.
    NOTE:

    After the reflect change-path-attribute command is run on the RR, the peer route-policy export command takes precedence over the peer next-hop-invariable and peer next-hop-local commands.

  5. Run commit

    The configuration is committed.

Verifying the BGP Route Reflector Configuration

After configuring a BGP route reflector, verify information about BGP routes and BGP peer groups.

Prerequisites

A BGP route reflector has been configured.

Procedure

  • Run the display bgp group [ group-name ] command to check information about BGP peer groups.
  • Run the display bgp routing-table [ network ] [ mask | mask-length ] [ longer-prefixes ] command to check information about the BGP routing table.

Example

Run the display bgp routing-table [ network ] command to view information about the BGP routing table.

<HUAWEI> display bgp routing-table 10.1.1.0
BGP local router ID : 4.4.4.4
 Local AS number : 65010
 Paths:   1 available, 0 best, 0 select
 BGP routing table entry information of 10.1.1.0/24:
 From: 10.1.4.1 (2.2.2.2)
 Route Duration: 00h00m14s
 Relay IP Nexthop: 0.0.0.0
 Relay IP Out-Interface:
 Original nexthop: 10.1.1.2
 Qos information : 0x0
 AS-path Nil, origin igp, MED 0, localpref 100, pref-val 0, internal, pre 255
 Originator:  1.1.1.1
 Cluster list: 0.0.0.1
 Not advertised to any peer yet
Translation
Download
Updated: 2019-01-14

Document ID: EDOC1100058916

Views: 34103

Downloads: 49

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