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 Examples for NE and ME60 Routers in Typical Enterprise Scenarios 2.0

This document provides NE series routers typical 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).
Example for Configuring Route-Policies to Control Traffic Scheduling in an IGW Scenario

Example for Configuring Route-Policies to Control Traffic Scheduling in an IGW Scenario

This section provides an example for configuring route-policies to implement proper scheduling on upstream and downstream traffic in an international gateway (IGW) scenario.

Applicable Products and Versions

Table 1-39 lists the applicable products and software versions of this solution.

Table 1-39  Applicable products and versions

Product Name

Software Version

CE12800

V200R005C00 or later

NE40E

V800R010C10 or later

Networking Requirements

NOTE:

In this solution, each NE40E functions as an IGW and implements scheduling on upstream and downstream traffic. This solution is applicable to large-scale IGW scenarios.

A carrier needs to build an IGW network, as shown in Figure 1-31. The networking requirements are as follows:

  • The old network includes only IPv4 users, not IPv6 users. These IPv4 users access devices of different tire-1 carriers. An E2E national backbone network needs to be set up. All services on the old network will be migrated to the new network. According to the planning, the new network uses the private network AS 65002 to carry services such as HSI, IMS, IPTV, CDMA, NGBSS, and video surveillance services. Internet services need to be available to both IPv4 and IPv4/IPv6 dual-stack users.
  • It is required that network configurations be optimized based on the traffic of access users so that traffic distribution and utilization of downstream links are more clear and proper and upstream links balance traffic.
  • In addition, high reliability needs to be ensured for the Internet traffic and the traffic between master and backup IGWs.
Figure 1-31  Networking diagram for an IGW scenario

Configuration Roadmap

  • Set up a 10 Gbit/s direct link between the IGWs of city A and city B for inter-city traffic forwarding and Internet route protection.

  • Set up a 10 Gbit/s Layer 2 direct link between the switches of city A and city B. Establish an OSPF neighbor relationship between the IGWs over a 1 Gbit/s link. (The 1 Gbit/s link is used as a backup of the 10 Gbit/s direct link to protect traffic between city A and city B.)

  • Configure the two IGWs as RRs in the same cluster and establish IBGP peer relationships between the two IGWs and access routers on the old network. The IGWs identify the location of each access router and implement route control based on the community attribute carried in the routes advertised by the access router.

  • Connect the IGW of each city on the old network to the Ps of the same city on the new network through a 10 Gbit/s link and establish an EBGP peer relationship over the link. Configure both IPv4 and IPv6 on Ps.

  • Configure Ps on the new network to add planned community attributes to the routes to be advertised to the IGWs for the IGWs to identify the location of each P. Configure a route-policy for each IGW to replace the private network AS 65002 with the public network AS number when the IGW sends network segment routes of the new network to the old network and the Internet.

NOTE:

The following describes how to configure the NE40E. For configuration details about other devices, see their product documentation.

Initial Configuration

Logging In to a Device for the First time

For details, see "Logging In to a Device for the First Time" in "Typical Configuration Cases."

Configuring Remote Login

You can remotely log in to a device through Telnet or SSH. Telnet has security risks. SSH, which is more secure, is recommended.

For details, see "Using STelnet (SSH) to Remotely Log In to a Device" in "Typical Configuration Cases."

Setting a Device Name

Configure a specific name for each device to facilitate identification during login. For example, name a device "NE40E".

#
sysname NE40E
#

Configuring IP Addresses for Interfaces

In this example, the IP address 172.16.11.6/30 is set for GE 1/0/1 on the NE40E.

#
interface GigabitEthernet1/0/1
 undo shutDown
 ip address 172.16.11.6 255.255.255.252       //Configure an IP address for the interface.
#

The configuration of other IP addresses is similar to the configuration of this IP address.

Connecting the IGW in Each City on the Old Network to the Ps in the Same City on the New Network

To facilitate description of the interconnection, Figure 1-31 is simplified as Figure 1-32.
Figure 1-32  IGW-P interconnection

In Figure 1-32, IGW1 of the old network, and P1 and P2 of the new network are located in city A; IGW2 of the old network, and P3 and P4 of the new network are located in city B. On the new IP core network, all services are encapsulated in a VPN for forwarding. In city A and city B, each P is connected to a BRAS to provide Internet services.

On each P, set IP prefix lists to allow HSI public network addresses to be advertised to IGWs. Configure route-policies on each P to control the costs of advertised EBGP address segment routes so that each IGW preferentially selects itself to divert traffic to address segments of the local city. Configure each P to set an EBGP cost for the IP address segment of another P in the same city and a different EBGP cost for the IP address segments of the Ps in another city to provide route protection.

Use route-policies to configure each P to add a community attribute in the routes to be advertised to IGWs for location identification. Based on the community attributes, IGWs use route-policies to control routes for the traffic from the Internet. Configure a route-policy on each P so that the P accepts only the default routes from IGWs to reduce the number of public network routes in the routing table of the P.

