Problemen oplossen met intermitterende routeringsprotocolkleppen met EEM en EPC

Inleiding

In dit document wordt beschreven hoe u problemen kunt oplossen met intermitterende routeringsprotocolkleppen en BFD-kleppen in Cisco IOS® XE met EEM en EPC.

Voorwaarden

Vereisten

Het wordt aanbevolen om vertrouwd te zijn met de specifieke kenmerken van Embedded Event Manager (EEM) en Embedded Packet Capture (EPC) voor het platform (en) dat (die) betrokken is (zijn) bij het oplossen van problemen, evenals Wireshark. Daarnaast wordt aanbevolen om vertrouwd te zijn met de basisfuncties voor hello en keepalive voor routeringsprotocollen en bidirectionele forwarding-detectie (BFD).

Gebruikte componenten

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.

Probleemoverzicht

Intermitterende routeringsprotocolkleppen zijn een veel voorkomend probleem in productienetwerken, maar vanwege hun onvoorspelbare aard kunnen ze moeilijk in realtime worden opgelost. EEM biedt de mogelijkheid om de gegevensverzameling te automatiseren door het vastleggen van gegevens te activeren met syslog-tekenreeksen wanneer de flappen optreden. Met EEM en EPC kunnen pakketregistratiegegevens worden verzameld aan beide uiteinden van de nabijheid om mogelijk pakketverlies te isoleren vóór het tijdstip van de klep.

De aard van intermitterende routeringsprotocolkleppen is dat ze altijd te wijten zijn aan een hello of keepalive time-out (tenzij het een duidelijk fysiek probleem is, zoals verbindingskleppen die in de logs zouden verschijnen). Dat is dan ook de logica die in dit document aan de orde komt.

Methodologie voor probleemoplossing

Het belangrijkste om te bepalen wanneer een routeringsprotocolklep optreedt, is of de hello-pakketten of keepalive-pakketten op beide apparaten zijn verzonden en ontvangen op het moment van het probleem. Bij deze methode voor probleemoplossing wordt een continue EPC op een cirkelvormige buffer gebruikt totdat de flap optreedt, waarna EEM de relevante syslog-tekenreeks gebruikt om een reeks opdrachten uit te voeren, waarvan er één de EPC stopt. De circulaire bufferoptie stelt de EPC in staat om nieuwe pakketten te blijven vastleggen terwijl de oudste pakketten in de buffer worden overschreven, wat ervoor zorgt dat de gebeurtenis wordt vastgelegd en de buffer niet vooraf wordt gevuld en gestopt. De pakketregistratiegegevens kunnen vervolgens worden gecorreleerd met de tijdstempel van de flap om te bepalen of de benodigde pakketten vóór het evenement aan beide uiteinden zijn verzonden en ontvangen.

Dit probleem treedt meestal op voor apparaten die een nabijheid vormen over een tussenliggend netwerk, zoals een Internet Service Provider (ISP), maar dezelfde methodologie kan worden toegepast voor elk intermitterend routeringsprotocolklepscenario, ongeacht de specifieke topologiedetails. Hetzelfde kan worden gedaan in gevallen waarin het apparaat van de buur wordt beheerd door een derde partij en niet kan worden geopend. In dergelijke gevallen kan de probleemoplossingsmethode die in dit document wordt beschreven, worden toegepast op slechts één apparaat dat toegankelijk is om te bewijzen of het de vereiste pakketten vóór de flap heeft verzonden en ontvangen. Wanneer dit wordt bevestigd, kunnen de gegevens worden getoond aan de partij die de buur beheert om zo nodig verdere problemen op te lossen.

Configuratieoverzicht

Deze sectie bevat een set configuratiesjablonen die kunnen worden gebruikt om deze geautomatiseerde gegevensvastlegging in te stellen. Wijzig indien nodig de IP-adressen, interfacenamen en bestandsnamen.

ACL-configuratiesjabloon

In de meeste gevallen is het enige verkeer dat afkomstig is van het IP-adres van de interface aan beide uiteinden van een routeringsnabijheid het routeringscontroleverkeer zelf. Als zodanig dekt een ACL die verkeer van zowel het IP-adres van de lokale interface als het IP-adres van het buurland naar elke bestemming toestaat, de vereiste voor elk routeringsprotocol, evenals BFD. Als een extra filter nodig is, kan ook de relevante IP-bestemming op basis van het routeringsprotocol of de BFD-modus worden opgegeven. De ACL-parameters definiëren in de config-modus:

config t

ip access-list extended 

permit ip host  any

permit ip host  any

end

Template EPC-parameters

