EIGRP – Frame Relay

EIGRP över Frame-Relay är lite speciellt, något jag redan nämnt i tidigare poster är att det ej är möjligt att skicka broadcast. Detta ställer ju till stora problem för just EIGRP med även andra routingprotokoll som OSPF & RIPv2 då de använder sig av multicast. Det finns dock två olika lösningar för detta:

Pseudobroadcast

Frame-Relay har en inbyggd funktion där den emulerar broadcast (dessa skickas istället som unicast) över en länk. Detta konfigureras automatiskt om vi använder oss av “Inverse ARP” för att sätta upp mappningen med DLCI-nummer mellan två siter. Det går dock även att göra detta manuellt, först stänger vi av Inverse Arp genom “no frame-relay inverse-arp“, och skapar sedan mappningen manuellt via “frame-relay map ip x.x.x.x  (destinations-adress) x (lokal dlci) broadcast“.

Statisk Neighbor-mappning

Det finns även möjligheten att statiskt ange varje neighbor, eigrp skickar då istället unicast endast. Detta gör dock att automatisk neighbor adjacency inte längre fungerar utan man är tvungen att manuellt skriva in varje neighbor vart eftersom de läggs till i nätet. Detta konfigureras under “router eigrp x”, ex: “neighbor x.x.x.x serial0/0.1“.

Split-Horizon över multipoint

Split-Horizon är per default inaktiverat på fysiska interface, men aktiverat på subinterface. Detta leder till stora problem med routing-uppdateringar om vi kör en Multipoint-access över ett subinterface.. I “Hub-n-spoke”-exemplet nedan så får R3 aldrig reda på näten som R2 har och vice-versa på grund av just Split-Horizon.

hubnspoke

Vi måste därför komma ihåg att ALLTID stänga av split-horizon i dessa fall. Detta görs på subinterfacet med kommandot “no ip split-horizon eigrp x” där x är AS-numret. Den enda fördelen med att använda sig av multipoint istället för point-to-point är egentligen att man sparar in på antal ip-adresser som behövs. Det kan även vara användbart vid riktigt stora nät där det skulle bli alldeles för stort administrativt arbete att skapa point-to-point-länkar för varje site.

Justera EIGRPs bandbreddsutnyttjande

Som nämndes i gårdagens post finns det möjlighet att styra hur mycket bandbredd EIGRP får använda sig av på ett interface. Detta är default 50% av den konfigurerade bandwith:en, och om det är ett multipoint-förhållande så delar den värdet med antal neighbors. Om vi tar nedanstående topologi ser vi att det kan leda till problem om vi inte i efterhand justerar dessa värden.

frame-relay hubnspoke

Om vi ovanstående exempel säger följande:

  • PVC1 mellan BB & R4 har en CIR på 512k
  • PVC2 mellan BB & R2 har en CIR på 128k
  • PVC3 mellan BB & R3 har en CIR på 128k
  • PVC4 mellan BB & R5 har en CIR på 64k

Vad händer då om R4 skickar en update till R5? 50% av 512k är 256k (vi delar inte per antal neighbors då det endast är Backbone som använder sig av multipoint-interface), länken för R5 kommer med andra ord att bli överlastad med endast EIGRP-trafik.

Enklaste lösningen är egentligen att migrera nätet från multipoint och istället skapa point-to-point för varje site. Men det går som sagt även att justera bandbreddsutnyttjandet enligt följande:

Ta PVC med lägst bandbredd, i detta fall PVC4 på 64k och multiplicera med antal pvc’s får vi = 256k, detta sätter vi som bandwith på Backbone-routern. Backbone-routern kommer då dela 256k / 4 (antal neighbors) och limitera EIGRP-trafiken till 64k per PVC – Problemet löst!

Detta ska väl täcka Frame-Relay för EIGRP och jag börjar känna mig klar med detta protokoll! Men innan jag hoppar vidare till OSPF tänkte jag sätta mig och göra följande labbar från gns3vault:

  • Frame-Relay Basucs
  • EIGRP over Frame-Relay with Subinterfaces
  • EIGRP over Frame-Relay with Multipoint-interface
  • EIGRP Multipoint bandwith Pacing
  • EIGRP Point-to-point bandwith Pacing
  • EIGRP Hybrid Bandwith Pacing

