## Introduction

The purpose of this lab is to introduce improved selection (i.e make it more deterministic) of the outbound transit paths in our multi homed group.

## Lab Topology

The lab topology diagram is included below as a reminder.

## Choosing Transit Providers

Our autonomous system can now choose between two transit providers for all non-local traffic. As we saw in the previous exercise, the border router in our AS would choose either of the transits based purely on the age of the learned default route from the upstream. If a link is toggled, the other transit provider would be chosen (as it became the oldest learned default). This really is not ideal.

## Outbound Traffic Engineering

We will now configure our border router such that the transit provider chosen for outbound traffic is TR1 (AS121). TR2 (AS122) will be the back up.

Recall from the BGP presentation that we choose outbound paths using the local-preference attribute. So we need to set up a route-map to tag the default route we learn from AS121 with a high local preference.

### Route-map Configuration

Note we already have a route-map applied to the BGP peering with AS121 - the configuration currently looks something like this:

    router bgp X0
     address-family ipv4
      neighbor <ipv4-ptp-TR1> route-map Transitv4-in in
      neighbor <ipv4-ptp-TR2> route-map Transitv4-in in
    !
     address-family ipv6
      neighbor <ipv6-ptp-TR1> route-map Transitv6-in in
      neighbor <ipv6-ptp-TR2> route-map Transitv6-in in
    !

The same route-map is being used on both Transit router Peerings. This is not a good idea long term as we will want to implement different policy for each transit provider.

We will now redo the route-maps for each Transit provider. Here are the two existing route-maps (IPv4 and IPv6):

    route-map Transitv4-in permit 5
     match ip address prefix-list DEFAULT-ROUTEv4
     set community no-advertise
    !
    route-map Transitv4-in permit 10
     description Local pref for Upstream routes
     set local-preference 50
    !
    route-map Transitv6-in permit 5
     match ipv6 address prefix-list DEFAULT-ROUTEv6
     set community no-advertise
    !
    route-map Transitv6-in permit 10
     description Local pref for Upstream routes
     set local-preference 50
    !

We will create a new route-map (one for IPv4, another for IPv6) for the AS121 peering to include an additional `set` clause, to make the local-preference 150. Like this for IPv4:

    route-map TR1v4-in permit 5
     match ip address prefix-list DEFAULT-ROUTEv4
     set community no-advertise
     set local-preference 150
    !
    route-map TR1v4-in permit 10
     description Local pref for Upstream routes
     set local-preference 50
    !

and like this for IPv6:

    route-map TR1v6-in permit 5
     match ipv6 address prefix-list DEFAULT-ROUTEv6
     set community no-advertise
     set local-preference 150
    !
    route-map TR1v6-in permit 10
     description Local pref for Upstream routes
     set local-preference 50
    !

Once you have created the new route-map, we can apply it to the BGP peering with AS121, like this:

    router bgp X0
     address-family ipv4
      neighbor <ipv4-ptp-TR1> route-map TR1v4-in in
    !
     address-family ipv6
      neighbor <ipv6-ptp-TR1> route-map TR1v6-in in
    !

Once applied, don’t forget to do a route-refresh on the BGP session.

Next, we create a new route-map for the AS122 peering. It is exactly the same as the existing route-map `Transitv4-in`, just with a new name. We don’t need to set the local-preference here, as the default local-preference of 100 is sufficient (but it is included in the example anyway). And we’ll set the local-preference for any other routes to be 40, lower than the 50 on any routes heard from Transit 1.

Here is an example of the IPv4 route-map:

    route-map TR2v4-in permit 5
     match ip address prefix-list DEFAULT-ROUTEv4
     set local-preference 100
     set community no-advertise
    !
    route-map TR2v4-in permit 10
     description Local pref for Upstream routes
     set local-preference 40
    !

and here is an example of the IPv6 route-map:

    route-map TR2v6-in permit 5
     match ipv6 address prefix-list DEFAULT-ROUTEv6
     set local-preference 100
     set community no-advertise
    !
    route-map TR2v6-in permit 10
     description Local pref for Upstream routes
     set local-preference 40
    !

Now apply the route-map to the AS122 peering, in the same way as we did for the AS121 peering. Don’t forget to apply a route-refresh to the BGP peering (as IOS does not do it automatically).

### Cleaning up

Once you have applied the new route-maps to the two eBGP peerings, you need to remove the old route-maps simply by doing `no route-map Transitv4-in` and `no route-map Transitv6-in` in configuration mode. Save the configuration and then confirm that these two route-maps are gone.

