CCNP 1 v3.0 Module 9 BGP

1© 2003, Cisco Systems, Inc. All rights reserved.

CCNP 1 v3.0 Module 9BGP

Cisco Networking Academy


Objectives

• Autonomous Systems

• Basic BGP Operation

• Configuring BGP

• Monitoring BGP Operation

• The BGP Routing Process

• BGP Attributes

• The BGP Decision Process

• BGP Route Filtering and Policy Routing

• Redundancy, Symmetry, and Load Balancing

• BGP Redistribution


Overview of Autonomous Systems


Single-homed Autonomous Systems


AS_Path and Private AS Numbers


Multihomed Nontransit Autonomous Systems


Multihomed Transit Autonomous Systems


When Not to Use BGP


BGP Neighbors


BGP Message Types

• The Type field can have four values, 1 to 4. Each of these values corresponds to one of the four BGP message types:

1. Open Message

2. Keepalive Message

3. Notification Message

4. Update Message


Open Message

• Open Message – This message is used to establish connections with peers and includes fields for the BGP version number, the AS number, hold time, and Router ID.


Keepalive Message

• Keepalive Message – This message type is sent periodically between peers to maintain connections and verify paths held by the router sending the keepalive.

• If the periodic timer is set to a value of zero (0), no keepalives are sent.

The recommended keepalive interval is one third of the hold time interval.

The keepalive message is a 19-byte BGP message header with no data following it.


Notification Message

• Notification Message – This message type is used to inform the receiving router of errors.


Update Message

• Update Message – The update messages contain all the information BGP uses to construct a loop free picture of the internetwork.

• There are three basic components of an update message. 1. Network-Layer Reachability Information (NLRI)

2. Path Attributes

3. Withdrawn Routes


BGP Neighbor Negotiation


BGP FSM

• Includes six states:

Idle

Connect

Active

OpenSent

Open Confirm

Established


BGP FSM Idle State

• Idle is the first state of a BGP connection.

– BGP is waiting for a Start event, which is normally initiated by an administrator or a network event; a Start event is usually caused by an administrator configuring a BGP session, resetting an already existing session, or a link coming up across which a BGP is configured.

– At the Start event, BGP initializes its resources, resets a connect retry timer, initiates a TCP connection, and starts listening for a connection that may be initiated by a remote peer.


BGP FSM Idle State

• BGP then transitions to a Connect state. BGP can transition back to Idle from any other state in case of errors (Notification).


BGP FSM Connect State

• BGP is waiting for the TCP connection to be completed.

– If the TCP connection is successful, the state transitions to OpenSent.

– If the TCP connection fails, the state transitions to Active, and the router tries to connect again.

– If the connect retry timer expires, the state will remain in the Connect state, the timer will be reset, and a TCP connection will be initiated.

• In case of any other event (initiated by system or administrator), the state will go back to Idle.


BGP FSM Active State

• BGP is trying to acquire a peer by initiating a TCP connection.

– If it is successful, it will transition to OpenSent. If the connect retry timer expires, BGP will restart the connect timer and fall back to the Connect state.

– While Active, BGP is still listening for a connection that may be initiated from another peer.

• The state may go back to Idle in case of other events, such as a stop event initiated by the system or the operator.


BGP FSM

• In general, a neighbor state that is flip-flopping between Connect and Active is an indication that something is wrong, and the TCP connection is not taking effect.

– It could be because of many TCP retransmissions or the inability of a neighbor to reach the IP address of its peer.


BGP FSM OpenSent State

• BGP is waiting for an OPEN message from its peer. The OPEN message is checked for correctness.

• In case of errors, such as a incompatible version number or an unacceptable AS, the system sends an error NOTIFICATION message and goes back to Idle.


BGP FSM OpenSent State

• If there are no errors, BGP starts sending KEEPALIVE messages and resets the KEEPALIVE timer.


BGP FSM OpenSent

• At the OpenSent state, the BGP will recognize whether the peer belongs to the same AS (Internal BGP - it is an IBGP peer) or to a different AS (External BGP - it is an EBGP peer) by comparing its AS number to the AS number of its peer.

• When a TCP disconnect is detected, the state falls back to Active.

– For any other errors, such as an expiration of the hold timer, BGP will send a NOTIFICATION message with the corresponding error code and will fall back to the Idle state.


BGP FSM OpenConfirm

• BGP is waiting for a KEEPALIVE or NOTIFICATION message.

– If a KEEPALIVE is received, the state will go to the Established state, and the neighbor negotiation is complete.


BGP FSM OpenConfirm

