The purpose of this part of the lab is introduce bi-lateral peering at the Internet Exchange Point in our lab.
The final 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. |
| Restricted | 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 Restricted 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.
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).
Here is a configuration example, peering with another AS present at the IXP (AS “Y”). (Again noting that we are re-using configuration created earlier on.)
First let’s create the prefix filters we need to use for the bi-lateral peerings.
ip prefix-list ASX0-block permit 100.68.X.0/24
ipv6 prefix-list ASX0-v6block permit 2001:DB8:X::/48
!
ip prefix-list ASY0-block permit 100.68.Y.0/24
ipv6 prefix-list ASY0-v6block permit 2001:DB8:Y::/48
!And then we set up the direct eBGP sessions between ourselves and all the other autonomous systems at the IXP - don’t forget to apply the prefix-filters:
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 password cisco
neighbor 100.127.1.Y prefix-list ASX0-block out
neighbor 100.127.1.Y prefix-list ASY0-block 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 password cisco
neighbor 2001:DB8:FFFF:1::Y prefix-list ASX0-v6block out
neighbor 2001:DB8:FFFF:1::Y prefix-list ASY0-v6block in
!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?
To distinguish between the two paths to the same autonomous system we will now create a route-map setting the local preference appropriate for the bi-lateral peering (see the previous lab exercise for the different local preference values). Note that this route-map sets local preference on everything received - and it has no address family specific configuration so it can be used on both the IPv4 and IPv6 peerings:
route-map IXP-bilateral-in permit 10
set local-preference 170
!And then we apply them to the BGP sessions:
router bgp X0
address-family ipv4
neighbor 100.127.1.Y route-map IXP-bilateral-in in
!
address-family ipv6
neighbor 2001:DB8:FFFF:1::Y route-map IXP-bilateral-in in
!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.