BGP Aggregation and Route Filtering Lab 

Initial Configuration 
IP addressing: 

● All Loopback1 is used for management and is in the range:

○ 10.x.x.x/32 in all AS
○ The loopback1 address is only advertised into IGP internally in each AS
● Inter-AS links are in the range: 200.16.x.x
○ For example: between R1 and R5: R1=200.16.15.1; R5=200.16.27.5
● Each Router has loopback interfaces configured with the following IP addresses. XX is the AS
with one less zero and Y is the router number.
○ XX.Y.0.1/24 -
■ Example: R1=12.1.0.1/24
■ Example: R10=100.1.0.1/24
○ XX.Y.1.1/24
■ Example R1=12.1.1.1/24
■ Example: R10=100.1.1.1/24
 ○ XX.Y.2.1/24
■ Example R1=12.1.2.1/24
■ Example: R10=100.1.2.1/24
○ XX.Y.3.1/24
■ Example R1=12.1.3.1/24
■ Example: R10=100.1.3.1/24
.
● All eBGP peers are over physical interfaces.
● All iBGP peers are over Loopback interfaces.

BGP/IGP Config 

- AS 120, 340, 780, 560

- Use EIGRP named mode as IGP to advertise loopbacks
- Do not advertise inter-AS links into the IGP
- iBGP peers over loopback interfaces.
- Advertise all networks except for loopback1 into BGP
- Exclude inter-AS links
- Configure eBGP peering using inter-AS links
- AS 900, 1000
- Run OSPFv3 for IPv4 over their shared link.
- AS 900 advertises 90.9.0.0/24 and 90.9.1.0/24 into OSPF
- OSPF should advertise the proper netmask
- AS 1000 advertises 100.1.0.0/24 and 100.1.1.0/24 into OSPF
- OSPF should advertise the proper netmask
- Do not become direct BGP peers with each other
- Advertise all networks except for loopback1 into BGP
- Exclude inter-AS links
- Configure eBGP peering using inter-AS links

Lab Objectives 

Task 1 - AS 900 
- Is not a Transit AS
- Do not use prefix-list or ip access-list to complete this
- Accepts AS 120’s local routes and a default route from AS 120
- Configure filtering on AS 900
- You may not use a prefix-list, or ip access-list
- Configure default route on AS 120
- Receives the full table from AS 340
- Uses the direct link to AS 1000 for the following prefixes
- 100.1.0.0/24
- 100.1.1.0/24
Task 2 - AS 120 
- R1 and R2 should aggregate to 12.0.0.0/8
- Leak R1 routes to AS 780
- Leak R2 routes to AS 560
- Leak full table to AS 340
- Sends default route to AS 900 along with specific routes

Task 3 - AS 340 
- Sends aggregate for R4 links to AS 560
- Sends full table to AS 120
- Do not send aggregate to AS 780

Task 4 - AS 560 
- Sends an aggregate only for R6 routes to AS 120
- Sends an aggregate for both R5 and R6 to AS 340
- Sends full table to AS 780

Task 5 - AS 780 
- Sends R7 local routes and other eBGP routes to AS 120 only
- Sends R8 local routes and other eBGP routes to AS 340 only
- Sends full table to AS 560

Task 6 - AS 1000 
- Is not a Transit AS
- Do not use prefix-list or ip access-list to complete this
- Only receives prefixes with prefix length 16 or less
- Filtering should be done by AS 560 and 780 outbound but configured in AS 1000
- Make sure AS1000 can still reach all prefixes
- Changes can be made as needed in any AS to meet this objective
- Uses direct link to AS 90 to reach following prefixes
- 90.9.0.0/24
- 90.9.1.0/24

   
SOLUTIONS 

Task 1 - AS 900 
- Is not a transit AS
- Do not use prefix-list or ip access-list to complete this
- Accepts AS 120’s local routes and a default route from AS 120
- Configure filtering on AS 900
- You may not use a prefix-list, or ip access-list
- Configure default route on AS 120
- Receives the full table from AS 340
- Uses the direct link to AS 1000 for the following prefixes
- 100.1.0.0/24
- 100.1.1.0/24

