Troubleshoot Unexpected Ping Source IP with no IP Classless

Introduction

This document describes the Troubleshoot ICMP source address selection exception caused by interaction between no ip classless and the default route.

Prerequisites

Requirements

Cisco recommends that you have knowledge of these topics:

• Border Gateway Protocol (BGP) concepts and functionality
• Border Gateway Protocol (BGP) Routing and Default Route Learning Mechanisms
• IPv4 Routing Table and Longest Prefix Match
• The Role of the Default Route 0.0.0.0/0
• Classful vs. Classless IPv4 Routing Lookup Mechanisms
• Basic Logic for Source Address Selection in Cisco IOS XE for Locally Generated Traffic

Components Used

• Cisco Catalyst 8500L-8S4X Edge Platform in version 17.12.7b
• Cisco Catalyst C9300 switch in version 17.12.05

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.

Background Information

1. What Is ip classless

• ip classless allows a router to continue searching for other more suitable routes, including supernet and default routes, when a specific subnet route within a classful major network is not matched.
• no ip classless uses the traditional classful lookup behavior.
• When the destination address belongs to a major network already present in the routing table but there is no matching subnet route within that major network, no ip classless can prevent the router from properly using the default route to complete the lookup.

2. Why no ip classless Is Not Recommended

• Currently, VLSM (Variable Length Subnet Mask), CIDR (Classless Inter-Domain Routing), BGP aggregated routes and default routes are commonly used in networks.
• no ip classless is a compatibility behavior designed for early classful networks and is not suitable for modern IP networks.

Problem Background

Problem Description

On C8500L Router, the default route is learned through BGP, and the next hop of the default route points to the public network exit.

When the command is executed directly:

C8500L# ping 8.8.8.8

The device does not select the public network exit interface address as the source address for the ICMP Echo, but instead selects the internal interface address (such as 192.168.72.208). Since this internal address cannot correctly return via the public network, the Ping fails.

However, for another public address that also relies on the default route, such as:

C8500L# ping 10.10.10.10

The device can correctly select the public network exit interface address as the source address, and the Ping is successful.

Topology

Key Conditions for the Problem

• C8500L learns 0.0.0.0/0 through BGP.
• There are BGP prefixes related to the major network of 8.0.0.0/8 in the routing table.
• There are no specific subnets for 8.8.8.8 available.
• The configuration contains no ip classless.

Basic Configuration

C8500L Configuration:

interface TenGigabitEthernet0/1/0
no ip address
!
interface TenGigabitEthernet0/1/0.490
encapsulation dot1Q 490
ip address 172.16.119.30 255.255.255.252
!
interface TenGigabitEthernet0/1/0.2190
encapsulation dot1Q 2190
ip address 172.16.0.58 255.255.255.252
ip nat outside
!
interface TenGigabitEthernet0/1/1
no ip address
!
interface TenGigabitEthernet0/1/1.5
encapsulation dot1Q 5
ip address 192.168.72.208 255.255.255.192
!
interface TenGigabitEthernet0/1/1.1011
encapsulation dot1Q 1011
ip address 192.168.197.184 255.255.255.0
no ip proxy-arp
ip nat inside
ip tcp adjust-mss 1300
!
! 
no ip classless
ip forward-protocol nd
!
router bgp 65001
bgp log-neighbor-changes
neighbor 10.1.1.2 remote-as 65002

Symptom Verification

1. Routing and CEF Table

C8500L#show ip route bgp
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, m - OMP
n - NAT, Ni - NAT inside, No - NAT outside, Nd - NAT DIA
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
H - NHRP, G - NHRP registered, g - NHRP registration summary
o - ODR, P - periodic downloaded static route, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
& - replicated local route overrides by connected

Gateway of last resort is 172.28.0.57 to network 0.0.0.0

B* 0.0.0.0/0 [20/0] via 172.28.0.57, 6d22h
  8.0.0.0/8 is variably subnetted, 5 subnets, 3 masks
B 8.x.203.0/24 [20/0] via 10.1.1.2, 3d17h
B 8.x.0.0/16 [20/0] via 10.1.1.2, 6d22h
B 8.x.0.0/17 [20/0] via 10.1.1.2, 6d22h
B 8.x.0.0/17 [20/0] via 10.1.1.2, 6d22h
B 8.x.0.0/16 [20/0] via 10.1.1.2, 6d22h

