CCNP ROUTE (Version 7) – Chapter 7: BGP Implementation

Topics

• BGP Terminology, Concepts, and Operation
• Implementing Basic BGP
• BGP Attributes and the Path-Selection Process
• Controlling BGP Routing Updates
• Implementing BGP for IPv6 Internet Connectivity

BGP Terminology, Concepts, and Operation

• Using BGP between autonomous systems
• Comparing BGP with other scalable routing protocols
• BGP path vector characteristics
• BGP characteristics
• BGP tables
• BGP message types
• When to use BGP
• When not to use BGP

BGP Use Between Autonomous Systems

• BGP’s interdomain routing enables connectivity between autonomous systems.
• Is usually based on a set of policies, not just the technical characteristics of the underlying infrastructure.

Comparison with Other Scalable Routing Protocols

• BGP is also a distance vector protocol, with many enhancements; it is usually called a path vector protocol.
• BGP does not look at bandwidth for the best path.
• BGP is a policy-based routing protocol that allows an autonomous system to control traffic flow using multiple BGP attributes.

BGP Path Vector Characteristics

• BGP routers exchange network reachability information, called path vectors, made up of path attributes.

• The autonomous system path information is used to construct a graph of loop-free autonomous systems.

For AS 64512 to reach networks in AS 64700 through AS 64520, some possible paths are:

• 64520 64600 64700
• 64520 64600 64540 64550 64700
• 64520 64540 64600 64700
• 64520 64540 64550 64700

Autonomous system 64512 does not see all these possibilities. AS 64520 only announce its bets path

BGP Characteristics

• BGP uses the Transmission Control Protocol (TCP) as its transport protocol. Port number 179.
• After the TCP connection is made, the routers exchange their full BGP tables.
• Because the connection is reliable, BGP routers need to send only changes (incremental updates) after that.
• TCP is designed to use a sliding window.
• This method allows any TCP application, such as BGP, to continue streaming packets without having to stop and wait, as OSPF or EIGRP.

BGP Tables

BGP keeps a neighbor table containing a list of neighbors with which it has a BGP connection.

A router running BGP also keeps its own table for storing BGP information received from and sent to other routers. Also called:

• BGP table
• BGP topology table
• BGP topology database
• BGP routing table
• BGP forwarding database.

• The router offers the best routes from the BGP table to the IP routing table.
• They can be configured to share information between the two tables (by redistribution).
• For BGP to establish an adjacency, you must configure it explicitly for each neighbor.
• BGP sends BGP/TCP keepalives by default every 60 seconds.
• After establishing an adjacency, the neighbors exchange their best BGP routes.
• All routes that have been learned from each neighbor are placed in the BGP table.
• Each path learned is associated with BGP attributes.
• The single best route for each network is selected from the BGP table using these attributes in the BGP route-selection process and then offered to the IP routing table.
• Each router compares the offered BGP routes to any other possible paths to those networks in its IP routing table, and the best route, based on administrative distance, is installed in the IP  routing table.
• External BGP (eBGP) routes (BGP routes learned from an external autonomous system) have a default administrative distance of 20.
• Internal BGP (iBGP) routes (BGP routes learned from within the autonomous system) have a default administrative distance of 200.
• Note: A route does not have to be in the IP routing table for BGP to advertise it. BGP advertises the best route from the BGP table.

BGP Message Types

BGP defines the following message types:

• Open
• Keepalive
• Update
• Notification

Open and Keepalive Messages

• After a TCP connection is established, the first message sent by each side is an open message.
• When the open is confirmed, the BGP connection is established, and update, keepalive, and notification messages can be exchanged.
• Keepalive packets are sent to ensure that the connection is alive between the BGP peers.
• Notification packets are sent in response to errors or special conditions.

An open message includes the following information:

• Version: This 8-bit field indicates the message’s BGP version number. (BGP-4).
• My autonomous system: This 16-bit field indicates the sender’s autonomous system number.
• Hold time: This 16-bit field indicates the maximum number of seconds that can elapse between the successive keepalive or update messages from the sender.
• BGP router identifier (router ID): This 32-bit field indicates the sender’s BGP identifier. Chosen the same way as OSPF ID.
• Optional parameters: A length field indicates the total length of the optional parameters field in octets.

Update Messages

An update message has information on one path only. multiple paths require multiple messages.

