1 / 163

CCNP 1 v3.0 Module 9 BGP

CCNP 1 v3.0 Module 9 BGP. 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

ralph-alvarez
Télécharger la présentation

CCNP 1 v3.0 Module 9 BGP

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CCNP 1 v3.0 Module 9BGP Cisco Networking Academy

  2. 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

  3. Overview of Autonomous Systems

  4. Single-homed Autonomous Systems

  5. AS_Path and Private AS Numbers

  6. Multihomed Nontransit Autonomous Systems

  7. Multihomed Transit Autonomous Systems

  8. When Not to Use BGP

  9. BGP Neighbors

  10. 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: • Open Message • Keepalive Message • Notification Message • Update Message

  11. 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.

  12. 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.

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

  14. 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. • Network-Layer Reachability Information (NLRI) • Path Attributes • Withdrawn Routes

  15. BGP Neighbor Negotiation

  16. BGP FSM • Includes six states: • Idle • Connect • Active • OpenSent • Open Confirm • Established

  17. 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.

  18. 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).

  19. 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.

  20. 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.

  21. 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.

  22. 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.

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

  24. 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.

  25. 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.

  26. 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.

  27. 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.

  28. BGP Message Types • Type: The type field can have four values (1-4): • (1) OPEN • (2) UPDATE • (3) NOTIFICATION • (4) KEEPALIVE.

  29. 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.

  30. The BGP Open Message

  31. 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).

  32. The BGP Notification Message

  33. 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.

  34. Path Attributes

  35. 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

  36. 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

  37. 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.

  38. 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.

  39. Basic BGP Configuration

  40. 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.

  41. EBGP and IBGP

  42. EBGP and IBGP Configuration Example

  43. Building Peering Sessions

  44. 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.

  45. 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

  46. 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)

  47. 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)#neighborIP-addressebgp-multihop [hops]

  48. EBGP Multihop and IBGP

  49. AS 200 AS 300 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 2.2.2.0/30 1.1.1.0/30

  50. 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.

More Related