## Introduction

The purpose of this part of the lab is introduce an Internet Exchange Point into our lab. IXPs are a very important if not critical component of today’s Internet architecture, and it is vitally important to ensure the correct configuration so that network operators gain maximum advantage from their participation at an IXP.

## Lab Topology

The lab topology has been further enhanced according to the diagram below.

We have introduced an Internet Exchange Point for each group to connect to. Each IXP also has a Route Server and a Services Router; the latter is used to give transit to any of the services that the IXP might be offering to its members (eg DNS, content caching, NTP, Looking Glass, etc). We will set this up later on in this lab.

## Configuring the IXP links

Each group should now configure their link to the IXPs according to the above diagram. Groups 1 to 4 connect to IXP 1, Groups 5 to 8 connect to IXP 2.

### Physical Link

Consult the IP Address Plan document for the address space used by the IXPs. Following the document, configure the interface on the Peering router accordingly. The example below shows the connection for Groups 1 to 4 to IXP1.

    interface GigabitEthernet 3
     description ASX0 link to IXP 1
     ip address 100.127.1.N 255.255.255.0
     no ip redirects
     no ip proxy-arp
     ipv6 address 2001:DB8:FFFF:1::N/64
     ipv6 nd prefix default no-advertise
     ipv6 nd ra suppress all
     no shutdown
    !

For Groups 5 to 8, the configuration example would look like this for connecting to IXP 2:

    interface GigabitEthernet 3
     description ASX0 link to IXP 2
     ip address 100.127.3.N 255.255.255.0
     no ip redirects
     no ip proxy-arp
     ipv6 address 2001:DB8:FFFE:1::N/64
     ipv6 nd prefix default no-advertise
     ipv6 nd ra suppress all
     no shutdown
    !

Note the subnet masks - this time the ethernet is NOT a point-to-point link but a shared LAN media. Once the interfaces have been configured, see if you can ping any of the other groups on their IXP addresses (both IPv4 and IPv6). Are you able to ping the Route Server too?

### Configuring IS-IS

Do not configure IS-IS towards any IXP peer! They are not part of your autonomous system.

However, so that traceroutes across the IXP do not break, we might wish to carry the IXP LAN address block within our IS-IS (not iBGP). To do this, we simply mark the IXP facing interface as passive in the IS-IS configuration. Here is an example:

    router isis asX0
     passive-interface GigabitEthernet 3

If you recall from the IS-IS presentation, this will tell IS-IS to announce the subnet attached to this interface.

Now all routers in your AS will see the IXP LAN address - check from your Core, Access and Border routers, just to make sure.

## Setting BGP Community

In earlier labs, we attached a specific community to each type of route we introduced into our IBGP. We are going to do the same thing for the routes we learn from our private peers, as the following sections show.

### Community Policy

This is the community we will be using:

Prefix Type | Community | Description
--- | --- | ---
IXP RS Peer addresses | AS:1300 | Any addresses our IXP RS peers send to us

### Community Configuration

Each group now needs to add one more community definition on their Border, Core, Peering and Access routers (not the Customer router, which is not in the group’s AS).

    ip community-list standard RS-peer permit X0:1300

## Configuring eBGP

We now configure eBGP on our Peering Router with the Exchange Point’s Route Server.

The Route Server for IXP 1 sits in AS 65534 and for IXP 2 it sits in AS 65533 - these are private ASes, and are not visible on the public Internet. In fact, we don’t want the IX Route Server AS to be visible inside our own AS either, and that’s one of the unique features of a Route Server1 - it does not add its AS into the AS path when distributing prefixes to its eBGP neighbours.

DO NOT forget to filter what you hear from the Route Server, and what you send to the Route Server. You should only accept the address blocks originated by the other IXP participants (they may send you more by mistake!), and you should only send prefixes you originate!

### Outbound Policy Configuration

