Gebruik de optie BGP "Slow Peer" om problemen met trage peers op te lossen

Inleiding

Dit document beschrijft hoe een langzaam peer probleem met het gebruik van het Protocol van de Rand Gateway (BGP) langzaam peer optie kan worden opgelost, dat een langzaam peer in een BGP update groep identificeert en de langzaam peer uit de update groep permanent of tijdelijk kan verplaatsen.

Achtergrondinformatie

Deze sectie geeft een overzicht van de trage peer optie en het gebruik van update groepen.

Actugroepen

De langzaam peer optie wordt gebruikt in update groepen. Een update groep is een dynamische methode die wordt gebruikt om BGP-peers met hetzelfde uitgaande beleid te groeperen. Het voordeel van de studiegroepen is dat het groepsbeleid wordt gebruikt om berichten één keer op te maken, en dan worden ze herhaald en naar de andere leden van de groep gestuurd. Deze methode is efficiënter dan de noodzaak om BGP-updates voor elk peer afzonderlijk te formatteren.

Wanneer deze methode wordt geïmplementeerd, als het uitgaande beleid verandert, veranderen de peer groepen per update groep. De update groepen worden gevormd per adresfamilie (AF).

Hier is een voorbeeld van twee BGP peers in verschillende update groepen voor AF IPv4 unicast maar met de zelfde update groep voor AF VPNv4:

R2#show ip bgp update-group
BGP version 4 update-group 1, external, Address Family: IPv4 Unicast
  Has 1 member (* indicates the members currently being sent updates):
   10.1.3.4
 
BGP version 4 update-group 2, external, Address Family: IPv4 Unicast
  Has 1 member (* indicates the members currently being sent updates):
   10.1.2.3
 
R2#show ip bgp vpnv4 all update-group
BGP version 4 update-group 1, external, Address Family: VPNv4 Unicast
  Has 2 members (* indicates the members currently being sent updates):
   10.1.2.3         10.1.3.4

De update groep wordt efficiënter naarmate het aantal BGP-peers dat in de update groep is opgenomen, toeneemt. Meestal hebben interne BGP-peers (iBGP-peers) hetzelfde uitgaande beleid. Voor iBGP kan een routereflector (RR) veel iBGP peers hebben; zij zal dus over grote groepen bijgewerkte gegevens beschikken . Edge (PE) routers van providers kunnen veel externe BGP-peers (eBGP) hebben naar de Customer Edge-routers (CE) in één Virtual/Routing Forwarding (VRF). De PE routers kunnen grote update groepen ook voor de peer met CE routers op de VRF interfaces hebben.

Probleem

Een langzaam peer is een peer die niet bij het tarief kan houden waarmee de router BGP update berichten over een lange periode (in de volgorde van minuten) in een update groep genereert. De reden hiervoor kunnen aanhoudende netwerkproblemen zijn. De netwerkredenen kunnen pakketverlies en/of geladen links of doorvoerproblemen met de BGP-sessies zijn. Een BGP-peer kan ook zwaar worden geladen in termen van CPU en kan de TCP-verbinding niet met de gewenste snelheid bedienen.

Langzame peers hebben invloed op de BGP-convergentie van de volledige actualiseringsgroep. Als één BGP peer langzaam is, veroorzaakt het de volledige update groep om te vertragen. Het gevolg is dat ook de andere leden van de groep die de actualisering hebben, een langzamere convergentie zullen hebben. Daarom moet deze kwestie worden opgelost.

U kunt de langzaam peer identificeren en het uit de update groep verplaatsen. Om deze taak te volbrengen, kunt u het uitgaande beleid voor die BGP-peer wijzigen; dit is echter een handmatige taak . U moet eerst de vertragende peer identificeren en dan het uit de update groep verplaatsen. Deze optie kan automatisch worden uitgevoerd, zodat geen gebruikersinterventie vereist is.

Oplossing

Er zijn drie onderdelen voor de functie langzaam peer:

• Detectie van de langzaam werkende peer
  
  
• Verplaatsing van de langzaam peer in een langzame update groep
  
  
• Herstel van de langzaam peer (die het teruggekregen peer terug naar zijn oorspronkelijke update groep verplaatst)