All the attributes in the update message refer to that path, and the networks are those that can be reached through that path.

An update message might include the following fields:

• Withdrawn routes: A list of IP address prefixes for routes that are being withdrawn from service, if any.
• Path attributes: The attribute type consists of the attribute flags, followed by the attribute type code.
• Network layer reachability information (NLRI): A list of networks (IP address prefixes and their prefix lengths) that can be reached by this path.

Notification Messages

• A BGP router sends a notification message when it detects an error condition.
• The BGP router closes the BGP connection immediately after sending the notification message.
• Notification messages include an error code, an error subcode, and data related to the error.

When to Use BGP

BGP use in an autonomous system is most appropriate when the effects of BGP are well understood and at least one of the following conditions exists:

• The autonomous system allows packets to transit through it to reach other autonomous systems (for example, it is a service provider).
• The autonomous system has multiple connections to other autonomous systems.
• Routing policy and route selection for traffic entering and leaving the autonomous system must be manipulated.

When Not to Use BGP

Do not use BGP if one or more of the following conditions exist:

• A single connection to the Internet or another autonomous system.
• Lack of memory or processor power on edge routers to handle constant BGP updates.
• You have a limited understanding of route filtering and the BGP path- selection process.
• If the routing policy that will be implemented in an autonomous system is consistent with the policy implemented in the ISP autonomous system.

Implementing Basic BGP

• BGP neighbor relationships
• Basic BGP configuration requirements
• Entering BGP configuration mode
• Defining BGP neighbors and activating BGP sessions
• Basic BGP configuration and verification

BGP Neighbor Relationships

• A BGP peer, also known as a BGP neighbor, is a BGP speaker that is configured to form a neighbor relationship with another BGP speaker for the purpose of directly  exchanging BGP routing information with one another.
• A BGP speaker has a limited number of BGP neighbors with which it peers and forms a TCP-based relationship

External BGP Neighbors

• When BGP is running between routers in different autonomous systems, it is called external BGP.
• Routers running eBGP are usually directly connected to each other.

• An eBGP neighbor is a router running in a different autonomous system.
• For two routers to exchange BGP routing updates, the TCP transport layer on each side must successfully pass the TCP three-way handshake.
• Therefore, the IP address used in the neighbor command must be reachable without using an IGP.
• Note If a BGP neighbor is not directly connected, a router must have a route to the neighbor’s address installed in its routing table; a default route does not suffice for this use.

Internal BGP Neighbors

When BGP is running between routers within the same autonomous system, it is called internal BGP.

There are several requirements for an iBGP neighbor relationship:

• Same autonomous system number
• Define neighbors
• Reachability (An IGP typically runs inside the autonomous system, and provides this reachability).

Routers running iBGP do not have to be directly connected to each other.

A loopback address is usually used in the BGP neighbor command to establish the iBGP sessions.

iBGP in a Transit Autonomous System

• All routers in a transit autonomous system must have complete knowledge of external routes.
• Theoretically, one way to achieve this goal is to redistribute BGP routes into an IGP at the edge routers.
• Because the current Internet routing table is very large, redistributing all the BGP routes into an IGP is not a scalable way for the interior routers.
• Another method that you can use is to run iBGP on all routers within the autonomous system.

iBGP in a Nontransit Autonomous System

• A nontransit autonomous system, such as an organization that is multihoming with two ISPs, does not pass routes between the ISPs.
• To make proper routing decisions, however, the BGP routers within the autonomous system still require knowledge of all BGP routes passed to the autonomous  system.

TCP and Full Mesh

• TCP was selected as the transport layer for BGP because TCP can move a large volume of data reliably.
• TCP sessions cannot be multicast or broadcast because TCP has to ensure the delivery of packets to each recipient.
• Because TCP cannot use broadcasting or multicasting, BGP cannot use it either.
• To avoid routing loops within an autonomous system, BGP specifies that routes learned through iBGP are never propagated to other iBGP peers.
• This is sometimes referred to as the BGP split-horizon rule.
• Thus, each iBGP router needs to send routes to all the other iBGP neighbors in the same autonomous system.
• So that they all have a complete picture of the routes sent to the autonomous system.
• Because they cannot use broadcast or multicast, an iBGP neighbor relationship must be configured between each pair of routers.
• If the sending iBGP neighbor is not fully meshed with each iBGP router, the routers that are not peering with this router will have different IP routing tables than the routers that are  peering with it.