• If a NOTIFICATION message is received, the state falls back to Idle. The system will send periodic KEEPALIVE messages at the rate set by the KEEPALIVE timer.

• In case of any TCP disconnect or in response to any stop event (initiated by the system or the administrator), the state will fall back to Idle. In response to any other event, the system will send a NOTIFICATION message with an FSM error code and will go back to Idle.


BGP FSM Established State

• Established is the final state in the neighbor negotiation; BGP starts exchanging UPDATE packets with its peers.

• Each UPDATE message is checked for errors, such as missing or duplicate attributes. If errors are found, a NOTIFICATION is sent to the peer.

• Any NOTIFICATION received while Established will cause the BGP process to drop the receiving peer back to Idle.


BGP Message Types

• Type: The type field can have four values (1-4):

(1) OPEN

(2) UPDATE

(3) NOTIFICATION

(4) KEEPALIVE.


The BGP Open Message

• If two BGP speakers fail to negotiate a neighbor relationship, they will never exchange updates.

• Neighbor negotiation is based on the successful completion of a TCP connection, the successful processing of the OPEN message, and periodic detection of the KEEPALIVE messages.


The BGP Open Message


The BGP Notification Message

• A NOTIFICATION message can close a peering relationship from any BGP state.

• In the event of a connection failure, you may need to examine a NOTIFICATION message for clues about what went wrong.

• The NOTIFICATION message is composed of the Error Code (8 bits), Error Subcode (8 bits), and a Data fields (variable length).


The BGP Notification Message


Network-Layer Reachability Information (NLRI)

Rather than advertise reachable destinations as a network and a subnet mask,BGP advertises them using network-layer reachability information (NLRI),which consists of prefixes and prefix lengths.


Path Attributes


Path Attributes

Well-known mandatory

• An attribute that has to exist in the BGP UPDATE packet. It must be recognized by all BGP implementations.

• If a well-known attribute is missing, a notification error will be generated; this ensures that all BGP implementations agree on a standard set of attributes.

Examples: AS_PATH, ORIGIN, NEXT_HOP attributes


Path Attributes

Well-known discretionary

• An attribute that is recognized by all BGP implementations, but may or may not be sent in the BGP UPDATE message.

Example: LOCAL_PREF, ATOMIC_AGGREGATE


Path Attributes

Optional transitive

• An attribute that may, or may not be, recognized by all BGP implementations (thus, optional).

• Because the attribute is transitive, BGP should accept and advertise the attribute even if it isn’t recognized.


Path Attributes

Optional non-transitive

• An attribute that may, or may not be, recognized by all BGP implementations.

• Whether or not the receiving BGP router recognizes the attribute, it is non-transitive, and should not passed along to other BGP peers.


Basic BGP Configuration


BGP Operation

• When two routers establish a TCP-enabled BGP connection between each other, they are called neighbors or peers.

• Each router running BGP is called a BGP speaker.


EBGP and IBGP


EBGP and IBGP Configuration Example


Building Peering Sessions


IBGP v EBGP

• When BGP is running inside an AS, it is referred to as Internal BGP (IBGP).– If a BGP router’s role is to route IBGP traffic, it is

called a transit router.

• When BGP runs between autonomous systems, it is called External BGP (EBGP). – Routers that sit on the boundary of an AS and use

EBGP to exchange information with the ISP are called border routers.


EBGP v IBGP

• EBGP peers must be directly connected, but there are certain exceptions to this requirement (mutli-hop BGP).

• In contrast, IBGP peers merely require TCP/IP connectivity within the same AS. – As long as RTY can communicate with RTW using TCP,

both routers can establish an IBGP session.

– If needed, an IGP such as OSPF can provide IBGP peers with routes to each other.

• As long as the two BGP routers can reach each other somehow, they can become BGP neighbors


IBGP

• In a typical configuration, an IBGP router maintains IBGP sessions with all other IBGP routers in the AS, forming a logical full-mesh.– This is necessary because IBGP routers do not advertise

routes learned via IBGP to other IBGP peers (to prevent routing loops).

– In other words, if you want your IBGP routers to exchange BGP routes with each other, you should configure a full-mesh.

– An alternative to this approach: configuring a route reflector (covered later)


EBGP Multihop

• EBGP neighbors must be directly connected in order to establish an EBGP session.

• However, EBGP multihop is a Cisco IOS option allows two routers to be logically connected in an EBGP session, despite the fact that they are separated by a router that does not support BGP.

– The EBGP multihop option is configured on each peer with the following command:

Router(config-router)#neighbor IP-address ebgp-multihop [hops]


EBGP Multihop and IBGP


EBGP Multihop

RTW(config)#router bgp 200