Explanation:  
The first objective for this task is that AS 900 should never be used as a transit AS. In BGP, it is
possible to control whether other Autonomous Systems use you as transit by controlling what you
advertise to them. In this scenario, if AS 900 only advertises its own originated routes, then it will receive
traffic only for its own prefixes. The restrictions say not to use a prefix-list or ip access-list to accomplish
this task. Here we can use an AS-Path access-list to match only the locally originated routes. The
regular expression “^$” will match any route where the AS path is null indicating that AS 900 originated
the route.

The second objective is similar to the first. This time, AS 900 only accepts routes originated by AS 120
along with a default route. First, AS 120 should be configured to send a default route to AS 900 using the
“default-originate” for R1’s peering with R9. Then, R9 applies another AS Path filter to accept only routes
that only have “120” in the AS_PATH attribute. This ensures these routes were originated by AS 120 and
were received directly from AS 120 as well.

The next objective requires no configuration to solve.

The last objective indicates that AS 900 should use the backdoor link for the two prefixes 100.1.0.0/24
and 100.1.1.0/24 it receives from AS 1000. Left to defaults, AS 900 learns these prefixes both from its
eBGP peers with an AD of 20 and directly from AS 1000 through OSPFv3 with and AD of 110. The eBGP
path will be installed into R9’s RIB, causing R9 to take an indirect path to reach the prefixes. By making
use of the backdoor feature of BGP, BGP will use an AD of 200 for those routes allowing AS 900 to install
both routes using OSPF instead of BGP (AD 110 vs AD 200). This is done by matching the routes with
network ​commands and adding the ​backdoor​ keyword at the end.

Configuration: 
R9:

ip as-path access-list 120 permit ^120$

 ip as-path access-list 9 permit ^$
!
route-map R1IN permit 10
match as-path 120
!
route-map R4OUT permit 10
match as-path 9
!
route-map R1OUT permit 10
match as-path 9
!
router bgp 900
neighbor 200.16.19.1 route-map R1IN in
neighbor 200.16.19.1 route-map R1OUT out
neighbor 200.16.49.4 route-map R4OUT out
network 100.1.0.0 mask 255.255.255.0 backdoor
network 100.1.1.0 mask 255.255.255.0 backdoor

R1:

router bgp 120

neighbor 200.16.19.9 default-originate

Task 2 - AS 120 
- R1 and R2 should aggregate to 12.0.0.0/8
- Leak R1 routes to AS 780
- Leak R2 routes to AS 560
- Leak full table to AS 340
- Sends default route to AS 900 along with specific routes

Explanation: 
The first objective is for R1 and R2 to send an aggregate for all of their prefixes. R1 and R2 should also
leak specific prefixes depending on the router. R1 leaks R2’s specific routes to R5. R2 leaks R1’s specific
routes to R7 while leaking all routes to R3.

To solve this configure both R1 and R2 to aggregate their prefixes to 12.0.0.0/8 and only advertise this
prefix to all neighbors by adding the ​no-summary​ keyword. Then, apply specific unsuppress maps for
each neighbor to allow each prefix through. Prefix lists are used to designate which prefixes to allow
through. R1 should unsuppress only R2’s routes to R5. R2 should unsuppress only R1’s routes to R7 and
all routes to R3.

Finally, make sure AS 120 is advertising the default route to AS 900, as configured in the previous
section.

Configuration: 
R1:
 !
ip prefix-list UNSUP_R2 seq 5 permit 12.1.0.0/16 ge 24 le 24
ip prefix-list UNSUP_R5 seq 5 permit 12.2.0.0/16 ge 24 le 24
!
route-map UNSUP_R2 permit 10
match ip address prefix-list UNSUP_R2
!
route-map UNSUP_R5 permit 10
match ip address prefix-list UNSUP_R5
!
R1#show running-config | section router bgp
router bgp 120
aggregate-address 12.0.0.0 255.0.0.0 summary-only
neighbor 10.2.2.2 unsuppress-map UNSUP_R2
neighbor 200.16.15.5 unsuppress-map UNSUP_R5
neighbor 200.16.19.9 default-originate

R2:

ip prefix-list UNSUP_R1 seq 5 permit 12.2.0.0/16 ge 24 le 24

