Beste praktijken voor Cisco IOS XR-implementatie voor OSPF/IS-IS en BGP-routing 

 

Inhoud

[UPDATE THE TABLE] 3

[UPDATE THE TABLE][UPDATE THE TABLE] 3

[UPDATE THE TABLE][UPDATE THE TABLE] 3

[UPDATE THE TABLE] 3

[UPDATE THE TABLE] 3

[UPDATE THE TABLE][UPDATE THE TABLE] 4

[UPDATE THE TABLE][UPDATE THE TABLE] 4

[UPDATE THE TABLE][UPDATE THE TABLE] 4

[UPDATE THE TABLE] 5

[UPDATE THE TABLE][UPDATE THE TABLE] 6

[UPDATE THE TABLE][UPDATE THE TABLE] 6

[UPDATE THE TABLE][UPDATE THE TABLE] 6

[UPDATE THE TABLE][UPDATE THE TABLE] 7

[UPDATE THE TABLE][UPDATE THE TABLE] 7

[UPDATE THE TABLE] 8

[UPDATE THE TABLE] 9

[UPDATE THE TABLE][UPDATE THE TABLE] 9

[UPDATE THE TABLE][UPDATE THE TABLE] 10

[UPDATE THE TABLE][UPDATE THE TABLE] 11

[UPDATE THE TABLE] 12

[UPDATE THE TABLE][UPDATE THE TABLE] 12

[UPDATE THE TABLE][UPDATE THE TABLE] 14

[UPDATE THE TABLE][UPDATE THE TABLE] 14

[UPDATE THE TABLE][UPDATE THE TABLE] 17

[UPDATE THE TABLE][UPDATE THE TABLE] 18

[UPDATE THE TABLE] 19

VRIJWARING  

Dit document verstrekt een samenvatting op hoog niveau van sommige gevestigde beste praktijkaanbevelingen voor OSPF/IS-IS en BGP-routing. Deze aanbevelingen vertegenwoordigen geen door Cisco gevalideerd ontwerp, en de nodige zorg en aandacht zijn vereist voor implementatie in een specifieke besturingsomgeving. Zij moeten worden gelezen in samenhang met de configuratiehandleidingen en de technische documentatie voor de relevante producten, waarin meer in detail wordt beschreven hoe deze aanbevelingen voor beste praktijken kunnen worden uitgevoerd.  Verwijzingen in dit document naar configuratiehandleidingen en technische documentatie voor specifieke producten zijn slechts bedoeld als voorbeelden. Raadpleeg de configuratiehandleidingen en de technische documentatie voor uw specifieke producten.

Inleiding  

Dit document schetst een aantal gevestigde best practices en aanbevelingen voor het bouwen van vereenvoudigde, efficiënte en schaalbare netwerken die worden aangedreven door IOS XR-routingplatforms. Dit document concentreert zich op specifieke implementatietechnieken en opties voor functieondersteuning die in IOS XR beschikbaar zijn om te helpen OSPF/IS-IS en BGP-implementaties aan te passen. 

OSPF-implementatie  

Het OSPF-protocol dat in RFC 2328 is gedefinieerd, is een IGP die wordt gebruikt om routeringsinformatie binnen één autonoom systeem te distribueren. OSPF biedt verscheidene voordelen over andere protocollen, maar een juist ontwerp wordt vereist om tot een schaalbaar en fout-verdraagzaam netwerk te leiden.  

Raadpleeg voor meer informatie over OSPF: 

■ TechNotes over OSPF:
https://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/7039-1.html#anc13 

■ Configuratiehandleiding voor OSPF: https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k-r7-6/routing/configuration/guide/b-routing-cg-asr9000-76x/implementing-ospf.html 

■ Opdrachtreferentie: https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/711x/routing/configuration/guide/b-routing-cg-asr9000-711x/implementing-ospf.html?dtid=osscdc000283

Belangrijkste concepten 

■ Hiërarchie: Een hiërarchisch netwerkmodel is een handig hulpmiddel op hoog niveau voor het ontwerpen van betrouwbare netwerkinfrastructuur en helpt complexe netwerkontwerpproblemen te doorbreken in kleinere en beter te beheren gebieden.  

■ Modulariteit: Door verschillende functies op een netwerk in modules te splitsen, is het netwerk veel gemakkelijker te ontwerpen. Cisco heeft verschillende modules geïdentificeerd, waaronder de bedrijfscampus, servicesblok, datacenter en Internet edge.  

■ Resiliency: Het netwerk is beschikbaar in zowel normale als abnormale omstandigheden. De normale omstandigheden omvatten verwachte verkeersstromen, patronen, en geplande gebeurtenissen zoals onderhoudsvensters. Abnormale omstandigheden omvatten hardware- of softwarestoringen, extreme verkeersbelastingen, ongebruikelijke verkeerspatronen, DoS-gebeurtenissen (denial-of-service) en andere geplande of ongeplande gebeurtenissen.   

■ Flexibiliteit: de mogelijkheid om delen van het netwerk te wijzigen, nieuwe services toe te voegen of de capaciteit te vergroten zonder een aanzienlijke upgrade van de heftruck (dat wil zeggen, vervanging van belangrijke hardwareapparaten). 

Als algemene beste praktijk, zou de netwerkplaatsing van de "spanwijdte"van het netwerk moeten rekenschap geven om de routes binnen een specifieke grens en routes te bevatten die door de routers binnen een domein voor het door:sturen relevant zijn en worden vereist. Het effectieve gebruik van OSPF-gebieden helpt het aantal link-state-advertenties (LSA’s) en ander overhead-verkeer dat over het netwerk wordt verzonden te verminderen. Een van de voordelen van het creëren van een hiërarchie is dat deze aanpak helpt ervoor te zorgen dat de grootte van de topologiedatabase die elke router zal moeten onderhouden, beheersbaar is en voldoet aan het geheugenprofiel van de router.   

OSPF-domein en BGP-herdistributie 

OSPF is ontworpen om slechts een paar duizend routes te dragen. Op een hoog niveau zijn OSPF-gebieden secties van een netwerk waar elke router weet van de routermogelijkheden van elke andere router in het gebied. Dit maakt snelle convergentie mogelijk wanneer een apparaat een probleem heeft, maar ten koste van een beperkte schaalbaarheid. Als zodanig wordt OSPF gebruikt in een Service Provider-kern om de basisconnectiviteit tussen alle kernapparaten te bieden, en worden alle kernapparaten geconfigureerd binnen hetzelfde OSPF-gebied. Dit is een standaardontwerp van een "underlay"-netwerk.    

BGP is daarentegen ontworpen om aanzienlijk meer routes te transporteren dan de meeste IGP's, zoals OSPF. Risico's die verbonden zijn aan het herverdelen van BGP-routes in een IGP zoals OSPF. Als een serviceprovider vereist dat BGP-routes voor elk gebruik opnieuw worden gedistribueerd naar het IGP-domein, moet dit worden beheerd door de serviceprovider, met de juiste filtering bij de Autonomous System Boundary Routers (ASBR’s) en met de overbelastingsbescherming die op de ontvangende router is geconfigureerd. Als BGP-herdistributie niet in een OSPF-apparaat wordt gefilterd, zal elk OSPF-apparaat in de ASBR beginnen met het ontvangen van routes die veel verder gaan dan de capaciteit om tegelijkertijd te verwerken. Met Cisco IOS XR-routers kunnen bijvoorbeeld alleen 10.000 BGP-routes standaard worden herverdeeld in OSPF. Wanneer BGP-routes in de IGP worden herverdeeld, is het mogelijk dat alle routers binnen het IGP-domein deze routes ontvangen, afhankelijk van het IGP-ontwerp. Overeenkomstig OSPF-protocol RFC moet elke externe route die naar OSPF wordt herverdeeld, worden gedistribueerd naar alle routers in het OSPF-gebied.   