RTW(config-router)#neighbor 1.1.1.2 remote-as 300

RTW(config-router)#neighbor 1.1.1.2 ebgp-multihop 2

RTU(config)#router bgp 300

RTU(config-router)#neighbor 2.2.2.1 remote-as 200

RTU(config-router)#neighbor 2.2.2.1 ebgp-multihop 2

AS 200

AS 300

2.2.2.0/301.1.1.0/30


BGP Operation

• BGP’s job is to exchange routing information between autonomous systems, while guaranteeing loop-free path selection.

– BGP4 is the first version of BGP that supports CIDR and route aggregation.

• BGP does not use technical metrics. Instead, BGP makes routing decisions based on network policies.


BGP Operation

• BGP updates are carried using TCP on port 179.– RIP updates use UDP port 520, while OSPF does not

use a Layer-4 protocol.

• Because BGP requires TCP, IP connectivity must exist between BGP peers and TCP connections must be negotiated between them before updates can be exchanged. – Thus, BGP inherits TCP’s reliable, connection-oriented

properties.


BGP Operation – AS_PATH

Public AS numbers range between 1 and 64511 and the private AS numbers between 64512 and 65535.

500

AS Path =

200100400

300

800


The AS_Path Attribute


BGP Operation

• The connection between any two systems forms a path, and the collection of path information expressed as a sequence of AS numbers (called the AS_PATH).

• This sequence forms a route to reach a specific destination.

–All things being equal, BGP prefers routes with shorter AS paths.


BGP Operation

• Peer routers exchange multiple messages to open and confirm the connection parameters, such as the version of BGP to be used.

• If there are any disagreements between the peers, notification errors are sent and the connection fails.


BGP Operation

• When BGP neighbors first establish a connection, they exchange all candidate BGP routes. After this initial exchange, incremental updates are sent as network information changes. – Incremental updates are more efficient than complete

table updates.

– Especially true with BGP routers, which may contain the complete Internet routing table.


Clearing the BGP Table

• BGP can take up to 60 seconds to learn about configuration changes or topology changes

• To force a change to show up in the BGP table and therefore in the routing table, you may have to clear the BGP table after a configuration change.

Router# clear ip bgp [as number | ip address | *]


Verifying BGP Operation


An Overview of the BGP Routing Process

• Routes are exchanged between BGP peers by way of update messages

• BGP routers receive the update messages

• BGP routers run some policies or filters over the updates, and then pass the routes on to other BGP peers


Implementing Policy

• BGP input and output policies are defined, generally, using route maps.

• Route maps are used with BGP to control and modify routing information and to define the conditions by which routes are redistributed between routing domains.


The Route Map Command

• Router(config)#route-map map-tag [permit | deny] [sequence-number]

– Note that map-tag is a name that identifies the route map;

– the sequence-number indicates the position that an instance of the route map is to have in relation to other instances of the same route map.

– Instances are ordered sequentially, starting with the number 10 by default.


An Example Route Map

RTA(config)#route-map MYMAP permit 10

RTA(config-route-map)#match ip address 1

RTA(config-route-map)#set metric 5

RTA(config-route-map)#exit

RTA(config)#access-list 1 permit 1.1.1.0 0.0.0.255


Applying a Route Map to BGP

RTA(config)#router bgp 100

RTA(config-router)#neighbor 172.16.20.2 remote-as 300

RTA(config-router)#neighbor 172.16.20.2 route-map MYMAP out


Implementing BGP Routing Policy

Configuring a Simple Route Map

Applying a Route Map to a BGP Neighbor


Controlling BGP Routing with Attributes

• Common BGP Attributes

Next Hop

AS_Path

Atomic Aggregate

Aggregator

Local Preference

Weight

Multiple Exit Discriminator (MED)

Origin


NEXT_HOP Attribute

• The next hop attribute is a well-known mandatory attribute, type code 3.

• For EBGP sessions, the next hop is the IP address of the neighbor that announced the route.

For routes injected into the AS by way of EBGP, the next hop learned from EBGP is carried unaltered into IBGP.

• For IBGP sessions, where routes originated inside the AS the next-hop is the IP address of the neighbor that announced the route.


The Next Hop Attribute


BGP Attributes: Next Hop

Next-hop attribute is different for BGP than it isfor the IGPs that we have already learned about


BGP Attributes: Next Hop Example

• The NEXT_HOP is not necessarily reachable via a direct connection.

– RTA’s next-hop for 128.213.1.0/24 is 1.1.1.1, but reaching it requires a pathway through 3.3.3.3.

• Thus, the next-hop behavior mandates a recursive IP routing table lookup for a router to know where to send the packet.