First let’s implement the route-map which looks for our aggregate being tagged by the “aggregate” community (and customer-pi too), and only sends that. It’s similar to the one we created for our private peer in the previous lab:

    route-map IXP-RS-out permit 5
     description Prefixes to our IXP Peers
     match community aggregate
     match community customer-pi
    !

Note that the same route-map can be used for both IPv4 and IPv6 as it only matches against the BGP community values.

### Inbound Policy Configuration

For our inbound policy configuration, we are going to use a route-map from the outset as that will give us greater policy flexibility as we proceed through the remaining labs.

Now we need to set up inbound filters for the prefixes we expect to hear from the Route Server. Add a line for each group that we expect to hear from the Route Server.

Note carefully: Group 1 will only expect to hear prefixes from Groups 2 through 4; Group 8, will only expect to hear prefixes from Groups 5 to 7; and so on. Don’t accept prefixes from groups which are not present at your IXP.

IPv4 example:

    ip prefix-list IXP-RSv4 description IPv4 Prefixes from IXP Route-Server
    ip prefix-list IXP-RSv4 permit 100.68.<first-group>.0/24
    ..etc..

IPv6 Example:

    ipv6 prefix-list IXP-RSv6 description IPv6 Prefixes from IXP Route-Server
    ipv6 prefix-list IXP-RSv6 permit 2001:DB8:<first-group>::/48
    ..etc..

Once complete, each prefix list should have 3 entries in them.

And then we create a route-map to apply the prefix-list. First for IPv4:

    route-map IXP-RSv4-in permit 5
     description Filter and tag prefixes from IXP RS
     match ip address prefix-list IXP-RSv4
     set community X0:1300
    !

And for IPv6:

    route-map IXP-RSv6-in permit 5
     description Filter and tag prefixes from IXP RS
     match ipv6 address prefix-list IXP-RSv6
     set community X0:1300
    !

Notice we have to use different route-maps for IPv4 and IPv6 as they have address-family specific configuration (prefix-list) in them.

### Applying the Policy Configuration

Finally we apply the newly created inbound and outbound policies. Here is a configuration sample for the Peering Router for the groups connecting to IXP 1 - note that we are reusing some configuration we have set up earlier:

    router bgp X0
     address-family ipv4
      neighbor 100.127.1.254 remote-as 65534
      neighbor 100.127.1.254 description eBGP with IXP 1 RS
      neighbor 100.127.1.254 password ixp-rs
      neighbor 100.127.1.254 route-map IXP-RS-out out
      neighbor 100.127.1.254 route-map IXP-RSv4-in in
      neighbor 100.127.1.254 activate
    !
     address-family ipv6
      neighbor 2001:DB8:FFFF:1::FE remote-as 65534
      neighbor 2001:DB8:FFFF:1::FE description eBGP with IXP 1 RS
      neighbor 2001:DB8:FFFF:1::FE password ixp-rs
      neighbor 2001:DB8:FFFF:1::FE route-map IXP-RS-out out
      neighbor 2001:DB8:FFFF:1::FE route-map IXP-RSv6-in in
      neighbor 2001:DB8:FFFF:1::FE activate
    !

Groups 5 to 8 need to modify the above to suit their Peering Router configuration at IXP 2.

Once this has been configured, has the BGP session with the Route Server established? If not, why not? What do the router logs tell you?

You will notice from the logs that the router is complaining about a BGP peer AS not being in the announced AS path - this is Cisco IOS protecting against improper BGP announcements because, according to the BGP RFC, the AS number of the neighbouring AS must appear as the adjacent AS in the AS PATH. And if you recall from early on in the notes, that was a special feature of the Route Server: its AS does not appear in the path.

So we need to turn this safety check off in IOS:

    router bgp X0
     no bgp enforce-first-as

and once this has been done you will now see that the eBGP sessions with the Route Server will have been established.

### Analysing the outcome

Now that the BGP session with the Route Server is fully established, what do you now see in the BGP table?

