This lab continues the series demonstrating how an AS can use Local Preference to control outbound routing paths, and how to use MEDs (multi-exit discriminators or metrics), BGP communities, AS path prepends, and subnet leaking to determine inbound routing paths. All five are very powerful tools for ISPs to control how their external peering links are used.
Refer to the BGP presentations and documentation for more information about the BGP path selection process and the default values for, and priorities of, the “local_pref” and “metric” attributes.
The following common topology is used for this lab.
As a reminder, the diagram below displays the desired traffic flows between particular routers and ASes. Eight traffic flows are to be implemented.
The arrows in the diagram show the flows that will be configured. Each arrow originates from a border router in an AS, and terminates on one of the routers in another AS. This signifies the traffic flows desired for the links between the two routers.
Each of the policy labs we are going to do has a description on how to implement the traffic flow represented by each arrow. It is important to pause and think what the policy is, and what needs to be done to achieve it.
If at any time there is any doubt as to the configuration required, ask the lab instructors.
The diagram may look “busy” but the key to success is to focus on the traffic engineering that your group needs to do, and “ignore” the other activities by other groups.
As a reminder, the addressing used for this lab is documented in the address plan and is replicated here for convenience:
| AS Number | Router | IPv4 subnet | IPv6 subnet |
|---|---|---|---|
| AS64501 | Router1 | 100.68.1.32/28 | 2001:DB8:1:100::/56 |
| Router2 | 100.68.1.48/28 | 2001:DB8:1:200::/56 | |
| Router3 | 100.68.1.64/28 | 2001:DB8:1:300::/56 | |
| AS64502 | Router4 | 100.68.2.32/28 | 2001:DB8:2:100::/56 |
| Router5 | 100.68.2.48/28 | 2001:DB8:2:200::/56 | |
| Router6 | 100.68.2.64/28 | 2001:DB8:2:300::/56 | |
| Router7 | 100.68.2.80/28 | 2001:DB8:2:400::/56 | |
| AS64503 | Router8 | 100.68.3.32/28 | 2001:DB8:3:100::/56 |
| Router9 | 100.68.3.48/28 | 2001:DB8:3:200::/56 | |
| Router10 | 100.68.3.64/28 | 2001:DB8:3:300::/56 | |
| AS64504 | Router11 | 100.68.4.32/28 | 2001:DB8:4:100::/56 |
| Router12 | 100.68.4.48/28 | 2001:DB8:4:200::/56 | |
| Router13 | 100.68.4.64/28 | 2001:DB8:4:300::/56 | |
| Router14 | 100.68.4.80/28 | 2001:DB8:4:400::56 |
Before we start with this scenario it is important that the configuration from the previous BGP Community lab is removed.
This involves removing the community-lists, route-maps, prefix-lists and the per-neighbour configuration checking for communities.
All router teams should do this, and then do a route-refresh of their EBGP peerings.
This lab in the BGP Policy series introduces the third of the four methods of influencing inbound policies, the AS_PATH prepend.
Here the AS_PATH prepend is used to demonstrate how to influence inbound traffic flows. The main difference between this technique and the previous two is that the AS_PATH prepend is visible across all autonomous systems, not just between immediate neighbours as was the case for MED and the BGP Community.
As for the previous scenario, please read the instructions carefully, and discuss within your team, and in your AS, how you are going to implement the following.
The example in this step achieves exactly the same traffic flow between neighbouring ASes as in the previous scenario for the networks in question. Refer to the diagram above for a picture of the traffic flow…
AS 64501:
All traffic TO 100.68.1.64/28 and 2001:DB8:1:300::/56 (Router3) from anywhere in the lab topology must enter AS 64501 via the Router14 – Router2 link. (Hint: this means that Router1 and Router3 must announce 100.68.1.64/28 and 2001:DB8:1:300::/56 with a longer AS path than the other networks in AS 64501. Router2 needs to announce 100.68.1.64/28 and 2001:DB8:1:300::/56 with a longer AS path in its peering with Router4.)
All traffic TO 100.68.1.32/28 and 2001:DB8:1:100::/56 (Router1) from anywhere in the lab topology must enter AS 64501 via the Router5 – Router3 link. (Hint: this means that Router1 and Router2 must announce 100.68.1.32/28 and 2001:DB8:1:100::/56 with a longer AS path than the other networks in AS 64501.)
AS 64502:
All traffic TO 100.68.2.48/28 and 2001:DB8:2:200::/56 (Router5) from anywhere in the lab topology must enter AS 64502 via the Router8 – Router6 link. (Hint: this means that Router4, Router5 and Router7 must announce 100.68.2.48/28 and 2001:DB8:2:200::/56 with a longer AS path than the other networks in AS 64502.)
All traffic TO 100.68.2.64/28 and 2001:DB8:2:300::/56 (Router6) from anywhere in the lab topology must enter AS 64502 via the Router2 – Router4 link. (Hint: this means that Router5, Router6 and Router7 must announce 100.68.2.64/28 and 2001:DB8:2:300::/56 with a longer AS path than the other networks in AS 64502.)
AS 64503:
All traffic TO 100.68.3.32/28 and 2001:DB8:3:100::/56 (Router8) from anywhere in the lab topology must enter AS 64503 via the Router7 – Router9 link. (Hint: this means that Router8 and Router10 must announce 100.68.3.32/28 and 2001:DB8:3:100::/56 with a longer AS path than the other networks in AS 64503. Router9 needs to announce 100.68.3.32/28 and 2001:DB8:3:100::/56 with a longer AS path in its peering with Router11.)
All traffic TO 100.68.3.48/28 and 2001:DB8:3:200::/56 (Router9) from anywhere in the lab topology must enter AS 64503 via the Router11 – Router9 link. (Hint: this means that Router8 and Router10 must announce 100.68.3.48/28 and 2001:DB8:3:200::/56 with a longer AS path than the other networks in AS 64503. Router9 needs to announce 100.68.3.48/28 and 2001:DB8:3:200::/56 with a longer AS path in its peering with Router7.)
AS 64504:
All traffic TO 100.68.4.48/28 and 2001:DB8:4:200::/56 (Router12) from anywhere in the lab topology must enter AS 64504 via the Router1 – Router13 link. (Hint: this means that Router11, Router12 and Router14 must announce 100.68.4.48/28 and 2001:DB8:4:200::/56 with a longer AS path than the other networks in AS 64504.)
All traffic TO 100.68.4.64/28 and 2001:DB8:4:300::/56 (Router13) from anywhere in the lab topology must enter AS 64504 via the Router10 – Router12 link. (Hint: this means that Router11, Router13 and Router14 must announce 100.68.4.64/28 and 2001:DB8:4:300::/56 with a longer AS path than the other networks in AS 64504.)
The traffic flow we want to achieve above is also visually described in the earlier lab diagram, where the coloured arrows show the traffic flow we want to achieve between ASes.
AS_PREPEND is commonly used by smaller ISPs who are multihoming to their upstream providers. It is convention on the Internet to add at least two ASes when using AS_PREPEND. More usually, three ASes are added, especially if the upstream ISPs have links to each other going through a third party. Of course, ultimately the size of prepend needs depends on the upstream Internet topology - it is not a good idea to think of a large number for the prepend and hope that it works as several operators drop prefixes with paths more than 25 or 30 ASNs long!
Here is a sample IPv4 configuration for Router9 in its peerings with Router7 and Router11 for the AS 64503 example above:
ip prefix-list R8-v4prefix permit 100.68.3.32/28
ip prefix-list R9-v4prefix permit 100.68.3.48/28
!
route-map R7-v4prepend permit 10
match ip address prefix-list R9-v4prefix
set as-path prepend 64503 64503 64503
!
route-map R7-v4prepend permit 20
!
route-map R11-v4prepend permit 10
match ip address prefix-list R8-v4prefix
set as-path prepend 64503 64503 64503
!
route-map R11-v4prepend permit 20
!
router bgp 64503
address-family ipv4
neighbor 100.68.3.1 remote-as 64502
neighbor 100.68.3.1 description EBGP peering with Router7
neighbor 100.68.3.1 route-map R7-v4prepend out
neighbor 100.68.3.7 remote-as 64504
neighbor 100.68.3.7 description EBGP peering with Router11
neighbor 100.68.3.7 route-map R11-v4prepend out
!and here is the equivalent IPv6 configuration for Router9:
ipv6 prefix-list R8-v6prefix permit 2001:DB8:3:100::/56
ipv6 prefix-list R9-v6prefix permit 2001:DB8:3:200::/56
!
route-map R7-v6prepend permit 10
match ipv6 address prefix-list R9-v6prefix
set as-path prepend 64503 64503 64503
!
route-map R7-v6prepend permit 20
!
route-map R11-v6prepend permit 10
match ipv6 address prefix-list R8-v6prefix
set as-path prepend 64503 64503 64503
!
route-map R11-v6prepend permit 20
!
router bgp 64503
address-family ipv6
neighbor 2001:DB8:3:1::1 remote-as 64502
neighbor 2001:DB8:3:1::1 description EBGP peering with Router7
neighbor 2001:DB8:3:1::1 route-map R7-v6prepend out
neighbor 2001:DB8:3:4::1 remote-as 64504
neighbor 2001:DB8:3:4::1 description EBGP peering with Router11
neighbor 2001:DB8:3:4::1 route-map R11-v6prepend out
!Notice again the use of descriptive names for the prefix-lists and route-maps.
Use the above example to come up with a configuration for your router and the policy it needs to implement on its EBGP session. Discuss with the other members of your group (your AS) - it is likely that you will have some common configuration snippets you can share with each other.
Note: Router2 and Router9 have two EBGP peers, and will need a separate route-map for each peering. Use the hint above, naming the route-map after the peer name (and is also common practice in day to day network operations).
Once the policy has been implemented, remember to run a route-refresh on the EBGP session. And then try doing a traceroute (trace command, and remember to specify the source interface – why?) through the network, to the destination you have targeted. Does the traceroute follow the arrows in the diagram? If not, why not? Maybe check the BGP table and if your colleagues in your AS have completed their steps in the exercise as well.
On completion of the exercise the instructor will display traceroutes to the selected destinations on the classroom screen - the traffic has to enter the AS as specified in the exercise above and the instructor will check from various points of the lab that the traffic is flowing as intended.
The AS_PATH prepend is a useful tool for deprioritising an entry path into an Autonomous System. Industry best practices consider that prepends should only be done up to a level that is necessary - more than 5 AS_PATH prepends are really not going to achieve anything in terms of traffic engineering compared with using 4 or 5.
Question: how would another AS override the AS_PATH prepending that any network operator is doing?
Answer: by using Local Preference. Remember, Local Preference is “the most powerful BGP attribute” when it comes to making policy decisions - a network operator can use Local Preference on a prefix they have received to override any policy statement by a neighbouring AS.
For this lab here, have a look at the paths you are receiving directly from your EBGP peers. Do you see any with a long AS_PATH? If so, add in a policy line which matches that prefix and sets Local Preference to 200. Try a traceroute now to the destination and see what happens (from your router and from all routers in your AS).
Note: The instructors will discuss this point with the class before moving on to the next lab.