BGP Partial-Mesh and Full-Mesh Examples

Basic BGP Configuration Requirements

Basic BGP configuration requires the following main steps:

• Step 1. Define the BGP process.
• Step 2. Establish the neighbor relationships.
• Step 3. Advertise the networks into BGP.

Entering BGP Configuration Mode

• Use the router bgp autonomous-system global configuration command to enter BGP configuration mode and identify the local autonomous system in which this  router belongs.
• The router bgp command alone does not activate BGP on a router.
• You must enter at least one subcommand under the router bgp command to activate the BGP process on the router.
• Only one instance of BGP can be configured on a router at a time.

Defining BGP Neighbors and Activating BGP Sessions

Use the neighbor ip-address remote-as autonomous-system router configuration command

• to activate a BGP session for external and internal neighbors and
• to identify a peer router with which the local router will establish a session.

The ip-address must be reachable.

The autonomous-system field determines if the communication with the peer is and eBGP or iBGP session.

Basic BGP Configuration and Verification

The first part of the show ip bgp summary command output describes the local router:

• BGP router identifier: The IP address that all other BGP speakers recognize as representing this router.
• Local AS number: The local router’s autonomous system number.

The next part of this command output describes the BGP table:

• BGP table version: This is the version number of the local BGP table; it increases when the BGP table changes.
• Main routing table version: This is the last version of BGP database that was injected into the main routing table.

The rest of this command output describes the current neighbor status, one for each configured neighbor:

• Neighbor: The IP address, used in the neighbor statement, with which this router is setting up a relationship.
• Version (V): The version of BGP this router is running with the listed neighbor.
• AS: The listed neighbor’s autonomous system number.
• Messages received (MsgRcvd): The number of BGP messages received from this neighbor.
• Messages sent (MsgSent): The number of BGP messages sent to this neighbor.
• TblVer: The last version of the BGP table that was sent to this neighbor.
• In queue (InQ): The number of messages from this neighbor that are waiting to be processed.
• Out queue (OutQ): The number of messages queued and waiting to be sent to this neighbor. TCP flow control prevents this router from overwhelming a neighbor with a large update.
• Up/down: The length of time this neighbor has been in the current BGP state (established, active, or idle).
• State: The current state of the BGP session: active, idle, open sent, open confirm, or idle (admin).
• Note that if the session is in the established state, a state is not displayed.
• Prefix received (PfxRcd): When the session is in the established state, this value represents the number of BGP network entries received from this neighbor.

Configuring and Verifying an iBGP Session

Advertising Networks in BGP and Verifying That They Are Propagated

• Use the network network-number [mask network-mask] router configuration command to inject routes that are present in the IPv4 routing table into the BGP table so that they can be  advertised in BGP.
• Unlike for IGPs, the network command does not start BGP on specific interfaces.
• Rather, it indicates to BGP which networks it should originate from this router.
• The list of network commands must include all networks in your autonomous system that you want to advertise, not just those locally connected to your router.

• If the (optional) mask parameter is not specified, this command announces only the classful network number.
• At least one subnet of the specified major network must be present in the IP routing table.
• However, if you specify the mask network-mask, an exact match to the network (both address and mask) must exist in the routing table for the network to be advertised.
• You can force a route to be present in the routing table by pointing it to null 0:
• ip route 172.16.0.0 255.255.0.0 null 0

• A row with an asterisk (*) in the first column means that the next-hop address is valid.
• A greater-than sign (>) in the second column indicates the best path for a route selected by BGP. This route is offered to the IP routing table.

Using the Next-Hop-Self Feature

• How BGP establishes an iBGP relationship differs significantly from the way that IGPs behave.
• An internal protocol, such as RIP, EIGRP, or OSPF, always uses the source IP address of a routing update as the next- hop address for each network.
• Recall that BGP routes autonomous system by autonomous system, not router by router, and the default next hop is the next autonomous system.
• As such, for BGP the next hop is the IP address that is used to reach the next autonomous system.
• For iBGP, however, the next hop advertised by eBGP is carried into iBGP, by default.
• It is sometimes necessary to override a router’s default behavior and force it to advertise itself as the next-hop address for routes sent to a neighbor.
• The neighbor ip-address next-hop-self router configuration command enables you to force BGP to use the source IP address of the update as the next hop for  each network it advertises to the neighbor.

