IPv6 – EIGRP

Detta blir ett kort inlägg om EIGRP för att ta upp de skillnader som finns i implementering av EIGRP under IPv6 till skillnad mot IPv4. Se tidigare inlägg för information om mer grundläggande saker som Query-packets, Successor/Feasible successor, Stuck in Active etc.

  • Aktiveras per interface istället för via network-statements (ipv6 eigrp n)
  • Vi måste konfigurera ett router-id under eigrp-processen
  • EIGRP-processen är per default i shutdown, aktiveras genom “no shutdown” under ipv6 router eigrp n
  • Kräver IOS >=12.4.(6)T
  • Split-Horizon inaktiverat då vi kan ha flera ip-adresser per interface
  • Ingen klassfull routing eller auto-summering
  • Använder multicast-adressen FF02::A (L2 dst-adr 33:33:00:00:00:0A)

Vi konfar upp EIGRP-IPV6 enligt följande:

R1(config)#inte fa0/1
R1(config-if)#ipv6 eigrp 10 
R1(config-if)#ipv6 router eigrp 10
R1(config-rtr)#router-id 10.10.10.10
R1(config-rtr)#no shutdown
*Mar 1 00:14:58.123: %DUAL-5-NBRCHANGE: IPv6-EIGRP(0) 10: Neighbor FE80::2 (FastEthernet0/1) is up: new adjacency

Vi kan verifiera att allt är ok via:

R1#show ipv6 protocols
IPv6 Routing Protocol is "connected"
IPv6 Routing Protocol is "static"
IPv6 Routing Protocol is "eigrp 10"
 EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
 EIGRP maximum hopcount 100
 EIGRP maximum metric variance 1
 Interfaces:
 FastEthernet0/1
 Redistribution:
 None
 Maximum path: 16
 Distance: internal 90 external 170
R1#show ipv6 eigrp neighbors 
IPv6-EIGRP neighbors for process 10
H Address Interface Hold Uptime SRTT RTO Q Seq
 (sec) (ms) Cnt Num
0 Link-local address: Fa0/1 11 00:24:58 1291 5000 0 3
 FE80::2
R1#show ipv6 eigrp topology 
IPv6-EIGRP Topology Table for AS(10)/ID(10.10.10.10)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
 r - reply Status, s - sia Status
P 2001:DB8:6783::/64, 1 successors, FD is 281600
 via Connected, FastEthernet0/1
R1#show ipv6 eigrp traffic 
IPv6-EIGRP Traffic Statistics for AS 10
 Hellos sent/received: 332/332
 Updates sent/received: 4/5
 Queries sent/received: 0/0
 Replies sent/received: 0/0
 Acks sent/received: 3/2
 SIA-Queries sent/received: 0/0
 SIA-Replies sent/received: 0/0
 Hello Process ID: 230
 PDM Process ID: 194
 IPv6 Socket queue: 0/50/1/0 (current/max/highest/drops)
 Eigrp input queue: 0/2000/1/0 (current/max/highest/drops)

Debug från skapande av adjacency (debug ipv6 eigrp):

*Mar 1 00:40:48.855: %DUAL-5-NBRCHANGE: IPv6-EIGRP(0) 10: Neighbor FE80::2 (FastEthernet0/1) is up: new adjacency
*Mar 1 00:40:48.871: IPv6-EIGRP(0:10): 2001:DB8:6783::/64 - do advertise out FastEthernet0/1
*Mar 1 00:40:48.875: IPv6-EIGRP(0:10): Int 2001:DB8:6783::/64 metric 281600 - 256000 25600
*Mar 1 00:40:48.967: IPv6-EIGRP(0:10): Processing incoming UPDATE packet
*Mar 1 00:40:50.919: IPv6-EIGRP(0:10): 2001:DB8:6783::/64 - do advertise out FastEthernet0/1
*Mar 1 00:40:50.927: IPv6-EIGRP(0:10): Int 2001:DB8:6783::/64 metric 281600 - 256000 25600
*Mar 1 00:40:50.931: IPv6-EIGRP(0:10): Processing incoming UPDATE packet
*Mar 1 00:40:50.931: IPv6-EIGRP(0:10): Int 2001:DB8:6783::/64 M 307200 - 256000 51200 SM 281600 - 256000 25600
*Mar 1 00:40:50.935: IPv6-EIGRP(0:10): 2001:DB8:6783::/64 routing table not updated

Om vi vill summera ett nät använder vi kommandot:

R1(config-if)#ipv6 summary-address eigrp 10 2001:DB8:6783::/32
R2#sh ipv6 route eigrp
 IPv6 Routing Table - 18 entries
 Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
 U - Per-user Static route, M - MIPv6
 I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
 O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
 ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
 D - EIGRP, EX - EIGRP external
D 2001:DB8::/32 [90/307200]
 via FE80::1, FastEthernet0/1

En debug visar följande, observera att vi precis som i IPv4 river adjacency och inte bara skickar ett nytt Update-packet:

*Mar 1 00:43:32.199: IPv6-EIGRP(0:10): 2001:DB8::/32 (5/281600) added to RIB
 *Mar 1 00:43:32.199: %DUAL-5-NBRCHANGE: IPv6-EIGRP(0) 10: Neighbor FE80::2 (FastEthernet0/1) is down: summary configured
 *Mar 1 00:43:34.299: %DUAL-5-NBRCHANGE: IPv6-EIGRP(0) 10: Neighbor FE80::2 (FastEthernet0/1) is up: new adjacency
 *Mar 1 00:43:34.315: IPv6-EIGRP(0:10): 2001:DB8:6783::/64 - don't advertise out FastEthernet0/1
 *Mar 1 00:43:34.319: IPv6-EIGRP(0:10): 2001:DB8::/32 - do advertise out FastEthernet0/1
 *Mar 1 00:43:34.319: IPv6-EIGRP(0:10): Int 2001:DB8::/32 metric 281600 - 256000 25600
 *Mar 1 00:43:34.379: IPv6-EIGRP(0:10): Processing incoming UPDATE packet

Det finns inte så mycket mer att ta upp faktiskt, det mesta är sig likt från IPv4. Next up, BGP! 🙂

IPv6 – RIPng

Detta blir ett kortare inlägg om RIPng då det inte finns speciellt mycket att gå igenom, det är fortfarande precis lika basic som RIP/RIPv2 (IPv4). Det mesta är sig även likt när det kommer till hur själva protokollet fungerar.

  • Kommunicerar över UDP 521
  • Skickar uppdateringar över Multicast, dst-adr; FF02::9
  • Metric – Hop count (max 16)
  • Använder link-local som source-adress i sina uppdateringar
  • Har fortfarande en AD på 120
  • Skickar periodiska uppdateringar var 30:e sekund med hela sin rip-databas
  • Skickar även “triggered-updates” när ex. ett nät går ner/läggs till (innehållandes endast de påverkade näten)
  • RFC 2080

Den lilla skillnaden som finns är att routern vid en inkommande uppdatering alltid tar Hopcount + 1 innan den installerar routen i sin databas. Detta gör att om vi jämför en identisk topologi mellan RIPv2 & RIPng kommer vi se 1 högre hop-count för routes i RIPng. Vi aktiverar även själva RIPng-processen direkt på interfacet istället för via “router rip”.

Har i tidigare inlägg visat hur vi aktiverar RIPng så detta får bli lite repetition.

ipv6-simple-topology

R1 / R2 / R3:

int fa0/0
ipv6 rip RIP-LAB enable
int s0/0
ipv6 rip RIP-LAB enable
int s0/1
ipv6 rip RIP-LAB enable
int lo0
ipv6 rip RIP-LAB enable

Show ipv6 rip visar följande:

RIP process "RIP-LAB", port 521, multicast-group FF02::9, pid 192
 Administrative distance is 120. Maximum paths is 16
 Updates every 30 seconds, expire after 180
 Holddown lasts 0 seconds, garbage collect after 120
 Split horizon is on; poison reverse is off
 Default routes are not generated
 Periodic updates 4, trigger updates 2
 Interfaces:
 Loopback0
 Serial0/1
 Serial0/0
 FastEthernet0/0
 Redistribution:
 None

