## Introduction

The purpose of this part of the lab is to set up private peering between adjacent autonomous systems. In our case, AS10 will private peer with AS20, AS30 with AS40, AS50 with AS60, and AS70 with AS80. We will use what we have learned so far to ensure that the adjacent ASNs only hear the routes they are meant to hear - a true private peering.

## Lab Topology

The lab topology has been enhanced according to the diagram below. We simply add in the peering links mentioned in the preamble.

## Configuring the Private Peering Links

Each group should now configure the private peering links as shown in the diagram.

### Physical Link

Agree on which addresses should be used for the point-to-point links. Typically one group will contribute the IPv4 /31 and IPv6 /127 on the link. Look at the provided address plan for some spare point-to-point link addresses you can use.

    interface GigabitEthernet 0/2
     description Link to Group Y Peering Router
     ip address <ptp-link> 255.255.255.254
     no ip directed-broadcast
     no ip redirects
     no ip proxy-arp
     ipv6 address <v6ptp-link>/127
     ipv6 nd prefix default no-advertise
     ipv6 nd ra suppress all
     no shutdown
    !

Once the interfaces have been configured make sure that the links can be pinged on both IPv4 and IPv6 endpoints.

### Configuring IS-IS

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

## 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
--- | --- | ---
Private Peer addresses | AS:1100 | Any addresses our private 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 private-peer permit X0:1100

## Configuring eBGP

We now configure eBGP with the private peer. Don’t forget to filter what you hear from the private peer, and what you send to them. You should only accept their address blocks from them (they may send you more by mistake!), and you should only send prefixes you have originated!

### 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. We did this in the previous lab on the Border router, so now we implement a similar route-map on the Peering router:

    route-map private-peer-out permit 5
     description Prefixes to our Private Peer
     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.

First we set up prefix lists for our private peer’s address blocks:

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

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

    route-map private-peerv4-in permit 5
     description Filter and tag prefixes from Private Peer
     match ip address prefix-list ASY0-ROUTESv4
     set community X0:1100
    !

And for IPv6:

    route-map private-peerv6-in permit 5
     description Filter and tag prefixes from Private Peer
     match ipv6 address prefix-list ASY0-ROUTESv6
     set community X0:1100
    !

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

### Applying the Policy Configuration

Finally we apply the newly created inbound and outbound policies. Here is a configuration sample, first for IPv4:

    router bgp X0
    !
     address-family ipv4
      neighbor <ptp-v4> remote-as Y0
      neighbor <ptp-v4> description eBGP with ASY0
      neighbor <ptp-v4> password BGPlab
      neighbor <ptp-v4> route-map private-peer-out out
      neighbor <ptp-v4> route-map private-peerv4-in in
      neighbor <ptp-v4> activate
    !

and then for IPv6:

    router bgp X0
    !
     address-family ipv6
      neighbor <ptp-v6> remote-as Y0
      neighbor <ptp-v6> description eBGP with ASY0
      neighbor <ptp-v6> password BGPlab
      neighbor <ptp-v6> route-map private-peer-out out
      neighbor <ptp-v6> route-map private-peerv6-in in
      neighbor <ptp-v6> activate
    !

Once this has been configured, you should now see your private peer originated routes coming from them, and you should be able to see your aggregate being sent to your private peer:

    show ip bgp neigh <ptp-v4> routes
    show bgp ipv6 uni neigh <ptp-v6> routes

and to show what you are sending:

    show ip bgp neigh <ptp-v4> advertised-routes
    show bgp ipv6 uni neigh <ptp-v6> advertised-routes

### Confirmation & Testing

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? What does a 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 your upstream provider. If this is not the case, you will need to start doing some troubleshooting!

As with previous labs, try and ping your private peer’s routers from your routers. What do you see? If you ping your neighbour from your Peering Router, you might find that you have to send the pings sourced from the Loopback 0 interface of your Peering Router. How do you do that? Use the CLI help to find out.