TSHOOT – Part II, Frame-Relay, IPv6 & OSPF

18 september, 2013 Jonas CollénCCNP

tshoot-ospf

Frame-Relay är min överlägset svagaste sida så det här är verkligen välkommen repetition. Innan vi börjar med OSPF etc så lär vi först fixa basic L2-connectivity.

Frame-Relay IPv4

R1(config)#interface s1/0
 R1(config-if)#encapsulation frame-relay
 R1(config-if)#no shut
 R1(config-if)#
 R1(config-if)#interface s1/0.12 point-to-point
 R1(config-subif)#ip add 10.1.1.1 255.255.255.252
 R1(config-subif)#frame-relay interface-dlci 102
 R1(config-fr-dlci)#desc to R2

R2(config)#interface s1/0
 R2(config-if)#encapsulation frame-relay
 R2(config-if)#no shut
 R2(config-if)#
 R2(config-if)#interface serial 1/0.21 point-to-point
 R2(config-subif)#ip add 10.1.1.2 255.255.255.252
 R2(config-subif)#desc to R1
 R2(config-subif)#frame-relay interface-dlci 201
 R2(config-fr-dlci)#
 R2(config-fr-dlci)#interface serial 1/0.23 point-to-point
 R2(config-subif)#ip add 10.1.1.5 255.255.255.252
 R2(config-subif)#desc to R3
 R2(config-subif)#frame-relay interface-dlci 203
 R2(config-fr-dlci)#end

R3(config)#interface s1/0
 R3(config-if)#encapsulation frame-relay
 R3(config-if)#no shut
 R3(config-if)#
 R3(config-if)#interface serial 1/0.32 point-to-point
 R3(config-subif)#ip add 10.1.1.6 255.255.255.252
 R3(config-subif)#frame-relay interface-dlci 302
 R3(config-fr-dlci)#
 R3(config-fr-dlci)#interface serial 1/0.34 point-to-point
 R3(config-subif)#ip add 10.1.1.9 255.255.255.252
 R3(config-subif)#frame-relay interface-dlci 304
 R3(config-fr-dlci)#

R4(config)#interface s1/0
 R4(config-if)#encapsulation frame-relay
 R4(config-if)#no shut
 R4(config-if)#
 R4(config-if)#interface serial 1/0.43 point-to-point
 R4(config-subif)#ip add 10.1.1.10 255.255.255.252
 R4(config-subif)#desc to R3
 R4(config-subif)#frame-relay interface-dlci 403

Frame-Relay IPv6

R1(config)#ipv6 unicast-routing
 R1(config)#int s1/0.12 point-to-point
 R1(config-subif)#ipv6 add 2026::12:1/122

R2(config)#ipv6 unicast-routing
 R2(config)#interface s1/0.21 point-to-point
 R2(config-subif)#ipv6 add 2026::12:2/122
R2(config-subif)#interface s1/0.23 point-to-point
 R2(config-subif)#ipv6 add 2026::1:1/122
 R2(config-subif)#end

R3(config)#ipv6 unicast-routing
 R3(config)#interface s1/0.32 point-to-point
 R3(config-subif)#ipv6 add 2026::1:2/122
 R3(config-subif)#end

Mellan R3 & R4 ska vi enligt skissen istället ha en GRE-tunnel. Se tidigare inlägg här för mer info om hur vi sätter upp statiska/6to4/ISATAP-IPv6 tunnlar.

R3(config)#interface Tunnel0
 R3(config-if)#ipv6 address 2026::34:1/122
 R3(config-if)#tunnel source s1/0.34
 R3(config-if)#tunnel destination 10.1.1.10
 R3(config-if)#tunnel mode ipv6ip

R4(config)#ipv6 unicast-routing
 R4(config)#interface Tunnel0
 R4(config-if)#ipv6 address 2026::34:2/122
 R4(config-if)#tunnel source s1/0.43
 R4(config-if)#tunnel destination 10.1.1.9
 R4(config-if)#tunnel mode ipv6ip

OSPFv2

Inget avancerat här direkt, glöm bara inte att annonsera default-routen från R1 till övriga (default-information originate).

R1(config)#router ospf 1
 R1(config-router)#router-id 1.1.1.1
 R1(config-router)#network 10.1.1.0 0.0.0.3 area 12
 R1(config-router)#default-information originate

R2(config)#router ospf 1
 R2(config-router)#router-id 2.2.2.2
 R2(config-router)#network 10.1.1.0 0.0.0.3 area 12
 R2(config-router)#network 10.1.1.4 0.0.0.3 area 0