RIPng-Databasen vi skickar var 30:e sekund kan vi lista genom “show ipv6 rip database”:

RIP process "RIP-LAB", local RIB
 2001:DB8:6783:2::/64, metric 2, installed
 Serial0/0/FE80::2, expires in 177 secs
 2001:DB8:6783:3::/64, metric 2, installed
 Serial0/1/FE80::3, expires in 175 secs
 2001:DB8:6783:12::/64, metric 2
 Serial0/0/FE80::2, expires in 177 secs
 2001:DB8:6783:13::/64, metric 2
 Serial0/1/FE80::3, expires in 175 secs
 2001:DB8:6783:23::/64, metric 2, installed
 Serial0/1/FE80::3, expires in 175 secs
 Serial0/0/FE80::2, expires in 177 secs
 2001:DB8:6783:2222::/64, metric 2, installed
 Serial0/0/FE80::2, expires in 177 secs
 2001:DB8:6783:3333::/64, metric 2, installed
 Serial0/1/FE80::3, expires in 175 secs

En show ipv6 ip route visar väl inte direkt något nytt den heller:

IPv6 Routing Table - 14 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
 U - Per-user Static route, M - MIPv6
 I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
 O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
 ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
 D - EIGRP, EX - EIGRP external
R 2001:DB8:6783:2::/64 [120/2]
 via FE80::2, Serial0/0
R 2001:DB8:6783:3::/64 [120/2]
 via FE80::3, Serial0/1
R 2001:DB8:6783:23::/64 [120/2]
 via FE80::2, Serial0/0
 via FE80::3, Serial0/1
R 2001:DB8:6783:2222::/64 [120/2]
 via FE80::2, Serial0/0
R 2001:DB8:6783:3333::/64 [120/2]
 via FE80::3, Serial0/1

En av skillnaderna från RIP/RIPv2 var som sagt att vi nu lägger till ett extra hop count. Vi kan verifiera detta med en “debug ipv6 rip” som låter oss inspektera uppdateringarna som inkommer från R2 & R3:

Från R2:

*Mar 1 00:09:12.975: RIPng: response received from FE80::2 on Serial0/0 for RIP-LAB
*Mar 1 00:09:12.975: src=FE80::2 (Serial0/0)
*Mar 1 00:09:12.979: dst=FF02::9
*Mar 1 00:09:12.979: sport=521, dport=521, length=132
*Mar 1 00:09:12.979: command=2, version=1, mbz=0, #rte=6
*Mar 1 00:09:12.979: tag=0, metric=1, prefix=2001:DB8:6783:2222::/64
*Mar 1 00:09:12.979: tag=0, metric=1, prefix=2001:DB8:6783:2::/64
*Mar 1 00:09:12.983: tag=0, metric=1, prefix=2001:DB8:6783:12::/64
*Mar 1 00:09:12.983: tag=0, metric=1, prefix=2001:DB8:6783:23::/64
*Mar 1 00:09:12.983: tag=0, metric=2, prefix=2001:DB8:6783:3333::/64
*Mar 1 00:09:12.983: tag=0, metric=2, prefix=2001:DB8:6783:3::/64

R3:

*Mar 1 00:09:37.155: RIPng: response received from FE80::3 on Serial0/1 for RIP-LAB
*Mar 1 00:09:37.155: src=FE80::3 (Serial0/1)
*Mar 1 00:09:37.159: dst=FF02::9
*Mar 1 00:09:37.159: sport=521, dport=521, length=132
*Mar 1 00:09:37.159: command=2, version=1, mbz=0, #rte=6
*Mar 1 00:09:37.159: tag=0, metric=1, prefix=2001:DB8:6783:3333::/64
*Mar 1 00:09:37.159: tag=0, metric=1, prefix=2001:DB8:6783:3::/64
*Mar 1 00:09:37.163: tag=0, metric=1, prefix=2001:DB8:6783:23::/64
*Mar 1 00:09:37.163: tag=0, metric=1, prefix=2001:DB8:6783:13::/64
*Mar 1 00:09:37.163: tag=0, metric=2, prefix=2001:DB8:6783:2::/64
*Mar 1 00:09:37.163: tag=0, metric=2, prefix=2001:DB8:6783:2222::/64

Om vi tittar närmare på prefix=2001:DB8:6783:3333::/64″ vi lärde oss från R3 så har den i uppdateringen metric satt till 1.  Men en show ipv6 route 2001:DB8:6783:3333::/64 visar:

R 2001:DB8:6783:3333::/64 [120/2]
 via FE80::3, Serial0/1

Om vi vill annonsera en default-route (::/1) till våra neighbors så använder vi följande kommando:

R1:
int s0/0ipv6 rip RIP-LAB default-information originateint s0/1ipv6 rip RIP-LAB default-information originate

En debug ip R2 visar att vi nu även får en default-route från R1:

*Mar 1 00:17:03.411: src=FE80::1 (Serial0/0)
*Mar 1 00:17:03.415: dst=FF02::9
*Mar 1 00:17:03.415: sport=521, dport=521, length=152
*Mar 1 00:17:03.415: command=2, version=1, mbz=0, #rte=7
*Mar 1 00:17:03.415: tag=0, metric=1, prefix=2001:DB8:6783:1111::/64
*Mar 1 00:17:03.415: tag=0, metric=1, prefix=2001:DB8:6783:1::/64
*Mar 1 00:17:03.419: tag=0, metric=1, prefix=2001:DB8:6783:13::/64
*Mar 1 00:17:03.419: tag=0, metric=1, prefix=2001:DB8:6783:12::/64
R2#sh ipv6 route 
*Mar 1 00:17:03.419: tag=0, metric=2, prefix=2001:DB8:6783:3333::/64
*Mar 1 00:17:03.419: tag=0, metric=2, prefix=2001:DB8:6783:3::/64
*Mar 1 00:17:03.423: tag=0, metric=1, prefix=::/0
R2#sh ipv6 route ::/1 | beg ::
R ::/0 [120/2]
 via FE80::1, Serial0/0

En liten notis är att till skillnad från RIP/RIPv2 så annonseras även nätet som är “Directly connected” med dess neighbor. Exempelvis så annonserar R1 den seriella länken mellan R1 & R2 om vi kan se i följande wireshark-dump:

ipv6-ripng

Det är ungefär allt som finns att ta upp om RIPng, Ska försöka få upp två inlägg om EIGRP & OSPFv3 asap så jag kan börja med lite roligare grejjer sen, det här känns inte direkt superspännande.. 🙂

IPv6 – Simple Topology & RIPng

Detta blir ett kortare inlägg om hur vi konfar upp ett litet IPv6-nät med Global & Link-local adresser.

ipv6-simple-topology

Låt oss börja med R1:

För att aktivera IPv6 routing måste vi först lägga till:

ipv6 unicast-routing

Interface-konfigen blir sedan:

interface FastEthernet0/0
description To CustLAN
!Global
ipv6 address 2001:db8:6783:1::1/64
!Sätter statisk ipv6 för link-local istället för en genererad EUI64-adress
ipv6 address fe80::1 link-local
no shut
interface Serial0/0
 ipv6 address FE80::1 link-local
 ipv6 address 2001:DB8:6783:12::1/64
 clock rate 256000
no shut

interface Serial0/1
 ipv6 address FE80::1 link-local
 ipv6 address 2001:DB8:6783:13::1/64
 clock rate 256000
no shut
interface Loopback0
ipv6 address 2001:db8:6783:1111::1/64

Det är inga problem att ha samma link-local adress på alla interface, kom ihåg att den endast gäller lokalt inom L2-segmentet!

Detta ger följande output:

ipv6-biref

R2:

ipv6 unicast-routing
interface Loopback0
ipv6 address 2001:DB8:6783:2222::2/64

interface FastEthernet0/0
ipv6 address FE80::2 link-local
 ipv6 address 2001:DB8:6783:2::2/64
no shut

interface Serial0/0
ipv6 address FE80::2 link-local
 ipv6 address 2001:DB8:6783:12::2/64
no shut