P3 is used as an example, and its configurations are as follows:

#
ip ip-prefix P1-BRAS1-HSI index 10 permit 10.1.1.0 23
ip ip-prefix P2-BRAS2-HSI index 10 permit 10.1.2.0 23
ip ip-prefix P3-BRAS3-HSI index 10 permit 10.1.3.0 23
ip ip-prefix P4-BRAS4-HSI index 10 permit 10.1.4.0 23
ip ip-prefix default index 10 permit 0.0.0.0 0
ip ipv6-prefix P1-BRAS1-IPv6 index 10 permit 2001:db8:11:: 49 greater-equal 49 less-equal 128
ip ipv6-prefix P2-BRAS2-IPv6 index 10 permit 2001:db8:12:: 49 greater-equal 49 less-equal 128
ip ipv6-prefix P3-BRAS3-IPv6 index 10 permit 2001:db8:13:: 49 greater-equal 49 less-equal 128
ip ipv6-prefix P4-BRAS4-IPv6 index 10 permit 2001:db8:14:: 49 greater-equal 49 less-equal 128
ip ipv6-prefix default index 10 permit :: 0
#
route-policy default_in permit node 10
 if-match ip-prefix default
#
route-policy ipv6_default_in permit node 10
 if-match ipv6 address prefix-list default
#
route-policy to_igw permit node 10
 if-match ip-prefix P3-BRAS3-HSI
 apply community 100:3000        //AS 100 is a public-network AS.
#
route-policy to_igw permit node 20
 if-match ip-prefix P4-BRAS4-HSI
 apply community 100:3000
#
route-policy to_igw permit node 30
 if-match ip-prefix P1-BRAS1-HSI
 apply cost 100
 apply community 100:3001
#
route-policy to_igw permit node 40
 if-match ip-prefix P2-BRAS2-HSI
 apply cost 200
 apply community 100:3001
#
route-policy to_igw_ipv6 permit node 10
 if-match ipv6 address prefix-list P3-BRAS3-IPv6
 apply cost 100
 apply community 100:4000
#
route-policy to_igw_ipv6 permit node 20
 if-match ipv6 address prefix-list P4-BRAS4-IPv6
 apply cost 200
 apply community 100:4000
#
route-policy to_igw_ipv6 permit node 30
 if-match ipv6 address prefix-list P1-BRAS1-IPv6
 apply cost 300
 apply community 100:4001
#
route-policy to_igw_ipv6 permit node 40
 if-match ipv6 address prefix-list P2-BRAS2-IPv6
 apply cost 400
 apply community 100:4001
#
bgp 65002
 #
 ipv4-family vpn-instance HSI
  import-route ospf 1        //Connect each P to a BRAS through OSPF and import the routes of the BRAS.
  peer 10.1.5.1 as-number 100
  peer 10.1.5.1 description to IGW2
  peer 10.1.5.1 route-policy default_in import
  peer 10.1.5.1 route-policy to_igw export
  peer 10.1.5.1 advertise-community
#
 ipv6-family vpn-instance HSI
  import-route ospfv3 1      //Connect each P to a BRAS through OSPFv3 and import the routes of the BRAS.
  peer 2001:db8:205::2 as-number 100
  peer 2001:db8:205::2 description to IGW2
  peer 2001:db8:205::2 route-policy ipv6_default_in import
  peer 2001:db8:205::2 route-policy to_igw_ipv6 export
  peer 2001:db8:205::2 advertise-community

Connecting the IGWs to Access Routers on the Old Network

Figure 1-33 shows the simplified networking diagram of the old network. The key points for configuring the interconnection between the IGW and access routers on the old network are as follows:
  • Use 10 Gbit/s interfaces to connect each IGW to the corresponding switch, and use OSPF and IBGP to connect each IGW to access routers. Configure each IGW as an OSPF DR and IBGP RR.
  • Use 10 Gbit/s interfaces to connect the IGWs, and configure OSPF and IBGP on the interfaces for inter-city traffic forwarding and Internet route protection.
  • Use 10 Gbit/s interfaces to connect the switches.
  • Use 1 Gbit/s interfaces of the IGWs to implement OSPF interconnection through the switches. The 1 Gbit/s link functions as a backup of the 10 Gbit/s link between the IGWs. If the 10 Gbit/s link fails, inter-city traffic is forwarded through the 1 Gbit/s link.
  • Create a sub-interface on the upstream link of each access router in each city and use the sub-interface to implement OSPF interconnection with the IGW in the other city through the switch (working in Layer 2 mode) in the local city. Establish an IBGP connection between each access router and the IGW in the same city. Configure each access router to add a community attribute to the IBGP routes to be advertised. The community attribute is used to identify the location of each access router.
  • Configure each IGW to advertise default routes through OSPF so that Internet access traffic of users on the access routers supporting OSPF rather than IBGP can be forwarded.
  • Configure each IGW to advertise default routes through IBGP so that Internet access traffic of users on the access routers can be forwarded.
  • Configure a route-policy for each IGW to replace the private network AS number in the user address segment routes of the new network with the public network AS number before the IGW advertises the routes.
