BGP RF-schaaloverwegingen en KPI-bewaking

Inleiding

In dit document worden de belangrijkste factoren beschreven die bijdragen aan de maximale schaal die een BGP-routereflectoren (RR) (Border Gateway Protocol) kunnen bereiken en bieden zij richtlijnen voor BGP RR-prestatiebewaking.

HW/SW-platformselectie

Een grootschalige BGP-RR bevindt zich doorgaans niet in het doorsturen van pakketten die services van een internetserviceprovider bevatten. Daarom zijn de hardwarevereisten voor een BGP RF en routers die voornamelijk pakketten doorsturen in het gegevenspad verschillend. Standaardrouters zijn gebouwd met een krachtig gegevenspad-doorsturen element en een relatief gematigd controle-pad element. Een BGP RR voert al zijn taken uit in een controleplan.
Binnen de Cisco IOS® XR-reeks producten kunt u kiezen uit drie smaken van HW/SW-platforms voor een BGP RR-rol:

Fysieke Cisco IOS XR-router	Cisco IOS XRv 9000 applicatie	Cisco IOS XRv 9000 router (ook bekend als XRv9k)
Matige capaciteit van het bedieningsvliegtuig (meestal tussen 2 en 6 CPU-kernen toegewezen aan RP XR VM) Ongebruikte gegevenspadcapaciteit	Capaciteit van hoog bedieningsvliegtuig (op een Cisco UCS M5-gebaseerd apparaat zijn 36 CPU-kernen bestemd voor RP XR VM) Gelijke verdeling tussen gegevenspad en regelpadcapaciteit. XRv9k image draait op barebone voor maximale prestaties	Aanpasbare capaciteit van het bedieningsvliegtuig Gelijke splitsing tussen gegevenspad en regelpad bij gebruik van BGP RR-afbeelding. Een extra laag virtualisatie heeft invloed op de prestaties.

Ten tijde van het schrijven van dit artikel is de XRv9k-applicatie de optimale platformkeuze voor BGP RR, omdat deze de hoogste besturingsplantecapaciteit biedt met maximale prestaties.

Overwegingen over schaal en prestaties

De ondersteunde schaal van data-plane entiteiten is relatief eenvoudig uit te drukken omdat de prestaties van het data-path element zelden afhankelijk is van de schaal. Een TCAM-zoekopdracht neemt bijvoorbeeld dezelfde tijd in, ongeacht het aantal actieve TCAM-vermeldingen.
De ondersteunde schaal van besturings-vlakke entiteiten is vaak veel complexer omdat de schaal en de prestaties onderling verbonden zijn. Overweeg een BGP RF met 1M routes. Het werk dat een BGP-proces moet uitvoeren om deze BGP-tabel te onderhouden, hangt af van:

1. Hoeveel BGP-peers zijn actief?
2. Welke adresfamilies zijn actief?
3. Hoe worden ze verdeeld over updategroepen?
4. De complexiteit van RPL’s (routebeleid)
5. Frequentie van updates (inkomende updates en ook uitgaande updates - advertentieinterval).
6. TCP MSS, Interface/Path MTU - afstemming van dit zal helpen bij betere prestaties 
7. Bij dual-RP is NSR ingeschakeld
8. Alle bekende slow-peers die niet in een aparte update-groep zitten
9. Waarde Nexthop trigger-vertraging

Aantal BGP-peers

Het aantal BGP-peers is meestal het eerste en helaas vaak het enige dat in gedachten komt bij het overwegen van de BGP-schaal. Hoewel de ondersteunde BGP-schaal niet kan worden weergegeven zonder het aantal BGP-peers te vermelden, is dit niet de belangrijkste factor. Veel andere aspecten zijn even relevant.

Adresfamilies

Het type adresfamilie (AF) is een belangrijke factor in BGP-prestatieoverwegingen, omdat het bij typische implementaties invloed heeft op de omvang van één route. Het aantal IPv4-routes dat in één TCP-segment kan worden ingepakt, is aanzienlijk hoger dan het aantal VPNv4-routes. Om dezelfde schaal van BGP-tabelwijzigingen mogelijk te maken, heeft een IPv4 BGP-RR minder werk te doen dan een VPNv4 BGP-RR. In implementaties waar een aanzienlijk aantal gemeenschappen aan elke route wordt toegevoegd, wordt het verschil tussen AF's minder groot, maar de omvang van een enkele route is dan nog groter en vereist aandacht. 

Aantal updategroepen

Het BGP-proces bereidt één update voor alle leden van dezelfde updategroep voor. Vervolgens splitst TCP-proces de updategegevens in een vereist aantal TCP-segmenten (afhankelijk van TCP MSS) naar elk lid van de updategroep. U kunt de actieve updategroepen en hun leden zien door het show bgp update-group bevel te gebruiken. U kunt beïnvloeden welke en hoeveel peers lid zijn van een updategroep door een gemeenschappelijk uitgaand beleid te creëren voor een groep peers die u in dezelfde updategroep wilt zijn. Een enkele update die door de BGP RR naar een groot aantal BGP RR-clients wordt verzonden, kan een burst van TCP-ACK's genereren die in LPTS-component (Local Packet Transport Service) van Cisco IOS XR-routers kan worden gedropt.

Complexiteit van RPL’s (routebeleid)

