Routing Fundamentals and Protocols Questions

Comprehensive Internet Protocol routing principles and common routing protocol behaviors that network engineers are expected to know. Candidates should understand how routers build and consult routing tables to forward packets, the forwarding decision process including longest prefix match and tie breaking, the difference between static routing and dynamic routing, and how the control plane and the forwarding plane interact. Core concepts include route selection logic, route metrics and how they influence path choice, administrative distance and route preference, default routes, route summarization and aggregation, and route redistribution between protocols. Familiarity with interior gateway protocols and their typical behaviors is expected, including Routing Information Protocol version two, Open Shortest Path First, Enhanced Interior Gateway Routing Protocol, and Intermediate System to Intermediate System, plus an introduction to Border Gateway Protocol for interdomain routing where relevant. Candidates should also understand convergence properties and failure handling, basic configuration trade offs for performance and scalability, and common troubleshooting techniques and commands used to diagnose routing and reachability issues in enterprise and service provider networks.

MediumSystem Design

83 practiced

Design an OSPF area layout for a medium enterprise with 12 regional sites (each with two routers) and a central data center hosting 20 VLANs. Goals: fast intra-region convergence, limited LSDB size in the backbone, and simplified management. Sketch your area plan, specify where ABRs and summarization should be placed, whether to use stub/NSSA areas, and justify your decisions.

HardTechnical

135 practiced

You need to implement inbound traffic engineering for your prefix 198.51.100.0/24 across three upstream ISPs. Describe and compare techniques such as AS_PATH prepend, MED, selective advertisement, and communities. Provide an example route-map or prefix-list logic to prepend AS_PATH on one upstream and set a community on another, and discuss limitations of each method.

Sample Answer

**Brief approach**Use a mix: selective advertisement for coarse control, AS_PATH prepend to discourage one path, MED to influence neighbors in same AS, and BGP communities to ask upstreams to apply provider-specific prepends or local-pref adjustments. Combine methods because none guarantee global behavior.

**Technique comparison**- AS_PATH prepend - Pros: Simple; widely supported. - Cons: Heuristic — some peers ignore long AS_PATHs; increases path length but may not override local policies.- MED - Pros: Precise influence for multihomed peers within same neighboring AS or when neighbor honors MED. - Cons: Only compared when same neighboring AS advertises multiple paths; many ISPs ignore MED.- Selective advertisement - Pros: Strong control — don’t announce to a provider to force traffic elsewhere. - Cons: Reduces redundancy; single-point-of-failure if removed path is needed.- Communities - Pros: Powerful when upstream documents community actions (prepend-on-receive, set-local-pref, blackhole, no-export). - Cons: Provider-dependent; requires coordination and documented policies.

**Example (Cisco IOS)**- Define prefix-list

cisco

ip prefix-list MYPREFIX seq 5 permit 198.51.100.0/24

- Route-map to prepend for ISP-A (peer-group/neighbor A) and set community for ISP-B

cisco

route-map TO_ISP_A permit 10
 match ip address prefix-list MYPREFIX
 set as-path prepend 65000 65000 65000

route-map TO_ISP_B permit 10
 match ip address prefix-list MYPREFIX
 set community 65000:100 additive

- Apply to neighbors

cisco

neighbor 203.0.113.1 route-map TO_ISP_A out
neighbor 198.51.100.1 route-map TO_ISP_B out

**Limitations & operational notes**- Test in maintenance window; monitor with looking glasses and flow analytics.- Coordinate communities with ISPs; verify which communities they honor.- Prepending is best-effort — use in combination with selective advertisement or provider-side communities for stricter control.- Track BGP convergence and possible route churn from frequent changes.

MediumTechnical

88 practiced

Explain DUAL's role in EIGRP convergence and how feasible successors allow fast failover. Provide an example topology where a feasible successor exists and an example where it does not, and describe how EIGRP behaves in each case during a link failure.

HardTechnical

78 practiced

Customers report intermittent blackholing of traffic between two sites over an MPLS backbone that uses iBGP to distribute routes. Describe a structured troubleshooting approach: which CLI commands and logs you would collect (e.g., 'show mpls ldp neighbor', 'show mpls forwarding-table', 'show ip bgp', 'show ip route'), telemetry/packet captures you might run, likely root causes (label distribution, next-hop reachability, LDP/RSVP issues, route flapping), and steps to isolate and fix the problem.