EPC-parameters worden aangemaakt vanuit de exec-modus met bevoegdheden, niet vanuit de config-modus. Zorg ervoor dat u de platformspecifieke configuratiehandleidingen controleert om te bepalen of er beperkingen zijn met EPC. Maak de parameters voor de gewenste interface en koppel deze aan de ACL om te filteren op het gewenste verkeer:

• monitor capture <EPC name>-interface <interface> beide
• monitor capture <EPC name> access-list <ACL name>
• buffergrootte van monitor capture <EPC name> 5 circulair

Opmerking: op sommige softwareversies is lokaal gegenereerd verkeer niet zichtbaar met een EPC op interfaceniveau. In dergelijke scenario's kunnen de vastlegparameters worden gewijzigd om beide verkeersrichtingen op de CPU vast te leggen:

• monitor capture <EPC name> control-plane beide
• monitor capture <EPC name> access-list <ACL name>
• buffergrootte van monitor capture <EPC name> 5 circulair

Start de EPC zodra deze is geconfigureerd:

• start van monitor capture <EPC name>

De EEM is ingesteld om de opname te stoppen wanneer de flap optreedt.

Om ervoor te zorgen dat pakketten in beide richtingen worden vastgelegd, controleert u de opnamebuffer:

show monitor capture  buffer brief

Opmerking: De katalysatorschakelplatforms (zoals Cat9k en Cat3k) vereisen dat de opname wordt gestopt voordat de buffer kan worden bekeken. Als u wilt bevestigen dat de vastlegging werkt, stopt u de vastlegging met de opdracht monitor capture stop, bekijkt u de buffer en start u deze opnieuw om gegevens te verzamelen.

EEM-configuratiesjabloon

Het belangrijkste doel van de EEM is om de pakketopname te stoppen en samen met de syslog-buffer op te slaan. Extra opdrachten kunnen worden opgenomen om andere factoren te controleren, zoals CPU, interfacedaling of platformspecifiek brongebruik en valtellers. Maak de EEM-applet in de config-modus:

config t
event manager applet  authorization bypass
event syslog pattern "" maxrun 120 ratelimit 100000
action 000 cli command "enable"

action 005 cli command "show clock | append bootflash:.txt"

action 010 cli command "show logging | append bootflash:.txt"

action 015 cli command "show process cpu sorted | append bootflash:.txt"

action 020 cli command "show process cpu history | append bootflash:.txt"

action 025 cli command "show interfaces | append bootflash:.txt"

action 030 cli command "monitor capture  stop"

action 035 cli command "monitor capture  export bootflash:.pcap"

action 040 syslog msg "Saved logs to bootflash:.txt and saved packet capture to bootflash:.pcap"

action 045 cli command "end"

end

Opmerking: op Catalyst-switchingplatforms (zoals Cat9k en Cat3k) is de opdracht om de opname te exporteren iets anders. Wijzig voor deze platforms de CLI-opdracht die wordt gebruikt in actie 035:

action 035 cli command "monitor capture  export location bootflash:.pcap"

De snelheidsbegrenzingswaarde in de EEM is in seconden en geeft aan hoeveel tijd er moet verstrijken voordat de EEM opnieuw kan worden uitgevoerd. In dit voorbeeld is deze ingesteld op 100000 seconden (27,8 uur) om de netwerkbeheerder voldoende tijd te geven om te bepalen of de bestanden zijn voltooid en uit het apparaat te halen voordat het opnieuw wordt uitgevoerd. Als de EEM na deze snelheidsbegrenzingsperiode weer zelfstandig wordt uitgevoerd, worden geen nieuwe pakketregistratiegegevens verzameld, aangezien de EPC handmatig moet worden gestart. Nieuwe uitvoer van de opdracht show wordt echter aan de tekstbestanden toegevoegd.

De EEM kan naar behoefte worden gewijzigd om platformspecifieke pakketdropinformatie te verzamelen en extra functionaliteit te bereiken die voor uw scenario vereist is. 

Problemen met intermitterende routeringsprotocolkleppen oplossen

Voorbeeld - EIGRP

