IS-IS Routingprotokol - Teori

IS-IS er en skalerbar link-state routingprotokol, brugt i ISP-netværk som TDC. Den opererer direkte på datalinklaget, understøtter IPv4/IPv6 og bruger et fleksibelt TLV-format. Lær IS-IS teori og opsætning i GNS3 med RapidHub.

Grundlæggende teori

Hvad er IS-IS?
Intermediate System-to-Intermediate System (IS-IS) er en Interior Gateway Protocol (IGP) og en link-state routingprotokol ligesom OSPF. IS-IS danner nabo-adjacencies, udveksler link-state information og bygger en topologidatabase, hvorefter den kører Dijkstras SPF, for at beregne de korteste veje til hver destination. Protokollen blev oprindeligt udviklet til OSI-netværk (CLNS) af DEC, men blev sidenhen udvidet til også at kunne route IP – også kendt som Integrated IS-IS. I dag anvendes IS-IS ofte i store netværk hos mange service providere . Den er meget skalerbar, hvilket er en af grundene til at den benyttes i mange service provider-backbone netværk.

IS-IS vs. OSPF
Selvom IS-IS og OSPF begge er link-state IGP’er med mange ligheder, er der vigtige forskelle i design og funktionalitet:

  • Netværkslag vs. datalinklag: OSPF kører oven på IP (protocol 89) som transport, hvorimod IS-IS opererer direkte på datalinklaget med sin egen Ethernet-type. Derfor behøver IS-IS ikke IP for at fungere. En god sideeffekt er øget isolation fra IP – det er vanskeligere for en hacker at sende eller injicere ondsindet IS-IS trafik via IP, sammenlignet med OSPF.
  • Adresseskema: OSPF identificerer routere via IP-adresser (Router-ID) og segmenterer netværket i IP-baserede områder. IS-IS derimod anvender OSI-adresser kaldet NET (Network Entity Title) baseret på NSAP-formatet. Hver IS-IS-router får en unik NET-adresse, som indeholder både områdenummer og en system ID (ofte afledt af MAC eller en del af en IP) samt en NSEL (ofte 00). Dette OSI-adressesystem betyder, at IS-IS er uafhængig af IP-adressering i sine interne routingstrukture.
  • Områdestruktur: OSPF har en strikt områdestruktur, hvor alle områder skal tilsluttes en backbone Area 0 for inter-area routing. IS-IS bruger en to-niveau hierarki (Level 1/Level 2) med en mere fleksibel tilgang. Hele routeren tilhører ét IS-IS-område (i stedet for at have interfaces i forskellige områder), og backbone dannes automatisk af de routere, der kører som Level 2. OSPF’s “Area 0's” krav kan passe godt til net med en central core, mens IS-IS’ mere afslappede to-niveau design egner sig til “serie” eller decentraliserede topologier, som ikke naturligt passer ind i en enkelt core netværk.
  • Forlængelse og nye funktioner: IS-IS blev designet med et TLV-baseret format (Type-Length-Value) for at kunne udvides nemt. Det vil sige, at nye typer information kan tilføjes i protokollen uden at ændre den grundlæggende pakkeformat. Da IS-IS skulle understøtte IP, blev det gjort ved at definere en ny TLV (Type 128) til at bære IP-præfikser. Tilsvarende er understøttelse af fx IPv6, trafficengineering (TE) og flere topologier blevet tilføjet via nye TLV’er i IS-IS. OSPF er derimod mindre fleksibel i udvidelser – fx krævede OSPF IPv6 en ny protocol-version (OSPFv3) – hvilket historisk har gjort IS-IS mere attraktiv for udbydere med behov for hurtig implementering af nye features. En ofte citeret forskel er, at hvor OSPF definerer flere faste LSA-typer til forskellige formål, anvender IS-IS typisk én type link-state PDU (LSP) per niveau, der kan indeholde mange forskellige TLV’er. OSPF skal altså udsende flere forskellige LSAs, hvilket gør OSPF “mere snakkesaglig” og potentielt mindre effektiv i et stort, fladt netværk.
  • Historisk adoption og stabilitet: IS-IS har traditionelt været foretrukket i mange service provider-netværk. En af årsagerne er historisk – tilbage i begyndelsen af 1990’erne var Ciscos implementering af IS-IS betydeligt mere stabil end deres OSPF-implementering, hvilket gjorde at ISP'er dengang naturligt valgte IS-IS. De største ISP’er brugte IS-IS og pressede leverandørerne for forbedringer, hvilket gjorde IS-IS implementeringerne meget tunet og robuste . OSPF blev senere forbedret og kan i dag matche de fleste funktioner, men denne tidlige fordel gav IS-IS fodfæste i mange backbone-net. Endvidere har IS-IS fortsat en vis feature lead i visse tilfælde – fordi de største netværksoperatører bruger IS-IS, tilføjer router-producenter ofte nye optimeringsfunktioner til IS-IS før de finder vej til OSPF. Samlet set ser man derfor, at ISP'er ofte benytter IS-IS i core-nettet for at udnytte fordelene af protokollens skalerbarhed, fleksibilitet og stabilitet.

