50 Expert Q&As + 15-Question Interactive Quiz

5 — the lowest administrative distance in EIGRP.

ip summary-address eigrp — configured under the interface.

Null0 — the discard interface used for loop protection.

eigrp stub — configured under the router EIGRP process.

connected summary — advertises only connected and summary routes.

No — that is the core purpose of stub routing.

show ip protocols — look for the "Stub" section.

Prefix-list — matches both network and prefix length.

distribute-list — configured under the router EIGRP process.

Inbound — prevents routes from entering the local routing table.

set tag — applies a numeric tag to redistributed routes.

170 — external routes have a higher AD than internal (90).

show ip route [prefix] detail — look for the "Tag" field.

0 to 4294967295 — a 32-bit unsigned integer.

ASBR — Autonomous System Boundary Router.

The Null0 route prevents routing loops by discarding traffic for subnets that fall within the summary range but are not actually reachable, avoiding the blackhole that would occur if that traffic were sent to the summary's next-hop.

Specific subnets will still be advertised to neighbors on the other interfaces, which can cause suboptimal routing or loops because downstream routers receive both the summary and the specific routes.

Stub routing confines queries to a small domain by preventing edge routers from forwarding queries, which eliminates cascading SIA events that would otherwise propagate across the entire network.

A router should not be configured as a stub when it acts as a transit router that must forward queries on behalf of downstream neighbors, such as a distribution or ASBR router.

A standard ACL matches only the network address, while a prefix-list matches both the network address and the prefix length, making it more precise and structured for routing policies.

Inbound filtering prevents routes from entering the local routing table, which is safer because it does not affect downstream routers that may depend on those routes.

Route tagging attaches a numeric identifier to redistributed routes so that when they are redistributed back into their original protocol, they can be identified and filtered to prevent redistribution loops.

Without an explicit seed metric, the redistributed routes would inherit an infinite metric and be rejected by the receiving protocol, preventing them from being installed in the routing table.

An ASBR (Autonomous System Boundary Router) is a router that sits at the boundary between two routing domains and performs redistribution, making it the critical point where routing information crosses between protocols.

A stub router advertises limited routes and does not forward queries, while a transit router forwards queries on behalf of downstream neighbors and can be part of the query propagation path.

AD 5 is lower than any other EIGRP route (internal 90, external 170), ensuring the Null0 route is preferred and cannot be overridden by a leaked specific subnet, protecting the summary range from blackholes.

Bidirectional route tagging combined with mutual filtering ensures that routes originating in one protocol are not redistributed back into the same protocol, breaking the loop cycle.

An offset-list inflates the metric of the redistributed route, allowing you to make it less preferred than other paths while keeping the route valid in the topology table.

The Null0 protection disappears, and traffic for unassigned subnets within the summary range can be routed to the summary's next-hop, creating a blackhole or routing loop.

Summarization reduces query scope because downstream routers only know the summary route, not the specific subnets, so queries for specific subnets are contained at the summarization boundary and do not propagate further.

First check: Verify whether the specific subnet is actually reachable within the EIGRP domain.

show ip route | include Null0
show ip route 10.1.15.0
show ip eigrp topology | include 10.1.15

If the specific subnet has been removed but the summary still advertises it, the Null0 route is discarding traffic. You need to either re-advertise the specific subnet or adjust the summary to exclude it.

Likely cause: The stub configuration is too restrictive — it only advertises connected routes but does not advertise summaries or static routes that users need.

Fix:

router eigrp 1234
 eigrp stub connected summary static

Also verify the stub is not blocking routes it should be receiving.

Diagnostic steps:

1. Check if a distribute-list is filtering it: show ip protocols | include filter
2. Check if an ACL or prefix-list is blocking it: show ip prefix-list
3. Check if the route is a candidate for distribution but rejected due to tag mismatch

Inbound filtering silently rejects routes — there are no syslog messages. This is why show ip protocols is the first check.

Possible causes:

• The redistribution point (ASBR) is configured as a stub — it cannot advertise redistributed routes
• A prefix-list is blocking the specific prefix
• The route tag is being denied on the reverse redistribution
• The seed metric is set to infinity

show ip route eigrp | include EX
show ip protocols | section Stub
show ip prefix-list

Root cause: Missing route tags on redistributed routes.

Fix: Apply two-way tagging with mutual filtering.

route-map OSPF_TO_EIGRP permit 10
 set tag 100
 set metric 100000 100 255 1 1500

route-map EIGRP_TO_OSPF deny 5
 match tag 100
route-map EIGRP_TO_OSPF permit 10
 set tag 200

The key is the deny clause that prevents re-redistribution of already-tagged routes.

show ip route 10.16.0.0 detail

! Look for "Tag 100, type external" in the output

If the tag field is missing or shows a different value, the route-map is not matching properly.

