Wednesday, July 16, 2014

Lab 6 - BGP Aggregation

This lab is focused on the concept of aggregation and some of its optional features such as summary-only and as-set. To solve this lab properly focus on the constraints  and requirements.

Concepts tested:
-Aggregation and AS_PATH attributes
-Community attribute manipulation
-AS_PATH filtering

Topology used



Using the aggregate-address command complete the following tasks:

1. Configure eBGP on all routers per the diagram
2. Advertise all loopback addresses on R3 and R4 into BGP
3. Aggregate the loopbacks of R3 and R4 on R2 so that only a single prefix for those networks exist
R1
4. Modify the prefix 172.16.1.0/24 to include the no-export community when advertised to AS 200
- R3 and R4 should only see their own BGP prefixes in their local BGP RIB table
- R3 and R4 should not see the aggregate address in their local BGP RIB table
- R1 should only be able to see the aggregate address in its local BGP RIB table
- Do not use prefix filtering to accomplish this
- Any summarization should only contain R3 and R4 prefixes with no overlap with any other prefixes

GNS3 files: Link


Solution

To begin configure the neighbor sessions:

R1(config)#router bgp 100
R1(config-router)#neighbor 192.168.12.2 remote-as 200

R2(config)#router bgp 200
R2(config-router)#neighbor 192.168.12.1 remote-as 100

R3(config)#router bgp 300
R3(config-router)#neighbor 192.168.23.2 remote-as 200

R4(config)#router bgp
R4(config-router)#neighbor 192.168.24.2 remote-as 200

Then advertise the loopbacks on R3 and R4

R3(config-router)#network 172.16.1.0 mask 255.255.255.0
R3(config-router)#network 172.16.2.0 mask 255.255.255.0
R3(config-router)#network 172.16.3.0 mask 255.255.255.0
R3(config-router)#network 172.16.1.0 mask 255.255.255.0 ?

R4(config-router)#network 172.16.4.0 mask 255.255.255.0
R4(config-router)#network 172.16.5.0 mask 255.255.255.0
R4(config-router)#network 172.16.6.0 mask 255.255.255.0
R4(config-router)#network 172.16.7.0 mask 255.255.255.0

Then configure R3 to add and send the no-export community for the 172.16.1.0/24 prefix

R3(config)#ip prefix-list NET_172.16.1.0 permit 172.16.1.0/24

R3(config)#route-map NO_EXPORT permit
R3(config-route-map)#match ip address prefix-list NET_172.16.1.0
R3(config-route-map)#set community no-export
R3(config-route-map)#exit

Don't forget to enable R3 to send communities

R3(config-router)#neighbor 192.168.23.2 send-community both

R1 should now see all prefixes except 172.16.1.0/24

R1#sh ip bgp
BGP table version is 27, local router ID is 192.168.12.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 172.16.0.0/24    192.168.12.2                           0 200 300 i
*> 172.16.2.0/24    192.168.12.2                           0 200 300 i
*> 172.16.3.0/24    192.168.12.2                           0 200 300 i
*> 172.16.4.0/24    192.168.12.2                           0 200 400 i
*> 172.16.5.0/24    192.168.12.2                           0 200 400 i
*> 172.16.6.0/24    192.168.12.2                           0 200 400 i
*> 172.16.7.0/24    192.168.12.2                           0 200 400 i

Now configure R2 to send an aggregate of the prefixes for R3 and R4 loopback addresses but with some constraints. First R3 and R4 should not see each other prefix advertisements or the aggregate address advertised by AS200. R1 should only see the aggregate address and not the sub-prefixes from R3 and R4.

So the R1 constraint is simple, just use the summary-only option with the aggregate command which tells BGP to only send the /21 prefix and filter all the sub-prefixes of R3 and R4. But how do we filter the prefixes from R3 and R4 without using prefix filtering. Well we use the as-set option. This option says to send the aggregate address but include the attributes of the included prefixes such as community values and includes the AS_SET information of the sub-prefixes as well.

So with this option enabled a couple of thisngs happen. First the AS_PATH information now includes the AS's from R3 and R4 as well as the community values. So this solves our filter problem because R3 and R4 will no longer accept the aggregate address because they will now see their AS in the AS_PATH information.

*> 172.16.0.0/21    192.168.12.2             0             0 200 {300,400} I

But this also creates a new problem. Because the aggregate inherits the attributes of the sub-prefixes it inherited the no-community attribute and is now no longer being advertised by R2. We solve that with the attribute-map command.

R2(config)#route-map NO_COMMUNITY permit
R2(config-route-map)#set community none
R2(config-route-map)#exit

R2(config-router)#aggregate-address 172.16.0.0 255.255.248.0 summary-only as-set attribute-map NO_COMMUNITY

Now everything look good

R1#sh ip bgp
<snip>
   Network          Next Hop            Metric LocPrf Weight Path
*> 172.16.0.0/21    192.168.12.2             0             0 200 {300,400} i

R3#sh ip bgp
<snip>
   Network          Next Hop            Metric LocPrf Weight Path
*> 172.16.0.0/24    0.0.0.0                  0         32768 i
*> 172.16.1.0/24    0.0.0.0                  0         32768 i
*> 172.16.2.0/24    0.0.0.0                  0         32768 i
*> 172.16.3.0/24    0.0.0.0                  0         32768 i

R4#sh ip bgp
<snip>
   Network          Next Hop            Metric LocPrf Weight Path
*> 172.16.4.0/24    0.0.0.0                  0         32768 i
*> 172.16.5.0/24    0.0.0.0                  0         32768 i
*> 172.16.6.0/24    0.0.0.0                  0         32768 i
*> 172.16.7.0/24    0.0.0.0                  0         32768 i

Sources:




No comments:

Post a Comment