CCIE - Internetwork Expert's Online Community

SG Solution:

router bgp 100
 no synchronization
 bgp router-id 150.1.4.4
 bgp log-neighbor-changes
 aggregate-address 139.1.0.0 255.255.0.0 summary-only
 redistribute rip route-map IGP_TO_BGP
 neighbor 150.1.6.6 remote-as 100
 neighbor 150.1.6.6 update-source Loopback0
 neighbor 150.1.6.6 next-hop-self
 neighbor 204.12.1.254 remote-as 54
 neighbor 204.12.1.254 unsuppress-map IGP_TO_BGP
 distribute-list prefix DENY_AGGREGATE in

ip prefix-list DENY_AGGREGATE seq 5 deny 139.1.0.0/16
ip prefix-list DENY_AGGREGATE seq 10 permit 0.0.0.0/0 le 32

Qns - Why is there a need to use the 'distrbute-list' to filter off 139.1.0.0/16? R4 is redistributing only RIP VLAN5 into BGP. Aggregate 139.1.0.0/16 is advertised on both R4 and R6, both BB1 and BB3 will see this aggregate 139.1.0.0/16, when VLAN5 is redistributed into BGP. Using a distribute-list will not help is filtering off to the rest of the internal subnets. Results is the same for before and after using the command distribute-list prefix DENY_AGGREGATE in.

Hi,

I think this distribute-list is there for good reason. 

We are creating a aggregate address "aggregate-address 139.1.0.0 255.255.0.0 summary-only" in order to have aggregate 139.1.0.0 on BB3 as per the Task 10.2. The problem here is that aggregate-address  will also create another entry in R4's routing table as show below.

Rack1R4(config-router)#do sir bgp                            
     139.1.0.0/16 is variably subnetted, 8 subnets, 3 masks
B       139.1.0.0/16 [200/0] via 0.0.0.0, 00:10:17, Null0

By default R4 uses the default route originated by R5 to reach any network which it does not have specific route in its routing table. So before using aggregate-address if R4 want to reach R3's loopback it matches the default route and reaches the destination. With this R4 will not have any reachability problem. But when R3 try to reach 150.1.4.4 the source ip address will be either 139.1.13.0 (link between R1 and R3) or 139.1.23.0 (link between R2 and R3) and the ping will fail. The reason for this is due to the fact that when we use aggregate address it will create an entry for 139.1.0.0 which it will point out to a null 0. Hence when R4 try to reach 139.1.13.0 or 139.1.23.0 it will match the route which is pointing to null interface (which is the more specific match for it for 139.1.x.x network) rather than the default route. So all traffic will getting dropped here as show below

Rack1R3#p 150.1.4.4    

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.4.4, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

In oder to avoid this we create an distribute list which will prevent this entry (139.1.0.0/16 [200/0] via 0.0.0.0, 00:10:17, Null0) getting on to the routing table.

The result will be as show..

Rack1R4(config-router)#distribute-list prefix DENY_AGGREGATE in

Rack1R3#p 150.1.4.4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.4.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/146/204 ms

Hope this will answer your query.