• To reach the NEXT_HOP 1.1.1.1, RTA will consult its IGP routing table to see if, and how, 1.1.1.1 is reachable. This recursive search continues until the router associates destination 1.1.1.1 with an outgoing interface.


Next Hop and Multiaccess Nets

• Recall that a network link is considered multi-access if more than two hosts can potentially connect to it.

• Routers on a multi-access link share the same IP subnet, and can physically access all other connected routers in one hop.

• Ethernet, Frame Relay, and ATM are examples of multi-access media.


NEXT_HOP Multiaccess

• On a Multiaccess environment such as Ethernet or Frame Relay, the next hop will be the interface connected to the media that originated the route.

• The ‘next-hop-self’ keyword forces the router to advertise itself as the next hop if needed.

next-hop-self is generally used for NBMA networks like Frame Relay.



• BGP speakers always advertise the actual source of the route if the source is on the same multi-access link as the speaker.



Hey, RTA…BGP Route: 11.11.11.0/24

Next Hop is 10.10.10.3 (RTB)

(not me)


Example Explained

• RTA, RTB, and RTC share a common multi-access media.

– RTA and RTC are running EBGP, while RTC and RTB are running OSPF.

– RTC has learned network 11.11.11.0/24 from RTB via OSPF and is advertising it to RTA via EBGP.

– The correct behavior is for RTA to consider RTB (10.10.10.3) as the next hop because RTB shares the same media with RTC.


Next Hop and NBMA

• If the media is broadcast, such as Ethernet and FDDI, physical connectivity is a given and the NEXT_HOP behavior is no problem.

• If the media is non-broadcast, such as Frame Relay and ATM, problems can arise.


Next Hop and NBMA


Next Hop and NBMA

• RTA gets a BGP routing update about 11.11.11.0/24 from RTC and would try to use RTB (10.10.10.3) as the next hop (the same behavior as on multi-access media).

• Routing will fail because no virtual circuit exists between RTA and RTB.


Next Hop and NBMA

• Cisco IOS supports a special case parameter that remedies this situation.

• The ‘next-hop-self’ command forces the router (in this case, RTC) to advertise 11.11.11.0/24 with itself as the next hop (10.10.10.2).

• RTA would then direct its traffic to RTC to reach destination 11.11.11.0/24.


next-hop-self

Router(config-router)#neighbor IP-address next-hop-self

Soooooooo…RTC(config-router)#neighbor 10.10.10.1 next-hop-self


The Atomic Aggregate Attribute


The Aggregator Attribute

• A well-known discretionary attribute, type code 7.

• Enabling ISP administrators to determine which BGP router is responsible for a particular instance of aggregation.

– The AGGREGATOR attribute indicates the local router as the device that has done the aggregating (summarizing).

• “I did the aggregating”

– The ATOMIC_AGGREGATE attributes says who did the aggregating.

• “He did the aggregating”


ATOMIC_AGGREGATE

• The ATOMIC_AGGREGATE is a well-know discretionary attribute (type code 6). The ATOMIC_AGGREGATE attribute is set to either “True” or “False.”


ATOMIC_AGGREGATE

• If true, this attribute alerts BGP routers that multiple destinations have been grouped into a single update.

• In other words, the BGP router that sent the update had a more specific route to the destination, but did not send it.

• ATOMIC_AGGREGATE warns receiving routers that the information they are receiving is not necessarily the most complete route information available.


ATOMIC_AGGREGATE

You can manually configure BGP to summarize routes by using the aggregate-address command, which has the following syntax:

Router(config-router)#aggregate-address address mask [as-set]

[summary-only] [suppress-map map-name][advertise-map map-name] [attribute-map map-name]


ATOMIC_AGGREGATE – Summarization




RTA(config-router)#network 160.10.0.0

RTA(config-router)#aggregate-address 160.0.0.0 255.0.0.0


AGGREGATOR

• AGGREGATOR is a well-known discretionary attribute (type code 7).

• When configuring address aggregation, you can also configure the router to include its router ID and local AS number along with the supernet route.

• This attribute allows ISP administrators to determine which BGP router is responsible for a particular instance of aggregation.

• Tracing a supernet to its original “aggregator” may be necessary for troubleshooting purposes.


LOCAL_PREFERENCE

• Local Preference is a well-known discretionary attribute, type code 5.

• The Local Preference attribute is a degree of preference given to a route for comparison with other routes for the same destination

Higher Local Preference values are preferred.

Local Preference is local to the AS and is exchanged between IBGP peers only.


The Local Preference Attribute

AS 256


Local Preference Configuration

SanJose(config)#route-map SECONDARY_T1 permit 10