Understanding and Troubleshooting BGP Neighbor States

After the TCP handshake is complete, the BGP application tries to set up a session with the neighbor.

BGP is a state machine that takes a router through the following states with its neighbors:

• Idle: The router is searching the routing table to see whether a route exists to reach the neighbor.
• Connect: The router found a route to the neighbor and has completed the threeway TCP handshake.
• Open sent: An open message was sent, with the parameters for the BGP session.
• Open confirm: The router received agreement on the parameters for establishing a session.
• Alternatively, the router goes into the active state if there is no response to the open message.
• Established: Peering is established and routing begins.

Idle State Troubleshooting

The idle state indicates that the router does not know how to reach the IP address listed in the neighbor statement.

Check the following two conditions to troubleshoot this problem:

• Ensure that the neighbor announces the route in its local routing protocol (IGP) (for iBGP neighbors).
• Verify that you have not entered an incorrect IP address in the neighbor statement.

Active State Troubleshooting

• This state means the router has found the IP address in the neighbor statement and has created and sent out a BGP open packet but has not received a response (an open confirm packet)  back from the neighbor.
• One common cause of this is when the neighbor does not have a return route to the source IP address.
• Another common problem associated with the active state is when a BGP router attempts to peer with another BGP router that does not have a neighbor statement peering back at the first  router (or has it wrong).
• If the state toggles between idle and active, the autonomous system numbers might be misconfigured.

BGP Session Resilience

• If the interface to which the IP address used in the neighbor command goes down, the BGP neighbor relationship would be lost.
• In cases where multiple paths exist to reach an iBGP neighboring routers, the routers could peer with each other’s loopback interface address.
• This peering arrangement adds resiliency to the iBGP sessions because they are not tied into a physical interface, which might go down for any number of reasons.
• Both routers must have a route to the loopback address of the other neighbor in their routing table; check to ensure that both routers are announcing their loopback addresses into the IGP.

• The BGP neighbor statement tells the BGP process the destination IP address of each update packet.
• The router must decide which IP address to use as the source IP address in the BGP routing update.
• The routing table lists the appropriate interface to get to the destination address. The address of this outbound interface is used as that packet’s source address by default.
• For BGP packets, this source IP address must match the address in the corresponding neighbor statement on the other router.
• In other words, the other router must have a BGP relationship with thempacket’s source IP address.)
• BGP does not accept unsolicited updates; it must be aware of every neighboring router and have a neighbor statement for it.

Sourcing BGP from Loopback Address

• In this case, R2 and R3 do not establish the BGP session because, despite correct neighbor IP addresses, each router expects the BGP packets to be originated from the  loopback 0 address of the other peer.
• You must tell BGP to use a loopback interface address rather than a physical interface address as the source address for all BGP packets.
• Use the neighbor ip-address update-source loopback interface-number router configuration command.

• Establishing the BGP session between the loopback IP addresses can also help increase the resilience of an eBGP connection.
• If multiple paths between two eBGP neighbors exist, the session will survive no matter which path remains available.
• The loopback addresses must be reachable from both sides, respectively.
• You typically need to configure static routes to the respective remote loopback IP address.

eBGP Multihop

• To fix this issue, you must also enable multihop eBGP, with the neighbor ip-address ebgp-multihop [ttl] router configuration command.
• This command allows the router to accept and attempt BGP connections to external peers residing on networks that are not directly connected.
• This command increases the default of one hop for eBGP peers by changing the default Time To Live (TTL) value of 1 (with the ttl parameter) and therefore allowing routes to the eBGP loopback  address.
• By default, the TTL is set to 255 with this command.
• This command is useful when redundant paths exist between eBGP neighbors.

Resetting BGP Sessions

• BGP can potentially handle huge volumes of routing information.
• When a BGP policy configuration change occurs the router cannot go through the huge table of BGP information and recalculate which entry is no longer valid in the local table.
• To avoid such a problem, the Cisco IOS Software applies changes on only those updates received or sent after the BGP policy configuration change has been performed.
• If the network administrator wants the policy change to be applied on all routes, he or she must trigger an update to force the router to let all routes pass through the new filter.
• There are two ways to trigger an update: a hard reset, and a soft reset.

Hard Reset of BGP Sessions

