Fehlerbehebung bei unerwarteter Ping-Quell-IP ohne IP-Klassenlos

Einleitung

In diesem Dokument wird die Fehlerbehebung bei der Auswahl der ICMP-Quelladresse beschrieben, die durch die Interaktion zwischen no ip classless und der Standardroute verursacht wird.

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

• Konzepte und Funktionen des Border Gateway Protocol (BGP)
• Border Gateway Protocol (BGP)-Routing und Standardroutenlernmechanismen
• IPv4-Routing-Tabelle und längste Präfix-Übereinstimmung
• Die Rolle der Standardroute 0.0.0.0/0
• Klassenbasierter oder klassenloser IPv4-Routing-Suchmechanismus
• Grundlegende Logik für die Quelladressenauswahl in Cisco IOS XE für lokal generierten Datenverkehr

Verwendete Komponenten

• Cisco Catalyst 8500L-8S4X Edge-Plattform in Version 17.12.7b
• Cisco Catalyst Switch C9300 in Version 17.12.05

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

Hintergrundinformationen

1. Was ist IP-Klassenlos

• ip classless ermöglicht einem Router die weitere Suche nach anderen geeigneten Routen, einschließlich Supernet- und Standardrouten, wenn eine bestimmte Subnetzroute innerhalb eines klassenbezogenen Hauptnetzwerks nicht übereinstimmt.
• no ip classless verwendet das herkömmliche klassenbezogene Suchverhalten.
• Wenn die Zieladresse zu einem Hauptnetzwerk gehört, das bereits in der Routing-Tabelle vorhanden ist, aber innerhalb dieses Hauptnetzwerks keine übereinstimmende Subnetzroute vorhanden ist, kann keine IP-Klassenlose verhindern, dass der Router die Standardroute ordnungsgemäß verwendet, um die Suche abzuschließen.

2. Warum wird kein IP classless nicht empfohlen?

• Derzeit werden in Netzwerken in der Regel VLSM (Variable Length Subnet Mask), CIDR (Classless Inter-Domain Routing), BGP-aggregierte Routen und Standardrouten verwendet.
• no ip classless ist ein Kompatibilitätsverhalten, das für klassische Netzwerke entwickelt wurde und für moderne IP-Netzwerke nicht geeignet ist.

Hintergrund des Problems

Problembeschreibung

Auf dem C8500L-Router wird die Standardroute über das BGP abgefragt, und der nächste Hop der Standardroute verweist auf den Ausgang des öffentlichen Netzwerks.

Wenn der Befehl direkt ausgeführt wird:

C8500L# ping 8.8.8.8

Das Gerät wählt nicht die Adresse der Ausgangsschnittstelle des öffentlichen Netzwerks als Quelladresse für das ICMP-Echo aus, sondern die interne Schnittstellenadresse (z. B. 192.168.72.208). Da diese interne Adresse nicht korrekt über das öffentliche Netzwerk zurückgegeben werden kann, schlägt der Ping-Befehl fehl.

Für eine andere öffentliche Adresse, die ebenfalls auf der Standardroute basiert, z. B.:

C8500L# ping 10.10.10.10

Das Gerät kann die Adresse der Schnittstelle zum Beenden des öffentlichen Netzwerks korrekt als Quelladresse auswählen, und der Ping-Test ist erfolgreich.

Topologie

Wichtigste Bedingungen für das Problem

• C8500L lernt 0.0.0.0/0 durch BGP.
• Die Routing-Tabelle enthält BGP-Präfixe für das Hauptnetzwerk 8.0.0.0/8.
• Es sind keine spezifischen Subnetze für 8.8.8.8 verfügbar.
• Die Konfiguration enthält kein IP classless.

Basiskonfiguration

C8500L-Konfiguration:

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überprüfung

1. Routing- und CEF-Tabelle

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 an ein betroffenes Ziel senden

Beispiel:

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)

Erwartetes normales Verhalten:

• Der Datenverkehr wird von der standardmäßigen, für die Route festgelegten WAN-Ausgangsstelle gesendet.

Tatsächliches Verhalten:

• Bei der Ausgabeschnittstelle handelt es sich um eine öffentliche WAN-Schnittstelle, aber die Quelladresse der ICMP-Nachricht wird als eine nicht-exitende Schnittstellenadresse ausgewählt.
• Aufgrund nicht erreichbarer Einschränkungen für Backhaul- und VLAN-Sicherheitsrichtlinien schlägt der Ping fehl.

3. Ping an ein nicht betroffenes Ziel senden

Beispiel:

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)

Normale Leistung:

• Die Routing-Suche löst nicht die gleiche klassenbezogene Netzwerkprüfung für die Pfadbestimmung aus.
• Die Standard-Routing-Suche wird normal abgeschlossen.
• Ping wählt die Adresse der WAN-Ausgangsschnittstelle als Quelladresse aus.
• ICMP-Kommunikation war erfolgreich.

Ursachenanalyse

Suche nach klassenbezogenem Hauptnetzwerk

Da in der RIB für 8.8.8.8 wichtige Netzwerkinformationen 8.0.0.0/8 vorhanden sind, führt der Router nach der Aktivierung von no ip classless zunächst eine klassenbezogene Suche durch:

1. Der Router erkennt, dass die Zieladresse 8.8.8.8 zum Hauptnetzwerk 8.0.0.0/8 der Klasse A gehört.
2. In der RIB befinden sich Routing-Informationen zu 8.0.0.0/8.
3. Anschließend sucht der Router in 8.0.0.0/8 nach einer spezifischeren Subnetzroute, die 8.8.8.8 entsprechen kann.
4. Die spezifischere Subnetzsuche schlägt fehl.

Die Standardroute wird bei der First-Hop-Suche nicht ordnungsgemäß verwendet.

Im Szenario no ip classless kann der Router zwar die Standardroute identifizieren, die nachfolgende Überprüfung der RIB-First-Hop-Suche kann jedoch normalerweise nicht die Schnittstelleninformationen zurückgeben, die mit dem Weiterleitungspfad verknüpft sind. Der interne Suchvorgang gibt schließlich ein leeres Ergebnis (NULL) zurück.

Quelladresse fällt auf eine Standardschnittstelle zurück

Wenn der lokal generierte Datenverkehr nicht die richtigen Informationen zur ausgehenden Schnittstellenzuordnung aus der First-Hop-Suche der RIB abrufen kann, wird die Quelladressenauswahllogik auf den Standardmechanismus für die Schnittstellenauswahl zurückgesetzt.

Dieser Fallback-Mechanismus garantiert nicht, dass die ausgewählte Adresse mit der tatsächlichen ausgehenden FIB-Schnittstelle übereinstimmt. Aus diesem Grund kann eine beliebige lokale Schnittstellenadresse ausgewählt werden, z. B. eine interne LAN-Schnittstellenadresse.

Infolgedessen kommt es zu dem scheinbar widersprüchlichen Ergebnis:

• Schnittstelle für die tatsächliche Ausgabe: WAN-Schnittstelle
• Der tatsächliche nächste Hop: Der nächste Hop am Ausgang des öffentlichen Netzwerks
• ICMP-Quelladresse: Interne LAN-Schnittstellenadresse

Dies ist die direkte Ursache des Ping-Fehlers.

Warum funktioniert 8.8.8.8 nicht, aber 10.10.10.10 funktioniert?

Ziel 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

• In der Routing-Tabelle ist das Hauptnetzwerkpräfix 8.0.0.0/8.
• Der Befehl no ip classless löst das Verhalten bei der Suche nach klassenbezogenen Subnetzen aus.
• Nachdem im Hauptnetzwerk kein passendes Subnetz gefunden wurde, kann die First-Hop-Suche die Schnittstelleninformationen nicht normal zurückgeben.
• Die lokale ICMP-Quelladressenfallbackauswahl ist auf eine Adresse der Schnittstelle festgelegt, die nicht exportiert wird.
• Der Ping-Befehl ist fehlgeschlagen.

Ziel 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

• Wenn es in der RIB keinen Hauptnetzwerkeintrag für 10.0.0.0/8 gibt, wird derselbe klassenbezogene Subnetzprüfungszweig nicht eingegeben.
• Die Standardroute kann normalerweise für die Routensuche verwendet werden.
• Der Router kann die korrekten Informationen zur Ausgangsschnittstelle abrufen.
• ICMP verwendet die Exit-Schnittstellenadresse als Quelladresse.
• Der Ping-Test ist erfolgreich.