interface Serial0/1
ipv6 address FE80::2 link-local
 ipv6 address 2001:DB8:6783:23::2/64
 clock rate 256000
no shut

R3

ipv6 unicast-routing
interface Loopback0
ipv6 address 2001:DB8:6783:3333::3/64
no shut
interface FastEthernet0/0
ipv6 address FE80::3 link-local
ipv6 address 2001:DB8:6783:3::3/64
no shut
interface Serial0/0
ipv6 address FE80::3 link-local
ipv6 address 2001:DB8:6783:23::3/64
no shut
interface Serial0/1
ipv6 address FE80::3 link-local
ipv6 address 2001:DB8:6783:13::3/64
no shut

Hur gör vi då om vi vill använda oss av ett routing-protokoll. Låt oss börja med den enklaste, RIPng (RIP Next-Generation).

Till skillnad från IPv4 så aktiverar vi RIPng på interfacet istället för via network-statements, samt vilken RIP-instans vi vill ansluta interfacet till.

Konfigen är densamma för R1/R2/R3:

int fa0/0
ipv6 rip RIP-LAB enable
int s0/0
ipv6 rip RIP-LAB enable
int s0/1
ipv6 rip RIP-LAB enable
int lo0
ipv6 rip RIP-LAB enable

Löjligt enkelt. Vi verifierar med hjälp av show ipv6 route rip:

ipv6-route

Observera att routern använder Link-local adresser som next hop!

R1#ping ipv6 2001:db8:6783:2::2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:6783:2::2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/5/20 ms
R1#ping ipv6 2001:db8:6783:3::3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:6783:3::3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/9/28 ms

OSPF – Authentication

OSPF kan precis som övriga routingprotokoll använda sig av autentisering. Till skillnad från EIGRP finns dock förutom MD5-kryptering även möjligheten att använda clear text, fast det är väl inte direkt någon fördel.. 😉

Varje OSPF-paket kommer autentiseras när vi aktiverar detta över en länk, dvs inte bara när adjacency bildas.

Om vi kollar en debug för R2 av OSPF-paketen i följande topologi kan vi se detta “in action”.

ospf authentication

*Mar 1 00:11:10.471: OSPF: rcv. v:2 t:1 l:48 rid:10.0.0.1
 aid:0.0.0.0 chk:C494 aut:0 auk: from FastEthernet0/0

Aut-fältet visar vilken autentisering som används.

  • Aut 0 – Ingen autentisering
  • Aut 1 – Clear text
  • Aut 2 – MD5-krypterat

Clear-text

Detta är givetvis inte rekommenderat att använda, men det kan ändå vara bra att känna till hur vi konfigurerar det.

R1
int fa0/0
ip ospf authentication
ip ospf authentication-key pa$$word (8 texten är max)

R2
Int fa0/0
ip ospf authentication
ip ospf authentication-key pa$$word (8 texten är max)

Istället för att skriva raden “ip ospf authentication” för varje interface  går det även att göra det globalt via:

router ospf 1
area 0 authentication

Det krävs dock fortfarande att vi anger en nyckel för respektive interface så det är väl individuellt vad man tycker är enklast.

En debug visar att aut nu ändrats till 1.

*Mar 1 00:18:00.931: OSPF: rcv. v:2 t:1 l:48 rid:10.0.0.1
 aid:0.0.0.0 chk:C493 aut:1 auk: from FastEthernet0/0

I wireshark kan vi se följande:

auth cleartext

Ganska enkelt att se varför vi inte vill använda oss av clear text.. 🙂

MD5-kryptering

Låt oss byta till MD5 istället.

R1
int fa0/0
ip ospf message-digest 1 md5 pa$$word
ip ospf authentication message-digest
R2
int fa0/0
ip ospf message-digest 1 md5 pa$$word
ip ospf authentication message-digest

En debug visar följande:

*Mar 1 00:25:10.559: OSPF: rcv. v:2 t:1 l:48 rid:10.0.0.1
 aid:0.0.0.0 chk:0 aut:2 keyid:1 seq:0x3C7ECA46 from FastEthernet0/0

Som synes har vi nu även key-id angivet vilket måste matcha mellan routrarna. Ändrar vi R1 till key 2 (ip ospf message-digest 2 md5 pa$$word) så tappar vi adjacency och ser följande i en debug:

R1(config-if)#do debug ip ospf adj
OSPF adjacency events debugging is on
*Mar 1 00:28:06.111: OSPF: Rcv pkt from 10.0.0.2, FastEthernet0/0 : Mismatch Authentication Key - No message digest key 1 on interface

Om vi jämför MD5 mot clear text i wireshark ser vi fördelen med kryptering.

auth md5

Ingen direkt djupdykning idag men just autentisering är rätt basic.

OSPF – The Basics

Intro

OSPF är ett Link-state Routing Protocol, som till skillnad från Distance Vector (EIGRP/RIP) har en karta över hela nätverket (åtminstone sin area, men mer om det senare) i sin topology-table, och varje router räknar själv ut den bästa vägen för att nå sin destination genom Dijkstra’s Shortest Path First (SPF)-Algoritm.

Förhoppningsvis har vi inte redan glömt att nackdelen med just Distance Vector är att de endast vet vad dess grannar berättat. En annan stor fördel gentemot  EIGRP är att OSPF är OpenSource och ej låst till Cisco, det  finns med andra ord möjligheter att sätta upp ett “mixed vendor”-nätverk och få dessa att prata med varandra genom OSPF!

OSPF använder sig av triggade updates, och skickar endast ut information om någon förändring inträffar på nätverket, som ex att en länk går ner/ett nät läggs till. Har det dock inte hänt något på 30 minuter skickas en “ls refresh” från varje router med dess routing-information för att vara säker på att alla har samma bild av nätverket och inget har missats.

OSPF använder precis som EIGRP tre “tables”:

Neighbor Table

Innehåller information om grannar som skickat Hello-paket till routern (behöver nödvändigtvis ej ha full adjacency mellan varandra). Information som ex. Router-ID, IP-adress och interface sparas här.

R1#sh ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
3.3.3.3 1 FULL/DR 00:00:30 12.0.0.2 FastEthernet0/1
2.2.2.2 1 FULL/DR 00:00:38 10.0.0.2 FastEthernet0/0

Topology Table

Innehåller samtliga routes inom en area, tillskillnad från ex. EIGRP som endast sparar successor/f.successor-routes.

R1#show ip ospf route
OSPF Router with ID (1.1.1.1) (Process ID 1)
Area BACKBONE(0)
Intra-area Route List
* 12.0.0.0/24, Intra, cost 10, area 0, Connected
 via 12.0.0.1, FastEthernet0/1
* 10.0.0.0/24, Intra, cost 10, area 0, Connected
 via 10.0.0.1, FastEthernet0/0
*> 11.0.0.0/24, Intra, cost 20, area 0
 via 12.0.0.2, FastEthernet0/1
 via 10.0.0.2, FastEthernet0/0
*> 192.168.0.0/24, Intra, cost 11, area 0
 via 12.0.0.2, FastEthernet0/1
* 1.1.1.1/32, Intra, cost 1, area 0, Connected
 via 1.1.1.1, Loopback0
*> 2.2.2.2/32, Intra, cost 11, area 0
 via 10.0.0.2, FastEthernet0/0
*> 3.3.3.3/32, Intra, cost 11, area 0
 via 12.0.0.2, FastEthernet0/1

Routing Table

Fungerar precis som vanligt, de routes med lägst metric till en destination sparas här. Observera att även OSPF har lastbalansering då det installerats två vägar till nätet 11.0.0.0/24 när metricen är densamma.

1.0.0.0/32 is subnetted, 1 subnets
C 1.1.1.1 is directly connected, Loopback0
 2.0.0.0/32 is subnetted, 1 subnets
O 2.2.2.2 [110/11] via 10.0.0.2, 00:24:35, FastEthernet0/0
 3.0.0.0/32 is subnetted, 1 subnets
O 3.3.3.3 [110/11] via 12.0.0.2, 00:22:30, FastEthernet0/1
 10.0.0.0/24 is subnetted, 1 subnets
