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

NE40E V800R010C00 Feature Description - VPN 01

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 of VPN ORF

Application of VPN ORF

Usage Scenario

Scenario 1: Some devices do not support VPN outbound route filtering (ORF) among devices connected through networks.

Figure 7-51  Scenario where VPN ORF-incapable devices exist

On the network shown in Figure 7-51, PE1 and the RR support VPN ORF, whereas PE2 does not support this feature. A BGP peer relationship is established between PE1 and the RR in the VPN target address family view. The VPN ORF negotiation between PE1 and the RR succeeds, and PE2 and the RR cannot negotiate using VPN ORF. PE1 sends VPN ORF routes carrying the import route targets (IRTs) and original AS number of desired routes to RR. Based on the received VPN ORF routes, RR generates an export route policy and filters PE1's desired routes. When PE1 advertises routes to PE2, the RR must be configured to advertise the default VPN ORF route to PE1. The default VPN ORF route is a VPN ORF route with the prefix 0:0. The device that receives the default VPN ORF route advertises all VPN routes to the device that sends the default VPN ORF route. Therefore, PE1 sends all local VPN routes to the RR, and then the RR forwards the routes to PE2. In this way, PE1 receives routes from CE3 and CE4, and PE2 receives routes from CE1 and CE2.

Scenario 2: Both RR clients and non-RR clients exist on networks.

Figure 7-52  Scenario where both RR clients and non-RR clients exist

On the network shown in Figure 7-52, PE1, PE2, PE3, and the RR support VPN ORF. PE1 is an RR client, whereas PE2 and PE3 are non-RR clients. VPN routes with the IRT value being 1:1 are configured on both PE1 and PE2. PE1 and PE2 advertise these routes to the RR. Suppose the RR preferentially selects the route with the RT 1:1 from PE2. When advertising this route to PE3, the RR needs to advertise the route with the RT 1:1 received from PE1. In this manner, PE3 can receive the route with the RT 1:1 and then advertise a VPN route with the RT 1:1 to the RR. Then the RR forwards the VPN route to PE1.

Scenario 3: Devices connected through a network span multiple ASs.

Figure 7-53  Scenario where devices span multiple ASs

On the network shown in Figure 7-53, a BGP peer relationship is established between each pair of all devices, and VPN ORF is enabled on all devices. The devices marked a through j reside in different ASs. If Device a advertises a VPN route, the route can be sent to Device e along two paths: Device i -> Device f -> Device e and Device i -> Device h -> Device g -> Device e. Device e preferentially selects the path Device i -> Device f -> Device e because it is shorter. Then Device e sends the path information to Device b and Device d, which then forward the information to Device a. If Device a preferentially selects the path Device e -> Device b -> Device a, the VPN route is advertised along the path Device a -> Device b -> Device e -> Device f -> Device i. Device d, Device g, and Device h do not receive the VPN route. By default, RT-matched VPN routes are advertised only along the optimal path that is selected among paths with the same RT-MEM-NLRI prefix. To allow RT-matched VPN routes to be advertised along multiple eBGP paths with the same RT-MEM-NLRI prefix, run the external-paths command in the VPN target address family view. For example, if the external-paths 2 command is run on Device e, RT-matched routes are advertised along the paths: Device i -> Device f -> Device e and Device i -> Device h -> Device g -> Device e.

Download
Updated: 2018-07-04

Document ID: EDOC1100027166

Views: 46997

Downloads: 181

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