Deze processen worden nader beschreven in de volgende paragrafen.

Detectie

De langzaam peer optie detecteert trage peers in een update groep. Elke update groep heeft een caching wachtrij, waar geformatteerde BGP updates tijdelijk worden opgeslagen vóór de transmissie.

Hier is een voorbeeld van zo'n update groep cache:

R2#show ip bgp replication

                                                                    Current    Next
Index  Members          Leader       MsgFmt    MsgRepl     Csize    Version Version
    1        1        10.1.1.1            0          0    0/100           6/0
    2        3        10.1.2.3            2          6    0/1000          6/0
    3        1        10.1.2.6            3          0    0/100           6/0

De grootte van de cache wordt dynamisch berekend en is afhankelijk van:

• Het aantal peers in de update groep
  
  
• Het geïnstalleerde systeemgeheugen
  
  
• Het type peers in de update groep
  
  
• Het type AF

Het aantal opgemaakte BGP-updates dat op transmissie wacht kan in één update groep opbouwen wanneer één peer (de langzame) de BGP-berichten niet zo snel als de andere leden erkent. Wanneer de cache limiet wordt bereikt, heeft de groep geen quota meer om nieuwe berichten in de rij te zetten. Er kunnen geen nieuwe berichten worden geformatteerd totdat de cache is verminderd (tot sommige berichten worden erkend door de trage peer(s)). Dit verbiedt de BGP peer en staat het niet toe om nieuwe berichten (updates of intrekken) naar de snellere leden van de groep te sturen. Dit vertraagt dus de convergentie van alle leeftijdsgroepen in de actualiseringsgroep.

Om de langzaam peer optie te identificeren verwijst het naar de BGP update timestamps en peer TCP parameters.

De vertraagde detectie van meerdere is standaard uitgeschakeld. Gebruik een van de volgende methoden om een trage detectie door gelijken mogelijk te maken:

• Schakel de optie voor het BGP-proces in (dit kan worden ingesteld via AF/VRF):
  

  bgp slow-peer detection [threshold 
         
         
           ] 
          
   
          
  [no] bgp slow-peer detection 
         

  Opmerking: De drempelwaarde kan tussen 120 en 3.600 seconden liggen en de standaardwaarde is 300 seconden.

• Schakel de optie per peer in:
  

  neighbor {
         
         
           / 
          
            } slow-peer detection [threshold < seconds >] 
           
   
           
  [no] neighbor { 
           
             / 
            
              } slow-peer detection 
             
            
           
         

• Schakel deze optie in via een peer-beleidssjabloon:
  

  slow-peer detection [threshold < seconds >]
  
  [no] slow-peer detection

Wanneer een langzaam peer wordt gedetecteerd, is een vergelijkbaar syslg-bericht afgedrukt:

%BGP-5-SLOWPEER_DETECT: Neighbor IPv4 Unicast 10.1.6.7 has been detected
 as a slow peer.

U kunt deze opdrachten voor de show invoeren om deze trage peers te bekijken:

• overzicht van ip bgp
  
  
• ip bgp buren langzaam tonen
  
  
• toon ip bgp update group langzaam

Hier is een voorbeeld dat opdrachtoutput toont wanneer het trage sleutelwoord wordt gebruikt:

R2#show ip bgp update-group summary slow
Summary for  Update-group 1, Address Family IPv4 Unicast
Summary for  Update-group 2, Address Family IPv4 Unicast
Summary for  Update-group 3, Address Family IPv4 Unicast
Summary for  Update-group 4, Address Family IPv4 Unicast
BGP router identifier 10.1.6.2, local AS number 2
BGP table version is 966013, main routing table version 966013
BGP main update table version 966013
50000 network entries using 6050000 bytes of memory
50000 path entries using 2600000 bytes of memory
5001/5000 BGP path/bestpath attribute entries using 700140 bytes of memory
5000 BGP AS-PATH entries using 183632 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 9533772 total bytes of memory
BGP activity 208847/158847 prefixes, 508006/458006 paths, scan interval 60 secs
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.1.6.7        4     7     165   50309        0    0  100 00:10:35        0

