Routing Loop Detected in Core Network – Real Fixes

1. Static Route Misconfiguration – The Most Common Cause

I can't tell you how many times I've walked into a client's server room and found a routing loop caused by someone typing a static route wrong. It happens all the time. You think you're being helpful by adding a static route to reach a subnet, but you accidentally point it back to the same router. Boom – loop.

The real fix is simple: check every static route on every router in the path. Use this command on Cisco gear:

show ip route | include S

Look for routes that point to the same interface or the same next-hop that's actually the router itself. For example, I had a client last month whose router had a static route for 10.1.2.0/24 pointing to 10.1.1.1, but 10.1.1.1 was the router's own IP on that subnet. Traffic went out, came back, went out again – loop.

Fix it by deleting the wrong route and adding the correct one:

no ip route 10.1.2.0 255.255.255.0 10.1.1.1
ip route 10.1.2.0 255.255.255.0 10.1.3.1

After you fix it, ping from one end to the other. If it works, the loop is gone. If not, check the next router.

2. Routing Protocol Redistribution Loop – The Sneaky One

This one is trickier. It happens when you have two routing protocols exchanging routes, like OSPF and EIGRP, and they feed each other back the same routes. I saw this at a mid-sized company last year. They had OSPF on the core and EIGRP on the edge. Someone enabled redistribution both ways without using route tags or filters.

Here's what happens: OSPF learns a route, redistributes it into EIGRP, EIGRP sends it back into OSPF, and OSPF sends it back to EIGRP. Traffic takes forever or doesn't move.

Fix it by adding route tags. On Cisco, do this:

route-map OSPF-to-EIGRP permit 10
 match tag 100

route-map EIGRP-to-OSPF permit 10
 match tag 200

Then tag your redistributed routes when you inject them. Set a tag of 100 for routes coming from OSPF into EIGRP, and tag 200 for the other direction. The route-map then blocks routes that don't have the right tag.

Another fix is to change administrative distance. But I prefer tags because they're clearer. If you don't want to mess with tags, just filter based on prefix lists. For example:

ip prefix-list BLOCK-LOOPS seq 5 deny 10.0.0.0/8 le 32
route-map EIGRP-to-OSPF permit 10
 match ip address prefix-list BLOCK-LOOPS

Test by checking the routing table on each router. Look for routes that shouldn't be there.

3. OSPF or EIGRP Neighbor Misconfiguration – The Timer Problem

Sometimes the loop is not a wrong route, but a neighbor bouncing. I had a client whose OSPF neighbors kept flapping because the hello and dead timers didn't match on two routers. One router had hello timers of 10 seconds, the other had 30. They'd form a neighbor, lose it, form again. During the down time, traffic took a different path and looped back.

Check your timers. On Cisco, use:

show ip ospf interface [interface-name]

Look for the hello and dead intervals. They must match. Fix it by setting them the same on both sides:

interface GigabitEthernet0/1
 ip ospf hello-interval 10
 ip ospf dead-interval 40

Also check the network type. If one side is point-to-point and the other is broadcast, they won't form a neighbor correctly. I once spent two hours chasing a loop that was really just a mismatched network type. Set them both to the same type.

For EIGRP, check the K-values. They have to match. And make sure the autonomous system number is the same. I had a client who typed 100 on one router and 1000 on another – no loop, just no neighbor, but it caused a failover loop because the backup path took over when the primary neighbor didn't form.

Quick-Reference Summary Table

If you still got a loop after checking these three things, get a packet capture. Wireshark will show you the TTL decrementing. That's you last resort, but it works.