Figure 1-33  Connecting the IGWs to Access Routers on the Old Network

IGW1 is used as an example, and its configurations are as follows:

#
interface GigabitEthernet1/0/1
 description to IGW2 GE1/0/1
 undo shutDown
 ipv6 enable
 ip address 10.200.5.1 255.255.255.252
 ipv6 address 2001:db8:205::1/126
 ospfv3 1 area 0.0.0.0
 ospf v3 cost 10
 ospf authentication-mode md5 1 cipher Huawei@123
 ospf cost 10
#
interface GigabitEthernet1/1/0
 negotiation auto
 description to Switch for connect IGW2
 undo shutDown
 ip address 10.201.5.1 255.255.255.252
 ipv6 address 2001:db8:209::1/126
 ospfv3 1 area 0.0.0.0
 ospfv3 cost 20         //OSPFv3 backup link
 ospf authentication-mode md5 1 cipher Huawei@123
 ospf cost 20           //OSPF backup link
#
interface GigabitEthernet2/0/1
 description to Switch for connect cityA
 undo shutDown
 set flow-stat interval 30
 ip address 10.201.6.1 255.255.255.192
 ospf authentication-mode md5 1 cipher Huawei@123
 ospf dr-priority 255    //OSPF DR
 ospf cost 10
#
interface GigabitEthernet2/0/1.10
 vlan-type dot1q 10
 description to Switch for connect cityB
 undo shutDown
 set flow-stat interval 30
 ip address 10.201.7.1 255.255.255.192
 ospf authentication-mode md5 1 cipher Huawei@123
 ospf dr-priority 255
 ospf cost 15
#
interface LoopBack0
 ip address 1.1.1.1 255.255.255.255
#
ospf 1 router-id 1.1.1.1
 default-route-advertise
 import-route static
 area 0.0.0.0
  network 10.200.5.0 0.0.0.3
  network 10.201.5.0 0.0.0.3
  network 10.201.6.0 0.0.0.63
  network 10.201.7.0 0.0.0.63
  network 1.1.1.1 0.0.0.0
#
ospfv3 1
 router-id 1.1.1.1
#
bgp 100
router-id 1.1.1.1
 peer 2.2.2.2 as-number 100
 peer 2.2.2.2 description to IGW2
 peer 2.2.2.2 connect-interface LoopBack0
 peer 2001:db8:209::1 as-number 100
 peer 2001:db8:209::1 description to IGW2
 peer 2001:db8:209::1 connect-interface LoopBack0
 group abc internal          //Add Old 1, Old 2, Old 3, and Old 4 to an IBGP peer group.
 peer abc connect-interface LoopBack0
 peer 3.3.3.3 as-number 100
 peer 3.3.3.3 group abc
 peer 4.4.4.4 as-number 100
 peer 4.4.4.4 group abc
 peer 5.5.5.5 as-number 100
 peer 5.5.5.5 group abc
 peer 6.6.6.6 as-number 100
 peer 6.6.6.6 group abc
 #
 ipv4-family unicast
  reflector cluster-id 1         //Configure the device as an RR.
  network 0.0.0.0         //Import the default route.
  peer 2.2.2.2 enable
  peer 2.2.2.2 next-hop-local
  peer 2.2.2.2 advertise-community
  peer 2.2.2.2 advertise-ext-community
  peer 2.2.2.2 keep-all-routes
  peer abc enable
  peer abc route-policy To-old export
  peer abc reflect-client
  peer abc next-hop-local
  peer abc advertise-community
  peer abc advertise-ext-community
  peer abc keep-all-routes  
  peer 3.3.3.3 enable
  peer 3.3.3.3 group abc          //Add Old 1 to the IBGP peer group abc.
  peer 4.4.4.4 enable
  peer 4.4.4.4 group abc          //Add Old 2 to the IBGP peer group abc. 
  peer 5.5.5.5 enable
  peer 5.5.5.5 group abc          //Add Old 3 to the IBGP peer group abc.
  peer 6.6.6.6 enable
  peer 6.6.6.6 group abc          //Add Old 4 to the IBGP peer group abc. 
 #
 ipv6-family unicast  
  peer 2001:db8:209::1 enable
  peer 2001:db8:209::1 route-policy To-old export
  peer 2001:db8:209::1 next-hop-local
  peer 2001:db8:209::1 advertise-community
  peer 2001:db8:209::1 advertise-ext-community  
#  
ip as-path-filter To-old-1 permit _65002       //Match the routes with AS 65002.
ip as-path-filter To-old-2 permit .*       //Match the routes without AS 65002.
#
route-policy To-old permit node 10
 if-match as-path-filter To-old-1
 apply as-path 100 overwrite       //Replace AS 65002 with the public-network AS number.
