Routing Protocols and Configuration Questions

Approach (brief)
Use R1 as the BGP Route Reflector (RR) in AS 65000. Configure iBGP neighbor sessions from R1 to R2 and R3 and mark those neighbors as route-reflector clients on R1. Do NOT configure R2↔R3 iBGP sessions — this avoids full mesh.

IOS configuration (example IPs / loopbacks)

• R1 (RR): router-id 1.1.1.1, peers to R2 (10.0.12.2) and R3 (10.0.13.3)

router bgp 65000
 bgp router-id 1.1.1.1
 neighbor 10.0.12.2 remote-as 65000
 neighbor 10.0.13.3 remote-as 65000
 ! designate clients so R1 reflects routes
 neighbor 10.0.12.2 route-reflector-client
 neighbor 10.0.13.3 route-reflector-client

• R2 (client): router-id 2.2.2.2, peer only to R1

router bgp 65000
 bgp router-id 2.2.2.2
 neighbor 10.0.12.1 remote-as 65000   ! IP of R1

• R3 (client): router-id 3.3.3.3, peer only to R1

router bgp 65000
 bgp router-id 3.3.3.3
 neighbor 10.0.13.1 remote-as 65000   ! IP of R1

(Adjust neighbor IPs to your interface addressing. If next-hop issues occur for eBGP-learned routes, consider neighbor x.x.x.x next-hop-self on R1.)

Why this works

• iBGP normally requires full mesh; RR lets R1 reflect client routes to other clients without R2–R3 peering.
• neighbor ... route-reflector-client on R1 marks a neighbor as client; reflection rules then apply.

Verification commands

• BGP summary & neighbor state:

show ip bgp summary
show ip bgp neighbors 10.0.12.2
show ip bgp neighbors 10.0.13.3

• Confirm route learned on R3 that originated on R2 (look for originator-id or next-hop):

show ip bgp
show ip route <prefix-from-R2>

• To see what R1 advertised to clients:

show ip bgp neighbors 10.0.13.3 advertised-routes
show ip bgp neighbors 10.0.12.2 advertised-routes

Example verification scenario

