Problemen oplossen FTD Upstream-apparaat kan niet worden gepingd ondanks ARP-invoer

Downloadopties

PDF (391.6 KB)
Met Adobe Reader op diverse apparaten bekijken
ePub (230.2 KB)
Bekijken in diverse apps op iPhone, iPad, Android, Sony Reader of Windows Phone
Mobi (Kindle) (192.2 KB)
Op Kindle-apparaat of via Kindle-app op meerdere apparaten bekijken

Bijgewerkt:30 september 2026

Document-id:225935

Inclusief taalgebruik

De documentatie van dit product is waar mogelijk geschreven met inclusief taalgebruik. Inclusief taalgebruik wordt in deze documentatie gedefinieerd als taal die geen discriminatie op basis van leeftijd, handicap, gender, etniciteit, seksuele oriëntatie, sociaaleconomische status of combinaties hiervan weerspiegelt. In deze documentatie kunnen uitzonderingen voorkomen vanwege bewoordingen die in de gebruikersinterfaces van de productsoftware zijn gecodeerd, die op het taalgebruik in de RFP-documentatie zijn gebaseerd of die worden gebruikt in een product van een externe partij waarnaar wordt verwezen. Lees meer over hoe Cisco gebruikmaakt van inclusief taalgebruik.

Over deze vertaling

Cisco heeft dit document vertaald via een combinatie van machine- en menselijke technologie om onze gebruikers wereldwijd ondersteuningscontent te bieden in hun eigen taal. Houd er rekening mee dat zelfs de beste machinevertaling niet net zo nauwkeurig is als die van een professionele vertaler. Cisco Systems, Inc. is niet aansprakelijk voor de nauwkeurigheid van deze vertalingen en raadt aan altijd het oorspronkelijke Engelstalige document (link) te raadplegen.

Inhoud

uitgifte

De Firewall Threat Defense (FTD) kon het IP-adres van het upstream-apparaat niet pingen, ondanks dat de firewall de ARP-vermelding voor het upstream-IP-adres kon observeren. De ARP-tabel toonde de verwachte items, wat aangeeft dat de Layer 2-connectiviteit functioneerde, maar het Layer 3-ping-verkeer werd geblokkeerd.

Topologie

Topology

FTD CLI-symptomen

Ping naar het upstream IP-adres faalt:

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

Er is een ARP-vermelding voor het upstream IP-adres:

device# show arp
        NET200 192.0.2.250 0000.5e00.5301 47

Schakel een opname met trace in op de FTD-interface:

device# capture CAPI interface NET200 trace match icmp host 192.0.2.200 host 192.0.2.250

FTD LINA-syslogs tijdens de ping-test:

device# show log | include 192.0.2.250
May 15 2026 09:46:26: %FTD-6-302020: Built outbound ICMP connection for faddr 192.0.2.250/0 gaddr 192.0.2.200/5035 laddr 192.0.2.200/5035 type 8 code 0 Internal-Data0/1:RX[0]
May 15 2026 09:46:26: %FTD-3-313001: Denied ICMP type=0, code=0 from 192.0.2.250 on interface NET200
May 15 2026 09:46:26: %FTD-6-302021: Teardown ICMP connection for faddr 192.0.2.250/0 gaddr 192.0.2.200/5035 laddr 192.0.2.200/5035 type 8 code 0 Internal-Data0/0:RX[0]
...

Packet capture toont ICMP-echo-antwoorden die aankomen:

device# show capture CAPI
10 packets captured
   1: 09:46:26.649456       802.1Q vlan#200 P0 192.0.2.200 > 192.0.2.250 icmp: echo request 
   2: 09:46:26.649883       802.1Q vlan#200 P0 192.0.2.250 > 192.0.2.200 icmp: echo reply 
   3: 09:46:28.642621       802.1Q vlan#200 P0 192.0.2.200 > 192.0.2.250 icmp: echo request 
   4: 09:46:28.643002       802.1Q vlan#200 P0 192.0.2.250 > 192.0.2.200 icmp: echo reply 
...

Packet trace van het ICMP echo antwoord laat zien dat het pakket overeenkomt met een bestaande verbinding zoals verwacht en de output interface is de FTD interface (NP Identity Ifc):