C 10.0.0.0 is directly connected, FastEthernet0/0
 11.0.0.0/24 is subnetted, 1 subnets
O 11.0.0.0 [110/20] via 12.0.0.2, 00:22:30, FastEthernet0/1
           [110/20] via 10.0.0.2, 00:24:36, FastEthernet0/0
O 192.168.0.0/24 [110/11] via 12.0.0.2, 00:14:28, FastEthernet0/1
 12.0.0.0/24 is subnetted, 1 subnets
C 12.0.0.0 is directly connected, FastEthernet0/1

Metric

OSPF använder sig av en metric som kallas “cost”. Cost adderas för varje utgående interface och får dess värde från =  10^8 / Bandwith, men vi kan förenkla detta genom att istället skriva 100 / Bandwith (i Mbps). Till skillnad från EIGRP så sparar OSPF endast den bästa routen som räknats ut genom SPF, om en förändring sker måste routern därför gå tillbaka och räkna ut en ny väg (om möjligt).

Här är en tabell med de vanligaste hastigheterna och dess cost:

  • 56k – 1785
  • 64k – 1562
  • T1 (1,544) – 65
  • E1 (2,048) – 48
  • Ethernet – 10
  • Fast Ethernet – 1

Som du kanske ser så har OSPF per default ingen möjlighet att se skillnad på länkar över 100Mbit, främst pga cost-utträkningen togs fram under 80-talet.. 🙂 Vi kan dock ändra detta genom kommandot:

router ospf x
auto-cost reference-bandwith x (anges i Mbps, 100 är default)

Om vi har länkar upp till 10Gb i vårat nätverk skulle vi då sätta reference-bandwith till 10000, detta måste ändras på samtliga routrar!

Areas

OSPF använder sig av ett koncept som kallas Area’s, per default kommer du alltid ha en standard-area, “0”, detta är även vad vi kallar “Backbone area“. Genom att använda area’s får vi en möjlighet att segmentera nätverket vilket har flera fördelar, exempelvis behöver OSPF endast skicka uppdateringar och använda SPF-algoritmen för att räkna ut den bästa vägen inom sin egen area. Detta minskar belastningen på CPU:er och ger snabbare konvergenstider. Om vi använder oss av en liknelse med GPS, så går det ju betydligt snabbare att räkna ut kortaste vägen mellan två gator inom samma stad än ex. hela sträckan mellan Västerås –  Malmö (Västerås hade varit en egen ospf-area).

OSPF areas

Det finns vissa regler som gäller för just areas:

  • Varje area måste ha en anslutning till area 0 / Backbone (kan dock vara virtuell, mer om detta senare)
  • Alla routrar inom en area måste ha samma topology-table/samma uppfattning om hur nätet ser ut
  • Uppdateringar skickas endast inom den egna arean
  • Routrar mellan två area’s kallas “Area Border Router” (ABR)
  • Routrar som är anslutet till ett annat nätverk som inte använder OSPF (ex BGP/RIP/EIGRP) kallas “Autonomous Border Router” (ASBR)
  • Nätsummeringar kan endast göras i ABR & ASBR
  • Neighbor-adjacencys skapas endast inom samma area

Cisco rekommenderar förövrigt att vi har max 50st routrar per area, och varje router bör endast vara neightbor med max. 16st andra. Men efter att ha lyssnat på OSPF – Design från PacketPushers  som jag länkade i ett tidigare inlägg så kan vi konstatera att detta är grovt överdrivet, och det är egentligen inga som helst problem att ha hundratals routrar i en och samma area. KSS – Keep it Simple Stupid! 🙂

Packet Types

OSPF använder sig ej av TCP för sin kommunikation utan har skapat sitt eget Lager 4-protokoll för att verifiera att allt sänds OK. De paket-typer som finns i OSPF är följande:

  • Hello-packet: Används för att sätta upp Neighbor-adjacencys
  • Database Description-packet (DBD): En “lightversion” av routerns linkstate database
  • Linkstate Request (LSR*): Används för att be om mer detaljerad information från en router
  • Linkstate Update(LSU*): Används för att skicka mer detaljerad routing-information
  • Linkstate Advertisement(LSA): En LSU innehåller en/flera LSA’s för att minska det antal paket som behöver skickas, varje enskild LSA innehåller information om en specifik route
  • Linkstack Acknowledgement(LSAck): För att bekräfta att DBD/LSR/LSU-paket kommit fram skickas en LSAck tillbaka

*Vid debugging visas LSR som LS REQ och LSU som LS UPD.

Hello-Packets

Efter att vi startat OSPF-processen för ett interface kommer routern börja skicka ut Hello-paket. Till skillnad från EIGRP så är det ganska mycket information som dessa innehåller och ett flertal fält måste vara identiska för att en adjacency skall kunna skapas. Hello-paketet består för följande information:

  • Router-ID: Varje OSPF-Router behöver ett unikt router-id, mer om detta senare)
  • Hello / Dead interval*: Här bestäms intervallet som Hello-paket kommer att skickas samt hur länge vi väntar innan en neighbor anses som offline (samma som EIGRP’s Holdtimer), dead interval är per default “Hellotimer x 4”
  • Neighbors: Innehåller information om routerns övriga neighbors
  • Area ID*: Vilket area routern befinner sig i
  • Router Priority: Används för att bestämma vem som blir Designated Router (DR) / Backup Designated Router (BDR), mer om detta senare
  • DR & BDR IP-adress: IP-adressen till routerns DR / BDR
  • Authentication Password*: Används för lösenordsskyddade routinguppdateringar, antingen i cleartext eller md5
  • Stub area flag*:  Förutom olika area-nummer har OSPF även olika typer av areas, mer om detta senare

Punkterna markerade med “*” kräver att båda routrarna har identiskt information för respektive fält. Hello-paket skickas per default ut var 10:e sekund på Broadcast/P2P-länkar, och var 30:e sekund på NMBA. Då dead interval var “4 x hello-timer” innebär detta att det sedan kommer ta 40 sekunder innan en router anser att sin granne är död på ex. ett ethernet-nätverk, och hela 180 sekunder på ett frame-relay nät!

Observera att AS-numret aldrig skickas med, till skillnad från EIGRP är OSPF’s AS endast lokalt, du kan därför blanda AS-nummer mellan routrarna och de kommer ändå få adjacency om resterande fält är ok. Varför man nu skulle vilja göra detta??.. 🙂

En debug så ser vi hur paketen ser ut i CLI:

R1#debug ip ospf packet
OSPF packet debugging is on
R1#
*Mar 1 04:00:27.539: OSPF: rcv. v:2 t:1 l:48 rid:3.3.3.3
 aid:0.0.0.0 chk:CF93 aut:0 auk: from FastEthernet0/1
  • V:2 – OSPF-version (IPv6 använder OSPFv3)
  • T:1 – Typ av OSPF-paket, 1 = Hello-paket
  • L:48 – Paketlängd i bytes
  • RID – Router-ID, i detta fall 3.3.3.3
  • AID – Area-ID, i detta fall 0
  • CHK:CF93 – Checksum för felhantering
  • AUT:0 – Autentisering, 0 = ingen (1 är cleartext, 2 md5)
  • AUK: – Används endast om autentisering är aktiverat

Neighbor Adjacency

Processen att sätta upp en Neighbor Adjacency i OSPF är tyvärr inte på långa vägar lika enkelt som EIGRP där vi endast behöver utbyta varsitt hello-paket, utan här är det betydligt mer omständigt. Efter att du startat OSPF-processen på R1 sker följande (vi förutsätter att det redan är aktiverat på R3):

ospf neighbors

R1 IP: 10.0.0.1
R2 IP: 10.0.0.2

Steg 1

R1 kommer först att välja ett Router-ID (ingår i Hello-paketet), och detta kan göras på tre olika sätt:

  • Routern väljer den högsta IP-adressen från något av sina aktiva interface (behöver ej köra OSPF)
  • Om ett loopback-interface finns konfigurerat har detta högre prioritet än andra interface oavsett IP-adress
  • Om du manuellt skriver in ett Router-ID så har detta prioritet över både Loopback och andra interface, oavsett adress

