• Search for:
    11Apr, 2023
    OSPFv3 LSAs – OSPF, BGP, and Route Manipulation

    OSPFv3 retains the LSA types used by OSPFv2 with some modifications and introduces two new LSAs: link LSA and intra-area-prefix.

    All LSAs use a common 20-byte header that indicates the LS type, the advertising router, and the sequence number. Figure 4-8 shows the format of the LSA header.

    Figure 4-8 LSA Header

    The LS Age field indicates the time in seconds since the LSA was generated.

    The LS Type field indicates the function performed by this LSA. This field includes a U bit and S2 and S1 bits. When the U bit is set to 0, the LSA is flooded only locally. When the U bit is set to 1, the LSA is stored and flooded. The S1 and S2 bits have the functions indicated in Table 4-5.

    Table 4-5 LSA Header S2 and S1 Bits

    S2 S1 ValueFlooding Scope
    00Link-local scope
    01Flood to all routers within the area
    10Flood to all routers within the autonomous system
    11Reserved

    The Link State ID field is used with the LS type and advertising router to identify the link-state database. The Advertising Router field contains the 32-bit router ID of the router that generated the LSA. The LS Sequence Number field is used to detect old or duplicate LSAs. The LS Checksum field is for error checking. The Length field indicates the length of the LSA, including the header.

    Table 4-6 summarizes the nine LSAs that can be used in OSPF. Most LSAs retain the same function used in OSPFv2 for IPv4. The OSPFv3 LSAs are described in more detail following the table.

    Table 4-6 OSPFv3 LSA Types

    LSA NameLS TypeDescription
    Router LSA0x2001Specifies the state of a router interface
    Network LSA0x2002Generated by DR routers in broadcast or NBMA networks
    Interarea-prefix LSA0x2003Routes to prefixes in other areas
    Interarea-router LSA0x2004Routes to routers in other areas
    Autonomous system external LSA0x4005Routes to networks external to the autonomous system
    Group-membership LSA0x2006Routes to networks that contain multicast groups
    NSSA Type 7 LSA0x2007Routes to networks external to the autonomous system, injected into the NSSA
    Link LSA0x0008Tells neighbors about link-local addresses and lists IPv6 prefixes associated with the link
    Intra-area-prefix LSA0x2009Specifies IPv6 prefixes connected to a router, a stub network, or an associated transit network segment

    Router LSAs describe the cost and state of all the originating router’s interfaces. These LSAs are flooded within the area only. Router LSAs are LS type 0x2001. No IPv6 prefixes are contained in router LSAs.

    Network LSAs are originated by DRs in broadcast or NBMA networks. They describe all routers attached to the link that are adjacent to the DR. These LSAs are flooded within the area only. The LS type is 0x2002. No IPv6 prefixes are contained in this LSA.

    Interarea-prefix LSAs describe routes to IPv6 prefixes that belong to other areas. They are similar to OSPFv2 Type 3 summary LSAs. The interarea-prefix LSA is originated by the ABR and has LS type 0x2003. It is also used to send the default route in stub areas. These LSAs are flooded within the area only.

    Each interarea-router LSA describes a route to a router in another area. It is similar to OSPF Type 4 summary LSAs. It is originated by the ABR and has LS type 0x2004. These LSAs are flooded within the area only.

    Autonomous system external LSAs describe networks that are external to the autonomous system. These LSAs are originated by ASBRs, have LS type 0x4005, and are flooded to all routers in the autonomous system.

    The group-membership LSA describes the directly attached networks that contain members of a multicast group. This LSA is limited to the area and has LS type 0x2006. This LSA is described further in RFC 1584. This LSA is not supported in Cisco IOS software.

    Type 7 LSAs describe networks that are external to the autonomous system, but they are flooded to the NSSA only. NSSAs are covered in RFC 1587. This LSA is generated by the NSSA ASBR and has type 0x2007.

    Link LSAs describe the router’s link-local address and a list of IPv6 prefixes associated with the link. This LSA is flooded to the local link only and has type 0x0008.

    The intra-area-prefix LSA is a new LSA type that is used to advertise IPv6 prefixes associated with a router, a stub network, or an associated transit network segment. This LSA contains information that used to be part of the router LSAs and network LSAs.

    2Feb, 2023
    BGP – OSPF, BGP, and Route Manipulation

    This section covers Border Gateway Protocol (BGP) theory and design concepts. The current version of BGP, version 4, is defined in RFC 4271. BGP is an interdomain routing protocol, which means it is used to exchange routing information between autonomous systems. (It is used for inter-autonomous system routing.) The primary function of BGP is to provide and exchange network-reachability information between domains or autonomous systems. BGP is a path vector protocol. BGP is best suited for setting routing policies between autonomous systems. In the enterprise campus architecture, BGP is used for Internet connectivity.

    BGP is the de facto standard for routing between service providers on the Internet because of its rich features. You can also use it to exchange routes in large internal networks. The Internet Assigned Numbers Authority (IANA) reserved TCP port 179 to identify BGP. BGPv4 was created to provide CIDR, a feature that was not present in the earlier versions of BGP. BGP is a path vector routing protocol; it is neither a distance vector nor link-state routing protocol.

    Note

    RFC 1519 describes CIDR, which provides the capability to forward packets based on IP prefixes only, with no concern for IP address class boundaries. CIDR was created as a means to constrain the growth of the routing tables in the Internet core through the summarization of IP addresses across network class boundaries. The early 1990s saw an increase in the growth of Internet routing tables and a reduction in Class B address space. CIDR provides a way for service providers to assign address blocks smaller than a Class B network but larger than a Class C network.

    BGP Neighbors

    BGP is usually configured between two directly connected routers that belong to different autonomous systems. Each autonomous system is under different technical administration. BGP is frequently used to connect the enterprise to service providers and to interconnect service providers, as shown in Figure 4-9. The routing protocol within the enterprise could be any interior gateway protocol (IGP). Common IGP choices include RIPv2, EIGRP, OSPF, and IS-IS. BGPv4 is the only deployed exterior gateway protocol (EGP).

    Figure 4-9 BGP Neighbors

    BGP is an interdomain routing protocol that allows BGP speakers residing in different autonomous systems to exchange routing network layer reachability information. An autonomous system is a collection of devices under common administration. BGP autonomous systems range from 1 through 65,535. Autonomous system numbers (ASNs) 1 through 64,511 are considered public ASNs. These are allocated by IANA to Regional Internet Registries (RIR). Entities wanting to receive an ASN must complete the application process with the local RIR and be approved before being assigned an ASN. ASNs 64,512 through 65,535 are considered private ASNs. These ASNs can be used by any organization, but, like RFC 1918 addresses, they cannot be used on the Internet.

    Before two BGP routers can exchange routing updates, they must become established neighbors. After BGP routers establish a TCP connection, exchange information, and accept the information, they become established neighbors and start exchanging routing updates. If the neighbors do not reach an established state, they do not exchange BGP updates. The information exchanged before the neighbors are established includes the BGP version number, ASN, BGP router ID, and BGP capabilities.

    25Nov, 2022
    eBGP – OSPF, BGP, and Route Manipulation

    External Border Gateway Protocol (eBGP) is the term used to describe BGP peering between neighbors in different autonomous systems. As required by RFC 1771, the eBGP peers share a common subnet (although Cisco does allow some flexibility to avoid doing so). In Figure 4-10, all routers speak eBGP with routers in other autonomous systems. Within AS 500, the routers communicate using iBGP, which is covered next.

    Figure 4-10 eBGP Used Between Autonomous Systems

    iBGP

    Internal Border Gateway Protocol (iBGP) is the term used to describe the peering between BGP neighbors in the same autonomous system. iBGP is used primarily in transit autonomous systems. Transit autonomous systems forward traffic from one external autonomous system to another external autonomous system. If transit autonomous systems did not use iBGP, the eBGP-learned routes would have to be redistributed into an IGP and then redistributed into the BGP process in another eBGP router. Normally, the number of eBGP routes is too large for an IGP to handle.

    iBGP provides a better way to control the routes within the transit autonomous system. With iBGP, the external route information (such as attributes) is forwarded. The various IGPs that might be used do not understand or forward BGP attributes, including autonomous system paths, between eBGP routers.

    Another use of iBGP is in large corporations, where the IGP networks are in smaller independent routing domains along organizational or geographic boundaries. In Figure 4-11, a company has decided to use three independent IGPs: one for the Americas; another for Asia and Australia; and another for Europe, the Middle East, and Africa. Routes are redistributed into an iBGP core.

    Figure 4-11 iBGP in a Large Corporation

    A CCNP enterprise designer should know at a high level these other uses for iBGP:

    • Applying policies in the internal autonomous system with the help of BGP path attributes: BGP path attributes are covered later in this chapter.
    • QoS policy propagation on BGP (QPPB): QPPB uses iBGP to spread common QoS parameters from one router to other routers in the network. It classifies packets using IP precedence bits based on BGP community lists, BGP autonomous system paths, and access lists. After packets are classified, QoS features can enforce policies.
    • Multiprotocol BGP (MP-BGP) peering of Multiprotocol Label Switching (MPLS) virtual private networks (VPNs): The multiprotocol version of BGP is used to carry MPLS VPN information between all provider edge (PE) routers within a VPN community. Multiprotocol Border Gateway Protocol (MP-BGP) is defined in RFC 2858. It introduces a new BGP capabilities advertisement to determine whether a BGP peer supports MP-BGP. It introduces optional nontransitive attributes used to advertise feasible routes to a peer, network layer reachability information, and other characteristics. It defines an address family identifier (AFI) of 2 to identify IPv6, which is used to convey an IPv4 address as the BGP next hop for the advertised IPv6 prefixes.
    15Oct, 2022
    Route Reflectors – OSPF, BGP, and Route Manipulation

    iBGP requires that all routers be configured to establish a logical connection with all other iBGP routers. The logical connection is a TCP link between all iBGP-speaking routers. The routers in each TCP link become BGP peers. In large networks, the number of iBGP-meshed peers can become very large. Network administrators can use route reflectors to reduce the number of required mesh links between iBGP peers. Some routers are selected to become the route reflectors to serve several other routers that act as route-reflector clients. Route reflectors allow a router to advertise or reflect routes to clients. The route reflector and its clients form a cluster. All client routers in the cluster peer with the route reflectors within the cluster. The route reflectors also peer with all other route reflectors in the internetwork. A cluster can have more than one route reflector.

    In Figure 4-12, without route reflectors, all iBGP routers are configured in an iBGP mesh, as required by the protocol. When Routers A and G become route reflectors, they peer with Routers C and D; Router B becomes a route reflector for Routers E and F. Routers A, B, and G peer among each other.

    Figure 4-12 Route Reflectors

    Routers A and G are configured to peer with each other and with Routers B, C, and D. The configuration of Routers C and D is different from the configuration of the rest of the routers; they are configured to peer with Routers A and G only. All route reflectors in the same cluster must have the same cluster ID number.

    Note

    The combination of the route reflector and its clients is called a cluster. In Figure 4-12, Routers A, G, C, and D form a cluster. Routers B, E, and F form another cluster.

    Router B is the route reflector for the second cluster. Router B peers with Routers A and G and with Routers E and F in its cluster. Routers E and F are route-reflector clients and peer only with Router B. If Router B goes down, the cluster on the right goes down because no second route reflector is configured.

    15Jul, 2022
    Confederations – OSPF, BGP, and Route Manipulation

    Another method to reduce the iBGP mesh within an autonomous system is to use BGP confederations. With confederations, the autonomous system is divided into smaller, sub-autonomous systems, and the whole group is assigned a confederation ID. The sub-ASNs or identifiers are not advertised to the Internet but are contained within the iBGP networks. The routers within each private autonomous system are configured with the full iBGP mesh. Each sub-autonomous system is configured with eBGP to communicate with other sub-autonomous systems in the confederation. External autonomous systems see only the ASN of the confederation, and this number is configured with the BGP confederation identifier.

    In Figure 4-13, a confederation divides the autonomous system into two.

    Figure 4-13 BGP Confederations

    Routers A, B, and G are configured for eBGP between the sub-autonomous systems. This involves using the bgp confederation identifier command on all routers, where confederation identifier is the same for all routers in the network. You use the bgp confederation peers command to identify the ASN of other sub-autonomous systems in the confederation. Because Routers A and G are in AS 10, the peer confederation to Router B is AS 20. Router B is in AS 20, and its peer confederation to Routers A and G is AS 10. Routers C and D are part of AS 10 and peer with each other and with Routers A and G. Routers E and F are part of AS 20 and peer with each other and with Router B.

    BGP Administrative Distance

    Cisco IOS software assigns an administrative distance to eBGP and iBGP routes, as it does with other routing protocols. For the same prefix, the route with the lowest administrative distance is selected for inclusion in the IP forwarding table. For BGP, the administrative distances are

    • eBGP routes: 20
    • iBGP routes: 200

    BGP Attributes, Weight, and the BGP Decision Process

    BGP uses path attributes to select the best path to a destination. This section describes BGP attributes, the use of weight to influence path selection, and the BGP decision process.

    BGP Path Attributes

    BGP uses several attributes, or metrics, for the path-selection process. BGP uses path attributes to communicate routing policies. BGP path attributes include next hop, local preference, autonomous system path, origin, multi-exit discriminator (MED), community, atomic aggregate, and aggregator. Of these, the autonomous system path is one of the most important attributes: It lists the number of autonomous system paths to reach a destination network.

    BGP attributes can be categorized as well known or optional. Well-known attributes are recognized by all BGP implementations. Optional attributes do not have to be supported by the BGP process.

    Well-known attributes can be further subcategorized as mandatory or discretionary. Mandatory attributes are always included in BGP update messages. Discretionary attributes might or might not be included in BGP update messages.

    Optional attributes can be further subcategorized as transitive or nontransitive. Routers must advertise a route with transitive attributes to their peers even if they do not support the attribute locally. If the path attribute is nontransitive, the router does not have to advertise the route to its peers.

    The following sections cover each attribute category.

    1May, 2022
    Next-Hop Attribute – OSPF, BGP, and Route Manipulation

    The next-hop attribute is the IP address of the next IP hop that will be used to reach the destination. The next-hop attribute is a well-known mandatory attribute.

    Local Preference Attribute

    The local preference attribute indicates which path to use to exit the autonomous system. It is a well-known discretionary attribute used between iBGP peers and is not passed on to external BGP peers. In Cisco IOS software, the default local preference is 100. The higher local preference is preferred.

    The default local preference is configured on the BGP router with an external path; it then advertises its local preference to internal iBGP peers. Figure 4-14 shows an example of the local preference attribute where Routers B and C are configured with different local preference values. Router A and other iBGP routers then receive routes from both Router B and Router C. Between the two possible paths (shown with arrows), Router A prefers using Router C to route Internet packets because it has a higher local preference (400) than Router B (300).

    Figure 4-14 BGP Local Preference

    Origin Attribute

    Origin is a well-known mandatory attribute that defines the source of the path information. Do not confuse the origin with comparing whether a route is external (eBGP) or internal (iBGP). The origin attribute is received from the source BGP router. There are three types:

    • IGP: Indicated by an i in the BGP table. Present when the route is learned by way of the network statement.
    • EGP: Indicated by an e in the BGP table. Learned from an EGP peer.
    • Incomplete: Indicated by a question mark (?) in the BGP table. Learned from redistribution of the route.

    In terms of choosing a route based on origin, BGP prefers routes that have been verified by an IGP over routes that have been learned from EGP peers, and BGP prefers routes learned from eBGP peers over incomplete paths.

    Autonomous System Path (AS_Path) Attribute

    The autonomous system path is a well-known mandatory attribute that contains a list of ASNs in the path to the destination. Each autonomous system prepends its own ASN to the autonomous system path. The autonomous system path describes all the autonomous systems a packet would have to travel to reach the destination IP network. It is used to ensure that the path is loop free. When the AS_Path attribute is used to select a path, the route with the fewest autonomous system hops is preferred. In the case of a tie, other attributes, such as MED, break the tie. Example 4-1 shows the autonomous system path for network 200.50.32.0/19. To reach the destination, a packet must pass autonomous systems 3561, 7004, and 7418. The command show ip bgp 200.50.32.0 displays the autonomous system path information.

    Example 4-1 Autonomous System Path Attribute

    Click here to view code image Router#
    show ip bgp 200.50.32.0

    BGP routing table entry for 200.50.32.0/19, version 93313535
    Paths: (1 available, best #1)
      Not advertised to any peer
      3561 7004 7418
       206.24.241.181 (metric 490201) from 165.117.1.219 (165.117.1.219)
        Origin IGP, metric 4294967294, localpref 100, valid, internal, best
        Community: 2548:182 2548:337 2548:666 3706:153

    15Mar, 2022
    MED Attribute – OSPF, BGP, and Route Manipulation

    The multi-exit discriminator (MED) attribute tells an external BGP peer the preferred path into the autonomous system when multiple paths into the same autonomous system exist. In other words, MED influences which one of many paths a neighboring autonomous system uses to reach destinations within the autonomous system. It is an optional nontransitive attribute carried in eBGP updates. The MED attribute is not used with iBGP peers. The lowest MED value is preferred, and the default value is 0. Paths received with no MED are assigned a MED of 0. The MED is carried into an autonomous system but does not leave the autonomous system.

    Consider the diagram shown in Figure 4-15. With all attributes considered equal, say that Router C selects Router A as its best path into AS 100, based on Router A’s lower router ID (RID). If Router A is configured with a MED of 200, Router C will select Router B as the best path to AS 100. No additional configuration is required on Router B because the default MED is 0.

    Figure 4-15 MED Attribute

    Community Attribute

    Although it is not an attribute used in the routing-decision process, the community attribute groups routes and applies policies or decisions (accept, prefer) to those routes. It is a group of destinations that share some common property. The community attribute is an optional transitive attribute of variable length.

    Atomic Aggregate and Aggregator Attributes

    The atomic aggregate attribute informs BGP peers that the local router used a less specific (aggregated) route to a destination instead of using a more specific route.

    The purpose of the attribute is to alert BGP speakers along the path that some information has been lost due to the route aggregation process, and the aggregate path might not be the best path to the destination. When some routes are aggregated by an aggregator, the aggregator does attach its RID to the aggregated route in the AGGREGATOR_ID attribute, and it sets the ATOMIC_AGGREGATE attribute (or not) based on whether the AS_Path information of the aggregated routes was preserved. The atomic aggregate attribute lets the BGP peers know that the BGP router used an aggregated route. A more specific route must be in the advertising router’s BGP table before it propagates an aggregate route.

    When the atomic aggregate attribute is used, the BGP speaker has the option to send the aggregator attribute. The aggregator attribute includes the ASN and the IP address of the router that originated the aggregated route. In Cisco routers, the IP address used is the RID of the router that performs the route aggregation. Atomic aggregate is a well-known discretionary attribute, and aggregator is an optional transitive attribute.

    10Jan, 2022
    Weight Attribute – OSPF, BGP, and Route Manipulation

    Weight is assigned locally on a router to specify a preferred path if multiple paths exist out of a router for a destination. Weights can be applied to individual routes or to all routes received from a peer. Weight is specific to Cisco routers and is not propagated to other routers. The weight value ranges from 0 to 65,535. Routes with a higher weight are preferred when multiple routes to a destination exist. Routes that are originated by the local router have a default weight of 32,768. The default weight for learned routes is 0.

    You can use weight rather than local preference to influence the selected path to external BGP peers. The difference is that weight is configured locally and is not exchanged in BGP updates. On the other hand, the local preference attribute is exchanged between iBGP peers and is configured at the gateway router.

    When the same destinations are advertised from both Router B and Router C, as shown in Figure 4-16, Router A prefers the routes from Router C over those from Router B because the routes received from Router C have a larger weight (600) locally assigned.

    Figure 4-16 BGP Weight

    Table 4-7 lists and describes the BGP attributes and their categories.

    Table 4-7 BGP Attributes

    BGP AttributeDescriptionCategory
    OriginIndicates the source of the path information: IGP, EGP, or incomplete.Well-known mandatory
    AS_PathLists the ASNs in the path to the destination.Well-known mandatory
    Next hopSpecifies the IP address of the router as the next hop to the destination.Well-known mandatory
    Local preferenceSpecifies the path to use to exit the AS.Well-known discretionary
    MEDTells an external BGP peer the preferred path into the AS.Optional non-transitive
    CommunityGroups routes and applies policies or decisions (accept, prefer) to those routes. (Not an attribute used in the routing-decision process.)Optional transitive
    Atomic aggregateInforms BGP peers that the local router used a less specific (aggregated) route to a destination instead of using a more specific route.Well-known discretionary
    WeightSpecifies a preferred path if multiple paths exist out of a router for a destination. Assigned locally on a router.Optional (Cisco specific)
    15Nov, 2021
    BGP Decision Process – OSPF, BGP, and Route Manipulation

    By default, BGP selects only a single path to reach a specific destination (unless you specify maximum paths). The Cisco implementation of BGP uses a simple decision process. When the path is selected, BGP puts the selected path in its routing table and propagates the path to its neighbors.

    To select the best path to a destination, Cisco routers running BGP use the following algorithm in the following order:

    If the specified next hop is inaccessible, drop the path.

    If the path is internal, and synchronization is enabled, and the path is not in the IGP, drop the path.

    Prefer the path with the highest weight. (This step is Cisco specific, and weight is localized to the router.)

    Prefer the path with the highest local preference. iBGP uses this path only to reach the preferred external BGP router.

    Prefer the path that was locally originated via a network or aggregate BGP subcommand or through redistribution from an IGP. Local paths sourced by network or redistribute commands are preferred over local aggregates sourced by the aggregate-address command. (This step is Cisco specific.)

    If no route was originated, prefer the route that has the shortest AS_Path.

    If all paths have the same autonomous system path length, prefer the path with the lowest origin type. Paths with an origin type of IGP (lower) are preferred over paths originated from an EGP such as BGP, and EGP origin is preferred over a route with an incomplete origin. (IGP < EGP < incomplete.)

    If the origin codes are the same, prefer the path with the lowest MED attribute. An eBGP peer uses this attribute to select a best path to the autonomous system. This attribute is exchanged between autonomous systems. (This step is a tiebreaker, as described in RFC 4271xxx.)

    If the paths have the same MED, prefer the external (eBGP) path over the internal (iBGP) path.

    If the paths are still the same, prefer the path through the closest IGP neighbor (best IGP metric). (This step is a tiebreaker, as described in RFC 4271xxx.)

    Prefer the oldest known path.

    Prefer the path with the BGP neighbor with the lowest BGP router ID. (The RFC that defines the BGP describes the router ID.)

    Prefer the path with the minimum cluster list length.

    Prefer the path with the lowest neighbor IP address.

    After BGP decides on a best path, it marks that path with a > sign in the output of the show ip bgp command and adds it to the IP routing table.

    Note

    Options for influencing outbound routing decisions include weight, local preference, and AS path length. Options for influencing inbound routing decisions include AS path length, BGP communities, and MED.

    Table 4-8 shows a summary of the BGP best path order.

    Table 4-8 BGP Best Path Order

    BGP Best Path Order
    Highest weight
    Highest local preference
    Prefer local originated route
    Shortest AS_Path
    Lowest origin type
    Lowest MED
    Prefer eBGP over iBGP
    Lowest IGP metric to the BGP next hop
    Oldest path
    Lowest BGP router ID source
    Minimum cluster list length
    Lowest neighbor address
    11Sep, 2021
    BGP Route Manipulation and Load Balancing – OSPF, BGP, and Route Manipulation

    By default, BGP chooses a single path to a destination. With thousands of routes, this choice can cause uneven traffic patterns. When you are working with BGP, there are different methods to control traffic paths and handle load balancing of traffic. Furthermore, outbound and inbound traffic flows are independent of each other.

    For incoming traffic, the following methods can be used to manipulate traffic:

    • You can advertise a subset of the network via ISP 1 and another via ISP 2. For example, if you have a /22 network, you can advertise subnet /23 on your side and the second /23 on the other side and the /22 on both sides.
    • With AS_Path prepending, you can add one or more AS numbers to the left of the AS_Path to make it longer.
    • You can use the BGP multi-exit discriminator (MED) attribute. When there are multiple entry points, MED tells the other AS how to route traffic into the AS.
    • You can use BGP communities with local preference to set up flags in order to mark a set of routes. Then the service provider can use those flags to apply local preference within the network.
    • You can use the BGP allow-as and as-override subcommands to allow eBGP routers to accept routes from the same AS.

    For outbound traffic, the following methods can be used to manipulate traffic:

    • You can use default routes to provide outbound traffic load balancing.
    • You can use provider-advertised partial routes from each provider or request full Internet tables and perform AS_Path filtering.
    • You can use the local preference attribute to indicate which path to use to exit the autonomous system. The higher local preference is used.
    eBGP Multihop

    eBGP Multihop can be used to connect to a BGP neighbor across multiple equal-cost links, as shown in Figure 4-17. The BGP peering is established between the loopback addresses and not the point-to-point links. This means the BGP peers do not have to be directly connected.

    Figure 4-17 eBGP Multihop and Multipath

    BGP Multipath

    BGP Multipath Load Sharing for eBGP and iBGP allows you to configure multipath load balancing with both eBGP and iBGP paths in BGP networks that are configured to use MPLS. This is accomplished using the maximum-paths command. For example, in Figure 4-17, the eBGP peering can be established by using the interface address of each link and not the loopback address. As a result, the routers receive multiple paths—one for each link—and install all paths up to the maximum-paths value that was configured.

    BGP Summary

    The characteristics of BGP follow:

    • BGP is an EGP used in routing on the Internet. It is an interdomain routing protocol.
    • BGP is a path vector routing protocol suited for strategic routing policies.
    • It uses TCP port 179 to establish connections with neighbors.
    • BGPv4 implements CIDR.
    • eBGP is used for external neighbors. It is used between different autonomous systems.
    • iBGP is used for internal neighbors. It is used within an autonomous system.
    • BGP uses several attributes in the routing-decision algorithm.
    • It uses confederations and route reflectors to reduce BGP peering overhead.
    • The MED attribute is used between autonomous systems to influence inbound traffic.
    • Weight is used to influence the path of outbound traffic from a single router, configured locally.
    • eBGP routes have an administrative distance of 20, and iBGP routes have an administrative distance of 200.