12.14 Basic BGP Configuration

CCNP RS 300-101, Implementing BGP, Uncategorized

Some notes.

  • By default in IBGP, the routing table for an internal BGP route will show the originating IP address as the next hop, no matter how many hops away they are. This never changes within the AS.
  • By default in EBGP, the routing table always shows the next hop towards a prefix as the next-hop IP address for the adjacent AS. That IP is considered the “entry point” into that AS.
  • The AD of 200 for IBGP routes is a mechanism to prevent black-holing routes on devices that are not participating in BGP.
  • The following route 209.165.200.224/27 does not have a > sign because it does not have a route to the next hop. It is therefore not entered into the routing table.
  • When an EBGP speaker sends a prefix to an IBGP speaker, it does not change the next-hop:
  • Default next-hop behavior is as follows.
    • EBGP: the IP address of the neighbor router that is sending the update
    • IBGP: the IP address advertised by the EBGP neighbor, propagated throughout the local ASN.
  • The next-hop-self command overrides the default IBGP forwarding behavior, replacing the IP address with its own to ensure the IBGP peer has a route back. It is configured as follows.
next-hop-self
  • These are the states for BGP session establishment:
    • Idle – Routing table is being searched to check the neighbor reachability
    • Connect – Route to the neighbor is found, 3-way handshake completed
    • Open sent – Open message is sent, with parameters for BGP session
    • Active – No response to open message is received from configured peer
    • Open confirm – Session parameter negotiation completed
    • Established – Peering is established, updates may take place
  • The most common reasons for a speaker to be in idle state is that it cannot reach the neighbor’s peer IP address, an address was misconfigured, or the remote AS is misconfigured.
  • If a response to Open sent is not received in 5 seconds, it transitions to Active
  • Use debug ip bgp ipv4 unicast for troubleshooting
  • When peering IBGP, preferably use a loopback address for resiliency. Ensure the IGP provides a route to the address.
  • BGP does not accept unsolicited updates. It must be aware of every neighboring router, including a neighbor statement for it to accept the packet. This means that sourcing IBGP from a loopback address requires the configuration of the neighbor update-source command, to tell the router to send the packet with the logical interface as its source, rather than its interface. If not configured, two routers with loopback interfaces sources may not peer with each other and remain in idle state.
  • The same resiliency can be provided with EBGP, but here you must use static routes to provide reachability to the loopback.
  • Use ebgp-multihop <ttl> to modify the TTL and allow EBGP to peer with addresses that are not directly connected. This is typically required when peering with loopbacks or in redundant circuit connectivity scenarios. (When not configured, the default is 1 hop; when configured without specification for TTL, the default is the maximum of 255 hops.)
  • To reset a BGP connection in a disruptive manner, issue the clear ip bgp * command. This causes the session to terminate and forces rebuild, which can take some time.
  • To reset a BGP connection using a soft reset (non-disruptive), issue the clear ip bgp <neighbor ID> out command. This creates a new UPDATE message and includes withdrawal provisions for deleted prefixes.
  • To reset a BGP connection using route-refresh capabilities (non-disruptive), issue the clear ip bgp <neighbor ID> in command. This triggers the neighbor to resend its BGP table without clearing the session.
Published