! Step 1: Re-apply the summarization
interface GigabitEthernet0/1
 ip summary-address eigrp 1234 10.16.0.0 255.255.240.0

! Step 2: Verify Null0 route is present
show ip route | include Null0

! Step 3: Verify specific subnets are reachable
show ip route 10.16.5.0

Recovery is immediate once the summary is re-applied because the Null0 route is automatically installed.

Recommended sequence:

1. Verify all specific subnets are currently reachable
2. Apply summarization during a maintenance window
3. Verify Null0 route is installed: show ip route | include Null0
4. Verify specific subnets are still reachable from remote routers
5. Test end-to-end connectivity for critical destinations

Approach: Use an outbound distribute-list with a prefix-list on the advertising router.

ip prefix-list BLOCK_SUBNET deny 10.1.15.0/24
ip prefix-list BLOCK_SUBNET permit 0.0.0.0/0 le 32

router eigrp 1234
 distribute-list prefix BLOCK_SUBNET out GigabitEthernet0/1

Verify with show ip protocols | include filter and by checking the neighbor's routing table.

Diagnosis: The stub is probably too aggressive and has prevented routes from being advertised that downstream hosts need.

Verify:

show ip protocols | section Stub
show ip route
show ip eigrp neighbors

Fix: Expand the stub options (e.g., add static or redistributed) or remove stub if the router actually needs to forward queries.

Design principles:

1. Apply summarization on ALL relevant interfaces, not just one
2. Ensure the summary does not overlap with routes from other domains
3. Verify the Null0 route is installed
4. Test failure scenarios before deploying to production
5. Consider a "summary null0" strategy where the summary is preferred only when the specific routes are unavailable

An ip summary-address eigrp is automatically installed on the interface and creates a Null0 discard route with AD 5, whereas a static summary route requires manual configuration and does not provide the automatic Null0 protection.

Always prefer the interface-level summary for EIGRP because it is tied to the protocol and moves with the interface configuration.

! On the stub router
show ip eigrp traffic
! Queries received should be low or zero

! On the non-stub peer
show ip eigrp events | include Query
! Query originations should not reach stub routers

! Verify stub annotation on neighbors
show ip eigrp neighbors detail | include Stub

If you see queries being forwarded to the stub routers, the stub configuration is not working correctly.

! Step 1: Verify the route is blocked on the new router
show ip protocols | include filter
show ip prefix-list

! Step 2: Check if the route is in the topology table
show ip eigrp topology | include [prefix]

! Step 3: If the route is absent from topology, the filter is blocking it
! Step 4: Correct the prefix-list
ip prefix-list FILTER permit [prefix]

! Step 5: Verify the route appears
show ip route [prefix]

Safe testing approach:

1. Apply the route-map with a prefix-list that permits only a single test prefix
2. Verify the test route is redistributed correctly
3. Check for loops using show ip route and traceroute
4. Expand the prefix-list one prefix at a time
5. Document and verify after each step

Never apply "redistribute all" without a prefix-list filter in production.

! Step 1: Verify Null0 route
show ip route | include Null0

! Step 2: Test an unassigned subnet within the summary
ping 10.16.99.1 source [local interface]
! Should receive "Destination Unreachable" via ICMP

! Step 3: Test an assigned subnet
ping 10.16.5.1 source [local interface]
! Should succeed

The difference in behavior confirms that Null0 is protecting against unassigned subnets.

! Step 1: Verify the redistribution configuration
show run | section redistribute

! Step 2: Verify the route-map is applied
show route-map

! Step 3: Check if the route-map has a set tag statement
! Step 4: Ensure the route-map is matching the correct prefix-list

! Step 5: Re-apply if necessary
router eigrp 1234
 redistribute ospf 1 route-map OSPF_TO_EIGRP

The stub router will not forward the query to other stub routers, but it will reply to the querying neighbor with a negative reply if it does not have a suitable alternate path. This behavior is by design to prevent query propagation into the stub domain.

If both sides are incorrectly configured (one stub, one non-stub that expects the stub to forward queries), the adjacency may drop with a "peer not stub-compatible" message.

The critical consideration: The summary must not overlap with subnets that are advertised by other routing domains or paths. If overlap occurs, traffic for the overlapping subnets can blackhole or loop.

Always document your IP address plan before applying summarization and verify with show ip route | include [summary] on all downstream routers.

Recovery sequence:

1. Immediately remove the redistribution configuration to break the loop
2. Verify routes stabilize: show ip route | include EX
3. Verify neighbor adjacencies are stable: show ip eigrp neighbors
4. Analyze logs for the loop source: show log | include DUAL|NBRCHANGE
5. Apply correct route tagging and re-enable redistribution during a maintenance window
6. Verify end-to-end connectivity after re-enabling