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.
A reminder of the lab topology is in the diagram below.
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).
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 create two route-maps. The first route-map is for the private peer:
route-map private-peer-in permit 5
description Local pref for Private Peer
set local-preference 200
!The second route-map is for the RS peering:
route-map IXP-RS-in permit 5
description Local pref for IXP RS Peers
set local-preference 150
!Once we create the route-maps, we apply them to the BGP peerings with the private peer and with the IXP Route Server respectively. Here is an example:
router bgp X0
address-family ipv4
neighbor <ptp-v4> route-map private-peer-in in
neighbor 100.127.1.254 route-map IXP-RS-in in
!
address-family ipv6
neighbor <ptp-v6> route-map private-peer-in in
neighbor 2001:DB8:FFFF:1::FE route-map IXP-RS-in in
!Once this is configured, do a route-refresh inbound on the two peerings. You should now see the local preferences attached to the routes from the IXP and from the private peer. What has happened now?
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 Transit-in permit 5
description Do not propogate the default route
match ip address prefix-list DEFAULT-ROUTE
set community no-advertise
!
route-map Transit-in permit 10
!
route-map Transitv6-in permit 5
description Do not propogate the default route
match ipv6 address prefix-list DEFAULT-v6ROUTE
set community no-advertise
!
route-map Transitv6-in permit 10
!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 Transit-in permit 10
description Local pref for Upstream routes
set local-preference 50
!
route-map Transitv6-in permit 10
description Local pref for Upstream routes
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?
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 122 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
*>i 100.68.6.0/24 100.68.1.3 0 150 0 60 i
* 100.121.1.0 50 0 121 122 60 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