SanJose(config-route-map)#set local-preference 200

SanJose(config-route-map)#exit

SanJose(config)#router bgp 256

SanJose(config-router)#neighbor 192.168.1.5 route-map SECONDARY_T1 in

LA(config)#route-map PRIMARY_T3 permit 10

LA(config-route-map)#set local-preference 300

LA(config-route-map)#router bgp 256

LA(config-router)#neighbor 192.168.1.1 route-map PRIMARY_T3 in


Weight Attribute

• The Weight attribute is similar to the Local Preference attribute in that it gives higher preference to the route that has a higher weight.

• The difference is that the weight parameter is local to the router and is not exchanged between routers.

–The weight parameter influences routes coming from different providers to the same router


The Weight Attribute


Multi-Exit-Discriminator

• The Multiple-exit-discriminator (MED) attribute is an optional nontransitive attribute, type code 4.

• MED informs external neighbors about the preferred path into an AS that has multiple entry points.

A lower MED is preferred over a higher MED

• Unlike Local Preference, the MED attribute is exchanged between autonomous systems,


The Multiple Exit Discriminator Attribute


MED Configuration Example

STOP

RTA will only compare the MED from RTC and RTD b/c they are from the same autonomous system.


MED Configuration

RTC(config)#route-map PRIMARY_T1_MED permit 10

RTC(config-route-map)#set Metric 120

RTC(config-route-map)#exit

RTC(config)#router bgp 300

RTC(config-router)#neighbor 192.168.1.5 route-map PRIMARY_T1_MED out

RTD(config)#route-map SECONDARY_T1_MED permit 10

RTD(config-route-map)#set Metric 200

RTD(config-route-map)#exit

RTD(config)#router bgp 300

RTD(config-router)#neighbor 192.168.1.1 route-map SECONDARY_T1_MED out


The Origin Attribute

• IGP – The prefix is internal to the originating AS.

• EGP – The prefix was learned by way of some EGP, such as BGP.

• Incomplete – The prefix was learned by some other means, probably redistribution.

– well-known mandatory attribute (type code 1)


The ORIGIN attribute

• BGP considers the ORIGIN attribute in its decision-making process to establish a preference ranking among multiple routes.

• Specifically, BGP prefers the path with the lowest origin type, where IGP is lower than EGP, and EGP is lower than INCOMPLETE.

• Use the set origin route map command to manipulate the ORIGIN attribute.


Highest WEIGHT Highest LOCAL PREFERENCE LOCALLY ORIGINATED (eg network/aggregate) Shortest AS-PATH Lowest ORIGIN (IGP < EGP < incomplete) Lowest MED EBGP IBGP Lowest IGP METRIC to next-hop

Neighbor with lowest ROUTE_ID

Full story see: www.cisco.com/warp/public/459/25.shtml

Basic Decision AlgorithmBasic Decision Algorithm

Consider only (synchronized) routes with no AS loopsand valid next-hop, then prefer:


BGP Decision Making

1. If the next hop is inaccessible, the route is ignored (this is why it is important to have an IGP route to the next hop).

2. The BGP router will prefer the path with the largest weight (weight is a Cisco proprietary parameter).

3. If the weights are the same, the BGP router will prefer the route with the largest local preference.


BGP Decision Making

4. If the routes have the same local preference, the BGP router will prefer the route that was locally originated (originated by this router).

5. If the local preference is the same, the BGP router will prefer the route with the shortest AS_PATH.

6. If the AS_PATH length is the same, the BGP router will prefer the route with the lowest origin type (where IGP is lower than EGP, and EGP is lower than INCOMPLETE).


BGP Decision Making

7. If the origin type is the same, the BGP router will prefer the route with the lowest MED.

8. If the routes have the same MED, the BGP router will prefer the route in the following manner: External (EBGP) is better than confederation external, which is better than IBGP. If the AS_PATH length is the same, the BGP router will prefer the route with the lowest origin type (where IGP is lower than EGP, and EGP is lower than INCOMPLETE).


BGP Decision Making

9. If all the preceding scenarios are identical, the BGP router will prefer the route that can be reached via the closest IGP neighbor—that is, take the shortest internal path inside the AS to reach the destination (follow the shortest path to the BGP NEXT_HOP).

10. If the internal path is the same, the BGP router ID will be a tie breaker. The BGP router will prefer the route coming from the BGP router with the lowest router ID. The router ID is usually the highest IP address on the router or the loopback address.


The BGP Decision Process


BGP Route Filtering


Using Filters to Implement Routing Policy

• Two steps in manipulating a route:

1. Identify the network number and subnet mask of the route to which the policies are to be applied.

2. Implement the policies, which can be filtering prefixes out altogether or manipulating the attributes of a prefix to influence the routing decision.


BGP Route Filtering

• Route filtering empowers a BGP speaker to choose what routes to exchange with any of its BGP peers.

• Route filtering is the cornerstone of policy routing.

– an AS can identify inbound traffic it is willing to accept by filtering its outbound advertisements

– an AS can control what routes its outbound traffic uses by specifying the routes to accept from EBGP neighbors


BGP Route Filtering

• Even more precise policies can be defined via route filters.

• For example, BGP routes passing through a filter can have their attributes manipulated to affect the best-path decision process.


Using Distribute-list to Filter BGP Routes

The distribute-list command can be used to filter updates so that AS3 does not receive transit traffic to network 192.69.10.0 /24.


BGP Route Filtering

• You can apply route filters to or from a particular neighbor by using the distribute-list command.


BGP Route Filtering




RTA(config-router)#neighbor 172.16.20.1 distribute-list 1 out

RTA(config-router)#exit

RTA(config)#access-list 1 deny 192.69.10.0 0.0.0.255

RTA(config)#access-list 1 permit any


BGP Route Filtering

• The distribute-list keyword, used as part of a BGP neighbor statement, prevents RTA from advertising prefix 192.69.10.0/24 to RTC.

• An access list is used to identify the prefixes to be filtered, and the distribute-list and out keywords apply the filter to outgoing updates.


BGP Route Filtering

• Whereas configuring BGP neighbor statements to include the distribute-list keyword is effective for filtering specific routes, controlling supernets can be a bit trickier.


BGP Route Filtering

• Configuring a distribute list relies on creating an access list.

• If we use a standard access list, we are afforded only limited functionality.


BGP Route Filtering

• What if you want to advertise an aggregate address of 172.16.0.0 /16, but not the individual subnets themselves?

• A standard access list would not work because it permits more than is desired, since it filters based on the network address only.

• For example, this access list would permit not only the 172.16.0.0/16 summary, but also all the components of that summary as well:

(any route that begins with 172.16.x.x)

access-list 1 permit 172.16.0.0 0.0.255.255


BGP Route Filtering

• To restrict the update to the 172.16.0.0/16 summary, you can use an extended access list.

• In the case of a BGP route filter, an extended list matches, first, the network address, and second, the subnet mask of the prefix.

• Both network and mask are paired with their own wildcard bitmask, using the following syntax:

Router(config)#access-list number permit|deny network

network-wildcard mask mask-wildcard

(both the network number and the subnetmask have a wildcard mask)


BGP Route Filtering

• Using this configuration, RTA would not send a subnet route (such as 172.16.0.0 /17 or 172.16.10.0 /24) in an update to AS1.




RTA(config-router)#neighbor 172.16.20.1 distribute-list 101 out

RTA(config-router)#exit

RTA(config)#access-list 101 permit ip 172.16.0.0 0.0.255.255 255.255.0.0 0.0.0.0

• It will only send the 172.16.0.0/16 update


BGP Route Filtering

• If using an extended access list to accomplish this type of filtering seems confusing to you, you are not alone.

• Improved user-friendliness was one of the factors that motivated Cisco to include the ip prefix-list command in IOS 12.0.


BGP Route Filtering

• You can use prefix lists as an alternative to access lists with many BGP route-filtering commands.


BGP Route Filtering

• You must define a prefix list before you can apply it as a route filter. The Cisco IOS allows a very flexible configuration procedure, where each statement can be assigned its own sequence numbers.

• To define a prefix list, use the ip prefix-list command, which has the following syntax:

Router(config)#ip prefix-list list-name [seq seq-value] deny|permit network/len [ge ge-value] [le le-value]


BGP Route Filtering

Parameter Descriptionlist-name Specifies the name of a prefix list.

seq (Optional) Applies the sequence number to the prefix list entry being created or deleted.

seq-value (Optional) Specifies the sequence number for the prefix list entry.

deny Denies access to matching conditions.

permit Permits access for matching conditions.

network/len (Mandatory) The network number and length (in bits) of the network mask.

ge (Optional) Applies ge-value to the range specified.

ge-value (Optional) Specifies the lesser value of a range (the "from" portion of the range description).

le (Optional) Applies le-value to the range specified.

le-value (Optional) Specifies the greater value of a range (the "to" portion of the range description).


BGP Route Filtering

RTA(config)#ip prefix-list ELMO deny 0.0.0.0/0

RTA(config)#ip prefix-list ELMO permit 172.16.0.0/16