#
route-policy To-old permit node 20
 if-match as-path-filter To-old-2
#

Internet Link Design

The downstream traffic of Internet users is much heavier than the upstream traffic in AS 100. The Internet link design has the following two key points:
  1. In the downstream direction: The two IGWs are the main entrance of AS 100 to the Internet and carry traffic of a large number of users. In peak hours, the two IGWs are fully loaded. Therefore, you need to properly plan the incoming traffic of the two IGWs so that traffic distribution and utilization of downstream links are more clear and proper.
  2. In the upstream direction: If the two IGWs receive the Internet routes on the entire network and query an outbound interface for the upstream traffic based on the destination of each route, most upstream traffic may be distributed to one external link. In this case, this link is heavily loaded or even overloaded, whereas other links are idle. Therefore, you need to properly plan upstream traffic to ensure load balancing.

Downstream Link Design

To meet the preceding requirements, you need to properly plan IP prefix lists and route-policies for the IGWs. Figure 1-34 shows the final traffic model.

Figure 1-34  Internet Downstream Link Design
The design is as follows:
  • Currently, only carrier A’s links support IPv6. All ADSL users will be migrated gradually to the new network. All the address segments of ADSL and new-network users are sent to carrier A.
  • For government and enterprise customers, the total bandwidth required is 200 Mbit/s, and all their traffic is transmitted through carrier B’s links.
  • For small ISP customers, the total bandwidth required is 200 Mbit/s, and all their traffic is transmitted through carrier C’s links.
  • CDMA services are key services and will increase continuously. In this case, carrier D’s links are exclusively allocated for CDMA services.

For users of the new network, configure route-policies on the IGWs to replace the private network AS number with the public network AS number. To prevent the IGWs from becoming the transit network of the tire-1 carriers, configure AS_Path filters for the EBGP connections between the IGWs and the devices of the tire-1 carriers.

IGW1 is used as an example, and its configurations are as follows:

//Configure AS_Path filterS to filter the routes of tire-1 carriers and prevent the IGWs from becoming the transit network of the carriers.
#
ip as-path-filter To-other deny ^1000_   //CarrierA
ip as-path-filter To-other deny ^1001_   //CarrierB
ip as-path-filter To-other deny ^1002_   //CarrierC
ip as-path-filter To-other deny ^1003_   //CarrierD
ip as-path-filter To-other permit .*
#
//Configure an IP prefix list for carrier B to match the address prefixes of government and enterprise users.
#
ip ip-prefix To-CarrierB index 1 permit 10.40.1.0 24
ip ip-prefix To-CarrierB index 2 permit 10.40.2.0 24
......
ip ip-prefix To-CarrierB index n permit 10.40.n.0 24
#
//Configure an IP prefix list for carrier C to match the address prefixes of ISP users.
#
ip ip-prefix To-CarrierC index 1 permit 10.50.1.0 24
ip ip-prefix To-CarrierC index 2 permit 10.50.2.0 24
......
ip ip-prefix To-CarrierC index n permit 10.50.n.0 24
#
//Configure an IP prefix list for carrier D to match the address prefixes of CDMA users.
#
ip ip-prefix To-CarrierD index 1 permit 10.60.1.0 24
ip ip-prefix To-CarrierD index 2 permit 10.60.2.0 24
......
ip ip-prefix To-CarrierD index n permit 10.60.n.0 24
#
//Configure an IP prefix list for carrier A to match the address prefixes of ADSL and new users.
#
ip ip-prefix To-CarrierA index 1 permit 10.30.1.0 24
ip ip-prefix To-CarrierA index 2 permit 10.30.2.0 24
......
ip ip-prefix To-CarrierA index n permit 10.30.n.0 24
#
//Configure an IPv6 prefix list for carrier A to match the address prefixes of IPv6 users.
#
ip ipv6-prefix To-CarrierA-IPv6 index 1 permit 2001:db8:205:: 48
ip ipv6-prefix To-CarrierA-IPv6 index 2 permit 2001:db8:206:: 48
......
ip ipv6-prefix To-CarrierA-IPv6 index n permit permit 2001:db8:209:: 48
#
//Configure IP prefix lists for the new network.
#
ip ip-prefix P3-NEW-IP index 10 permit 10.1.1.0 23
ip ip-prefix P4-NEW-IP index 10 permit 10.1.2.0 23
ip ip-prefix P1-NEW-IP index 10 permit 10.1.3.0 23
ip ip-prefix P2-NEW-IP index 10 permit 10.1.4.0 23
#
ip ipv6-prefix P3-NEW-IPv6 index 1 permit 2001:db8:11:: 48
ip ipv6-prefix P4-NEW-IPv6 index 1 permit 2001:db8:12:: 48
ip ipv6-prefix P1-NEW-IPv6 index 1 permit 2001:db8:13:: 48
ip ipv6-prefix P2-NEW-IPv6 index 1 permit 2001:db8:14:: 48
#
//Configure route-policies.
#
route-policy To-CarrierB permit node 10
 if-match ip-prefix To-CarrierB