Avancerede emner

TLV (Type-Length-Value) i IS-IS

IS-IS benytter TLV-formatet til at udveksle information i sine Link State PDU’er. TLV-strukturen består af en Type (hvilken slags information det er), en Length (længden af værdien) og Value (selve værdien). Denne fleksible struktur gør IS-IS let at udvide med nye funktioner. Som nævnt blev IPv4-routing integreret via en ny type (TLV 128), der kunne indeholde IP-præfikser. Senere er der tilføjet TLV’er for fx. IPv6 support wide metrics værdier, trafficengineering information (båndbredde, delay på links osv.) og segment routing. Uden TLV-arkitekturen ville sådane tilføjelser have krævet større protokol ændringer. OSPF benytter ikke TLV’er i sine LSA’er på samme måde og er grunden til at IS-IS kunne forblive én protokol for både IPv4 og IPv6, mens OSPF måtte designes om i OSPFv3 for IPv6. TLV’erne betyder også, at en IS-IS LSP kan indeholde mange forskellige stykker information samlet, i stedet for at sende separat opdatering per type – hvilket som nævnt reducerer overhead i store net.

Velkommen til RapidHub – Din Teknologiske Base
Vi deler hands-on erfaringer med virtualisering, sikkerhed og skalerbar kode. Fokus er på infrastruktur, automation og sikre systemarkitekturer, så du kan bygge stabile og fremtidssikrede løsninger.

LSP flooding-mekanismer