RTA(config-router)#neighbor 192.168.1.1 prefix-list ELMO out


BGP Route Filtering

• The real power of the ip prefix-list command is in its optional parameters.

• The keywords ge and le can be used to specify the range of the prefix length to be matched for prefixes that are more specific than the network/len value.

• The prefix-length range is assumed to be from ge-value to 32 if only the ge attribute is specified, and from len to le-value if only the le attribute is specified.


le and ge prefix-list options

• For example with only 192.0.0.0/8 le 24, prefixes from lengths 8 – 24 will be matched

• If we had used only 192.0.0.0/8 ge 25 then prefixes from lengths 25 – 32 will be matched

The /8 is essentially ignored when we use ‘ge’


BGP Route Filtering

• As another example, to accept a mask length of up to 24 bits in routes with the prefix 192.0.0.0/8, and deny more specific routes, use the commands as shown in.

RTA(config)#ip prefix-list GROVER permit 192.0.0.0/8 le 24

RTA(config)#ip prefix-list GROVER deny 192.0.0.0/8 ge 25


BGP Route Filtering

• Also the le and ge keywords can be used together, in the same statement:

RTA(config)#ip prefix-list OSCAR permit 10.0.0.0/8 ge 16 le 24

• This list permits all prefixes in the 10.0.0.0/8 address space that have a mask of between 16 and 24 bits.


BGP Route Filtering

• The prefix list NOSUBNETS denies mask lengths greater than 25 bits in all address space In other words, any prefix with a length greater than 24 bits will be matched and denied.

RTA(config)#ip prefix-list NOSUBNETS deny 0.0.0.0/0 ge 25

• The NO10NET prefix list will match and deny any route in the 10.0.0.0/8 address space.

RTA(config)#ip prefix-list NO10NET deny 10.0.0.0/8 le 32


BGP Route Filtering

• Each prefix list entry is assigned a sequence number, either by default or manually by an administrator.

• By numbering the prefix list statements, new entries can be inserted at any point in the list, which is important because routers test for prefix list matches from lowest sequence number to highest.


BGP Route Filtering

RTA#show ip prefix-list

ip prefix-list ELMO: 3 entries

seq 5 deny 0.0.0.0/0

seq 10 permit 172.16.0.0/16

seq 15 permit 192.168.0.0/16 le 24


The ip prefix-list command


Example ip prefix-list Configuration


Redundancy, Symmetry, and Load Balancing

• Redundancy is achieved by providing multiple alternate paths for the traffic.

This occurs by having multiple connections to one or more autonomous systems.

• Symmetry is achieved when traffic leaving the AS from one exit point comes back through the same point

• Exists if an AS maintains a single connection to outside networks


Redundancy, Symmetry, and Load Balancing


Issues with Redundancy, Symmetry, and Load Balancing

• If an AS has many different links to the outside world, traffic tends to flow asymmetrically.

• An asymmetrical traffic flow can result in increased delay and other routing problems.

In addition, customers and providers like to see their traffic come back the same way that it left the AS.

• To promote symmetry, choose a primary path and configure routing policies that force traffic to flow along this path.

To force traffic to leave the AS by way of a particular path, use LOCAL_PREFERENCE to force traffic to enter the AS by the same path, use MED.


Issues with Redundancy, Symmetry, and Load Balancing


Default Routing in BGP Networks

• To provide redundancy, default information could be received from multiple BGP sources.

• In a BGP system, the Local Preference attribute can be manipulated on the various default routes.

• This is so that one default route is identified as a primary, the highest Local Preference, and others are kept as backups.


Default Routing in BGP Networks


Load Balancing


Load Balancing

• If there are two default routes and one is used as the primary route and one is used as the backup then for outbound traffic, load balancing is not an option.

• However, for inbound traffic the customer can influence the routing decisions made by the ISP by manipulating the metrics advertised to the ISP.

The lowest metric will be preferred (MED configured using a route map).


Multihomed Connections with a Single Provider


Load Balancing to Different Providers

• What if this customer were multihomed to two different providers?

The customer could control inbound traffic the same way, by manipulating advertised metrics using a route map.

As for outbound traffic, the customer either can configure static default routes to the two providers or can dynamically learn a default route from both providers.

For static default routes, the administrative distance can be used to prefer one default route over the other, while one dynamically learned route can be preferred using the Local Preference attribute.


Multihomed Scenarios with a Multiple Provider


BGP Redistribution Overview


Injecting Information Statically into BGP


Injecting Information Statically into BGP

• Information can be injected into BGP dynamically or statically.

• Statically injected routes are constantly maintained by the BGP routing tables, regardless of the status of the networks that they identify.

