IPv6: BGP untuk siapa - Revision history

Onnowpurbo at 23:17, 25 March 2019

2019-03-25T23:17:31Z

Onnowpurbo: Created page with "Who Needs BGP? Not as many internetworks need BGP as you might think. A common misconception is that whenever an internetwork must be broken int routing domains, BGP should be..."

2019-03-18T04:29:32Z

Created page with "Who Needs BGP? Not as many internetworks need BGP as you might think. A common misconception is that whenever an internetwork must be broken int routing domains, BGP should be..."

New page

Who Needs BGP?
Not as many internetworks need BGP as you might think. A common misconception is that whenever an internetwork must be broken int
routing domains, BGP should be run between the domains. BGP is certainly an option, but why complicate matters by unnecessarily add
another routing protocol to the mix?
Take, for example, a multinational corporate network consisting of 3000 routers and perhaps 150,000 users. Figure 2-9 shows how such
internetwork might be constructed. The entire network is routed with OSPF and is divided into eight geographic OSPF routing domains fo
manageability. Although the illustration shows only the backbone areas for each OSPF domain, each of the domains is divided into multi
areas that also correspond to geographic subregions.
Figure 2-9. Even a Very Large Internetwork Can Be Built Using Only Multiple IGP Domains
BGP can be used to provide connectivity between the multiple OSPF domains, but it is unnecessary. Instead, each of the eight OSPF ba
areas redistributes into a single global backbone. The global backbone is another OSPF domain, consisting of a single OSPF area. Altho
core consists of high-end routers to handle the packet-switching load, the load on these routers from routing tables and OSPF processin
actually very small. Because of the way the entire internetwork is addressed, each of the eight OSPF domains advertises only a single a
route to the global backbone. In fact, aggregation is fundamental to making this design work. There are, presumably, such a large numbe
subnets in such an internetwork that without aggregation OSPF would "choke" trying to process them all. The result would be very poor
performance and possible router failures.
The hierarchical construction of the physical topology and the address space are two of the three factors contributing to the simplicity of t
internetwork in Figure 2-9. The third factor is a common administrative body for the entire internetwork. Having a single administration m
routing policies are imposed equally and consistently throughout. In this case, the routing policy dictates the address range used in each
area and that all OSPF processes interconnect through OSPF 1 only.
NOTE
A routing policy is just a designed and configured process for controlling the traffic patterns within an internetwork by controlling routes an
characteristics. Redistribution, route filters, and route maps are the most common tools for implementing routing policies with Cisco IOS
Of course, in real life, few corporations the size of the one depicted in Figure 2-9 have the luxury of being designed "from the ground up"
coordinated, logical fashion. Many, if not most, large internetworks have evolved from smaller internetworks that have been merged as d
and corporations have merged. The result is that different network administrators have made different design choices for the various part
internetwork; when the parts are merged, the first order of business is basic interoperability.
The second order of business might be the enforcement of routing policies. Some traffic from some domains of the internetwork to other
may be required to always prefer certain links or routes, for example, or perhaps only certain routes should be advertised between doma
most cases, the necessary policies can still be implemented with redistribution between IGPs and tools such as route filters and route ma
should implement BGP only when a sound engineering reason compels you to do so, such as when the IGPs do not provide the tools neto implement the required routing policies or when the size of the routing tables cannot be controlled with summarization. BGP proves us
instance, when many different IGPs are used in the domains. Here, BGP might be simpler to implement than attempting to redistribute am
the IGPs.
When considering whether BGP is necessary in an internetwork design, keep in mind why exterior routing protocols were invented in the
place. Exterior routing protocols are used to route between autonomous systems that is, between internetwork domains under different
administrative authorities. In a single corporate internetwork, even a large one with different domains under different local administrations
usually enough of a centralized authority to impose routing policy using the tools available with interior routing protocols. When separate
autonomous systems must interconnect, however, BGP might be called for.
The majority of the cases calling for BGP involve Internet connectivity either between a subscriber and an ISP or (more likely) between IS
even when interconnecting autonomous systems, BGP might be unnecessary. The remainder of this section examines typical inter-AS to
and demonstrates where BGP is and is not needed.
A Single-Homed Autonomous System
Figure 2-10 shows a subscriber attached by a single connection to an ISP. BGP, or any other type of routing protocol, is unnecessary in t
topology. If the single link fails, no routing decision needs to be made, because no alternative route exists. A routing protocol accomplish
nothing. In this topology, the subscriber adds a static default route to the border router and redistributes the route into his AS.
Figure 2-10. Static Routes Are All That Is Needed in This Single-Homed Topology
The ISP similarly adds a static route pointing to the subscriber's address range and advertises that route into its AS. Of course, if the sub
address space is a part of the ISP's larger address space, the route advertised by the ISP's router goes no farther than the ISP's own AS
rest of the world" reaches the subscriber by routing to the ISP's advertised address space, and the more-specific route to the subscriber
up only within the ISP's AS.
An important principle to remember when working with inter-AS traffic is that each physical link actually represents two logical links: one
incoming traffic and one for outgoing traffic (see Figure 2-11).
Figure 2-11. Each Physical Link Between Autonomous Systems Represents Two Logical Links, Carrying IncomThe routes you advertise in each direction influence the traffic separately. Avi Freedman, who has written many excellent articles on ISP
calls a route advertisement a promise to carry packets to the address space represented in the route. In Figure 2-10, the subscriber's rou
advertising a default route into the local AS a promise to deliver packets to any destination for which there is not a more-specific route. An
ISP's router, advertising a route to 205.110.32.0/20, is promising to deliver traffic to the subscriber's AS. The outgoing traffic from the sub
AS is the result of the default route, and the incoming traffic to the subscriber's AS is the result of the route advertised by the ISP's router
concept might seem somewhat trivial and obvious at this point, but it is very important to keep in mind as you examine more-complex top
The obvious vulnerability of the topology in Figure 2-10 is that the entire connection is made up of single points of failure. If the single da
fails, if a router or one of its interfaces fails, if the configuration of one of the routers fails, if a process within the router fails, or if one of th
all-too-human administrators makes a mistake, the subscriber's entire Internet connectivity can be lost. What is lacking in this picture is
redundancy.
Multihoming to a Single Autonomous System
Figure 2-12 shows an improved topology, with redundant links to the same provider. How the incoming and outgoing traffic is manipulate
these links depends on how the two links are used. For example, a typical setup when multihoming to a single provider is for one of the l
a primary, dedicated Internet access link say, a T1 and for the other link to be used only for backup. In such a scenario, the backup link is
be some lower-speed connection.
Figure 2-12. Multihoming to a Single Autonomous SystemWhen the redundant link is used only for backup, there is again no call for BGP. The routes can be advertised just as they were in the sin
homed scenario, except that the routes associated with the backup link have the distances set high so that they are used only if the prim
fails.
Example 2-9 shows what the configurations of the routers carrying the primary and secondary links might look like.
Example 2-9 Primary and Secondary Link Configurations for Multihoming to a Single Autonomous System
Primary Router
router ospf 100
network 205.110.32.0 0.0.15.255 area 0
default-information originate metric 10
!
ip route 0.0.0.0 0.0.0.0 205.110.168.108
_____________________________________________________________________________________________________
Backup Router
router ospf 100
network 205.110.32.0 0.0.15.255 area 0default-information originate metric 100
!
ip route 0.0.0.0 0.0.0.0 205.110.168.113 150
In this configuration, the backup router has a default route whose administrative distance is set to 150 so that it is in the routing table only
default route from the primary router is unavailable. Also, the backup default is advertised with a higher metric than the primary default ro
ensure that the other routers in the OSPF domain prefer the primary default route. The OSPF metric type of both routes is E2, so the adv
metrics remain the same throughout the OSPF domain. This consistency ensures that the metric of the primary default route remains low
the metric of the backup default route in every router, regardless of the internal cost to each border router. Example 2-10 shows the defa
in a router internal to the OSPF domain.
Example 2-10 The First Display Shows the Primary External Route; the Second Display Shows the Backup Rou
Used After the Primary Route Has Failed
Phoenix#show ip route 0.0.0.0
Routing entry for 0.0.0.0 0.0.0.0, supernet
Known via "ospf 1", distance 110, metric 10, candidate default path
Tag 1, type extern 2, forward metric 64
Redistributing via ospf 1
Last update from 205.110.36.1 on Serial0, 00:01:24 ago
Routing Descriptor Blocks:
* 205.110.36.1, from 205.110.36.1, 00:01:24 ago, via Serial0
Route metric is 10, traffic share count is 1
Phoenix#show ip route 0.0.0.0
Routing entry for 0.0.0.0 0.0.0.0, supernet
Known via "ospf 1", distance 110, metric 100, candidate default path
Tag 1, type extern 2, forward metric 64
Redistributing via ospf 1
Last update from 205.110.38.1 on Serial1, 00:00:15 ago
Routing Descriptor Blocks:
* 205.110.38.1, from 205.110.38.1, 00:00:15 ago, via Serial1
Route metric is 100, traffic share count is 1
Although a primary/backup design satisfies the need for redundancy, it does not efficiently use the available bandwidth. A better design is
both paths, with each providing backup for the other in the event of a link or router failure. In this case, the configuration used in both rou
indicated in Example 2-11.
Example 2-11 Configuration for Load Sharing When Multihomed to the Same AS
router ospf 100network 205.110.32.0 0.0.15.255 area 0
default-information originate metric 10 metric-type 1
!
ip route 0.0.0.0 0.0.0.0 205.110.168.108
The static routes in both routers have equal administrative distances, and the default routes are advertised with equal metrics (10). Notic
default routes are now advertised with an OSPF metric type of E1. With this metric type, each of the routers in the OSPF domain takes in
account the internal cost of the route to the border routers in addition to the cost of the default routes themselves. As a result, every route
chooses the closest exit point when choosing a default route (see Figure 2-13).
Figure 2-13. Border Routers Advertising a Default Route with a Metric of 10 and an OSPF Metric Type of E
In most cases, advertising default routes into the AS from multiple exit points, and summarizing address space out of the AS at the same
points, is sufficient for good internetwork performance. The one consideration is whether asymmetric traffic patterns will become a conce
geographical separation between the two (or more) exit points is large enough for delay variations to become significant, you might have
for better control of the routing. You might now consider BGP.
Suppose, for example, that the two exit routers depicted in Figure 2-12 are located in Los Angeles and London. You might want all your e
destined for the Eastern Hemisphere to use the London router and all your exit traffic for the Western Hemisphere to use the Los Angele
Remember that the incoming route advertisements influence your outgoing traffic. If the provider advertises routes into your AS via BGP,
internal routers have more-accurate information about external destinations. BGP also provides the tools for setting routing policies for th
destinations.
Similarly, outgoing route advertisements influence your incoming traffic. If internal routes are advertised to the provider via BGP, you hav
influence over which routes are advertised at which exit point, and also tools for influencing (to some degree) the choices the provider m
when sending traffic into your AS.
When considering whether to use BGP, carefully weigh the benefits gained against the cost of added routing complexity. You should use
when you can realize an advantage in traffic control. Consider the incoming and outgoing traffic separately. If it is only important to contro
incoming traffic, use BGP to advertise routes to your provider while still advertising only a default route into your AS.
On the other hand, if it is only important to control your outgoing traffic, use BGP only to receive routes from your provider. Consider care
ramifications of accepting routes from your provider. "Taking full BGP routes" means that your provider advertises to you the entire Intern
table. As of this writing, that is approximately 88,000 route entries, as shown in Example 2-12. To store and process a table of this size, y
reasonably powerful router and at least 64 MB of memory (although 128 MB is recommended). On the other hand, you can easily impleExample 2-12 This Full Internet Routing Table Summary Shows 57,624 BGP Entries
route-server>show ip route summary
Route Source Networks Subnets Overhead Memory (bytes)
connected 0 1 56 144
static 2 1 168 432
bgp 65000 76302 11967 4943064 12847416
External: 88269 Internal: 0 Local: 0
internal 779
Total 77083
906756
11969
4943288
13754748
route-server>
NOTE
The routing table summary in Example 2-12 is taken from a publicly accessible route server at route-server.ip.att.net. Another server to w
can Telnet is route-server.cerf.net. The number of BGP entries varies somewhat in each, but all indicate a similar size.
"Taking partial BGP routes" is a compromise between taking full routes and accepting no routes at all. As the name implies, partial routes
some subset of the full Internet routing table. For example, a provider might advertise only routes to its other subscribers, plus a default r
reach the rest of the Internet. The following section presents a scenario in which taking partial routes proves useful.
Another consideration is that when running BGP, a subscriber's routing domain must be identified with an autonomous system number. L
addresses, autonomous system numbers are limited and are assigned only by the regional address registries when there is a justifiable n
like IP addresses, a range of autonomous system numbers is reserved for private use: the AS numbers 64512 to 65535. With few excep
subscribers that are connected to a single service provider (either single or multihomed) use an autonomous system number out of the re
range. The service provider filters the private AS number out of the advertised BGP path.
Although the topology in Figure 2-12 is an improvement over the topology in Figure 2-10 because redundant routers and data links have
added, it still entails a single point of failure: the ISP itself. If the ISP loses connectivity to the rest of the Internet, so does the subscriber.
ISP suffers a major internal outage, the single-homed subscriber also suffers.
Multihoming to Multiple Autonomous Systems
Figure 2-14 shows a topology in which a subscriber has homed to more than one service provider. In addition to the advantages of multih
already described, this subscriber is protected from losing Internet connectivity as the result of a single ISP failure.
Figure 2-14. Multihoming to Multiple Autonomous SystemsFor a small corporation or a small ISP, there are substantial obstacles to multihoming to multiple service providers. You already have see
problems involved if the subscriber's address space is a part of one of the service providers' larger address space:
The originating provider must be persuaded to "punch a hole" in his CIDR block.
The second provider must be persuaded to advertise an address space that belongs to a different provider.
Both providers must be willing to closely coordinate the advertisement of the subscriber's address space.
If the subscriber's address space is smaller than a /19 (which a small subscriber's space is likely to be), some backbone providers
accept the route.
The best candidates for multihoming to multiple providers are corporations and ISPs that are large enough to qualify for a provider-indep
address space (or who already have one) and a public autonomous system number.
The subscriber in Figure 2-14 could still forego BGP. One option is to use one ISP as a primary Internet connection and the other as a ba
only; another option is to default route to both providers and let the routing chips fall where they may. If a subscriber has gone to the exp
multihoming and contracting with multiple providers, however, neither of these solutions is likely to be acceptable. BGP is the preferred o
this scenario.
Again, incoming and outgoing traffic should be considered separately. For incoming traffic, the most reliability is realized if all internal rou
advertised to both providers. This setup ensures that all destinations within the subscriber's AS are completely reachable via either ISP. E
though both providers are advertising the same routes, there are cases in which incoming traffic should prefer one path over another. BG
provides the tools for communicating these preferences.
For outgoing traffic, the routes accepted from the providers should be carefully considered. If full routes are accepted from both providers
route for every Internet destination is chosen. In some cases, however, one provider might be a preferred for full Internet connectivity, wh
other provider is preferred for only some destinations. In this case, full routes can be taken from the preferred provider and partial routes
taken from the other provider. For example, you might want to use the secondary provider, only to reach its other subscribers and for bac
your primary Internet provider (see Figure 2-15). The secondary provider sends its customer routes, and the subscriber configures a defa
to the secondary ISP to be used if the connection to the primary ISP fails.
Figure 2-15. ISP1 Is the Preferred Provider for Most Internet Connectivity; ISP2 Is Used Only to Reach Its ONotice that the full routes sent by ISP1 probably include the customer routes of ISP2. Because the same routes are received from ISP2,
the subscriber's routers normally prefer the shorter path through ISP2. If the link to ISP2 fails, the subscriber uses the longer paths throu
and the rest of the Internet to reach ISP2's customers.
Similarly, the subscriber normally uses ISP1 to reach all destinations other than ISP2's customers. If some or all of those more-specific ro
ISP1 are lost, however, the subscriber uses the default route through ISP2.
If router CPU and memory limitations prohibit taking full routes, partial routes from both providers are an option. Each provider might sen
customer routes, and the subscriber points default routes to both providers. In this scenario, some routing accuracy is traded for a saving
router hardware.
In yet another partial-routes scenario, each ISP might send its customer routes and also the customer routes of its upstream provider. In
16, for example, ISP1 is connected to Sprint, and ISP2 is connected to MCI. The partial routes sent to the subscriber by ISP1 consist of a
ISP1's customer routes and all of Sprint's customer routes. The partial routes sent by ISP2 consist of all of ISP2's customer routes and a
customer routes. The subscriber points to default routes at both providers. Because of the size of the two backbone service providers, th
subscriber has enough routes to make efficient routing decisions on a large number of destinations. At the same time, the partial routes a
significantly smaller than a full Internet routing table.
Figure 2-16. The Subscriber Is Taking Partial Routes from Both ISPs, Consisting of Each ISP's Customer RouThe remainder of this chapter (after two short cautionary sections) examines the operation of BGP and the tools it provides for setting pre
and policies for both incoming and outgoing traffic.
A Note on "Load Balancing"
The principal benefits of multihoming are redundancy and, to a lesser extent, increased bandwidth. Increased bandwidth does not mean
links are used with equal efficiency. You should not expect the traffic load to be balanced 50/50 across the two links; one of the ISPs will
always be "better connected" than the other ISP. The ISP itself or its upstream provider might have better routers, better physical links, o
NAP connections than the other ISP, or one ISP might just be topologically closer to more of the destinations to which your users regular
connect.
That is not to say that you cannot, through the expenditure of considerable time and effort, manipulate route preferences to fairly evenly
your route traffic across the two links. The problem is that you probably actually degrade your Internet performance by forcing some traffi
a less-optimal route for the sake of so-called load balancing. All you really accomplish, in most cases, is an evening out of the utilization
of your two ISP links. Do not be too concerned if 75 percent of your traffic uses one link while only 25 percent of your traffic uses the othe
Multihoming is for redundancy and increased routing efficiency, not load balancing.
BGP Hazards
Creating a BGP peering relationship involves an interesting combination of trust and mistrust. The BGP peer is in another AS, so you mu
the network administrator on that end to know what he or she is doing. At the same time, if you are smart, you will take every practical m
protect yourself in the event that a mistake is made on the other end. When you're implementing a BGP peering connection, paranoia is
friend.
Recall the earlier description of a route advertisement as a promise to deliver packets to the advertised destination. The routes you adve
directly influence the packets you receive, and the routes you receive directly influence the packets you transmit. In a good BGP peering
arrangement, both parties should have a complete understanding of what routes are to be advertised in each direction. Again, incoming
outgoing traffic must be considered separately. Each peer should ensure that he is transmitting only the correct routes and should use ro
or other policy tools such as AS_PATH filters, described in Chapter 3, to ensure that he is receiving only the correct routes.
Your ISP might show little patience with you if you make mistakes in your BGP configuration, but the worst problems can be attributed to
on both sides of the peering arrangement. Suppose, for example, that through some misconfiguration you advertise 207.46.0.0/16 to you
the receiving side, the ISP does not filter out this incorrect route, allowing it to be advertised to the rest of the Internet. This particular CID
belongs to Microsoft, and you have just claimed to have a route to that destination. A significant portion of the Internet community could d
the best path to Microsoft is through your domain. You will receive a flood of unwanted packets across your Internet connection and, mor
importantly, you will have black-holed traffic that should have gone to Microsoft. They will be neither amused nor understanding.
Figure 2-17 shows another example of a BGP routing mistake. This same internetwork was shown in Figure 2-15, but here the customerFigure 2-17. This Subscriber Is Advertising Routes Learned from ISP2 into ISP1, Inviting Packets Destined for I
Its Customers to Transit His Domain
In all likelihood, ISP1 and its customers will see the subscriber's domain as the best path to ISP2 and its customers. In this case, the traf
black-holed, because the subscriber does indeed have a route to ISP2. The subscriber has become a transit domain for packets from IS
ISP2, to the detriment of its own traffic. And because the routes from ISP2 to ISP1 still point through the Internet, the subscriber has caus
asymmetric routing for ISP2.
The point of this section is that BGP, by its very nature, is designed to allow communication between autonomously controlled systems. A
successful and reliable BGP peering arrangement requires an in-depth understanding of not only the routes to be advertised in each dire
also the routing policies of each of the involved parties.