What about the routes between you and your private peer that you set up earlier? Which is the best path now? Through the IXP, or over the private peering link?

Explain what you see to the workshop instructors. What can we do about this2?

## Supporting the IXP’s Services

### Background

You will have noticed from the IXP diagram that the IXP has services it offers to the participant members. These are usually the IXP website, DNS gTLD and ccTLD, usually a root name server instance, and perhaps even a CDN Cache or two. These services need transit to reach the Internet - this transit is not provided through the IXP, but via a separate transit connection that the IXP membership purchases from a transit provider (or two).

In our example, IXP1 is buying transit from AS121, and so has a direct connection to TR1 router; and IXP2 is buying transit from AS122, and so has a direct connection to the TR2 router.

### Adding Services to the Lab Topology

The workshop instructors will now enable the link from the IXP 1’s services router to AS121’s TR router, and from IXP 2’s services router to AS122’s TR router.

You should now notice the address space used by the IXP 1 and IXP 2 services infrastructure appearing in the routing table within your group. Consult the IP Address Plan document for the address space used by both IXPs and see if this is what you now see in your BGP table.

What does your BGP table show?

Check on your Border and Peering Routers.

### Updating Filters

You will have noticed that your Border router will have received the IPv4 and IPv6 Services address blocks of both IXPs from the upstream transit provider. This is because the upstream is sending all routes to you.

However, the IXP Services should also be visible across the Internet Exchange Point - after all, each Group is a member of an IX! And it is more efficient, lower latency, lower cost, than sending traffic via the transit provider.

We need to update our inbound filters for the Route Server peering to include the IXP’s Services address space. Let’s go back to the prefix-lists and add the extra lines in. Groups 1 to 4 need to do this:

    ip prefix-list IXP-RSv4 permit 100.127.0.0/24

and

    ipv6 prefix-list IXP-RSv6 permit 2001:DB8:FFFF::/48

and Groups 5 to 8 need to do this:

    ip prefix-list IXP-RSv4 permit 100.127.2.0/24

and

    ipv6 prefix-list IXP-RSv6 permit 2001:DB8:FFFE::/48

Once the filters have been updated, do an inbound route-refresh on the peering with the IXP’s Router Server.

What do you see in your BGP table now?

Compare what the Border Router has in its table with what the Peering Router has in its table.

Which is the best path?

## Appendix A - BIRD Route Server Configuration

