BGP Policy Lab - MEDs

Introduction

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.

Lab Topology

The following common topology is used for this lab.

Background

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.

Addressing

As a reminder, the addressing used for this lab is documented in the address plan and is replicated here for convenience:

Clean up

Before we start with this lab it is important that the configuration from the previous local-preference lab is removed.

This involves removing the route-maps, prefix-lists and the per-neighbour configuration to set local-preference.

All router teams need to do this, and then do a route-refresh of their EBGP peerings.

MEDs

This lab in the BGP Policy series introduces the first of four methods of influencing inbound policies, the Multi-Exit Discriminator (MED).

Policy Implementation

Here MEDs are used to demonstrate how to influence inbound traffic flows. While the use of MEDs on the global Internet is much reduced over what it was in the 1990s, it is still helpful to know how they can be used to influence inbound traffic flows by adjusting outbound routing announcements.

The example here achieves exactly the same traffic flow between neighbouring ASes as we saw in the local-preference lab for the networks in question - but this time the policy is implemented from the other AS!

Do remember that local-preference is used by an AS to influence outbound traffic paths, whereas MEDs are used to influence inbound traffic paths.

AS 64501:

• All traffic TO 100.68.1.32/28 and 2001:DB8:1:100::/56 (Router1) from anywhere in AS 64502 must enter AS 64501 via the Router5 – Router3 link. (Hint: this means that Router2 must announce 100.68.1.32/28 and 2001:DB8:1:100::/56 to AS 64502 with a higher metric than the equivalent announcement from Router3.)

• All traffic TO 100.68.1.64/28 and 2001:DB8:1:300::/56 (Router3) from anywhere in AS 64504 must enter AS 64501 via the Router14 – Router2 link. (Hint: this means that R1 must announce 100.68.1.64/28 and 2001:DB8:1:300::/56 to AS 64504 with a higher metric than the equivalent announcement from Router2.)

AS 64502:

• All traffic TO 100.68.2.48/28 and 2001:DB8:2:200::/56 (Router5) from anywhere in AS 64503 must enter AS 64502 via the Router8 – Router6 link. (Hint: this means that Router7 must announce 100.68.2.48/28 and 2001:DB8:2:200::/56 to AS 64503 with a higher metric than the equivalent announcement from Router6.)

• All traffic TO 100.68.2.64/28 and 2001:DB8:2:300::/56 (Router6) from anywhere in AS 64501 must enter AS 64502 via the Router2 – Router4 link. (Hint: this means that Router5 must announce 100.68.2.64/28 and 2001:DB8:2:300::/56 to AS 64501 with a higher metric than the equivalent announcement from Router4.)

AS 64503:

• All traffic TO 100.68.3.32/28 and 2001:DB8:3:100::/56 (Router8) from anywhere in AS 64502 must enter AS 64503 via the Router7 – Router9 link. (Hint: this means that Router8 must announce 100.68.3.32/28 and 2001:DB8:3:100::/56 to AS 64502 with a higher metric than the equivalent announcement from Router9.)

• All traffic TO 100.68.3.48/28 and 2001:DB8:3:200::/56 (Router9) from anywhere in AS 64504 must enter AS 64503 via the Router11 – Router9 link. (Hint: this means that Router10 must announce 100.68.3.48/28 and 2001:DB8:3:200::/56 to AS 64504 with a higher metric than the equivalent announcement from Router9.)

AS 64504:

• All traffic TO 100.68.4.48/28 and 2001:DB8:4:200::/56 (Router12) from anywhere in AS 64501 must enter AS 64504 via the Router1 – Router13 link. (Hint: this means that Router14 must announce 100.68.4.48/28 and 2001:DB8:4:200::/56 to AS 64501 with a higher metric than the equivalent announcement from Router13.)

• All traffic TO 100.68.4.64/28 and 2001:DB8:4:300::/56 (Router13) from anywhere in AS 64503 must enter AS 64504 via the Router10 – Router12 link. (Hint: this means that Router11 must announce 100.68.4.64/28 and 2001:DB8:4:300::/56 to AS 64503 with a higher metric than the equivalent announcement from Router12.)

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.

Suggestion: Choose a MED of 10 for the “low MED” configuration and a MED of 200 for “high MED” configuration. But most important of all, confer with your colleagues in your AS to make sure that your “low MED” value is lower than their chosen “high MED” value.

Example Configurations

Here is a sample configuration for Router6 for the AS64502 scenario above (showing the IPv4 and IPv6 policy statements):

ip prefix-list R5-v4prefix permit 100.68.2.48/28
!
ipv6 prefix-list R5-v6prefix permit 2001:DB8:2:200::/56
!
route-map R8-v4med permit 10
 match ip address prefix-list R5-v4prefix
 set metric 10
!
route-map R8-v4med permit 20
!
route-map R8-v6med permit 10
 match ipv6 address prefix-list R5-v6prefix
 set metric 10
!
route-map R8-v6med permit 20
!
router bgp 64502
 address-family ipv4
  neighbor 100.68.2.9 remote-as 64503
  neighbor 100.68.2.9 route-map R8-v4med out
!
 address-family ipv6
  neighbor 2001:DB8:2:5::1 remote-as 64503
  neighbor 2001:DB8:2:5::1 route-map R8-v6med out
!

Notice again the use of descriptive names for the prefix-lists and route-maps.

Implementation

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).

Verification

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.