Question 1

Why does the loop occur, and what BGP feature prevents it?

Accepted Answer

The loop occurs because when the ISP A link flaps, the enterprise router withdraws those routes from its RIB but may still have them in BGP due to slow convergence. If the router falls back to the default route from ISP B and forwards the packet back out toward ISP A (which has now recovered partially), a routing loop forms. The fix is **BGP Graceful Restart** on the ISP side and, more importantly, **BGP Prefix Independent Convergence (PIC)** or simply ensuring that the router does not advertise a default route back to an eBGP peer. At the enterprise edge, I would implement **BGP conditional advertisement** — only advertise the default route to internal peers if the full table from ISP A is present. I would also tune the BGP hold timer and keepalive for faster failure detection: `timers bgp 3 9`. For the interview, the key phrase is: "I ensure the AS_PATH prevents loops via eBGP split-horizon, and I use `bgp dampening` to suppress flapping prefixes so they do not churn the routing table."

Question 2

How do you detect and prevent this route leak using BGP communities and prefix limits?

Accepted Answer

This is a classic **route leak** caused by a more-specific prefix hijacking traffic within the same AS. First, I detect it by monitoring BGP updates with `show ip bgp` and comparing the AS_PATH. Since both prefixes originate from the same ASN, the leak is internal. To prevent it, I use **BGP Maximum Prefix Limits** on every eBGP and iBGP peer: `neighbor x.x.x.x maximum-prefix 100000`. I also implement **BGP Prefix-List filtering** at every datacenter edge so that only aggregate prefixes (/16, /15) are advertised between regions, and more-specifics (/24s) are filtered. The production-standard fix is **BGP Communities** — I tag all regional aggregates with a community like `65000:100` (London) and `65000:200` (Mumbai). At each border, I apply an inbound route-map that rejects any prefix with a foreign community unless it is an approved aggregate. This way, a /24 originating in Mumbai with `65000:200` is dropped at the London ingress because London only accepts `65000:100` or the global aggregate community.

Question 3

What are the three valid BGP techniques to influence outbound traffic, and which one do you use here?

Accepted Answer

The three valid techniques are: (1) **Local Preference** — influences outbound traffic within the AS by preferring one path over another; (2) **AS_PATH Prepending** — influences inbound traffic from other ASes by making one path look longer; (3) **MED (Multi-Exit Discriminator)** — influences inbound traffic when two paths enter from the same neighboring AS. For this scenario, I use **Local Preference** because I am influencing outbound traffic from my AS. I create a prefix-list matching 8.8.8.0/24, then a route-map that sets local-preference to 200 for that prefix when received from ISP A. For all other prefixes, I leave local-preference at 100 (default) so they load-balance. The route-map is applied inbound on the ISP A peering session. I would never use MED here because MED only works when both paths come from the SAME neighboring AS, and we have two different ISPs. I also mention that for true load-balancing of "all other traffic," both paths must have equal Local Preference, equal AS_PATH length, and the router must support `maximum-paths ebgp 2`.

Question 4

How does AS_PATH length affect BGP path selection, and what policy should AS 65001 implement to protect itself from artificially long AS_PATHs?

Accepted Answer

AS_PATH length is the fourth tiebreaker in the BGP best-path selection algorithm (after Weight, Local Preference, and locally originated). A shorter AS_PATH is preferred. However, AS 65002's peer is gaming the system by prepending AS 65002 repeatedly to de-preference its backup path. This artificially inflates AS_PATH length and can cause suboptimal routing in AS 65001. To protect itself, AS 65001 should implement an inbound route-map that rejects or depreferences any prefix with an AS_PATH exceeding a reasonable length, such as `ip as-path access-list 10 deny ^65002(_65002){4,}$` which blocks paths with five or more consecutive instances of AS 65002. More elegantly, AS 65001 can strip excessive AS_PATH prepends using a route-map with `set as-path replace 65002 65002 65002 65002 65002 65002` but this is risky and violates BGP trust boundaries. The best practice is to simply filter the route if the AS_PATH length exceeds a threshold or to use RPKI/ROV (Route Origin Validation) to ensure the originating AS is legitimate regardless of path length.

Question 5

