BGP Peering Sessions and Default Routes

• It may be tempting to simply configure a static default route to enable the iBGP peering session. However, such an approach can lead to unexpected behavior.
• If the sole route providing reachability to a BGP peering address is a default route, the BGP peering session won't be established. Cisco IOS does not consider reachability to the neighbor's peering address over a default route as reliable. Cisco's documentation states the following:
  • When BGP peers are configured to reach each other with default routes, the BGP neighborship does not appear. This is done to avoid route flapping and routing loops.
  • This choice is made for a logical reason. A default route is a "catch-all" route that instructs, "if you don't have a specific route, send it to this router or out this interface." There's no guarantee that the receiving device on the other end has a route to the destination itself. More concerning is when the receiving device has a route to the destination that leads back to the original forwarding router, directly or indirectly, creating a loop. These are the risks associated with relying on default routes within an organization.
• The only way a specific, non-default route can enter the routing table is through routing protocols, static route configuration, or when the route is directly connected to a router interface. All of these sources are considerably more reliable. Routing protocols are designed to be highly loop-resistant. With static route configuration, it's assumed that the administrator knows the route is valid, and the receiving router can handle the traffic without forming a loop. Directly connected routes are inherently reliable because they connect directly to the router.