• Resetting a session is a method of informing the neighbor or neighbors of a policy change.
• If BGP sessions are reset, all information received on those sessions is invalidated and removed from the BGP table.
• After a period of 30 to 60 seconds, the BGP sessions are reestablished automatically, and the BGP table is exchanged again, but through the new filters.
• Resetting the BGP session disrupts packet forwarding.
• Use the clear ip bgp * or clear ip bgp {neighbor-address} privileged EXEC command to cause a hard reset of the BGP neighbors involved.
• Be careful using the * option.

Soft Reset or Route Refresh

• Use the clear ip bgp {* | neighbor-address} out privileged EXEC command to cause BGP to do a soft reset for outbound updates.
• The router on which this command is issued does not reset the BGP session.
• Instead, the router creates a new update and sends the whole table to the specified neighbors.
• This update includes withdrawal commands for networks that the neighbor will not see anymore, based on the new outbound policy.
• This command is highly recommended when you are changing an outbound policy, but does not help if you are changing an inbound policy.
• The clear ip bgp soft command performs a soft reconfiguration of both inbound and outbound updates.

• When a BGP session is reset using soft reconfiguration, the following commands can be  useful for monitoring the BGP  routes received, sent, or filtered:
• show ip bgp neighbors {address} received-routes: Displays all received routes (both accepted and  rejected) from the specified neighbor
• show ip bgp neighbors {address} routes: Displays all routes that are received and accepted from the  specified neighbor.
• show ip bgp: Displays entries in the BGP table.
• show ip bgp neighbors {address} advertised-routes: Displays all BGP routes that have been advertised to  neighbors.

BGP Attributes and the Path-Selection Process

BGP Path Selection

• A router running BGP may receive updates about destinations from multiple neighbors, some in different autonomous systems, and therefore multiple paths might exist to reach a given network.
• These are kept in the BGP table.
• BGP chooses only a single best path to reach a specific destination.
• BGP is not designed to perform load balancing; paths are chosen because of policy, not based on bandwidth.
• The best BGP path is submitted to the IP routing table manager process and is evaluated against any other routing protocols that can also reach that network.

BGP Path Selection Process

The Path-Selection Decision Process with a Multihomed Connection

• An autonomous system rarely implements BGP with only one eBGP connection, so generally multiple paths exist for each network in the BGP forwarding database.
• If you are running BGP in a network with only one eBGP connection, it is loop free.
• If the next hop can be reached, the path is submitted to the IP routing table.
• Using the 11-step route-selection process, only the best path is put in the routing table and propagated to the router’s BGP neighbors.
• Without route manipulation, the most common reason for path selection is Step 4, the preference for the shortest AS-path.

BGP Attributes

• BGP uses the path attributes to determine the best path to the networks.
• The following are some terms defining how these attributes are implemented:
• An attribute is either well-known or optional, mandatory or discretionary, and transitive or nontransitive. An attribute might also be partial.
• Valid combinations are:
• Well-known mandatory
• Well-known discretionary
• Optional transitive
• Optional nontransitive
• Only optional transitive attributes might be marked as partial.

Well-Known Attributes

A well-known attribute is one that all BGP implementations must recognize and propagate to BGP neighbors.

There are two types of well-known attributes:

• Well-known mandatory attribute: A well-known mandatory attribute must appear in all BGP update messages.
• Well-known discretionary attribute: it is recognized by all BGP implementations but does not have to be in every update message.

Note If a well-known attribute is missing from an update message, a notification error is generated. This ensures that all BGP implementations agree on a standard set of  attributes.

Optional Attributes

BGP routers that implement an optional attribute might propagate it to other BGP neighbors, depending on its meaning.

• Optional transitive: BGP routers that do not implement an optional transitive attribute should pass it to other BGP routers untouched and mark the attribute as partial.
• Optional nontransitive: BGP routers that do not implement an optional nontransitive attribute must delete the attribute and must not pass it to other BGP routers.

Defined BGP Attributes

In addition, Cisco has defined a weight attribute for BGP. The weight is configured locally on a router and is not propagated to any other BGP routers.

The AS-Path Attribute

• The AS-path attribute is the list of autonomous system numbers that a route has traversed to reach a destination.
• The number of the autonomous system that originated the route is at the end of the list.
• The AS-path attribute is a well-known mandatory attribute.
• Whenever a route update passes through an autonomous system, the autonomous system number is prepended to that update.
• In other words, it is put at the beginning of the list when the update is advertised to the next eBGP neighbor