Som link-state protokol skal IS-IS sikre, at alle routere inden for samme område (eller backbone) får den opdaterede link-state database. IS-IS udsender LSP’er (Link State Packets) med information om routerens egne links og præfikser, og disse LSP’er flodes (floodes) til alle naboer. Hver LSP har et sekvensnummer og en levetid, som routerne bruger til at afgøre nyeste version og kassere forældede oplysninger. Reliable flooding opnås ved hjælp af særlige Sequence Number PDUs:

  • En CSNP (Complete Sequence Number PDU) indeholder en slags “indeks” over alle LSP’er en router kender til (ligesom til OSPF's Database Description packets). På multi-access net (fx Ethernet) udnævnes en DIS (Designated IS), der periodisk udsender CSNP’er til alle andre på segmentet for at annoncere det komplette indhold af sin database. DIS’en fungerer lignende OSPFs DR, men med den forskel at DIS ikke videresender trafikken – den tjener primært som referencenode for synkronisering. DIS’en skaber også en pseudonode-LSP, der repræsenterer selve LAN-segmentet (identificeret ved DIS’ system-ID med et særligt suffix) – dette forenkler topologiinformationen, så alle routere på LAN’et fremstår som direkte forbundet til pseudonoden.
  • En PSNP (Partial Sequence Number PDU) bruges af routerne til at kviter for modtagne LSPer, eller anmode om manglende LSPer. På point to point links kviteres nye LSP’er typisk med en PSNP (svarende til OSPF LS Ack) for at sikre at levering er gennemført. På et LAN segment afventer routerne normalt DISens næste CSNP i stedet for at kvittere hver LSP. Hvis en router modtager en CSNP og opdager, at den mangler en LSP eller har en ældre version, vil den sende en PSNP til DIS for at anmode om opdateringen. DIS vil dernæst floode den manglende LSP ud på netværket mellem dem. Gennem denne metode og brug af sekvensnumre og tidsstempler sikrer det, at alle routere i netværket konvergerer mod en ensartet link-state database.

Det er værd at bemærke, at IS-IS ikke bruger TCP til at transportere opdateringer i modsætning til f.eks. BGP, men håndterer forbindelsernes pårlidelighed ved hjælp af ovenstående metoder. LSP’er fornyes typisk hvert 15. minut, for at holde databasen opdateret og aktuel. Samlet set er flooding mekanismen i IS-IS designet til at skalere effektivt, selv på store netværk ved at minimere overflødige opdateringer og udnytte DIS/CSNP på LAN for at reducere "snak/chatter".


Nedenfor har jeg prøvet at illustrere en LSP header og hvordan man kan tilføje TLV'er, så det bliver mere visuelt og nemmere at forstå.

Her kan du se strukturen af en LSP Header

Klik her - For mere detaljeret information om TLV'er

  1. TLV 1: Area Addresses
    • Type: 1 (8 bit)
    • Length: Variabel (8 bit, 1-255)
    • Value: For hver områdeadresse: [Længde-octet | Adresseværdi]
    • Bruges til at identificere hvilket/hvilke områder routeren tilhører
  2. TLV 22: Extended IS Reachability
    • Type: 22 (8 bit)
    • Length: Variabel (8 bit)
    • Value: Indeholder information om naboer med følgende struktur:
      • Neighbor ID: 7 bytes (System ID + Pseudonode ID)
      • Metric: 3 bytes (24 bit) - link metric
      • Flags: 1 byte (8 bit)
      • Sub-TLV Length: 1 byte (8 bit)
      • Sub-TLVer:
        • Sub-TLV 3: Administrative Group (farve)
        • Sub-TLV 6: IPv4 Interface Address
        • Sub-TLV 8: Link Bandwidth
        • Sub-TLV 18: Traffic Engineering Metric
  3. TLV 135: Extended IP Reachability
    • Type: 135 (8 bit)
    • Length: Variabel (8 bit)
    • Value: For hver IP præfiks:
      • Metric: 4 bytes (32 bit)
      • Control: 1 byte (U/D bit, External bit, etc.)
      • Prefix Length: 1 byte (8 bit)
      • Prefix: Variabel længde
      • Sub-TLV Length: 1 byte
      • Sub-TLVer (hvis nogen)
  4. TLV 141: Router Capability
    • Type: 141 (8 bit)
    • Length: Variabel (8 bit)
    • Value:
      • Router ID: 4 bytes (32 bit)
      • Flags: 1 byte (8 bit)
      • Sub-TLVer:
        • Sub-TLV 7: Segment Routing Capability
        • Sub-TLV 2: MPLS Traffic Engineering Router ID
        • Sub-TLV 14: SR Algorithm
  5. TLV 137: Dynamic Hostname
    • Type: 137 (8 bit)
    • Length: Variabel (8 bit)
    • Value: Hostname i ASCII format (variabel længde)
  6. TLV 240: P2P Adjacency State
    • Type: 240 (8 bit)
    • Length: Variabel (8 bit)
    • Value:
      • Adjacency State: 1 byte (8 bit)
      • Extended Local Circuit ID: 4 bytes (32 bit)
      • Neighbor System ID: 6 bytes (48 bit)
      • Neighbor Extended Local Circuit ID: 4 bytes (32 bit)

SPF-algoritmen

IS-IS benytter ligesom OSPF, Dijkstra’s Shortest Path First (SPF) algoritme til at beregne de bedste ruter ud fra link-state databasen. Hver IS-IS-router kører SPF for henholdsvis Level 1 databasen (inden for eget område) og Level 2 databasen (backbone mellem områder), og bygger derfra sin routing table. SPF-algoritmen sikrer loopfri og optimale veje, baseret på de metrics, der er angivet på links (default metric i IS-IS er som standard 10 per link, men kan justeres). Moderne IS-IS understøtter også incremental SPF, hvor det kun er ændringer i netværket der genberegnes, hvilket gør at konvergensen i store net sker hurtigere end med OSPF. Resultatet af SPF er en træstruktur med routeren selv som rod, og korteste veje til alle kendte destinationer. Disse ligges ind i routing tabellen med IS-IS som kilde. Hvis flere veje har lige stor samlet metric, kan IS-IS lave load balancing over dem.

Multi-level IS-IS (L1/L2 funktionalitet)

IS-IS-netværk kan opdeles i områder og niveauer, hvilket minder om OSPF-områder. Level 1 i IS-IS svarer omtrent til intra-area routing: en Level-1 router kender kun til sin egen område-topologi og præfikser internt i området. Level 2 svarer til backbone: en Level-2 router kan udveksle routinginformation mellem områder også kaldet inter-area.
En Level 1-2 router deltager i begge og fungerer som bindeled mellem et intra-area og backbone.

Vigtigt ved IS-IS områder og levels:

  • En IS-IS-router befinder sig kun i ét område ad gangen, dvs. at hele routeren har én NET adresse med ét områdenummer. Man har altså ikke konceptet at en router direkte tilhører flere områder, som OSPF ABR gør ved at have interfaces i Area 0 og et andet område. En L1-2 router i IS-IS har én primær area (for sine L1 adjacencies), og betragtes samtidig som backbone-deltager via L2, men den skifter ikke område-ID på tværs af interfaces.
  • Neighbor adjacencies dannes kun mellem routere af samme level. To L1-routere kan blive naboer, ligesom to L2-routere kan. Hvis to nabofysiske routere begge er L1-2, kan de etablere to naboskaber over samme link – ét L1 og ét L2 – forudsat de deler område. I praksis vælger man ofte at køre enten L2 eller L1 på et link for simpelthed, men Cisco IOS default er at sende både L1 og L2 hellos på alle links, så hver opmærksom på dette.
  • Områder adskilt af backbone: Routere af Level 2 type udgør ryggraden (backbone). Alle Level-2 routere behøver ikke ligge i ét sammenhængende område, backbone defineres af det link-state domæne som alle L2 routere danner. Som minimum skal alle L2 eller L1-2 routere hænge sammen, for at sikre connectivity mellem alle områder. Level-1 routere har kun kendskab til interne ruter i området. Skal en L1 router nå et andet område, sender den trafikken til en tilknyttet L1-2 router som fungerer som "area border router" i IS-IS terminologi. L1-2 routeren modtager L1 LSPer fra sin område og leaker routes op i L2, der omvendt annoncerer default-router eller bestemte præfikser ned i L1, for at etablere connectivity mellem områder. Denne process sker automatisk for intermediate systems der kører begge levels.
  • Default settings: Som nævnt er Cisco IOS routere som standard L1-2, hvilket betyder de deltager i begge levels med mindre man konfigurerer andet. I en simpel single-area ISP-net kan alle routere således køre L1-2 uden problemer (de fungerer i praksis som ét område, men annoncerer også som L2). I et hierarkisk design med flere områder kan man vælge at nogle routere kun kører L1 det kan gøre L2 database størrelse mere overskueligt, mens core/backbone routere kun kører L2 for at carrie gennemgående traffik. Dette kan konfigureres pr. router fx is-type level-1 for en rent L1 router eller pr. interface om en given forbindelse kun skal være L1 eller L2. I designfasen skal man sikre at mindst én L1-2 router forbinder hver område til backbone, ellers bliver området isoleret.
Praktisk opsætning af IS-IS i GNS3
💡Det er en god idé at læse denne artikel inden du sætter IS-IS op I denne guide gennemgås, hvordan man kan implementere IS-IS i et netværksscenario ved hjælp af GNS3 med Cisco-routere (f.eks. Cisco 7200-serien). GNS3 er en emulator, der lader os køre rigtige router-images og forbinde dem i

Konklusion

IS-IS er en robust og skalerbar link-state routingprotokol, der anvendes bredt i service provider- og backbone-netværk på grund af dens effektivitet, fleksibilitet og evne til at håndtere store netværk med hurtig konvergens.

Den adskiller sig fra OSPF ved at operere direkte på datalinklaget (i stedet for IP), bruge TLV-baseret struktur for nem udvidelse og anvende et to-niveau hierarki (L1/L2) i stedet for OSPFs områdebaserede struktur. Dette gør IS-IS særligt velegnet til ISP'er som TDC, hvor stabilitet, skalerbarhed og hurtig fejlgenoprettelse er kritiske faktorer.

Med denne viden kan du nu designe og implementere IS-IS i virkelige netværk, samt fejlfinde og optimere ydeevnen baseret på protokollens avancerede mekanismer som SPF, TLV og LSP flooding.

IS-IS er en af de mest skalerbare og fremtidssikrede IGP'er, hvilket er grunden til, at den fortsat er det foretrukne valg i mange ISP verden over.


Referencer