#
route-policy To-CarrierC permit node 10
 if-match ip-prefix To-CarrierC
#
route-policy To-CarrierD permit node 10
 if-match ip-prefix To-CarrierD
#
route-policy To-CarrierA permit node 10
 if-match ip-prefix To-CarrierA
#
route-policy To-CarrierA permit node 70
 if-match ip-prefix P3-NEW-IP       //Advertise IP prefixes of the new network to carrier A.
#
route-policy To-CarrierA permit node 80
 if-match ip-prefix P4-NEW-IP       //Advertise IP prefixes of the new network to carrier A.
#
route-policy To-CarrierA-IPv6 permit node 10
 if-match ipv6 address prefix-list To-CarrierA-IPv6
#
route-policy To-CarrierA-IPv6 permit node 20
 if-match ipv6 address prefix-list P3-NEW-IPv6
#
route-policy To-CarrierA-IPv6 permit node 30
 if-match ipv6 address prefix-list P4-NEW-IPv6
#
//Configure BGP.
#
bgp 100
 peer 172.16.22.22 as-number 1001
 peer 172.16.22.22 description to CarrierB
 peer 172.16.33.33 as-number 1003
 peer 172.16.33.33 description to CarrierC
 peer 172.16.44.44 as-number 1003
 peer 172.16.44.44 description to CarrierD
 peer 172.16.11.11 as-number 1000
 peer 172.16.11.11 description to CarrierA
 peer 2001:db8:1b::1 as-number 1000
 peer 2001:db8:1b::1 description to CarrierA
 #
 ipv4-family unicast
  maximum load-balancing 5
  peer 172.16.22.22 enable
  peer 172.16.22.22 public-as-only        //Replace the private-network AS number.
  peer 172.16.22.22 as-path-filter To-other export
  peer 172.16.22.22 route-policy To-CarrierB export
  peer 172.16.22.22 keep-all-routes
  peer 172.16.33.33 enable
  peer 172.16.33.33 public-as-only
  peer 172.16.33.33 as-path-filter To-other export
  peer 172.16.33.33 route-policy To-CarrierC export
  peer 172.16.33.33 keep-all-routes
  peer 172.16.44.44 enable
  peer 172.16.44.44 public-as-only
  peer 172.16.44.44 as-path-filter To-other export
  peer 172.16.44.44 route-policy To-CarrierD export
  peer 172.16.44.44 keep-all-routes
  peer 172.16.11.11 enable
  peer 172.16.11.11 public-as-only
  peer 172.16.11.11 as-path-filter To-other export
  peer 172.16.11.11 route-policy To-CarrierA export
  peer 172.16.11.11 keep-all-routes
 #
 ipv6-family unicast
  peer 2001:db8:1b::1 enable
  peer 2001:db8:1b::1 public-as-only
  peer 2001:db8:1b::1 as-path-filter To-other export
  peer 2001:db8:1b::1 route-policy To-CarrierA-IPv6 export 
#

Upstream Link Design

The upstream traffic of Internet users is much lighter than the downstream traffic in AS 100. Therefore, we do not need to control each Internet link for upstream traffic as strictly as we do for downstream traffic. Instead, uses can select any link to the Internet.

To prevent all upstream traffic from being distributed to one link, you need to perform configurations on the IGWs for load balancing. IGW1 in city A is used as an example. The design of IGW1 is as follows:
  1. Configure import policies on the IGWs so that they accept only the default routes sent by the tire-1 carriers through EBGP connections.
  2. As the tire-1 carriers' ASs and destinations are different from those of the IGWs, the IGWs select the optimal default route among the EBGP default routes received from the tire-1 carriers’ networks. When users request to access the Internet, the IGWs use the optimal default route to the Internet. As a result, all upstream traffic is distributed to one link.
  3. To prevent the IGWs from selecting the optimal default route among the EBGP default routes, configure a static default route for each Internet link on the IGWs.
  4. By default, the priority of static routes is higher than that of BGP routes. Therefore, the IGWs use the static default routes to forward traffic for the users to access the Internet. After multiple static default routes are configured on the IGWs, load balancing is performed on the static default routes during traffic forwarding. In this case, traffic is evenly distributed among links.

IGW1 is used as an example, and its configurations are as follows:

#
ip route-static 0.0.0.0 0.0.0.0 172.16.11.11 description to CarrierA      //Configure a static route to carrier A.
ip route-static 0.0.0.0 0.0.0.0 172.16.22.22 description to CarrierB      //Configure a static route to carrier B.
ip route-static 0.0.0.0 0.0.0.0 172.16.33.33 description to CarrierC      //Configure a static route to carrier C.
ip route-static 0.0.0.0 0.0.0.0 172.16.44.44 description to CarrierD      //Configure a static route to carrier D.
ipv6 route-static :: 0 2001:db8:1b::1 description to CarrierA
#
ip ip-prefix default index 10 permit 0.0.0.0 0    //Configure an IP prefix list.
ip ipv6-prefix ipv6-default index 10 permit :: 0     //Configure an IPv6 prefix list.
#
route-policy default-in permit node 10      //Configure a route-policy.
 if-match ip-prefix default
#
route-policy ipv6-default-in permit node 10     //Configure an IPv6 route-policy.
 if-match ipv6 address prefix-list ipv6-default
#
bgp 100         //Configure BGP.
 #
 ipv4-family unicast
  peer 172.16.11.11 route-policy default-in import    //Configure a BGP import policy.
  peer 172.16.22.22 route-policy default-in import    //Configure a BGP import policy.
  peer 172.16.33.33 route-policy default-in import    //Configure a BGP import policy.
  peer 172.16.44.44 route-policy default-in import    //Configure a BGP import policy.
  #
 ipv6-family unicast
  peer 2001:db8:1b::1 route-policy ipv6-default-in import    //Configure a BGP import policy.
#

Reliability Design

To improve reliability, the following link protection functions are required:
  1. Internet routes over different egress links in the same city are available. If one of the links fails, service traffic is switched to another link.

  2. Link protection is available between the two IGWs. If the primary link goes Down, traffic is switched to the backup link.
  3. The two IGWs implement downstream route protection. If the downstream link of the IGW in a city goes Down, traffic detours to the IGW of the other city.
  4. The two IGWs implement device-level route protection. If the IGW of a city goes Down, traffic is switched to the IGW of the other city.
To meet the preceding reliability requirements, the design is as follows:
  • Use the 10 Gbit/s direct link between the two IGWs as the primary link for inter-city interconnection. Use the link between the two IGWs that passes through the switches as the backup link for inter-city interconnection.

  • Create a sub-interface on the upstream link of each access router in each city and use the sub-interface to implement OSPF interconnection with the IGW in the other city through the switch (working in Layer 2 mode) in the local city. Establish IBGP connections between each access router and the IGWs. Configure each access router to add a community attribute to the IBGP routes to be advertised. The community attribute is used to identify the location of each access router. Configure the IGWs as RRs in the same cluster.

  •  
  • Each IGW sends different address segments of the local city over different Internet links. The AS_Path length is changed for link backup.

  • The IGW in each city uses community attributes to change the AS_Path length of user address segments in the other city to protect Internet routes.

Inter-City Link Protection

Figure 1-35 shows the link protection networking.
  • Use the 10 Gbit/s direct link between the two IGWs as the primary link for inter-city interconnection and set the OSPF cost to 10.
  • Use the 1 Gbit/s link between the two IGWs that passes through the switches as the backup link for inter-city interconnection and set the OSPF cost to 20.
  • If the 10 Gbit/s link fails, inter-city traffic is forwarded through the 1 Gbit/s link.
Figure 1-35  Inter-city link protection

Access Link Protection on the Old Network

Figure 1-36 shows the access link protection on the old network.
  • Configure a sub-interface on all access devices (Old 1, Old 2, Old 3, and Old 4 shown in Figure 1-36). Use the sub-interface to implement OSPF interconnection with the IGW in the other city through the switch in the local city. Set the OSPF cost for the sub-interface to be greater by 5 than that for the interface connected to the IGW in the local city. Establish IBGP connections between each access router and the IGWs. Configure each access router to add a community attribute to the IBGP routes to be advertised.
  •  
  • Each access router preferentially selects the IGW in the local city for traffic forwarding. If a downstream link of the IGW in the local city fails, traffic is forwarded to the IGW in the other city.

Figure 1-36 shows how traffic is forwarded from IGW1 to Old 1. In normal cases, traffic is transmitted through the primary link (IGW1-Switch 1). If the primary the link fails, traffic is forwarded through the backup link.

Figure 1-36  Inter-city link protection

Access Link Protection on the New Network

Figure 1-37 shows the access link protection on the new network. Configure route-policies on each P to control the costs of advertised EBGP address segment routes. Configure each P to set an EBGP cost for the IP address segment of another P in the same city and a different EBGP cost for the IP address segments of the Ps in another city to provide route protection.
  • Use city A as an example. If the IGW1-P1 link is Down, traffic is transmitted through the IGW1-P2 link.
  • Still use city A as an example. If both the IGW1-P1 link and IGW1-P2 link fail, traffic detours to IGW2.
Figure 1-37  Inter-city link protection

Intra-City Internet Link Protection