De complexiteit van het routebeleid dat door BGP wordt gebruikt, heeft invloed op de prestaties van het BGP-proces. Elke ontvangen of verzonden route moet worden beoordeeld aan de hand van het geconfigureerde routebeleid. Een zeer lang beleid vereist dat veel CPU-cycli aan deze actie worden besteed. Een routebeleid dat een reguliere expressie omvat, is met name zwaar bij de verwerking. Een reguliere expressie helpt u het routebeleid uit te drukken in een kleiner aantal regels, maar vereist meer CPU-cycli tijdens het verwerken dan het equivalente routebeleid dat geen reguliere expressie gebruikt. 

Frequentie van de bijwerkingen

De frequentie van updates heeft een belangrijke invloed op de BGP-schaal. Het aantal updates is vaak moeilijk te voorspellen. U kunt de frequentie van updates beïnvloeden door de opdracht "advertentieinterval" te gebruiken, die het minimuminterval instelt tussen het verzenden van (BGP)-routingupdates. De standaardwaarde voor iBGP-peers is 0 seconden en 30 seconden voor eBGP-peers is het 30 seconden.

TCP/MSS en interface/pad-MTU

Het verdelen van een update in vele segmenten van TCP kan veel spanning op TCP procesmiddelen in een high-scale en high-update frequentiemilieu zetten. Een groter pad MTU en grotere TCP MSS zijn beter voor BGP en TCP prestaties.


NSR op dual-RP routers

NSR is een geweldige functie voor redundantie, maar het heeft wel invloed op BGP-prestaties. Op Cisco IOS XR-routers ontvangen beide RP’s tegelijkertijd elke BGP-update rechtstreeks van de NPU op de indringerlijnkaart, wat betekent dat de Active RP geen tijd hoeft te besteden aan het repliceren van de update naar de Standby RP. Elke update die door de Active RP wordt gegenereerd, moet echter worden verzonden naar de Standby RP en van daaruit naar de BGP peer. Dit maakt het mogelijk dat de Standby RP altijd up-to-date is op de volgorde en de bevestigingsnummers, maar heeft wel invloed op de algemene BGP-prestaties. Dit is waarom het wordt geadviseerd dat een BGP RR een single-RP router is.

Langzame peers

Een slow peer kan de updates voor alle leden van de updategroep vertragen omdat het BGP-proces de update in het geheugen moet houden tot alle peers het hebben bevestigd. Als u weet dat sommige peers veel langzamer zijn (bijvoorbeeld routers in een legacy-deel van het netwerk), scheidt u ze van tevoren in een updategroep. Standaard rapporteert Cisco IOS XR een trage peer via een syslogbericht. U kunt statische langzame peers (die nooit de updategroep met anderen delen) tot stand brengen of het dynamische langzame peer gedrag verfijnen door het BGP slow-peer configuratiebevel in globale of per-buur configuratiewijze te gebruiken. Een goede verdere informatie hierover kan worden gevonden in Probleemoplossing voor langzame BGP-convergentie als gevolg van suboptimaal routebeleid op IOS-XR op het Cisco xrdocs.io-portal. 

Nexus trigger-vertraging

Als meerdere BGP next-hops veranderen in een kort tijdsinterval en de kritische nexthop trigger-vertraging waarde van nul is geconfigureerd in een adresfamilie (AF) met een groot aantal routes, moet een volledige wandeling van de AF worden uitgevoerd op elke volgende-hop verandering gebeurtenis. Herhaalde wandelingen van die AF verhogen de convergentietijd in adresfamilies met lagere kritische nexthop trigger-vertragingwaarden. U kunt de volgende-hop trigger-vertraging waarden zien door de "show bgp alle nexthops" opdracht.

Voorbeeld van gevalideerde multidimensionale BGP RR-schaal

Multidimensionale schaalresultaten, met name voor de eigenschappen van het regelvlak, zijn sterk afhankelijk van de specifieke testomgeving. De testresultaten kunnen aanzienlijk variëren als bepaalde parameters worden gewijzigd.

Parameter	Waarde	Waarde
Platform	XRv9k-applicatie (UCS M5-gebaseerd)	ASR 9902 router
IOS XR-release	7.5.2 + paraplu SMU voor Cisco bug-id CSCwf09600 . (De onderdelen van deze paraplu-SMU zijn geïntegreerd in Cisco IOS XR-release 7.9.2 en hoger)	7.11.2
Gelijken	VPNv4 eBGP: 2500 VPNv4 iBGP: 1700	VPNv4 iBGP: 2000
BGP-routers	Per sessie: 200 Totaal: 400k Paden per route: 1	Per sessie: 750 VPNv4: 1,36M VPNv6: 150k IPv4: 950k IPv6: 200k Totaal: ~2,6M Paden per route: 1
IGP-routers	10k (ISIS)	10k (ISIS)
BGP-updategroepen	1	1
BGP-timers	standaard	standaard
LPTS BGP-bekend aantal policers	50,000	25,000
TCP-netwerkdraadconfiguratie	16 16	16 16
BGP-verzendbuffergrootte	standaard	standaard
Samenvatting van kernprestatie-indicatoren (KPI)	Testcase met hoogste input en output pakketsnelheid: Invoer: 49,4 kpps Output: 95kpps ==> LPTS druppels (policer op 50kpps) ==> Geen druppels in NetIO-clients ==> Max. grootte XIPC-wachtrij (BGP): 1362 ==> Max. grootte XIPC-wachtrij (TCP): 1248	Testcase met hoogste invoerpakketsnelheid: Invoer: 16030 Uitvoer: 31 pkts/s ==> Geen druppels in LPTS of NetIO-clients ==> Max. grootte XIPC-wachtrij (BGP): 378 ==> Max. grootte XIPC-wachtrij (TCP): 1021 Testcase met hoogste pakketuitvoersnelheid: Invoer: 12172 Uitvoer: 23465 pkts/s ==> Geen druppels in LPTS of NetIO-clients ==> Max. grootte XIPC-wachtrij (BGP): 109 ==> Max. grootte XIPC-wachtrij (TCP): 1518

