Projecten op grote schaal met ODR ontwerpen.
Inhoud
Inleiding
On-Demand Routing (ODR) is een versterking van Cisco Discovery Protocol (CDP), een protocol dat wordt gebruikt om andere Cisco-apparaten te ontdekken op basis van uitzending of niet-uitzending van media. Met de hulp van CDP, is het mogelijk om het apparaattype, het IP-adres, de Cisco IOS® versie die op het buurapparaat van Cisco draait, de mogelijkheden van het buurapparaat, enzovoort te vinden. In Cisco IOS-softwarerelease 11.2 is ODR aan CDP toegevoegd om het aangesloten IP-prefix van een router via CDP te adverteren. Deze eigenschap neemt extra vijf bytes voor elk netwerk of elk subnet, vier bytes voor het IP adres, en één byte om het subnetmasker samen met het IP te adverteren. ODR kan informatie over sub-masker (VLSM) met variabele lengte dragen.
ODR is ontworpen voor kleinhandelsklanten die hun netwerkbandbreedte niet willen gebruiken voor het routeren van protocol updates. In een milieu X.25, bijvoorbeeld, is het vaak zeer duur om een routingprotocol over die verbinding uit te voeren. De statische routing is een goede keuze, maar er is te veel overhead om de statische routes handmatig te onderhouden. ODR is niet CPU-intensief en wordt gebruikt om IP-routes dynamisch via Layer 2 te propageren.
ODR is geen routingprotocol en dient als zodanig niet te worden behandeld bij het configureren van het protocol. Traditionele configuraties voor verschillende IP-routingprotocollen werken niet in ODR, omdat ODR gebruik maakt van CDP op Layer 2. Om ODR te configureren gebruikt u de opdracht router of opdracht op de router van het hub-router. Het ontwerp, de implementatie, en de interactie van ODR met andere IP routingprotocollen kunnen moeilijk zijn.
ODR werkt niet op Cisco 700 Series routers of ATM-koppelingen met uitzondering van LAN-emulatie (LANE).
Stub-netwerken vs. transitnetwerken
Wanneer er geen informatie door het netwerk gaat, is het een statief netwerk. De hub-en de gesproken topologie is een goed voorbeeld van een stunnetwerk. Grote organisaties met veel sites die zijn aangesloten op een datacenter gebruiken dit type topologie.
Routers met kleine uitgangen, zoals Cisco 2500, 1600 en 1000 Series routers worden aan de gesproken kant gebruikt. Als de informatie door spaakrouters passeert om aan een ander netwerk te geraken, wordt die stoomrouter een doorvoerrouter. Deze configuratie komt voor wanneer een gesproken wordt aangesloten op een andere router behalve de hub router.
Een gemeenschappelijk zorg is hoe groot een ODR update een sprak kan sturen. Normaal gesproken worden spokes alleen op een hub aangesloten. Als spaken zijn verbonden met andere routers, zijn ze niet langer stopcontact en worden ze een transitnetwerk. Lage-eindboxen hebben meestal een of twee LAN interfaces. Cisco 2500 kan bijvoorbeeld twee LAN-interfaces ondersteunen. In normale situaties wordt een pakket van 10 bytes verzonden (voor het geval er twee LAN’s aan de gesproken kant zijn) als deel van CDP. CDP wordt standaard ingeschakeld, dus er is geen probleem met extra overhead. Er zal nooit een situatie zijn waarin er een grote ODR-update is. De omvang van de ODR-updates zal geen probleem zijn in een ware 'hub and sprak'-omgeving.
Hub-and-Spoke netwerken en ODR.
Een hub-en-zogenaamd netwerk is een typisch netwerk waar een hub (geavanceerde router) veel spaken (lage routers) dient. In speciale gevallen kan er meer dan één hub zijn, voor redundantiedoeleinden of om extra spokes via een afzonderlijk hub te ondersteunen. In deze situatie, laat ODR op beide knooppunten toe. Het is ook noodzakelijk om een routingprotocol te hebben om ODR te ruilen routinginformatie tussen de twee knooppunten.
Afbeelding 1: Hub-en-Spaanstalige topologie 
Spoelen met één uitgang
In afbeelding 1 hierboven, worden de spaken aangesloten op één hub zodat ze op de standaardgateway kunnen vertrouwen in plaats van alle routinginformatie voor het hub met één exitpunt te ontvangen. Het is niet nodig alle informatie door te geven aan de woordvoerders, aangezien een gesproken persoon geen intelligent routebesluit hoeft te nemen. Een uitgetekend zal altijd het verkeer naar de hub sturen, zodat de woordjes slechts een standaardroute nodig hebben die naar een hub wijst.
Er moet een manier zijn voor de van de gesproken informatie naar de hub te worden verzonden. Vóór Cisco IOS 11.2, was de enige manier om dit te bereiken een routeringsprotocol in het SPS toe te laten. Gebruikend ODR, echter, hoeven de routingprotocollen niet aan de gesproken kant te worden ingeschakeld. Met ODR, zijn alleen Cisco IOS 11.2 en een statische standaardroute naar een hub nodig op het spraken.
Spoelen met meerdere exitpunten
Een spraken kan meerdere verbindingen naar de hub hebben voor overtolligheid of reservedoeleinden in het geval van de primaire verbinding. Een afzonderlijk knooppunt is vaak vereist voor deze redundantie. In deze situatie hebben de woordvoerders meerdere exitpunten. ODR werkt ook goed in dit netwerk.
De punten moeten punt-aan-punt zijn, anders zal de drijvende statische standaardroute niet werken. In een multi-point configuratie is er geen manier om een mislukking van de volgende hop te detecteren, net zoals in een uitzending media.
Taakverdeling of back-up met één hub
Om het in evenwicht brengen van lading te bereiken, definieer twee statische standaardroutes op spokes met de zelfde afstand en de gesproken zal lading het in evenwicht brengen tussen die twee paden doen. Als er twee paden aan de bestemming zijn, zal ODR beide routes in de Routing Tabel houden en lading in evenwicht brengen op de hub.
Voor back-ups, definieer twee statische standaardroutes met een afstand beter dan de andere. De spits zal de primaire verbinding gebruiken en, wanneer de primaire verbinding daalt, zal de drijvende statische route werken. In de hub router, gebruik het afstand bevel voor elk CDP buuradres en maak één afstand beter dan het andere. Met deze configuratie zullen de ODR-routes die door de ene link zijn geleerd, de voorkeur genieten boven de andere. Deze configuratie is handig in een omgeving waar er snelle primaire koppelingen zijn en langzame (lage bandbreedte) back-uplinks en waar taakverdeling niet gewenst is.
Opmerking: Vandaag de dag is er geen andere methode aan de uitsparende zijde om de voorkeur te geven aan één link boven de andere in één enkel knooppunt, behalve zoals hierboven is beschreven. Als u IOS 12.0.5T of later gebruikt, verstuurt de hub automatisch de standaardroute via beide verbindingen en de toespraak kan geen onderscheid maken tussen de twee paden en zal beide in zijn routing tabel installeren. De enige manier om de voorkeur te geven aan één standaardroute boven de andere is door een statische standaardroute op de toespraak te gebruiken die een pad met een lagere admin afstand heeft waarvoor u wilt prefereren. Dit overschrijdt automatisch de standaardroutes die op de woordjes via ODR komen. Momenteel wordt het idee overwogen om de spreker een knop te geven, waarbij hij de ene link boven de andere kan prefereren.
Afbeelding 2: Spellen met meerdere exitpunten en één hub 
Taakverdeling of back-up met meerdere hubs
Deze configuraties kunnen ook worden gebruikt voor taakverdeling of back-ups wanneer er meerdere knooppunten zijn. Alle hubs moeten volledig worden gebogen zodat als een van de koppelingen van de spaken mislukt, de bestemming nog steeds via een tweede hub kan worden bereikt. Zie het gedeelte ODR vs. Overige routingprotocollen van dit document voor een gedetailleerdere uitleg. Op dezelfde manier, in het geval van meerdere knooppunten, als IOS 12.0.5T of later in gebruik is, verzenden de knooppunten de ODR standaardroutes naar woordspelden en de spaken installeren beiden in de routing tabel. Een toekomstige verbetering zal een uitgeweken persoon de voorkeur geven aan het ene hub boven het andere. Op dit moment kan dit gedaan worden door een statische standaardroute die op de router van de toespraak en het gebruik van admin afstand in het statische routebevel wordt gedefinieerd om één hub over het andere te prefereren. Dit heeft geen invloed op belastingsbalanceringssituaties.
Afbeelding 3: Spuiten met meerdere exit-punten en meerdere knooppunten 
ODR vs. Overige routingprotocollen
Het grootste voordeel van de ODR over IP-routing is dat de hubrouter IP-prefixes zal leren zonder routing protocollen op Layer 3 mogelijk te maken. De ODR-updates maken deel uit van CDP op Layer 2.
ODR vs.
In een ware hub-and-sprak omgeving is het onnodig om alle routinginformatie aan alle woordvoerders door te geven. Slow-link verspilt bandbreedte in het routeren van updates en het onderhouden van buurrelaties. Door het Uitgebreide Interior Gateway Routing Protocol (DHCP) op de spaken in te schakelen wordt routing updates naar de spaken verzonden. In grote netwerken worden deze updates enorm, verspillen zij bandbreedte van CPU, en kunnen meer geheugen op gesproken routers vereisen.
Een betere benadering met DHCP is filters op het centrum toe te passen. De routinginformatie wordt gecontroleerd zodat de knooppunten alleen een standaardroute dynamisch naar de woordjes sturen. Deze filters helpen de grootte van de routingtabel aan de gesproken kant te verminderen, maar als de hub een buurman verliest, zal zij vragen naar alle andere buren sturen. Deze vragen zijn onnodig omdat de hub nooit een antwoord van een buurman zal krijgen.
De beste benadering is het elimineren van de overheadkosten van vraag Ecro en buuronderhoud die ODR gebruikt. Door de ODR-timers aan te passen kan de convergentietijd worden verlengd.
Vandaag, hebben we een nieuwe eigenschap in Ecp die veel beter RKER in een hub en gesproken situatie schalen. Raadpleeg het gedeelte Enhanced IGRP stub-routing voor meer informatie over de optie DHCP-bestand.
ODR vs. OSPF
Open Shortest Path First (OSPF) biedt verschillende opties voor hub-and-sprak omgevingen, en de staaf no-summary optie heeft de minste overhead.
U kunt problemen ondervinden wanneer OSPF op grote schaal hub-and-sprak netwerken wordt uitgevoerd. De voorbeelden in deze sectie gebruiken Frame Relay omdat het de meest algemene hub-en-gesproken topologie is.
OSPF-point-to-point breedbandnetwerken
In dit voorbeeld wordt OSPF ingeschakeld op 100 spokes die aangesloten zijn door een point-to-point configuratie. Eerst is er een hoop verspilde IP adressen, zelfs als wij met een /30 netwerkmasker. Ten tweede, als we die 100 spokes in één gebied opnemen en één gesproken wordt ontvlamt, zal het kortste pad eerste (SPF) algoritme lopen en kan CPU-intensief worden. Deze situatie is in het bijzonder waar voor gesproken routers als de link voortdurend faalt. Méér buurflaps kan problemen veroorzaken waar het gaat om verspreide routers.
In OSPF is het gebied verstopt en niet de interface. Als er 100 routers in een stopnetwerk zijn, is meer geheugen op de spaken nodig om de grote database vast te houden. Dit probleem kan worden opgelost door een groot gebied in een klein gebied te verdelen. Een flap in één staafgebied zal echter nog steeds SPF's op de spaken laten draaien, zodat deze overhead niet kan worden genezen door een klein staafgebied te maken zonder samenvatting en zonder externe factoren.
Een andere optie is elke link naar één gebied toe te voegen. Met deze optie, zal de router van het hub een afzonderlijk SPF algoritme voor elk gebied moeten lopen en een summiere verbinding-staat reclame (LSA) voor routes in het gebied maken. Deze optie kan de prestaties van de hub router schaden.
Een verbetering naar een beter platform is geen permanente oplossing; ODR biedt echter een oplossing. Routes die via ODR zijn geleerd, kunnen opnieuw worden gedistribueerd in OSPF om andere routers over deze routes te informeren.
OSPF-to-Multipoint Stub-netwerken
In point-to-multipoint netwerken wordt IP-adresruimte opgeslagen door elk op dezelfde inhoud te zetten. Ook zal de grootte van het router LSA hub dat wordt gegenereerd worden gehalveerd aangezien het slechts één stub verbinding voor alle point-to-point links zal genereren. Een point-to-multipoint netwerk zal het hele netwerk dwingen om in één gebied te worden opgenomen. Bij een link-flap wordt SPF uitgevoerd, dat CPU-intensief kan zijn.
De Hallo Storm
OSPF-hallo-pakketten zijn klein, maar als er te veel buren zijn, kan hun grootte groot worden. Aangezien hellos multicast zijn, verwerkt de router de pakketten. Het OSPF-hub verstuurt en ontvangt hallo-pakketten die bestaan uit 20 bytes van IP-header, 24 bytes van OSPF-header, 20 bytes van hallo-parameters en 4 bytes voor elke bekeken buren. Een OSPF-hallo-pakket van een hub in een point-to-multipoint netwerk met 100 buren kan 464 bytes lang worden en zal elke 30 seconden worden overstroomd naar alle spokes.
Tabel 1: OSPF-hallo-pakket voor 100 buren| 20 bytes IP-header |
| 24 bytes OSPF-header |
| 20 bytes hallo parameters |
| 4 bytes per buurrouter-ID (RID) |
| . . . |
| . . . |
| . . . |
| . . . |
| . . . |
De overhead wordt opgelost in ODR omdat er geen extra informatie wordt verzonden van de hub naar de spaken. De spaken verzenden het IP prefix van 5 bytes per voorwerp naar de hub router. Gezien de grootte van het hallo pakket, vergelijk de 5 bytes in ODR (het gesproken verzenden van informatie van één aangesloten netwerk) aan de 68 bytes van OSPF (de kleinste hallo-pakketgrootte inclusief een IP-kop die van het gesproken wordt naar het hub) plus 68 bytes (het kleinste hallo-pakket verzonden van het hub naar het gesproken) tijdens een 30 seconden interval. Tevens gebeurt het OSPF-gereedschap op Layer 3 terwijl de ODR-updates op Layer 2 voorkomen. Met ODR wordt veel minder informatie verzonden, zodat de link-bandbreedte kan worden gebruikt voor belangrijke gegevens.
ODR vs. RIPv2
Routing Information Protocol versie 2 (RIPv2) is ook een goede keuze voor hub-and-sprak omgevingen. Om RIPv2 te ontwerpen, verstuur de standaardroute van de hub naar de spaken. De spaken adverteren vervolgens hun verbonden interface via RIP. RIPv2 kan worden gebruikt wanneer er secundaire adressen op de spaken zijn die moeten worden geadverteerd of wanneer verscheidene verkooprouters worden gebruikt of wanneer de situatie niet echt een hub is en wordt gesproken.
RIPv2 over vraag
Versie 2 heeft een paar wijzigingen, maar het protocol wordt niet drastisch gewijzigd. In dit deel worden een paar verbeteringen aan RIP besproken voor vraagcircuits.
De huidige internetwerken bewegen in de richting van dialoognetwerken of back-ups van primaire sites om verbindingen te maken met een groot aantal externe sites. Zulke typen verbindingen kunnen bij normaal gebruik zeer weinig of geen gegevensverkeer doorstaan.
Het periodiek gedrag van RIP veroorzaakt problemen op deze circuits. RIP heeft problemen met lage bandbreedte, punt-tot-punt interfaces. De updates worden verzonden elke 30 seconden met grote routeringstabellen die hoge bandbreedte gebruiken. In deze situatie is het het beste gebruik te maken van de verbonden RIP.
Verweven RIP
Geïntrigeerde RIP wordt ontworpen voor routers die alle routinginformatie met hun buur uitwisselen. Als de veranderingen in de routing plaatsvinden, worden alleen de veranderingen naar de buurman doorgeleid. De ontvangende router past de veranderingen onmiddellijk toe.
Gedrukte RIP updates worden slechts verzonden wanneer:
-
Een verzoek om een routingupdate wordt ontvangen.
-
Nieuwe informatie wordt ontvangen.
-
De bestemming is van circuit naar circuit omhoog veranderd.
-
De router wordt eerst ingeschakeld.
Hieronder volgt een configuratievoorbeeld voor de verbonden RIP:
Spoke# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Spoke(config)# int s0.1
Spoke(config-if)# ip rip triggered
Spoke(config)# int s0.2
Spoke(config-if)# ip rip triggered
interface serial 0
encapsulation frame-relay
interface serial 0.1 point /* Primary PVC */
ip address 10.x.x.x 255.255.255.0
ip rip triggered
frame-relay interface-dlci XX
interface serial 0.2 point /* Secondary PVC */
ip address 10.y.y.y 255.255.255.0
ip rip triggered
frame-relay interface-dlci XX
router rip
network 10.0.0.0
Spoke# show ip protocol
Routing Protocol is "rip"
Sending updates every 30 seconds, next due in 23 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Redistributing: rip
Default version control: send version 1, receive any version
Interface Send Recv Triggered RIP Key-chain
Ethernet0 1 1 2
Serial0.1 1 1 2 Yes
Serial0.2 1 1 2 Yes
Routing for Networks:
10.0.0.0
Routing Information Sources:
Gateway Distance Last Update
Distance: (default is 120)
De ip rip-getriggerde opdracht moet worden ingesteld op de interface van de hub router en op de spokes worden aangesloten.
Wanneer u RIPv2 met ODR vergelijkt, is ODR een betere keuze omdat RIPv2 op Layer 3 werkt en ODR op Layer 2 plaatsvindt. Wanneer de hub RIPv2 updates naar meer dan 1000 spokes stuurt, moet zij het pakket op Layer 3 herhalen voor elke gesproken persoon. ODR stuurt niets van het hub behalve de gebruikelijke CDP-update elke minuut op Layer 2, wat helemaal niet CPU-intensief is. Het verzenden van aangesloten subnetinformatie in Layer 2 van het gesproken wordt veel minder CPU intensief dan het verzenden van RIPv2 op Layer 3.
Grootschalig netwerkontwerp met ODR
ODR werkt beter in een netwerk op grote schaal dan elk ander routeringsprotocol. Het grootste voordeel van ODR is dat het routeren van protocollen niet hoeft te worden ingeschakeld op de aangesloten seriële links. Op dit moment zijn er geen routingprotocollen waarmee u routinginformatie kunt verzenden zonder deze op de aangesloten interface te activeren.
ODR met EDRG die op Hubs draait
Wanneer het in werking stellen van DHCP, maak een passieve interfaceverbinding aan het spits-en-spaaknetwerk zodat het geen onnodige hulp Ecp op de verbinding zal sturen. Indien mogelijk, is het beter om geen netwerkverklaringen voor netwerken tussen de hub en spokes te plaatsen omdat, als de verbinding daalt, zal DHCP geen onnodige vragen naar de kernburen sturen. Kies altijd een bogus netwerk tussen de hub en spokes zodat deze verbindingen niet in het domein zullen worden inbegrepen omdat u geen netwerkverklaringen in de configuraties zult plaatsen.
Redundantie en samenvatting
In één enkele hub-situatie zijn geen extra instellingen vereist. Vat de specifieke, verbonden subnetten van de woordjes samen en lek ze naar de kern. Maar de overheadkosten van de vragen zullen er altijd zijn. Als de specifieke routes van één van de spaken verloren zijn, stuur de vragen aan alle buren in de kernrouters door.
In het geval van meerdere hubs, is het zeer belangrijk dat beide hubs verbonden zijn en dat wanneer wanneer u een NHL instelt, de NHU's elkaar in werking stellen. Indien mogelijk moet deze link een uniek groot net zijn, zodat het niet interfereert met andere links die naar de woordjes gaan. Deze configuratie is noodzakelijk omdat kon worden toegelaten op een specifieke interface, zodat zelfs als wij de interface passief maken, het nog zal worden geadverteerd via DHCP. Als de interface is samengevat, worden de vragen nog steeds verzonden als iemand die wordt gesproken, is kwijtgeraakt. Zolang het verband tussen de twee hubs niet in het zelfde grote net zoals de spaken is, zou de configuratie goed moeten werken.
Afbeelding 4: Redundantie en samenvatting: De kern ontvangt samengevatte routes 
Een voordeel is dat het kan samenvatten op het interfaceniveau, dus de samengevatte route van spaaksubnetten zal naar de kern worden gestuurd en het zal een specifiekere route naar de andere hub sturen. Als de verbinding tussen een hub en een spits omlaag gaat, is het mogelijk om de bestemming via de tweede hub te bereiken.
ODR met OSPF-run op Hubs
In dit scenario hoeft OSPF niet te worden ingeschakeld op de link die de spaken verbindt. In een normaal scenario, als OSPF op de link is ingeschakeld en één specifieke link constant flappelt, kan het verschillende problemen veroorzaken, waaronder uitvoering van SPF, herstel van router LSA, summiere LSA regeneratie, etc. Wanneer ODR wordt uitgevoerd, neem dan niet de aangesloten seriële link op in het OSPF-domein. Het belangrijkste probleem is om de informatie over het LAN-segment van de spaken te ontvangen. Deze informatie kan worden verkregen via ODR. Als één verbinding constant flappelt, zal het niet met het Routing protocol in de hub router interfereren.
Redundantie en samenvatting
Alle specifieke koppelingen kunnen worden samengevat voordat ze in de kern lekken om routeberekening te vermijden als een van de aangesloten interfaces van een toespraak wordt afgebroken. Het kan niet worden gedetecteerd als de informatie over de kernrouter wordt samengevat.
Afbeelding 5: Redundantie en samenvatting: De kernrouter ontvangt samengevatte routes 
In dit voorbeeld is het voor de hubs zeer belangrijk om met elkaar te worden verbonden voor redundantiedoeleinden. Deze verbinding zal ook de toespraak verbonden subnetten samenvatten alvorens in de OSPF kern te lekken.
NSSA met toekomstige verbetering
Er zal uiteindelijk een optie OSPF Not-So-Stubby Areas (NSSA) zijn die niet alleen samenvatting in de kern toestaat, maar ook meer specifieke informatie over de hub door de NSSA verbinding. Het voordeel van het runnen van NSSA is dat de samengevatte routes naar de kern kunnen worden verstuurd. Dan kan de kern het verkeer naar een van beide hub sturen om de bestemming van de sprak te bereiken. Als de verbinding tussen een hub en een spits naar beneden gaat, zal er een specifieker type 7 LSA in beide hubs zijn om de bestemming door andere hub te bereiken.
Hierna volgt een configuratievoorbeeld met behulp van NSSA:
N2507: Hub 1
router odr
timers basic 8 24 0 1
!
router ospf 1
redistribute odr subnets
network 1.0.0.0 0.255.255.255 area 1
area 1 nssa
N2504: Hub 2
router odr
timers basic 8 24 0 1
!
router ospf 1
redistribute odr subnets
network 1.0.0.0 0.255.255.255 area 1
area 1 nssa
N2507# show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
U - per-user static route, o - ODR
Gateway of last resort is not set
C 1.0.0.0/8 is directly connected, Serial0
C 2.0.0.0/8 is directly connected, Serial1
3.0.0.0/24 is subnetted, 1 subnets
C 3.3.3.0 is directly connected, Ethernet0
o 150.0.0.0/16 [160/1] via 3.3.3.2, 00:00:23, Ethernet0
o 200.1.1.0/24 [160/1] via 3.3.3.2, 00:00:23, Ethernet0
o 200.1.2.0/24 [160/1] via 3.3.3.2, 00:00:23, Ethernet0
N2504# show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
U - per-user static route, o - ODR
Gateway of last resort is not set
C 1.0.0.0/8 is directly connected, Serial0
C 2.0.0.0/8 is directly connected, Serial1
3.0.0.0/24 is subnetted, 1 subnets
C 3.3.4.0 is directly connected, TokenRing0
C 5.0.0.0/8 is directly connected, Loopback0
C 6.0.0.0/8 is directly connected, Loopback1
O N2 150.0.0.0/16 [110/20] via 1.0.0.1, 00:12:06, Serial0
O N2 200.1.1.0/24 [110/20] via 1.0.0.1, 00:12:06, Serial0
O N2 200.1.2.0/24 [110/20] via 1.0.0.1, 00:12:06, Serial0
Samenvatting en Toekomstige Verbetering met NSSA
Wijs een aaneengesloten blok subnetten aan de woords toe zodat deze subnetten correct in de OSPF-kern kunnen worden samengevat, zoals in het volgende voorbeeld. Als de subnetten niet worden samengevat en één aangesloten subnet daalt, dan zou de gehele kern het detecteren en de routes opnieuw berekenen. Door de summiere route voor een aaneengesloten blok te verzenden, als het luidsprekende voorwerp wegschiet, zal de kern het niet detecteren.
N2504# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
N2504(config)# router ospf 1
N2504(config-router)# summary-address 200.1.0.0 255.255.0.0
N2504# show ip ospf database external
OSPF Router with ID (6.0.0.1) (Process ID 1)
Type-5 AS External Link States
LS age: 1111
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 200.1.0.0 (External Network Number )
Advertising Router: 6.0.0.1
LS Seq Number: 80000001
Checksum: 0x2143
Length: 36
Network Mask: /16
Metric Type: 2 (Larger than any link state path)
TOS: 127
Metric: 16777215
Forward Address: 0.0.0.0
External Route Tag: 0
Probleem bij afstand
In dit voorbeeld wordt meer specifieke informatie ontvangen van beide knooppunten. Aangezien de afstand OSPF 110 is en de ODR afstand 160 is, zal de informatie met ODR interfereren wanneer het van de andere hub over zelfde voorwerp wordt ontvangen. De andere hub zal altijd de voorkeur hebben om aan de uitgestrekte bestemming te krijgen, wat suboptimale routing zal veroorzaken. Om de situatie te verhelpen, verlaag de ODR afstand tot minder dan 110 met het afstand bevel, zodat de ODR route altijd over de OSPF route zal worden voorkeur. Als de ODR-route faalt, wordt de OSPF-externe route in de routingtabel van de database geïnstalleerd.
N2504(config)# router odr
N2504(config-router)# distance 100
N2504(config-router)# end
N2504# show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
U - per-user static route, o - ODR
Gateway of last resort is not set
C 1.0.0.0/8 is directly connected, Serial0
C 2.0.0.0/8 is directly connected, Serial1
3.0.0.0/24 is subnetted, 1 subnets
C 3.3.4.0 is directly connected, TokenRing0
C 5.0.0.0/8 is directly connected, Loopback0
C 6.0.0.0/8 is directly connected, Loopback1
o 150.0.0.0/16 [100/1] via 3.3.4.1, 00:00:39, TokenRing0
o 200.1.1.0/24 [100/1] via 3.3.4.1, 00:00:39, TokenRing0
o 200.1.2.0/24 [100/1] via 3.3.4.1, 00:00:39, TokenRing0
O 200.1.0.0/16 is a summary, 00:04:38, Null0
De N2-routes zijn nog steeds in de database en zullen actief worden als de hoofdverbinding naar de uitgeversmelte sterren wordt ingedrukt.
N2504# show ip ospf database nssa
OSPF Router with ID (6.0.0.1) (Process ID 1)
Type-7 AS External Link States (Area 1)
LS age: 7
Options: (No TOS-capability, Type 7/5 translation, DC)
LS Type: AS External Link
Link State ID: 150.0.0.0 (External Network Number )
Advertising Router: 6.0.0.1
LS Seq Number: 80000002
Checksum: 0x965E
Length: 36
Network Mask: /16
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 1.0.0.2
External Route Tag: 0
Met de versterking van NSSA, zal Type 7 specifieker LSA in de NSSA- databank zijn. In plaats van een samengevatte route zal de output van de NSSA database verschijnen zoals hieronder wordt getoond:
LS age: 868
Options: (No TOS-capability, Type 7/5 translation, DC)
LS Type: AS External Link
Link State ID: 200.1.1.0 (External Network Number)
Advertising Router: 3.3.3.1
LS Seq Number: 80000001
Checksum: 0xDFE0
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 1.0.0.1
External Route Tag: 0
LS age: 9
Options: (No TOS-capability, Type 7/5 translation, DC)
LS Type: AS External Link
Link State ID: 200.1.2.0 (External Network Number)
Advertising Router: 3.3.3.1
LS Seq Number: 80000002
Checksum: 0xFDC3
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 1.0.0.2
External Route Tag: 0
Demand circuit
Het verbruikscircuit is een Cisco IOS 11.2-functie die ook kan worden gebruikt in een netwerk met een hub en een spraaknetwerk. Deze optie is doorgaans handig in back-upscenario's voor bellen en in een virtuele circuit (SVC)-omgeving met X.25 of Frame Relay-switching. Hierna volgt een configuratievoorbeeld van een verbruikscircuit:
router ospf 1
network 1.1.1.0 0.0.0.255 area 1
area 1 stub no-summary
interface Serial0 /* Link to the hub router */
ip address 1.1.1.1 255.255.255.0
ip ospf demand-circuit
clockrate 56000
Spoke#show ip o int s0
Serial0 is up, line protocol is up
Internet Address 1.1.1.1/24, Area 1
Process ID 1, Router ID 141.108.4.2, Network Type POINT_TO_POINT, Cost: 64
Configured as demand circuit.
Run as demand circuit.
DoNotAge LSA not allowed (Number of DCbitless LSA is 1).
Transmit Delay is 1 sec, State POINT_TO_POINT,
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:06
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 130.2.4.2
Suppress hello for 0 neighbor(s)
Het gebruiken van de eigenschap van het vraagcircuit in een hub-and-sprak netwerk zal het circuit omhoog brengen en nieuwe nabijheid vormen als er een verandering in de topologie is. Bijvoorbeeld, als er een voorwerp in een wordt gesproken dat flaps heeft, zal het vraagcircuit de nabijheid omhoog brengen en deze informatie overspoelen. Deze informatie wordt in een omgeving met een groot gebied overspoeld door het hele stamgebied. ODR lost dit probleem op door deze informatie niet naar de andere spaken te lekken. Raadpleeg de OSPF-optie Circuit voor meer informatie.
ODR met point-to-point netwerken
De huidige grenzen van Cisco IOS 12.0 op Interface Descriptor Block (IDB) zijn als volgt:
| router | Limiet |
|---|---|
| 1000 | 300 |
| 2600 | 300 |
| 3600 | 800 |
| 4x00 | 300 |
| 5200 | 300 |
| 5300 | 700 |
| 5800 | 3000 |
| 7200 | 3000 |
| RSP | 1000 |
Vóór IOS 12.0, was het maximum aantal woordjes dat een hub kon ondersteunen 300 door IDB-limieten. Als een netwerk meer dan 300 spaken nodig had, was de point-to-point configuratie geen goede keuze. Er is ook een afzonderlijk CDP-pakket gegenereerd voor elke link. De tijdcomplexiteit van het verzenden van CDP-updates op point-to-point links is n2. De tabel hierboven geeft ons de IDB-limieten voor verschillende platforms. Het maximum aantal spaken dat op elk platform wordt ondersteund varieert, maar de overhead van het maken van een afzonderlijk CDP-pakket voor elke link is nog steeds een probleem. Daarom is het configureren van een point-to-multipoint interface in een grote hub en een spraaksituatie een betere oplossing dan een point-to-point interface.
ODR met point-to-multipoint netwerken
In een point-to-multipoint netwerk waar een hub meerdere spokes ondersteunt, zijn er drie belangrijke kwesties:
-
De hub kan gemakkelijk meer dan 300 spokes ondersteunen. Een 10.10.0.0/22 netwerk kan bijvoorbeeld 1024-2 spaken met een multipoint interface ondersteunen.
-
In een omgeving met meerdere punten, wordt één CDP-pakket gegenereerd voor alle buren en wordt herhaald op Layer 2. De tijdcomplexiteit van de CDP-update wordt verminderd tot n.
-
In een punt-aan-multipoint configuratie, kunt u slechts één voorwerp aan alle spokes toewijzen.
ODR en meerdere verkopers
Eén veel voorkomende misvatting is dat ODR niet zal werken als meerdere verkopers worden gebruikt. ODR zal werken zolang het netwerk een waarlijk knooppunt-en-netwerk is. Als er bijvoorbeeld 100 spaken zijn en twee van de spaken routers van een verschillende verkoper zijn, is het mogelijk om een routingprotocol in te schakelen op die koppelingen die verbinding maken met de verschillende routers en vervolgens nog steeds ODR op de resterende 98 Cisco-spaken uitvoeren.
Afbeelding 6: ODR met meerdere verkopers 
De hub router die op de 98 routers van Cisco wordt aangesloten zal subnetupdates door ODR ontvangen en zal routeringupdates van de resterende twee verschillende routers ontvangen. De verbindingen die met de verschillende routers worden verbonden moeten op afzonderlijk point-to-point of point-to-multipoint subnetten zijn.
Toekomstige groei-kwesties
Als een organisatie ODR op 100 spokes runt, kunnen ze uiteindelijk hun topologie van een netwerk willen veranderen. Bijvoorbeeld, kunnen zij besluiten om de één te verbeteren aan een groter platform, dat een hub maakte voor 20 andere nieuwe spokes.
Afbeelding 7: Toekomstige groei 
Het is mogelijk om een routeringsprotocol op de nieuwe hub uit te voeren en nog steeds het ODR-ontwerp te behouden zoals het is. Als de nieuwe hub 20 of meer nieuwe spokes ondersteunt, kan ODR op de nieuwe hub draaien. De nieuwe hub kan over die nieuwe gesproken subnetten door ODR leren en deze informatie opnieuw verdelen aan de originele hub door een ander routingprotocol.
Deze situatie is gelijk wanneer ODR met twee hubs begint. Er is geen overheadkosten voor het veranderen van protocollen. Basiliek, kan ODR lopen zolang de router een stomp is.
Prestaties
Verschillende instellingen kunnen worden aangepast voor snellere convergentie en betere prestaties bij het uitvoeren van ODR.
Aanpassing van timers voor snellere convergentie
In een grote ODR-omgeving, pas de ODR-timers voor snellere convergentie aan en vergroot de timers van de CDP-update van de hub naar de spaander om de CPU-prestaties van het hub te minimaliseren.
Hub router
De timer voor CDP zou op 60 seconden moeten blijven staan om de hoeveelheid verkeer van de hub naar de spaken te verminderen. De houdtijd moet worden verhoogd tot het maximum (255 seconden). Aangezien de hubrouter te veel CDP-nabijheidstabellen moet onderhouden en wanneer een paar buren omlaag gaan, verwijdert u de CDP-waarden gedurende 25 seconden (de maximaal toegestane wachttijd) niet uit het geheugen. Deze configuratie zal flexibiliteit aan de router van de hub geven omdat als de buur binnen vier minuten weer omhoog komt, de nabijheid van CDP niet zal hoeven te worden opnieuw gecreëerd. De oude tabelingang kan worden gebruikt en de uitvaltimer kan worden bijgewerkt.
Hierna volgt een voorbeeld van een IP-configuratiesjabloon voor een centrale router:
cdp holdtime 255
router odr
timers basic 8 24 0 1 /* odr timer's are update, invalid, hold down, flush
router eigrp 1
network 10.0.0.0
redistribute odr
default-metric 1 1 1 1 1
Er zijn drie permanente virtuele circuits (PVC’s) van elke externe locatie (pakhuis, regio en depot). Twee PVC’s gaan naar twee afzonderlijke centrale routers. Het derde PVC gaat naar een PayPoint-router. Het PVC moet worden gebruikt voor het verkeer dat bestemd is voor het PayPoint-netwerk. De andere twee PVC’s dienen primaire en reservefuncties voor al het andere verkeer. Op basis van deze vereisten, zie de configuratiesjabloon hieronder voor elke externe router.
Het is heel belangrijk om de ODR-timers aan te passen, zoals ongeldig, ingehouden en sneller convergentie te bereiken. Zelfs al stuurt CDP geen IP-prefix als de router is geconfigureerd, de ODR-update timer moet overeenkomen met de buurtimer voor CDP omdat de convergentie-timer alleen kan worden ingesteld als er een update-timer is. Deze timer is anders dan de CDP-timer en kan alleen worden gebruikt voor snellere convergentie.
Spoelrouter
Aangezien de woordjes ODR updates in CDP-pakketten verzenden, moet de timer voor CDP-updates erg klein worden gehouden voor een snellere convergentie. In een werkelijk gesproken omgeving is er geen beperking voor de vertragingstijd voor de buurman CDP, omdat er slechts een paar inzendingen voor de spaak zijn om in zijn CDP-tabel te blijven staan. De maximum holddown tijd van 255 seconden wordt aanbevolen zodat als het hub PVC daalt en binnen vier minuten terugkomt, er geen nieuwe CDP nabijheid nodig is omdat de oude tabelingang kan worden gebruikt.
Hieronder zie je een voorbeeld van een IP-configuratiesjabloon voor een externe site:
cdp timer 8
cdp holdtime 255
interface serial 0
encapsulation frame-relay
cdp enable
interface serial 0.1 point /* Primary PVC */
ip address 10.x.x.x 255.255.255.0
frame-relay interface-dlci XX
interface serial 0.2 point /* Secondary PVC */
ip address 10.y.y.y 255.255.255.0
frame-relay interface-dlci XX
interface bri 0
interface BRI0
description Backup ISDN for frame-relay
ip address 10.c.d.e 255.255.255.0
encapsulation PPP
dialer idle-timeout 240
dialer wait-for-carrier-time 60
dialer map IP 10.x.x.x name ROUTER2 broadcast xxxxxxxxx
ppp authentication chap
dialer-group 1
isdn spid1 xxxxxxx
isdn spid2 xxxxxxx
access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
dialer-list 1 LIST 101
/* following are the static routes that need to be configured on the remote routers
ip route 0.0.0.0 0.0.0.0 10.x.x.x
ip route 0.0.0.0 0.0.0.0 10.y.y.y
ip route 0.0.0.0 0.0.0.0 bri 0 100
ip classless
De statische standaardroutes zijn niet vereist als u IOS 12.0.5T of later gebruikt aangezien de hubrouter de standaardroute automatisch naar alle spaken verstuurt.
Filter en samenvatting van ODR-routers
ODR-routes kunnen worden gefilterd voordat ze in de kern worden gelekt. Gebruik de distributielijst in de opdracht. Alle gekoppelde subnetten van de spaken moeten worden samengevat wanneer ze in de kern lekken. Als samenvatting niet mogelijk is, dan kunnen de onnodige routes in de hub router worden gefilterd. In meerdere hubnetwerken kunnen de spaken de aangesloten interface adverteren die de link naar een ander knooppunt is.
In deze situatie, moet het bevel-verdeellijst worden toegepast zodat de hub die routes niet in de routingtabel plaatst. Wanneer ODR wordt herverdeeld in de hub, wordt die informatie niet uitgelekt in de kern.
TelePresence-aanpassing
Het is belangrijk om de telco-timer aan te passen om de convergentie-tijd voor de woordvoerders te verhogen. Als het PVC van de hub side naar beneden gaat, zouden de spaken in staat moeten zijn om het snel te detecteren naar de tweede hub.
CPU-prestaties
Het ODR-proces neemt niet veel CPU-gebruik in beslag. ODR is getest voor ongeveer 1000 buren met CPU-gebruik van drie tot vier procent. De agressieve timer instelling van de ODR op de hub helpt met een snellere convergentie. Als de standaardinstellingen worden gebruikt, blijft het CPU-gebruik op nul tot één procent staan.
Zelfs met agressieve ODR en CDP timers toont de hieronder weergegeven uitvoer aan dat er geen veel CPU-gebruik was. Deze test werd uitgevoerd met een 150 MHz processor op een Cisco 7206.
Hub# show proc cpu
CPU utilization for five seconds: 4%/0%; one minute: 3%; five minutes: 3%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
.
.
18 11588036 15783316 734 0.73% 1.74% 1.95% 0 CDP Protocol
.
.
48 3864 5736 673 0.00% 0.00% 0.00% 0 ODR Router
Hub# show proc cpu
CPU utilization for five seconds: 3%/0%; one minute: 3%; five minutes: 3%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
.
.
18 11588484 15783850 734 2.21% 1.83% 1.96% 0 CDP Protocol
.
.
48 3864 5736 673 0.00% 0.00% 0.00% 0 ODR Router
Hub# show proc cpu
CPU utilization for five seconds: 2%/0%; one minute: 3%; five minutes: 3%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
.
.
18 11588676 15784090 734 1.31% 1.79% 1.95% 0 CDP Protocol
.
.
48 3864 5736 673 0.00% 0.00% 0.00% 0 ODR Router
Hub# show proc cpu
CPU utilization for five seconds: 1%/0%; one minute: 3%; five minutes: 3%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
.
.
18 11588824 15784283 734 0.65% 1.76% 1.94% 0 CDP Protocol
.
.
48 3864 5737 673 0.00% 0.00% 0.00% 0 ODR Router
Hub# show proc cpu
CPU utilization for five seconds: 3%/0%; one minute: 3%; five minutes: 3%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
.
.
18 11589004 15784473 734 1.96% 1.85% 1.95% 0 CDP Protocol
.
.
48 3864 5737 673 0.00% 0.00% 0.00% 0 ODR Router
Hub# show proc cpu
CPU utilization for five seconds: 3%/0%; one minute: 3%; five minutes: 3%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
.
.
18 11589188 15784661 734 1.63% 1.83% 1.94% 0 CDP Protocol
.
.
48 3864 5737 673 0.00% 0.00% 0.00% 0 ODR Router
Verbeteringen
De versie van ODR voorafgaand aan Cisco IOS 12.0.5T had een aantal beperkingen. Hieronder volgt de lijst met verbeteringen in Cisco IOS 12.0.5T en hoger:
-
Vóór CSCdy48736 wordt secundaire subnetten in een CDP-update geadverteerd als /32. Dit is vastgelegd in 12.2.13T en later.
-
De hubs van CDP propageren nu standaardroutes naar de spaken, zodat er geen statische standaardroutes in de spaken hoeven toe te voegen. De convergentietijd neemt aanzienlijk toe. Als de volgende hop naar beneden gaat, detecteert de spits hem snel via ODR en convergeert hij. Deze optie wordt in 12.0.5T via bug CSCdk91586 toegevoegd.
-
Als de verbinding tussen de hub en de toespraak IP ongenummerd is, kan de standaardroute die door de hub wordt verstuurd niet op de spokes worden gezien. Dit bug, CSCdx6917, wordt vastgelegd in IOS 12.2.14, 12.2.14T en later.
-
Om de ODR-afstand op de spaken te vergroten/verminderen zodat zij de voorkeur kunnen geven aan het ene hub boven het andere, is een suggestie gedaan die via CSCdr35460 wordt gevolgd. De code is al getest en zal binnenkort beschikbaar zijn voor klanten.
Feedback