BGP was developed to handle large numbers of routes.This feature remedied the IGP limitations in relation to large databases.Therefore, we should be extremely cautious about redistributing any BGP derived routes into an IGP.The backbone of the Internet has over 90,000 routing entries. If we have a BGP peering session with an ISP, the ISP will send all, or a subset, of the complete Internet BGP table. Furthermore, we can ask our ISP to inject a default route for us to use in making our routing policies.
We should never consider redistributing a complete BGP table into an IGP of any sort. Doing this will lead to network instability and an IGP that will probably never converge in a failure. Also, it is unlikely that the resources are available to upgrade the processor and memory on every router in the IGP to accommodate
about the evolution from the NFSNET and the Routing Arbiter Project.
www.mae.net This location has everything you want to know about the MAE Internet Exchange Points operated by MCI Worldcom.
http://nanog.org This is the North American Network
Operators Group site, which serves as a link between the aca- demic community and technical communities.
http://nitrous.digex.net/mae/mae-lg.html This link provides a Web-enabled link to get BGP information from the MAE East Looking Glass server.
Also, there are several route servers available for general informa- tion about Internet routes and BGP tables. These servers are essentially Cisco routers running standard IOS that allow user access without a log- ging on, and they permit the user to issue a subset of available com- mands. Simply Telnet to one of the following route servers and issue an IOS command.
route-server.ip.att.net route-views.oregon-ix.net route-server-eu.exodus.net route-server.cerf.net route-server.exodus.net
this policy. It is always best to try to make all IP routing work using the simplest method possible. One method is to use only a default route to attract traffic out of an AS.To make this work effectively, you must have a well-thought-out IP net- work plan that summarizes IP address space from the access layer up to the core network layer. A thorough network plan that summarizes IP network prefixes along these boundaries provides the flexibility needed for implementation, and avoids instability associated with IGPs and large IP databases. Finally, the plan and routing policy should be flexible enough to allow for exceptions. An exception can be described as a network prefix that is not located in an area where it can be summarized into a CIDR block.
Redistributing the Default Route
We should use the default network like a magnet to attract IP traffic out of an AS. A routing policy that injects only a default network “0.0.0.0” limits the routing table size and makes trouble-shooting somewhat easier.Trouble-shooting is easier in that we know that the IP traffic should always flow towards the autonomous system boundary router (ASBR) for destinations that are not within the AS.The IGP used within an AS must also support classless routing; otherwise, we may need to inject a network default for the major net of our IP address space, for example, 172.20.0.0 for a Class B, or 10.0.0.0 for a Class A.This can be turned on in the Cisco IOS by using the exec command IP Classless on every router in the network.
Figure 10.18 gives a graphical representation of a typical IP routing policy for injecting a default route and summarizing an IP network towards the Internet that uses both public and private ASs. In this example, Router 1 sends to Router 2 via EBGP a complete Internet IP database and a default route of 0.0.0.0.This means that Router 2 must have the processing power and memory to handle a complete Internet BGP database to avoid network failure. Router 2 sends to Router 1 only the CIDR block 208.188.0.0/16 that resides within or beyond AS 10001, and strips off all private ASs in the AS_PATH.This is a Cisco unique fea- ture that enables the public AS to serve as a proxy advertisement to the Internet for all private AS networks that reside behind the public AS.
Router 2 then advertises via EBGP to Routers 3 and 4 a default route only.
Router 3 and Router 4 will advertise via EBGP to Router 2 the network pre- fixes that they can reach. In this case, Router 3 advertises the network
208.188.0.0/17, and Router 4 advertises the Network 208.188.128.0/17.They will also advertise these prefixes to each other. Assuming BGP synchronization is
disabled, we do not need to redistribute the network prefixes 208.188.0.0/17 or 208.188.128.0/17 into the OSPF 1 process. Synchronization is discussed in detail in the next section.Therefore, the OSPF 1 database contains only the
NEXT_HOP routing information necessary for IBGP.
Routers 3 and 4 now advertise to Router 5, Router 6, Router 7, and Router 8 a default network. If desired, these routers can also advertise one another’s net- work prefixes into the neighboring ASs. However, Figure 10.18 does not depict this scenario. Router 5, Router 6, Router 7, and Router 8 will advertise to Router 3 and Router 4 their respective network prefixes.Thus, we can see how advertising only a default network into an AS, and summarizing network prefixes into CIDR blocks, works in an ideal network.
BGP Synchronization
BGP synchronization applies only to IBGP network configurations, and it is enabled by default in the Cisco IOS. If you want to disable this feature, you should have a clear understanding of the routing policy for the network.
Synchronization prevents an AS from flooding network prefix information to an Figure 10.18Redistribution Plan
OSPF 100
OSPF 200 OSPF 1
AS 10001
Internet
Router 7 Router 8
Router 4 Router 3
Router 2 Router 1 EBGP
AS 65500
AS 65502 AS 65501
Full Internet Table &
0.0.0.0
Default 0.0.0.0 Only
Default 0.0.0.0 Only
Default 0.0.0.0 Only
208.188.0.0 /16
208.188.128.0 /17
208.188.0.0 /17 EBGP
Router 5 Router 6 EBGP
208.188.0.0 /18 208.188.128.0 /18
IBGP 208.188.64.0 /18
IBGP
208.188.192.0 /18
IBGP
external AS where no route exists within the IGP for the prefix in question.
Therefore, routes learned via IBGP are not advertised to EBGP neighbors unless a corresponding prefix also exists within the IGP.The primary reason for this fea- ture is depicted in Figure 10.19.
In this diagram, you can see that Router 1 is in the middle of the network and is not running a BGP process.Thus, if we disable synchronization on all IBGP routers, they will pass along the network prefixes that each learns from its neighboring AS, even though there is no route in the IGP. Connections will fail in this configuration, because Router 1 will discard the packets.To avoid this problem, do not use a topology that looks like Figure 10.19. An alternative to this would be either to have each router connect to three IBGP neighbors, or to enable synchronization and redistribute the network prefixes into the IGP.
Defining Internal BGP, Route