Zoals in de output wordt getoond, is peer 10.1.6.7 een langzaam peer voor de AF IPv4 unicast. De andere AF's vertonen geen trage peers.

Om te controleren of de detectie-timer momenteel draait en de waarde ervan, voert u deze opdracht in:

R2#show ip bgp update-group
BGP version 4 update-group 3, external, Address Family: IPv4 Unicast
  BGP Update version : 116013/0, messages 164 queue 164, not converged
  Private AS number removed from updates to this neighbor
  Update messages formatted 5948, replicated 11589
  Number of NLRIs in the update sent: max 249, min 1
  Minimum time between advertisement runs is 30 seconds
  Slow-peer detection timer (expires in 111 seconds)
  Has 3 members (* indicates the members currently being sent updates):
   10.1.4.5         10.1.5.6         10.1.6.7       

Zoals in de voorbeelduitvoer wordt getoond, is de detectie-timer gestart. De detectie-timer start wanneer de update group cache vol is.

In dit voorbeeld, kunt u zien dat een langzaam peer wordt gedetecteerd, maar het beweegt slechts uit de update groep nadat de langzame peer detectie timer verloopt:

R2#show ip bgp update-group
…
BGP version 4 update-group 3, external, Address Family: IPv4 Unicast
  BGP Update version : 516013/566013, messages 357 queue 357, not converged
  Private AS number removed from updates to this neighbor
  Update messages formatted 27044, replicated 53645
  Number of NLRIs in the update sent: max 249, min 0
  Minimum time between advertisement runs is 30 seconds
  Slow-peer detection timer (expires in 20 seconds)
  Has 3 members (* indicates the members currently being sent updates)
   (1 dynamically detected as slow): 

  *10.1.4.5        *10.1.5.6         10.1.6.7

Identificatie van langzame peers

Als de detectie van langzaam peer niet is ingeschakeld, moet u de vertraagde peer handmatig identificeren. Controleer eerst de tabelversie en de uitvoerrij van de peers in de update groep:

R2#show ip bgp update-group 3 summary
Summary for  Update-group 3, Address Family IPv4 Unicast
BGP router identifier 10.1.6.2, local AS number 2
BGP table version is 552583, main routing table version 552583
BGP main update table version 552583
37870 network entries using 4582270 bytes of memory
37870 path entries using 1969240 bytes of memory
5002/3788 BGP path/bestpath attribute entries using 700280 bytes of memory
5001 BGP AS-PATH entries using 183656 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 7435446 total bytes of memory
BGP activity 158847/108847 prefixes, 295876/258006 paths, scan interval 60 secs
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.1.4.5        4     5      77   26840   516013    0    0 01:07:12        0
10.1.5.6        4     6      69   26833   516013    0    0 01:00:30        0
10.1.6.7        4     7      79   26761   516013    0  194 00:45:42        0

In dit voorbeeld, controleer of de tabelversie (TblVer) van de peers ooit de belangrijkste BGP-tabelversie bevat of altijd achterblijft. Ten tweede, controleer voor een of meer peers met zeer hoge waarden van de uitvoerwachtrij. Dit zijn waarschijnlijk de trage peers.

Wanneer u de vermoedelijke trage BGP peer bekijkt, bekijk dan deze vragen (aan beide kanten van de BGP sessie):

• Hoe lang geleden werd het laatste schrijven uitgevoerd?
  
  
• Zijn de keepaliven in het vuur?
  
  
• Is de uitvoerwachtrij hoog?
  
  
• Is de SRTT/RTTO hoog?
  
  
• Verhoogt het aantal terugboekingen?
  
  
• Zijn er wachtrijen voor het opnieuw verzenden van pakketten?
  
  
• Is het TCP venster erg laag of nul?

Hierna volgt een voorbeeld:

R2#show ip bgp neighbors 10.1.6.7
BGP neighbor is 10.1.6.7,  remote AS 7, external link
 Member of peer-group group3 for session parameters
  BGP version 4, remote router ID 10.1.6.7
  BGP state = Established, up for 00:56:09
  Last read 00:00:43, last write 00:00:17, hold time is 180, keepalive interval
   is 60 seconds
  Keepalives are temporarily in throttle due to closed TCP window
  Neighbor capabilities:
    Route refresh: advertised and received(new)
    Address family IPv4 Unicast:
     advertised and received
  Message statistics
    InQ depth is 0
    OutQ depth is 0    Partial message pending
                         Sent       Rcvd
    Opens:                  5          4
    Notifications:          0          0
    Updates:            29004          0
    Keepalives:             0       1426
    Route Refresh:          0          0
    Total:              30336       1431
  Default minimum time between advertisement runs is 30 seconds
For address family: IPv4 Unicast
  BGP table version 250001, neighbor version 200001/250001
  Output queue size : 410
  Index 3, Offset 0, Mask 0x8
  3 update-group member
  group3 peer-group member
  Inbound soft reconfiguration allowed
  Private AS number removed from updates to this neighbor
  Inbound path policy configured
  Route map for incoming advertisements is eBGP-in
                                 Sent       Rcvd
  Prefix activity:               ----       ----
    Prefixes Current:            2596          0
    Prefixes Total:            102624          0
    Implicit Withdraw:             28          0
    Explicit Withdraw:         100000          0
    Used as bestpath:             n/a          0
    Used as multipath:            n/a          0
                                   Outbound    Inbound
  Local Policy Denied Prefixes:    --------    -------
    Total:                                0          0
  Maximum prefixes allowed 20000
  Threshold for warning message 80%, restart interval 300 min
  Number of NLRIs in the update sent: max 249, min 0
  Last detected as dynamic slow peer: never
 Dynamic slow peer recovered: never
  Oldest update message was formatted: 00:02:24
  Address tracking is enabled, the RIB does have a route to 10.1.6.7
  Connections established 4; dropped 3
  Last reset 00:57:39, due to User reset
  Transport(tcp) path-mtu-discovery is enabled
Connection state is ESTAB, I/O status: 1, unread input bytes: 0       
Connection is ECN Disabled
Mininum incoming TTL 0, Outgoing TTL 1
Local host: 10.1.6.2, Local port: 20298
Foreign host: 10.1.6.7, Foreign port: 179
Connection tableid (VRF): 0
 
Enqueued packets for retransmit: 15, input: 0  mis-ordered: 0 (0 bytes)
Event Timers (current time is 0x4A63D14):
Timer          Starts    Wakeups            Next
Retrans           697         29       0x4A6590C
TimeWait            0          0             0x0
AckHold            64         63             0x0
SendWnd             0          0             0x0
KeepAlive           0          0             0x0
GiveUp              0          0             0x0
PmtuAger          128        127       0x4A64CB7
DeadWait            0          0             0x0
Linger              0          0             0x0
 
iss:  130287252  snduna:  131516888  sndnxt:  131532233     sndwnd:  16384
irs: 1184181084  rcvnxt: 1184182346  rcvwnd:      15123  delrcvwnd:   1261
 
SRTT: 20122 ms, RTTO: 20440 ms, RTV: 318 ms, KRTT: 0 ms
minRTT: 20028 ms, maxRTT: 20796 ms, ACK hold: 200 ms
Status Flags: none
Option Flags: nagle, path mtu capable, higher precendence
 
Datagrams (max data segment is 1460 bytes):
Rcvd: 922 (out of order: 0), with data: 65, total data bytes: 1261
Sent: 1463 (retransmit: 29 fastretransmit: 1),with data: 1391, total
 data bytes: 1245129

Beweging

In dit deel wordt het bewegingsproces beschreven met betrekking tot de trage peer-functie in verschillende scenario's.

Beweging zonder trage peer-functie

Een langzaam peer kan handmatig in een nieuwe update groep worden verplaatst zonder de langzame peer optie.

Voordat de optie langzaam peer beschikbaar was, moest u de langzaam peer identificeren en dan handmatig uit de update groep verplaatsen. Dit wordt voltooid met een verandering in het uitgaande beleid van die BGP-peer. Dit uitgaande beleid moet anders zijn dan elk ander beleid dat wordt gebruikt, aangezien u moet verzekeren dat de trage peer niet naar een andere update groep verhuist die momenteel bestaat (en het probleem naar die update groep verplaatsen). De beste verandering die je kunt toepassen is er een die het beleid niet beïnvloedt. U kunt bijvoorbeeld het Minimale Route Advertisement Interval (MRAI) van de peer (onder de specifieke AF) wijzigen.