Alle timers zijn ingesteld op de standaardwaarde in dit voorbeeld (5-secondenhello's, 15-secondenwachttijd).

Topologie

De logs op R1 geven aan dat er intermitterende EIGRP-kleppen zijn geweest die meerdere uren van elkaar verwijderd waren:

R1#show logging | i EIGRP
*Jul 16 20:45:08.019: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 192.168.10.2 (Tunnel10) is down: Interface PEER-TERMINATION received
*Jul 16 20:45:12.919: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 192.168.10.2 (Tunnel10) is up: new adjacency
*Jul 17 10:25:42.970: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 192.168.10.2 (Tunnel10) is down: holding time expired
*Jul 17 10:25:59.488: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 192.168.10.2 (Tunnel10) is up: new adjacency
*Jul 17 14:39:02.970: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 192.168.10.2 (Tunnel10) is down: holding time expired
*Jul 17 14:39:16.488: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 192.168.10.2 (Tunnel10) is up: new adjacency

Het pakketverlies kan in beide richtingen zijn; wachttijd verstreken geeft aan dat dit apparaat geen hallo van de peer heeft ontvangen of verwerkt binnen de wachttijd, en Interface PEER-TERMINATION ontvangen geeft aan dat de peer de nabijheid heeft beëindigd omdat het geen hello heeft ontvangen of verwerkt binnen de wachttijd.

Configuratie

1. Configureer de ACL met de IP-adressen van de tunnelinterface, aangezien dit de bron-IP-adressen van de hellos zijn:

R1#conf t
R1(config)#ip access-list extended FLAP_CAPTURE
R1(config-ext-nacl)#permit ip host 192.168.10.1 any
R1(config-ext-nacl)#permit ip host 192.168.10.2 any
R1(config-ext-nacl)#end 

Opmerking: De getoonde configuraties zijn van R1. Hetzelfde gebeurt op R2 voor de relevante interfaces en met gewijzigde bestandsnamen voor de EEM. Als extra specificiteit vereist is, configureert u de ACL met EIGRP multicast-adres 224.0.0.10 als het IP-adres van de bestemming om hellos vast te leggen.

2. Maak de EPC en koppel deze aan de interface en de ACL:

R1#monitor capture CAP interface Tunnel10 both
R1#monitor capture CAP access-list FLAP_CAPTURE
R1#monitor capture CAP buffer size 5 circular

3. Start de EPC en bevestig dat pakketten in beide richtingen worden vastgelegd:

R1#monitor capture CAP start
R1#show monitor capture CAP buffer brief 
 ----------------------------------------------------------------------------
 #   size   timestamp     source             destination      dscp    protocol
 ----------------------------------------------------------------------------
   0   74    0.000000   192.168.10.1     ->  224.0.0.10       48 CS6  EIGRP
   1   74    0.228000   192.168.10.2     ->  224.0.0.10       48 CS6  EIGRP
   2   74    4.480978   192.168.10.2     ->  224.0.0.10       48 CS6  EIGRP
   3   74    4.706024   192.168.10.1     ->  224.0.0.10       48 CS6  EIGRP

4. Configureer de EEM:

R1#conf t
R1(config)#event manager applet R1_EIGRP_FLAP authorization bypass
R1(config-applet)#event syslog pattern "%DUAL-5-NBRCHANGE" maxrun 120 ratelimit 100000
R1(config-applet)#action 000 cli command "enable"
R1(config-applet)#action 005 cli command "show clock | append bootflash:R1_EIGRP_FLAP.txt"
R1(config-applet)#action 010 cli command "show logging | append bootflash:R1_EIGRP_FLAP.txt"
R1(config-applet)#action 015 cli command "show process cpu sorted | append bootflash:R1_EIGRP_FLAP.txt"
R1(config-applet)#action 020 cli command "show process cpu history | append bootflash:R1_EIGRP_FLAP.txt"
R1(config-applet)#action 025 cli command "show interfaces | append bootflash:R1_EIGRP_FLAP.txt"
R1(config-applet)#action 030 cli command "monitor capture CAP stop"
R1(config-applet)#action 035 cli command "monitor capture CAP export bootflash:R1_EIGRP_CAP.pcap"
R1(config-applet)#action 040 syslog msg "Saved logs to bootflash:R1_EIGRP_FLAP.txt and saved packet capture to bootflash:R1_EIGRP_CAP.pcap"
R1(config-applet)#action 045 cli command "end"
R1(config-applet)#end

5. Wacht tot de volgende flap optreedt en kopieer de bestanden van bootflash via de gewenste overdrachtsmethode voor analyse:

R1#show logging

*Jul 17 16:51:47.154: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 192.168.10.2 (Tunnel10) is down: Interface PEER-TERMINATION received
*Jul 17 16:51:48.015: %BUFCAP-6-DISABLE: Capture Point CAP disabled.
*Jul 17 16:51:48.283: %HA_EM-6-LOG: EIGRP_FLAP: Saved logs to bootflash:EIGRP_FLAP.txt and saved packet capture to bootflash:EIGRP_FLAP.pcap
*Jul 17 16:51:51.767: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 192.168.10.2 (Tunnel10) is up: new adjacency
R1#
R1#dir bootflash: | i EIGRP
23      -rw-           147804  Jul 17 2024 16:51:48 +00:00  EIGRP_CAP.pcap
22      -rw-            74450  Jul 17 2024 16:51:47 +00:00  EIGRP_FLAP.txt

• De logboekbuffer op de router geeft aan dat er een EIGRP-flap was en dat de bestanden zijn opgeslagen door de EEM.

analyse

Correleer op dit punt de tijd van de flap in de logbuffer met de pakketopnames die zijn verzameld om te bepalen of de hello-pakketten aan beide uiteinden zijn verzonden en ontvangen toen de flap optrad. Aangezien de ontvangen PEER-TERMINATION-interface werd gezien op R1, betekent dit dat R2 verloren hellos moet hebben gedetecteerd en daarom de wachttijd is verlopen, wat wordt gezien in het logbestand:

*Jul 17 16:51:47.156: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 192.168.10.1 (Tunnel10) is down: holding time expired
*Jul 17 16:51:51.870: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 192.168.10.1 (Tunnel10) is up: new adjacency

Omdat de door R2 gedetecteerde wachttijd is verlopen, moet u bevestigen of er in de 15 seconden vóór de flap in de opname die op R1 is verzameld, hellos zijn verzonden door R1:

• De opname toont hellos van zowel 192.168.10.1 (R1) en 192.168.10.2 (R2) in de 15 seconden voor het PEER-TERMINATION Hello-pakket dat R2 verzendt om 16:51:47 (pakket 513).
• De pakketten 503, 505, 508 en 511 (aangegeven door de groene pijlen) werden in deze periode allemaal door R1 verzonden.

De volgende stap is om te bevestigen of alle hellos verzonden door R1 werden ontvangen door R2 op het moment, dus de vangst verzameld van R2 moet worden gecontroleerd:

• Uit de opname blijkt dat de laatste begroeting die van 192.168.10.1 (R1) werd ontvangen om 16:51:32 was (aangegeven door de groene pijl). Hierna toont de volgende 15 seconden alleen hellos verzonden door R2 (aangegeven door het rode vak). Pakketten 505, 508 en 511 in de opname van R1 worden niet weergegeven in de opname op R2. Dit zorgt ervoor dat R2 de houdtijd van de verlopen timer detecteert en het PEER-TERMINATION hello-pakket verzendt om 16:51:47 (pakket 502).

De conclusie van deze gegevens is dat het pakketverlies zich ergens in het dragernetwerk tussen R1 en R2 bevindt. In dit geval was het verlies in de richting van R1 naar R2. Om verder te onderzoeken, moet de vervoerder worden betrokken om het pad te controleren op druppels.

OSPF

Dezelfde logica kan worden gebruikt om intermitterende OSPF-flappen op te lossen. In dit gedeelte worden de belangrijkste factoren beschreven die het onderscheiden van andere routeringsprotocollen met betrekking tot timers, IP-adresfilters en logberichten. 

• De standaard timers zijn 10-seconden hellos en een 40-seconden dode timer. Bevestig altijd de timers die in uw netwerk worden gebruikt bij het oplossen van problemen met dode timer verlopen flappen.
• Hello-pakketten zijn afkomstig van de IP-adressen van de interface. Als aanvullende ACL-specificiteit nodig is, is het multicast-bestemmingsadres voor OSPF-hellos 224.0.0.5.
• De logboekberichten op de apparaten verschillen enigszins. In tegenstelling tot EIGRP bestaat er geen concept van een bericht van peer-beëindiging met OSPF. Integendeel, het apparaat dat de verlopen dode timer detecteert, registreert dit als de flapreden en vervolgens bevatten de hellos die het verzendt niet langer de router-ID van de peer, waardoor de peer naar de INIT-status gaat. Wanneer de hellos opnieuw worden gedetecteerd, gaat de nabijheid door totdat deze de VOLLEDIGE toestand bereikt. Voorbeeld:

R1 detecteert dode timer verlopen:

R1#show logging | i OSPF
*Jul 30 15:29:14.027: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.30.2 on Tunnel20 from FULL to DOWN, Neighbor Down: Dead timer expired
*Jul 30 15:32:30.278: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.30.2 on Tunnel20 from LOADING to FULL, Loading Done
*Jul 30 16:33:19.841: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.30.2 on Tunnel20 from FULL to DOWN, Neighbor Down: Dead timer expired
*Jul 30 16:48:10.504: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.30.2 on Tunnel20 from LOADING to FULL, Loading Done

R2 toont echter alleen de logboekberichten wanneer OSPF teruggaat naar FULL. Er wordt geen logboekbericht weergegeven wanneer de status wordt gewijzigd in INIT:

R2#show logging | i OSPF    
*Jul 30 16:32:30.279: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.30.1 on Tunnel20 from LOADING to FULL, Loading Done
*Jul 30 16:48:10.506: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.30.1 on Tunnel20 from LOADING to FULL, Loading Done

Gebruik "%OSPF-5-ADJCHG" als syslog-patroon om de EEM op beide apparaten te activeren. Dit zorgt ervoor dat de EEM triggers op beide apparaten, zolang het ging naar beneden en kwam weer omhoog. De geconfigureerde ratelimietwaarde zorgt ervoor dat deze niet twee keer wordt geactiveerd binnen een korte periode wanneer meerdere logs met deze tekenreeks worden gezien. De sleutel is om te bevestigen of er aan beide zijden hellos worden verzonden en ontvangen in de pakketopnames.

BGP

Dezelfde logica kan worden gebruikt om intermitterende BGP-flappen op te lossen. In dit gedeelte worden de belangrijkste factoren beschreven die het onderscheiden van andere routeringsprotocollen met betrekking tot timers, IP-adresfilters en logberichten.  

• De standaardtimers zijn 60-seconden keepalives en een 180-seconden wachttijd. Bevestig altijd de timers die in gebruik zijn in uw netwerk bij het oplossen van problemen wachttijd verlopen flappen.
• Keepalive-pakketten worden unicast verzonden tussen de IP-adressen van de buren naar TCP-bestemmingspoort 179. Als extra ACL-specificiteit nodig is, staat u TCP-verkeer toe van de bron-IP-adressen naar de bestemming TCP-poort 179.
• De logberichten voor BGP zien er op beide apparaten hetzelfde uit, maar het apparaat dat de wachttijd detecteert, vervalt en laat zien dat het de melding naar de buurman heeft verzonden, terwijl de andere aangeeft dat het het meldingsbericht heeft ontvangen. Voorbeeld:

R1 detecteert de verstreken wachttijd en stuurt de melding naar R2:

R1#show logging | i BGP
*Jul 30 17:49:23.730: %BGP-3-NOTIFICATION: sent to neighbor 192.168.30.2 4/0 (hold time expired) 0 bytes 
*Jul 30 17:49:23.731: %BGP-5-NBR_RESET: Neighbor 192.168.30.2 reset (BGP Notification sent)
*Jul 30 17:49:23.732: %BGP-5-ADJCHANGE: neighbor 192.168.30.2 Down BGP Notification sent
*Jul 30 17:49:23.732: %BGP_SESSION-5-ADJCHANGE: neighbor 192.168.30.2 IPv4 Unicast topology base removed from session  BGP Notification sent

R2 ontvangt de melding van R1 omdat de door R1 gedetecteerde wachttijd is verlopen:

R2#show logging | i BGP
*Jul 30 17:49:23.741: %BGP-3-NOTIFICATION: received from neighbor 192.168.30.1 4/0 (hold time expired) 0 bytes 
*Jul 30 17:49:23.741: %BGP-5-NBR_RESET: Neighbor 192.168.30.1 reset (BGP Notification received)
*Jul 30 17:49:23.749: %BGP-5-ADJCHANGE: neighbor 192.168.30.1 Down BGP Notification received
*Jul 30 17:49:23.749: %BGP_SESSION-5-ADJCHANGE: neighbor 192.168.30.1 IPv4 Unicast topology base removed from session  BGP Notification received

Als u de EEM voor een BGP-flap wilt activeren, gebruikt u "%BGP_SESSION-5-ADJCHANGE" als syslog-patroon. Elk van de andere "%BGP" syslog berichten die ook worden geregistreerd na de flap kan worden gebruikt om de EEM te activeren ook.

Problemen met intermitterende BFD-kleppen oplossen

Dezelfde methodologie kan worden toegepast op het oplossen van problemen met intermitterende BFD-kleppen, met enkele kleine verschillen die van toepassing zijn op de analyse. Deze sectie behandelt enkele basisfuncties van BFD en geeft een voorbeeld van hoe u EEM en EPC kunt gebruiken om problemen op te lossen. Raadpleeg Bidirectionele forwarding-detectie oplossen in Cisco IOS XE voor meer gedetailleerde informatie over BFD-probleemoplossing.

In dit voorbeeld zijn de BFD-timers ingesteld op 300ms met een vermenigvuldiger van 3, wat betekent dat echos elke 300ms worden verzonden en een echofout wordt gedetecteerd wanneer 3 echopakketten op een rij niet worden geretourneerd (gelijk aan een wachttijd van 900ms). 

Topologie

Voorbeeld - BFD-echomodus

In de BFD Echo Mode (de standaardmodus) worden de BFD-echopakketten verzonden met de lokale IP-interface als bron en bestemming. Hierdoor kan de buur het pakket verwerken in het gegevensvlak en het terugsturen naar het bronapparaat. Elke BFD echo wordt verzonden met een echo-ID in de BFD Echo Message header. Deze kunnen worden gebruikt om te bepalen of een verzonden BFD-echopakket is terugontvangen, omdat er twee keer een bepaald BFD-echopakket moet voorkomen als het inderdaad door de buurman is geretourneerd. De BFD-besturingspakketten, die worden gebruikt om de status van de BFD-sessie te regelen, worden unicast verzonden tussen de IP-adressen van de interface.

De logboeken van R1 geven aan dat de BFD-nabijheid meerdere keren is gedaald als gevolg van ECHO FAILURE, wat betekent dat R1 tijdens die intervallen 3 van zijn eigen echopakketten niet van R2 heeft ontvangen of verwerkt.

R1#show logging | i BFD
*Jul 18 13:41:09.007: %BFDFSM-6-BFD_SESS_DOWN: BFD-SYSLOG: BFD session ld:4097 handle:1,is going Down Reason: ECHO FAILURE
*Jul 18 13:41:09.009: %BGP-5-NBR_RESET: Neighbor 192.168.30.2 reset (BFD adjacency down)
*Jul 18 13:41:09.010: %BGP-5-ADJCHANGE: neighbor 192.168.30.2 Down BFD adjacency down
*Jul 18 13:41:09.010: %BGP_SESSION-5-ADJCHANGE: neighbor 192.168.30.2 IPv4 Unicast topology base removed from session  BFD adjacency down
*Jul 18 13:41:09.010: %BFD-6-BFD_SESS_DESTROYED: BFD-SYSLOG: bfd_session_destroyed,  ld:4097 neigh proc:BGP, handle:1 active
*Jul 18 13:41:13.335: %BFDFSM-6-BFD_SESS_UP: BFD-SYSLOG: BFD session ld:4097 handle:1 is going UP
*Jul 18 13:41:18.576: %BFD-6-BFD_SESS_CREATED: BFD-SYSLOG: bfd_session_created, neigh 192.168.30.2 proc:BGP, idb:Tunnel30 handle:1 act
*Jul 18 13:41:19.351: %BFDFSM-6-BFD_SESS_UP: BFD-SYSLOG: BFD session ld:4097 handle:1 is going UP
*Jul 18 15:44:08.360: %BFDFSM-6-BFD_SESS_DOWN: BFD-SYSLOG: BFD session ld:4097 handle:1,is going Down Reason: ECHO FAILURE
*Jul 18 15:44:08.362: %BGP-5-NBR_RESET: Neighbor 192.168.30.2 reset (BFD adjacency down)
*Jul 18 15:44:08.363: %BGP-5-ADJCHANGE: neighbor 192.168.30.2 Down BFD adjacency down
*Jul 18 15:44:08.363: %BGP_SESSION-5-ADJCHANGE: neighbor 192.168.30.2 IPv4 Unicast topology base removed from session  BFD adjacency down
*Jul 18 15:44:08.363: %BFD-6-BFD_SESS_DESTROYED: BFD-SYSLOG: bfd_session_destroyed,  ld:4097 neigh proc:BGP, handle:1 active
*Jul 18 15:44:14.416: %BFDFSM-6-BFD_SESS_UP: BFD-SYSLOG: BFD session ld:4097 handle:1 is going UP
*Jul 18 15:44:14.418: %BFD-6-BFD_SESS_DESTROYED: BFD-SYSLOG: bfd_session_destroyed,  ld:4097 neigh proc:CEF, handle:1 active
*Jul 18 15:44:18.315: %BFD-6-BFD_SESS_CREATED: BFD-SYSLOG: bfd_session_created, neigh 192.168.30.2 proc:BGP, idb:Tunnel30 handle:2 act

Configuratie

1. Configureer de ACL met de IP-adressen van de tunnelinterface, aangezien dit de bron-IP-adressen van de BFD-echopakketten en besturingspakketten zijn:

R1#conf t
R1(config)#ip access-list extended FLAP_CAPTURE
R1(config-ext-nacl)#permit ip host 192.168.30.1 any
R1(config-ext-nacl)#permit ip host 192.168.30.2 any

Opmerking: De getoonde configuraties zijn van R1. Hetzelfde gebeurt op R2 voor de relevante interfaces en met gewijzigde bestandsnamen voor de EEM. Als extra specificiteit vereist is, configureert u de ACL voor UDP met bestemmingspoorten 3785 (echopakketten) en 3784 (controlepakketten).

2. Maak de EPC en koppel deze aan de interface en de ACL:

R1#monitor capture CAP interface Tunnel30 both
R1#monitor capture CAP access-list FLAP_CAPTURE
R1#monitor capture CAP buffer size 5 circular

3. Start de EPC en bevestig dat pakketten in beide richtingen worden vastgelegd:

R1#monitor capture CAP start 
R1#show monitor capture CAP buff brief 
 ----------------------------------------------------------------------------
 #   size   timestamp     source             destination      dscp    protocol
 ----------------------------------------------------------------------------
   0   54    0.000000   192.168.30.2     ->  192.168.30.2     48 CS6  UDP
   1   54    0.000000   192.168.30.2     ->  192.168.30.2     48 CS6  UDP
   2   54    0.005005   192.168.30.1     ->  192.168.30.1     48 CS6  UDP
   3   54    0.005997   192.168.30.1     ->  192.168.30.1     48 CS6  UDP

4. Configureer de EEM:

R1#conf t
R1(config)#event manager applet R1_BFD_FLAP authorization bypass
R1(config-applet)#event syslog pattern "%BFDFSM-6-BFD_SESS_DOWN" maxrun 120 ratelimit 100000
R1(config-applet)#action 000 cli command "enable"
R1(config-applet)#action 005 cli command "show clock | append bootflash:R1_BFD_FLAP.txt"
R1(config-applet)#action 010 cli command "show logging | append bootflash:R1_BFD_FLAP.txt"
R1(config-applet)#action 015 cli command "show process cpu sorted | append bootflash:R1_BFD_FLAP.txt"
R1(config-applet)#action 020 cli command "show process cpu history | append bootflash:R1_BFD_FLAP.txt"
R1(config-applet)#action 025 cli command "show interfaces | append bootflash:R1_BFD_FLAP.txt"
R1(config-applet)#action 030 cli command "monitor capture CAP stop"
R1(config-applet)#action 035 cli command "monitor capture CAP export bootflash:R1_BFD_CAP.pcap"
R1(config-applet)#action 040 syslog msg "Saved logs to bootflash:R1_BFD_FLAP.txt and saved packet capture to bootflash:R1_BFD_CAP.pcap"
R1(config-applet)#action 045 cli command "end"
R1(config-applet)#end

5. Wacht tot de volgende flap optreedt en kopieer de bestanden van bootflash via de gewenste overdrachtsmethode voor analyse:

R1#show logging

*Jul 18 19:09:47.482: %BFDFSM-6-BFD_SESS_DOWN: BFD-SYSLOG: BFD session ld:4097 handle:1,is going Down Reason: ECHO FAILURE
*Jul 18 19:09:47.483: %BGP-5-NBR_RESET: Neighbor 192.168.30.2 reset (BFD adjacency down)
*Jul 18 19:09:47.487: %BGP-5-ADJCHANGE: neighbor 192.168.30.2 Down BFD adjacency down
*Jul 18 19:09:47.487: %BGP_SESSION-5-ADJCHANGE: neighbor 192.168.30.2 IPv4 Unicast topology base removed from session  BFD adjacency down
*Jul 18 19:09:47.487: %BFD-6-BFD_SESS_DESTROYED: BFD-SYSLOG: bfd_session_destroyed,  ld:4097 neigh proc:BGP, handle:1 active
*Jul 18 19:09:48.191: %BUFCAP-6-DISABLE: Capture Point CAP disabled.
*Jul 18 19:09:48.668: %HA_EM-6-LOG: R1_BFD_FLAP: Saved logs to bootflash:R1_BFD_FLAP.txt and saved packet capture to bootflash:R1_BFD_CAP.pcap
*Jul 18 19:09:50.165: %BFDFSM-6-BFD_SESS_UP: BFD-SYSLOG: BFD session ld:4097 handle:1 is going UP
*Jul 18 19:09:54.386: %BFD-6-BFD_SESS_CREATED: BFD-SYSLOG: bfd_session_created, neigh 192.168.30.2 proc:BGP, idb:Tunnel30 handle:1 act
*Jul 18 19:09:54.386: %BGP-5-ADJCHANGE: neighbor 192.168.30.2 Up 
*Jul 18 19:09:55.178: %BFDFSM-6-BFD_SESS_UP: BFD-SYSLOG: BFD session ld:4097 handle:1 is going UP
R1#
R1#dir | i BFD
25      -rw-          1591803  Jul 18 2024 19:09:48 +00:00  R1_BFD_CAP.pcap
24      -rw-            84949  Jul 18 2024 19:09:48 +00:00  R1_BFD_FLAP.txt

• De logbuffer geeft aan dat er om 19:09:47 een BFD-flap was en dat de bestanden zijn opgeslagen door de EEM.

analyse

Correleer op dit moment de tijd van de flap in de logbuffer met de pakketopnames die zijn verzameld om te bepalen of de BFD-echo's aan beide uiteinden zijn verzonden en ontvangen toen het probleem zich voordeed. Aangezien de reden voor de flap op R1 ECHO FAILURE is, betekent dit dat het ook een controlepakket naar R2 zou hebben gestuurd om de BFD-sessie te beëindigen, en dit wordt weerspiegeld in het logbestand dat is verzameld uit R2, waar de BFD down reden RX DOWN wordt gezien:

*Jul 18 19:09:47.468: %BFDFSM-6-BFD_SESS_DOWN: BFD-SYSLOG: BFD session ld:4098 handle:2,is going Down Reason: RX DOWN
*Jul 18 19:09:47.470: %BGP-5-NBR_RESET: Neighbor 192.168.30.1 reset (BFD adjacency down)
*Jul 18 19:09:47.471: %BGP-5-ADJCHANGE: neighbor 192.168.30.1 Down BFD adjacency down
*Jul 18 19:09:47.471: %BGP_SESSION-5-ADJCHANGE: neighbor 192.168.30.1 IPv4 Unicast topology base removed from session  BFD adjacency down
*Jul 18 19:09:47.471: %BFD-6-BFD_SESS_DESTROYED: BFD-SYSLOG: bfd_session_destroyed,  ld:4098 neigh proc:BGP, handle:2 active

Omdat R1 een ECHO-FOUT heeft gedetecteerd, controleert u de pakketopname die op R1 is verzameld om te zien of deze BFD-echo's heeft verzonden en ontvangen in de 900ms vóór de flap.

• De opname laat zien dat R1 actief BFD-echopakketten heeft verzonden tot aan het moment van de flap, maar ze werden niet geretourneerd door R2, dus R1 stuurt een controlepakket om de sessie te beëindigen om 19:09:47.468. 
• Dit blijkt uit het feit dat pakketten 137, 138 en 140 (aangegeven door de groene pijlen) slechts één keer in de opname worden gezien, die kan worden bepaald aan de hand van de BFD Echo ID's (in het rode vak). Als de echo's waren geretourneerd, zou er een tweede kopie zijn van elk van die pakketten met dezelfde BFD-echo-ID. Het veld IP-identificatie in de IP-header (niet afgebeeld hier) kan ook worden gebruikt om dit te verifiëren.
• Deze opname laat ook zien dat er geen BFD-echo's zijn ontvangen van R2 na pakket 136, wat een andere indicatie is van pakketverlies in de richting van R2 naar R1.

De volgende stap is om te bevestigen of alle BFD-echopakketten die door R1 zijn verzonden, door R2 zijn ontvangen en geretourneerd, dus de opname die uit R2 is verzameld, moet worden gecontroleerd:

•  Deze opname laat zien dat alle BFD-echo's die door R1 zijn verzonden, zijn ontvangen en geretourneerd door R2 (aangegeven met groene pijlen); Pakketten 107 en 108 zijn dezelfde BFD-echo, pakketten 111 en 112 zijn dezelfde BFD-echo en pakketten 116 en 117 zijn dezelfde BFD-echo.
• Deze opname laat ook zien dat R2 actief echopakketten heeft verzonden (aangegeven met rode vakken) die niet worden gezien in de opname op R1, wat verder wijst op pakketverlies tussen de apparaten in de richting van R2 naar R1.

De conclusie van deze gegevens is dat het pakketverlies zich ergens in het dragernetwerk tussen R1 en R2 bevindt, en al het bewijs op dit punt geeft aan dat de verliesrichting van R2 naar R1 is. Om verder te onderzoeken, moet de vervoerder worden betrokken om het pad te controleren op druppels.

Asynchrone BFD-modus

Dezelfde methode kan worden toegepast wanneer de asynchrone BFD-modus in gebruik is (echofunctie uitgeschakeld) en de EEM- en EPC-configuratie hetzelfde kunnen worden gehouden. Het verschil in asynchrone modus is dat de apparaten unicast BFD-besturingspakketten naar elkaar sturen als keepalives, analoog aan een typische routing-protocolnabijheid. Dit betekent dat alleen UDP-poort 3784-pakketten worden verzonden. In dit scenario blijft BFD in de opwaartse toestand zolang een BFD-pakket binnen het vereiste interval van de buur wordt ontvangen. Wanneer dit niet gebeurt, is de reden voor de storing DETECT TIMER VERLOPEN en verzendt de router een controlepakket naar de peer om de sessie neer te halen.

Om de opnames te analyseren op het apparaat dat de storing heeft gedetecteerd, zoekt u naar de unicast BFD-pakketten die u van de peer hebt ontvangen in de tijd vlak voordat u de flap opent. Als het TX-interval bijvoorbeeld is ingesteld op 300ms met een vermenigvuldiger van 3, dan geeft dit aan dat er mogelijk pakketverlies is als er geen BFD-pakketten zijn ontvangen in de 900ms voorafgaand aan de flap. In de opname verzameld van de buurman via de EEM, controleer dit zelfde tijdvenster; als de pakketten tijdens die tijd zijn verzonden, bevestigt dit dat er ergens verlies is tussen de apparaten.