Herverdeling in IGP beheren  

Als algemene beste praktijk dient herverdeling alleen op een zorgvuldige en geplande manier te gebeuren als er geen andere opties zijn om de routes te leren die een herverdelingsfunctie zal bieden.  

In de regel dient u het volgende te doen: 

■ Vermijd herverdeling  

■ Vermijd het transporteren van routes in een IGP-domein 

■ BGP implementeren voor externe bereikbaarheid  

■ Gebruik IGP om alleen informatie over de volgende hop te dragen; bijvoorbeeld Loopback 0  

Beperkingen van OSPF-routeherdistributie  

De schaal van prefixes die van BGP naar OSPF worden herverdeeld wordt beheerd met de configuratie van de overbelastingsbescherming (max-lsa). Dit is de enige bescherming tegen het lekken van een groot aantal routes in het domein OSPF. In het geval van herdistributie in één enkel OSPF-gebied moet u meerdere lagen van bescherming tegen routeherdistributie implementeren. 

Hier zijn enkele van de opties die beschikbaar zijn voor bescherming tegen routeherverdeling: 

■ herdistributie met ACL   

■ Herdistributielimiet - wereldwijde instelling om te voorkomen dat meer dan een bepaald aantal routes opnieuw worden gedistribueerd. Als het filter wordt verwijderd, is de mondiale herdistributielimiet de tweede verdedigingslinie die de kernen zal beschermen. 

■ Max-LSA-configuraties op alle apparaten in het OSPF-gebied - als de bescherming die in de bovenstaande opsommingen wordt genoemd mislukt, dwingt u de ontvangende routers om de inkomende buitensporige LSA's te weigeren.

OSPF Link-State Database Overload-bescherming  

De functie OSPF Link-State Database Overload Protection biedt een mechanisme op OSPF-niveau om het aantal niet-zelf gegenereerde LSA’s voor een bepaald OSPF-proces te beperken. Als andere routers in het netwerk verkeerd zijn geconfigureerd, kunnen ze bijvoorbeeld een groot volume LSA's genereren om grote aantallen prefixes te herverdelen in OSPF. Dit beschermingsmechanisme helpt bij het voorkomen dat routers veel LSA's ontvangen en daardoor te maken krijgen met CPU- en geheugentekorten.  

Functiegedrag

Dit is hoe de functie zich gedraagt: 

■ Wanneer deze functie is ingeschakeld, houdt de router een telling bij van het aantal ontvangen (niet-zelf-gegenereerde) LSA’s.  

■ Wanneer de ingestelde drempelwaarde is bereikt, wordt een foutbericht vastgelegd.  

■ Wanneer het ingestelde max. aantal ontvangen LSA’s wordt overschreden, accepteert de router geen nieuwe LSA’s.   

max-lsa <max-lsa-count> <%-drempel-naar-log-waarschuwing> negeren-telling <negeren-telling-waarde> negeren-tijd <negeren-tijd-in-minuten> reset-time <time-to-reset-ignore-count-in-minuten>   

OSPF-staten

Als de ontvangen LSAs-telling hoger is dan het geconfigureerde max-nummer na een minuut, brengt het OSPF-proces alle nabijheid naar beneden en ontruimt het OSPF-gegevensbestand. Deze staat wordt de negestaat genoemd. In deze staat, worden alle OSPF-pakketten die worden ontvangen op alle interfaces die tot de OSPF-instantie behoren, genegeerd en er worden geen OSPF-pakketten gegenereerd op de interfaces. Het OSPF-proces blijft in de negestaat voor de duur van de geconfigureerde negetijd (standaard is 5 minuten). Wanneer de negetijd verloopt, keert het OSPF-proces terug naar de normale werking en wordt nabijheid op alle interfaces opgebouwd.   

Als de LSA-telling het maximale aantal overschrijdt zodra de OSPF-instantie terugkeert van de staat die wordt genegeerd, kan de OSPF-instantie eindeloos oscilleren tussen de normale staat en de staat die wordt genegeerd. Om deze oneindige oscillatie te voorkomen, telt de OSPF-instantie hoe vaak het in de negestaat is geweest. Deze teller wordt de negerentelling genoemd. Als de negerentelling (standaard negerentelling is 5) de ingestelde waarde overschrijdt, blijft de instantie OSPF permanent in de negerstatus.   

U moet de duidelijke ospf-opdracht uitgeven om de OSPF-instantie naar de normale status te retourneren. Het negeren-tellen wordt teruggesteld aan nul als het LSA-tellen niet het maximum aantal opnieuw overschrijdt tijdens de tijd die door het reset-time sleutelwoord is geconfigureerd.   

Als u het waarschuwing-enige sleutelwoord gebruikt, gaat de instantie OSPF nooit de negeerstaat in. Wanneer de LSA-telling het maximale aantal overschrijdt, logt het OSPF-proces een foutbericht in en gaat de OSPF-instantie door in de normale werking van de status.  

Er is geen standaardwaarde voor max-lsa. De limiet wordt alleen gecontroleerd als deze specifiek is ingesteld.  

Zodra max-lsa is geconfigureerd, kunnen andere parameters standaardwaarden hebben:

■ standaard %-drempel-naar-log-waarschuwing - 75%  

■ standaardwaarde voor negeren/tellen - 5

■ standaard negeer-tijd-in-minuten - 5 minuten  

■ standaardtijd om te resetten-negeren-telling - 10 minuten

Hier is een voorbeeld van de implementatie die toont hoe te om de instantie OSPF te vormen om 12000 niet zelf-geproduceerde LSAs en 1000 niet-zelf-geproduceerde LSAs in VRF V1 goed te keuren.

RP/0/RSP0/CPU0:router# configureren  

RP/0/RSP0/CPU0:router (configuratie)# router ospf 0   

RP/0/RSP0/CPU0:router (config-ospf)# max-lsa 12000  

RP/0/RSP0/CPU0:router (config-ospf)# Vrf V1  

RP/0/RSP0/CPU0:router (config-ospf)# max-lsa 1000   

Het volgende voorbeeld toont hoe de huidige status van de OSPF-instantie te tonen.  

RP/0/RSP0/CPU0:router# ospf 0 tonen  

    Routing-proces "ospf 0" met ID 10.0.0.2  

    NSR (non-stop routing) is uitgeschakeld  

    Ondersteunt alleen enkele TOS(TOS0) routes  

    Ondersteunt ondoorzichtige LSA  

    Het is een router aan de gebiedskader  

    Maximumaantal niet zelf gegenereerde LSA’s 12000  

       Huidig aantal niet zelf gegenereerde LSA 1  

       Drempelwaarde voor waarschuwingsbericht 75%  

       Negeren-tijd 5 minuten, reset-tijd 10 minuten  

       Negeren-telling toegestaan 5, stroom negeren-telling 0  