Dit is een voorbeeld dat de handmatige beweging van een langzaam peer toont wanneer de functie van langzaam peer niet beschikbaar is:

RR1#debug ip bgp groups 
BGP groups debugging is on

RR1(config)#router bgp 1                                    
RR1(config-router)#address-family vpnv4                           
RR1(config-router-af)#neighbor 10.100.1.3 advertisement-interval 3 
 
BGP-DYN(4): 10.100.1.3 cannot join update-group 1 due to an advertisement-interval
 mismatch
BGP(4): Scheduling withdraws and update-group membership change for 10.100.1.3
BGP(4): Resetting 10.100.1.3's version for its transition out of update-group 1
BGP-DYN(4): 10.100.1.3 cannot join update-group 1 due to an advertisement-interval
 mismatch
BGP-DYN(4): Removing 10.100.1.3 from update-group 1
BGP-DYN(4): 10.100.1.3 cannot join update-group 1 due to an advertisement-interval
 mismatch
BGP-DYN(4): Created update-group 0 from neighbor 10.100.1.3
BGP-DYN(4): Adding 10.100.1.3 to update-group 0

Statische trage peer-beweging

Om één peer van een update groep in een nieuwe update groep te bewegen kunt u het als een statische langzaam peer configureren. Als er meerdere trage peers zijn, dan worden statische trage peers met hetzelfde uitgaande beleid in dezelfde langzaam update groep geplaatst.

Om een langzaam peer statistisch te verplaatsen, kunt u deze met het gebruik van deze opdrachten configureren:

• Statische peer beweging per buurman of per peer-groep inschakelen:
  

  [no] neighbor {
         
         
           / 
          
            } slow-peer split-update-group static 
           
         

• Statische peer-beweging via een peer-beleidssjabloon inschakelen:
  

  [no] slow-peer split-update-group static

Dynamische trage peer-beweging

Langzame peer beweging is standaard uitgeschakeld. Om de langzame peer beweging in te schakelen kunt u deze via een van deze methoden configureren:

• Langzame peer beweging voor het BGP-proces inschakelen:
  

  bgp slow-peer split-update-group dynamic [permanent]
  
  [no] bgp slow-peer split-update-group dynamic

  Opmerking: Dit kan worden ingesteld vanuit de weergave van de adresfamilie/topologie/VRF.

• Lage beweging per peer inschakelen:
  

  neighbor {
         
         
           / 
          
            } slow-peer split-update-group dynamic [permanent] 
           
   
           
  [no] neighbor { 
           
             / 
            
              } slow-peer split-update-group dynamic 
             
            
           
         

• Lage beweging via een peer-beleidssjabloon inschakelen:
  

  slow-peer split-update-group dynamic [permanent]
  
  [no] slow-peer split-update-group dynamic

Opmerking: Het permanente sleutelwoord geeft aan dat de langzaam peer niet automatisch zal herstellen. In dit geval, kunt u de teruggekregen langzaam peer terug naar zijn originele update groep verplaatsen via één van de duidelijke opdrachten.

De statische trage peers en dynamische langzaam peers zijn in de zelfde langzaam peer update groep. In dit voorbeeld kunt u één langzaam peer in een langzaam update groep zien:

R2#show ip bgp update-group
…
BGP version 4 update-group 4, external, Address Family: IPv4 Unicast
  BGP Update version : 0/566013, messages 100 queue 100, not converged
  Slow update group
  Private AS number removed from updates to this neighbor
  Update messages formatted 2497, replicated 0
  Number of NLRIs in the update sent: max 10, min 1
  Minimum time between advertisement runs is 30 seconds
  Has 1 member (* indicates the members currently being sent updates)
   (1 dynamically detected as slow):
  *10.1.6.7

Herstel

Een langzaam peer kan worden hergroepeerd onder zijn originele update groep (die het uitgaande beleid aanpast) wanneer wordt bevestigd dat het niet langer een langzaam peer is (het vangt op). De hersteltimer start wanneer de groep langzaam peer update is geconvergeerd. Als de timer voor het herstel verloopt, wordt de vertragende peer terug naar de reguliere update groep verplaatst.

