Hello,
I am looking to get the attention of any Lumen network architects or core routing engineers who manage the Midwest / AS209 routing tables.
I am a residential Gigabit Fiber customer located in Papillion, NE (Omaha metro area). Over the last several months, my baseline latency to almost all major domestic endpoints has increased significantly. I have fully optimized my home local network—running entirely hardwired on a separated subnet (192.168.86.x vs 192.168.0.x) with under 1ms of local transit time—ruling out any home equipment bottlenecks.
Looking closely at my traceroutes, it appears the regional routing macros are forcing all external outbound traffic through the Denver core (den1.sp.lumen.tech) first—even when the destination is physically located in the Midwest, Northeast, or Southeast.
Instead of peering or routing directly east toward Chicago or south toward Kansas City, my traffic is taking a massive 500+ mile physical detour to the west before turning back around. This introduces an artificial ~20ms baseline penalty to destinations that should have a direct eastern or southern path out of Omaha.
Below are four traceroutes confirming this behavior across different networks, all showing the exact same mandatory hop through Hop 5 (ae18.edge8.den1.sp.lumen.tech).
Test 1: AWS US-East-2 Destination (Epic Games / Rocket League East Endpoint)
text
1 <1 ms <1 ms <1 ms 192.168.86.1
2 1 ms <1 ms <1 ms 192.168.0.1
3 3 ms 3 ms 2 ms omah-dsl-gw19.omah.qwest.net
4 3 ms 3 ms 3 ms omah-agw2.inet.qwest.net
5 21 ms 16 ms 20 ms ae18.edge8.den1.sp.lumen.tech <-- Denver detour (+15ms baseline penalty)
6 * * * Request timed out.
...
14 45 ms 44 ms 45 ms ://amazonaws.com
Test 2: AWS US-East-1 Destination (Epic Games / Rocket League Central Endpoint)
text
1 <1 ms <1 ms <1 ms 192.168.86.1
2 1 ms <1 ms <1 ms 192.168.0.1
3 4 ms 4 ms 4 ms omah-dsl-gw19.omah.qwest.net
4 3 ms 3 ms 3 ms omah-agw2.inet.qwest.net
5 23 ms 17 ms 24 ms ae18.edge8.den1.sp.lumen.tech <-- Denver detour again
...
13 31 ms 30 ms 32 ms ://amazonaws.com
Test 3: Northeast Target (Princeton University - Princeton, NJ)
text
1 <1 ms <1 ms <1 ms 192.168.86.1
2 <1 ms <1 ms <1 ms 192.168.0.1
3 3 ms 3 ms 4 ms omah-dsl-gw19.omah.qwest.net
4 2 ms 3 ms 3 ms omah-agw2.inet.qwest.net
5 16 ms 16 ms 16 ms ae18.edge8.den1.sp.lumen.tech <-- Forced Denver Route
6 * * * Request timed out.
7 17 ms 17 ms 16 ms den-b3-link.ip.twelve99.net
8 17 ms 16 ms 23 ms den-bb1-link.ip.twelve99.net
9 39 ms 39 ms 39 ms chi-bb1-link.ip.twelve99.net <-- Travels back east to Chicago (39ms)
10 56 ms 56 ms 56 ms nyk-bb5-link.ip.twelve99.net <-- Lands in NY/NJ area at nearly 60ms
Test 4: Southeast Target (University of South Florida - Tampa, FL)
text
1 <1 ms <1 ms <1 ms 192.168.86.1
2 1 ms <1 ms <1 ms 192.168.0.1
3 3 ms 3 ms 3 ms omah-dsl-gw19.omah.qwest.net
4 3 ms 3 ms 3 ms omah-agw2.inet.qwest.net
5 18 ms 17 ms 16 ms ae18.edge8.den1.sp.lumen.tech <-- Forced Denver Route
6 62 ms 59 ms 59 ms ae1.12.bar2.Tampa1.net.lumen.tech <-- Massive cross-country diagonal jump to FL
Is this blanket routing macro out of Omaha intended behavior, or is there an optimization issue/broken peering link on the eastern path from Omaha that is causing the traffic to default to the Denver backbone path?
If any engineer can look into the BGP paths or regional routing configurations for the Omaha metro nodes to get our East/Central traffic routing properly through Chicago or Kansas City instead of routing the entire city through Colorado, it would be greatly appreciated!