• BGP routers use the AS-path attribute to ensure a loop-free environment.
• If a BGP router receives a route in which its own autonomous system is part of the AS-path attribute, it does not accept the route.
• Routers advertising routes to iBGP neighbors do not change the AS-path attribute.

The Next-Hop Attribute

• The BGP next-hop attribute is a well-known mandatory attribute that indicates the nexthop IP address that is to be used to reach a destination.
• For eBGP the next-hop address is the IP address of the neighbor that sent the update.
• For iBGP the next hop advertised by eBGP is carried into iBGP by default.
• This behavior can be overridden by configuring a router to advertise itself as the next-hop address for routes sent to its neighbor.

The Origin Attribute

The origin is a well-known mandatory attribute that defines the origin of the path information. The origin attribute can be one of three values:

IGP:

• The route is interior to the originating autonomous system.
• This normally happens when a network command is used to advertise the route via BGP.
• An origin of IGP is indicated with an i in the BGP table.

EGP:

• The route is learned via EGP (not longer supported).
• This is indicated with an e in the BGP table.

Incomplete:

• The route’s origin is unknown or is learned via some other means.
• This usually occurs when a route is redistributed into BGP.
• An incomplete origin is indicated with a ? in the BGP table.

The Local-Preference Attribute

• Local preference is a well-known discretionary attribute that indicates to routers in the autonomous system which path is preferred to exit the autonomous system.
• A path with a higher local preference is preferred.
• The local preference attribute is sent only to iBGP neighbors; it is not passed to eBGP peers.
• The default value for local preference on a Cisco router is 100.

Routers A and B are iBGP neighbors in AS 64520 and both receive updates about network 172.16.0.0 from different directions.

• The local preference on router A is set to 200.
• The local preference on router B is set to 150.

Because the local preference for router A is higher, it is selected as the preferred exit point from AS 64520.

The Community Attribute

• BGP communities are one way to filter incoming or outgoing routes.
• BGP communities allow routers to tag routes with an indicator (the community) and allow other routers to make decisions based on that tag.
• Any BGP router can filter routes in incoming or outgoing updates or can select preferred routes based on communities (the tag).
• Communities are not restricted to one network or one autonomous system, and they have no physical boundaries.
• Communities are optional transitive attributes. If a router does not understand the concept of communities, it defers to the next router.
• However, if the router does understand the concept, it must be configured to propagate the community; otherwise, communities are dropped by default.

The MED Attribute

The MED attribute, also called the metric, is an optional nontransitive attribute.

• In the output of the show ip bgp command for example, the MED is displayed in the metric column.

The MED indicates to external neighbors the preferred path into an autonomous system.

This is a dynamic way for an autonomous system to try to influence another autonomous system as to which way it should choose to reach a certain route if there are multiple entry points  into the autonomous system.

A lower metric value is preferred.

Unlike local preference, the MED is exchanged between autonomous systems

The MED is sent to eBGP peers; those routers propagate the MED within their autonomous system.

• The MED is not passed to a third AS.

MED influences inbound traffic to an autonomous system, whereas local preference influences outbound traffic from an autonomous system.

Keep in mind that there is no guarantee that neighboring autonomous system will take the MED attribute into account; it may have already decided on the path based on other attributes.

By default, a router compares the MED attribute only for paths from neighbors in the same autonomous system.

The Weight Attribute (Cisco Only)

• The weight attribute is configured locally and provides local routing policy only; it is not propagated to any BGP neighbors.
• Routes with a higher weight are preferred when multiple routes to the same destination exist.
• The weight can have a value from 0 to 65535. Paths that the router originates have a weight of 32768 by default, and other paths have a weight of 0 by default.
• The weight attribute applies when using one router with multiple exit points out of an autonomous system.
• Compare this to the local preference attribute, which is used when two or more routers provide multiple exit points.

• Router R1 has two ways to reach 209.165.201.0 and must decide which way to go.
• Router R1 is configured to set the weight of updates coming from router R2 to 200 and the weight of those coming from router R3 to 150.
• Because the weight for router R2’s updates is higher, router R1 uses router R2 as a next hop to reach 209.165.201.0.

Changing the Weight for All Updates from a Neighbor

The neighbor ip-address weight weight router configuration command is used to assign a weight to updates from a neighbor connection

Changing the Weight Using Route Maps