BGP-implementatie 

BGP-adresfamilies maken van de BGP een "multiprotocol" routeringsprotocol. Het is sterk aanbevolen dat u begrijpt hoe de adresfamilies worden gebruikt om schaalbare topologieën te creëren die eenvoudig te implementeren en te beheren zijn. Door gebruik te maken van adresfamilies kan de operator verschillende topologieën maken voor verschillende technologieën, bijvoorbeeld EVPN, Multicast, enzovoort.  

Zie de BGP-configuratiegids voor meer informatie over BGP: https://www.cisco.com/c/en/us/td/docs/iosxr/ncs5500/bgp/76x/b-bgp-cg-ncs5500-76x/implementing-bgp.html 

BGP en BFD 

BGP-convergentie in een netwerk van serviceproviders is belangrijk om te voldoen aan de verwachtingen van klanten voor het bouwen van veerkrachtige en fouttolerante netwerken. Standaard heeft BGP een Keepalive-timer van 60 seconden en een Hold-timer van 180 seconden. Dit alles betekent dat BGP zeer traag zal zijn om samen te komen tenzij er hulp beschikbaar is van ondersteunende protocollen. BFD Bi-directional Forwarding (BFD) is een van deze protocollen die ontworpen is om de clientprotocollen sneller te laten convergeren. Met BFD kunnen protocollen binnen enkele seconden samenkomen.   

Aanvullende informatie

■ Deze handleiding bevat conceptuele en configuratiegegevens voor BFD: https://www.cisco.com/c/en/us/td/docs/iosxr/ncs5500/routing/76x/b-routing-cg-ncs5500-76x/implementing-bfd.html 

■ Dit witboek geeft een serviceprovider-gerichte weergave van snelle convergentie met BFD op de routers van Cisco NCS 5500 en Cisco Network Convergence System 500 Series: https://xrdocs.io/ncs5500/tutorials/bfd-architecture-on-ncs5500-and-ncs500/  

■ Raadpleeg https://xrdocs.io/ repository voor een dieper overzicht van het gebruik van BFD op Bundle interfaces en het implementeren van Multipath en MultiHop BFD.  

BGP-detectie van langzame peer  

Een slow peer is een peer die geen gelijke kan houden met de snelheid waarmee de router updateberichten genereert over een langere periode (in de volgorde van minuten) in een updategroep. Wanneer een langzame peer in een updategroep aanwezig is, bouwt het aantal geformatteerde updates in afwachting van transmissie op. Wanneer de cachelimiet is bereikt, heeft de groep geen quota meer om nieuwe berichten te formatteren. Om een nieuw bericht te formatteren, moeten sommige bestaande berichten worden verzonden met de slow peer en dan uit het cache worden verwijderd. De rest van de leden van de groep die sneller zijn dan de langzame peer en de transmissie van de geformatteerde berichten hebben voltooid zullen niets nieuws te verzenden hebben, alhoewel er onlangs gewijzigde BGP-netwerken kunnen zijn die wachten om geadverteerd of ingetrokken te worden. Dit effect van het blokkeren van de opmaak van alle peers in een groep wanneer een van de peers traag is in het verwerken van updates is het "slow peer" probleem.  

Gebeurtenissen die een significante breuk in de BGP-tabel (zoals verbindingsresets) veroorzaken, kunnen een korte piek in de snelheid van de updategeneratie veroorzaken. Een peer die tijdelijk achterop raakt tijdens dergelijke evenementen, maar zich snel herstelt na de gebeurtenis, wordt niet beschouwd als een traag peer. Voor een peer om als langzaam te worden gemarkeerd, moet het niet in staat zijn om met het gemiddelde tarief van geproduceerde updates over een langere periode (in de orde van een paar minuten) bij te houden.  

BGP Slow peer kan worden veroorzaakt door:   

■ pakketverlies of veel verkeer op de link naar de peer. 

■ Een BGP-peer kan zwaar worden geladen in termen van CPU en kan daarom de TCP-verbinding niet op de vereiste snelheid onderhouden.  

■ In dit geval moeten de hardwaremogelijkheden van het platform en de aangeboden belasting worden gecontroleerd. 

■ Doorvoerproblemen met de BGP-verbinding  

■ Zie voor meer informatie over BGP Slow peer detectie: https://www.cisco.com/c/en/us/td/docs/iosxr/ncs5500/bgp/76x/b-bgp-cg-ncs5500-76x/implementing-bgp.html#concept_ir5_j4w_p4b  

Hier zijn sommige matigingen en beste praktijken voor het beheren van langzame edelen:   

■ End-to-end QoS, die bandbreedte reserveert voor BGP-verkeer van besturingsplane tijdens stremming. 

■ Gebruik van correcte en geschikte MSS / MTU-waarden met BGP PMTUD- en/of TCP MSS-instellingen. 

■ Gebruik de juiste hardware en minimaliseer het aantal routes met betrekking tot de hardware. 

Slow-peer detectie is standaard ingeschakeld in Cisco IOS XR vanaf release 7.1.2. Langzame peers zijn peers die traag zijn bij het ontvangen en verwerken van de inkomende BGP-updates en de updates bevestigen aan de afzender. Als de slow peer deel uitmaakt van dezelfde updategroep als andere peers, kan dit het updateproces voor alle peers vertragen. In deze versie, wanneer IOS XR een langzame peer ontdekt, zal het tot een syslog leiden die de details over de specifieke peer heeft.   

Snelle convergentie met BGP-prefix onafhankelijke convergentie  

Voor BGP-prefixes wordt snelle convergentie bereikt met BGP Prefix Independent Convergence (PIC), waarin BGP een alternatieve beste pad en primaire beste pad berekent en beide paden in de routertabel als primaire en back-uppaden installeert.   

Als de BGP next-hop remote onbereikbaar wordt, switch BGP onmiddellijk naar het alternatieve pad met BGP PIC in plaats van het pad na de fout opnieuw te berekenen.   

Als de BGP next-hop externe PE nog springt, maar er is een padfout, behandelt IGP TI-LFA FRR snelle re-convergentie naar het alternatieve pad en werkt BGP de IGP next-hop voor de externe PE bij.   

BGP PIC wordt geconfigureerd onder VRF-adresfamilie voor snelle convergentie van VPN-prefixes als een externe PE onbereikbaar wordt.  

Zie voor meer informatie over BGP Prefix Independent Convergence:
https://www.cisco.com/c/en/us/td/docs/iosxr/ncs5500/bgp/76x/b-bgp-cg-ncs5500-76x/bgp-pic.html 

 

BGP-beveiliging met BGP-stroomspecificatie  

BGP Flowspec, in een notendop, is een eigenschap die u toestaat om IPv4/IPv6 verkeersstroomspecificaties (bron X, bestemming Y, protocol UDP, bronpoort A, etc.) en acties te ontvangen die op dat verkeer moeten worden genomen (zoals beëindigen, politie, of omleiden) via BGP update.
Binnen de BGP update, worden de Flowspec aanpassingscriteria vertegenwoordigd door BGP NLRI, en BGP uitgebreide gemeenschappen vertegenwoordigen de acties.