Ontwerpoverwegingen

Er zijn twee benaderingen voor BGP RR-plaatsing in het netwerk:

1. Gecentraliseerd/plat BGP RF-ontwerp.
2. Gedistribueerd/hiërarchisch BGP RR-ontwerp.

In een gecentraliseerd/vlak ontwerp, alle BGP RR-clients in het netwerk maken BGP peering met een set (meestal een paar) BGP RR-apparaten die exact dezelfde informatie bevatten. Deze benadering is eenvoudig uit te voeren en werkt goed in netwerken op kleine tot middelgrote schaal. Elke wijziging in de BGP-tabel wordt snel doorgevoerd naar alle BGP RR-clients. Naarmate het aantal BGP RR-clients toeneemt, kan het ontwerp een schaallimiet bereiken wanneer het aantal TCP-verbindingen op de BGP RR-apparaten zodanig toeneemt dat hun prestaties worden beïnvloed.


In een gedistribueerd/hiërarchisch ontwerp wordt het netwerk in verschillende regio's verdeeld. Alle routers in een regio maken BGP-peiling met een set (meestal een paar) BGP RR-apparaten die exact dezelfde informatie bevatten. Deze BGP RR-apparaten fungeren als BGP RR-clients voor een andere set (meestal een paar) BGP RR-apparaten. Deze ontwerpbenadering zorgt voor een eenvoudige netwerkuitbreiding, terwijl het aantal TCP-verbindingen op elke BGP RR onder een bepaalde limiet blijft.
Een andere ontwerpoverweging is het afstemmen van het bereik van ontvangers van BGP-updates. Afhankelijk van de VRF-distributie onder BGP RR-clients is het de moeite waard om de RT Constrained Route Distribution te overwegen. Als alle BGP RR-clients interfaces in dezelfde VRF hebben, levert RT Constrained Route Distribution niet veel voordelen op. Als VRF’s echter schaars verdeeld zijn over alle BGP RR-clients, vermindert het gebruik van RT Constrained Route Distribution aanzienlijkƒ de belasting op het bgp-proces op de BGP RR.

Monitor BGP-toetsprestatie-indicatoren (KPI)

De controle van de Belangrijkste Prestatie Indicatoren van BGP RR (KPI) is belangrijk voor het verzekeren van juiste netwerkverrichting. 


Een significante verandering in de netwerktopologie (bijvoorbeeld een belangrijke DWDM-linkflap) kan leiden tot routingupdates die buitensporig verkeer naar en/of van de BGP-router genereren. Significant verkeer dat de BGP RR raakt, heeft doorgaans de volgende kenmerken:

1. Updates van BGP-peers.
2. TCP-ACK’s gegenereerd door de BGP-peers, in antwoord op updates verzonden door BGP R en vice versa

In dit gedeelte van het document wordt de KPI uitgelegd die op een typische BGP RR moet worden bewaakt en ook hoe u kunt vertellen welke van de twee belangrijke BGP-verkeerstypen een hoge verkeerspercentage veroorzaken.

Het pad van BGP-pakketten binnen de router kan als volgt worden weergegeven:

Punt
Ethernet-controller -(pakket)-> datapath-doorvoerder -(pakket)-> LPTS -(pakket)-> SPP -(pakket) -> NetIO -(pakket)-> TCP -(bericht)-> BGP

Injecteren
BGP -(bericht)-> TCP -(pakket)-> NetIO -(pakket)-> SPP -(pakket) -> datapath-doorvoerder -(pakket)-> Ethernet-controller

KPI's kunnen worden opgesplitst in:


Essentiële elementen:

1. Datapath Forwarder
2. LPTS (hardware punt policers instellingen, acceptatie tellers en drop tellers)
3. SPP
4. NetIO
5. IPC-wachtrijen (NetIO <==> TCP <==> BGP)
6. BGP InQ/OutQ-formaten

Optioneel:

1. CPU-gebruik
2. Geheugengebruik
3. TCP-statistieken
4. BGP-procesprestaties
5. BGP-convergentie

Monitor Datapath Forwarder

Op XRv9000 is de datapath-doorvoerder de Data Plane Agent (DPA) en op ASR9000-platforms is het de Network Processor (NP).

Monitor XRv9000 dataplane agent (DPA)

Handige opdracht om de belasting en statistieken van de DPA te zien is:

   show controllers dpa statistics global 

Deze opdracht toont alle niet-nul teller, die u inzicht geeft in het type en aantal pakketten die van netwerkinterfaces naar RP CPU worden gepunteerd, die van RP CPU naar netwerkinterfaces worden geïnjecteerd, en het aantal pakketten dat daalde:

RP/0/RP0/CPU0:xrv9k-01#show controllers dpa statistics global Index Debug Count ---------------------------------------------------------------------------- 350 TBPG L2 mailbox events 1 Index Punt Count ---------------------------------------------------------------------------- 1500 CDP 46790 1503 ARP 212 1611 IFIB 595305 1776 LLDP 94037 2001 IPv4 incomplete Tx adjacency 2 Index Inject Count ---------------------------------------------------------------------------- 744 CLNS multicast from fabric pre-route 321250 749 IPv4 from fabric 273993 765 Inject to fabric 595245 766 Inject to port 141033 Index Drop Count ---------------------------------------------------------------------------- 416 Egress UIDB in down state 1 474 IPv4 egress UIDB down 2 673 Pre-route PIT lookup missed 2

