This post represents the solution and explanation for quiz-4.
Have a look at it to understand the problem.

As described in the quiz, you try to establish a BGP external peering between the border routers of two offices. These routers can reach each using the default route that each of them has via the ISP.

The quiz shows that, although the BGP speakers can reach each other, they do not establish an eBGP session.

quiz-4 

Office-1#sh ip cef 2.2.2.2
0.0.0.0/0, version 9, epoch 0, cached adjacency to Serial0/0
0 packets, 0 bytes
  via 155.1.1.2, 0 dependencies, recursive
    next hop 155.1.1.2, Serial0/0 via 155.1.1.0/30
    valid cached adjacency
WARNING

The key to the quiz is that the BGP speaker will not try to establish an EBGP session if/when its peer is reachable over a default route.

[UPDATE] According to the Cisco documentation this is done in order to avoid route flapping and routing loops.

In this situation, debug ip bgp events doesn't show usefull information, but the problem could be easily spotted with debug ip bgp ipv4 unicast: 

Office-1#deb ip bgp event
BGP events debugging is on
Office-1#
*Mar  1 00:12:39.931: BGP: Import timer expired. Walking from 1 to 1
*Mar  1 00:12:54.931: BGP: Import timer expired. Walking from 1 to 1
Office-1#
Office-1#deb ip bgp ipv4 unicast
BGP debugging is on for address family: IPv4 Unicast
Office-1#
*Mar  1 00:31:36.603: BGP: 2.2.2.2 active open failed - no route to peer, open active delayed 31267ms (35000ms max, 28% jitter)
*Mar  1 00:32:07.871: BGP: 2.2.2.2 active open failed - no route to peer, open active delayed 32532ms (35000ms max, 28% jitter)
Office-1#

Let's configure a static route on Office-1 router - soon after that the BGP session goes up: 

Office-1(config)#ip route 2.2.2.2 255.255.255.255 155.1.1.2
Office-1(config)#end
Office-1#
Office-1#
*Mar  1 00:22:34.607: %BGP-5-ADJCHANGE: neighbor 2.2.2.2 Up
Office-1#
Office-1#sh ip bgp s
BGP router identifier 1.1.1.1, local AS number 65100
BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
2.2.2.2         4 65200       4       4        1    0    0 00:00:17        0
Office-1#
Office-1#
Office-1#sh ip bgp nei 2.2.2.2 | inc state|host
  BGP state = Established, up for 00:00:41
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Local host: 1.1.1.1, Local port: 53209
Foreign host: 2.2.2.2, Foreign port: 179
Office-1#
Office-1#sh tcp brief
TCB       Local Address               Foreign Address             (state)
6752A090  1.1.1.1.53209               2.2.2.2.179                 ESTAB
Office-1#

As you can see in both outputs sh ip bgp nei and sh tcp brief, Office-1 router initiates the TCP connection (acts as a client) - local port 53209 - to Office-2 router (2.2.2.2) on port 179 (that will act as a server). Note that I added the static route only on 1.1.1.1 router - 2.2.2.2 router still uses the default route.

Another interesting thing is that the route to the peer can as well be learned via BGP. There were people that replied in the quiz saying that "(quote) the route to the peer must not be default nor learned via BGP (endofqoute)" - the 2nd part is not true ! Here is an output showing that the BGP is established even though the route to the BGP peer is learned via another BGP session: 

Office-2#sh ip bgp sum
...
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
1.1.1.1         4 65100      10      10        2    0    0 00:05:50        0
155.2.2.2       4   100      11      11        2    0    0 00:07:00        1
Office-2#
Office-2#sh ip route 1.1.1.1
Routing entry for 1.1.1.1/32
  Known via "bgp 65200", distance 20, metric 0
...
Office-2#
Office-2#sh tcp br
TCB       Local Address               Foreign Address             (state)
650B7CB8  2.2.2.2.55415               1.1.1.1.179                 ESTAB

In this output, Office-2 router has an eBGP peering with the ISP and learns the IP of Office-1 (1.1.1.1) via this peering - which is enough to start a TCP connection to Office-1.


Conclusion:
  • a BGP speaker will not initiate the TCP session to establish a BGP peering if the peer is reachable only over a default route.
    You'll need a more specific route than default - it can br learned statically or dynamically (including via another BGP session - it's still ok)
  • a BGP speaker will accept/respond to a TCP session and will establish a BGP peering even if the peer is reachable over a default route. Thus, the non-default route is only needed on one side, but it's always recommended to exist on both sides
  • once established, the BGP peering will not be broken if the more specific route is lost and connectivity remains over the default route

Thanks everyone for your comments in the quiz !