Deze optie is gebaseerd op RFC 5575 en kan worden gebruikt om DDoS-aanvallen te helpen beperken. Wanneer een bepaalde host binnen een netwerk wordt aangevallen, kunnen we een Flowspec-update naar randrouters sturen zodat aanvalsverkeer kan worden gepoliceerd of weggelaten, of zelfs ergens anders omgeleid, misschien naar een apparaat dat het verkeer kan reinigen (filter het ‘slechte’ verkeer en doorsturen alleen het ‘goede’ verkeer naar de aangetaste host).  

Zodra Flowspecs door een router worden ontvangen en in toepasselijke lijnkaarten geprogrammeerd, zullen om het even welke actieve L3 havens op die lijnkaarten beginnen toegangsverkeer volgens Flowspec regels te verwerken.  

Zie voor meer informatie over het implementeren van BGP FlowSpec:  

■ BGP FlowSpec-whitepaper: https://xrdocs.io/ncs5500/tutorials/bgp-flowspec-on-ncs5500/  

■ BGP-configuratiehandleiding: https://www.cisco.com/c/en/us/td/docs/iosxr/ncs5500/bgp/76x/b-bgp-cg-ncs5500-76x/implementing-bgp.html#concept_uqv_bxq_h2b 

 

BGP maximale prefixfunctie

De functie Maximum-prefix is handig wanneer een router, bij een wijziging van het uitgaand beleid op de externe peering site, meer prefixes begint te ontvangen dan de resources van de peering router kunnen verwerken maar ook om resources of de interne BGP-peers te beschermen waar deze externe prefixes doorgestuurd zullen worden. Zulke bron-overheadkosten zouden ontwrichtend kunnen zijn.

De BGP-functie voor maximale prefixen legt een maximale limiet op aan het aantal prefixes dat wordt ontvangen van een buurman voor een bepaalde adresfamilie. Standaard wordt, wanneer het aantal ontvangen prefixes hoger is, het maximale aantal geconfigureerd, de BGP-sessie een stopmelding naar de buur verstuurd en de sessie wordt beëindigd. Eén adresfamilie die het maximum-prefix kruist, zal de hele BGP-sessie omlaag brengen, wat een impact heeft op alle andere adresfamilies die in die BGP-sessie ingeschakeld zijn.

Deze functie wordt veel gebruikt voor externe BGP-peers om de interne infrastructuur van een serviceprovider te beschermen. Het dient als een vangnet om de uitputting van routermiddelen te verhinderen die door een misconfiguratie, of plaatselijk of op de verre buur zouden kunnen worden veroorzaakt. Het configureren van een maximum-prefix wordt ten zeerste aanbevolen ter bescherming tegen lokale of externe misconfiguraties die kunnen leiden tot het overstromen van een routetabel. Dit beschermt ook tegen prefixdeaggregatie-aanvallen.

De BGP-configuratie met maximale voorvoegsel moet expliciet worden ingeschakeld op alle eBGP-routers om het aantal voorvoegsels te beperken dat deze van een bepaalde buur moet ontvangen, of dit nu de klant is of de peer. Aanbevolen wordt dat de operator een acceptabele marge met extra prefixes configureert die het systeem mogelijk kan aanhouden na zorgvuldige evaluatie van het beschikbare systeemgeheugen. Opgemerkt moet worden dat er geen één grootte past alle configuratie die kan worden toegepast op alle routers en de drempel zou zorgvuldig moeten worden aangepast gebaseerd op de rol van het apparaat in het netwerk. Als bijvoorbeeld BGP maximum-prefix moet worden geconfigureerd op IBGP-buren, dan moet de maximum-prefixwaarde lager zijn op de buren die zijn geconfigureerd op de routereflector versus de buren die zijn geconfigureerd op de route-reflector-clients. De route-reflector aggregeert prefixes ontvangen van meerdere peering routers en adverteert vervolgens de volledige tabel opnieuw naar de route-reflector-clients. Daarom zal de route-reflector meer prefixes aan zijn klanten adverteren dan wat hij van elke individuele peer ontvangt. Op dezelfde manier kan een peer router ook meer prefixes naar de route-reflector heradverteren dan wat hij van elke individuele externe peer ontvangt.

Samengevat, wordt het aanbevolen om zorgvuldig de juiste actie te bekijken en te configureren die moet worden uitgevoerd wanneer de maximale prefixdrempel op een productieapparaat is bereikt. Sommige kenmerken van de opties voor de maximale prefixopdracht worden als volgt beschreven:

• Wanneer een BGP-sessie expliciet is geconfigureerd met de functie voor het maximale prefix zonder extra trefwoorden (zoals alleen-waarschuwen of potentieel opnieuw opstarten), wordt de sessie als standaardgedrag afgebroken. De standaardactie van peer-sessie die wordt afgebroken zonder automatisch herstel kan leiden tot een langdurige onderbreking in de kern.

%ROUTING-BGP-5-ADJCHANGE_DETAIL : buurman 10.10.10.10 Down - BGP melding ontvangen, maximaal aantal bereikte prefixes (VRF: standaard; AFI/SAFI: 1/1, 1/128, 2/4, 2/128, 1/133, 2/133) (AS: 65000) "

%ROUTING-BGP-5-NBR_NSR_DISABLED_STANDBY: NSR uitgeschakeld op buur 10.10.10.10 in standby RP vanwege overschrijding van maximale prefixlimiet door peer (VRF: standaard)

• Als u de optie Extra paden negeren instelt, worden alle overtollige prefixes die van de buur worden ontvangen, verlaagd boven de ingestelde maximumwaardedrempel. Deze daling resulteert niet in sessievlak. De voordelen van deze optie omvatten het beperken van het gebruik van het BGP-procesgeheugen en het tegenhouden van de flappen van de peers binnen het kernnetwerk. Dit kan echter resulteren in het doorsturen van lusjes voor de prefixes die worden weggegooid omdat de doorsturen ingangen inconsistent kunnen worden tussen routers in het netwerk.
• Wanneer u add-path gebruikt, is de ingestelde maximale prefixwaarde van toepassing op paden in plaats van prefixes, aangezien de NLRI is gemaakt van het prefix en de padkenmerken. Raadpleeg de volgende opdrachtreferentie voor meer informatie:

https://www.cisco.com/c/en/us/td/docs/iosxr/ncs5500/bgp/b-ncs5500-bgp-cli-reference/b-ncs5500-bgp-cli-reference_chapter_01.html

Aanbeveling: evalueer zorgvuldig de volgende opties bij het configureren van de opdracht maximum-prefix:

• Geen expliciete actie gedefinieerd: de router zal de sessie neerhalen en de BGP-buurrelatie laag houden tot de operator de BGP-sessie handmatig leeg maakt. [opdracht bgp wissen]
• Herstart [time-interval]: Breng de sessie naar beneden en probeer periodiek een automatische herstart van de BGP-sessie na een geconfigureerde timer. Dit zal lukken als de remote peer stopt met het adverteren van de overtollige prefixes anders zal de BGP-sessie opnieuw dalen (waardoor periodieke instabiliteit wordt veroorzaakt).
• Verwerp-extra-paden: met de optie verwerpen-extra-paden blijft de BGP-sessie omhoog, maar prefixes boven de maximum-prefixlimiet worden verwijderd. Deze optie heeft geen gevolgen voor andere adressenfamilies waar het maximum-prefix niet is bereikt en zorgt ervoor dat lokale bronnen niet uitgeput zijn, maar dit kan leiden tot het doorsturen van loops voor de prefixes die worden weggegooid. Merk op dat de optie van de verwerping extra wegen niet met de zachte reconfig knop kan coëxisteren.
• Alleen waarschuwing: log een waarschuwing alleen in wanneer de drempelwaarde wordt bereikt, zodat de bediener handmatig kan ingrijpen om de toestand te verhelpen.