C8500L#show ip route 8.8.8.8
% Subnet not in table
C8500L#show ip route 10.10.10.10
% Network not in table
C8500L#show ip cef 0.0.0.0/0 detail
0.0.0.0/0, epoch 2, flags [rib only nolabel, rib defined all labels, default route]
recursive via 172.16.0.57
attached to TenGigabitEthernet0/1/0.2190
C8500L#show ip cef 8.8.8.8 detail
0.0.0.0/0, epoch 2, flags [rib only nolabel, rib defined all labels, default route]
recursive via 172.16.0.57
attached to TenGigabitEthernet0/1/0.2190
C8500L#show ip cef 10.10.10.10 detail
0.0.0.0/0, epoch 2, flags [rib only nolabel, rib defined all labels, default route]
recursive via 172.16.0.57
attached to TenGigabitEthernet0/1/0.2190
C8500L#show ip cef exact-route 172.16.0.54 8.8.8.8
172.28.0.54 -> 8.8.8.8 =>IP adj out of TenGigabitEthernet0/1/0.2190, addr 172.16.0.57
C8500L#show ip cef exact-route 172.16.0.54 10.10.10.10
172.28.0.54 -> 10.10.10.10 =>IP adj out of TenGigabitEthernet0/1/0.2190, addr 172.16.0.57
C8500L#show ip cef exact-route 192.168.72.208 8.8.8.8
10.0.72.208 -> 8.8.8.8 =>IP adj out of TenGigabitEthernet0/1/0.2190, addr 172.16.0.57
C8500L#show ip cef exact-route 192.168.72.208 10.10.10.10
10.0.72.208 -> 10.10.10.10 =>IP adj out of TenGigabitEthernet0/1/0.2190, addr 172.16.0.57

2. Ping to an Affected Destination

Example:

C8500L# ping 8.8.8.8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

debug ip packet output:
IP: s=192.168.72.208 (local), d=8.8.8.8 (WAN-interface)

Expected normal behavior:

• The traffic is sent from the default route-specified WAN exit.

Actual behavior:

• The output interface is a public WAN interface,but the source address of the ICMP message is selected as a non-exit interface address.
• Due to unreachable backhaul and VLAN security policy restrictions, the Ping fails.

3. Ping to an Unaffected Destination

Example:

C8500L# ping 10.10.10.10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.10, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 62/62/63 ms

debug ip packet output:
IP: s=172.16.0.58 (local), d=10.10.10.10 (WAN-interface)

Normal performance:

• Routing lookup does not trigger the same classful major network check for path determination.
• Default routing lookup is completed normally.
• Ping selects the WAN exit interface address as the source address.
• ICMP communication is successful.

Root Cause Analysis

Classful Major Network Lookup

For 8.8.8.8, since there is major network information of 8.0.0.0/8 in the RIB, after enabling no ip classless, the router first performs a classful lookup:

1. The router identifies that the destination address 8.8.8.8 belongs to the Class A main network 8.0.0.0/8.
2. There is routing information related to 8.0.0.0/8 in the RIB.
3. The router then continues to search within 8.0.0.0/8 for a more specific subnet route that can match 8.8.8.8.
4. The more specific subnet search fails.

Default Route Is Not Properly Used by the First-Hop Lookup

In the no ip classless scenario, although the router can identify the default route, the subsequent verification of RIB first-hop lookup cannot normally return the interface information associated with the forwarding path. The internal lookup process ultimately returns an empty result (NULL).

Source Address Falls Back to a Default Interface

When the local-generated traffic cannot obtain the correct outgoing interface association information from the RIB first-hop lookup, the source address selection logic revert to the default interface selection mechanism.

This fallback mechanism does not guarantee that the selected address is consistent with the actual FIB outgoing interface. Therefore, it can choose any available local interface address, such as an internal LAN interface address.

As a result, the seemingly contradictory outcome occurs:

• Actual output interface: WAN interface
• The actual next hop: The next hop at the public network exit
• ICMP source address: Internal LAN interface address

This is the direct cause of the Ping failure.

Why Does 8.8.8.8 Fail but 10.10.10.10 Work

Destination 8.8.8.8

C8500L#show ip route 8.0.0.0 255.0.0.0 longer-prefixes
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, m - OMP
n - NAT, Ni - NAT inside, No - NAT outside, Nd - NAT DIA
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
H - NHRP, G - NHRP registered, g - NHRP registration summary
o - ODR, P - periodic downloaded static route, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
& - replicated local route overrides by connected