This appendix shows the configuration of the route server as used for this workshop. It uses BIRD, the most commonly use Route Server software at Internet Exchange Points today3. BIRD runs on a variety of Linux operating systems - we use Ubuntu 18.04 LTS for these workshops.

    # This configuration based on:
    # https://gitlab.labs.nic.cz/labs/bird/-/wikis/Simple_route_server
    # https://gitlab.labs.nic.cz/labs/bird/-/wikis/transition-notes-to-bird-2
    # https://github.com/pierky/arouteserver/blob/master/examples/default/bird_v2.conf
    #
    # For more options see:
    # /usr/share/doc/bird2/examples/bird.conf
    # https://bird.network.cz/?get_doc&f=bird.html&v=20

    log "/var/log/bird/bird.log" all;
    #log syslog all;

    router id 100.127.1.254;
    define myas = 65534;

    protocol device { }

    # This function returns True if 'net' is a bogon prefix
    # or falls within a bogon prefix.

    function prefix_is_bogon()
    prefix set bogons_4;
    prefix set bogons_6;
    {
            bogons_4 = [
                    # Default route
                    0.0.0.0/0,

                    # IANA - Local Identification
                    0.0.0.0/8{8,32},

                    # RFC 1918 - Private Use
                    10.0.0.0/8{8,32},

                    # IANA - Loopback
                    127.0.0.0/8{8,32},

                    # RFC 6598 - Shared Address Space
                    # NSRC: commented out as we use this
                    # 100.64.0.0/10{10,32},

                    # RFC 3927 - Link Local
                    169.254.0.0/16{16,32},

                    # RFC 1918 - Private Use
                    172.16.0.0/12{12,32},

                    # RFC 5737 - TEST-NET-1
                    192.0.2.0/24{24,32},

                    # RFC 3068 - 6to4 prefix
                    192.88.99.0/24{24,32},

                    # RFC 1918 - Private Use
                    192.168.0.0/16{16,32},

                    # RFC 2544 - Network Interconnect Device Benchmark Testing
                    198.18.0.0/15{15,32},

                    # RFC 5737 - TEST-NET-2
                    198.51.100.0/24{24,32},

                    # RFC 5737 - TEST-NET-3
                    203.0.113.0/24{24,32},

                    # RFC 5771 - Multicast (formerly Class D) and Class E
                    224.0.0.0/3{3,32}
            ];
            bogons_6 = [
                    # Default route
                    ::/0,

                    # loopback, unspecified, v4-mapped
                    ::/8{8,128},

                    # RFC 6052 - IPv4-IPv6 Translation
                    64:ff9b::/96{96,128},

                    # RFC 6666 - reserved for Discard-Only Address Block
                    100::/8{8,128},

                    # RFC 4048 - Reserved by IETF
                    200::/7{7,128},

                    # RFC 4291 - Reserved by IETF
                    400::/6{6,128},

                    # RFC 4291 - Reserved by IETF
                    800::/5{5,128},

                    # RFC 4291 - Reserved by IETF
                    1000::/4{4,128},

                    # RFC 4380 - Teredo prefix
                    2001::/32{32,128},

                    # RFC 5180 - Benchmarking
                    2001:2::/48{48,128},

                    # RFC 7450 - Automatic Multicast Tunneling
                    2001:3::/32{32,128},

                    # RFC 4843 - Deprecated ORCHID
                    # NSRC: commented out as we use 2001:18::/31
                    # 2001:10::/28{28,128},

                    # RFC 7343 - ORCHIDv2
                    2001:20::/28{28,128},

                    # RFC 3849 - NON-ROUTABLE range to be used for documentation purpose
                    # NSRC: commented out as we use it
                    # 2001:db8::/32{32,128},

                    # RFC 3068 - 6to4 prefix
                    2002::/16{16,128},

                    # RFC 5156 - used for the 6bone but was returned
                    3ffe::/16{16,128},

                    # RFC 4291 - Reserved by IETF
                    4000::/2{2,128},

                    # RFC 4291 - Reserved by IETF
                    8000::/1{1,128}
            ];

            if net.type = NET_IP4 then
                    if net ~ bogons_4 then return true;
            if net.type = NET_IP6 then
                    if net ~ bogons_6 then return true;
            return false;
    }

    ####
    # Protocol template

    template bgp PEERS {
      local as myas;
      rs client;
    }

    ####
    # Configuration of BGP peer follows

    ###
    filter bgp_in_AS131
    prefix set allnet;
    int set allas;
    {
      if (prefix_is_bogon()) then reject;
      if (bgp_path.first != 131 ) then reject;

      allas = [ 131 ];
      if ! (bgp_path.last ~ allas) then reject;

      allnet = [ 100.127.0.0/24, 2001:DB8:FFFF::/48 ];
      if ! (net ~ allnet) then reject;

      accept;
    }

    protocol bgp SR1v4 from PEERS {
      description "SR1 - IPv4";
      neighbor 100.127.1.253 as 131;
      ttl-security;
      password "ixp-rs";
      ipv4 {
        import filter bgp_in_AS131;
        import limit 10000 action restart;
        export all;
      };
    }

    protocol bgp SR1v6 from PEERS {
      description "SR1 - IPv6";
      neighbor 2001:DB8:FFFF:1::FD as 131;
      ttl-security;
      password "ixp-rs";
      ipv6 {
        import filter bgp_in_AS131;
        import limit 10000 action restart;
        export all;
      };
    }

    ### AS10 - Group 1
    filter bgp_in_AS10
    prefix set allnet;
    int set allas;
    {
      if (prefix_is_bogon()) then reject;
      if (bgp_path.first != 10 ) then reject;

      allas = [ 10, 135533 ];
      if ! (bgp_path.last ~ allas) then reject;

      allnet = [ 100.68.1.0/24, 100.68.101.0/24, 61.45.248.0/24,
                 2001:DB8:1::/48, 2001:DB8:101::/48 ];
      if ! (net ~ allnet) then reject;

      accept;
    }

    protocol bgp R10v4 from PEERS {
      description "Group 1 - IPv4";
      neighbor 100.127.1.1 as 10;
      password "ixp-rs";
      ipv4 {
        import filter bgp_in_AS10;
        import limit 10000 action restart;
        export all;
      };
    }

    protocol bgp R10v6 from PEERS {
      description "Group 1 - IPv6";
      neighbor 2001:DB8:FFFF:1::1 as 10;
      password "ixp-rs";
      ipv6 {
        import filter bgp_in_AS10;
        import limit 10000 action restart;
        export all;
      };
    }

    ### AS20 - Group 2
    filter bgp_in_AS20
    prefix set allnet;
    int set allas;
    {
      if (prefix_is_bogon()) then reject;
      if (bgp_path.first != 20 ) then reject;

      allas = [ 20, 135534 ];
      if ! (bgp_path.last ~ allas) then reject;

      allnet = [ 100.68.2.0/24, 100.68.102.0/24, 61.45.249.0/24,
                 2001:DB8:2::/48, 2001:DB8:102::/48 ];
      if ! (net ~ allnet) then reject;

      accept;
    }

    protocol bgp R20v4 from PEERS {
      description "Group 2 - IPv4";
      neighbor 100.127.1.2 as 20;
      password "ixp-rs";
      ipv4 {
        import filter bgp_in_AS20;
        import limit 10000 action restart;
        export all;
      };
    }

    protocol bgp R20v6 from PEERS {
      description "Group 2 - IPv6";
      neighbor 2001:DB8:FFFF:1::2 as 20;
      password "ixp-rs";
      ipv6 {
        import filter bgp_in_AS20;
        import limit 10000 action restart;
        export all;
      };
    }

    ### AS30 - Group 3
    filter bgp_in_AS30
    prefix set allnet;
    int set allas;
    {
      if (prefix_is_bogon()) then reject;
      if (bgp_path.first != 30 ) then reject;

      allas = [ 30, 135535 ];
      if ! (bgp_path.last ~ allas) then reject;

      allnet = [ 100.68.3.0/24, 100.68.103.0/24, 61.45.250.0/24,
                 2001:DB8:3::/48, 2001:DB8:103::/48 ];
      if ! (net ~ allnet) then reject;

      accept;
    }

    protocol bgp R30v4 from PEERS {
      description "Group 3 - IPv4";
      neighbor 100.127.1.3 as 30;
      password "ixp-rs";
      ipv4 {
        import filter bgp_in_AS30;
        import limit 10000 action restart;
        export all;
      };
    }

    protocol bgp R30v6 from PEERS {
      description "Group 3 - IPv6";
      neighbor 2001:DB8:FFFF:1::3 as 30;
      password "ixp-rs";
      ipv6 {
        import filter bgp_in_AS30;
        import limit 10000 action restart;
        export all;
      };
    }

    ### AS40 - Group 4
    filter bgp_in_AS40
    prefix set allnet;
    int set allas;
    {
      if (prefix_is_bogon()) then reject;
      if (bgp_path.first != 40 ) then reject;

      allas = [ 40, 135536 ];
      if ! (bgp_path.last ~ allas) then reject;

      allnet = [ 100.68.4.0/24, 100.68.104.0/24, 61.45.251.0/24,
                 2001:DB8:4::/48, 2001:DB8:104::/48 ];
      if ! (net ~ allnet) then reject;

      accept;
    }

    protocol bgp R40v4 from PEERS {
      description "Group 4 - IPv4";
      neighbor 100.127.1.4 as 40;
      password "ixp-rs";
      ipv4 {
        import filter bgp_in_AS40;
        import limit 10000 action restart;
        export all;
      };
    }

    protocol bgp R40v6 from PEERS {
      description "Group 4 - IPv6";
      neighbor 2001:DB8:FFFF:1::4 as 40;
      password "ixp-rs";
      ipv6 {
        import filter bgp_in_AS40;
        import limit 10000 action restart;
        export all;
      };
    }