Influencing BGP Path Selection

Changing the Weight

Changing Local Preference

• Local-preference settings are shared within an autonomous system, so this will affect both GW1 and GW2.
• One way to change the local preference is to change the default value of 100 with the bgp default local-preference value router configuration command.
• All BGP routes that are advertised would include this local preference value.
• Local preference can also be changed within a route map.

Setting the AS-Path

• One way that an autonomous system can attempt to influence incoming traffic flow is by sending out eBGP updates with an extended AS-path attribute for undesired paths.
• The autonomous system path is extended with multiple copies of the autonomous system number of the sender.
• The receiver of this update is less likely to select the path as the best because its AS-path attribute appears to be longer.
• This feature is called AS-path prepending.
• You can configure prepending on a router for all routing updates that you send to a neighbor or only on a subset of them.
• In our example topology, GW2 needs to prepend a single instance of its autonomous system number to the AS-path advertised to ISP2. ISP3 will receive updates about the networks in autonomous system 65000 with a  shorter path via ISP1 and a longer path via ISP2

Controlling BGP Routing Updates

Filtering BGP Routing Updates

BGP allows you to filter updates that are received from a neighbor or that are sent to a neighbor.

The primary route filtering tools include route maps, distribute lists and prefix lists.

A common scenario where update filtering is used is in dual-homed enterprise environments.

In this environment, an enterprise should advertise only its own address space to the ISPs.

BGP Filtering Using Prefix Lists

The neighbor ip-address prefix-list prefix-list-name {in | out} router configuration command is used to apply a prefix list to routes from or to a neighbor.

BGP Filtering Using AS-Path Access Lists

When a BGP route is sourced as a result of a network command in a BGP process or redistribution into a BGP process, the AS-path attribute is created and is empty.

Each time the route is advertised by an egress router to another autonomous system, the AS-path attribute is modified, with the egress AS number being prepended.

Routers can filter incoming routes based on their AS-path attributes.

When routers filter BGP updates based on the content of the AS-path attribute, they use regular expressions.

The autonomous system path access list is defined by the ip as-path access-list accesslist-number {permit | deny} regexp global configuration command.

The neighbor ip-address filter-list access-list-number {in | out} router configuration command is used to apply an AS- path access list to routes from or to a neighbor.

Routes that are permitted by the AS-path access list are permitted to be received from or sent to the neighbor, and those that are denied are not included.

*These commands avoid AS6500 to be used as a transit network.

BGP Filtering Using Route Maps

A route map can match and set several different BGP attributes, including the following:

• Origin
• Next hop
• Community
• Local preference
• MED

Route maps can match based on other items, including the following:

• Network number and subnet mask (with an IP prefix list)
• Route originator
• Tag attached to an IGP route
• AS-path
• Route type (internal or external)

When used for BGP filtering, a deny means that the route is ignored and a permit means that the route is processed further and the set clauses are applied.

The set clauses allow one or more attributes to be changed or set to specific values before the route passes the route map.

To apply a route map to filter incoming or outgoing BGP routes, use the neighbor routemap router configuration command.

AS6500 only accepts a default route and uses AS 65100 as their primary link

Filtering Order

The incoming filter list, prefix list (or distribute list) and route map (in this order) must all permit the routes that are received from a neighbor before they will be accepted into  the BGP table.

Similarly, outgoing routes must pass the outgoing filter list, route map, and prefix list (or distribute list) (in this order) before they will be sent to the neighbor.

Note: The order in which BGP filtering mechanisms are processed may differ in different IOS versions.

Clearing the BGP Session

Recall from the earlier “Resetting BGP Sessions” section that if you want a policy change, such as a BGP filter, to be applied, you must trigger an update.

You can do either a hard reset or a route refresh (soft reset).

BGP Peer Groups

In BGP, many neighbors are often configured with the same update policies.

On a Cisco IOS router, neighbors with the same update policies can be grouped into peer groups to simplify configuration and, more important, to make updating more  efficient and improve performance.

When a BGP router has many peers, this approach is highly recommended.

Peer Group Operation

The policies of the peer group are similar to a template; the template is then applied to the individual members of the peer group.

Members of the peer group inherit all the peer group’s configuration options.

The router can also be configured to override these options, but only options that affects inbound updates.

The actual TCP transmission still has to be done on a per- neighbor basis because of the connection-oriented characteristics of BGP sessions.

