|
|
|
CNA uses link-groups to refer to separate site-links (tunnels) on multiple physical (logical) networks that lead to the same remote site. ANS6 uses the next hop and/or BGP communities information from natural routing to figure out which site-link goes to which remote site, and then uses that information to determine the appropriate next hop and/or communities to use when asserting a performance route. In ANS6, this involves manually specifying a table of next hop and/or BGP community values that correspond to each site in the CNA configuration. Some installations might choose to specify next hops, some might choose to specify communities, and some might choose both.
The active measurement system also needs to be aware of the site information specified by link-groups. In ANS6, active measurement now reads the site information from the configuration and can use LSRR with the appropriate next-hop for each link from the site table when probing a prefix. ANS6 does require that probed addresses be manually associated with a site.
ANS6 also uses the link-group name as a prefix-alias to label any prefixes it determines reside at a particular site. However, if a “report prefix-alias” exists for the prefix, that assignment will override the link-group name.
The following example shows the syntax for defining two link-groups, one for Seattle and another for Chicago, and using LSRR for probing them both:
module engine
link-group seattle
source-route active-measurement
link uunet next-hop 10.0.1.1 community 100:1
link att next-hop 10.0.1.2 community 100:2
end
link-group chicago
source-route active-measurement
link uunet next-hop 10.0.2.1 community 100:3
link att next-hop 10.0.2.2 comminity 100:4
end
end
Given the above table, whenever CNA hears a natural route with community 100:1, community 100:2, next-hop 10.0.1.1, or next-hop 10.0.1.2, it would consider the prefix to be in link-group seattle. Similarly, if CNA hears a natural route with 100:3, 100:4, 10.0.2.1, or 10.0.2.2, it would consider the prefix to be in link-group chicago.
When CNA asserts a performance route for a prefix in Seattle over link L1, it will assert a next hop of 10.0.1.1, and a community of 100:1. Assertions for other links/link-groups would behave similarly.
Both the next-hop and the community parts of the config lines are optional, such that only one of them or even neither of them need be specified. This allows an administrator to specify just the link (causing the global facing address to show through as the next-hop), specify only next-hop or community, or specify both according to their needs.
If only a subset of links are specified in the link-group, then only those links will be used for the prefixes in the link-group. Also, the global facing address shows through as the next-hop for a link automatically if none is specified in the link command. Following is another example that illustrates additional uses of the link and link-group commands:
module engine
link uunet
provider-as 65000 172.16.0.1
end
link att
provider-as 65000 172.16.0.2
end
link verio
provider-as 65000 172.16.0.3
link-group seattle
source-route active-measurement
link uunet next-hop 10.0.0.1
link att
end
link-group chicago
link uunet next-hop 10.0.0.1 community 100:1
link att next-hop 10.0.0.3
link verio community 100:3
end
end
In this example, only UUNET and AT&T will be used for Seattle, and active-measurement will use LSRR. The next-hop for UUNET will be 10.0.0.1, and the next-hop for AT&T will be 172.16.0.2. No community information will be used for Seattle. If a natural route is heard with next-hop 10.0.0.1, it will be identified as being in Seattle.
For Chicago, all three links will be used. UUNET will use next-hop 10.0.0.1, AT&T will use next-hop 10.0.0.3, and Verio will use next-hop 172.16.0.3. LSRR will not be used, instead relying on PBR on the router to direct measurements down the appropriate link or tunnel. If a natural route is heard with community 100:1, community 100:3, next-hop 10.0.0.1, or next-hop 10.0.0.3, it will be identified as being in Chicago.
NOTE: This example is not realistic for a real world installation, since it contains a combination of next-hop and community information. A real installation would tend to have link statements with matching patterns of next-hop and community information.
One final addition in ANS6 is the ability to create a user-defined prefix and force it to be in a link-group. The following example illustrates how to accomplish that:
module engine set-link-group seattle prefix 192.168.100.0/24 end
|
|
|