IXP Bilateral Peering Lab

Peering & IXP Workshop

Introduction

The purpose of this part of the lab is introduce bi-lateral peering at the Internet Exchange Point in our lab.

Peering with Route Server or Peering Directly with IXP peers?

The next part of this workshop lab is to investigate how to set up peering directly with our IXP Peers. While peering with the IXP Route Server is sufficient for many operators, others have specific peering requirements that often cannot be met by the Route Server (at least in the basic configuration we have here).

There are three types of peering policies adopted by network operators today:

Peering Policy	Description
Open	Network Operator will peer with all comers, no questions asked. At an IXP this means they will peer with the Route Server.
Selective	Network Operator will usually peer with most operators, but enters a conversation with the peering partner first before establishing the link. At an IXP this means they will set up a direct peering across the IX fabric, not with the Route Server.
Restrictive	Network Operator will choose who they peer with, under very stringent conditions. They rarely show up at an IXP, and if they do, peering will be directly across the IX fabric.

We have set up our peering at the moment to assume that all groups have an Open peering policy. But what if they had a Selective policy instead? How do we configure that?

Note that the two Transit providers are not present at the IXP. They have a Restrictive peering policy - they will peer with each other, but none of the other autonomous systems in the lab. This is normal - IXPs are for local interconnects, as you will have learned in the presentation.

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 Bilateral Peer addresses	AS:1200	Any addresses our IXP Bilateral 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 bilateral-peer permit X0:1200

Configuring EBGP

Bi-lateral peering across IXP Fabric

What we will do now is modify our eBGP at the IXP so that we also include a direct eBGP session with our IXP peers. We’ll set this up to supplement the Route Server (or we could simply remove the Route Server peering once we have peered with all members of the IXP).

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 earlier:

route-map bilateral-out permit 5
 description Prefixes to our Bilateral 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. And we can use the same one for each peer as we have the same outbound policy for each.

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.

First let’s create the prefix filters we need to use for the bi-lateral peerings. We already have our outbound prefix filter so we don’t need to create that. But we need to create a prefix-list for every bi-lateral peer we are going to peer with across the IX, like this:

ip prefix-list ASY0-ROUTESv4 permit 100.68.Y.0/24
ipv6 prefix-list ASY0-ROUTESv6 permit 2001:DB8:Y::/48
!

Hint: replace “Y” with the Group numbers that you are going to peer with.

Once we have created the prefix filters for each group, we now need to create a route-map for each group too! Each route-map will call its respective prefix-list that we created above.

IPv4 example:

route-map ASY0-bilateralv4-in permit 5
 description Filter and tag prefixes from ASY0 bilateral peer
 match ip address prefix-list ASY0-ROUTESv4
 set community X0:1200
!

IPv6 example:

route-map ASY0-bilateralv6-in permit 5
 description Filter and tag prefixes from ASY0 bilateral peer
 match ipv6 address prefix-list ASY0-ROUTESv6
 set community X0:1200
!

Hint: replace “Y” with the Group numbers that you are going to peer with.

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

Creating a Peer-Group

Given we are going go to set up bi-lateral peerings with all the other ASNs at the IX, let’s create a peer-group to make this simpler to scale in the future (if we need to add more peers, or make changes to our outbound policy, etc). Note that the peer-group will contain only our outbound policy - our inbound policy (the per neighbour filters) will be applied directly to the peer.

router bgp X0
 address-family ipv4
  neighbor IXP-bilateralv4 peer-group
  neighbor IXP-bilateralv4 description eBGP with bi-lateral peers at IXP
  neighbor IXP-bilateralv4 password BGPlab
  neighbor IXP-bilateralv4 route-map bilateral-out out
!
 address-family ipv6
  neighbor IXP-bilateralv6 peer-group
  neighbor IXP-bilateralv6 description eBGP with bi-lateral peers at IXP
  neighbor IXP-bilateralv6 password BGPlab
  neighbor IXP-bilateralv6 route-map bilateral-out out
!

Applying the Policy Configuration

Once the peer-group is created, we then apply it to direct eBGP sessions between ourselves and all the other autonomous systems at the IXP - don’t forget to apply the per-neighbour inbound route-map we created earlier:

router bgp X0
 address-family ipv4
  neighbor 100.127.1.Y remote-as Y0
  neighbor 100.127.1.Y description eBGP with ASY0
  neighbor 100.127.1.Y peer-group IXP-bilateralv4
  neighbor 100.127.1.Y route-map ASY0-bilateralv4-in in
!
 address-family ipv6
  neighbor 2001:DB8:FFFF:1::Y remote-as Y0
  neighbor 2001:DB8:FFFF:1::Y description eBGP with ASY0
  neighbor 2001:DB8:FFFF:1::Y peer-group IXP-bilateralv6
  neighbor 2001:DB8:FFFF:1::Y route-map ASY0-bilateralv6-in in
!

Once all this is completed, you should see two paths to your IXP peers - they are almost indistinguishable apart from the router-id of the neighbouring router - one will be of the route-server, the other will be of the direct eBGP peer.

Which is preferred?

Preferring Bi-lateral Peer over RS Peering

To distinguish between the two paths to the same autonomous system we will now add the local preference appropriate for the bi-lateral peering to all the route-maps we just created (see the previous lab exercise for the different local preference values). Here is the IPv4 example (do this for all the route-maps!):

route-map ASY0-bilateralv4-in permit 5
 set local-preference 170
!

and here is the IPv6 example:

route-map ASY0-bilateralv6-in permit 5
 set local-preference 170
!

Run a route-refresh on the peerings. What do you see now?

Once you are peering with all of the members of the IXP, you can remove your peering with the Route Server if you wish:

if you have decided that your group has a Selective Peering Policy, you may not want to peer with the Route Server, as then you won’t be able to select the new peers (unless the Route Server operator offers a more sophisticated configuration than we have here in the lab)
Many operators bi-lateral peer across the IXP but retain the Route Server peering as backup as well - for redundancy purposes.