Peer Group Configuration

The neighbor peer-group-name peer-group router configuration command is used to create a BGP peer group.

The neighbor ip-address peer-group peer-group-name router configuration command, is used to assign neighbors as part of the group after the group has been created.

The clear ip bgp peer-group peer-group-name EXEC command is used to reset the BGP connections for all members of a BGP peer group.

Peer Group Configuration Example

Implementing  BGP for IPv6  Internet  Connectivity

MP-BGP is capable of carrying a rich set of routed protocols,  including IPv4 and IPv6, over a transport protocol, such as IPv4  or IPv6.This section covers the following topics:

• MP-BGP support for IPv6
• Exchanging IPv6 routes over an IPv4 session
• Exchanging IPv6 routes over an IPv6 session
• BGP for IPv6 configuration and verification
• Comparing IPv4 to Dual (IPv4/IPv6) BGP transport
• BGP filtering mechanisms for IPv6

MP-BGP Support for IPv6

Multiprotocol extensions are defined as new attributes.

IPv6-specific extensions incorporated into MBGP include the following:

• A new identifier for the IPv6 address family.
• Scoped addresses. (Link-local address as next-hop)
• The next-hop attribute and NLRI are expressed as IPv6 addresses and prefixes.

In an all-IPv4 environment, BGP establishes sessions using IPv4. IPv4 is the carrier protocol. The routes that BGP advertises, which is the passenger protocol, are also IPv4.

Protocols other than IPv4, including IPv6, also need to advertise reachability information.

MP-BGP extensions allow these other protocols to be carried using BGP.

In an all-IPv6 environment, BGP can be used as both the carrier and passenger protocol.

Exchanging IPv6 Routes over an IPv4 Session

Existing IPv4 TCP sessions can carry IPv6 routing information when adding IPv6 support to a network.

MP-BGP allows the use of many address families to define the type of addresses being carried.

The address-family {ipv4 | ipv6} [unicast | multicast] router configuration command enters address family configuration mode for configuring BGP routing sessions.

In an IPv6 address family, a neighbor needs to be activated using the neighbor {IPv4 address | IPv6 address} activate address- family configuration command.

The network ipv6-address/prefix-length command, this time in address family configuration mode, is used to specify the networks to be advertised.

Exchanging IPv6 Routes over an IPv6 Session

MP-BGP also supports exchanging IPv6 routes over an IPv6 session.

By default, BGP sets its router ID to the IPv4 address of the highest address of the loopback interface, or if no loopback exists, to the highest IP address of the physical interface.

If a router running BGP over IPv6 transport has no IPv4 addresses configured, you need to manually specify BGP router ID.

The bgp router-id ip-address router configuration command configures a fixed router ID for the local BGP routing process.

The ip-address parameter is an IPv4-address format 32-bit dotted-decimal number.

BGP for IPv6 Configuration and Verification

Initial State of Routers

Enable eBGP IPv6 Route Exchange

*Notice that the configuration is  automatically updated to the  address-family style.

*Notice that the route received  from R2 is not marked as best.

*Notice that the R2 has a valid IPv6 next hop address to R1.

Enable iBGP IPv6 Route Exchange

When IPv6 routes are exchanged over an IPv6 BGP session, the next- hop parameter is correctly configured automatically and there is no need for a route map to modify it.

Comparing IPv4 to Dual (IPv4/IPv6) BGP Transport

Both IPv4 and IPv6 address families can use a single IPv4 neighbor or two separate sessions can be established, one for each address family.

Using a single IPv4 neighbor reduces the number of neighbor sessions. This can significantly reduce the size and complexity of configuration.

However, running IPv6 over an IPv4 session requires modification of the next-hop attribute.

In contrast, when using two separate sessions for IPv4 and IPv6, there is no need to implement route maps to overwrite the next-hop parameter.

Exchange of IPv4 and IPv6 routes is completely independent; neighbor configuration and handling is duplicated.

BGP Filtering Mechanisms for IPv6

MP-BGP offers the same set of IPv6 filtering and route manipulation capabilities that exist for IPv4.

The mechanisms include incoming and outgoing prefix-lists, filter lists (for AS-path matching), and route maps.

The order of incoming and outgoing filtering process is identical to IPv4.

IPv6 Prefix List Filtering

IPv6 Path Selection with BGP Local Preference