R3 – Kom ihåg “Totally Not-so-stubby” för area 34!

R3(config)#router ospf 1
 R3(config-router)#router-id 3.3.3.3
 R3(config-router)#network 10.1.1.4 0.0.0.3 area 0
 R3(config-router)#network 10.1.1.8 0.0.0.3 area 34
 R3(config-router)#area 34 nssa no-summary

R4(config)#router ospf 1
 R4(config-router)#router-id 4.4.4.4
 R4(config-router)#network 10.1.1.8 0.0.0.3 area 34
 R4(config-router)#area 34 nssa

OSPFv3

R1(config-rtr)#interface Serial1/0.12 point-to-point
R1(config-subif)# ipv6 ospf 6 area 12

R2(config)#interface Serial1/0.21 point-to-point
R2(config-subif)# ipv6 ospf 6 area 12
R2(config-subif)#interface Serial1/0.23 point-to-point
R2(config-subif)# ipv6 ospf 6 area 0

R3(config)#ipv6 router ospf 6
R3(config-rtr)#area 34 nssa no-summary
R3(config-rtr)#exit
R3(config)#interface Serial1/0.32 point-to-point
R3(config-subif)#ipv6 ospf 6 area 0
R3(config)#interface Tunnel0
R3(config-if)# ipv6 ospf 6 area 34

R4(config)#ipv6 router ospf 6
 R4(config-rtr)#area 34 nssa
 R4(config-rtr)#exit
 R4(config)#interface Tunnel0
 R4(config-if)# ipv6 ospf 6 area 34

Verifiering

En hel del adresser att testa så enklast är att göra ett TCL-script istället.

R1#tclsh
 R1(tcl)#tclsh
R1(tcl)#foreach address {
 +>(tcl)#209.65.200.241
 +>(tcl)#209.65.200.242
 +>(tcl)#209.65.200.226
 +>(tcl)#209.65.200.225
 +>(tcl)#10.1.1.1
 +>(tcl)#10.1.1.2
 +>(tcl)#10.1.1.5
 +>(tcl)#10.1.1.6
 +>(tcl)#10.1.1.9
 +>(tcl)#10.1.1.10
 +>(tcl)#2026::12:1
 +>(tcl)#2026::12:2
 +>(tcl)#2026::1:1
 +>(tcl)#2026::1:2
 +>(tcl)#2026::34:1
 +>(tcl)#2026::34:2
 +>(tcl)#} { ping $address re 3 }
 Translating "209.65.200.241"
Type escape sequence to abort.
 Sending 3, 100-byte ICMP Echos to 209.65.200.241, timeout is 2 seconds:
 ..!
 Success rate is 33 percent (1/3), round-trip min/avg/max = 136/136/136 ms
 Translating "209.65.200.242"
Type escape sequence to abort.
 Sending 3, 100-byte ICMP Echos to 209.65.200.242, timeout is 2 seconds:
 !!!
 Success rate is 100 percent (3/3), round-trip min/avg/max = 16/34/60 ms
 Translating "209.65.200.226"
Type escape sequence to abort.
 Sending 3, 100-byte ICMP Echos to 209.65.200.226, timeout is 2 seconds:
 !!!
 Success rate is 100 percent (3/3), round-trip min/avg/max = 20/32/44 ms
 Translating "209.65.200.225"
Type escape sequence to abort.
 Sending 3, 100-byte ICMP Echos to 209.65.200.225, timeout is 2 seconds:
 ...
 Success rate is 0 percent (0/3)
 Translating "10.1.1.1"
Type escape sequence to abort.
 Sending 3, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:
 !!!
 Success rate is 100 percent (3/3), round-trip min/avg/max = 28/58/76 ms
 Translating "10.1.1.2"
Type escape sequence to abort.
 Sending 3, 100-byte ICMP Echos to 10.1.1.2, timeout is 2 seconds:
 !!!
 Success rate is 100 percent (3/3), round-trip min/avg/max = 28/34/48 ms
 Translating "10.1.1.5"
Type escape sequence to abort.
 Sending 3, 100-byte ICMP Echos to 10.1.1.5, timeout is 2 seconds:
 !!!
 Success rate is 100 percent (3/3), round-trip min/avg/max = 8/38/76 ms
 Translating "10.1.1.6"