What are the three most common MPLS BGP misconfigurations that break intra-VRF communication?

Accepted Answer

First, **missing or mismatched Route Distinguishers (RDs)** or Route Targets (RTs). The PE must import and export the correct RT for the VRF. If Site A exports RT 100:1 and Site B imports RT 100:2, the routes never enter Site B's VRF table. I verify with `show ip vrf detail` and `show ip bgp vpnv4 all`. Second, **missing MPLS label distribution** between PEs. Even if BGP carries the VPNv4 prefix, the P routers in the core must have LDP or RSVP-TE running to swap labels. If LDP is down, the packet arrives at the egress PE without a VPN label and is dropped. I check with `show mpls ldp neighbor` and `show mpls forwarding-table`. Third, **BGP address-family misconfiguration** on the PE. The CE-PE session might be IPv4 unicast only, but the provider needs the prefix in the VPNv4 address family. If the PE only has `address-family ipv4` and not `address-family vpnv4`, the route is never propagated across the MPLS core. I verify with `show ip bgp vpnv4 vrf CUSTOMER` and `show bgp vpnv4 unicast summary`.

Question 6

How do you achieve this using BGP communities without changing the actual AS_PATH?

Accepted Answer

You cannot change the AS_PATH without violating BGP semantics, but you can influence path selection before AS_PATH is evaluated. The trick is to use **Local Preference** as a community-triggered policy. The provider defines a community for Premium customers, e.g., `65000:PREM`. When the provider's edge router receives a full Internet route from upstream, it applies two outbound route-maps: one for Premium peers that sets local-preference to 300, and one for Standard peers that leaves local-preference at 100. Since Local Preference (step 2) is evaluated before AS_PATH length (step 4), Premium customers always prefer the provider's path regardless of AS_PATH. Alternatively, if the provider wants to send DIFFERENT routes to Premium vs Standard, they can use **BGP Conditional Advertisement** or **ORF (Outbound Route Filtering)**. But for the interview, the community-driven Local Preference answer is the most elegant and scalable. I would also mention that some providers use **BGP Large Communities** (RFC 8092) for this because standard communities only support 2-byte ASNs, and many modern providers have 4-byte ASNs.

Question 7

What BGP timer or feature reduces this convergence time from minutes to seconds in a Clos fabric?

Accepted Answer

In a BGP-based data center fabric (RFC 7938), the default BGP timers (60/180) are far too slow. The fix is **BGP Fast Peering Session Deactivation** combined with aggressive timers and **BFD (Bidirectional Forwarding Detection)**. I configure `timers bgp 3 9` on all leaf-spine sessions so failure detection happens in 9 seconds instead of 180. Then I enable BFD with `bfd interval 300 min_rx 300 multiplier 3` which detects link failure in 900ms. On top of that, I use **BGP Additional Paths** so that when one spine fails, the leaf already has pre-computed backup paths and does not need to wait for BGP best-path recalculation. I also enable **BGP Prefix Independent Convergence (PIC)** at the edge, which allows forwarding to continue using an alternate path immediately without waiting for the RIB/FIB to be fully updated. For a Clos fabric specifically, the interview answer should mention that iBGP is avoided in favor of eBGP because eBGP does not require a full mesh or route reflectors, and each leaf only needs one session per spine.

Question 8

Which BGP attribute do you manipulate, and how do you measure the latency to make the decision?

Accepted Answer

The attribute to manipulate is **MED (Multi-Exit Discriminator)**, but MED only works when both paths originate from the SAME neighboring AS. Since we have two different ISPs, MED is ineffective. Instead, I manipulate the **AS_PATH by prepending** my own AS multiple times on the undesirable ISP so that the Internet prefers the shorter path — but the question explicitly says the shorter AS_PATH is NOT the lower latency path. Therefore, the correct answer is to use **BGP communities** to request that one ISP does not advertise the prefix globally (using a no-export community), or to use **BGP Flowspec** or **Performance-Based Routing (PBR)** at the edge. However, the standard BGP answer is: you cannot directly encode latency into BGP. Instead, you use **IP SLA** or **BFD** to measure latency to each ISP's next hop, and then use an EEM (Embedded Event Manager) script or a route-map with `set as-path prepend` that dynamically adjusts based on the IP SLA result. A more modern answer is **BGP Link-State (BGP-LS)** or **SR Traffic Engineering** with latency constraints, but for a standard interview, the best answer is: "I use IP SLA to monitor latency, and I apply conditional AS_PATH prepending via a route-map so that the low-latency ISP is always preferred by the global Internet."