==Pranala Menarik==

* [[IPv6: Advanced Routing]]

@@ Line 1: / Line 1: @@
 Who Needs BGP?
 Not as many internetworks need BGP as you might think. A common misconception is that whenever an internetwork must be broken int
 routing domains, BGP should be run between the domains. BGP is certainly an option, but why complicate matters by unnecessarily add
 another routing protocol to the mix?
 Take, for example, a multinational corporate network consisting of 3000 routers and perhaps 150,000 users. Figure 2-9 shows how such
 internetwork might be constructed. The entire network is routed with OSPF and is divided into eight geographic OSPF routing domains fo
 manageability. Although the illustration shows only the backbone areas for each OSPF domain, each of the domains is divided into multi
 areas that also correspond to geographic subregions.
 Figure 2-9. Even a Very Large Internetwork Can Be Built Using Only Multiple IGP Domains
 BGP can be used to provide connectivity between the multiple OSPF domains, but it is unnecessary. Instead, each of the eight OSPF ba
@@ Line 19: / Line 22: @@
 routing policies are imposed equally and consistently throughout. In this case, the routing policy dictates the address range used in each
 area and that all OSPF processes interconnect through OSPF 1 only.
 NOTE
 A routing policy is just a designed and configured process for controlling the traffic patterns within an internetwork by controlling routes an