ip prefix-list UNSUP_R3 seq 5 permit 12.0.0.0/8 ge 24 le 24
ip prefix-list UNSUP_R7 seq 5 permit 12.1.0.0/16 ge 24 le 24
!
route-map UNSUP_R1 permit 10
match ip address prefix-list UNSUP_R1
!
route-map UNSUP_R3 permit 10
match ip address prefix-list UNSUP_R3
!
route-map UNSUP_R7 permit 10
match ip address prefix-list UNSUP_R7
!
router bgp 120
aggregate-address 12.0.0.0 255.0.0.0 summary-only
neighbor 10.1.1.1 unsuppress-map UNSUP_R1
neighbor 200.16.23.3 unsuppress-map UNSUP_R3
neighbor 200.16.27.7 unsuppress-map UNSUP_R7

Task 3 - AS 340 
- Sends aggregate for R4 links to AS 560
- Sends full table to AS 120
- Do not send aggregate to AS 780

Explanation: 
In this task, you are to send an aggregate for only R4’s links to AS 560. This is the 34.4.0.0/16 range and
is accomplished using the ​aggregate-address ​command on R3. R3 then suppresses the specific prefixes
to R6 using a prefix-list and outbound route-map on the ​neighbor​ command for the R3-R6 peering.

No change needs to be made to accomplish the second step objective.

The final objective can be achieved by filtering any prefix that is more specific than /24 from being
advertised to AS 780 using a prefix list and outbound route-map on the ​neighbor ​command for the R4-R8
peering. (Note: Alternatively the prefix-list could match specifically only the summary route 34.4.0.0/16 as
well).

Configuration: 
R3:

ip prefix-list SUP_R6 seq 5 permit 34.4.0.0/16 ge 24 le 24

!
route-map R6_OUT deny 10
match ip address prefix-list SUP_R6
route-map R6_OUT permit 20
!
router bgp 340
neighbor 200.16.36.6 route-map R6_OUT out

R4:

ip prefix-list SUP_AGG seq 5 permit 34.0.0.0/8 le 23

!
route-map R8_OUT deny 10
match ip address prefix-list SUP_AGG
route-map R8_OUT permit 20
!
router bgp 340
neighbor 200.16.48.8 route-map R8_OUT out

Task 4 - AS 560 
- Sends an aggregate only for R6 routes to AS 120
- Sends an aggregate for both R5 and R6 to AS 340
- Sends full table to AS 780

Explanation: 
For the first objective, configure an aggregate route for R6’s prefixes on R5 using the ​aggregate-address
56.6.0.0 mask 255.255.0.0 summary-only ​keyword on R5.

For the second objective configure R6 with the ​aggregate-address 56.0.0.0 mask 255.255.0.0
summary-only ​command to suppress all routes and advertise a summary route. Then using a suppress
map, leak R6’s routes to R5 so it can advertise them to R1. Finally unsuppress all /24 routes to R7. You
must also filter the 56.0.0.0/8 route from being advertised to R1 by R5 using a route-map.

Configuration: 
R5:
ip prefix-list SUP_AGG_R1 seq 5 permit 56.0.0.0/8
!
route-map R1_OUT deny 10
match ip address prefix-list SUP_AGG_R1
route-map R1_OUT permit 20
!
router bgp 560
aggregate-address 56.6.0.0 255.255.0.0 summary-only
neighbor 200.16.15.1 route-map R1_OUT out

R6:

ip prefix-list UNSUP_R5 seq 5 permit 56.6.0.0/16 ge 24 le 24

ip prefix-list UNSUP_R7 seq 5 permit 56.0.0.0/8 ge 24 le 24
!
route-map UNSUP_R5 permit 10
match ip address prefix-list UNSUP_R5
route-map UNSUP_R7 permit 10
match ip address prefix-list UNSUP_R7
!
router bgp 560
aggregate-address 56.0.0.0 255.0.0.0 summary-only
neighbor 10.5.5.5 unsuppress-map UNSUP_R5
neighbor 200.16.67.7 unsuppress-map UNSUP_R7

Task 5 - AS 780 
- Sends R7 local routes and other eBGP routes to AS 120 only
- Sends R8 local routes and other eBGP routes to AS 340 only
- Sends full table to AS 560

Explanation: 
For the first objective, simply filter all R8 routes from being sent by R7 to R2 using an outbound route-map
configured on the R2-R7 peering. There is no aggregation needed.

The second objective requires filtering all R7 routes from being sent by R8 to R4 using an outbound
route-map configured on the R8-R4 peering. There is no aggregation needed.