Gateway of last resort is 172.16.0.57 to network 0.0.0.0

  8.0.0.0/8 is variably subnetted, 5 subnets, 3 masks

B 8.x.203.0/24 [20/0] via 10.1.1.2, 3d17h
B 8.x.0.0/16 [20/0] via 10.1.1.2, 6d22h
B 8.x.0.0/17 [20/0] via 10.1.1.2, 6d22h
B 8.x.0.0/17 [20/0] via 10.1.1.2, 6d22h
B 8.x.0.0/16 [20/0] via 10.1.1.2, 6d22h

• There is a major network prefix of 8.0.0.0/8 in the routing table.
• The command no ip classless triggers the behavior of searching for classful subnets.
• After not finding a matching subnet in the major network, the first-hop lookup cannot return the interface information normally.
• The local ICMP source address fallback selection is set to a non-export interface address.
• The Ping failed.

Destination 10.10.10.10

C8500L#show ip route 10.0.0.0 255.0.0.0 longer-prefixes
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, m - OMP
n - NAT, Ni - NAT inside, No - NAT outside, Nd - NAT DIA
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
H - NHRP, G - NHRP registered, g - NHRP registration summary
o - ODR, P - periodic downloaded static route, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
& - replicated local route overrides by connected

Gateway of last resort is 172.16.0.57 to network 0.0.0.0

• If there is no major network entry corresponding to 10.0.0.0/8 in the RIB, the same classful subnet checking branch not be entered.
• The default route can be normally used for route lookup.
• The router can obtain the correct exit interface information.
• ICMP uses the exit interface address as the source address.
• The Ping is successful.

Therefore, the occurrence of the problem is not random. Instead, it depends on whether the classful major network corresponding to the destination address exists in the routing table, and whether there is a matching more specific subnet route.

Workarounds

Recommended Workaround

Remove no ip classless and restore the classless route lookup:

C8500L#configure terminal
C8500L(config)#ip classless
C8500L(config)#end

Temporary Workarounds

If it is not possible to immediately modify no ip classless, you can explicitly specify the source interface for a specific local application, for example:

C8500L(config)#ip domain lookup source-interface <interface>
C8500L(config)#ip http client source-interface <interface>

For Ping tests, the source address can be manually specified:

C8500L#ping 8.8.8.8 source <wan-interface-or-wan-ip>

Or Configure static routes for specific addresses represents a temporary/directive bypass solution for a specific destination address.

C8500L(config)#ip route 8.8.8.8 255.255.255.255 TenGigabitEthernet0/1/0.2190 172.16.0.57

These methods only solve the source address issue for specific applications or single tests and cannot replace the removal of no ip classless.

Troubleshooting Commands

• show tech-support routing detail

• show ip route supernets-only
• show running-config | include ip classless
• show ip route <destination>
• show ip route <major-network> <mask> longer-prefixes
• show ip cef <destination> detail
• show ip route 0.0.0.0
• show ip bgp <destination>
• debug ip packet <acl> detail
• debug ip icmp
• debug ip routing

Impact Assessment

Affected Traffic

The main impact is on local generated traffic that does not explicitly specify the source address, such as:

• Ping
• Default source address traceroute
• DNS query
• HTTP/HTTPS client access
• Smart Licensing online registration or communication
• Management plane traffic of NTP, Syslog, SNMP, and so on (without specified source-interface)

Normally Unaffected Traffic

Usually does not directly affect:

• The traffic that has entered from the LAN side and been forwarded by the router;
• The local traffic with a clearly specified source address or source-interface;
• The traffic with more specific routing matching.

However, the exact impact still depends on the network backhaul path, NAT policies, ACLs and security policies. Therefore, it is recommended to fully verify the critical management plane and control plane communications in the production network.

Final Conclusion

In a network with default routes and multiple interface addresses, the no ip classless command can prevent the correct retrieval of interface information associated with the actual forwarding path for classful routing of specific destination addresses.

When this occurs, the source address selection for locally generated traffic on the device can revert to the non-path-dependent interface selection logic, resulting in local traffic such as Ping using incorrect source IPs. If the source IP does not have public reachability or a correct backhaul path, communication can fail.

Related Information

• Cisco: IP Classless 
• Understand the Extended Ping and Extended Traceroute Commands 

Revision History

Revision	Publish Date	Comments
1.0	04-Sep-2026	Initial Release