### Confirmation

Now look at the BGP table. What do you see?

Try a traceroute from your Access router to the Internet - which transit provider does the trace exit through? Is it AS121 or AS122?

What about a traceroute to another group? Hopefully that still goes through the IXP or private peer!

Now try a traceroute from your laptop to the Access routers in the network. Which way does the traffic go, through AS121 or AS122 or both? Can you explain what is happening?

Here is an example of the BGP table as seen on Group 6’s border router, from a previous workshop - compare with what you see on your router:

    B6#sh ip bgp
    BGP table version is 44, local router ID is 100.68.6.1
    Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
                  r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
                  x best-external, a additional-path, c RIB-compressed,
                  t secondary path,
    Origin codes: i - IGP, e - EGP, ? - incomplete
    RPKI validation codes: V valid, I invalid, N Not found

         Network          Next Hop            Metric LocPrf Weight Path
     *>   0.0.0.0          100.121.1.10                  150      0 121 i
     *                     100.122.1.10                  100      0 122 i
     *>i  100.68.1.0/24    100.68.6.3              20    170      0 10 i
     *                     100.121.1.10                   50      0 121 122 10 i
     *                     100.122.1.10                   40      0 122 10 i
     *>i  100.68.2.0/24    100.68.6.3               0    170      0 20 i
     *                     100.121.1.10                   50      0 121 122 20 i
     *                     100.122.1.10                   40      0 122 20 i
     *>i  100.68.3.0/24    100.68.6.3              20    170      0 30 i
     *                     100.121.1.10                   50      0 121 122 30 i
     *                     100.122.1.10                   40      0 122 30 i
     *    100.68.4.0/24    100.122.1.10                   40      0 122 40 i
     *                     100.121.1.10                   50      0 121 122 40 i
     *>i                   100.68.6.3               0    170      0 40 i
     *>i  100.68.5.0/24    100.68.6.3               0    200      0 50 i
     *                     100.121.1.10                   50      0 121 122 50 i
     *                     100.122.1.10                   40      0 122 50 i
     *>i  100.68.6.0/24    100.68.6.2               0    100      0 i
     *>i  100.68.6.28/30   100.68.6.2               0    100      0 i
     *>i  100.68.6.64/26   100.68.6.4               0    100      0 i
     *>i  100.68.7.0/24    100.68.6.3              20    170      0 70 i
     *                     100.121.1.10                   50      0 121 122 70 i
     *                     100.122.1.10                   40      0 122 70 i
     *    100.68.8.0/24    100.122.1.10                   40      0 122 80 i
     *                     100.121.1.10                   50      0 121 122 80 i
     *>i                   100.68.6.3               0    170      0 80 i
    ...etc...

Notice the primary and backup paths to the various destinations, and the local-preferences which have been set.

## Inbound Traffic Engineering

Right now the traffic entering each group from the wider network will enter through the AS121 transit provider (but not by any deliberate policy on our behalf1). We will now modify the configuration on the peering with our upstreams so that inbound traffic comes through AS122 transit provider to each group.

To do this we will have one policy tool available to us, the AS-PATH prepend. We will modify the policy on our peering with AS121 so that our address block is announced to AS121 with a longer AS path than that of the peering with AS122.

### Route-map Configuration

First we create a new route-map for use outbound on the peering with AS121. It will replace the existing `Transit-out` route-map we previously set up on the peering with AS121. This route-map will look for our IP address block, and apply a three times AS-PATH prepend on it. Here is an example - note we can use this route-map for both IPv4 and IPv6 as it has no address family specific configuration in it:

    route-map TR1-prepend permit 5
     match community aggregate customer-pi
     set as-path prepend X0 X0 X0
    !

Once we have created the route-map we apply it to the BGP peering with AS121. Here is an example for IPv4:

    router bgp X0
     address-family ipv4
      neighbor <ipv4-ptp-TR1> route-map TR1-prepend out
    !

and for IPv6:

    router bgp X0
     address-family ipv6
      neighbor <ipv6-ptp-TR1> route-map TR1-prepend out
    !

Once the configuration has been applied, remember to run an outbound route-refresh on the eBGP session with the AS121 router (TR1). For IPv4 and for IPv6.

### Confirmation

There is no real way of seeing what is happening within the transit provider network - but the instructors will log into the transit routers and show the class the BGP table there.

