CCIE Certification Guide (by Odom) Notes: BGP


  • BGP uses path attributes instead of metric.
  • BGP port 179 – TCP connection.
  • Keepalive – 60 and Hold time – 180, “bgp timers keepalive holdtime” or “neighbor timers” (they do not need to match for neighbor relationship)
  • Router ID: “bgp router-id” à highest IP of loopback à highest IP of another interface
  • Auto-summary is off by default and MD5 is uses only with “neighbor password” command
  • iBGP peers often use loopback interface IP addresses for BGP peering to achieve higher availability. Peering loopbacks makes most sense
  • For IGP, if using loopback, do: neighbor update-source loopback1
  • for eBGP, if IP redundancy exists b/w two eBGP peers, the eBGP neighbor commands should use loopback IP address to take advantage of that redundancy, so that even if the link fails, the TCP connection remains established. If you use eBGP peers loopback, you should use, “neighbor ebgp-multihop” command (set ttl to 2)
  • the initiator of the connection uses a dynamic port number, the receiver (server) uses port 179
  • Tools BGP can use to inject routes:
    • maximum number injected by the NETWORK command in one BGP process is 200.
    • redistribution into BGP does not require any consideration of setting metrics.
    • BGP auto-summary router subcommand causes BGP to summarize only those routes injected due to redistribution on that router. logic differs b/w redistribute and network command. REDISTRIBUTE: do not inject subnets in routing table, inject the classful network.
    • network – for network commands that list a classful network number and no mask parameter, inject the classful network if at least one subnet of that classful network exists in the IP routing table.
    • AGGREGATE-ADDRESS: components (AS SEQ and AS SET). AS SEQ becomes null when ASSEQ of component subnet differs in any way, with as-set the router creates AS_SET segment for the aggregate route if this is the case. “summary-only” suppresses component subnets. “suppress-maps” advertises a subset.
    • aggregate-address summary-only as-set
    • adding default routes to BGP: 3 ways: 1) using “network” command (route to must exist in the routing table), 2) using redistribute, 3) using “neighbor neighbor-id default-information [route-map]” subcommand – doesn’t need to check the route table, it just advertises the default to the specified neighbor.
  • Advertising BGP routes to Neighbors
    • BGP update message has 3 main parts; withdrawn routes, path attributes, prefix and prefix length fields.
    • Choose router with shortest AS path à if aspath is tie, prefer singe eBGP route over one or more iBGP route à if best route not chosen, choose the route with the lowest IGP metric to the NEXT_HOP of the routes. à if the IGP metric ties, choose the iBGP learned route with the lowest BGP RID of advertising router.
    • For a route to be considered, next hop is either (internal routes) or reachable according to the IP routing table.
    • iBGP à neighbor …next-hop-self, for eBGP à neighbor …next-hop-unchangedf
    • Two ways to solve the next-hop problem:
      • make the eBGP neighbor’s IP address reachable by advertising that subnet into IGP
      • Use the next-hop-self option on the neighbor command that points to iBGP peers.
  • Building the IP Routing Table
    • in its simplest form, BGP takes the already identified best BGP routes for each prefix and adds those routes to the IP routing table. Restrictions: AD (for eBGP and iBGP) and BGP synchronization (iBGP routes only).
    • eBGP learned routes should never be prefixes from within an AS (i.e. reason for having AD 20).
    • locally injected routes default to 200.
    • Can change the “distance bgp” or distance BGP subcommand.
    • the route that’s added to the IP routing table contains the exact same prefix, prefix length, and next-hop IP address as listed in the BGP table.
    • Backdoor routes: elegant way of not allowing router to use eBGP route and to use an IGP route instead. “network backdoor” command. “network <dest_network> backdoor”.
    • Requirements for adding route:
      • the route must be the best BGP route
      • The route must be the best route (according to the AD) in comparison with other routing sources.
    • BGP synchronization is off by default. To solve the blackhole problem, older solutions recommended turing BGP synch on and redistributing the routes. But now we have two better options: BGP route reflectors and BGP confederations.
      • Using Sync and Redistributing routes:
        • Key: redistribution solves the blackhole problem and sync solves the problem of advertising a black-hole route to another AS. BGP Synch, “Do not consider an iBGP route in the BGP table as “best” unless the exact prefix was learned via an IGP and is currently in the routing table”
        • RIB-failure is seen means that prefix is known via an IGP.
        • sync does not work if OSPF RID and BGP RID do not match.
      • Disabling Sync and using BGP on all routers.
        • N(N-1)/2 connections required. N routers.
      • Confederations
        • avoid loops by using AS_PATH PA.
        • the add AS_PATH segment called AS_CONFED_SEQ.
        • just like AS_SEQ and AS_SET help prevent loops b/w AS, same way these two help as well within confederation AS.
        • before iBGP route is advertised into another sub-AS, the route must make sure the destination sub-AS is not already in the AS_PATH AS_CONFED_SEQ segment.
        • ASN 64512 through 65535 are private ASNs.
        • TTL is 1 by default and can be changed using “neighbor ebgp-multihop” command.
        • confederation eBGP connections act like iBGP connections in every other regards – e.g. NEXT_HOP is not changed by default.
        • TRUE ASN will be configured on the “bgp confederation identifier” BGP subcommand and not “router bgp”.
        • to identify a neighboring AS as another sub-AS, “bgp confed peers subasn”
      • Route Reflectors
        • RR servers: these servers are allowed to learn iBGP routes from their clients and then advertise them to other iBGP peers.
        • only one router acting as RR uses modified rules; the other routers (clients and non-clients) are not even aware of the RR.
          • receives from client: advertises routes to client and non-client
          • receives from non-client: advertises routes to client.
          • receives from eBGP: advertises routes to clients and non-clients.
        • ONE CASE where RR does not reflect routes is when RR receives a route from a non-client, with RR not reflection that roué to other non-clients.
        • tools in RR to prevent loops:
          • CLUSTER_LIST – RRs add their cluster ID into a BGP PA called CLUSTER_LIST before sending an update. when receiving a BGP update, RRs discard received prefixes for which their cluster ID already appears.
          • ORIGINATOR_ID: PA that tells the first iBGP peer to advertise the route into the AS. If a routes sees it’s own id in received route, it does not use or propagate the route.
          • only advertises the BEST routes.


One thought on “CCIE Certification Guide (by Odom) Notes: BGP

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s