Raadpleeg de Routing Configuration Guide als volgt voor meer informatie:

https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k-r7-3/routing/configuration/guide/b-routing-cg-asr9000-73x/implementing-BGP.html#concept_5AF38064B1D044B7B5F439C10BCF9808

Beste praktijken en aanbevelingen

De volgende lijst geeft een overzicht van de algemene best practices en aanbevelingen, in niet-specifieke volgorde:  

■ Netwerkaudit voor de algemene gezondheid van het systeem. Begin met een configuratiecontrole en ga achtereenvolgens van interfaceconfiguraties naar routing en services.   

■ Zorg voor een bewakingsstrategie. Terwijl SNMP standaardpraktijk is, overweeg het opstellen van robuustere en beschrijvende technieken met behulp van streaming telemetrie. Raadpleeg het volgende witboek voor aanbevelingen over beste praktijken bij het implementeren van telemetrie op een IOS XR-router: https://xrdocs.io/telemetry/  

OSPF  

Hier zijn algemene best practices en aanbevelingen voor OSPF: 

■ Voer routesamenvatting voor intragebiedroutes voor OSPF uit.  

■ Configureer de router-ID expliciet binnen OSPF als een van de OSPF-enabled loopback-adressen.  

■ Ontwerp een hiërarchisch netwerk om de LSA's binnen een gebied voor OSPF te beperken. Houd het aantal ABR's voor een gebied binnen een redelijk bereik (~3 tot 4).  

■ OSPF "max-lsa"-configuratie voor OSPF of gelijkwaardig implementeren om de LSA’s in de database te beperken om het geheugen van het systeem effectief te gebruiken.   

■ Beperk het maximale aantal routes dat van BGP naar OSPF kan worden gedistribueerd. In IOS-XR is de standaardlimiet 10K. 

■ Use Route Policy (RPL) om de routes te herverdelen in OSPF. 

■ Voeg, waar van toepassing, een overzicht toe van de interzoneroute en de externe type 5-routes.   

■ Gebruik van authenticatie indien nodig.   

■ Gebruik altijd NSF en NSR. 

■ Configuratie van herdistributie filtering aan de bron in plaats van de bestemming.   

■ Gebruik passieve interface waar van toepassing.   

■ OSPF moet alleen Loopback- en Router-Interface-routes dragen - verwijder elke andere BGP-to-OSPF-herdistributie.   

■ Overweeg elke primaire hub naar zijn eigen gebied (NSSA) te verplaatsen.   

■ Gebruik BFD voor snelle detectie van fouten in vergelijking met de agressieve routeringsprotocoltimers.   

■ Gebruik de opdracht mtu-negeer niet zoveel mogelijk.  

■ Overweeg het gebruik van IGP-LDP-synchronisatie in een MPLS-omgeving om te voorkomen dat er verkeer op een niet-gelabeld pad wordt verzonden. 

■ Overweeg schaal binnen ondersteunde platformgrenzen (aantal prefixes, aantal labels, ECMP, aantal gebieden, enzovoort). 

■ Vermijd wederzijdse herverdeling op meerdere punten.  

■ Configureer de beheerafstand zodat elk prefix van elk protocol of proces via het betreffende protocol of proces van het domein wordt bereikt.  

■ Beheer de prefixes (met behulp van afstand of prefix-lijstcombinatie), zodat dezelfde prefix niet wordt geadverteerd naar het oorspronkelijke domein.   

■ OSPF-proces-ID is lokaal van belang voor de router, maar het wordt aanbevolen om dezelfde proces-ID te hebben voor alle routers in hetzelfde OSPF-domein. Dit verbetert de configuratieconsistentie en vergemakkelijkt de automatische configuratietaken.  

■ Wanneer u OSPF configureert voor hub-and-spoke omgevingen, ontwerp u de OSPF-gebieden met een kleiner aantal routers.   

■ Configureer de bandbreedte van de OSPF-automatische verwijzing in het OSPF-domein naar de hoogste bandbreedte in het netwerk.  

■ Vanuit een ontwerpperspectief raden we u aan om IGP-peer met domeinen onder dezelfde administratieve of operationele controles te implementeren om te voorkomen dat ongeplande of schurke IGP-update zich over het netwerk verspreidt. Dit zou voor beter nut en gemak van het oplossen van problemen moeten toestaan ingeval de fouten voorkomen. Als een groot IGP-domein een zakelijke noodzaak is, plant dan het gebruik van BGP in die gevallen om het aantal routes in het IGP-netwerkdomein te beperken.  

■ Als u end-to-end MPLS-connectiviteit nodig hebt, kunt u doorgaan met het gebruik van hiërarchie/segmentering en opties gebruiken zoals RFC3107 BGP-LU of berekening van pad tussen domeinen via PCE, of herdistributie/lekken selecteren met beleid als laatste redmiddel.  

■ OSPF Shortest Path First Throttling feature kan worden gebruikt om SPF-planning in milliseconden intervallen te configureren en mogelijk de SPF-berekeningen uit te stellen tijdens netwerkinstabiliteit. 

■ OSPF SPF Prefix Priorisation functie stelt een beheerder in staat om belangrijke prefixes sneller te convergeren tijdens routeinstallatie.  

ISIS  

Hier zijn algemene best practices en aanbevelingen voor IS-IS: 

■ Als je een vlak netwerk met één niveau gebruikt, denk dan aan de schaal. Alle routers alleen als L2 configureren. Standaard is de router L1-L2, en lekken van routerinformatie van L1 naar L2 is standaard ingeschakeld. Dit zou tot alle routers kunnen leiden die alle L1 routes naar L2 lekken, die het verbinding-staat gegevensbestand opblazen.  

■ Als u een netwerk op meerdere niveaus (meerdere gebieden) gebruikt, zorg er dan voor dat Layer 3-topologie de ISIS-hiërarchie volgt. Maak geen backdoor-koppelingen tussen L1-gebieden.  

■ Als u een netwerk op meerdere niveaus (meerdere gebieden) gebruikt, zorg er dan voor dat de L1- en L2-routers via zowel L1- als L2-gebieden zijn verbonden. Dit vereist geen meervoudige fysieke of virtuele verbindingen tussen hen; stel het verband tussen L1 en L2 routers als L1/L2 kring in werking.  

■ Als u een netwerk op meerdere niveaus (meerdere gebieden) gebruikt, vat u samen wat kan worden samengevat - bijvoorbeeld in het geval van MPLS moet de loopback van PE-routers worden gepropageerd tussen gebieden, maar de infrastructurele koppelingsadressen niet.  

■ Maak en volg het juiste adresseringsplan als dat mogelijk is. Dat maakt samenvatting mogelijk en helpt schaalbaar te zijn.  

■ Stel de LSP-levensduur in op maximaal 18 uur. 

■ Vermijd herverdeling op welke manier dan ook. Herdistributie is complex en moet handmatig worden beheerd om routing loops te voorkomen. Gebruik, indien mogelijk, een ontwerp met meerdere gebieden/niveaus.  