Ska dock först skriva en mer detaljerad post om EIGRP’s Query-paket som kan ställa till den hel del problem och hur man kommer runt detta.

EIGRP – The basics III

Fortsätter på samma tema med ett lite mer avancerat exempel på successor / feasible successor som tog ett tag för mig att greppa helt och hållet.

eigrp metric

Hur skulle R3’s Topology Table se ut i detta exempel för att nå “Molnet”? Svaren är skriven i vit text, så markera för facit och se om du räknat rätt.

R4 kommer annonsera sin AD = 10, R3’s Feasible Distance (FD) blir då 18, inga konstigheter där.
R1 kommer däremot annonsera sin AD = 34, R3’s FD blir då?  40. Inte helt glasklart kanske?
R2’s AD = 31, R3’s FD blir?  -> 40

Om du läst CCNA så bör du redan veta varför R1 & R2 inte annonserar ut den närmaste vägen till Molnet: Split-Horizon.

eigrp metric splithorizon

Vilken route R3 kommer välja som successor kräver inte direkt något tankeverksamhet för att lista ut, det blir givetvis direkt via R4 som också hade lägst FD, 18. Men vilken route kommer bli feasible successor? Svar: Ingen.

Kom ihåg regeln om att en Feasible Fuccessor måste ha ett lägre Advertised Distance än Successorns Feasible Distance. R3’s fd = 18. R1’s AD = 34 och R2’s = 31, med andra ord finns det ingen route som kvalificerar sig som FS. Nog om Successor/FS, detta ska väl förhoppningsvis ha klarnat nu.

Unequal Cost Load-balancing

Unikt för EIGRP är att det tillåter Unequal cost Load-Balacing (UCLB), läs mer här. Om vi använder oss av en tidigare topologi så kör vi en snabb dragning om hur variance-kommandot fungerar.

5 routrar

Förhoppningsvis ser vi direkt att R1’s successor-route blir via R2 -> R3 och dess FS är R4 -> R3. Lastbalansering är redan aktiverat i EIGRP men inträffar endast när två routes har samma metric, om vi vill använda oss av “UCLB” måste vi justera variance-värdet. Det är endast möjligt att använda Feasible Successors för UCLB, övriga blockeras på grund av risken för routing-loopar.

EIGRP-processen kommer endast installera routes där “Metric <= Best_Metric*Variance”.  Metric är i detta fall FD för den alternativa routen, Best_Metric är FD för successor-routen. Som standard är Variance satt till 1, men genom att ändra detta får vi möjligheten att lastbalansera över en länk med sämre metric.

I ovanstående exempel har successor-routen för R1 25 FD, via R4 30 och R5 206. För vi in detta i ekvationen ser vi vad variance måste konfigureras till för att aktivera UCLB.

Via R4: 30 <= 25 x Variance. 30/25 = 1,2 – Men endast heltal går att använda så därför avrundar vi upp till 2.  30 < 25 x 2 = true och EIGRP kommer då även installera FS-routen i Routing table för lastbalansering med den befintliga successor-routen.

Om vi även vill aktivera lastbalansering via R5 konfigurerar vi variance till? Svar: 9.

Förhoppningsvis har du koll påhur metrics, successor/feasible successor, AD  & FD fungerar inom EIGRP efter dessa tre inlägg. Så som en sista slutfråga, vad skulle vi behöva konfigurera variance till om länken mellan R4 & R3 skulle ändras från 10 till 20 för att aktivera lastbalansering på R1?

Svar: 9. R1’s FD för successor-routen är 25, AD för R4 hade i detta fall också blivit 25. Kom ihåg, för att en route skall räknas som feasible successor måste dess AD vara MINDRE än successorns FD. Endast routen via R5-R3 kvalificerar sig därför som FD.