Inhoud
[UPDATE THE TABLE][UPDATE THE TABLE]
[UPDATE THE TABLE][UPDATE THE TABLE]
[UPDATE THE TABLE][UPDATE THE TABLE]
[UPDATE THE TABLE][UPDATE THE TABLE]
[UPDATE THE TABLE][UPDATE THE TABLE]
[UPDATE THE TABLE][UPDATE THE TABLE]
[UPDATE THE TABLE][UPDATE THE TABLE]
[UPDATE THE TABLE][UPDATE THE TABLE]
[UPDATE THE TABLE][UPDATE THE TABLE]
[UPDATE THE TABLE][UPDATE THE TABLE]
[UPDATE THE TABLE][UPDATE THE TABLE]
[UPDATE THE TABLE][UPDATE THE TABLE]
[UPDATE THE TABLE][UPDATE THE TABLE]
[UPDATE THE TABLE][UPDATE THE TABLE]
[UPDATE THE TABLE][UPDATE THE TABLE]
[UPDATE THE TABLE][UPDATE THE TABLE]
[UPDATE THE TABLE][UPDATE THE TABLE]
[UPDATE THE TABLE][UPDATE THE TABLE]
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.
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.
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
■ 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 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.
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
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.
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.
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>
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-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-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.
■ 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.
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.
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 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.
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
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:
%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)
Aanbeveling: evalueer zorgvuldig de volgende opties bij het configureren van de opdracht maximum-prefix:
Raadpleeg de Routing Configuration Guide als volgt voor meer informatie:
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/
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.
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.
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)
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.
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
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
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
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
■ 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
Autonoom systeem grens routerisolatie en aangrenzingscontrole voor LSA-overflows |
Geïntroduceerd in 7.10.1 op NCS 5500 vaste poortrouters: NCS 5700 vaste poortrouters In een netwerk dat gebruik maakt van een Autonomous System Boundary Router (ASBR) en andere routers, bent u nu verzekerd van ononderbroken verkeersstromen, zelfs als de ASBR LSA's genereert die de door u ingestelde limiet overschrijden. Dit is mogelijk omdat u nu ASBRs kunt isoleren en ook de duur van de nabijheid in de Exchange of LOADING fase kunt controleren. Door de ASBR te isoleren van zijn directe buren kan de resterende netwerktopologie blijven functioneren zonder onderbreking, waardoor nadelige gevolgen voor de verkeersstroom effectief worden voorkomen. Deze benadering vereenvoudigt ook het herstelproces, omdat handmatige interventie alleen nodig is voor de directe buren van de ASBR routers. Deze eigenschap introduceert deze veranderingen: CLI: YANG Data-model: · Cisco IOS-XR-IPv4-ospf-cfg.yang · Cisco IOS-XR-IPv4-ospf-oper.yang · Cisco 800-IOS-XR-um-router-ospf-cfg.yang (zie GitHub, YANG Data Models Navigator) |
In deze release geïntroduceerd op: NCS 5500 vaste poortrouters; NCS 5700 vaste poortrouters; NCS 5500 modulaire routers (NCS 5500 lijnkaarten; NCS 5700 lijnkaarten [Modus: Compatibiliteit; Native]) U kunt de router nu configureren om automatisch een BGP-buursessie opnieuw in te stellen die is uitgeschakeld omdat de maximale prefixlimiet is overschreden. Met deze functie worden de volgende wijzigingen geïntroduceerd: CLI YANG Data-model: · Nieuwe XPaths voor openconfig-bgp-Neighbor.yang(zie GitHub, YANG Data Modellen Navigator) |
|
Geïntroduceerd in 7.10.1 release op: NCS 5500 modulaire routers (NCS 5700 lijnkaarten [Modus: Native]) U kunt nu effectief BGP Flowspec gebruiken op Bridge-Group Virtual Interface (BVI) om verbinding te maken met uitzenddomeinen waarin hostapparaten zijn ondergebracht, zoals in het geval van ondernemingsnetwerken. Deze ondersteuning betekent dat uw klanten hun netwerken kunnen beveiligen tegen netwerkbedreigingen zoals gedistribueerde Denial of Service (DDoS)-aanvallen die binnenkomen via de BVI. |
|
Geïntroduceerd in 7.10.1 release op: NCS 5500 vaste poortrouters; NCS 5700 vaste poortrouters; NCS 5500 modulaire routers (NCS 5500 lijnkaarten; NCS 5700 lijnkaarten [Modus: Compatibiliteit; Native]) U kunt nu voorkomen dat de sessie opnieuw wordt ingesteld wanneer een BGP-sessie fouten tegenkomt tijdens het parseren van het ontvangen updatebericht. Dit is mogelijk omdat de functie het verwerpen van het inkomende updatebericht als een trekkingsbericht toelaat. CLI: · update in foutenbehandeling verhandeling-als-terugtrekken YANG Data-model: · Nieuwe XPaths voor openconfig-bgp-Neighbour.yang (zie GitHub, YANG Data Modellen Navigator) |
|
Uitsluiting van labeltoewijzing voor niet-geadverteerde routes |
Geïntroduceerd in 7.10.1 release op: NCS 5500 vaste poortrouters; NCS 5700 vaste poortrouters; NCS 5500 modulaire routers (NCS 5500 lijnkaarten; NCS 5700 lijnkaarten [Modus: Compatibiliteit; Native]) We hebben een beter label ruimtebeheer en het gebruik van hardwareresources mogelijk gemaakt door de MPLS-labeltoewijzing flexibeler te maken. Deze flexibiliteit betekent dat u deze labels nu kunt toewijzen aan alleen die routes die worden geadverteerd naar hun peer routes, waardoor een beter label ruimtebeheer en gebruik van hardwareresources. Vóór deze release werd de label toegewezen, ongeacht of de routes werden geadverteerd. Dit resulteerde in inefficiënt gebruik van labelruimte. |
Bescherming van direct verbonden EBGP-buren via op interface gebaseerde LPTS-identificatie |
Geïntroduceerd in 7.10.1 release op: NCS 5500 vaste poortrouters We hebben de netwerkbeveiliging voor direct aangesloten eBGP-buren verbeterd door ervoor te zorgen dat alleen pakketten die afkomstig zijn van aangewezen eBGP-buren door één interface kunnen worden gepasseerd, waardoor IP-spoofing wordt voorkomen. Dit is mogelijk omdat we nu een interface-identifier hebben toegevoegd voor lokale pakkettransportservices (LPTS). LPTS-filters en -toezicht op de pakketten op basis van het type debiet dat u vormt. Deze functie introduceert het volgende: CLI: YANG Data-model: · Cisco 800-IOS-XR-um-router-bgp-cfg (zie GitHub, YANG Data Models Navigator) |
Verminder de kans op herhaling voor eBGP-peer op Loopback Address op Bridge-Group Virtual Interface |
Geïntroduceerd in 7.10.1 release op: NCS 5500 modulaire routers (NCS 5700 lijnkaarten [Modus: Native]) U kunt nu eBGP-peer op Loopback-interfaces op Bridge-Group Virtual Interface (BVI) realiseren en het recursieniveau van drie naar twee verlagen. Deze vermindering van het recursieniveau, die wordt bereikt door de behoefte te verwijderen om de naam BVI in de configuratie van statische routes te gebruiken, staat sneller pakket toe door:sturen en beter gebruik van netwerkmiddelen. |
Geïntroduceerd in release 7.9.1: Border Gateway Protocol (BGP) beleidsmaatregelen voor accounting en classificeert IP-verkeer dat wordt ontvangen van verschillende peers. U kunt al het verkeer per klant en rekening dienovereenkomstig identificeren en verantwoorden. Beleidsaccounting is ingeschakeld op basis van een individuele input-interface. Met BGP-beleidsaccounting kunt u nu rekening houden met verkeer volgens de route die het doorkruist. Deze optie wordt nu ondersteund op routers die de op Cisco NC57 gebaseerde lijnkaarten met externe TCAM (eTCAM) hebben en in de native modus werken. Deze eigenschap introduceert deze veranderingen: · CLI: De functie introduceert de hw-module fib bgppa stats-mode opdracht. · YANG Data Model: Nieuwe XPaths voor Cisco-IOS-XR-um-hw-module-profile-cfg.yang (zie GitHub, YANG Data Models Navigator) |
|
Ingebracht in release 7.9.1: BGP-peers verwerken de inkomende BGP-updateberichten tegen verschillende snelheden. Een slow peer is een peer die inkomende BGP update-berichten zeer langzaam verwerkt over een lange periode in vergelijking met andere peers in de update-subgroep. Langzame peer-handling is belangrijk wanneer routes voortdurend veranderen over een lange periode. Het is belangrijk om verouderde informatie in de wachtrij op te schonen en alleen de laatste status te versturen. Het is handig om te weten of er een traag peer is, die aangeeft dat er een netwerkprobleem is, zoals aanhoudende netwerkstremming of een ontvanger die geen updates op tijd verwerkt, die de netwerkbeheerder kan aanpakken. |
|
Geïntroduceerd in release 7.9.1: De niet-zelf-gegenereerde link-state advertenties (LSA's) voor een bepaald Open Shortest Path First (OSPF) proces zijn beperkt tot 500000. Dit beschermingsmechanisme voorkomt dat routers veel LSA's ontvangen, waardoor CPU-uitval en geheugentekorten worden voorkomen, en wordt standaard ingeschakeld vanaf deze release. Als u meer dan 500000 LSA's in uw netwerk hebt, configureer dan de max-LSA-opdracht met de verwachte LSA-schaal voordat u een upgrade uitvoert naar deze release of hoger. Deze eigenschap wijzigt de volgende opdrachten: · toon ospf om het maximumaantal herverdeelde prefixes te tonen. · toon ospf gegevensbestand-samenvatting detail om het aantal tellingen LSA per router te tonen. · toon ospf gegevensbestand-samenvatting adv-router ID om de routerinformatie en LSAs te tonen die van een bepaalde router wordt ontvangen. |
|
Het beperken van de maximale herverdeelde type-3 LSA-prefixes in OSPF |
Geïntroduceerd in release 7.9.1: Standaard is de maximale herverdeelde Type-3 LSA prefixes voor een gegeven OSPF-proces nu beperkt tot 100000. Dit mechanisme verhindert OSPF een groot aantal prefixes als Type-3 LSAs opnieuw te verdelen en daarom hoge CPU-benutting en geheugentekorten te voorkomen. Zodra het aantal opnieuw gedistribueerde prefixes is bereikt of de drempelwaarde overschrijdt, wordt het systeemlogbericht gegenereerd en worden er geen prefixes meer opnieuw gedistribueerd. |
Revisie | Publicatiedatum | Opmerkingen |
---|---|---|
2.0 |
15-Feb-2024 |
Werkte de opdrachtreferentie link bij. |
1.0 |
23-Jul-2022 |
Eerste vrijgave |