In this final installment, let’s look at an alternative to BGP network statements, the “redistribute” command. For example, let’s say that our config looks like this:
interface loopback 0
ip address 172.16.1.1 255.255.255.0
router bgp 65001
neighbor 1.2.3.4 remote-as 65002
redistribute connected
no auto-summary
What our router will do in this case is search its IP routing table for any prefixes which are directly connected, such as 172.16.1.0/24. Those prefixes will be injected into BGP, and would be available for advertisement to BGP peers.
Note that since auto-summary is disabled, the connected prefix (172.16.1.0/24) would be originated into BGP. Compare this behavior to that obtained using this configuration:
interface loopback 0
ip address 172.16.1.1 255.255.255.0
router bgp 65001
neighbor 1.2.3.4 remote-as 65002
redistribute connected
auto-summary
With auto-summary enabled, the classful network to which the connected subnet belongs (172.16.0.0/16) will be originated into BGP.
Be aware that when redistributing routes from any protocol into BGP (be they connected, static or dynamic) all such routes are redistributed. This means, when using “redistribute connected”, that all connected prefixes (including loopbacks) would be originated into BGP, and thereby available for advertisement to BGP peers. This could include private address space as well as public.
Of course, network statements and redistributions could be used simultaneously to control the origination of routes into BGP. Not only that, but once the routes have been injected via either mechanism, further summarizations could be performed using the BGP “aggregate-address” command (note that this command also affects the summarization of routes learned via BGP and passed to BGP peers). Let’s look at an example, as follows:
interface loopback 0
ip address 172.16.1.1 255.255.255.0
router bgp 65001
neighbor 1.2.3.4 remote-as 65002
network 172.16.1.0 mask 255.255.255.0
aggregate-address 172.16.0.0 255.255.0.0 summary-only
no auto-summary
Given this configuration, the BGP “network” statement would cause our router to look for an exact match for the 172.16.1.0/24 prefix in the IP routing table (which it would find), and originate it into BGP (which it would do). Then, the “aggregate-address” command would look for the existence of any prefix within the 172.16.0.0/16 address space in the BGP table. If found (which it would be), the router would originate a prefix for 172.16.0.0/16 into BGP, and this prefix would be available for advertisement to BGP peers. Advertisement of the 172.16.1.0/24 prefix to BGP peers would be suppressed by the “summary-only” option. The bottom line is that you can make it as complicated as you desire!
One more thing … when the conditions that caused a prefix to be originated into BGP are no longer satisfied, that route will be removed from the BGP table. For example, if a prefix that’s being matched by a BGP network statement disappears from the IP routing table, the route will be removed from the BGP table as well. Likewise, if a prefix is being redistributed into BGP, loss of that prefix from the IP routing table will result in its being removed from the BGP table. Of course, if the applicable network statement(s) and/or redistribute command(s) are removed, that will cause the affected route(s) to be removed from the BGP table, as well.
Well, that’s it for BGP and network statements. Next time, we’ll do something completely different!