OECG – Chapter 12


We need to talk about how BGP builds its table with routing information. BGP is not all that different from an IGP – you can use “network” statements in the router bgp paragraph, you learn about routes from a neighbor, and you can redistribute routes from another routing protocol. It’s worth mentioning that BGP does not, technically, advertise routes. Rather, it advertises “network layer reachability information” (NLRI), and the path attributes (PAs) associated with that NLRI. The NLRI is the IP prefix with its length, what normal human beings would think of as the route.

So then…let’s discuss the common ways to get prefixes into BGP:

  • The “network” command. Although this is same keyword you see for protocols such as EIGRP and OSPF, the behavior in the context of BGP is rather different. When you put a network command into the BGP paragraph, you’re really telling the router to look in his existing routing table. If he sees a route in his routing table that precisely matches the network command (assuming “no auto-summary”), then create an NLRI and put it in the BGP table. Therefore, connected routes, static routes, IGP routes, etc. that the router may know are candidates to be matched by the BGP network command and an NLRI created. Some points to know about the “network” command:
    • If there’s no mask configured, the classful mask is assumed. (In fact, if you insert a mask, and that mask happens to classfully match that natural class boundary of the network, the router will remove your mask automatically. So, if you are looking at a network statement in your router bgp paragraph thinking to yourself “I could swear that I put in a mask”, then check to see whether your mask was a duplicate of the classful boundary.)
    • If you’re using “no auto-summary”, then the IP route must match exactly both the prefix and prefix length.
    • If you’re using “auto-summary” and listing a classful network, then any existing subnets of that classful network will cause a match.
    • When matching a route, BGP will populate his NEXT_HOP PA with the next hop of the route it matched.
    • The OECG mentions that you can’t go over 200 network statements in your BGP paragraph, but this is an ancient limitation. Your only limit now is the resources of the router.
    • You can use a route-map in your network command for purposes of filtering routes and tweaking PAs.
  • The “redistribute” command allows you to redistribute routes in the way you are largely familiar…but of course there are exceptions:
    • BGP, as you may recall from the last blog post, does not use a metric to determine best path. Rathe, BGP uses a conflagration of steps including AS_PATH to determine best route. That in mind, you don’t concern yourself with setting metrics when redistributing into BGP.
    • On the other hand, you can tweak with PAs via a route-map when you do redistribute. So in that sense, you can still influence BGP’s routing decisions regarding redistributed routes.
    • The “auto-summary” command in your BGP paragraph will force a classful summary route to be created, if any subnet of that classful network exists. Note that this is only true for redistributed routes. If BGP learns routes from other BGP neighbors, the auto-summary command will not affect them.
      • In the context of “redistribute”, auto-summary will cause classful networks to be injected instead of the subnets that may be components of the classful network.
      • In the context of “network”, auto-summary will cause classful networks to be injected if the network statement has no mask (implied classful), and there is a subnet in the routing table that falls in that classful network.
  • The “aggregate-address” command allows routes to be manually summarized for purposes of advertising summarized routes to neighbors.
    • The aggregate-address command is not limited to classful networks.
    • This command does not have to suppress advertising of subnets, but can if configured to do so.
    • The aggregate route must include the AS_PATH PA, like any other NLRI. The AS_PATH PA is made up of the following:
      • AS_SEQ (AS Sequence) – the sequence of ASN’s that the NLRI is advertised through. In the case of a summary route made up of individual subnets that might have come from different ASN’s, its hard to come up with an AS_SEQ. Thus…AS_SET takes care of this.
      • AS_SET – an unordered list of ALL ASNs used by all subnet NLRIs AS_SEQs that make up the summary NLRI.
      • AS_CONFED_SEQ (AS Confederation Sequence)
    • The aggregate-address command follows these guidelines when creating a summary route.
      • The summary will not be created unless there’s an NLRI that falls within the summarized route.
      • If all NLRI’s that fall under the summary fall out of the BGP table, then BGP will tell neighbors that the summary is bad.
      • The NEXT_HOP for summary routes will point locally to
      • The NEXT_HOP for summary routes will point to the “update-source” address for neighbor’s receiving the summary.
      • If all routes being summarized have the same AS_SEQ, the the summary route will have that same AS_SEQ.
      • If AS_SEQ of the routes being summarized are at all different, the summarized route will have a null AS_SEQ.
      • If the as-set option has been configured, the router created an AS_SET for the summarized route, assuming that the summarized route’s AS_SEQ is null.
      • As with any eBGP advertisement, the router will prepend his own ASN to the AS_SEQ before sending the NLRI update.
      • Of the “summary-only” keyword is used, then routes falling within the summary route will be suppressed. If the “summary-only” keyword is not present, then all will be advertised, including the summary route. If the “suppress-map” option is configured, then a subset of routes will be advertised.
  • You can add routes to BGP by injecting a default-route in one of these ways:
    • Using the “network” command. To do this, a route to must be present in the local routing table, via whatever means. In addition, the “network” command must be used. If the network falls out of the local routing table, then the default route is no longer injected into BGP.
    • Using the “redistribute” command, coupled with “default-information originate”. Again, a default route must exist in the routing table. Even a static default to Null0 would suffice. You could then “redistribute static” and have redistributed, assuming that the “default-information originate” was also present.
    • Using the “neighbor <id> default-information” command. This command does NOT presuppose the existence of a local default route, although you can check for one with a route-map if you wish. If there is no local default-route, this command will not install one in the local routing table. However, the neighbor will receive a default route advertisement. Again, you can except this behavior if you wish by using a route-map.
  • Another PA worth mentioning through all of this is the ORIGIN path attribute.
    • BGP will populate the ORIGIN PA based on how the route was injected into the BGP table.
      • IGP, notated as “i” by IOS – will be used when routes have been injected into the BGP table with “network”, “aggregate-address” (sometimes), and “neighbor default-originate” commands.
      • EGP, notated as “e” byIOS – will be used when routes have been injected into the BGP table via EGP, the old Exterior Gateway Protocol, precursor to BGP.
      • Incomplete, notated as “?” by IOS, will be used with “redistribute”, “aggregate-address” (in some cases) and “default-information originate” command.
    • In the context of the “aggregate-address” command above, the router will make the determination of how to populate the ORIGIN PA based on the following:
      • If the as-set option is unused, then IGP.
      • If the as-set option is used and all networks being summarized are ORIGIN “IGP”, then the summary route will be ORIGIN IGP as well.
      • If the as-set option is used and even one of the networks being summarized is ORIGIN “Incomplete”, then the summary route ORIGIN PA will also be “Incomplete”.
By Ethan Banks

Ethan Banks is a podcaster and writer with a BSCS and 20+ years in enterprise IT. He's operated data centers with a special focus on infrastructure — especially networking. He's been a CNE, MCSE, CEH, CCNA, CCNP, CCSP, and CCIE R&S #20655. He's the co-founder of Packet Pushers Interactive, LLC where he creates content for humans in the hot aisle.