From: Leo Leung (leoleung_yh@yahoo.com)
Date: Tue Jan 29 2008 - 00:25:08 ARST
Greetings GS,
A question about BGP aggregation referring to IE Lab14. A full reachability was there after IGP section. SW2 got default OSPF default route from R5 that directly connected and able to reach all IP addresses. Now they are peering in BGP in next section and SW2 is asked to configure with aggregate-address 150.1.0.0 255.255.240.0 summary-only, SW2 then lost reachability to loopback IP address of routers in EIGRP.
I am copying a few snapshots below. It appeared to me that I had to use distance command to push the BGP aggregated route out in order to restore full reachability while keep BGP part remain working. My thought is aggregated route is still more specific than default route, therefore preferred. It must be a elegant way to do that and I may have missed something terribly here, since nobody asked this question. Please let me know, Would you?
Before:
Rack1SW2#sh ip ro 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
Known via "ospf 1", distance 110, metric 1, candidate default path
Tag 1, type extern 2, forward metric 10
Last update from 167.1.58.5 on FastEthernet0/13, 00:34:53 ago
Routing Descriptor Blocks:
* 167.1.58.5, from 150.1.5.5, 00:34:53 ago, via FastEthernet0/13
Route metric is 1, traffic share count is 1
Route tag 1
Now they are peering in BGP in next section and SW2 is configured with aggregate-address
150.1.0.0 255.255.240.0 summary-only
Rack1SW2#sh ip bgp | i 150.1.0.0
*> 150.1.0.0/20 0.0.0.0 32768 i
Rack1SW2#sh ip bgp 150.1.1.0
BGP routing table entry for 150.1.0.0/20, version 19
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to update-groups:
1 2
Local, (aggregated by 65078 150.1.8.8)
0.0.0.0 from 0.0.0.0 (150.1.8.8)
Origin IGP, localpref 100, weight 32768, valid, aggregated, local, atomic-aggregate, best
Rack1SW2#sh ip cef 150.1.0.0 255.255.240.0
150.1.0.0/20
attached to Null0
Rack1SW2#sh ip cef 150.1.1.0
150.1.0.0/20
attached to Null0
Because BGP aggregated route is more specific than default route, when ping 150.1.1.1 for example, it went to Null0, thus failed
My workaround is to issue a distance command in BGP with ACL 8
distance 255 0.0.0.0 255.255.255.255 8
access-list 8 deny 150.1.7.0 0.0.0.255
access-list 8 permit 150.1.0.0 0.0.15.255
After:
Rack1SW2#sh ip bgp | i 150.1.0.0
r> 150.1.0.0/20 0.0.0.0 32768 i
Rack1SW2#
Rack1SW2#sh ip bgp 150.1.1.0
BGP routing table entry for 150.1.0.0/20, version 20
Paths: (1 available, best #1, table Default-IP-Routing-Table, RIB-failure(2))
Advertised to update-groups:
1 2
Local, (aggregated by 65078 150.1.8.8)
0.0.0.0 from 0.0.0.0 (150.1.8.8)
Origin IGP, localpref 100, weight 32768, valid, aggregated, local, atomic-aggregate, best
Rack1SW2#sh ip cef 150.1.0.0 255.255.240.0
%Prefix not found
Rack1SW2#
Rack1SW2#sh ip cef 150.1.1.0
0.0.0.0/0
nexthop 167.1.58.5 FastEthernet0/13
Rack1SW2#
Now the full reachability is restored
---------------------------------
Never miss a thing. Make Yahoo your homepage.
This archive was generated by hypermail 2.1.4 : Fri Feb 01 2008 - 10:38:02 ARST