No configuration changes need to be made for the final objective

Configuration: 
R7:

ip prefix-list FILTER_R8 seq 5 permit 78.8.0.0/16 ge 24 le 24

!
route-map R2_OUT deny 10
match ip address prefix-list FILTER_R8
route-map R2_OUT permit 100
!
router bgp 780
neighbor 200.16.27.2 route-map R2_OUT out

R8:

ip prefix-list FILTER_R7 seq 5 permit 78.7.0.0/16 ge 24 le 24

!
route-map R4_OUT deny 10
match ip address prefix-list FILTER_R7
route-map R4_OUT permit 100
!
router bgp 780
neighbor 200.16.48.4 route-map R4_OUT out

Task 6 - AS 1000 
- Is not a Transit AS
- Do not use prefix-list or ip access-list to complete this
- Only receives prefixes with prefix length 16 or less
- Filtering should be done by AS 560 and 780 outbound but configured in AS 1000
- Make sure AS1000 can still reach all prefixes
- Changes can be made as needed in any AS to meet this objective

Explanation: 
The first objective for this task is that AS 1000 should never be used as a transit AS. In BGP, it is
possible to control whether other Autonomous Systems use you as transit by controlling what you
advertise to them. In this scenario, if AS 1000 only advertises its own originated routes, then it will receive
traffic only for its own prefixes. The restrictions say not to use a prefix-list or ip access-list to accomplish
this task. Here we can use an AS-Path access-list to match only the locally originated routes. The regular
expression “^$” will match any route where the AS path is null indicating that AS 1000 originated the
route.

The second objective for this task is to filter all prefixes greater than /16 (all of the routes advertised in the
scenario except for the aggregates) on R10. This filtering should be done by AS 560 and AS 780
outbound towards R10, however, it is not allowed to configure the filtering on routers from AS 560 and AS
780 directly. This task is accomplished using the Outbound Route Filtering (ORF) feature of BGP. This
feature is negotiated during BGP capabilities exchange and is enabled using the ​neighbor ​[neighbor ip]
capability orf prefix-list [send | receive | both] ​command. The keyword ​send ​will be used on R10
towards R5 and R8 and the keyword ​receive ​is used on R5 and R8 towards R10. Next a prefix-list that is
meant to be sent to R10’s upstream AS peers is configured and applied to each peering using the
neighbor ​[neighbor ip] ​prefix-list ​[prefix-list]​ in ​command.

The final task aims to ensure R10 has connectivity to all other prefixes. To accomplish this, we need to
advertise aggregate routes for AS 900 and AS 780 to be advertised into BGP. The aggregate needs to be
filtered from advertisement to R4 and R2 in AS 780 to comply with the previous requirements.
Configuration: 
R10:
ip as-path access-list 10 permit ^$
!
ip prefix-list ORF seq 5 permit 0.0.0.0/0 le 16
!
route-map R8OUT permit 10
match as-path 10
!
route-map R5OUT permit 10
match as-path 10
!
router bgp 1000
neighbor 200.16.105.5 route-map R5OUT out
neighbor 200.16.108.8 route-map R8OUT out
neighbor 200.16.105.5 capability orf prefix-list send
neighbor 200.16.105.5 prefix-list ORF in
neighbor 200.16.108.8 capability orf prefix-list send
neighbor 200.16.108.8 prefix-list ORF in

R5:
router bgp 560
neighbor 200.16.105.10 capability orf prefix-list receive

R8:

router bgp 780

aggregate-address 78.0.0.0 255.0.0.0
neighbor 200.16.108.10 capability orf prefix-list receive
!
ip prefix-list FILTER_AGG seq 5 permit 78.0.0.0/8
route-map R4_OUT deny 10
match ip address prefix-list FILTER_R7
route-map R4_OUT deny 20
match ip address prefix-list FILTER_AGG
route-map R4_OUT permit 100

R7:

ip prefix-list FILTER_AGG seq 5 permit 78.0.0.0/8

!
route-map R2_OUT deny 10
match ip address prefix-list FILTER_R8
route-map R2_OUT deny 20
match ip address prefix-list FILTER_AGG
route-map R2_OUT permit 100

R9:
router bgp 900
​aggregate-address 90.0.0.0 255.0.0.0