## Introduction

The purpose of this part of the lab is fix (i.e. make more deterministic) the routing issues we saw when we introduced the IXP to our lab network in the previous exercise.

## Lab Topology

A reminder of the lab topology is in the diagram below.

## Private Peering link versus IXP Peering

We are now going to deal with the issue where we see two paths between us and our private peer. One is via our private peering link, the other is via our peering with them across the IXP.

In day to day Internet operations, network operators prioritise links according to the value they attach to them - the list goes something like this:

Type of Link | Priority (local preference)
--- | ---
BGP Customer | 250
Private Peer | 200
IXP Bi-lateral | 170
IXP RS | 150
(default) | 100
Local Transit | 70
Global Transit | 50

Obviously there will be many variations on this theme, but the principle remains the same. Traffic to BGP customers naturally should go from the operator directly over the customer link, and not over any other link (peering or transit) - hence such customers are tagged with the highest local preference. Peering links have no operational cost, so are highly preferred over links which have an operational cost (transit). Private peering links are preferred over IXP links as the former are brokered directly with the partner, while the IXP links are via a third party infrastructure. It is not physically possible to peer privately with every operator, and this is the function that the IXP then provides (as was covered in the course presentations).

## BGP Policy on the Peering Router

We will now attach local preference to the routes we hear from our private peer and from the IXP Route Server, according to the table above.

To do this we will add a `local-preference` line to our existing `private-peer-in` and `IXP-RS-in` route-maps. The first example shows the addition to the route-maps for the private peer:

    route-map private-peerv4-in permit 5
     set local-preference 200
    !
    route-map private-peerv6-in permit 5
     set local-preference 200
    !

The second example shows the addition to the route-map for the RS peering:

    route-map IXP-RSv4-in permit 5
     set local-preference 150
    !
    route-map IXP-RSv6-in permit 5
     set local-preference 150
    !

Once we have added the `local-preference` line to the route-maps, we need to do a route-refresh inbound on the private and IXP RS peerings. You should now see the local preferences attached to the routes from the IXP and from the private peer. What has happened now?

## BGP Policy on the Border Router

Right now we are receiving the full routing table from our upstream provider. Rather than relying on defaults in the path selection process, we will now tag the routes we hear from the upstream according to the policy table above.

We already have a route-map applied inbound on the IPv4 and IPv6 eBGP sessions of the border router. These two route-maps are reproduced below, as a reminder:

    route-map Transitv4-in permit 5
     description Do not propagate the default route
     match ip address prefix-list DEFAULT-ROUTEv4
     set community no-advertise
    !
    route-map Transit-in permit 10
     description Allow full routes
     match ip address prefix-list FULL-ROUTESv4
    !
    route-map Transitv6-in permit 5
     description Do not propagate the default route
     match ipv6 address prefix-list DEFAULT-ROUTEv6
     set community no-advertise
    !
    route-map Transitv6-in permit 10
     description Allow full routes
     match ipv6 address prefix-list FULL-ROUTESv6
    !

We will now augment these two route-maps to add in the policy we need. We will add the local-preference to the second statement (line 10):

    route-map Transitv4-in permit 10
     set local-preference 50
    !
    route-map Transitv6-in permit 10
     set local-preference 50
    !

Once the route-map configuration shown above has been applied, do a route-refresh inbound on the eBGP session with the upstream.

What do you see now?

## Confirmation

Check on the Border, Core, Access and Peering Routers for what you now see in the BGP table.

What is the best path to your private peer? Look in the BGP and Routing tables.

What does `traceroute` tell you?

Hopefully you will see that the best path to your private peer will be via the private peering link. And the routes to the rest of the class will be via the Internet Exchange Point. The only traffic going via the Upstream Provider now will be traffic out to the Internet itself. If this is not the case, you will need to start doing some troubleshooting!

Here is an example showing what the BGP table of the Border router of Group 1 should look like:

    BGP table version is 13, local router ID is 100.68.1.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,
    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.0                            0 121 i
     *>i 100.68.1.0/24    100.68.1.2               0    100      0 i
     *>i 100.68.1.28/30   100.68.1.2               0    100      0 i
     *>i 100.68.1.64/26   100.68.1.4               0    100      0 i
     *   100.68.2.0/24    100.121.1.0                    50      0 121 20 i
     *>i                  100.68.1.3               0    200      0 20 i
     *   100.68.3.0/24    100.121.1.0                    50      0 121 30 i
     *>i                  100.68.1.3               0    150      0 30 i
     *   100.68.4.0/24    100.121.1.0                    50      0 121 40 i
     *>i                  100.68.1.3               0    150      0 40 i
     *   100.68.5.0/24    100.121.1.0                    50      0 121 122 50 i
     *>i                  100.68.1.3               0    150      0 50 i
     *   100.68.6.0/24    100.121.1.0                    50      0 121 122 60 i
     *>i                  100.68.1.3               0    150      0 60 i
     *   100.68.7.0/24    100.121.1.0                    50      0 121 122 70 i
     *>i                  100.68.1.3               0    150      0 70 i
     *   100.68.8.0/24    100.121.1.0                    50      0 121 122 80 i
     *>i                  100.68.1.3               0    150      0 80 i
     *>  100.121.0.0/16   100.121.1.0              0     50      0 121 i
     *>  100.122.0.0/16   100.121.1.0                    50      0 121 122 i
     *>  100.127.0.0/24   100.121.1.0                    50      0 121 131 i
     *>i                  100.68.1.3               0    150      0 131 i