@@ Line 32: / Line 36: @@
 instance, when many different IGPs are used in the domains. Here, BGP might be simpler to implement than attempting to redistribute am
 the IGPs.
 When considering whether BGP is necessary in an internetwork design, keep in mind why exterior routing protocols were invented in the
 place. Exterior routing protocols are used to route between autonomous systems that is, between internetwork domains under different
@@ Line 40: / Line 45: @@
 even when interconnecting autonomous systems, BGP might be unnecessary. The remainder of this section examines typical inter-AS to
 and demonstrates where BGP is and is not needed.
 A Single-Homed Autonomous System
 Figure 2-10 shows a subscriber attached by a single connection to an ISP. BGP, or any other type of routing protocol, is unnecessary in t
 topology. If the single link fails, no routing decision needs to be made, because no alternative route exists. A routing protocol accomplish
@@ Line 61: / Line 68: @@
 all-too-human administrators makes a mistake, the subscriber's entire Internet connectivity can be lost. What is lacking in this picture is
 redundancy.
 Multihoming to a Single Autonomous System
 Figure 2-12 shows an improved topology, with redundant links to the same provider. How the incoming and outgoing traffic is manipulate
 these links depends on how the two links are used. For example, a typical setup when multihoming to a single provider is for one of the l
@@ Line 72: / Line 81: @@
 Example 2-9 Primary and Secondary Link Configurations for Multihoming to a Single Autonomous System
 Primary Router
 router ospf 100