Monitor ASR 9000 netwerkprocessor (NP)

Handige opdrachten om de belasting en statistieken van elke NP in het systeem te zien zijn:

   show controllers np load all

   show controllers np counters all

NP op ASR9000 heeft een rijke set tellers die u het aantal, tarief en type van verwerkte en gevallen pakketten, tonen.

RP/0/RSP0/CPU0:ASR9k-B#show controllers np load all Node: 0/0/CPU0: ---------------------------------------------------------------- Load Packet Rate NP0: 0% utilization 937 pps NP1: 0% utilization 538 pps RP/0/RSP0/CPU0:ASR9k-B#

RP/0/RSP0/CPU0:ASR9k-B#show controllers np counters all Node: 0/0/CPU0: ---------------------------------------------------------------- Show global stats counters for NP0, revision v4 Last clearing of counters for this NP: NEVER Read 92 non-zero NP counters: Offset Counter FrameValue Rate (pps) ------------------------------------------------------------------------------------- 16 MDF_TX_LC_CPU 25475368 10 17 MDF_TX_WIRE 681957877 267 21 MDF_TX_FABRIC 683500690 267 33 PARSE_FAB_RECEIVE_CNT 681767730 267 37 PARSE_INTR_RECEIVE_CNT 1323024637 517 41 PARSE_INJ_RECEIVE_CNT 13949634 5 45 PARSE_ENET_RECEIVE_CNT 677655725 265 49 PARSE_TM_LOOP_RECEIVE_CNT 49331192 19 53 PARSE_TOP_LOOP_RECEIVE_CNT 1520846 1 109 RSV_DROP_EGR_UIDB_NO_MATCH 10 0 146 RSV_DROP_IPV4_RXADJ_DROP 1 0 164 RSV_DROP_ING_LAG_NO_MATCH 3 0 241 RSV_DROP_MPLS_LEAF_NO_MATCH 1312 0 <. . .> 

Monitor LPTS

Aangezien een standaardBGP RR niet in de voorwaartse weg is, worden alle pakketten die op netwerkinterface worden ontvangen gestraft aan controle-vliegtuig. Het data-path element op een BGP RR voert een klein aantal eenvoudige bewerkingen uit voordat pakketten worden gepunteerd op control-plane. Aangezien het gegevenspad-element waarschijnlijk geen congestiepunt zal zijn, zijn de LPTS-stats het enige element op de lijnkaart dat bewaking behoeft.

Houd er rekening mee dat in het geval van XRv9k de hardwarestatistiek aan de vPP is toegewezen 

Opdracht:

  show lpts pifib hardware police location <location> | inc "Node|flow_type|BGP"

Voorbeeld:

RP/0/RP0/CPU0:xrv9k-01#sh lpts pifib hardware police location 0/0/CPU0 | i "Node|flow_type|BGP" Node 0/0/CPU0: flow_type priority sw_police_id hw_policer_addr Cur. Rate burst static_avgrate avgrate_type AggrAccepts AggrDrops TOS Value BGP-known high 6 220 50000 1250 2500 Global 16401392 0 01234567 BGP-cfg-peer medium 7 221 4000 1000 2000 Global 355976 1563 01234567 BGP-default low 8 222 3000 750 1500 Global 5212380 0 01234567 RP/0/RP0/CPU0:xrv9k-01# 

Wat u moet zoeken:
Als een significante sprong in AggDrops tegen BGP-bekend stroomtype wordt waargenomen, begin te zoeken naar de veranderingen van de netwerktopologie die dergelijke massale controlevliegtuigkarnton hebben teweeggebracht.

Gegevenspad telemetrie:

  Cisco-IOS-XR-lpts-pre-ifib-oper:lpts-pifib

SPP monitor

SPP is de eerste entiteit op de routeprocessor of lijnkaart CPU die het pakket ontvangt dat via interne stof van de NP of DPA wordt geprikt, en het laatste punt in de verwerking van softwarepakketten voordat het wordt overhandigd aan de stof voor injectie in de NP of DPA.

Relevante opdrachten voor SPP-bewaking:

show spp node-counters

show spp client

De show spp node-counters  opdracht toont de snelheid van gepunte/geïnjecteerde pakketten en is gemakkelijk te lezen en te begrijpen. Voor BGP-sessies staan de relevante tellers onder client/punt  en client/inject  op de actieve RP.

Het show spp client  is rijker in output en geeft een gedetailleerder inzicht in het aantal pakketten die naar klanten worden gevraagd of afgestoten, evenals het hoge watermerk.

RP/0/RP0/CPU0:xrv9k-01#show spp node-counters 0/RP0/CPU0: socket/rx Punted packets: 595305 Punt bulk reads: 6 Punt non-bulk reads: 595293 Management packets: 74200158 Management bulk reads: 1775930 Management non-bulk reads: 70031734 ------------------------------- socket/tx Injected packets: 595245 Management packets: 139939168 ------------------------------- xrv9k/classify Forwarded to SPP clients: 74795463 ------------------------------- client/inject Injected from client: 140534413 Non-bulk injects: 140534413 ------------------------------- client/punt punted to client: 74795371 no client found - send to defa: 92 ------------------------------- 0/0/CPU0: <. . .>