device# show capture CAPI packet-number 2 trace
10 packets captured
   2: 09:46:26.649883       802.1Q vlan#200 P0 192.0.2.250 > 192.0.2.200 icmp: echo reply 
...
Phase: 3
Type: FLOW-LOOKUP
Subtype:      
Result: ALLOW
Elapsed time: 4096 ns
Config:
Additional Information:
Found flow with id 1400, using existing flow
...

Result:
input-interface: NET200(vrfid:0)
input-status: up
input-line-status: up
output-interface: NP Identity Ifc
Action: allow
Time Taken: 28672 ns

Foutopsporing ICMP trace toont aan dat het ICMP echo antwoord wordt geweigerd:

FTD220-5# debug icmp trace
debug icmp trace enabled at level 1

FTD220-5# ping 192.0.2.250
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.0.2.250, timeout is 2 seconds:
ICMP echo request from self:192.0.2.200 to NET200:192.0.2.250 ID=49503 seq=15001 len=72
ICMP echo reply from NET200:192.0.2.250 to self:192.0.2.200 ID=49503 seq=15001 len=72
Denied ICMP type = 0, code = 0 from 192.0.2.250on interface 4
?
...
Success rate is 0 percent (0/5)

Let op: gebruik debugs met voorzichtigheid!

U schakelt de ICMP-debug als volgt uit:

device# no debug icmp trace
debug icmp trace disabled.

milieu

FTD 10.x. Ook andere softwareversies worden getroffen.

resolutie

Het probleem werd opgelost door een ICMP-regelconfiguratie in de platforminstellingen te identificeren en te corrigeren die ping-verkeer weigerde.

De resolutie behelsde de volgende stappen:

Stap 1. ARP-tabelvermeldingen verifiëren

Bevestig dat de ARP-vermeldingen voor het upstream-IP-adres zichtbaar zijn in de ARP-tabel van de firewall, wat aangeeft dat de Layer 2-connectiviteit goed werkt:

device# show arp

Stap 2. Controleer de platforminstellingen voor ICMP-regels

Navigeer naar de configuratie van de platforminstellingen en bekijk het ICMP-regelbeleid dat van invloed kan zijn op ping-verkeer. Zoek specifiek naar regels die ICMP-echo-verzoek-/antwoordpakketten kunnen blokkeren of weigeren.

Stap 3. ICMP-regel voor blokkering identificeren en wijzigen

Zoek de ICMP-regel in de platforminstellingen die is geconfigureerd om ping-verkeer te weigeren.

Platform Settings

In dit voorbeeld staat de ICMP-regel toe dat alleen ICMP-echoverzoeken door de FTD-interface worden geaccepteerd.

FTD CLI-verificatie:

device# show run icmp
icmp unreachable rate-limit 1 burst-size 1
icmp permit any echo NET200

Stap 4. ICMP-regelconfiguratie bijwerken

Wijzig de geïdentificeerde ICMP-regel om ping-verkeer toe te staan of verwijder de blokkeringsconfiguratie die geschikt is voor de netwerkbeveiligingsvereisten en operationele behoeften.

ICMP Policy

De resulterende ICMP-regel:

device# show run icmp
icmp unreachable rate-limit 1 burst-size 1
icmp permit any echo NET200
icmp permit 192.0.2.0 255.255.255.0 echo-reply NET200

Stap 5. Connectiviteit testen

Nadat u de configuratiewijzigingen hebt doorgevoerd, test u de ping-connectiviteit met het upstream-IP-adres om te controleren of het probleem is opgelost en of het ICMP-verkeer nu correct verloopt:

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

Oorzaak

De hoofdoorzaak van dit probleem was een ICMP-regel die was geconfigureerd in de platforminstellingen en die expliciet het ICMP-echo-antwoordverkeer weigerde. Hoewel de firewall de juiste Layer 2-connectiviteit behield (wat blijkt uit de zichtbare ARP-vermeldingen), blokkeerde de ICMP-regel op platformniveau Layer 3 ICMP-antwoordpakketten, waardoor succesvolle ping-bewerkingen naar het upstream IP-adres werden voorkomen. Dit type configuratie kan optreden wanneer beveiligingsbeleid wordt geïmplementeerd om het ICMP-verkeer te beperken, maar kan onbedoeld invloed hebben op legitieme tests en bewaking van netwerkconnectiviteit.