Type escape sequence to abort.
 Sending 3, 100-byte ICMP Echos to 10.1.1.6, timeout is 2 seconds:
 !!!
 Success rate is 100 percent (3/3), round-trip min/avg/max = 60/89/112 ms
 Translating "10.1.1.9"
Type escape sequence to abort.
 Sending 3, 100-byte ICMP Echos to 10.1.1.9, timeout is 2 seconds:
 !!!
 Success rate is 100 percent (3/3), round-trip min/avg/max = 36/64/92 ms
 Translating "10.1.1.10"
Type escape sequence to abort.
 Sending 3, 100-byte ICMP Echos to 10.1.1.10, timeout is 2 seconds:
 !!!
 Success rate is 100 percent (3/3), round-trip min/avg/max = 92/118/152 ms
 Type escape sequence to abort.
 Sending 3, 100-byte ICMP Echos to 2026::12:1, timeout is 2 seconds:
 !!!
 Success rate is 100 percent (3/3), round-trip min/avg/max = 0/1/4 ms
 Type escape sequence to abort.
 Sending 3, 100-byte ICMP Echos to 2026::12:2, timeout is 2 seconds:
 !!!
 Success rate is 100 percent (3/3), round-trip min/avg/max = 8/46/84 ms
 Type escape sequence to abort.
 Sending 3, 100-byte ICMP Echos to 2026::1:1, timeout is 2 seconds:
 !!!
 Success rate is 100 percent (3/3), round-trip min/avg/max = 16/25/36 ms
 Type escape sequence to abort.
 Sending 3, 100-byte ICMP Echos to 2026::1:2, timeout is 2 seconds:
 !!!
 Success rate is 100 percent (3/3), round-trip min/avg/max = 44/70/88 ms
 Type escape sequence to abort.
 Sending 3, 100-byte ICMP Echos to 2026::34:1, timeout is 2 seconds:
 !!!
 Success rate is 100 percent (3/3), round-trip min/avg/max = 24/52/68 ms
 Type escape sequence to abort.
 Sending 3, 100-byte ICMP Echos to 2026::34:2, timeout is 2 seconds:
 !!!
 Success rate is 100 percent (3/3), round-trip min/avg/max = 84/112/160 ms
 R1(tcl)#tclquit
 R1#ping 2026::34:2
Type escape sequence to abort.
 Sending 5, 100-byte ICMP Echos to 2026::34:2, timeout is 2 seconds:
 !!!!!
 Success rate is 100 percent (5/5), round-trip min/avg/max = 36/100/160 ms
 R1#ping ipv6 2026::34:2
Type escape sequence to abort.
 Sending 5, 100-byte ICMP Echos to 2026::34:2, timeout is 2 seconds:
 !!!!!
 Success rate is 100 percent (5/5), round-trip min/avg/max = 60/80/104 ms
 R1#ping 2026::34:1
Type escape sequence to abort.
 Sending 5, 100-byte ICMP Echos to 2026::34:1, timeout is 2 seconds:
 !!!!!
 Success rate is 100 percent (5/5), round-trip min/avg/max = 40/56/76 ms

OSPF – Network Types

15 juni, 2013 Jonas CollénCCNP

Fortsättning på tidigare inlägg om DR & BDR.

OSPF har ett flertal olika “Network Types” specificerade, och det är utefter detta som ospf-processen bestämmer om den behöver välja en DR/BDR under 2-way state i skapandet av en Neighbor Adjacency. Dessa är:

Non-Broadcast (NMBA)
Point-To-Multipoint
Point-To-Multipoint Non-Broadcast
Broadcast
Point-To-Point

Kom ihåg att DR/BDR endast behövs för multiaccess-nät. Detta innebär att för Point-to-Point så skippas hela DR/BDR-processen över och full adjacency sätts upp. Skillnaden går att se genom “sh ip ospf neighbor” där vi har en Point-to-Point länk på Fa0/1 och ett vanligt multiaccess (ethernet) på fa0/0.

Neighbor ID Pri State Dead Time Address Interface
2.2.2.2 1 FULL/DR 00:00:34 10.0.0.2 FastEthernet0/0
3.3.3.3 1 FULL/DROTHER 00:00:30 10.0.0.3 FastEthernet0/0
192.168.0.2 0 FULL/ – 00:00:33 192.168.0.2 FastEthernet0/1*

*Detta exempel är kanske lite förvirrande, per default är det alltid broadcast som network-type för Ethernetinterface, men för detta exempel ändrade jag detta genom “ip ospf network point-to-point”.

