The purpose of this part of the lab is to show how to propagate BGP customer routers and how to configure multihoming and traffic engineering when the customer multihomes between two members of an IXP.
The diagram shows how each customer is multi-homed between two upstreams. The customers of Group 1 and 2, 3 and 4, 5 and 6, and 7 and 8 respectively, multihome on to each others networks.
This scenario shows how to connect a multihoming customer who has their own address space. It will test our configuration which supports Provider Independent Address space (the customer-pi community and associated policy we configured earlier in the IBGP Lab).
We will leave the existing configuration which demonstrated how a customer who’d get their address space from their upstream provider, and the necessary configuration to support it appearing on the Customer, Access, and Peering Routers (the latter for inbound filters from the Private and IXP Peers).
We now will set up BGP on the Customer Router.
The new address block is listed in the Address Plan under the Customer Provider Independent section. Refer to the address plan, and make a note of your IPv4 and IPv6 address blocks.
Next, we create the BGP process using the AS number 1000X0 (where X is your Group number) and originate the address block in question. Here is an example configuration:
router bgp 1000X0
bgp log-neighbor-changes
bgp deterministic-med
no bgp default ipv4-unicast
!
address-family ipv4
distance bgp 200 200 200
network 100.68.10X.0 mask 255.255.255.0
!
address-family ipv6
distance bgp 200 200 200
network 2001:DB8:10X::/48
!
ip route 100.68.10X.0 255.255.255.0 null0
ipv6 route 2001:DB8:10X::/48 null0
!Next we need to set up eBGP with the Access Router. First we create the prefix-lists needed, for inbound and outbound filtering:
ip prefix-list CustX-out permit 100.68.10X.0/24
!
ip prefix-list default permit 0.0.0.0/0Do the same for IPv6:
ipv6 prefix-list CustX-v6out permit 2001:DB8:10X::/48
!
ipv6 prefix-list v6default permit ::/0and then applying the configuration to the eBGP neighbour:
router bgp 1000X0
!
address-family ipv4
neighbor 100.68.X.34 remote-as X0
neighbor 100.68.X.34 description eBGP with ASX0
neighbor 100.68.X.34 prefix-list CustX-out out
neighbor 100.68.X.34 prefix-list default in
!
address-family ipv6
neighbor 2001:DB8:X:31:: remote-as X0
neighbor 2001:DB8:X:31:: description eBGP with ASX0
neighbor 2001:DB8:X:31:: prefix-list CustX-v6out out
neighbor 2001:DB8:X:31:: prefix-list v6default in
!We also need to create an anchor point for the new address space. We’ve already used Loopback 0 for a previous anchor, so let’s use Loopback 1 for the new one:
interface Loopback 1
description Address Anchor for New Block
ip address 100.68.10X.1 255.255.255.255
ipv6 address 2001:DB8:10X::1/128
!
We now need to set up the matching configuration on the Access Router in each group’s AS. Again we need to set up prefix-lists before we set up the eBGP session - here is an example of the IPv4 prefix-list for all groups:
ip prefix-list CustX-in permit 100.68.10X.0/24
!
ip prefix-list default permit 0.0.0.0/0
!And the IPv6 prefix-list for all groups:
ipv6 prefix-list CustX-v6in permit 2001:DB8:10X::/48
!
ipv6 prefix-list v6default permit ::/0
!We now set up the eBGP session on the Access router:
router bgp X0
!
address-family ipv4
neighbor 100.68.X.35 remote-as 1000X0
neighbor 100.68.X.35 description eBGP with Customer
neighbor 100.68.X.35 prefix-list CustX-in in
neighbor 100.68.X.35 prefix-list default out
neighbor 100.68.X.35 default-originate
!
address-family ipv6
neighbor 2001:DB8:X:31::1 remote-as 1000X0
neighbor 2001:DB8:X:31::1 description eBGP with Customer
neighbor 2001:DB8:X:31::1 prefix-list CustX-v6in in
neighbor 2001:DB8:X:31::1 prefix-list v6default out
neighbor 2001:DB8:X:31::1 default-originate
!Note the default-originate on the eBGP session - we are announcing the default route to our customer as they do not need the full BGP table or any other routes apart from default.
Because we are now getting a customer originated route from a provider independent block, we need to tag it with the correct community and set local-preference appropriately according to our inbound policies (IXP Policy Lab). We noted that Customer independent addresses (which this one) go into community AS:1005, and all customer routes are tagged with local-preference of 2501.
To do this, we create a route-map, like this:
route-map set-pi-community permit 5
description Set community on Provider Independent prefix
set community X0:1005
set local-preference 250
!and then we add it to the BGP configuration:
router bgp X0
!
address-family ipv4
neighbor 100.68.X.35 route-map set-pi-community in
!
address-family ipv6
neighbor 2001:DB8:X:31::1 route-map set-pi-community in
!If the peering is already up from the previous step, you will need to do a route-refresh so that the community becomes attached to the prefix being announced.
Once the Access Router is configured, we can now go back to the Customer Router and remove the static default routes for IPv4 and IPv6:
no ip route 0.0.0.0 0.0.0.0 100.68.X.34
no ipv6 route ::/0 2001:DB8:X:31::Confirm that connectivity still works, as you did earlier on in the eBGP lab - routing between the Customer Router and its upstream should now be relying on BGP.
Now check on the Core Router for the prefix announcements originated by the Customer Router, and being transited by the Access Router. Use the sh ip bgp and sh bgp ipv6 unicast commands to find out the state of the IPv4 and IPv6 BGP tables. What do you see?
You should see that the 100.68.10X.0/24 and 2001:DB8:10X::/48 prefixes are being originated from AS 1000X0. Here is an example from the Border Router in Group 1 from a previous version of this lab:
B1#show bgp ipv4 unicast 100.68.101.0
BGP routing table entry for 100.68.101.0/24, version 15
BGP Bestpath: deterministic-med
Paths: (1 available, best #1, table default)
Advertised to update-groups:
1
Refresh Epoch 1
100010
100.68.1.4 (metric 4) from 100.68.1.2 (100.68.1.2)
Origin IGP, metric 0, localpref 100, valid, internal, best
Community: 10:1005
Originator: 100.68.1.4, Cluster list: 100.68.1.2
rx pathid: 0, tx pathid: 0x0Compare the above with what you see. Also check the IPv6 status. You should see an output similar to the following:
B1#show bgp ipv6 unicast 2001:DB8:101::/48
BGP routing table entry for 2001:DB8:101::/48, version 15
BGP Bestpath: deterministic-med
Paths: (1 available, best #1, table default)
Advertised to update-groups:
1
Refresh Epoch 1
100010
2001:DB8:1::4 (metric 4) from 2001:DB8:1::2 (100.68.1.2)
Origin IGP, metric 0, localpref 100, valid, internal, best
Community: 10:1005
Originator: 100.68.1.4, Cluster list: 100.68.1.2
rx pathid: 0, tx pathid: 0x0Are you able to explain everything you see in the show bgp outputs above?
Ask your peers and upstreams if they see any prefix announcements coming from you with AS1000X0 as the origin AS.
What do they see? Are you able to explain what is going on?
As this updated customer is one of our BGP customers, and other Groups have the same set up, we need to update our filters on the Peering Router to allow these new prefixes from our peers to get access to our network.
NOTE: We don’t need to do anything about outbound announcements though. Are you able to explain why?
Before you start making configuration changes, check the current configuration. You will see that you have prefix lists for the EBGP peerings (private, bi-lateral, Route Server) on the Peering Router looking like this:
ip prefix-list AS10-block permit 100.68.1.0/24
!
ip prefix-list AS20-block permit 100.68.2.0/24
!
ip prefix-list AS30-block permit 100.68.3.0/24
!
ip prefix-list AS40-block permit 100.68.4.0/24
!
ip prefix-list AS50-block permit 100.68.5.0/24
!
ip prefix-list AS60-block permit 100.68.6.0/24
!
ip prefix-list AS70-block permit 100.68.7.0/24
!
ip prefix-list AS80-block permit 100.68.8.0/24
!
ip prefix-list IXP-RS description IPv4 prefixes from RouteServer
ip prefix-list IXP-RS permit 100.68.1.0/24
ip prefix-list IXP-RS permit 100.68.2.0/24
ip prefix-list IXP-RS permit 100.68.3.0/24
ip prefix-list IXP-RS permit 100.68.4.0/24
ip prefix-list IXP-RS permit 100.68.5.0/24
ip prefix-list IXP-RS permit 100.68.6.0/24
ip prefix-list IXP-RS permit 100.68.7.0/24
ip prefix-list IXP-RS permit 100.68.8.0/24
ip prefix-list IXP-RS permit 100.127.0.0/24
!with similar configuration for IPv6.
You now want to allow the new address space from the (now) BGP customer you have to come in to the Peering Router. This means updating the above prefix-lists to add in the new address space.
Let’s consider carefully what we would hear from each peer.
Consider this example: if you are Group 1, you’d like your Private Peer, Group 2, to send you both their BGP Customer address (100.68.102.0/24 & 2001:DB8:102::/48) and your BGP Customer address (100.68.101.0/24 & 2001:DB8:101::/48) to you. Why?2
This means updating each of the ASn0-block and ASn0-v6block prefix-lists to include both of the peer AS’s BGP customers: For example:
From AS10 you’d expect to hear 100.68.101.0/24 and 100.68.102.0/24.
From AS20 you’d expect to hear 100.68.101.0/24 and 100.68.102.0/24.
From AS30 you’d expect to hear 100.68.103.0/24 and 100.68.104.0/24.
From AS40 you’d expect to hear 100.68.103.0/24 and 100.68.104.0/24.
etc
The prefix lists will therefore need to be updated to include what is shown in the example below:
ip prefix-list AS10-block permit 100.68.101.0/24
ip prefix-list AS10-block permit 100.68.102.0/24
!
ip prefix-list AS20-block permit 100.68.101.0/24
ip prefix-list AS20-block permit 100.68.102.0/24
!
ip prefix-list AS30-block permit 100.68.103.0/24
ip prefix-list AS30-block permit 100.68.104.0/24
!
ip prefix-list AS40-block permit 100.68.103.0/24
ip prefix-list AS40-block permit 100.68.104.0/24
!
ip prefix-list AS50-block permit 100.68.105.0/24
ip prefix-list AS50-block permit 100.68.106.0/24
!
ip prefix-list AS60-block permit 100.68.105.0/24
ip prefix-list AS60-block permit 100.68.106.0/24
!
ip prefix-list AS70-block permit 100.68.107.0/24
ip prefix-list AS70-block permit 100.68.108.0/24
!
ip prefix-list AS80-block permit 100.68.107.0/24
ip prefix-list AS80-block permit 100.68.108.0/24
!What about from the Route Server?
The Route Server prefix-list simply needs the new address space added to it. There is no distinction in this lab environment about which peer the relevant address block comes from. So the Route Server prefix-list simply needs the following added to it:
ip prefix-list IXP-RS permit 100.68.101.0/24
ip prefix-list IXP-RS permit 100.68.102.0/24
ip prefix-list IXP-RS permit 100.68.103.0/24
ip prefix-list IXP-RS permit 100.68.104.0/24
ip prefix-list IXP-RS permit 100.68.105.0/24
ip prefix-list IXP-RS permit 100.68.106.0/24
ip prefix-list IXP-RS permit 100.68.107.0/24
ip prefix-list IXP-RS permit 100.68.108.0/24
!Why did we include our own BGP Customer address block3?
Set up the same modifications to the IPv6 prefix-lists.
Once the prefix-lists have been updated, perform an incoming route-refresh on all the EBGP peerings on the Peering Router.
What do you see now?
The next step is to configure multihoming on the Customer Router.
Refer to the address plan to find the addresses for the point-to-point link between your Access Router and the neighbour Group’s Customer Router. And likewise for the addresses of the point-to-point link between your Customer Router and the neighbouring Group’s Access Router.
We now configure the link from our Access Router to the neighbouring Group’s Customer Router. Take the IPv4 and IPv6 point-to-point link addresses from the plan, and apply them to the interface - as the ISP, you provide the point-to-point link addresses.
interface GigabitEthernet 0/3
description P2P Ethernet Link to Cust (Group Y)
ip address 100.68.X.36 255.255.255.254
no ip redirects
no ip proxy-arp
ipv6 address 2001:DB8:X:32::/127
ipv6 nd prefix default no-advertise
ipv6 nd ra suppress all
!
We now configure the link from our Customer Router to the neighbouring Group’s Access Router. Take the IPv4 and IPv6 point-to-point link addresses from the plan, and apply them to the interface - as the customer, you take the point-to-point link addresses provided by the other Group.
interface GigabitEthernet 0/2
description P2P Ethernet Link to AY
ip address 100.68.Y.37 255.255.255.254
no ip redirects
no ip proxy-arp
ipv6 address 2001:DB8:Y:32::1/127
ipv6 nd prefix default no-advertise
ipv6 nd ra suppress all
!
Before proceeding, check that you can ping the other Group’s customer and access routers from your access and customer routers respectively.
We now need to set up the extra BGP session from our Access Router, to the neighbouring Group’s Customer Router. As before, first we set up the prefix-lists needed:
ip prefix-list CustY-in permit 100.68.10Y.0/24
!
ipv6 prefix-list CustY-v6in permit 2001:DB8:10Y::/48Here is an example of the BGP configuration that is required:
router bgp X0
!
address-family ipv4
neighbor 100.68.X.37 remote-as 1000Y0
neighbor 100.68.X.37 description eBGP with Customer (Group Y)
neighbor 100.68.X.37 route-map set-pi-community in
neighbor 100.68.X.37 prefix-list CustY-in in
neighbor 100.68.X.37 prefix-list default out
neighbor 100.68.X.37 default-originate
!
address-family ipv6
neighbor 2001:DB8:X:32::1 remote-as 1000Y0
neighbor 2001:DB8:X:32::1 description eBGP with Customer (Group Y)
neighbor 2001:DB8:X:32::1 route-map set-pi-community in
neighbor 2001:DB8:X:32::1 prefix-list CustY-v6in in
neighbor 2001:DB8:X:32::1 prefix-list v6default out
neighbor 2001:DB8:X:32::1 default-originate
!
We set up the extra BGP session on the Customer Router, with the neighbouring Group’s Access Router. We have already created the prefix filters for the EBGP session with our Access Router, so it’s simply a case of applying the following configuration:
router bgp 1000X0
!
address-family ipv4
neighbor 100.68.Y.36 remote-as Y0
neighbor 100.68.Y.36 description eBGP with ASY0
neighbor 100.68.Y.36 prefix-list CustX-out out
neighbor 100.68.Y.36 prefix-list default in
!
address-family ipv6
neighbor 2001:DB8:Y:31:: remote-as Y0
neighbor 2001:DB8:Y:31:: description eBGP with ASY0
neighbor 2001:DB8:Y:31:: prefix-list CustX-v6out out
neighbor 2001:DB8:Y:31:: prefix-list v6default in
!Remember that X is your Group number, and Y is the number of the neighbouring Group.
Once you have set up BGP on the Customer router and on the Access router, check the status of the BGP sessions. Here is an example showing Customer 5 from a previous version of this workshop:
BGP table version is 4, local router ID is 100.68.5.64
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.68.6.36 0 60 i
*> 100.68.5.34 0 50 i
*> 100.68.105.0/24 0.0.0.0 0 32768 iNotice that you now have two default routes for the customer router. The best-path will be the oldest route, as per Cisco IOS best path selection - unless the EBGP sessions have been reset since they were established.
As has been covered in the presentations, simply following the default route is not enough in this situation.
Before we start this section of the lab, investigate the following:
try a traceroute from the Customer Router to the Core Router in your group
now try a traceroute from the Core Router in your group to your Customer Router
You should find that the outbound path will follow the best-path default route outbound. This might be direct via your Access Router (assuming no EBGP reset), or via your neighbouring Group’s Access Router. The latter is not optimal, as the outbound traffic will go to your neighbouring Group, then across the Private Peering, to your Core Router. Here is an example from a previous version of this workshop:
Cust6#trace 100.68.6.2 source loopback 1
Type escape sequence to abort.
Tracing the route to 100.68.6.2
VRF info: (vrf in name/id, vrf out name/id)
1 100.68.5.36 [AS 50] 44 msec 64 msec 68 msec
2 100.68.5.20 [AS 50] 64 msec 60 msec 64 msec
3 100.68.5.19 [AS 50] 64 msec 64 msec 64 msec
4 100.68.5.33 [AS 50] 68 msec 68 msec 64 msec
5 * 100.68.6.18 [AS 50] 56 msec *The AS50 in the trace is partly spurious - IOS displays the AS number based on the entries in the routing table, and the address 100.68.6.18 in this case is actually part of AS60’s block.
But notice how the outbound traffic from Customer of Group 6 in this case has gone to the Core Router of Group 6 via Group 5, across the Private Peering. In the absence of the Private Peering, it’d be traffic across the IXP instead.
The return path from Core6 is direct:
C6>trace 100.68.6.64
Type escape sequence to abort.
Tracing the route to 100.68.6.64
VRF info: (vrf in name/id, vrf out name/id)
1 100.68.6.21 12 msec 16 msec 16 msec
2 100.68.6.35 48 msec * 72 msecWe want to fix this case of asymmetric routing, not because we don’t like asymmetric routing, but because outbound traffic (which gives us revenue) from our customer is going via another provider.
We will enhance the EBGP configuration so that we will announce our locally known address space to our customer in the EBGP session.
On the Access Router, rather than just originating a default route, we will also announce the prefixes belonging to communities aggregate and customer-pi. This way our customer has access to all the addresses we reach directly.
First we create a route-map to let these communities out to our customer:
route-map Customer-out permit 5
description Announcements to BGP Customers
match community aggregate customer-pi
!And then we apply to the Customer BGP configuration on the Access Router:
router bgp X0
!
address-family ipv4
neighbor 100.68.X.35 route-map Customer-out out
neighbor 100.68.Y.37 route-map Customer-out out
!
address-family ipv6
neighbor 2001:DB8:X:31::1 route-map Customer-out out
neighbor 2001:DB8:Y:32::1 route-map Customer-out out
!Now that we are announcing prefixes to our customer, we need to remove the prefix-lists only permitting the default route:
router bgp X0
!
address-family ipv4
no neighbor 100.68.X.35 prefix-list default in
no neighbor 100.68.Y.37 prefix-list default in
!
address-family ipv6
no neighbor 2001:DB8:X:31::1 prefix-list v6default in
no neighbor 2001:DB8:Y:32::1 prefix-list v6default in
!and then delete the prefix-lists themselves:
no ip prefix-list default permit 0.0.0.0/0
!
no ipv6 prefix-list v6default permit ::/0Once this is done, we implement a Route Refresh so that the new policy is applied.
With the Access Router now updated to send the Customer their aggregates and their customers’ Provider Independent space (aggregate and customer-pi community lists respectively - see earlier), we now need to update the EBGP configuration on the Customer Router to allow these prefixes in.
This doesn’t not mean deleting the inbound filter and allowing everything in though. We will replace the inbound default prefix filter with one matching the prefixes our upstream is likely to send us4.
First we create the new IPv4 prefix-lists for each upstream. From the upstream in our Group, we expect to get their aggregate (100.68.X.0/24) and their customers who have their own address space (in this case only 100.68.10Y.0/24). So we make a prefix-list to suit:
ip prefix-list GroupX-in permit 0.0.0.0/0
ip prefix-list GroupX-in permit 100.68.X.0/24
ip prefix-list GroupX-in permit 100.68.10Y.0/24
!
ip prefix-list GroupY-in permit 0.0.0.0/0
ip prefix-list GroupY-in permit 100.68.Y.0/24
ip prefix-list GroupY-in permit 100.68.10X.0/24We do the same thing for IPv6:
ipv6 prefix-list GroupXv6-in permit ::/0
ipv6 prefix-list GroupXv6-in permit 2001:DB8:X::/48
ipv6 prefix-list GroupXv6-in permit 2001:DB8:10Y::/48
!
ipv6 prefix-list GroupYv6-in permit ::/0
ipv6 prefix-list GroupYv6-in permit 2001:DB8:Y::/48
ipv6 prefix-list GroupYv6-in permit 2001:DB8:10X::/48Notice these are exact matches on the prefixes they will be sending us.
Then we apply them to the BGP session:
router bgp 1000X0
!
address-family ipv4
neighbor 100.68.X.34 prefix-list GroupX-in in
neighbor 100.68.Y.36 prefix-list GroupY-in in
!
address-family ipv6
neighbor 2001:DB8:X:31:: prefix-list GroupXv6-in in
neighbor 2001:DB8:Y:32:: prefix-list GroupYv6-in in
!This will overwrite the existing prefix-lists in the BGP configurations. We can now remove those:
no ip prefix-list default permit 0.0.0.0/0
no ipv6 prefix-list v6default permit ::/0And once this is done we can perform a route-refresh on the EBGP sessions to implement the new policy.
Now repeat the traceroutes you tried earlier:
trace from your customer router to your core router - is the path direct, or via your neighbouring group?
trace from your core router to your customer router - the path should be direct, as you’ve set local preference to be 200 on your customer routes
Check the BGP table on your customer router to see if it shows what you see in your traceroute (it should!). The IPv4 table should look something like this, the Customer Router of Group 1, taken from a previous version of this workshop:
Cust1#show ip bgp
BGP table version is 6, local router ID is 100.68.101.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,
t secondary path,
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.68.1.34 0 10 i
* 100.68.2.36 0 20 i
*> 100.68.1.0/24 100.68.1.34 0 10 i
*> 100.68.2.0/24 100.68.2.36 0 20 i
*> 100.68.101.0/24 0.0.0.0 0 32768 i
*> 100.68.102.0/24 100.68.1.34 0 10 100020 i
* 100.68.2.36 0 20 100020 iTraffic from Group 1’s customer to the rest of Group 1’s address space goes via the link to Group 1. And traffic from Group 1’s customer to Group 2’s address space goes via the link to Group 2.
But there is one issue remaining, if you look carefully at the table above: best path from Group 1’s customer to Group 2’s customer goes via Group 1:
Cust1#sh ip bgp 100.68.102.0/24
BGP routing table entry for 100.68.102.0/24, version 5
BGP Bestpath: deterministic-med
Paths: (2 available, best #2, table default)
Not advertised to any peer
Refresh Epoch 1
20 100020
100.68.2.36 from 100.68.2.36 (100.68.2.4)
Origin IGP, localpref 100, valid, external
rx pathid: 0, tx pathid: 0
Refresh Epoch 1
10 100020
100.68.1.34 from 100.68.1.34 (100.68.1.4)
Origin IGP, localpref 100, valid, external, best
rx pathid: 0, tx pathid: 0x0Why is the second path above the best path?
This is caused by Cisco IOS inserting an extra step into the BGP Path Selection process (refer to the BGP Attributes presentation), where the age of the entry in the BGP table has significance. The second path above is older than the first path above, so the former is chosen. If we reset the BGP session with Group 1’s Access Router, then we find the best path now becomes via Group 2, which is what we really want:
Cust1#sh ip bgp 100.68.102.0/24
BGP routing table entry for 100.68.102.0/24, version 9
BGP Bestpath: deterministic-med
Paths: (2 available, best #2, table default)
Not advertised to any peer
Refresh Epoch 2
10 100020
100.68.1.34 from 100.68.1.34 (100.68.1.4)
Origin IGP, localpref 100, valid, external
rx pathid: 0, tx pathid: 0
Refresh Epoch 1
20 100020
100.68.2.36 from 100.68.2.36 (100.68.2.4)
Origin IGP, localpref 100, valid, external, best
rx pathid: 0, tx pathid: 0x0What do you think you need to do to make this more deterministic?
Which upstream provider is the best path to the neighbouring BGP customer?
Discuss within your group, and with the lab instructors.
What is the right answer?
Is there a right answer?
This lab has demonstrated the correct way of fixing asymmetric routing between BGP customer and their upstream. It is all too common on the Internet of today for upstream providers to leak their entire IBGP to their BGP customers. This is WRONG, can be a security risk, and puts an unnecessarily high burden on the customer to support what can be quite a large BGP table on a router that perhaps cannot handle so many prefixes. All that an upstream provider should be leaking to their customers are their own aggregates blocks and their customer PI space, as we have done in this example.
What happens if the link from your Access Router to your Customer Router goes down? Where does traffic from your customer to you now go? Try a traceroute and see.
Can you explain what you are seeing?
The instructors will lead a discussion about this scenario, and the behaviour that you might expect to see.
Refer back to the Peering Policy Lab for where we determined the local preferences we’d be setting on different classes of BGP routes depending on where we heard them from.↩︎
If your BGP Customer link to you is down, you’d still want to be able to reach them via your Private Peer - you need to allow your Private Peer to send you your BGP Customer’s address block. This is preferable to sending the traffic through your transit provider.↩︎
Because if our customer link is down, we want to hear our customer via our Peer, rather than via our Transit provider↩︎
In real life/best practice, our upstream provider will inform us which prefixes they will be sending - and keep us updated when there are any changes to this list.↩︎