RP/0/RP0/CPU0:xrv9k-01#show spp client Sat Apr 20 17:11:40.725 UTC 0/RP0/CPU0: Clients ======= <. . .> netio, JID 254 (pid 4591) ---------------------------------------------------------- Reconnect Pending: F, Exited: F, Keep Queues: F, Pakman Client: T Quota Current: 0, Limit: 16384, Drops 0 Queues: Key Cur Max Enqueues High Watermark (Timestamp) Drops 0xffffffff 0 10 0 0 (22:13:52.195 Feb 21 24 UTC) 0 0x03000006 0 2048 0 0 (22:13:52.196 Feb 21 24 UTC) 0 0x03000007 0 3072 414881 1 (23:03:30.721 Feb 21 24 UTC) 0 0x03000008 0 1024 5 1 (13:41:28.389 Mar 13 24 UTC) 0 0x03000009 0 2048 180411 1 (23:03:31.565 Feb 21 24 UTC) 0 

Monitor NetIO

Terwijl de LPTS-policer alleen de hoeveelheid pakketten toont die door een corresponderende policer worden geaccepteerd of afgestoten, kunnen we op NetIO-niveau de snelheid zien van pakketten die worden gepunteerd op RP CPU. Aangezien op een typische BGP RR de overgrote meerderheid van de ontvangen pakketten BGP-pakketten zijn, geeft het totale NetIO-tarief zeer nauw het tarief van ontvangen BGP-pakketten aan.

Command:
show netio rates 

Voorbeeld:

RP/0/RP0/CPU0:xrv9k-01#show netio rates Netio packet rate for node 0/RP0/CPU0 ----------------------------------- Current rate (updated 0 seconds ago): Input: 7845 pkts/s Output: 10570 pkts/s Driver Output: 10598 pkts/s 1 minute rate (updated 0 seconds ago): Input: 7825 pkts/s Output: 10542 pkts/s Driver Output: 10569 pkts/s 5 minute rate (updated 0 seconds ago): Input: 7997 pkts/s Output: 10677 pkts/s Driver Output: 10704 pkts/s RP/0/RP0/CPU0:xrv9k-01# 

Wat te zoeken:

• Als een significante sprong in tarief NetIO wordt waargenomen, begin het zoeken naar veranderingen van de netwerktopologie die dergelijke massale de vliegtuigkarnton hebben teweeggebracht.


Gegevenspad telemetrie:

• niet van toepassing omdat telemetrie tegenwaarden moet streamen, niet tarieven. BGP-bekende LPTS policer accepteert teller kan worden gebruikt op de Telemetry Collector om de gemiddelde snelheid van ontvangen BGP pakketten van bekende peers te benaderen.

Monitor XIPC-wachtrijen

Op het punt pad worden pakketten die NetIO van LPTS ontvangt doorgegeven aan TCP en BGP. Het is belangrijk om deze wachtrijen te bewaken:
1. TCP-wachtrij met hoge prioriteit waarin NetIO pakketten levert aan TCP
2. BGP-controlewachtrij
3. BGP-gegevenswachtrij

Op de injectiepad worden pakketten aangemaakt door TCP en doorgegeven aan NetIO. Het is belangrijk om deze wachtrijen te bewaken:

1. UitvoerL XIPC-wachtrij

Opdrachten:

show netio clients show processes bgp | i "Job Id" show xipcq jid <bgp_job_id> show xipcq jid <bgp_job_id> queue-id <n>

Voorbeelden:

NetIO naar TCP, weergave vanuit NetIO-standpunt:

RP/0/RP0/CPU0:xrv9k-01#show netio clients <. . .> Input Punt XIPC InputQ XIPC PuntQ ClientID Drop/Total Drop/Total Cur/High/Max Cur/High/Max <. . .> tcp L 0/340774 0/0 L 0/10/12800 0/0/0 H 0/44774091 H 0/784/12800

TCP naar NetIO, weergave vanuit NetIO-standpunt:

RP/0/RP0/CPU0:xrv9k-01#show netio clients <. . .> XIPC queues Dropped/Queued Cur/High/Max ------------------------------------------------------------ OutputL 124860/9355257 0/14000/14000 

NetIO naar TCP, weergave vanuit TCP-processtandpunt:

RP/0/RP0/CPU0:xrv9k-01#show processes tcp | i "Job Id"
 Job Id: 430
RP/0/RP0/CPU0:xrv9k-01#show xipcq jid 430 Mon Apr 17 16:16:11.315 CEST Id Name Size Cur Size Produced Dropped HWM ------ ------------------------------- ------ --------- ----------- ----------- -------- 17 XIPC_xipcq_12_0_9854_6506_i... 60000 0 39010269 0 960 16 XIPC_xipcq_12_0_9854_6506_i... 24000 0 31518436 0 1364 15 XIPC_tcp_124 3200 0 0 0 0 14 XIPC_tcp_125 9600 0 0 0 0 13 XIPC_tcp_psb_0 25600 0 0 0 0 10 XIPC_tcp_iq_9 102400 0 9486010 0 312 12 XIPC_tcp_iq_8 102400 0 8892274 0 280 9 XIPC_tcp_iq_5 102400 0 8291392 0 289 11 XIPC_tcp_iq_7 102400 0 9700123 0 319 8 XIPC_tcp_iq_6 102400 0 9378703 0 332 7 XIPC_tcp_iq_3 102400 0 7221706 0 261 6 XIPC_tcp_iq_4 102400 0 9791070 0 308 4 XIPC_tcp_ctrl_iq_1 4266 0 0 0 0 5 XIPC_tcp_iq_2 102400 0 9699027 0 295 3 XIPC_tcp_ctrl_iq_0 4266 0 209909 0 9 2 XIPC_tcp_i1 12800 0 39460564 0 784 1 XIPC_tcp_i0 12800 0 212540 0 10 

TCP naar BGP:

RP/0/RP0/CPU0:xrv9k-01#show processes bgp | i "Job Id" Job Id: 1078 RP/0/RP0/CPU0:xrv9k-01#show xipcq jid 1078 Mon Apr 17 16:09:33.046 CEST Id Name Size Cur Size Produced Dropped HWM ------ ------------------------------- ------ --------- ----------- ----------- -------- 2 XIPC_xipcq_12_0_9854_6506_i... 60000 2 35546667 0 15034 1 XIPC_xipcq_12_0_9854_6506_i... 24000 0 1369029 0 50 RP/0/RP0/CPU0:xrv9k-01# 

BGP-gegevenswachtrij:

RP/0/RP0/CPU0:xrv9k-01#show xipcq jid 1078 queue-id 1 XIPC_xipcq_12_0_9854_6506_inst_1_data_toapp: Magic: 12344321 Version: 0 SHM Size: 192392 Owner PID: 9854 Owner JID: 1078 Queue ID: 1 Owner MQ handle: 483 User Context: 0x64 Interrupt Flag: 0 Sent-on-full Flag: 0 Max Queue Size: 24000 Queue Size: 0 Client Queue Size: 24000 High watermark: 50 Last Trigger Sent: Mon Apr 17 16:11:10.009 CEST MQ Send Errors: 0 Priority Queues: Prio Size Drops Total ---------- ---------- ---------- ---------- Unspec 24000 0 0 Normal 24000 0 1396159 Medium 24000 0 0 High 24000 0 0 Crucial 24000 0 0 RP/0/RP0/CPU0:xrv9k-01# 

BGP-controlewachtrij:

RP/0/RP0/CPU0:xrv9k-01#show xipcq jid 1078 queue-id 2 XIPC_xipcq_12_0_9854_6506_inst_1_ctrl_toapp: Magic: 12344321 Version: 0 SHM Size: 480392 Owner PID: 9854 Owner JID: 1078 Queue ID: 2 Owner MQ handle: 485 User Context: 0x64 Interrupt Flag: 0 Sent-on-full Flag: 0 Max Queue Size: 60000 Queue Size: 0 Client Queue Size: 60000 High watermark: 15034 Last Trigger Sent: Mon Apr 17 16:12:49.483 CEST MQ Send Errors: 0 Priority Queues: Prio Size Drops Total ---------- ---------- ---------- ---------- Unspec 60000 0 0 Normal 60000 0 37313633 Medium 60000 0 0 High 60000 0 0 Crucial 60000 0 0 RP/0/RP0/CPU0:xrv9k-01# 

Wat te zoeken:

• de relevante rijen mogen niet worden ingelopen
• in XIPC-wachtrijstats Hoog watermerk (HWM) mag niet groter zijn dan 50% van wachtrijgrootte


Voor een betere tracering van de evolutie met een hoge watermerkwaarde moet u de hoge watermerkwaarde na elke aflezing verwijderen. Merk op dat dit niet alleen de HWM teller ontruimt maar ook alle wachtrijstatistieken ontruimt. Het formaat van het bevel voor het ontruimen van de XIPC rijstatistieken is: clear xipcq statistics queue-name <queue_name>

Aangezien de naam van de wachtrij vaak de proces-ID (PID) bevat, verandert de naam van de wachtrij na het opnieuw opstarten van het proces.
Enkele voorbeelden van opdrachten voor het wissen van de relevante wachtrijstatistieken:

  clear xipcq statistics queue-name XIPC_tcp_i0
  clear xipcq statistics queue-name XIPC_tcp_i1
  clear xipcq statistics queue-name XIPC_xipcq_12_0_9854_6506_inst_1_data_toapp
  clear xipcq statistics queue-name XIPC_xipcq_12_0_9854_6506_inst_1_ctrl_toapp

Telemetriepad:

• Er zijn geen Telemetry sensorpaden voor XIPC.

Monitor BGP-ingangen en -uitvoerwachtrijen

BGP houdt een invoer- en uitvoerwachtrij bij voor elke BGP-peer. Gegevens worden opgeslagen in InQ wanneer TCP het heeft doorgegeven aan BGP, maar BGP heeft deze nog niet verwerkt. Gegevens worden opgeslagen in OutQ terwijl BGP op TCP wacht om de gegevens in pakketten te splitsen en te verzenden. De momentane grootte van BGP InQ/OutQ geeft een goede indicatie van hoe druk het BGP-proces is.


Opdracht:

show bgp <AFI> <SAFI> summary

Voorbeeld:

RP/0/RP0/CPU0:xrv9k-01#show bgp all all summary Address Family: VPNv4 Unicast ----------------------------- BGP router identifier 192.168.0.1, local AS number 65000 BGP generic scan interval 60 secs BGP table state: Active Table ID: 0x0 BGP main routing table version 2208096 BGP scan interval 60 secs BGP is operating in STANDALONE mode. Process RcvTblVer bRIB/RIB LabelVer ImportVer SendTblVer StandbyVer Speaker 2208096 2208096 2208096 2208096 2208096 2208096 Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd 10.0.0.2 0 65000 180 601022 2208096 0 0 02:56:18 100 10.0.0.3 0 65000 180 601022 2208096 0 0 02:56:18 100 10.0.0.4 0 65000 180 601022 2208096 0 0 02:56:21 100 10.0.0.5 0 65000 180 601022 2208096 0 0 02:56:21 100 10.0.0.6 0 65000 180 601022 2208096 0 0 02:56:18 100 

Wat u moet zoeken:

• De grootte van InQ/OutQ moet nul zijn wanneer het netwerk stabiel is. Het verandert snel wanneer updates worden uitgewisseld.
• De InQ/OutQ-grootte mag in de loop der tijd niet monotoon toenemen.