Det går sedan endast att byta Router-ID vid omstart av OSPF-processen alternativt hela routern. Kommer återkomma till detta när vi börjar prata om DR / BDR senare. I detta fall kommer Router-ID att bli 1.1.1.1.

Steg 2

R1 lägger till det interface du specificerat under “network x.x.x.x x.x.x.x area x” i “Link-state Database” (LSDB). Ex:

router ospf 1
network 10.0.0.0 0.0.0.3 area 0

Steg 3 – “Down State”

R1 börjar skicka ut Hello-paket på Fa0/1-interfacet innehållande den information vi skrev om under “Hello-packets” via multicast på adressen 224.0.0.5. Länken betraktas nu vara i ett “Down State” tills den själv mottar ett Hello-paket.

Steg 4 – “Init State”

R1 har nu förutom att börja skicka ut sina egna Hello-paket även mottagit ett från sin neighbor R3, detta skickades som ett unicast direkt till R1 på 10.0.0.1. Länken ändras från att vara i ett “Down State” till “Init State“, R1 & R3 jämför nu så att alla fält markerade med * under Hello-packet stämmer överens med den information de själv besitter. Är allt ok går de vidare till Steg 5, om inte så backar de länken till “Down State“/steg 3 igen.

Steg 5 – “2-way State”

R1 & R3 kontrollerar nu om den redan finns angiven under “Neighbors”-fältet i det mottagna Hello-paketet, om så är fallet bortser den från Hello-paketet och nollställer istället Dead interval.

Finns de inte med betraktas neighborn som ny och läggs istället till i “Neighbor Table“, de går sedan vidare till Steg 6.

Steg 6 – “Exstart State”

Länken ändras från ett “2-way State” till ett “Exstart State“. De två routrarna kommer nu överens om vem som skall vara Master & Slave, detta bestäms efter:

  • Priority (default “1”)
  • Om Priority är samma används istället Router-ID, där högst router-id = Master

Master/Slave-förhållandet bestämmer endast vilken av routrarna som skall börja skicka sin routing-information till den andra. I detta exempel hade R3 blivit Master, och R1 Slave. Efter de kommit överens sker följande:

  • Master skickar en “lightversion av sin routing-databas innehållande vilka routes den känner till, detta kallas “Database Description-Packet” (DBD), Jeremy från CBT kallade även detta “Cliffnotes of it’s linkstate database”
  • Slave skickar en Ack på Mastern’s DBD-paket och sänder sedan sitt egna DBD-paket
  • Master skickar en Ack på Slave’s DBD-paket

Steg 7 – “Loading State”

Både Master & Slave går nu över den information de fått i DBD-paketet och jämför med sin egen linkstate database. För de nät de inte redan känner till sker följande:

  • Slave skickar ett Linkstate Request (LSR) och ber om mer information för dessa nät
  • Master skickar en LSAck och svarar med en Linkstate Update (LSU), som i sin tur innehåller en Linkstate Advertisement (LSA) för varje route Slave behövde information om
  • Slave svarar med en LSAck
  • Master skickar ett Linkstate Request (LSR) och ber om mer information
  • Slave skickar en LSAck och svarar med en  Linkstate Update (LSU), som i sin tur innehåller en Linkstate Advertisement (LSA) för varje route Master behövde information om
  • Master svarar med en LSAck

Steg 8 – “Full State”

R1 & R3 är nu synkade med varandra och länken ändras från “Loading State” till “Full State“. Det är nu dags för SPF att kavla upp ärmarna och räkna ut vilka routes som skall läggas till i Routing Table.

Debug

Det är ju alltid bättre att se hur det faktiskt fungerar i verkligen än att jag sitter och skriver såhär. Här följer en debug från R1 som visar hela händelseförloppet från Steg 1 till Steg 8 (har dock rensat bort info om BD/BDR).

*Mar 1 04:17:22.914: OSPF: Interface FastEthernet0/1 going Up
*Mar 1 04:17:22.954: OSPF: 2 Way Communication to 3.3.3.3 on FastEthernet0/1, state 2WAY <- Steg 5
*Mar 1 04:17:22.958: OSPF: Backup seen Event before WAIT timer on FastEthernet0/1
*Mar 1 04:17:22.962: OSPF: Send DBD to 3.3.3.3 on FastEthernet0/1 seq 0x1DEF opt 0x52 flag 0x7 len 32
R1(config-router)#
*Mar 1 04:17:22.998: OSPF: Rcv DBD from 3.3.3.3 on FastEthernet0/1 seq 0xBD2 opt 0x52 flag 0x7 len 32 mtu 1500 state EXSTART <- Steg 6
*Mar 1 04:17:22.998: OSPF: NBR Negotiation Done. We are the SLAVE 
*Mar 1 04:17:23.002: OSPF: Send DBD to 3.3.3.3 on FastEthernet0/1 seq 0xBD2 opt 0x52 flag 0x0 len 32
*Mar 1 04:17:23.038: OSPF: Rcv DBD from 3.3.3.3 on FastEthernet0/1 seq 0xBD3 opt 0x52 flag 0x3 len 92 mtu 1500 state EXCHANGE
*Mar 1 04:17:23.038: OSPF: Send DBD to 3.3.3.3 on FastEthernet0/1 seq 0xBD3 opt 0x52 flag 0x0 len 32
*Mar 1 04:17:23.070: OSPF: Rcv DBD from 3.3.3.3 on FastEthernet0/1 seq 0xBD4 opt 0x52 flag 0x1 len 32 mtu 1500 state EXCHANGE
*Mar 1 04:17:23.070: OSPF: Exchange Done with 3.3.3.3 on FastEthernet0/1
*Mar 1 04:17:23.070: OSPF: Send LS REQ to 3.3.3.3 length 36 LSA count 3 <- Steg 7
*Mar 1 04:17:23.074: OSPF: Send DBD to 3.3.3.3 on FastEthernet0/1 seq 0xBD4 opt 0x52 flag 0x0 len 32
*Mar 1 04:17:23.106: OSPF: Rcv LS UPD from 3.3.3.3 on FastEthernet0/1 length 132 LSA count 3
*Mar 1 04:17:23.106: OSPF: Synchronized with 3.3.3.3 on FastEthernet0/1, state FULL
*Mar 1 04:17:23.106: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on FastEthernet0/1 from LOADING to FULL, Loading Done <- Steg 8

Och nu är det äntligen klart! Inte riktigt lika enkelt som EIGRP kanske.. 😉 Det finns dock undantag till ovanstående, men det återkommer jag till i nästa post om BD/BDR.

EIGRP – Debug dump

eigrp debug as

Gjorde följande labb från GNS3-vault idag som inte var helt enkel. Scenariot är att du precis installerat en ny router (Jack) men saknar tillgång och dokumentation angående router John. Du behöver nu få igång en EIGRP-adjacency mellan dessa två, hur gör du (behöver få fram AS-numret på något vis)?

Jag började först med att testa mig fram mellan alla EIGRP-debug kommandon utan något resultat. Satte upp EIGRP med AS 1 på Jack som test, men detta var det enda jag kunde se:

*Mar 1 00:54:57.899: EIGRP: Sending HELLO on FastEthernet0/0
*Mar 1 00:54:57.903: AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
*Mar 1 00:55:02.439: EIGRP: Sending HELLO on FastEthernet0/0
*Mar 1 00:55:02.443: AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0

Tydligen så när det är mismatch på AS-nummer så discardas hello-paketet från John, Gjorde istället ett försök med en access-lista,

ip access-list extended 100
permit eigrp host 192.168.12.2 any

debug ip packet 100 visade så följande:

*Mar 1 00:57:03.131: IP: s=192.168.12.2 (FastEthernet0/0), d=224.0.0.10, len 60, rcvd 2
*Mar 1 00:57:07.643: IP: s=192.168.12.2 (FastEthernet0/0), d=224.0.0.10, len 60, rcvd 2
*Mar 1 00:57:11.943: IP: s=192.168.12.2 (FastEthernet0/0), d=224.0.0.10, len 60, rcvd 2

debug ip packet 100 detail var inte heller till mycket hjälp:

*Mar 1 00:57:53.027: IP: s=192.168.12.2 (FastEthernet0/0), d=224.0.0.10, len 60, rcvd 2, proto=88
*Mar 1 00:57:57.355: IP: s=192.168.12.2 (FastEthernet0/0), d=224.0.0.10, len 60, rcvd 2, proto=88

Efter lite googlande så visade det sig att det finns ett dolt kommando under debug ip packet, debug ip packet 100 dump.

*Mar 1 00:35:21.451: IP: s=192.168.12.2 (FastEthernet0/0), d=224.0.0.10, len 60, rcvd 2
07A014C0: 0100 5E00000A ..^...
07A014D0: CC0617A8 00000800 45C0003C 00000000 L..(....E@.<....
07A014E0: 01580BF6 C0A80C02 E000000A 0205EEC0 .X.v@(..`.....n@
07A014F0: 00000000 00000000 00000000 0000000C ................
07A01500: 0001000C 01000100 0000000F 00040008 ................
07A01510: 0C040102 ....

Det vi letar efter är raden med “leading 0’s”, dvs den 4:e raden. 0000000C är ju bevisligen i hex, så om vi gör om detta till binärt får vi = 12. Låt oss testa!

Jack(config)#router eigrp 12
Jack(config-router)#network 0.0.0.0
Jack(config-router)#
*Mar 1 01:00:35.291: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 12: Neighbor 192.168.12.2 (FastEthernet0/0) is up: new adjacency

Kanske inte något man kommer använda varje dag direkt men ändå. 🙂

EIGRP – Authentication

Något jag glömt nämna men som är väldigt basic är att aktivera autentisering för EIGRP.

Konfigen är enligt följande:

key chain LAB
 key 1
   key-string CISCO
interface x/x
ip authentication key-chain eigrp 1 LAB
ip authentication mode eigrp 1 md5

Debuggar vi hello-paket kan vi nu se följande:

*Mar 1 01:05:31.375: EIGRP: received packet with MD5 authentication, key id = 1
*Mar 1 01:05:31.379: EIGRP: Received HELLO on Serial0/1 nbr 192.168.45.5
*Mar 1 01:05:31.379: AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0

Viktigt är att nyckeln har samma nummer på båda routrar annars kommer neighbor adjacency att misslyckas. Vi testar detta genom att sätta Key 2 på den ena neighborn istället:

*Mar 1 01:09:50.555: EIGRP: Sending HELLO on Serial0/1
*Mar 1 01:09:50.559: AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
*Mar 1 01:09:53.083: EIGRP: pkt authentication key id = 2, key not defined or not live

Det finns även möjlighet att göra använda sig av dynamiska/tidsstyrda nycklar, detta kräver dock att båda routrarna synkar mot en NTP-server så att de har samma tid.

key chain LAB
 key 1
 key-string CISCO
 accept-lifetime 00:00:00 Jan 1 2013 00:00:00 Jan 1 2014
 send-lifetime 00:00:00 Jan 1 2013 00:00:00 Jan 1 2014
 key 2
 key-string CISCO2
 accept-lifetime 00:00:00 Jan 1 2014 00:00:00 Jan 1 2015
 send-lifetime 00:00:00 Jan 1 2014 00:00:00 Jan 1 2015

Efter att ha aktiverat detta tappar vi dock neigbor-adjacency, varför? En debug visar föjande:

*Mar 1 01:14:34.439: EIGRP: interface Serial0/1, No live authentication keys
*Mar 1 01:14:35.503: EIGRP: interface Serial0/1, No live authentication keys
*Mar 1 01:14:35.507: EIGRP: Sending HELLO on Serial0/1

En show clock visar problemet, nyckeln kommer inte börja användas förrän om 11 år.. 🙂

Dobbs#sh clock
*01:15:45.683 UTC Fri Mar 1 2002

Efter att vi ställt in klockan så får vi direkt upp adjacency, detta visar varför det är så viktigt med tidssynkronisering!

Dobbs#clock set 16:22:00 11 June 2013 
*Jun 11 16:22:00.000: %SYS-6-CLOCKUPDATE: System clock has been updated from 01:17:01 UTC Fri Mar 1 2002 to 16:22:00 UTC Tue Jun 11 2013, configured from console by console.
Dobbs#
Jun 11 16:22:01.871: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.45.4 (Serial0/1) is up: new adjacency

EIGRP – Query-packet, Stubzone & SIA

Query-packet

När EIGRP tappar en successor-route och det ej finns någon feasible succesor ändras routen från “Passive” till “Active” i topology-table och routern börjar sedan skicka ut Query’s på samtliga interface (exkl. successorn) där den frågar om någon annan neighbor känner till detta nät.

Ta topologin nedan som exempel:

query1

R1 tappar sin länk och har inte längre en route till 10.0.0.0/24-nätet. Det finns ingen feasible successor då det endast är R1 som är anslutet till detta nät, 10.0.0.0/24 kommer därför ändras från Passive till Active och R1 kommer skicka ut Query’s på övriga interface till R2 & R3 och fråga om de känner till detta nät. R2 & R3 saknar kännedom och kommer därför själva skicka en query till sina neighbors (R4, R5, R6, R7).

query2

R2 & R3 kommer inte svara R1 innan de själva fått svar från sina neighbors R4-7.

query3

Detta är ju ett relativt litet nät, men det är ganska lätt att inse hur långsamt och ineffektivt detta är när vi börjar prata om riktigt stora nät. Även om R1 skulle få tillbaka ett svar från en neighbor om en tillgänglig route till just 10.0.0.0/24 så kommer den EJ att använda denna innan den fått svar från samtliga neighbors den skickat query till.

Vad händer då om R1 inte får svar på en Query? Låt os säga att länken mellan R3 & R7 är rejält överbelastad för stunden och har därför kraftig packetloss. Låt oss säga att Query-paketet som skickades från R3 försvinner på vägen och R7 känner därför inte till att både R1 & R3 sitter och väntar på att den skall svara. Detta fel kallas “Stuck-in-active“.

Stuck-in-Active

Då EIGRP använder sig av RTP förväntar den sig alltid respons på Query-paket inom 3 minuter (går att justera med kommandot “timers active” under router eigrp x. Får den inget svar under den tiden kommer den döda sin neighbor-adjacency med den specifika routern, detta leder ju i sin tur till att den tappar alla routes den lärt sig från den specifika router och kommer på så vis behöva skicka ytterligare Querys ut på nätverket, inte helt optimalt! Om vi tar nedanstående topologi som exempel så kan vi följa vad som händer:

sia

  1. R1 tappar sin länk och saknar feasible successor
  2. R1 skickar en Query ang den specifika routen till R2
  3. R2 har ingen information om routern och skickar därför en Query vidare till R3
  4. R3 har ingen info och har inte heller någon annan neighbor, den skickar därför ett svar tillbaka till R2 med att den ej känner till nätet
  5. R2 skickar sitt Reply-paket till R1, men pga exempelvis dålig radiolänk tappas detta paket
  6. Efter 3 minuter kommer R1 döda sin neighbor adjacency med R2 inkluderat alla routes den lärt sig från just R2

I senare versioner av Cisco’s IOS (>12.1) så infördes två nya paket, SIA query & SIA reply. Om R1 i detta fall inte fått något svar på sitt Query-paket efter 1½ minut kommer den skicka en SIA Query till R2 och fråga vad som händer, R2 svarar med en SIA reply och neighbor adjacencys behålls uppe.

Stubzone & Summary-routes

Hur kommer vi då till rätta med det här problemet med att Query-paket fullständigt svämmar över nätverket när en route går ner? Det finns två alternativ, och det absolut enklaste är via summary-routes. När du skapar en summary-route installerades denna i routing-table och pekar till Null0. Låt oss bygga upp följande topologi och kolla hur det ser ut i respektive router (skippade dock R5 + R6).

query1

Såhär ser routing-table ut för R7:

Gateway of last resort is not set
172.16.0.0/30 is subnetted, 4 subnets
D 172.16.0.4 [90/358400] via 172.16.1.5, 00:07:49, FastEthernet0/1
C 172.16.1.4 is directly connected, FastEthernet0/1
D 172.16.0.0 [90/332800] via 172.16.1.5, 00:07:49, FastEthernet0/1
D 172.16.1.0 [90/307200] via 172.16.1.5, 00:07:49, FastEthernet0/1
 10.0.0.0/24 is subnetted, 1 subnets
D 10.0.0.0 [90/309760] via 172.16.1.5, 00:01:02, FastEthernet0/1

Om vi nu stänger ner länken till 10.0.0.0/24 kommer vi se följande om vi kör debug eigrp packets query update reply på R7:

*Mar 1 00:10:44.107: EIGRP: Received QUERY on FastEthernet0/1 nbr 172.16.1.5
*Mar 1 00:10:44.111: AS 10, Flags 0x0, Seq 16/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
*Mar 1 00:10:44.123: EIGRP: Enqueueing REPLY on FastEthernet0/1 nbr 172.16.1.5 iidbQ un/rely 0/1 peerQ un/rely 0/0 serno 6-6
*Mar 1 00:10:44.131: EIGRP: Sending REPLY on FastEthernet0/1 nbr 172.16.1.5
*Mar 1 00:10:44.135: AS 10, Flags 0x0, Seq 6/16 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 6-6

 

Kollar vi i Wireshark ser Query-paketet ur såhär:

r7 query

R3 skickar ett multicast till 224.0.0.10 för att annonsera att den inte längre kan nå nätet. R7 svarar först med ett Ack och sedan med ett Reply-paket som ser mer eller mindre identiskt ut:

r7 reply

Skillnaden är egentligen att R7 skickar sitt svar till R3 (obs! ej direkt till R1) som ett unicast men anger också att nätet är unreachable.

Kollar vi sedan på R1 ser vi att vi får svar från både R2 & R3.

*Mar 1 00:51:09.835: EIGRP: Received REPLY on FastEthernet0/1 nbr 172.16.1.2
*Mar 1 00:51:09.839: AS 10, Flags 0x0, Seq 27/41 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
*Mar 1 00:51:09.843: EIGRP: Received REPLY on FastEthernet0/0 nbr 172.16.0.2
*Mar 1 00:51:09.847: AS 10, Flags 0x0, Seq 44/42 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0

Summary-route

Genom att använda oss av en summary-route för 10.0.0.0/24 så kommer R1’s neighbors fortfarande ha kännedom om nätet trots att R1 inte längre når det, detta är extremt användbart i riktigt stora nät då vi inte längre behöver skicka query’s mellan varenda router i nätverket, R1’s neighbors kan istället svara direkt med ett “Nej” på frågan om de har någon route till det önskade nätet och behöver inte skicka vidare till sina neighbors, som skickar vidare till sina neighbors osv… De vet ju om att R1 har detta nät!

Vi konfigurerar följande summary-route på R1’s interface mot R2 & R3:

ip summary-address eigrp 10 10.0.0.0 255.255.252.0 5

Kollar vi routing table på R1 & R7 ser det nu ut såhär:

R1

172.16.0.0/30 is subnetted, 4 subnets
D 172.16.0.4 [90/307200] via 172.16.0.2, 00:15:00, FastEthernet0/0
D 172.16.1.4 [90/307200] via 172.16.1.2, 00:15:00, FastEthernet0/1
C 172.16.0.0 is directly connected, FastEthernet0/0
C 172.16.1.0 is directly connected, FastEthernet0/1
 10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
D 10.0.0.0/24 [90/156160] via 192.168.0.2, 00:00:04, FastEthernet1/0
D 10.0.0.0/22 is a summary, 00:04:14, Null0
D 10.0.1.0/24 [90/156160] via 192.168.0.2, 00:03:09, FastEthernet1/0

R7

Gateway of last resort is not set
172.16.0.0/30 is subnetted, 4 subnets
D 172.16.0.4 [90/358400] via 172.16.1.5, 00:31:45, FastEthernet0/1
C 172.16.1.4 is directly connected, FastEthernet0/1
D 172.16.0.0 [90/332800] via 172.16.1.5, 00:31:45, FastEthernet0/1
D 172.16.1.0 [90/307200] via 172.16.1.5, 00:31:45, FastEthernet0/1
 10.0.0.0/22 is subnetted, 1 subnets
D 10.0.0.0 [90/437760] via 172.16.1.5, 00:01:59, FastEthernet0/1

Om vi nu återigen stänger ner länken till 10.0.0.0/24, vad händer?

R3 får Query-paketet precis som vanligt:

*Mar 1 01:17:49.879: EIGRP: Received QUERY on FastEthernet0/0 nbr 172.16.1.1
*Mar 1 01:17:49.883: AS 10, Flags 0x0, Seq 95/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
*Mar 1 01:17:49.895: EIGRP: Enqueueing REPLY on FastEthernet0/0 nbr 172.16.1.1 iidbQ un/rely 0/1 peerQ un/rely 0/0 serno 40-40
*Mar 1 01:17:49.903: EIGRP: Sending REPLY on FastEthernet0/0 nbr 172.16.1.1
*Mar 1 01:17:49.903: AS 10, Flags 0x0, Seq 63/95 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 40-40

Men det stannar där! R7 får aldrig något query-paket av R3. Om vi haft ytterligare 20-30 routrar efter R3 så har vi nu sparat in oerhört många onödiga query/reply-sändningar och minskar även risken för “Stuck in Active“.

Kollar vi routing-tabellen för R7 igen så har det inte skett någon förändring:

172.16.0.0/30 is subnetted, 4 subnets
D 172.16.0.4 [90/358400] via 172.16.1.5, 00:55:49, FastEthernet0/1
C 172.16.1.4 is directly connected, FastEthernet0/1
D 172.16.0.0 [90/332800] via 172.16.1.5, 00:55:49, FastEthernet0/1
D 172.16.1.0 [90/307200] via 172.16.1.5, 00:55:49, FastEthernet0/1
 10.0.0.0/22 is subnetted, 1 subnets
D 10.0.0.0 [90/437760] via 172.16.1.5, 00:18:52, FastEthernet0/1

Men vad händer om vi pingar en adress i 10.0.0.0/24-nätet nu då? Om vi kör en debug ip packet som pekar på en ACL jag konfat i R1 och pingar från R7:

R7#ping 10.0.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)

Observera att vi får Unreachable, inte timeout!

Kollar vi i R1 kan vi se följande:

R1#
*Mar 1 01:31:00.271: IP: tableid=0, s=172.16.1.6 (FastEthernet0/1), d=10.0.0.1 (Null0), routed via RIB
*Mar 1 01:31:02.331: IP: tableid=0, s=172.16.1.6 (FastEthernet0/1), d=10.0.0.1 (Null0), routed via RIB
*Mar 1 01:31:04.367: IP: tableid=0, s=172.16.1.6 (FastEthernet0/1), d=10.0.0.1 (Null0), routed via RIB

Paketen skickas ut på Null0-interfacet (blackhole), paketet skulle ju annars skickas vidare till default-gateway och med all sannolikhet orsaka en routingloop.

Stubzone

Ibland är det inte alltid möjligt att använda sig av summary-routes, vi skulle då istället kunna använda oss av en så kallad Stubzone. Detta anger vi på routrar som inte har någon annan väg “ut” från sina lokala nät, exempelvis branchoffice-routrar. Om vi går tillbaka till den topologi vi precis använt skulle vi här kunna ange R4, R5, R6 & R7 som stubzone. Stubzone-routrar får INGA Query-paket!

query1

Stubzone har flera inställningsmöjligheter som även går att kombinera (förutom Recieve-only som endast går att köra “solo”):

  • Recieve-only: Stubroutern kommer inte att annonsera något nät över huvudtaget (men kommer fortfarande lyssna på updates från andra routrar, ungefär som passive-interface för RIP)
  • Connected: Stubroutern kommer endast annonsera Directly Connected-nät
  • Static: Stubroutern kommer endast annonsera statiska route (kräver att du redistributar dessa in till eigrp först)
  • Summary: Stubroutern kommer endast annonsera summary-routes
  • Redistribute: Stubroutern kommer endast annonsera redistribute-routes

Per default är det Connected och Summary som tillåts annonseras.

Vi tar och testar detta!

Jag har tagit bort summary-routen från topologin, så när 10.0.0.0/24-nätet går ner får vi återigen query-paket till R7 från R3 . Jag har även lagt till 4st Loopback-nät inklusive en summary-route (/16) för att ha något att laborera med i R7, såhär ser routing table ut:

1.0.0.0/24 is subnetted, 4 subnets
C 1.1.0.0 is directly connected, Loopback3
C 1.1.1.0 is directly connected, Loopback0
C 1.1.2.0 is directly connected, Loopback1
C 1.1.3.0 is directly connected, Loopback2
 172.16.0.0/30 is subnetted, 4 subnets
D 172.16.0.4 [90/358400] via 172.16.1.5, 01:15:20, FastEthernet0/1
C 172.16.1.4 is directly connected, FastEthernet0/1
D 172.16.0.0 [90/332800] via 172.16.1.5, 01:15:20, FastEthernet0/1
D 172.16.1.0 [90/307200] via 172.16.1.5, 01:15:21, FastEthernet0/1
 10.0.0.0/24 is subnetted, 2 subnets
D 10.0.0.0 [90/437760] via 172.16.1.5, 00:00:08, FastEthernet0/1
D 10.0.1.0 [90/437760] via 172.16.1.5, 00:00:32, FastEthernet0/1

Och dessa routes kan R3 se utan problem:

1.0.0.0/16 is subnetted, 1 subnets
D 1.1.0.0 [90/409600] via 172.16.1.6, 00:00:08, FastEthernet0/1
 172.16.0.0/30 is subnetted, 4 subnets
D 172.16.0.4 [90/332800] via 172.16.1.1, 01:24:14, FastEthernet0/0
C 172.16.1.4 is directly connected, FastEthernet0/1
D 172.16.0.0 [90/307200] via 172.16.1.1, 01:52:11, FastEthernet0/0
C 172.16.1.0 is directly connected, FastEthernet0/0
 10.0.0.0/24 is subnetted, 2 subnets
D 10.0.0.0 [90/412160] via 172.16.1.1, 00:07:03, FastEthernet0/0
D 10.0.1.0 [90/412160] via 172.16.1.1, 00:07:28, FastEthernet0/0

Om vi nu konfigurerar R7 till stub connected, vad händer?

Summary-routen försvinner från R3 (R7 får endast annonsera sina connected-nät):

1.0.0.0/24 is subnetted, 4 subnets
D 1.1.0.0 [90/409600] via 172.16.1.6, 00:00:08, FastEthernet0/1
D 1.1.1.0 [90/409600] via 172.16.1.6, 00:00:08, FastEthernet0/1
D 1.1.2.0 [90/409600] via 172.16.1.6, 00:00:08, FastEthernet0/1
D 1.1.3.0 [90/409600] via 172.16.1.6, 00:00:08, FastEthernet0/1
 172.16.0.0/30 is subnetted, 4 subnets
D 172.16.0.4 [90/332800] via 172.16.1.1, 01:27:11, FastEthernet0/0
C 172.16.1.4 is directly connected, FastEthernet0/1
D 172.16.0.0 [90/307200] via 172.16.1.1, 01:55:09, FastEthernet0/0
C 172.16.1.0 is directly connected, FastEthernet0/0
 10.0.0.0/24 is subnetted, 2 subnets
D 10.0.0.0 [90/412160] via 172.16.1.1, 00:10:02, FastEthernet0/0
D 10.0.1.0 [90/412160] via 172.16.1.1, 00:10:26, FastEthernet0/0

Om vi byter till stub recieve-only?

172.16.0.0/30 is subnetted, 4 subnets
D 172.16.0.4 [90/332800] via 172.16.1.1, 01:29:44, FastEthernet0/0
C 172.16.1.4 is directly connected, FastEthernet0/1
D 172.16.0.0 [90/307200] via 172.16.1.1, 01:57:41, FastEthernet0/0
C 172.16.1.0 is directly connected, FastEthernet0/0
 10.0.0.0/24 is subnetted, 2 subnets
D 10.0.0.0 [90/412160] via 172.16.1.1, 00:12:33, FastEthernet0/0
D 10.0.1.0 [90/412160] via 172.16.1.1, 00:12:57, FastEthernet0/0

R3 kan nu inte längre se 1.1.0.0-1.1.3.0 näten.

Vi återgår till stub connected summary och tar istället och testar vad som händer när 10.0.0.0/24-nätet går ner.

Från R3 (fa0/0 går till R1 och fa0/1 går till R7):

*Mar 1 02:10:48.147: EIGRP: Received QUERY on FastEthernet0/0 nbr 172.16.1.1
*Mar 1 02:10:48.147: AS 10, Flags 0x0, Seq 189/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
*Mar 1 02:10:48.163: EIGRP: Enqueueing REPLY on FastEthernet0/0 nbr 172.16.1.1 iidbQ un/rely 0/1 peerQ un/rely 0/0 serno 95-95
*Mar 1 02:10:48.167: EIGRP: Enqueueing UPDATE on FastEthernet0/1 iidbQ un/rely 0/1 serno 96-96
*Mar 1 02:10:48.167: EIGRP: Enqueueing UPDATE on FastEthernet0/1 nbr 172.16.1.6 iidbQ un/rely 0/0 peerQ un/rely 0/0 serno 96-96
*Mar 1 02:10:48.171: EIGRP: Sending UPDATE on FastEthernet0/1
*Mar 1 02:10:48.171: AS 10, Flags 0x0, Seq 138/0 idbQ 0/0 iidbQ un/rely 0/0 serno 96-96
*Mar 1 02:10:48.175: EIGRP: Sending REPLY on FastEthernet0/0 nbr 172.16.1.1
*Mar 1 02:10:48.175: AS 10, Flags 0x0, Seq 137/189 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 95-95
*Mar 1 02:10:48.319: EIGRP: Received QUERY on FastEthernet0/1 nbr 172.16.1.6
*Mar 1 02:10:48.319: AS 10, Flags 0x0, Seq 60/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
*Mar 1 02:10:48.331: EIGRP: Enqueueing UPDATE on FastEthernet0/0 iidbQ un/rely 0/1 serno 96-97
*Mar 1 02:10:48.331: EIGRP: Enqueueing REPLY on FastEthernet0/1 nbr 172.16.1.6 iidbQ un/rely 0/1 peerQ un/rely 0/0 serno 97-97
*Mar 1 02:10:48.335: EIGRP: Enqueueing UPDATE on FastEthernet0/0 nbr 172.16.1.1 iidbQ un/rely 0/0 peerQ un/rely 0/0 serno 96-97
*Mar 1 02:10:48.339: EIGRP: Sending UPDATE on FastEthernet0/0
*Mar 1 02:10:48.339: AS 10, Flags 0x0, Seq 139/0 idbQ 0/0 iidbQ un/rely 0/0 serno 96-97
*Mar 1 02:10:48.347: EIGRP: Sending REPLY on FastEthernet0/1 nbr 172.16.1.6
*Mar 1 02:10:48.347: AS 10, Flags 0x0, Seq 140/60 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 97-97

Detta hade jag inte alls förväntat mig! Observera dock att R3 inte längre skickar någon Query till R7, däremot en Update  att 10.0.0.0/24 inte längre är nåbart, se följande wireshark-bild:

stubreply

Inget konstigt där egentligen, men det märkliga är det som händer efteråt!

R7 skickar en Query till R3 och frågar efter en route till 10.0.0.0/24 (!?).

stubquery

 

Detta tyckte jag var väldigt märkligt, så egentligen har vi ju inte minskat antal Query-paket, skillnaden är att det nu är R7 som skickar det till R3 istället för tvärtom (och att R3 måste först skicka ett Update-paket till R7). Detta känns ju som att det bara bidrar till mer overhead? Ska ta och forska vidare lite men detta inlägg har blivit alldeles för långt så tar och avslutar det här med denna “cliffhanger” hehe. På återseende!

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.