Sample Answer

**Situation & goal**Show a structured, reproducible troubleshooting workflow to find intermittent blackholing across an MPLS backbone using iBGP.

**Step 1 — Gather control/forwarding state (commands)**Collect BGP, RIB, MPLS and interface state from both edge and core devices:

bash

show ip bgp summary
show ip bgp <prefix> detail
show ip route <prefix>
show ip cef <prefix>                # or show mpls forwarding-table <prefix>
show mpls forwarding-table
show mpls ldp neighbor
show mpls ldp bindings
show mpls ldp discovery
show interfaces terse | include <iface>
show logging | include mpls|ldp|bgp
show ip bgp neighbors <nbr> advertised-routes

**Step 2 — Telemetry & packet captures**- Capture packet-in/icmp unreachable/arp on PE/CE facing interfaces for affected prefix.- Use NetFlow/IPFIX or sFlow on PEs to see where traffic stops.- Collect LDP/RIB/Label bindings periodically (every 30s) to correlate with blackhole times.- If supported, enable BGP/LDPCORE debug tied to timestamps (short windows).

**Step 3 — Likely root causes**- Label distribution issues: missing or inconsistent LDP bindings between PEs/LSRs.- Next-hop reachability: iBGP next-hop not reachable due to IGP flaps or blackhole in core.- LDP session flaps or signaling bugs (TTL, auth, adjacency churn).- Route flapping / BGP pathology: iBGP withdraws or inconsistent route reflection.- MPLS forwarding table corruption / CEF inconsistencies.- MTU, ACL, or QoS dropping packets on specific LSPs.

**Step 4 — Isolation steps**- Correlate timestamps: match blackhole event to LDP/BGP/IGP logs and NetFlow.- Verify label presence end-to-end: - On ingress PE: ensure there is an outgoing label for prefix. - On intermediate LSRs: ensure label swap entries exist. - On egress PE: ensure label pop/implicit-null present.- Check next-hop reachability in the IGP: -

show ip ospf neighbor

show isis adjacency

as applicable.- Force traceroutes with MPLS TTL preserved (mpls ttl-expiry) to see where label-stack drops: -

traceroute mpls <dest>

or use tcpdump with MPLS snapshot.- Temporarily route around problematic LSR/PE (static or IGP metric) to see if issue clears.

**Step 5 — Remediation**- If LDP session flaps: clear LDP on affected neighbors, investigate MTU/auth, CPU/memory, control-plane policing.- If missing bindings: restart LDP process gracefully or re-negotiate sessions; check LDP for mismatched transport addresses.- If next-hop not reachable: fix IGP adjacency, correct route-reflector configuration, ensure route redistribution consistent.- If BGP withdraws: check route-reflector, policy, dampening, and update timers; patch buggy IOS/JunOS if reproducible.- If forwarding-table corrupted: clear CEF/MPLS forwarding safely during maintenance window.- Implement monitoring/alarms: LDP/BGP session flaps, label binding mismatch alerts, NetFlow drop trends.

**Why this approach**Collecting control-plane (BGP/IGP/LD P) + forwarding-plane (CEF/MPLS) + telemetry (flow/capture) lets you correlate control changes to packet loss and isolate whether blackholing is due to route state, label/state distribution, or packet forwarding. Restarting protocols or rerouting is corrective; root cause fixes address MTU/bugs/IGP stability to prevent recurrence.

EasyTechnical

79 practiced

Explain how a router performs the forwarding decision using the longest-prefix-match (LPM) rule. Using the example routes 10.0.0.0/8, 10.1.0.0/16 and 10.1.2.0/24 and a packet destined to 10.1.2.5, show which route is chosen and why. Then describe the typical tie-breaking steps when multiple routes of the same prefix length are present (for example: comparing administrative distance, metrics, route type, and ECMP behavior) and mention any vendor-specific nuances you know.

Unlock Full Question Bank

Get access to hundreds of Routing Fundamentals and Protocols interview questions and detailed answers.

Join thousands of developers preparing for their dream job.