■ Als u herdistributie moet gebruiken, gebruik dan route tagging tijdens herdistributie en "distribute-list in" filtering op basis van tags om het te beheren. Vat dit zo mogelijk samen tijdens de herverdeling.  

■ Configureer interfaces als "point-to-point" waar mogelijk. Dit verbetert de prestaties en schaalbaarheid van het protocol. 

■ Gebruik geen ISIS in een topologie met zeer veel netwerk. De verbinding-staat protocollen gedragen zich slecht in hoogst vermaasde milieu's.  

■ Configureer een hoge standaardmetriek in de submodus van de ISIS-adresfamilie. Dit voorkomt dat nieuwe links verkeer kunnen aantrekken als ze per ongeluk zonder metriek zijn geconfigureerd.  

■ "log nabijheidswijzigingen" configureren om te helpen bij probleemoplossing bij verbindingen.

■ Gebruik "metric-style wide" onder de ISIS-adresfamilie ipv4 sub-mode. Smalle metriek zijn niet erg nuttig en ondersteunen geen functies zoals segmentrouting of flex-algo.  

■ Als u SR-MPLS TI-LFA gebruikt moet u "ipv4 unnumed mpls traffic-eng Loopback0" aan de configuratie toevoegen om ISIS in staat te stellen indien nodig TE-tunnels toe te wijzen.  

■ Laat de "lsp-gen-interval" en "spf-interval" configuraties standaard, tenzij u er zeker van bent dat snellere native convergentie vereist is. Met Ti-LFA native convergentie is niet zo cruciaal, omdat snel omleiden enkele topologiewijzigingen in 50 ms of minder zal verwerken.  

■ Als u "lsp-gen-interval" of "spf-interval" wijzigt, gebruik dan geen initiële vertraging korter dan 50 ms.  

■ In de meeste gevallen is "set-overload-bit" een betere keuze dan "max-metric", omdat het een atomaire verandering is die wordt ondersteund door fast-reroute.  

■ Gebruik cryptografische verificatie voor Hellos (hello-password) en LSP’s (lsp-password). Keychains bieden de meeste flexibiliteit en kunnen
geschikt voor hitless key rollovers.  

■ "nsf cisco" configureren voor hitless authenticatie van ISIS-procesherstart en SMU-installatie. Ondanks de naam, zorgt dit voor een betere interoperabiliteit met andere leveranciers dan "nsf ietf". 

■ Op een platform met dubbele RP's, configureer OOK "nsr" om RP-switchovers aan te kunnen.  

■ Gebruik "group" en "application-group" sjablonen om herhaalde configuratiesecties te configureren. Dit is minder foutgevoelig en gemakkelijker te veranderen indien nodig.  

■ Overweeg in een netwerk op meerdere niveaus zorgvuldig of u "propagate" moet gebruiken om prefixes van Niveau 2 aan Niveau 1 te lekken. Dit kan schaalbaarheid beperken en vaak is de standaardroute van niveau 1 die door het Bijgevoegde bit wordt geboden voldoende. 

■ Als u meerdere ISIS-instanties in dezelfde VRF gebruikt, kunt u unieke "afstand"-waarden voor deze instanties configureren. Dit maakt de installatie van de route in de RIB deterministischer als elk een route naar hetzelfde prefix heeft.  

■ Gebruik BFD voor snelle link-down detectie. Omdat de BFD deze functie biedt, kan het ISIS-hello-interval veilig worden verlengd om de schaalbaarheid te verbeteren.  

BGP  

Hier zijn algemene best practices en aanbevelingen voor BGP: 

■ Gebruik NSR en NSF / graceful reset met zorgvuldig afgestemde timers afhankelijk van de verwachte schaal. 

■ BGP configureren met behulp van de ‘always UP’ loopback-interface, niet de fysieke interface voor IBGP-peer. 

■ Verdeel BGP-routes (met groot volume) niet opnieuw in IGP (relatief laag volume) en vice versa zonder de juiste RPL, waardoor het aantal herverdeelde routes van BGP naar een IGP (OSPF/ISIS) wordt beperkt.   

■ Als BGP wordt gebruikt voor IGP-herdistributie zonder een juiste, goed geteste beleidsoptie (ACL), kan bron- (geheugen-) uitputting van de router veroorzaken.  

■ Gebruik van summiere routes in BGP om de grootte van de routeringstabel en het gebruik van geheugen te verminderen. Aggregate routes met samenvatting-slechts waar het steek houdt  

■ Gebruik routefiltering voor efficiënte reclame en ontvangst van routes, met name in BGP.  

■ We raden het gebruik van Route-Reflector (RR) en confederatie aan om het netwerk op te schalen.   

■ Een aantal van de overwegingen met betrekking tot het routeweerkaatsingsontwerp zijn: 

■ Schaalvergroting pad gebaseerd op het aantal clients/niet-clients. 

■ Gebruik in hiërarchische RR’s dezelfde cluster-id op hetzelfde niveau (redundante RR) voor luspreventie en -schaal.  

■ Control MTU binnen het BGP-pad of gebruik het PMTUD-protocol om BGP MSS automatisch aan te passen.  

■ Gebruik BFD- of BGP-timers voor snellere foutdetectie. 

■ BGP-schaal is per configuratie en gebruikscase, en geen enkele grootte past allemaal. Je moet een goed idee hebben over:  

■ routesnelheid  

— pad schaal (met zachte herconfiguratie, het zal toenemen)  

— kenmerkschaal  

■ Als het add-path is geconfigureerd, neemt het meer geheugen in beslag.  

■ Nauwkeurig begrip van het BGP-beleid voor buurlanden: 

— pass-all (met name bij een grensrouter) kan verwoesting veroorzaken terwijl de geheugenschaal omhoog schiet. 

— Gebruik beleidsconstructies die reguliere expressieovereenkomsten in RPL voorkomen.  

■ Met NSR zal standby RP ongeveer 30% meer virtueel geheugen gebruiken dan actief. Houd hier rekening mee als er een standby is. 

■ Let op continue karnvorming op een aanzienlijk aantal routes (versiebobbels). Hierdoor kan het geheugen van de updategeneratie hoog watermerk houden. 

■ Bescherm peers met max-prefixknop.  

■ Gebruik next-hop-trigger vertragingsparameters volgens schaal- en convergentiedoelstellingen. 

■ Probeer in het netwerkontwerp nieuwe eigenschappen te vermijden. Unieke kenmerken leiden tot inefficiënte verpakking en resulteren in meer BGP-updates.  

■ Het configureren van meerdere paden in het netwerk kan leiden tot het doorsturen van loops. Gebruik het voorzichtig.  

■ Gebruik het tabelbeleid om te voorkomen dat de route aan de rib wordt geïnstalleerd als RR niet inline-RR is (geen next-hop-self)   

Monitorsysteemgeheugen voor routingprocessen

Geen apparaat heeft oneindig veel middelen - als we een oneindig aantal routes naar een apparaat verzenden, moet het apparaat kiezen hoe het faalt. De routers zullen proberen om alle routes te onderhouden tot de geheugengrenzen worden uitgeput, en dit kan alle routeringsprotocollen en processen veroorzaken om te mislukken.  