Figure 1-38 shows intra-city Internet link protection. Use IGW1 in city A as an example. The protection design for different Internet links is as follows:
  • On each IGW, set an IP prefix list for each Internet link and configure route-policies so that each IGW preferentially selects itself to divert traffic to address segments of the local city.
  • In BGP, the attributes most commonly used to control EBGP routes are the cost and AS_Path. On each IGW, configure an IP prefix list-based route-policy to retain the AS_Path length of the route advertised to one carrier and increase the AS_Path length of the routes advertised to other carriers by adding four public network AS numbers. Such a configuration provides protection among intra-city Internet links.
  • For the user address segments of the new network, set a route-policy to replace the private network AS number with the public network AS number.
  • IPv6 is supported only by carrier A’s links. Therefore, all IPv6 prefixes are sent to carrier A, which means that route protection cannot be implemented among intra-city links.
Figure 1-38  Intra-city Internet link protection

IGW1 is used as an example, and its configurations are as follows:

#
//Configure IP prefix lists.
#
ip ip-prefix P3-NEW-IP index 10 permit 10.1.1.0 23
ip ip-prefix P4-NEW-IP index 10 permit 10.1.2.0 23
ip ip-prefix P1-NEW-IP index 10 permit 10.1.3.0 23
ip ip-prefix P2-NEW-IP index 10 permit 10.1.4.0 23
#
//Configure a route-policy for carrier A.
#
route-policy To-CarrierA permit node 10
 if-match ip-prefix To-CarrierA      //Match the routes advertised to carrier A and retain their AS_Path lengths.
#
route-policy To-CarrierA permit node 20
 if-match ip-prefix To-CarrierB      //Match the routes advertised to carrier B and increase their AS_Path lengths.
 apply as-path 100 100 100 100 additive    //AS 100 is a public-network AS.
#
route-policy To-CarrierA permit node 30
 if-match ip-prefix To-CarrierD      //Match the routes advertised to carrier D and increase their AS_Path lengths.
 apply as-path 100 100 100 100 additive
#
route-policy To-CarrierA permit node 40
 if-match ip-prefix To-CarrierC      //Match the routes advertised to carrier C and increase their AS_Path lengths.
 apply as-path 100 100 100 100 additive
#
route-policy To-CarrierA permit node 70
 if-match ip-prefix P3-NEW-IP       //Advertise address prefixes of the new network to carrier A and retain their AS_Path lengths.
#
route-policy To-CarrierA permit node 80
 if-match ip-prefix P4-NEW-IP       //Advertise address prefixes of the new network to carrier A and retain their AS_Path lengths.
#
//Configure a route-policy for carrier B.
#
route-policy To-CarrierB permit node 10
 if-match ip-prefix To-CarrierB
#
route-policy To-CarrierB permit node 20
 if-match ip-prefix To-CarrierD
 apply as-path 100 100 100 100 additive
#
route-policy To-CarrierB permit node 30
 if-match ip-prefix To-CarrierC
 apply as-path 100 100 100 100 additive
#
route-policy To-CarrierB permit node 50
 if-match ip-prefix To-CarrierA
 apply as-path 100 100 100 100 additive
#
route-policy To-CarrierB permit node 70
 if-match ip-prefix P3-NEW-IP
 apply as-path 100 100 100 100 100 overwrite
#
route-policy To-CarrierB permit node 80
 if-match ip-prefix P4-NEW-IP
 apply as-path 100 100 100 100 100 overwrite
#
//Configure a route-policy for carrier C.
#
route-policy To-CarrierC permit node 10
 if-match ip-prefix To-CarrierC
#
route-policy To-CarrierC permit node 20
 if-match ip-prefix To-CarrierB
 apply as-path 100 100 100 100 additive
#
route-policy To-CarrierC permit node 30
 if-match ip-prefix To-CarrierD
 apply as-path 100 100 100 100 additive
#
route-policy To-CarrierC permit node 50
 if-match ip-prefix To-CarrierA
 apply as-path 100 100 100 100 additive
#
route-policy To-CarrierC permit node70
 if-match ip-prefix P3-NEW-IP
 apply as-path 100 100 100 100 100 overwrite
#
route-policy To-CarrierC permit node 80
 if-match ip-prefix P4-NEW-IP
 apply as-path 100 100 100 100 100 overwrite
#
//Configure a route-policy for carrier D.
#
route-policy To-CarrierD permit node 10
 if-match ip-prefix To-CarrierD
#
route-policy To-CarrierD permit node 20
 if-match ip-prefix To-CarrierB
 apply as-path 100 100 100 100 additive
#
route-policy To-CarrierD permit node 30
 if-match ip-prefix To-CarrierC
 apply as-path 100 100 100 100 additive
#
route-policy To-CarrierD permit node 50
 if-match ip-prefix To-CarrierA
 apply as-path 100 100 100 100 additive
#
route-policy To-CarrierD permit node 70
 if-match ip-prefix P3-NEW-IP
 apply as-path 100 100 100 100 100 overwrite
#
route-policy To-CarrierD permit node 80
 if-match ip-prefix P4-NEW-IP
 apply as-path 100 100 100 100 100 overwrite
