Preparing for a networking interview? Here are 10 advanced BGP interview questions and answers, with the CLI commands and sample outputs you should know. Each answer is short, practical and easy to explain in an interview.
- BGP timers, and why is the Hold timer high?
- update-source vs next-hop-self
- BGP session stuck in "Active" state
- Route in BGP table but not in routing table
- Why use a loopback for BGP peering?
- eBGP neighbors using loopbacks: extra configuration
- How does eBGP prevent routing loops?
- Soft reset vs hard reset
- BGP best path selection order
- Why is iBGP full mesh needed, and how do route reflectors help?
Question 1: What are the BGP timers, and why is the BGP Hold timer high compared to other routing protocols?
Default BGP timers:
- Keepalive: 60 seconds
- Hold timer: 180 seconds
Even if a router receives no message from its neighbor for up to 3 minutes, the BGP session stays up. Unlike IGPs such as OSPF or EIGRP, BGP does not react quickly to small network changes.
Why is it so high?
- BGP is designed for stability, not speed. It is a deliberately "slow" protocol.
- BGP is the protocol of the Internet. It connects thousands of ISPs, enterprises and data centers, whereas OSPF and EIGRP operate inside a single organization (intra-AS).
- BGP exchanges millions of routes and carries critical Internet traffic, so any instability has global consequences.
- A long Hold timer prevents sessions from flapping on short link blips, which avoids constant route withdrawals and re-advertisements.
R1(config-router)# neighbor 2.2.2.2 timers 10 30 ! keepalive 10s, hold 30s (the lower value of the two peers is negotiated)
Question 2: What is the difference between update-source and next-hop-self in BGP?
update-source controls the source IP of the BGP session. It makes the peer use a loopback instead of the physical interface.
neighbor x.x.x.x update-source Loopback0
next-hop-self changes the NEXT_HOP attribute of the routes you advertise to your own IP.
neighbor x.x.x.x next-hop-self
Default next-hop behavior in BGP:
- Advertising a route to an eBGP neighbor: the next hop becomes the router itself.
- Advertising a route to an iBGP neighbor: the next hop is not changed.
Question 3: A BGP session is stuck in the "Active" state. What could be the issue?
"Active" means the router is actively trying to open a TCP connection to the neighbor, but it is not succeeding.
R1# show ip bgp summary BGP router identifier 1.1.1.1, local AS number 65001 BGP table version is 3, main routing table version 3 Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 2.2.2.2 4 65002 0 0 0 0 0 00:01:34 Active
1) Neighbor reachability issue
Check connectivity to the neighbor with ping <neighbor IP>.
R1# ping 2.2.2.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds: ..... Success rate is 0 percent (0/5)
2) BGP peer not configured correctly
Wrong neighbor IP or wrong remote-as. Verify with show running-config | section bgp. In the example below, R1 is configured with neighbor 3.3.3.3, but the real peer is 2.2.2.2.
R1# show running-config | section bgp router bgp 65001 bgp log-neighbor-changes neighbor 3.3.3.3 remote-as 65002
3) Incorrect update-source interface
The peer expects the session from a specific address, but R1 sources it from a different interface. Here R1 uses Loopback1 while the peer is configured for Loopback0.
R1# show running-config | section bgp router bgp 65001 bgp log-neighbor-changes neighbor 2.2.2.2 remote-as 65002 neighbor 2.2.2.2 update-source Loopback1
Fix: neighbor <IP> update-source Loopback0
4) Firewall or ACL blocking TCP 179
BGP runs over TCP port 179. Check with show access-lists and debug ip tcp transactions.
R1# show access-lists
Extended IP access list BLOCK_BGP
10 deny tcp host 1.1.1.1 host 2.2.2.2 eq bgp
20 permit ip any any
R1# debug ip tcp transactions
*Jul 19 10:11:32.223: TCP: sending SYN to 2.2.2.2 port 179
*Jul 19 10:11:34.227: TCP: SYN retry timeout
*Jul 19 10:11:36.231: TCP: SYN retry timeout
*Jul 19 10:11:38.235: TCP: SYN retry timeout
ebgp-multihop (see Question 6), and MD5 password mismatches can also keep a session from establishing.
Question 4: You are receiving a BGP route in the BGP table, but it is not installed in the routing table. Why?
- The BGP table holds the valid BGP routes.
- The RIB (routing table) installs only the best route from all protocols (OSPF, BGP, static, etc.).
1) Administrative Distance (AD) preference
- eBGP AD = 20, iBGP AD = 200
- If another protocol has the same prefix with a lower AD (for example OSPF at 110, or a static route at 1), that route wins and the BGP route is not installed.
Check with show ip route <prefix>. In the output below, the prefix 100.1.1.1/32 is learned from BGP (marked with * only, not *>), but OSPF owns the routing table entry.
R1# show ip bgp
Network Next Hop Metric LocPrf Weight Path
*>i 192.168.20.0 2.2.2.2 0 100 0 65002 i
* 100.1.1.1/32 2.2.2.2 0 100 0 65002 i
R1# show ip route 100.1.1.1
Routing entry for 100.1.1.1/32
Known via "ospf 1", distance 110, metric 20, type intra area
Last update from 10.0.0.2 on GigabitEthernet0/1, 00:01:12 ago
Routing Descriptor Blocks:
* 10.0.0.2, from 10.0.0.2, via GigabitEthernet0/1
Route metric is 20, traffic share count is 1
Tip: * only means the route was received by BGP but not selected as best. *> means it is the best path and is a candidate for the RIB.
2) Next-hop unreachable
BGP will not install a route if its next hop is not reachable.
show ip bgp <prefix> ! shows the next hop
show ip route <next-hop> ! is the next hop reachable?
R1# show ip bgp
Network Next Hop Metric LocPrf Weight Path
* 100.1.1.1/32 192.168.100.2 0 100 0 65002 i
R1# show ip route 192.168.100.2
% Network not in table
Fix: make sure the next hop is known via an IGP or a static route.
3) iBGP route without next-hop-self
Between iBGP peers the next hop is not modified. If the original eBGP next hop (a link outside your AS) is not in your IGP, downstream routers cannot reach it.
Fix: use neighbor x.x.x.x next-hop-self on the sending iBGP router.
4) Prefix affected by a policy or route-map
A route-map, prefix-list or filter in the BGP path can leave a prefix in the BGP table without it being used. Check with show run | section route-map and show ip bgp <prefix>.
R1# show ip bgp 100.1.1.1/32
BGP routing table entry for 100.1.1.1/32
Paths: (1 available, best #1, not installed in IP routing table)
Not advertised to any peer
65002
2.2.2.2 (metric 0) from 2.2.2.2 (2.2.2.2)
Origin IGP, metric 0, localpref 100, valid, internal
rx pathid: 0, tx pathid: 0
R1# show ip route 100.1.1.1
% Network not in table
R1# show run | section route-map
route-map FILTER-BLOCK deny 10
match ip address prefix-list DENY-PFX
route-map FILTER-BLOCK permit 20
!
ip prefix-list DENY-PFX seq 5 deny 100.1.1.1/32
ip prefix-list DENY-PFX seq 10 permit 0.0.0.0/0 le 32
The key line is "best #1, not installed in IP routing table". That tells you the route won best-path selection inside BGP but was rejected when handed to the RIB.
Question 5: Why is a loopback interface preferred over physical interfaces when configuring a BGP neighbor?
- Stability: a loopback never goes down unless it is manually shut. If a physical link fails, a session bound to that interface drops.
- Redundancy: if one link fails, the loopbacks stay reachable over an alternate path, so the BGP session survives. This requires the IGP (or static routes) to provide reachability to the peer's loopback.
- Load balancing / ECMP: with multiple equal-cost IGP paths to the loopback, traffic towards it can be load-balanced. A session tied to one physical interface cannot do this.
- Fewer sessions, simpler configuration: one session per router pair instead of one per link.
- Easier identification and troubleshooting: the router is always known by one predictable address.
neighbor 4.4.4.4 remote-as 100 neighbor 4.4.4.4 update-source Loopback0
Question 6: In the scenario below, if the eBGP neighbors are configured using loopback interfaces, what additional configuration is required?
Scenario: R1 (AS 100, Loopback 1.1.1.1) is connected to R2 (AS 200, Loopback 2.2.2.2) over a WAN link (R1 s0: 12.1.1.1/24, plus a second link s1: 21.1.1.1/24).
R1 neighbor 2.2.2.2 remote-as 200 neighbor 2.2.2.2 update-source Loopback0 R2 neighbor 1.1.1.1 remote-as 100 neighbor 1.1.1.1 update-source Loopback0
Answer: ebgp-multihop
- eBGP neighbors are expected to be directly connected (same subnet).
- Loopbacks are in different subnets and are not directly connected to each other.
- By default, eBGP packets are sent with TTL = 1, so they die after one hop and never reach the loopback.
- Increase the TTL with the
ebgp-multihopcommand (range 1 to 255, default 1). For loopbacks, use 2 or more.
R1(config-router)# neighbor 2.2.2.2 ebgp-multihop 2 R2(config-router)# neighbor 1.1.1.1 ebgp-multihop 2
R1(config)# ip route 2.2.2.2 255.255.255.255 12.1.1.2 R2(config)# ip route 1.1.1.1 255.255.255.255 12.1.1.1
Question 7: How does eBGP prevent routing loops?
eBGP prevents loops primarily using the AS_PATH attribute.
- Every time a route passes through an Autonomous System, that AS number is prepended to the AS_PATH.
- If a BGP router sees its own AS number in the AS_PATH of a received route, it rejects the route.
R1# debug ip bgp BGP: 10.0.0.0/8 received via eBGP from 192.0.2.2 BGP: AS_PATH = 65003 65002 65001 BGP: route ignored due to AS path loop, local AS 65001 in path
Bonus: inside an AS, iBGP uses a different rule, iBGP split horizon: a route learned from one iBGP peer is not advertised to another iBGP peer (see Question 10).
Question 8: What is the difference between a soft reset and a hard reset in BGP?
| Hard reset | Soft reset | |
|---|---|---|
| What it does | Tears down the BGP session and rebuilds it from scratch | Re-sends BGP updates without tearing down the session |
| Command | clear ip bgp [neighbor] |
clear ip bgp [neighbor] soft inclear ip bgp [neighbor] soft out |
| Impact | Session drops, routes are withdrawn and re-advertised, so there is a temporary disruption | No session disruption; routes are refreshed in place |
| Use case | Session problems (stuck session), or you want to fully rebuild it | Applying new route-maps, filters or policies and reprocessing routes |
- Soft in: asks the neighbor to resend (or re-evaluates stored) received updates so inbound policy is reapplied.
- Soft out: resends your local BGP updates to the neighbor so outbound policy is reapplied.
Note: inbound soft reset works through the BGP route refresh capability, which modern IOS supports by default. Older setups relied on neighbor x.x.x.x soft-reconfiguration inbound, which stores an extra copy of received routes in memory.
Question 9: What is the BGP best path selection order?
When BGP has multiple paths to the same prefix, it picks one best path by comparing attributes in this order (Cisco IOS). It stops at the first step where a path wins:
- Weight: highest wins (Cisco-proprietary, local to the router)
- Local Preference: highest wins (default 100, shared across the AS)
- Locally originated: prefer routes originated by this router (network, aggregate, redistribute)
- AS_PATH length: shortest wins
- Origin code: IGP (i) over EGP (e) over incomplete (?)
- MED (metric): lowest wins (compared between paths from the same neighboring AS by default)
- eBGP over iBGP
- Lowest IGP metric to the BGP next hop
- Oldest eBGP path (for stability)
- Lowest router ID
- Lowest neighbor IP address
R1# show ip bgp 10.10.10.0/24 ! look for the "best" flag and compare weight, localpref, AS path, origin, metric
Question 10: Why is an iBGP full mesh required, and how do route reflectors solve it?
The problem: iBGP split horizon
- Inside an AS, the AS_PATH does not change between iBGP peers, so it cannot be used to detect loops.
- Instead, a router will not advertise a route learned from one iBGP peer to another iBGP peer.
- So every iBGP router must peer directly with every other iBGP router: a full mesh of
n(n-1)/2sessions. With 10 routers that is 45 sessions, and with 100 routers it is 4,950.
The solution: Route Reflector (RR)
- An RR is allowed to re-advertise iBGP-learned routes to its iBGP clients.
- Clients peer only with the RR, not with each other, which cuts the session count dramatically.
- Loops are prevented with the ORIGINATOR_ID and CLUSTER_LIST attributes.
! On the Route Reflector router bgp 65001 neighbor 10.0.0.2 remote-as 65001 neighbor 10.0.0.2 update-source Loopback0 neighbor 10.0.0.2 route-reflector-client neighbor 10.0.0.3 remote-as 65001 neighbor 10.0.0.3 update-source Loopback0 neighbor 10.0.0.3 route-reflector-client
Other option: BGP confederations split a large AS into smaller sub-ASes to reduce the full-mesh requirement.
Found this useful? Share it with someone preparing for a networking interview, and subscribe to Network Engineer Stuff for more interview questions.
Write to us: networkengineerstuff@gmail.com | WhatsApp: +91-8828002605
Best of Luck!