-network 205.110.32.0 0.0.15.255 area 0
+ router ospf 100
-default-information originate metric 10
+ network 205.110.32.0 0.0.15.255 area 0
+ default-information originate metric 10
 ip route 0.0.0.0 0.0.0.0 205.110.168.108
 _____________________________________________________________________________________________________
 Backup Router
 router ospf 100
-network 205.110.32.0 0.0.15.255 area 0default-information originate metric 100
+ router ospf 100
+ network 205.110.32.0 0.0.15.255 area 0default-information originate metric 100
 ip route 0.0.0.0 0.0.0.0 205.110.168.113 150
 In this configuration, the backup router has a default route whose administrative distance is set to 150 so that it is in the routing table only
 default route from the primary router is unavailable. Also, the backup default is advertised with a higher metric than the primary default ro
@@ Line 113: / Line 125: @@
 indicated in Example 2-11.
 Example 2-11 Configuration for Load Sharing When Multihomed to the Same AS
-router ospf 100network 205.110.32.0 0.0.15.255 area 0
-default-information originate metric 10 metric-type 1
+ router ospf 100
+ network 205.110.32.0 0.0.15.255 area 0
-ip route 0.0.0.0 0.0.0.0 205.110.168.108
+ default-information originate metric 10 metric-type 1
 The static routes in both routers have equal administrative distances, and the default routes are advertised with equal metrics (10). Notic
 default routes are now advertised with an OSPF metric type of E1. With this metric type, each of the routers in the OSPF domain takes in
@@ Line 141: / Line 156: @@
 table. As of this writing, that is approximately 88,000 route entries, as shown in Example 2-12. To store and process a table of this size, y
 reasonably powerful router and at least 64 MB of memory (although 128 MB is recommended). On the other hand, you can easily impleExample 2-12 This Full Internet Routing Table Summary Shows 57,624 BGP Entries
 route-server>show ip route summary
-Route Source Networks Subnets Overhead Memory (bytes)
+ route-server>show ip route summary
-connected 0 1 56 144
+ Route Source Networks Subnets Overhead Memory (bytes)
-static 2 1 168 432
+ connected 0 1 56 144
-bgp 65000 76302 11967 4943064 12847416
+ static 2 1 168 432
-External: 88269 Internal: 0 Local: 0
+ bgp 65000 76302 11967 4943064 12847416
-internal 779
+ External: 88269 Internal: 0 Local: 0
-Total 77083
+ internal 779
+ Total 77083
-−
 4943288
-13754748
+ 4943288
-route-server>
+ 13754748
 NOTE
 The routing table summary in Example 2-12 is taken from a publicly accessible route server at route-server.ip.att.net. Another server to w