## Appendix B - Cisco IOS Route Server Configuration

This appendix shows the configuration of the route server used for older versions of this workshop. It is Cisco IOS based - in the mid 2000s Cisco had a project to produce a route server implementation in IOS, but it lacked traction amongst IXPs and showed relatively poor performance when compared with Open Source implementations such as BIRD. However, the code remains in IOS/IOS-XE on the higher end platforms.

    interface GigabitEthernet0/0
     description IXP LAN
     ip address 100.127.1.254 255.255.255.0
     no ip redirects
     no ip proxy-arp
     ipv6 address 2001:DB8:FFFF:1::FE/64
     ipv6 nd prefix default no-advertise
     ipv6 nd ra suppress all
    !
    router bgp 65534
     bgp log-neighbor-changes
     bgp deterministic-med
     no bgp default ipv4-unicast
     neighbor ixp-peers peer-group
     neighbor ixp-peers password ixp-rs
     neighbor v6ixp-peers peer-group
     neighbor v6ixp-peers password ixp-rs
     neighbor 100.127.1.1 remote-as 10
     neighbor 100.127.1.1 peer-group ixp-peers
     neighbor 100.127.1.1 description AS10 peer
     neighbor 100.127.1.2 remote-as 20
     neighbor 100.127.1.2 peer-group ixp-peers
     neighbor 100.127.1.2 description AS20 peer
     neighbor 100.127.1.3 remote-as 30
     neighbor 100.127.1.3 peer-group ixp-peers
     neighbor 100.127.1.3 description AS30 peer
     neighbor 100.127.1.4 remote-as 40
     neighbor 100.127.1.4 peer-group ixp-peers
     neighbor 100.127.1.4 description AS40 peer
     neighbor 100.127.1.5 remote-as 50
     neighbor 100.127.1.5 peer-group ixp-peers
     neighbor 100.127.1.5 description AS50 peer
     neighbor 100.127.1.6 remote-as 60
     neighbor 100.127.1.6 peer-group ixp-peers
     neighbor 100.127.1.6 description AS60 peer
     neighbor 100.127.1.7 remote-as 70
     neighbor 100.127.1.7 peer-group ixp-peers
     neighbor 100.127.1.7 description AS70 peer
     neighbor 100.127.1.8 remote-as 80
     neighbor 100.127.1.8 peer-group ixp-peers
     neighbor 100.127.1.8 description AS80 peer
     neighbor 100.127.1.253 remote-as 131
     neighbor 100.127.1.253 peer-group ixp-peers
     neighbor 100.127.1.253 description IXP Services
     neighbor 2001:DB8:FFFF:1::1 remote-as 10
     neighbor 2001:DB8:FFFF:1::1 peer-group v6ixp-peers
     neighbor 2001:DB8:FFFF:1::1 description AS10 peer
     neighbor 2001:DB8:FFFF:1::2 remote-as 20
     neighbor 2001:DB8:FFFF:1::2 peer-group v6ixp-peers
     neighbor 2001:DB8:FFFF:1::2 description AS20 peer
     neighbor 2001:DB8:FFFF:1::3 remote-as 30
     neighbor 2001:DB8:FFFF:1::3 peer-group v6ixp-peers
     neighbor 2001:DB8:FFFF:1::3 description AS30 peer
     neighbor 2001:DB8:FFFF:1::4 remote-as 40
     neighbor 2001:DB8:FFFF:1::4 peer-group v6ixp-peers
     neighbor 2001:DB8:FFFF:1::4 description AS40 peer
     neighbor 2001:DB8:FFFF:1::5 remote-as 50
     neighbor 2001:DB8:FFFF:1::5 peer-group v6ixp-peers
     neighbor 2001:DB8:FFFF:1::5 description AS50 peer
     neighbor 2001:DB8:FFFF:1::6 remote-as 60
     neighbor 2001:DB8:FFFF:1::6 peer-group v6ixp-peers
     neighbor 2001:DB8:FFFF:1::6 description AS60 peer
     neighbor 2001:DB8:FFFF:1::7 remote-as 70
     neighbor 2001:DB8:FFFF:1::7 peer-group v6ixp-peers
     neighbor 2001:DB8:FFFF:1::7 description AS70 peer
     neighbor 2001:DB8:FFFF:1::8 remote-as 80
     neighbor 2001:DB8:FFFF:1::8 peer-group v6ixp-peers
     neighbor 2001:DB8:FFFF:1::8 description AS80 peer
     neighbor 2001:DB8:FFFF:1::FD remote-as 131
     neighbor 2001:DB8:FFFF:1::FD peer-group v6ixp-peers
     neighbor 2001:DB8:FFFF:1::FD description IXP Services
    !
     address-family ipv4
      neighbor ixp-peers route-server-client
      neighbor 100.127.1.1 activate
      neighbor 100.127.1.2 activate
      neighbor 100.127.1.3 activate
      neighbor 100.127.1.4 activate
      neighbor 100.127.1.5 activate
      neighbor 100.127.1.6 activate
      neighbor 100.127.1.7 activate
      neighbor 100.127.1.8 activate
      neighbor 100.127.1.253 activate
      distance bgp 200 200 200
     exit-address-family
    !
     address-family ipv6
      neighbor v6ixp-peers route-server-client
      neighbor 2001:DB8:FFFF:1::1 activate
      neighbor 2001:DB8:FFFF:1::2 activate
      neighbor 2001:DB8:FFFF:1::3 activate
      neighbor 2001:DB8:FFFF:1::4 activate
      neighbor 2001:DB8:FFFF:1::5 activate
      neighbor 2001:DB8:FFFF:1::6 activate
      neighbor 2001:DB8:FFFF:1::7 activate
      neighbor 2001:DB8:FFFF:1::8 activate
      neighbor 2001:DB8:FFFF:1::FD activate
      distance bgp 200 200 200
     exit-address-family
    !
    ip route 0.0.0.0 0.0.0.0 Null0
    !
    ipv6 route ::/0 Null0
    !

1. See RFC7948 for a complete and detailed description of how a Route Server operates and can be used at an Internet Exchange Point.↩︎

2. Cisco IOS BGP Best Path Selection process includes a step which chooses the oldest path stored in the BGP table. So we are seeing the results of this. We brought up the Private Peering first, and the IXP Peering after that. So the router prefers the Private Peering. Shutting down and then bringing up the private peering again will result in the best path between the adjacent ASNs going over the IXP. It’s a not deterministic, which is a problem. You can disable this in IOS by adding in the `bgp bestpath compare-routerid` configuration under the BGP process - then the router will not compare the age of the prefixes heard, but compare the router-id’s of the neighbours which sent the prefix.↩︎

3. The most popular Route Server software today is BIRD, used by most IXPs worldwide. The LINX modified version of Quagga is also used (Quagga itself is not scalable and can only handle a few neighbours). And GoBGP is also another Route Server candidate being used by some IXPs.↩︎