Telemetriepad:

• Cisco 800-IOS-XR-IP4-bgp-oper:bgp

BGP-berichtsnelheden controleren

Sommige BGP-buren kunnen continu updates of intrekkingen verzenden als de netwerktopologie instabiel is. De BGP RR moet deze routeringstabel vervolgens duizenden keren wijzigen in al zijn RR-clients. Daarom is het belangrijk om de van de buurlanden ontvangen berichtsnelheden te controleren en de bronnen van instabiliteit te volgen.


Opdracht:

show bgp <AFI> <SAFI> summary

Voorbeeld:

RP/0/RP0/CPU0:xrv9k-01#show bgp all all summary Address Family: VPNv4 Unicast ----------------------------- BGP router identifier 192.168.0.1, local AS number 65000 BGP generic scan interval 60 secs BGP table state: Active Table ID: 0x0 BGP main routing table version 2208096 BGP scan interval 60 secs BGP is operating in STANDALONE mode. Process RcvTblVer bRIB/RIB LabelVer ImportVer SendTblVer StandbyVer Speaker 2208096 2208096 2208096 2208096 2208096 2208096 Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd 10.0.0.2 0 65000 180 601022 2208096 0 0 02:56:18 100 10.0.0.3 0 65000 180 601022 2208096 0 0 02:56:18 100 10.0.0.4 0 65000 180 601022 2208096 0 0 02:56:21 100 10.0.0.5 0 65000 180 601022 2208096 0 0 02:56:21 100 10.0.0.6 0 65000 180 601022 2208096 0 0 02:56:18 100 

RR-clients hebben ruwweg dezelfde hoeveelheid MsgSent, maar sommige buren kunnen een aantal MsgRcvd hoger hebben dan anderen. U moet meerdere snapshots van deze opdracht opnemen om de snelheid van de berichten te bepalen.

Zodra u de beledigende peers hebt geïdentificeerd, kunt u vervolgens andere opdrachten doorlopen zoals show bgp neighbor <neighbor> detail  en show bgp neighbor <neighbor> performance-statistics  of proberen show bgp recent-prefixes  te begrijpen welke prefixes knipperen en of het altijd dezelfde of verschillende zijn.

CPU-gebruik voor monitoren

Het gebruik van cpu moet op elke router worden gecontroleerd, maar op een router met een hoog aantal cpu kernen gewijd aan controlevliegtuig kunnen sommige lezingen unintuïtief zijn. Op een BGP-router met een groot aantal CPU-cores die specifiek zijn voor Routing Processor (RTP), zoals bij de XRv9k-applicatie, werken actieve threads op verschillende CPU-cores, terwijl een aantal CPU-cores inactief blijft. Als gevolg kunnen sommige CPU-kernen erg druk zijn, maar het totale CPU-gebruik dat voor alle CPU-kernen wordt berekend, blijft gematigd.

Gebruik daarom de show processes cpu thread  opdracht voor goede bewaking van het gebruik van CPU-cores via CLI.

TCP-statistieken controleren

Cisco IOS® onderhoudt gedetailleerde statistieken over elke TCP-sessie. De CLI-opdracht show tcp brief  geeft een lijst weer van alle bestaande TCP-sessies. In deze samenvatting van de output, voor elke TCP sessie kunt u deze informatie zien:

• PCB: unieke TCP sessie-identificatie.
• VRF-ID: de ID van de VRF waarin de sessie bestaat.
  • Om de corresponderende VRF-naam te zien, voert u deze opdracht uit:
  • show cef vrf all summary | utility egrep "^VRF:|Vrfid" | utility egrep -B1 <VRF-ID>
• Recv-Q: onmiddellijke grootte van de ontvangstwachtrij Q. Ontvang wachtrijen voor pakketten ontvangen van NetIO. Het TCP-proces extraheert de gegevens uit een pakket en stuurt deze naar de corresponderende toepassing.
• Send-Q: onmiddellijke grootte van de Send Q. Send wachtrij houdt gegevens die van een toepassing zijn ontvangen. Het TCP-proces splitst de gegevens in TCP-segmenten (gedicteerd door overeengekomen maximale segmentgrootte - TCP MSS), kapselt elk segment in in een Layer 3-header van de corresponderende adresfamilie (IPv4 of IPv6) en verstuurt het pakket naar NetIO.
• Lokaal adres: lokaal IPv4- of IPv6-adres dat aan de TCP-socket is gekoppeld. TCP-sessies in LISTEN-staat zijn doorgaans gebonden aan "elk" IP-adres, dat wordt weergegeven als "0.0.0.0" of ":" in het geval van IPv4 of IPv6.
• Vreemd adres: extern IPv4- of IPv6-adres gekoppeld aan de TCP-socket. TCP-sessies in LISTEN-staat zijn doorgaans gebonden aan "elk" IP-adres, dat wordt weergegeven als "0.0.0.0" of ":" in het geval van IPv4 of IPv6.
• Status: TCP-sessiestatus. Mogelijke TCP-sessiestatus is: LUISTEREN, SYNSEND, SYNRCVD, ESTAB, LASTACK, SLUITEN, CLOSEwait, FINwait1, FINwait2, timewait, GESLOTEN.

Aangezien het bekende BGP-poortnummer 179 is, kunt u de weergegeven TCP-sessies beperken tot de sessies die aan de BGP-toepassing zijn gekoppeld.

Voorbeeld:

RP/0/RSP0/CPU0:ASR9k-B#show tcp brief | include "PCB|:179 " PCB VRF-ID Recv-Q Send-Q Local Address Foreign Address State 0x00007ff7d403bde0 0x60000000 0 0 :::179 :::0 LISTEN 0x00007ff7d403b020 0x60000002 0 0 :::179 :::0 LISTEN 0x00007ff7d403d130 0x60000000 0 0 192.168.0.4:50144 192.168.0.5:179 ESTAB 0x00007ff7a4025650 0x60000000 0 0 0.0.0.0:179 0.0.0.0:0 LISTEN 0x00007ff7a4024a50 0x60000002 0 0 0.0.0.0:179 0.0.0.0:0 LISTEN 

U kunt de weergegeven PCB-waarde gebruiken om de statistieken voor een bepaalde TCP-sessie te verkrijgen. CLI-opdrachten die inzicht bieden in TCP-processtatistieken:

Wereldwijd:

  show tcp statistics clients location <active_RP>

  show tcp statistics summary location <active_RP>

Per PCB:

  show tcp brief | i ":179"

  show tcp detail pcb <pcb> location 0/RP0/CPU0

  show tcp statistics pcb <pcb> location <active_RP>

De globale TCP statistieken bevelen tonen de algemene gezondheid van TCP zittingen. Naast de statistieken van het gegevenspakket (in/out), kunt u bijvoorbeeld zien of er pakketten met controlesomfouten zijn, misvormde pakketten, pakketten die wegens verificatiefouten zijn gelaten vallen, out-of-order pakketten, pakketten met gegevens na venster, wat u een indicatie geeft van het gedrag van TCP-peers.

In de per-PCB opdrachten, kunt u belangrijke parameters van een TCP-sessie zien, zoals MSS, maximale round-trip tijd, enzovoort.

Relevante tellers in de uitvoer van show tcp detail pcb commando zijn:

• Begint timer terug: geeft aan hoe vaak de timer voor herverzending is gestart.
• Retrans Timer Wakeups: geeft aan hoe vaak de hertransmissie-timer is uitgelopen, waardoor een hertransmissie van het TCP-segment wordt geactiveerd.
• Huidige verzend wachtrijgrootte in bytes: niet erkende bytes van de edele.
• Stroom ontvangt wachtrijgrootte in bytes/pakketten: bytes/pakketten die nog moeten worden gelezen door de applicatie (BGP).
• niet-geordende bytes: bytes die in de wachtrij voor opslaan als gevolg van een gat in TCP-ontvangstvenster in de wachtrij staan.

RP/0/RSP0/CPU0:ASR9k-B#show tcp detail pcb 0x4a4400e4 ============================================================== Connection state is ESTAB, I/O status: 0, socket status: 0 Established at Sat Apr 20 18:26:26 2024 PCB 0x4a4400e4, SO 0x4a42c0ac, TCPCB 0x4a43b708, vrfid 0x60000000, Pak Prio: Normal, TOS: 64, TTL: 255, Hash index: 402 Local host: 10.10.10.229, Local port: 179 (Local App PID: 856311) Foreign host: 10.10.10.254, Foreign port: 46980 (Local App PID/instance/SPL_APP_ID: 856311/0/0) Current send queue size in bytes: 0 (max 16384) Current receive queue size in bytes: 0 (max 65535) mis-ordered: 0 bytes Current receive queue size in packets: 0 (max 60) Timer Starts Wakeups Next(msec) Retrans 2795 0 0 SendWnd 1341 0 0 TimeWait 0 0 0 AckHold 274 2 0 KeepAlive 333 1 299983 PmtuAger 0 0 0 GiveUp 0 0 0 Throttle 0 0 0 FirstSyn 0 0 0 iss: 2030796738 snduna: 2034498828 sndnxt: 2034498828 sndmax: 2034498828 sndwnd: 3291 sndcwnd: 4200 irs: 285455091 rcvnxt: 285455710 rcvwnd: 64917 rcvadv: 285520627 
SRTT: 162 ms, RTTO: 415 ms, RTV: 253 ms, KRTT: 0 ms
minRTT: 0 ms, maxRTT: 247 ms ACK hold time: 200 ms, Keepalive time: 300 sec, SYN waittime: 30 sec Giveup time: 0 ms, Retransmission retries: 0, Retransmit forever: FALSE Connect retries remaining: 0, connect retry interval: 0 secs <...> RP/0/RSP0/CPU0:ASR9k-B#

Monitorgeheugengebruik

De BGP-routetabel wordt opgeslagen in het BGP-geheugen van de processtapel. De routeringstabel wordt opgeslagen in het RIB-processtapgeheugen.

Handige opdrachten voor bewaking van heapgeheugen:

  show memory summary

  show memory summary detail

  show memory-top-consumers

  show memory heap summary all

Pad telemetriesensor:

  Cisco-IOS-XR-nto-misc-oper:memory-summary/nodes/node/detail 

FIB slaat het doorsturen van ingangen op in gedeelde geheugenruimte.

Handige opdrachten voor gedeelde geheugenbewaking:

  show memory summary

  show memory summary detail

  show shmwin summary

BGP-procesprestaties bewaken

Handige opdracht die interne gegevens over BGP-procesprestaties levert:

  show bgp process performance-statistics 

  show bgp process performance-statistics detail 

BGP-convergentie controleren

Een andere nuttige opdracht is de opdracht die de algemene status van BGP-convergentie toont: show bgp convergence

Als het netwerk stabiel is, zie je zoiets:

RP/0/RP0/CPU0:ASR9k-B#show bgp convergence Mon Dec 18 13:55:47.976 UTC Converged. All received routes in RIB, all neighbors updated. All neighbors have empty write queues. RP/0/RP0/CPU0:ASR9k-B#