Elk proces in de kernrouter heeft een "RLIMIET" gedefinieerd. De "RLIMIET" is de hoeveelheid systeemgeheugen die elk proces mag verbruiken.   

In dit gedeelte worden enkele standaardtechnieken beschreven om het systeemgeheugen te controleren dat door het BGP-proces wordt gebruikt. 

Procesgeheugen  

Toont de hoeveelheid geheugen die door een proces wordt verbruikt.

RP/0/RP0/CPU0:NCS-5501#show-proc geheugen  

JID Text(KB) Data(KB) Stack(KB) Dynamisch(KB) Proces  

------ ---------- ---------- ---------- ----------- ------------------------------  

1150/896 368300 136 33462 lspv_server  

380 316 1877872 136 32775 parser_server  

1084 2092 2425220 136 31703 bgp  

1260 1056 1566272 160 31691 ipv4_rib  

1262 1304 1161960 152 28962 ipv6_rib  

1277 4276 1479984 136 21555 pim6  

1301 80 227388 136 21372 schema_server  

1276 4272 1677244 136 20743  

250 124 692436 136 20647 invmgr_proxy  

1294 4540 2072976 136 20133 l2vpn_mgr  

211 212 692476 136 19408 sdr_invmgr  

1257 4 679752 136 17454 status_manager_g  

 

Elk proces krijgt een maximale hoeveelheid geheugen toegewezen die het mag gebruiken. Dit wordt gedefinieerd als de limiet.  

RP/0/RP0/CPU0:NCS-5501#show-geheugen  

Dynamisch Shm-tot PHY-Tot-proces met Dyn-Limit (JID-tekststack)  

============================================================================================================  

1150/896K/359M/136K/32M/1024M/18M/24M LSPV_server  

1084 2M 2368M 136K 30M 7447M 43M 69M bgp  

1260 1M 1529M 160K 30M 8192M 38M 52M IPV4_rib  

380 316K 1833M 136K 29M 2048M 25M 94M parser_server  

1262 1M 1134M 152K 28M 8192M 22M 31M IPV6_rib  

1277 4M 1445M 136K 21M 1024M 18M 41M PIM6  

1301 80K 222M 136K 20M 300M 5M 33M schema_server  

1276 4M 1637M 136K 20M 1024M 19M 41M PIM  

250 124K 676M 136K 20M 1024M 9M 31M invmgr_proxy  

1294 4M 2024M 136K 19M 1861M 48M 66M l2vpn_mgr  

211 212K 676M 136K 18M 300M 9M 29M sdr_invmgr  

1257 4K 663M 136K 17M 2048M 20M 39M statsd_manager_g  

288 4K 534M 136K 16M 2048M 15M 33M status_manager_l  

...    

Belangrijkste geheugengebruikers  

RP/0/RP0/CPU0:NCS-5501#show geheugen-top-consumenten  

###########################################################################  

 Belangrijkste geheugenconsumenten op 0/0/CPU0 (bij 2022/apr/13/15:54:12)  

###########################################################################  

    Totale PID-proces (MB) Hoop (MB) gedeeld (MB)  

   3469 fia_driver 826 492.82 321  

   4091 fib_mgr 175 1094,43 155  

   3456 spp.  

   4063 dpa_port_mapper 108 1.12 105  

   3457 pakket 104 1,36 101  

   5097 l2fib_mgr 86 52.01 71  

   4147 bfd_agent 78 6.66 66  

   4958 eth_intf_ea 66 4.76 61  

   4131 optische driver 62 141.23 22  

   4090 ipv6_nd 55 4,13 49  

###########################################################################  

 Belangrijkste geheugenconsumenten op 0/RP0/CPU0 (op 20x/MMM/HH:MM:SS)  

###########################################################################  

    Totale PID-proces (MB) Hoop (MB) gedeeld (MB)  

   3581 spp.  

   4352 dpa_port_mapper 106 2,75 102  

   4494 fib_mgr 99 7,71 90  

   3582 pakket 96 1,48 94  

   3684 parser_server 95 64.27 25  

   814 te_control 71 15.06 55  

   890 bgp 70 27,61 44  

   7674 l2vpn_mgr 67 23,64 48  

   8376 mibd_interface 65 35.28 28  

   3608 sap 65 15,75 48   

Totaal geheugen - gebruikt en beschikbaar  

Systeemcomponenten hebben een vaste hoeveelheid geheugen beschikbaar.  

RP/0/RP0/CPU0:NCS-5501#show geheugen samenvatting locatie alles  

knooppunt: knooppunt0_0_CPU0  

------------------------------------------------------------------  

 Fysiek geheugen: 8192M totaal (6172M beschikbaar)  

 Toepassingsgeheugen: 8192M (6172M beschikbaar)  

 Afbeelding: 4M (bootram: 0M)  

 Gereserveerd: 0M, IOMem: 0M, flashfsys: 0M  

 Totaal gedeeld venster: 226M  

knooppunt: knooppunt0_RP0_CPU0  

------------------------------------------------------------------  

 Fysiek geheugen: 18432M totaal (15344M beschikbaar)  

 Toepassingsgeheugen: 18432M (15344M beschikbaar)  

 Afbeelding: 4M (bootram: 0M)  

 Gereserveerd: 0M, IOMem: 0M, flashfsys: 0M  

 Totaal gedeeld venster: 181M  

 

Het venster voor gedeeld geheugen biedt informatie over de gedeelde geheugentoewijzingen op het systeem.  

RP/0/RP0/CPU0:NCS-5501#show geheugen samenvatting detaillocatie 0/RP0/CPU0  

knooppunt: knooppunt0_RP0_CPU0  

------------------------------------------------------------------  

 Fysiek geheugen: 18432M totaal (15344M beschikbaar)  

 Toepassingsgeheugen: 18432M (15344M beschikbaar)  

 Afbeelding: 4M (bootram: 0M)  

 Gereserveerd: 0M, IOMem: 0M, flashfsys: 0M  

 Gedeeld venster soasync-app-1: 243.328K  

 Gedeeld venster soasync-12: 3.328K  

 ...  

 Gedeeld venster herschrijven-db: 272.164K  

 Gedeeld venster l2fib_brg_shm: 139.758K  

 Gedeeld venster im_rules: 384.211K  

 Gedeeld venster grid_svr_shm: 44.272M  

 Gedeeld venster spp: 86.387M  

 Gedeeld venster im_db: 1.306M  

 Totaal gedeeld venster: 180.969M  

 Toegewezen geheugen: 2,337G  

 Programma Tekst: 127.993T  

 Programmagegevens: 64.479G  

 Programmastack: 2.034G  

Systeem RAM: 18432M ( 19327352832)  

Totaal gebruikt: 3088M ( 3238002688)  

 Tweedehands: 0M ( 0)  

 Gebruikt gedeeld: 3088M ( 3238002688)  

 

U kunt de deelnemersprocessen met een gedeeld geheugenvenster controleren.  

RP/0/RP0/CPU0:NCS-5501#sh shmwin spp deelnemers lijst  

Gegevens voor Window "spp":  

-----------------------------  

Lijst van huidige deelnemers:-  

NAAM PID JID-INDEX  

3581 113 0  

pakket 3582-345-1  

NCD 4362 432 2  

Noot 4354 234 3  

nsr_ping_reply 4371 291 4  

aib 4423 296 5  

ipv6_io 4497 430 6  