#
//Configure a BGP export policy.
#
bgp 100
 #
 ipv4-family unicast
  peer 172.16.11.11 route-policy To-CarrierA export
  peer 172.16.22.22 route-policy To-CarrierB export
  peer 172.16.33.33 route-policy To-CarrierC export
  peer 172.16.44.44 route-policy To-CarrierD export
#

Inter-City Internet Link Protection

Figure 1-39 shows how route protection is implemented among inter-city Internet links:
  • Each access router of the old network adds a community attribute to routes for location identification before sending the routes to the IGWs.

  • Each P of the new network also adds a community attribute to routes for location identification before sending the routes to the IGWs.

  • Each IGW uses community attribute-based route-policies to increase the AS_Path length of non-local address segments by adding eight public network AS numbers, and sends corresponding routes to tire-1 carriers. In this manner, Internet route protection is provided for users in the other city.

  • For the user address segments of the new network, set a route-policy to replace the private network AS number with the public network AS number.

Figure 1-39  Inter-city Internet link protection

Use users in city A as an example. If IGW1 of city A fails, users in city A can receive and send Internet traffic through IGW2 of city B.

IGW1 is used as an example, and its configurations are as follows:

# 
//Configure community attribute filters.
#
ip community-filter basic A-OLD permit 100:1000    //Match city A's address prefixes of the old network.
ip community-filter basic B-OLD permit 100:1001    //Match city B's address prefixes of the old network.
ip community-filter basic A-OLD-IPv6 permit 100:2000    //Match city A's address prefixes of the old network.
ip community-filter basic B-OLD-IPv6 permit 100:2001    //Match city B's address prefixes of the old network.
ip community-filter basic A-NEW permit 100:3000    //Match city A's address prefixes of the new network.
ip community-filter basic B-NEW permit 100:3001    //Match city B's address prefixes of the new network.
ip community-filter basic A-NEW-IPv6 permit 100:4000    //Match city A's address prefixes of the new network.
ip community-filter basic B-NEW-IPv6 permit 100:4001    //Match city B's address prefixes of the new network.
# 
//Configure a route-policy for carrier A.
#
route-policy To-CarrierA permit node 60
 if-match community-filter B-OLD    //Match city B's address prefixes of the old network.
 apply as-path 100 100 100 100 100 100 100 100 additive    //Increase the AS_Path length.
#
route-policy To-CarrierA permit node 90
 if-match community-filter B-NEW    //Match city B's address prefixes of the new network.
 apply as-path 100 100 100 100 100 100 100 100 100 overwrite    //Overwrite the original AS_Path.
#
//Configure an IPv6 route-policy for carrier A.
#
route-policy To-CarrierA-IPv6 permit node 50
 if-match community-filter B-NEW-IPv6    //Match city B's IPv6 address prefixes of the new network.
 apply as-path 100 100 100 100 100 100 100 100 100 overwrite    //Overwrite the original AS_Path.
#
//Configure an IPv6 route-policy for carrier B.
#
route-policy To-CarrierB permit node 60
 if-match community-filter B-OLD
 apply as-path 100 100 100 100 100 100 100 100 additive
#
route-policy To-CarrierB permit node 90
 if-match community-filter B-NEW
 apply as-path 100 100 100 100 100 100 100 100 100 overwrite
#
//Configure a route-policy for carrier C.
#
route-policy To-CarrierC permit node 60
 if-match community-filter B-OLD
 apply as-path 100 100 100 100 100 100 100 100 additive
#
route-policy To-CarrierC permit node 90
 if-match community-filter B-NEW
 apply as-path 100 100 100 100 100 100 100 100 100 overwrite
#
//Configure a route-policy for carrier D.
#
route-policy To-CarrierD permit node 60
 if-match community-filter B-OLD
 apply as-path 100 100 100 100 100 100 100 100 additive
#
route-policy To-CarrierD permit node 90
 if-match community-filter B-NEW
 apply as-path 100 100 100 100 100 100 100 100 100 overwrite
#
//Configure a BGP export policy.
#
bgp 100
 #
 ipv4-family unicast
   peer 172.16.11.11 route-policy To-CarrierA export
   peer 172.16.22.22 route-policy To-CarrierB export
   peer 172.16.33.33 route-policy To-CarrierC export
   peer 172.16.44.44 route-policy To-CarrierD export
 #
 ipv6-family unicast
  peer 2001:db8:1b::1 route-policy To-CarrierA-IPv6 export 
#

Summary

This case shows a complex scenario for IGW design and migration where each IGW has multiple Internet links and connects to multiple tire-1 carriers. For Internet downstream traffic, IP prefix lists, community attribute filters, and route-policies must be properly configured on each IGW so that the bandwidth usage of each link is clear and proper. For Internet upstream traffic, load balancing needs to be configured to prevent all traffic from being distributed to one link.

Updated: 2019-05-16

Document ID: EDOC1000120969

Views: 26253

Downloads: 879

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