Opmerking: Om het gedrag te zien dat gerelateerd is aan de detectie/herstel-timer, voert u de opdracht debug ip bgp update events in.

Wanneer een langzaam peer terug naar de originele update groep (dit betekent een herstel) wordt verplaatst, wordt een gelijkaardig syslg bericht afgedrukt:

%BGP-5-SLOWPEER_RECOVER: Slow peer IPv4 Unicast 10.1.6.7 has recovered.

Om te controleren of de timer op dit moment draait en de waarde, voert u deze opdracht in:

R2#show ip bgp update-group
BGP version 4 update-group 1, external, Address Family: IPv4 Unicast
  BGP Update version : 165973/0, messages 0 queue 0, converged
  Route map for outgoing advertisements is dummy
  Update messages formatted 0, replicated 0
  Number of NLRIs in the update sent: max 0, min 0
  Minimum time between advertisement runs is 30 seconds
  Slow-peer recovery timer (expires in 16 seconds)
  Has 1 member (* indicates the members currently being sent updates):
   10.1.1.1

In dit voorbeeld geeft de hersteltimer, met een waarde van 16 seconden, aan dat een mogelijk langzaam peer in 16 seconden terug kan keren naar zijn oorspronkelijke update groep.

In dit voorbeeld, kunt u een peer zien die van de langzame peer status hersteld heeft:

R2#show ip bgp neighbor 10.1.6.7 

BGP neighbor is 10.1.6.7,  remote AS 7, external link
 Member of peer-group group3 for session parameters
  BGP version 4, remote router ID 10.1.6.7
…
 3 update-group member
  group3 peer-group member
…
 Number of NLRIs in the update sent: max 249, min 0
  Last detected as dynamic slow peer: 00:12:49
  Dynamic slow peer recovered: 00:01:57
  Oldest update message was formatted: 00:00:55

De status langzame peer wissen

De status langzaam peer kan met deze opdrachten handmatig worden gewist:

• ip bgp * langzaam
  
  
• heldere ip bgp AF {unicast| multicast] <AS aantal> langzaam
  
  
• helder ip bgp AF {unicast|multicast] peer-group <group-name> langzaam
  
  
• heldere ip bgp <buuradres> langzaam
  
  
• helder bgp AF {unicast|multicast] * langzaam
  
  
• helder bgp AF {unicast|multicast] <AS aantal> langzaam
  
  
• helder bgp AF {unicast|multicast] peer-group <group-name> langzaam
  
  
• helder bgp AF {unicast| multicast] <buuradres> langzaam

Opmerking: Wanneer u deze opdrachten gebruikt, vervangt u AF door de eigenlijke adresfamilie.

Met het gebruik van deze opdrachten, wordt de peer terug verplaatst naar de oorspronkelijke update groep.

Voer de interne opdracht show ip bgp in om de trage detectie- en bewegingsinstellingen van de peer te bekijken:

R2#show ip bgp internal
Time left for bestpath timer: 593 secs
Address-family IPv4 Unicast, Mode : RW
    Table Versions : Current 622091, RIB 622091
    Start time : 00:00:01.168    Time elapsed 01:21:56.740
    First Peer up in : 00:00:07    Exited Read-Only in : 00:02:16
    Done with Install in : 00:02:26    Last Update-done in : never
    0 updates expanded
    Attribute list queue size: 0
    Slow-peer detection is enabled  Threshold is 300 seconds
    Slow-peer split-update-group dynamic is enabled
    BGP Nexthop scan:-
        penalty: 0, Time since last run: never,  Next due in: none
        Max runtime : 0 ms Latest runtime : 0 ms Scan count: 0
    BGP General Scan:-
        Max runtime : 14572 ms Latest runtime : 14572 ms Scan count: 78
    BGP future scanner version: 79
    BGP scanner version: 0

Opmerking: Samengevat is de BGP langzaam peer een eigenschap die een langzaam peer in een BGP update groep detecteert en voor snellere BGP convergentie met de beweging van de langzaam peer uit de update groep toelaat.