-
-
-
Configure virtual path route cost
-
-
This content has been machine translated dynamically.
Dieser Inhalt ist eine maschinelle Übersetzung, die dynamisch erstellt wurde. (Haftungsausschluss)
Cet article a été traduit automatiquement de manière dynamique. (Clause de non responsabilité)
Este artículo lo ha traducido una máquina de forma dinámica. (Aviso legal)
此内容已经过机器动态翻译。 放弃
このコンテンツは動的に機械翻訳されています。免責事項
이 콘텐츠는 동적으로 기계 번역되었습니다. 책임 부인
Este texto foi traduzido automaticamente. (Aviso legal)
Questo contenuto è stato tradotto dinamicamente con traduzione automatica.(Esclusione di responsabilità))
This article has been machine translated.
Dieser Artikel wurde maschinell übersetzt. (Haftungsausschluss)
Ce article a été traduit automatiquement. (Clause de non responsabilité)
Este artículo ha sido traducido automáticamente. (Aviso legal)
この記事は機械翻訳されています.免責事項
이 기사는 기계 번역되었습니다.책임 부인
Este artigo foi traduzido automaticamente.(Aviso legal)
这篇文章已经过机器翻译.放弃
Questo articolo è stato tradotto automaticamente.(Esclusione di responsabilità))
Translation failed!
Configure Virtual Path Route Cost
Citrix SD-WAN supports the following routing enhancements related to data center administration.
For example, consider the SD-WAN network with two data centers; one in North America and one in Europe. You want all sites in North America to route traffic through the data center in North America and all sites in Europe to use the Europe data center. Previously, in SD-WAN 9.3 and earlier release versions, this functionality of data center administration was not supported. This is implemented with the introduction of Virtual Path Route cost.
- Virtual Path Route cost: You can configure the Virtual Path route cost for individual virtual paths that are added to the route cost when a route is learned from a remote site.
This feature invalidates or deletes the WAN to WAN forwarding Cost.
-
OSPF Route Cost: You can now import OSPF route cost (type1 metric) by enabling “Copy OSPF Route Cost” in import filters. OSPF Route cost is considered in route selection instead of SD-WAN cost. Cost up to 65534 instead of 15 is supported, but it is advisable to accommodate for the appropriate virtual path route cost that is added if the route is learned from a remote site.
-
BGP - VP cost to MED: You can now copy the Virtual Path route cost for SD-WAN routes into BGP MED values when exporting (redistributing) SD-WAN routes to BGP peers. This can be set for individual neighbors by creating a BGP policy and applying it in the “OUT” direction for each neighbor.
-
Any site can have multiple virtual paths to other sites. Sometimes, if there is a Branch to which there is connectivity to services through more virtual paths, there can be two virtual paths from the Branch site. One virtual path through DC1 and the other through DC2. DC1 can be an MCN and DC2 can be a Geo-MCN, and can be configured as another site with Static Virtual Path.
-
Add a default cost for each VP as 1. Virtual Path Route cost helps associate a cost to each virtual path of a site. This helps to manipulate route exchanges/updates over a specific virtual path instead of default site cost. With this, we can manipulate which data center to be preferred for sending out the traffic.
-
Allow cost to be configured within a small range of values (for example; 1–10) for each VP.
-
The Virtual path cost must be added to any route shared with neighbor sites to indicate routing preference, including routes learned via Dynamic Routing.
-
No Static Virtual Path must have a lower cost than a Dynamic Virtual Path.
Note
VP Route cost deprecates the WAN to WAN forwarding cost that existed in release versions earlier than release version 10.0. The routing decisions based on WAN to WAN forwarding costs have to be reinfluenced by using VP route cost as the WAN to WAN forwarding cost has no significance when you migrate to release version 10.0.
How to Configure Virtual Path Route Cost
You can configure Virtual Path Route in the SD-WAN GUI under Connections-> View Region > View site > Virtual Paths > Basic Settings. All routes are installed with basic Citrix SD-WAN cost + VP route cost to influence route costs across multiple virtual paths.
Use Case:
For example, there are subnets 172.16.2.0/24 and 172.16.3.0/24. Assume that there are two data centers DC1 and DC2 that use both these subnets to transmit traffic to SD-WAN. With the default virtual path route cost, you cannot influence routing since it depends on which route got installed first it can be either the DC2 first or the DC1 next.
With virtual path, you can influence specifically DC2 virtual path to have a higher virtual path route cost (for example, 10) while DC1 has the default VP route cost of 5. This manipulation helps install routes with DC1 first and DC2 next for both.
You can have four routes, two routes to 172.16.2.0/24; one via DC1 with lower cost and then via DC2 with higher cost, and 2 more for 172.16.3.0/24.
Monitoring and Troubleshooting
The routing table displays how the same subnets advertised by two sites connected to a branch site over the virtual path are installed with precedence of cost with Virtual Path route cost addition.
To verify the route cost and which routes are used in the routing table, navigate to Monitoring > Statistics > under Show field, select Routes. Route costs and hit counts can be verified in the same page.
This figure below shows the route table with two different costs for the same route which is 172.16.6.0/24 with cost 10 and 11 for services DC-Branch01 and GEOMCN-Branch01 respectively.
Share
Share
This Preview product documentation is Cloud Software Group Confidential.
You agree to hold this documentation confidential pursuant to the terms of your Cloud Software Group Beta/Tech Preview Agreement.
The development, release and timing of any features or functionality described in the Preview documentation remains at our sole discretion and are subject to change without notice or consultation.
The documentation is for informational purposes only and is not a commitment, promise or legal obligation to deliver any material, code or functionality and should not be relied upon in making Cloud Software Group product purchase decisions.
If you do not agree, select I DO NOT AGREE to exit.