• A dynamic advertisement will end if the network being advertised no longer exists, a static advertisement will not.


Injecting Information Dynamically into BGP

• Dynamically injected routes come and go from the BGP routing table, depending on the status of the networks that they identify.

• A dynamic advertisement will end if the network being advertised no longer exists in the routing table.

• Dynamically injected information can be further divided into purely dynamic redistribution or semi-dynamic redistribution.


Injecting Information Dynamically into BGP

• For purely dynamic redistribution, all the IGP routes are redistributed into BGP using the ‘redistribute’ command.

• For semi-dynamic redistribution, only certain IGP routes are to be injected into BGP using the BGP network command.


Redistribution Issues

• Mutual redistribution between IGP and BGP can also result in the propagation of flawed routing information.

With mutual redistribution, an EBGP route that was injected from the outside into the AS will be redistributed into the IGP and propagated within the AS.

However, because the IGP is redistributing into BGP the original external route could be sent back into BGP by way of the IGP as if it originated from inside the AS.

• To remedy these situations, special filtering should be put on the border routers to specify what particular networks should be injected from the IGP into BGP.

For protocols that differentiate between internal and external routes, such as OSPF, configure the IGP to ensure that it will redistribute only internal routes into BGP.


BGP Redistribution Configuration Example

For example, a network learned via BGP from AS 100 should show up asexternal to OSPF and should not be redistributed back into BGP from OSPF.


Redistribution Issues

• In the Cisco implementation, external OSPF routes are automatically blocked from being redistributed into BGP.

• Certain protocols may not distinguish between internal and external routes, such as RIP or IGRP.

For these protocols, you should use route filters such as distribute lists and prefix lists.


Scaling BGP

• Autonomous systems consisting of hundreds of BGP routers can pose a serious management problem.

• If that many Internal BGP (IBGP) speakers are configured as a logical full mesh, BGP operation becomes extremely complex.

– Imagine a network where over 100 neighbor statements are required just to define the remote-as of each peer!


Route Reflector (RR)

• recent addition to BGP (IOS 11.1)

• offers an alternative to the logical full-mesh requirement of IBGP.

• acts as a focal point for IBGP sessions.

Multiple BGP routers can peer with a central point (the RR), rather than peer with every other router in a full mesh.

similar to OSPF’s DR/BDR feature

• provides large ISPs with added BGP scalability.



• The use of route reflectors is recommended only for autonomous systems that support a large internal BGP mesh, on the order of more than 100 sessions per router.

– introduces processing overhead on the routers that act as route reflectors

– if configured incorrectly, can cause routing loops and instability.



IBGP routers are typically

fully meshed.



A route reflector can be configured so that IBGP routers don’t have to be in a full mesh to completely exchange routing information.

Route Reflector Server

Route Reflector Client



• RTA receives an update from an external peer and passes it on to RTB, which is configured as a route reflector server with two clients, RTA and RTC.

• RTB will reflect the update from client RTA to client RTC.



• The IBGP peers of a route reflector fall under two categories: clients and nonclients.

• A route reflector and its clients form a cluster.

• All IBGP peers of the route reflector that are not part of the cluster are nonclients and must be fully meshed to all other nonclients and RR servers.

Never configure route reflector clients to peer with IBGP speakers outside their cluster.



• Clients and nonclients don’t even know that route reflection is occurring. To identify clients and clusters, use the neighbor command, which has the following syntax, on the route reflector server:

Router(config-router)#neighbor IP-address route-reflector-client





Configuring a RR server:RTB(config)#router bgp 100

RTB(config-router)#neighbor 1.1.1.1 remote-as 100

RTB(config-router)#neighbor 1.1.1.1 route-reflector-client


RTB(config-router)#neighbor 2.2.2.2 route-reflector-client






Configuring a RR client:





• When the route reflector receives an advertised route, depending on the neighbor, it does the following:

A route from an external BGP speaker is advertised to all clients and nonclient peers.

A route from a nonclient peer is advertised to all clients.

A route from a client is advertised to all clients and nonclient peers. Hence, the clients need not be fully meshed.




Summary

• The details of the practical implementation for BGP as part of the overall design problem in building reliable Internet connectivity was covered.

• Specific attributes of BGP and how the attributes are applied individually and together address this design problem.

• The terminology, attributes, and details of this module are specific to BGP.

• The general concepts and problems raised are pertinent to routing architecture design, regardless of what specific protocols are being utilized.

Date post:	31-Dec-2015
Category:	Documents
Upload:	ralph-alvarez
View:	75 times
Download:	3 times

CCNP 1 v3.0 Module 9 BGP

Documents