Daher ist das Auftreten des Problems nicht zufällig. Stattdessen hängt es davon ab, ob das der Zieladresse entsprechende klassenbezogene Hauptnetzwerk in der Routing-Tabelle vorhanden ist und ob eine passende spezifischere Subnetzroute vorhanden ist.

Problemumgehungen

Empfohlene Lösung

Entfernen Sie no ip classless, und stellen Sie die klassenlose Routensuche wieder her:

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

Temporäre Problemumgehungen

Wenn es nicht möglich ist, keine IP-Klassenlose sofort zu ändern, können Sie die Quellschnittstelle für eine bestimmte lokale Anwendung explizit angeben. Beispiel:

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

Für Ping-Tests kann die Quelladresse manuell angegeben werden:

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

Oder stellt die Konfiguration statischer Routen für bestimmte Adressen eine vorübergehende/Direktiven-Umgehungslösung für eine bestimmte Zieladresse dar.

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

Diese Methoden lösen nur das Problem mit der Quelladresse für bestimmte Anwendungen oder Einzeltests und können das Entfernen von no ip classless nicht ersetzen.

Befehle für die Fehlerbehebung

• Routing-Details für den technischen Support anzeigen

• show ip route supernets-only
• show running-config | IP-Klassenlos einschließen
• show ip route <Ziel>
• show ip route <Hauptnetz> <Maske> längere Präfixe
• show ip cef <Ziel> detail
• show ip route 0.0.0.0
• show ip bgp <Ziel>
• debug ip packet <acl> detail
• debug ip icmp
• debug ip routing

Analyse der Auswirkungen

Betroffener Datenverkehr

Die Hauptauswirkungen sind auf lokal generierten Datenverkehr, der die Quelladresse nicht explizit angibt, wie z. B.:

• Ping
• Traceroute für Standardquellenadresse
• DNS-Abfrage
• HTTP-/HTTPS-Client-Zugriff
• Smart Licensing - Online-Registrierung oder Kommunikation
• Verkehr auf Verwaltungsebene von NTP, Syslog, SNMP usw. (ohne angegebene Quellschnittstelle)

Normalerweise nicht betroffener Datenverkehr

In der Regel nicht direkt betroffen:

• Der Datenverkehr, der von der LAN-Seite eingegangen ist und vom Router weitergeleitet wurde.
• den lokalen Datenverkehr mit einer eindeutig festgelegten Quelladresse oder Quellschnittstelle;
• Der Datenverkehr mit spezifischerem Routing-Matching.

Die genauen Auswirkungen hängen jedoch weiterhin vom Netzwerk-Backhaul-Pfad, den NAT-Richtlinien, ACLs und Sicherheitsrichtlinien ab. Daher wird empfohlen, die kritische Kommunikation auf Management- und Kontrollebene im Produktionsnetzwerk vollständig zu überprüfen.

Schlussbemerkung

In einem Netzwerk mit Standardrouten und mehreren Schnittstellenadressen kann der Befehl no ip classless den korrekten Abruf der Schnittstelleninformationen verhindern, die dem tatsächlichen Weiterleitungspfad für das klassenweise Routing bestimmter Zieladressen zugeordnet sind.

In diesem Fall kann die Quelladressenauswahl für lokal generierten Datenverkehr auf dem Gerät auf die nicht pfadabhängige Schnittstellenauswahllogik zurückgesetzt werden, was zu lokalem Datenverkehr wie Ping mit falschen Quell-IPs führt. Wenn die Quell-IP nicht über eine öffentliche Erreichbarkeit oder einen korrekten Backhaul-Pfad verfügt, kann die Kommunikation fehlschlagen.

Zugehörige Informationen

• Cisco: IP-Klassenlos 
• Grundlegendes zu den erweiterten ping- und traceroute-Befehlen 

Revisionsverlauf

Überarbeitung	Veröffentlichungsdatum	Kommentare
1.0	04-Sep-2026	Erstveröffentlichung