CCNP BSCI 19

BGP has auto-summarization capabilities. However, it does summarization like EIGRP and RIP, and sadly there is a bad reason why we usually type "no auto" when we get into the EIGRP or RIP process. We'll talk about how to turn auto-summarization off later in this article.
Right now I want to focus on adding networks into the BGP process. There are two ways we can do this:
-"network" command
-"redistribution" command

Now let's get back on the same topology we used in the previous article.



Suppose that R5, the ISP router, has networks at 20.0.0.0/24. and 20.0.1.0/24. If we type "network 20.0.0.0", we would actually advertise a whole class A network! We should instead use:
network 20.0.0.0 mask 255.255.255.0
network 20.0.1.0 mask 255.255.255.0

You can advertise with the network command only either the classful boundary or the exact subnet. You cannot do summarization with the "network" command. For example, "network 20.0.0.0 mask 255.254.0.0" will NOT work!

Typically IGP carries private network information, so it's not recommended to redistribute IGP routes into BGP. Redistribution should only be done when necessary and only the necessary routes should appear in the BGP process. How would we do this? If you've followed the previous articles, the first thing in your head would be Route-Maps and you would be right!

Now, let's assume that the ISP router has routes from its IGP going to 30.[0-7].0.0/16. We would only want 30.5.0.0/16 and 30.6.0.0/16 going out into BGP during redistribution. We'll create an access-list to permit those first:
ip access-l standard PERMIT_5_6
permit 30.5.0.0 0.0.255.255
permit 30.6.0.0 0.0.255.255

We can now permit using a Route-Map:
route-map REDISTRIBUTE_5_6
match ip address PERMIT_5_6

We can now redistribute OSPF with the Route-Map we created:
redistribute ospf 1 route-map REDISTRIBUTE_5_6

By default, 12.2(8)T and above have auto-summarization turned off by default. If you happen to be running an IOS below 12.2(8)T, you would have to type:
no auto

Now hop on over to R1 and check the BGP table:
show ip bgp

Notice that even though you've received the external routes from IBGP, they still may not be in the routing table. This is because of the BGP synchronization rule. BGP synchronization rule states that routes should not be used or advertised until its IGP has learnt it as well.

What this rule help prevent is the Networking Blackhole described in the previous article! BGP Synchronization is on by default in IOS versions 12.2(8)T and below. This is because Cisco assumed that if you're running IBGP, you would probably be running it contiguously, which you should!

To turn off synchronization, we should type (on all IBGP routers):
no sync

Now, even if you've disabled synchronization, it may still not be in the routing table. If we check the BGP table now ("show ip bgp"), we would notice that the route's next hop is set to R5's interface. R1 does not know how to get to R5!

By default, next-hop addresses would be changed to itself whenever a router advertises to an EBGP peer. However, next-hop addresses would remain the same if a router advertises to an IBGP peer! That explains why the next hop was still R5!

To fix this, we'll need to tell R3 to change the next-hop to itself when advertising all routes to R1. To do this, we'll go on R3 and type:
neighbor 10.0.1.3 next-hop-self

BGP has a lot of queer behaviors and you would need to know these off the top of your head if you're into both the examination or real world implementation.