Question 9

What three BGP scaling techniques reduce the impact of peer flaps on router CPU?

Accepted Answer

First, **BGP Update Group Optimization** — Cisco routers automatically group peers with identical outbound policies into update groups so a single update copy is sent to multiple peers. I verify with `show ip bgp update-group` and ensure all peers sharing a policy use the same route-map. Second, **BGP Route Refresh** instead of hard resets. If I must clear a peer, I use `clear ip bgp * soft out` rather than a hard reset, which avoids withdrawing and re-advertising every prefix. Third, **BGP Prefix Limit and Dampening**. I configure `neighbor x.x.x.x maximum-prefix 950000 90` to warn at 90% and `bgp dampening` to suppress flapping prefixes so they do not trigger repeated best-path calculations. A fourth technique I mention for bonus points is **BGP Peer Groups** or **Peer Templates** which reduce configuration overhead and allow the router to process updates more efficiently. For very large scale, **BGP Read-Only Mode** during maintenance windows or **BGP LLGR (Long-Lived Graceful Restart)** for planned restarts prevents the peer from withdrawing routes temporarily.

Question 10

What is the most common route-reflector misconfiguration in MPLS VPN environments, and what is the fix?

Accepted Answer

The most common misconfiguration is that the route-reflector does not have the VPNv4 address family activated, or it reflects routes without modifying the next-hop. In standard iBGP, the next-hop is preserved across iBGP peers. If the route-reflector receives a VPNv4 prefix from PE1 with a next-hop of PE1's loopback, and reflects it to PE2, PE2 must have reachability to PE1's loopback via the MPLS core. If the route-reflector is not in the data path and does not run MPLS, PE2 may try to resolve the next-hop directly through the route-reflector, which fails. The fix is to ensure the route-reflector is either: (1) also an MPLS-enabled PE in the forwarding path, or (2) configured with `neighbor x.x.x.x next-hop-self all` in the VPNv4 address family so that the route-reflector rewrites the next-hop to itself. However, `next-hop-self` on a route-reflector is generally discouraged because it forces traffic through the RR. The better fix is to ensure all PEs have labeled reachability to each other via LDP or SR, and the RR simply reflects without next-hop modification. I verify with `show ip bgp vpnv4 all` and `show mpls forwarding-table`.

Question 11

What BGP policy do you implement to protect the enterprise router while maintaining connectivity to all cloud services?

Accepted Answer

I implement **BGP Aggregate Address** generation locally on the enterprise router, combined with an inbound prefix-list that only accepts aggregates (/16 or shorter) from the cloud provider. First, I politely open a support case with the cloud provider to request aggregate advertisements — AWS supports this via BGP communities. Second, on my router, I create an inbound route-map: `ip prefix-list CLOUD_AGGREGATES permit 0.0.0.0/0 le 16` and apply it to the Direct Connect BGP peer. This silently drops all /24s and only accepts the aggregates. If the cloud provider does not offer aggregates, I generate my own local aggregates using `aggregate-address 172.31.0.0 255.255.0.0 summary-only` after filtering the specific routes. I also configure `bgp maxas-limit 50` to drop any path with an unrealistically long AS_PATH, which is common in cloud BGP hijacking scenarios. Finally, I enable `soft-reconfiguration inbound` so I can inspect the received routes without tearing down the session.

Question 12

What BGP community-based blackholing technique achieves this, and how do you ensure you do not accidentally blackhole your own management traffic?

Accepted Answer