Samma sak gäller för Point-to-Multipoint & PtM Non-Broadcast räknas OSPF som flera inviduella Point-to-Point och väljer därför EJ någon DR/BDR.

Så vi kan konstatera att DR/BDR används endast för Broadcast & Non-Broadcast (NMBA – Non-Broadcast MultiAccess).

Skönt nog har Cisco gjort det enkelt för oss och dessa nätverkstyper konfigureras automatiskt åt oss. Vi kan kontrollera vilken network type ett interface har genom kommandot “sh ip ospf interface“:

Ethernet:

FastEthernet0/0 is up, line protocol is up
 Internet Address 10.0.0.1/24, Area 0
 Process ID 1, Router ID 1.1.1.1, Network Type BROADCAST, Cost: 10

Point-to-Point:

Serial0/0 is up, line protocol is up 
 Internet Address 192.168.0.2/30, Area 1 
 Process ID 1, Router ID 192.168.0.2, Network Type POINT_TO_POINT, Cost: 10

Point-to-MultiPoint

Serial0/0.1 is up, line protocol is up 
 Internet Address 172.16.0.1/16, Area 1 
 Process ID 1, Router ID 192.168.0.2, Network Type POINT_TO_MULTIPOINT, Cost: 64

Non-Broadcast:

Serial0/0 is up, line protocol is up
Internet Address 172.16.0.1/16, Area 1 
 Process ID 1, Router ID 192.168.0.2, Network Type NON_BROADCAST, Cost: 64

Det finns som tidigare nämnt möjlighet att manuellt justera vilken network-type ett interface skall ha, detta kan vara användbart i framförallt labb-miljöer. Du ändrar detta via kommandot “ip ospf network x“,

R4(config-if)#ip ospf network ?
 broadcast Specify OSPF broadcast multi-access network
 non-broadcast Specify OSPF NBMA network
 point-to-multipoint Specify OSPF point-to-multipoint network
 point-to-point Specify OSPF point-to-point network

DR/BDR i Frame-Relay

Ett problem som uppstår i en Frame-Relay miljö som använder sig av Hub & Spoke är som bekant att all trafik mellan “spokes” måste gå via huvudroutern. Och som du förhoppningsvis inte sovit under dina CCNA-studier känner du redan till att routrar ej forwardar Broadcast – detta innefattar även Multicast. Om vi tar följande topologi för att utveckla:

Vad händer om Spoke 1 skulle bli DR eller BDR? Spoke2 kommer försöka sätta upp en full adjacency till Spoke1, vilket kommer misslyckas då all multicast fastnar i Hub och ej forwardas.

Det är därför ett KRAV att Hub konfigureras till DR och att vi EJ tillåter varken Spoke1 eller Spoke2 att bli BDR, detta gäller för både Broadcast*- & NMBA i Hub&Spoke-nät. Har du läst den tidigare posten ang. BD/BDR så har du förhoppningsvis redan koll på hur vi löser detta (hint: genom ip ospf priority x).

*Kom ihåg att vi kan konfigurera Frame-Relay att tillåta en form av pseudo-broadcast genom antingen Inverse-ARP eller manuellt mappa dlci och ip-adress och sedan använda broadcast i statement, ex;

R1(config)#interface serial0 
R1(config-if)#no frame-relay inverse-arp 
R1(config-if)#frame map ip 200.1.1.2 122 broadcast 
R1(config-if)#frame map ip 200.1.1.3 123 broadcast

Neighbor adjacencys för Non-broadcast

Speciellt för Non-broadcast och Point-to-Multipoint Non-broadcast är ju som vi hör på namnet att de EJ tillåter broadcast (vilket även innebär att multicast stoppas). OSPF har dock möjlighet att helt använda sig av unicast istället, det enda vi behöver göra i detta fall är att manuellt ange våra neighbors. Väldigt enkelt!

R1(config)#router ospf 1
R1(config-router)#neighbor 10.0.0.2 
R1(config-router)#neighbor 10.0.0.3

Försöker vi dock göra detta på ett nätverk som tillåter broadcast får vi följande meddelande:

*Mar  1 01:43:08.991: %OSPF-4-CFG_NBR_INVAL_NET_TYPE: Can not use configured neighbor: neighbor command is allowed only on NBMA and point-to-multipoint networks

Här är förövrigt en bra “fusklapp” att använda.

EIGRP – Frame Relay

10 juni, 2013 Jonas CollénCCNA

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.

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.

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.

Road to .. NetDevOps?

Posting nerdy stuff about networking since 2013

Etikett: Frame Relay