Here is an example of the IPv4 BGP table as seen on TR1, taken from a previous workshop:

    TR1#sh ip bgp
    BGP table version is 28, local router ID is 100.64.0.2
    Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
                  r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
                  x best-external, a additional-path, c RIB-compressed,
                  t secondary path,
    Origin codes: i - IGP, e - EGP, ? - incomplete
    RPKI validation codes: V valid, I invalid, N Not found

         Network          Next Hop        Metric LocPrf Weight Path
          0.0.0.0          0.0.0.0                            0 i
     *>   100.68.1.0/24    100.121.0.1                        0 122 10 i
     *                     100.121.1.1                        0 10 10 10 10 i
     *>   100.68.2.0/24    100.121.0.1                        0 122 20 i
     *                     100.121.1.3                        0 20 20 20 20 i
     *>   100.68.3.0/24    100.121.0.1                        0 122 30 i
     *                     100.121.1.5                        0 30 30 30 30 i
     *>   100.68.4.0/24    100.121.0.1                        0 122 40 i
     *                     100.121.1.7                        0 40 40 40 40 i
     *>   100.68.5.0/24    100.121.0.1                        0 122 50 i
     *                     100.121.1.9                        0 50 50 50 50 i
     *>   100.68.6.0/24    100.121.0.1                        0 122 60 i
     *                     100.121.1.11                       0 60 60 60 60 i
     *>   100.68.7.0/24    100.121.0.1                        0 122 70 i
     *                     100.121.1.13                       0 70 70 70 70 i
     *>   100.68.8.0/24    100.121.0.1                        0 122 80 i
     *                     100.121.1.15                       0 80 80 80 80 i
     *>   100.68.101.0/24  100.121.0.1                        0 122 10 100010 i
     *                     100.121.1.1                        0 10 10 10 10 100010 i
     *                     100.121.1.3                        0 20 20 20 20 100010 i
     *>   100.68.102.0/24  100.121.0.1                        0 122 10 100020 i
     *                     100.121.1.1                        0 10 10 10 10 100020 i
     *                     100.121.1.3                        0 20 20 20 20 100020 i
     *    100.68.103.0/24  100.121.1.7                        0 40 40 40 40 100030 i
     *>                    100.121.0.1                        0 122 30 100030 i
     *                     100.121.1.5                        0 30 30 30 30 100030 i
     *    100.68.104.0/24  100.121.1.7                        0 40 40 40 40 100040 i
     *>                    100.121.0.1                        0 122 30 100040 i
     *                     100.121.1.5                        0 30 30 30 30 100040 i
     *>   100.68.105.0/24  100.121.0.1                        0 122 50 100050 i
     *                     100.121.1.11                       0 60 60 60 60 100050 i
     *                     100.121.1.9                        0 50 50 50 50 100050 i
     *>   100.68.106.0/24  100.121.0.1                        0 122 50 100060 i
     *                     100.121.1.11                       0 60 60 60 60 100060 i
     *                     100.121.1.9                        0 50 50 50 50 100060 i
     *    100.68.107.0/24  100.121.1.15                       0 80 80 80 80 100070 i
     *>                    100.121.0.1                        0 122 70 100070 i
     *                     100.121.1.13                       0 70 70 70 70 100070 i
     *    100.68.108.0/24  100.121.1.15                       0 80 80 80 80 100080 i
     *>                    100.121.0.1                        0 122 70 100080 i
     *                     100.121.1.13                       0 70 70 70 70 100080 i
     *>   100.121.0.0/16   0.0.0.0              0         32768 i
     *>   100.122.0.0/16   100.121.0.1          0             0 122 i
     *>   100.127.0.0/24   100.121.1.17         0             0 131 i
     *>   100.127.2.0/24   100.121.0.1                        0 122 132 i

Notice the 3x prepend which each group has done on announcements towards their backup transit provider.

Also, each group should try a `traceroute` from their laptops to their Customer router connected to their Group network. Which way does the inbound traffic go? Via AS121 or AS122 or what happens? What about an outbound traceroute from the Customer router to 8.8.8.8, for example?

## Conclusion

This lab has shown how to select transit providers for either primary or backup paths for particular destinations. The next step would be to load balance traffic between two transit providers, and this example here shows the first steps of how to do that. Participants should refer to the BGP Multihoming presentations for more examples.

1. The path from the outside world to our 6 groups comes from the Virtualised Training Platform to AS121 first - AS121 best path to every group is via the direct link. The hop via AS122 is one AS longer so will not be used unless for backup.↩︎