The standard technique is **Remotely Triggered Black Hole (RTBH)** filtering using BGP communities. I advertise the victim /32 with a specific community that the upstream ISPs recognize as "blackhole this prefix." The most common community is `65535:666` (well-known discard community per RFC 7999) or the ISP's custom blackhole community like `ISP_AS:999`. On my edge router, I create a static route to the victim /32 pointing to Null0: `ip route 192.0.2.100 255.255.255.255 Null0 tag 666`. Then I redistribute this static route into BGP with a route-map that attaches the blackhole community. To protect management traffic, I apply an **ACL on the management interface** (out-of-band or dedicated VRF) that permits traffic to my management IPs regardless of routing. I also use **uRPF (Unicast Reverse Path Forwarding)** in loose mode on edge interfaces so that blackholed traffic is dropped at the provider edge without reaching my network. Critically, I never advertise a default route or my management prefix with the blackhole community — I maintain a strict prefix-list that only allows specific victim IPs to be tagged.

Question 13

What is the key difference in how BGP treats confederation eBGP versus regular eBGP, and what configuration fixes this?

Accepted Answer

In BGP confederations, peers within different sub-ASes are treated as **confederation eBGP** peers. The critical difference is that confederation eBGP preserves the NEXT_HOP, LOCAL_PREF, and MED attributes — unlike regular eBGP, which rewrites the next-hop to itself and strips Local Preference. If Sub-AS 65001 receives an external route and passes it to the confederation backbone, the backbone reflects it to Sub-AS 65002. However, if the next-hop is the external peer's IP and Sub-AS 65002 does not have a route to that next-hop, the route is hidden in the BGP table (not installed in the RIB). The fix is to configure `next-hop-self` on the confederation eBGP peer sessions, or to ensure the confederation backbone redistributes the external peer's subnet into the IGP so all sub-ASes can resolve the next-hop. I verify with `show ip bgp` looking for `h` (history) or `r` (RIB-failure) flags. I also check that the confederation AS is correctly configured with `bgp confederation identifier 65000` and `bgp confederation peers 65002` on every router in Sub-AS 65001.

Question 14

How do you advertise both the aggregate and the more-specifics without causing routing instability or being filtered by the ISP's maximum prefix limits?

Accepted Answer

This is a classic **traffic engineering with BGP aggregation** scenario. I advertise the /20 aggregate from all upstream points to ensure baseline reachability. Then I advertise the specific /24s from the ISP where I want that traffic to enter. For example, /24 A is advertised from ISP A, and /24 B is advertised from ISP B. Both ISPs also receive the /20. Since BGP prefers the longest prefix match, traffic to /24 A enters via ISP A even though the /20 is also advertised there. To prevent the aggregate from flapping when a /24 is withdrawn, I use `aggregate-address 203.0.112.0 255.255.240.0 summary-only` which suppresses the advertisement of the component /24s and only sends the aggregate. Then I use a route-map to explicitly unsuppress the specific /24s where needed: `aggregate-address ... summary-only` combined with `suppress-map` or `unsuppress-map`. I also ensure the ISP knows about the specific /24s by including them in my prefix-list export. To avoid hitting prefix limits, I only advertise a small number of specifics (e.g., 4–8 /24s) rather than the entire /20 de-aggregated.

Question 15

What BGP security framework enforces this, and what are its limitations?

Accepted Answer

The framework is **RPKI (Resource Public Key Infrastructure)** with **ROV (Route Origin Validation)**, combined with **BGPsec** for path validation. However, RPKI/ROV only validates that the origin AS is authorized to announce the prefix — it does not prevent a malicious intermediate AS from inserting itself into the path (path shortening or interception). To prevent routes from traversing unauthorized ASes, the provider needs **BGPsec** (RFC 8205), which cryptographically signs the full AS_PATH. Unfortunately, BGPsec has significant CPU overhead and is not widely deployed on the public Internet as of 2026. The practical interim solution is **AS_PATH filtering** using prefix-lists and **peer-locking** — configuring each customer session with a strict export policy that only allows the customer's own routes and explicitly denies any route with another customer's AS in the path. I also implement **BGP Monitoring Protocol (BMP)** to stream BGP updates to a monitoring server that alerts when an unexpected AS appears in a customer's path. For the interview, the balanced answer is: "RPKI prevents origin hijacks, BGPsec prevents path manipulation, but today most providers rely on strict export filters, AS_PATH ACLs, and BMP monitoring to enforce customer isolation."

BGP Interview Questions: 15 Real-World Scenarios for CCNP & CCIE Candidates

More CCNP Enterprise Interview Prep