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

ME60 V800R010C10SPC500 Feature Description - WAN Access 01

This is ME60 V800R010C10SPC500 Feature Description - WAN Access
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).
Application Scenarios for Routing Policies

Application Scenarios for Routing Policies

Specific Route Filtering

On the OSPF-enabled network shown in Figure 10-2, Device A receives routes from the Internet and advertises some of the routes to Device B.

  • Device A advertises only routes 172.1.17.0/24, 172.1.18.0/24, and 172.1.19.0/24 to Device B.

  • Device C accepts only the route 172.1.18.0/24.

  • Device D accepts all the routes advertised by Device B.

Figure 10-2 Filtering received and advertised routes

There are multiple approaches to meet the preceding requirements, and the following two approaches are used in this example:
  • Use IP prefix lists

    • Configure an IP prefix list for Device A and configure the IP prefix list as an export policy on Device A for OSPF.
    • Configure another IP prefix list for Device C and configure the IP prefix list as an import policy on Device C for OSPF.
  • Use route-policies

    • Configure a route-policy (the matching rules can be the IP prefix list, cost, or route tag) for Device A and configure the route-policy as an export policy on Device A for OSPF.
    • Configure another route-policy on Device C and configure the route-policy as an import policy on Device C for OSPF.

    Compared with an IP prefix list, a route-policy can change route attributes and control routes more flexibly, but it is more complex to configure.

Transparent Transmission of Routes of Other Protocols Through an OSPF AS

On the network shown in Figure 10-3, an AS runs OSPF and functions as a transit AS for other areas. Routes from the IS-IS area connected to Device A need to be transparently transmitted through the OSPF AS to the IS-IS area connected to Device D. Routes from the RIP-2 area connected to Device B need to be transparently transmitted through the OSPF AS to the RIP-2 area connected to Device C.

Figure 10-3 Transparently transmitting routes of other protocols through an OSPF AS

To meet the preceding requirements, configure a route-policy for Device A to set a tag for the imported IS-IS routes. Device D identifies the IS-IS routes from OSPF routes based on the tag.

Routing Policy Application in Inter-AS VPN Option C

On the network shown in Figure 10-4, CE1 and CE2 communicate with each other through inter-AS VPN Option C.

Figure 10-4 Implementing route-policies in the inter-AS VPN Option C scenario

To establish an inter-AS label switched path (LSP) between PE1 and PE2, route-policies need to be configured for autonomous system boundary routers (ASBRs).
  • When an ASBR advertises the routes received from a PE in the same AS to the peer ASBR, the ASBR allocates MPLS labels to the routes using a route-policy.
  • When an ASBR advertises labeled IPv4 routes to a PE in the same AS, the ASBR reallocates MPLS labels to the routes using another route-policy.

In addition, to control route transmission between different VPN instances on a PE, configure a route-policy for the PE and configure the route-policy as an import or export policy for the VPN instances.

Application of BGP to IGP

On the network shown in Figure 10-5, Device A and Device B are aggregation devices on a backbone network, and Device C and Device D are egress devices of a metropolitan area network (MAN). BGP peer relationships are established between Device A and Device C as well as between Device B and Device D. External routes are advertised to the MAN using BGP. The MAN runs OSPF to implement interworking.

Figure 10-5 BGP to IGP

To enable devices on the MAN to access the backbone network, Device C and Device D need to import routes. When OSPF imports BGP routes, a routing policy can be configured to control the number of imported routes based on private attributes (such as the community) of the imported BGP routes or modify the cost of the imported routes to control the MAN egress traffic.

Translation
Download
Updated: 2019-01-04

Document ID: EDOC1100059473

Views: 14401

Downloads: 10

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