• Advertise loopback 192.0.2.2/32 from R2 into BGP. On R3 run show ip bgp 192.0.2.2 — you should see the route present with originator-id (R2's router-id) and AS path consistent with reflection, confirming R1 reflected R2's route to R3.

Goal: Determine why 172.16.10.0/24 is seen in OSPF LSDB/advertisements but not installed in RIB/FIB.

1. Confirm symptom and where route appears

• Verify RIB absence:

show ip route 172.16.10.0
show ip route | include 172.16.10.0

• Verify OSPF knows about the network:

show ip ospf database network 172.16.10.0
show ip ospf database | include 172.16.10.0

Reason: establishes whether OSPF LSA exists but RIB lacks the route.

2. Check route source and administrative distance

• See candidate route details (source protocol and AD):

show ip route 172.16.10.0 detail

• Inspect routing protocols and their administrative distances:

show ip protocols

Reason: if another protocol (e.g., static with AD 1, EIGRP AD 90) has a better AD, it will win.

3. Look for route filtering/policy preventing RIB install

• Check route-maps/prefix-lists applied to OSPF redistribution or neighbor:

show running-config | section router ospf
show ip prefix-list
show route-map
show ip access-lists

• Check distribute-list/prefix-lists on interfaces or VRFs:

show running-config | include distribute-list

Reason: OSPF may be receiving/advertising but filters block installation or redistribution.

4. Verify next-hop resolution and adjacency to next-hop

• Get OSPF next-hop: (OSPF external will show next-hop in detail)

show ip route ospf
show ip route 172.16.10.0

• Confirm next-hop is reachable/resolved:

show ip route <next-hop-ip> detail
show ip arp | include <next-hop-ip>
ping <next-hop-ip>
traceroute <next-hop-ip>

• Check CEF/FIB presence:

show ip cef 172.16.10.0

Reason: route won’t be installed into FIB if next-hop is unresolved or recursive lookup fails.

5. Verify route type and preference within OSPF

• Check if it’s OSPF external, NSSA external, or intra-area (LSA type):

show ip ospf database external
show ip ospf database nssa-external

Reason: External LSAs may be suppressed or have different selection rules.

6. Check for overlapping or longer-match routes

• Ensure no more-specific route in RIB that overrides:

show ip route | include 172.16.10.

Reason: A /25 or host route would be chosen over /24.

7. Inspect virtualization/VRF and control-plane configs

• Confirm VRF context:

show vrf
show ip route vrf <name> 172.16.10.0

Reason: route may be in another VRF.

8. Confirm forwarding plane installation and debug carefully

• Check FIB/Hardware:

show platform hardware rate-limit forwarding
show ip cef 172.16.10.0

• If safe, enable targeted debug (use during maintenance window):

debug ip routing
debug ip cef

Reason: reveals why kernel/ASIC rejected installation.

9. Summarize findings and remediate

• If AD conflict: adjust AD or remove competing route.
• If filtering: modify prefix-list/route-map.
• If next-hop unresolved: fix interface/adjacency or static/connected route to next-hop.
• If VRF mismatch: move or correct OSPF/VRF config.

Example outcome: “show ip route 172.16.10.0 detail” showed a static route with AD 1 installed; OSPF’s LSA present but AD 110 lost—resolved by removing the static or adjusting AD.

Follow-up: after change, verify:

clear ip route *
show ip route 172.16.10.0
show ip cef 172.16.10.0

Brief framing
I’d treat this as multi-layer control-plane scaling: limit what must be stored/validated, offload peers, and design graceful fallbacks when HW/CPU limits are hit.

Selective RIB admission

• Accept only prefixes needed for forwarding/peers (e.g., full table for transit, default+customer routes for stubs).
• Use filters, max-prefix, and prefix-lists per-peer.
• Trade-off: reduces memory/TCAM but can cause reachability loss and operational complexity (per-peer policies).

Route-servers / offloading peers

• Use route-servers (IXP or internal) to do route selection/mediation so edge router peers with a few servers instead of thousands.
• Trade-off: centralizes control; increases dependency on route-server availability and trust; need consistent policy translation.

Hardware TCAM limits & prefix programming

• Program only required prefixes to TCAM (active FIB), keep full RIB in control-plane software.
• Use LPM aggregation, supernets, and ECMP hashing to reduce entries.
• Trade-off: risk of slower software forwarding misses, longer convergence when programming TCAM.

RIB partitioning

• Split RIB across linecards/processes (VRF, per-linecard RIBs) or use route-reflection with selective import/export.
• Trade-off: complexity in synchronization, potential asymmetric routing, harder troubleshooting.

Graceful-degradation

• Implement thresholds (max-prefix, CPU/RIB watermarks) that trigger:
  • Stop accepting new peers
  • Demote less-critical VRFs
  • Serve stale FIB entries
• Trade-off: temporary service degradation but preserves control-plane stability.

RPKI validation latency

• On-path RPKI validation adds per-update latency and CPU load; synchronous validation can stall route installs.
• Mitigations: asynchronous validation with optimistic acceptance, cache local validators, use fast-validate hardware, or accept routes pending validation with lower preference.
• Trade-off: accepting unvalidated routes risks ROA-based filtering errors; synchronous blocks installs and reduces update throughput.

Conclusion / operational notes
Balance safety vs scale: prefer route-server offload + selective admission + async RPKI with strong caching. Monitor watermarks, automated circuit/policy actions, and rehearse failure modes.

Brief answer — ordered BGP best-path attributes

BGP evaluates attributes in this order (highest to lowest priority) until a single best path remains:

1. Weight (Cisco proprietary, local to router)
2. Local Preference (higher preferred)
3. Locally originated (via network/aggregate/redistribute)
4. AS-path length (shorter preferred)
5. Origin type (IGP < EGP < Incomplete)
6. MED (lower preferred; only compared if from same neighboring AS unless configured otherwise)
7. eBGP over iBGP (prefer eBGP)
8. IGP metric to BGP next hop (lowest cost to next-hop)
9. Older path (prefer older to avoid flap) / Router ID or peer address tie-breaker (lowest) — vendor-specific order and tie-breakers follow

Vendor-specific notes

• Cisco: weight is first (local, non-transitive). After IGP metric, Cisco historically uses route age then highest router-id? New IOS may use lowest router-id as final tie-breaker.
• Juniper: no weight; uses preference and next-hop metric, and lowest peer address/router-id as final tie-breaker.

Short example
Three candidate routes to 10.0.0.0/24:

• Path A: weight 0, local-pref 100, AS-path 3 hops, origin IGP, MED 50, learned via eBGP, IGP metric 10, router-id 1.1.1.1
• Path B: weight 0, local-pref 200, AS-path 5 hops, origin IGP, MED 10, learned via iBGP, IGP metric 5, router-id 2.2.2.2
• Path C: weight 0, local-pref 100, AS-path 2 hops, origin EGP, MED 20, learned via eBGP, IGP metric 20, router-id 3.3.3.3

Selection:

• No weight differences → check Local-pref: B has 200, others 100 → Path B selected despite being iBGP and longer AS-path because local-pref outranks AS-path and eBGP/iBGP. If local-pref tied between A and C, next AS-path would prefer C (2 hops) over A (3 hops).

Brief statement
RIP v2 is a classless distance-vector routing protocol that uses hop count as its metric, broadcasts/ multicasts updates, and adds authentication and subnet masks compared to RIP v1. It’s simple but limited.

Key behaviors & limits

• Maximum hop count: 15 (16 = unreachable). Limits network diameter.
• Convergence: relatively slow; susceptible to routing loops without mitigations.
• Updates: periodic every 30s by default; supports multicast to 224.0.0.9.

Loop prevention mechanisms

• Split horizon: a route learned on an interface is not advertised back out that same interface — reduces chance of loops.
• Poison reverse: explicitly advertises a learned route back out the source interface with metric = 16 (unreachable) to quickly inform neighbors and prevent incorrect acceptance — useful when split horizon alone would hide a change.

Triggered updates

• When a route changes (e.g., goes down), RIP v2 can send immediate triggered updates instead of waiting for the next 30s interval to speed convergence. Still, triggered updates can cause update storms in larger networks.

When RIP v2 is appropriate today

• Small, flat networks with few hops (<=15), simple lab environments, legacy equipment compatibility, or constrained embedded devices where complexity must be minimal.
• Not suitable for cloud-scale, multi-site, or highly available enterprise fabrics — prefer OSPF, EIGRP, or BGP for scalability, faster convergence, and richer features.

Practical note (as a Network Engineer)
Use RIP v2 only where simplicity and legacy interoperability outweigh its scalability and convergence limitations; otherwise choose a link-state or path-vector protocol.