ipv4_io 4484 438 7  

fib_mgr 4494 293 8  

...  

SNMP 8171 1002 44  

8417.1030,45 ospf  

MPLS_ldp 7678 1292 46  

8980 1084,47 GBP  

CDP 9295 337 48  

RP/0/RP0/CPU0:NCS-5501#sh shmwin soasync-1 deelnemerslijst  

Gegevens voor venster "soasync-1":  

-----------------------------  

Lijst van huidige deelnemers:-  

NAAM PID JID-INDEX    

TCP 5584 168 0        

8980 1084 BGP    

 

Resourcemonitoring en -bewaking  

Geheugengebruik wordt bewaakt door een systeem waakhond in cXR en met Resmon in eXR.  

RP/0/RP0/CPU0:NCS-5501#show-waakhond-geheugenstatus  

---- knooppunt0_RP0_CPU0 ----  

Geheugeninformatie:  

    Fysiek geheugen: 18432,0 MB  

    Gratis geheugen: 15348,0 MB  

    Geheugenstaat : Normaal  

RP/0/RP0/CPU0:NCS-5501#  

RP/0/RP0/CPU0:NCS-5501#show watchdog drempel geheugen standaardlocatie 0/RP0/CPU0  

---- knooppunt0_RP0_CPU0 ----  

 Standaardgeheugendrempels:  

 Klein: 1843 MB ß—10%  

 Ernstig: 1474 MB ß-8%  

 Kritisch: 921.599 MB ß-5%  

Geheugeninformatie:  

    Fysiek geheugen: 18432,0 MB  

    Gratis geheugen: 15340,0 MB  

    Geheugenstaat : Normaal  

RP/0/RP0/CPU0:NCS-5501#  

RP/0/RP0/CPU0:NCS-5501(config)#watchdog drempelgeheugen?  

  <5-40> geheugenverbruik in percentage  

 

Er wordt een waarschuwing afgedrukt als de drempelwaarden worden overschreden.  

RP/0/RP0/CPU0:Feb 17 23:30:21.663 UTC: resmon[425]: %HA-HA_WD-4-MEMORY_ALARM: Geheugendrempel overschreden: Klein met 1840.000MB gratis. Vorige staat: Normaal  

RP/0/RP0/CPU0:Feb 17 23:30:21.664 UTC: resmon[425]: %HA-HA_WD-6-TOP_MEMORY_GEBRUIKERS_INFO: Top 5 consumenten van systeemgeheugen (1884160 Kbytes vrij):  

RP/0/RP0/CPU0:Feb 17 23:30:21.664 UTC: resmon[425]: %HA-HA_WD-6-TOP_MEMORY_USER_INFO : 0: Procesnaam: bgp[0], pid: 7861, Heap gebruik: 12207392 kbytes.  

RP/0/RP0/CPU0:Feb 17 23:30:21.664 UTC: resmon[425]: %HA-HA_WD-6-TOP_MEMORY_USER_INFO : 1: Procesnaam: ipv4_rib[0], pid: 4726, Heap gebruik: 708784 kbytes.  

RP/0/RP0/CPU0:Feb 17 23:30:21.664 UTC: resmon[425]: %HA-HA_WD-6-TOP_MEMORY_USER_INFO : 2: Procesnaam: fib_mgr[0], pid: 3870, Heap gebruik: 584072 kbytes.  

RP/0/RP0/CPU0:Feb 17 23:30:21.664 UTC: resmon[425]: %HA-HA_WD-6-TOP_MEMORY_USER_INFO : 3: Procesnaam: netconf[0], pid: 9260, Heap gebruik: 553352 kbytes.  

RP/0/RP0/CPU0:Feb 17 23:30:21.664 UTC: resmon[425]: %HA-HA_WD-6-TOP_MEMORY_USER_INFO : 4: Procesnaam: netio[0], pid: 3655, Heap gebruik: 253556 kbytes.  

LC/0/3/CPU0:Mar 8 05:48:58.414 PST: resmon[172]: %HA-HA_WD-4-MEMORY_ALARM: Geheugendrempel overschreden: Ernstig met 600.182MB vrij. Vorige staat: Normaal  

LC/0/3/CPU0:Mar 8 05:48:58.435 PST: resmon[172]: %HA-HA_WD-4-TOP_MEMORY_USER_WARNING: Top 5 consumenten van systeemgeheugen (624654 Kbytes vrij):  

LC/0/3/CPU0:Mar 8 05:48:58.435 PST: resmon[172]: %HA-HA_WD-4-TOP_MEMORY_USER_WARNING: 0: Procesnaam: fib_mgr[0], pid: 5375, Heap gebruik 1014064 Kbytes.  

LC/0/3/CPU0:Mar 8 05:48:58.435 PST: resmon[172]: %HA-HA_WD-4-TOP_MEMORY_USER_WARNING: 1: Procesnaam: ipv4_mfwd_partner[0], pid: 5324, Heap gebruik 185596 Kbytes.  

LC/0/3/CPU0:Mar 8 05:48:58.435 PST: resmon[172]: %HA-HA_WD-4-TOP_MEMORY_USER_WARNING: 2: Procesnaam: nfsvr[0], pid: 8357, Heap gebruik 183692 Kbytes.  

LC/0/3/CPU0:Mar 8 05:48:58.435 PST: resmon[172]: %HA-HA_WD-4-TOP_MEMORY_USER_WARNING: 3: Procesnaam: fia_driver[0], pid: 3542, Heap gebruik 177552 Kbytes.  

LC/0/3/CPU0:Mar 8 05:48:58.435 PST: resmon[172]: %HA-HA_WD-4-TOP_MEMORY_USER_WARNING: 4: Procesnaam: npu_driver[0], pid: 3525, Heap gebruik 177156 Kbytes.   

Sommige processen kunnen specifieke acties ondernemen op basis van de status van het horlogegeheugen. BGP doet bijvoorbeeld het volgende:  

■ in de minder belangrijke staat brengt BGP geen nieuwe peers meer op  

■ in de ernstige staat brengt BGP geleidelijk een aantal peers omlaag.  

■ in kritieke toestand wordt BGP-proces uitgeschakeld.  

Processen kunnen geconfigureerd worden om te registreren voor meldingen van geheugenstatus.  

Toon waakhond of-bewust-proces  

 

Gebruikers kunnen automatische processtopzetting uitschakelen vanwege de wachttijd van de waakhond.  

watchdog herstart geheugen-hog uitschakelen

Waar vindt u meer informatie?  

■ Cisco IOS XR-weblogs en Whitepapers-opslagplaats (xrdocs.io) 

■ Core Fabric Design: https://xrdocs.io/design/blogs/latest-core-fabric-hld : In dit artikel worden de recente trends en evolutie in core backbone-netwerken besproken.   

■ Peering Fabric Design: https://xrdocs.io/design/blogs/latest-peering-fabric-hld : Dit whitepaper biedt een uitgebreid overzicht van de uitdagingen en aanbevelingen voor best practices voor peering design met de nadruk op netwerkvereenvoudiging.  

Referentie ■-configuratiehandleiding: implementatie van BGP https://www.cisco.com/c/en/us/td/docs/iosxr/ncs5500/bgp/710x/b-bgp-cg-ncs5500-710x/implementing-bgp.html

Verbeteringen in functies