IPv6 – HSRP

Hot Standby Routing Protocol är ett Cisco proprietärt protokoll som erbjuder redundans genom användandet av en virtuell ip-adress som delas mellan routrar för att sedan användas som default-gateway. Denna video förklarar grunderna väldigt bra:

https://www.youtube.com/watch?v=kxhdPI1jh6I

Detta är dock som synes för IPv4, så funktionaliteten skiljer lite när vi använder oss av IPv6 istället. Något som jag själv inte kände till var att IPv6 faktiskt har en light-version av detta inbyggt i protokollet, och genom att modifiera timers för Router Advertisements & Neighbor Discoverys kan få “fail-over” tiden under 1 sekund. Packetlife.net har en väldigt läsvärd post om just detta här.

ipv6-hsrp

Vår host kommer ha sin default-gateway konfigurerad till FE80:CC1E:1, men innan den kan skicka paketen dit behöver den först ta reda på Lager 2-adressen (MAC). Då vi inte har ARP-requests i IPv6 skickas istället en “Neighbor Solicitation” över multicast till den L2-adress hosten TROR att FE80:CC1E;:1 har. Vi tog upp allt detta i en tidigare post om just Neighbor Solicitation här om du behöver friska upp minnet lite.

När vi konfigurerat upp HSRP kommer den aktiva routern att gå med i multicast-gruppen som relaterar till den virtuella adress vi konfigurerat. Den aktiva routern kommer då svara hosten med en tillhörande virtuell mac-adress (deriverad från HSRPs grupp-nummer).

Innan vi konfigurerat mer än grundkonfigen från ovanstående topologi så visar en show ipv6 int fa0/0 på R2 (mot SW1) följande:

FastEthernet0/0 is up, line protocol is up
 IPv6 is enabled, link-local address is FE80::2
 No Virtual link-local address(es):
 No global unicast address is configured
 Joined group address(es):
  FF02::1 <- all nodes
  FF02::2 <- all routers
  FF02::1:FF00:2 <- solicited-node

Hur konfar vi då upp HSRP? Enkelt! Vi gör det direkt på interfacet.

R2(config)#inte fa0/0
 R2(config-if)#standby ?
 <0-4095> group number
 authentication Authentication
 bfd Enable HSRP BFD
 delay HSRP initialisation delay
 follow Name of HSRP group to follow
 ip Enable HSRP IPv4 and set the virtual IP address
 ipv6 Enable HSRP IPv6
 mac-address Virtual MAC address
 mac-refresh Refresh MAC cache on switch by periodically sending packet
 from virtual mac address
 name Redundancy name string
 preempt Overthrow lower priority Active routers
 priority Priority level
 redirect Configure sending of ICMP Redirect messages with an HSRP
 virtual IP address as the gateway IP address
 timers Hello and hold timers
 track Priority tracking
 use-bia HSRP uses interface's burned in address
 version HSRP version

Vi har en hel del valmöjligheter för finjustering som synes, men för att få upp en enkel HSRP-session mellan R1 & R2 behövs endast följande:

R1

interface FastEthernet0/0
 standby version 2
 standby 1 ipv6 FE80:ccie::1
 standby 1 priority 101
 standby 1 preempt
*Mar  1 02:20:04.447: %HSRP-5-STATECHANGE: FastEthernet0/0 Grp 1 state Standby -> Active

R2

interface FastEthernet0/0
 standby version 2
 standby 1 ipv6 FE80:ccie::1
 standby 1 priority 99
 standby 1 preempt
*Mar  1 02:28:31.107: %HSRP-5-STATECHANGE: FastEthernet0/0 Grp 1 state Speak -> Standby

För att kunna använda HSRP tillsammans med IPv6 krävs det att vi aktiverar version 2 av protokollet (standby version 2). Vi kan även styra vilken router som ska vara aktiv genom att modifiera priority, högst värde vinner (default: 100), i detta fall kommer därför R1 bli aktiv. Om vi inte inkluderar kommandot “preempt” kommer sekundären fortsätta vara aktiv även om den primära routern blir nåbar igen vid ett eventuellt avbrott.

Både R1 & R2 kommer nu börja skicka HSRPv2 Hello-paket till multicast-adressen FF02::66.

R1 skickar dock sitt Hello-paket med state – Active

ipv6-hsrp-hello

R3 markerar istället sitt Hello-paket som state – standby

ipv6-hsrp-hello-standby

Om vi återigen tar en titt på R2s interface kan vi nu se att den gått med i ytterligare två multicast-grupper som förväntat:

R2#sh ipv6 int fa0/0
 FastEthernet0/0 is up, line protocol is up
 IPv6 is enabled, link-local address is FE80::2 [UNA]
 Virtual link-local address(es):
 FE80:CC1E::1 [OOD]
 No global unicast address is configured
 Joined group address(es):
 FF02::1
 FF02::2
 FF02::66 <- HSRP
 FF02::1:FF00:1 <- Solicited-node adress för FE80:CC1E::1
 FF02::1:FF00:2

Och för R3:

R3#sh ipv6 int fa0/0
 FastEthernet0/0 is up, line protocol is up
 IPv6 is enabled, link-local address is FE80::3 [UNA]
 Virtual link-local address(es):
 FE80:CC1E::1 [UNA/OOD/TEN]
 No global unicast address is configured
 Joined group address(es):
 FF02::1
 FF02::2
 FF02::66
 FF02::1:FF00:3

Observera att R3 endast gått med i HSRP-multicastgruppen, bara den aktiva routern går med i solicited-node gruppen (FF02::1:FF00:1)! 

Vi kan verifiera att allt är ok via kommandot show standby:

R2#sh standby 
FastEthernet0/0 - Group 1 (version 2)
 State is Active
 2 state changes, last state change 00:25:37
 Virtual IP address is FE80:CC1E::1
 Active virtual MAC address is 0005.73a0.0001
 Local virtual MAC address is 0005.73a0.0001 (v2 IPv6 default)
 Hello time 3 sec, hold time 10 sec
 Next hello sent in 1.756 secs
 Preemption enabled
 Active router is local
 Standby router is FE80::3, priority 99 (expires in 7.040 sec)
 Priority 101 (configured 101)
 Group name is "hsrp-Fa0/0-1" (default)

Vi sätter nu denna virtuella adress som default-gateway på R1:

R1(config)#ipv6 route ::/0 FastEthernet0/0 FE80:cc1e::1
R1(config)#end
R1#ping ipv6 2001:db8:cc1e:4444::4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:CC1E:4444::4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/56/92 ms

Vi stänger ner R2’s interface via shutdown och ser vad som händer..

R2 skickar ut ett HSRP Resign-paket för att informera om att den är på väg ner:

ipv6-hsrp-resign

R3 ser detta och ändrar state från Standby till Active.

*Mar  1 02:49:30.131: %HSRP-5-STATECHANGE: FastEthernet0/0 Grp 1 state Standby -> Active
R1#ping ipv6 2001:db8:cc1e:4444::4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:CC1E:4444::4, timeout is 2 seconds:
!.!.!
Success rate is 60 percent (3/5), round-trip min/avg/max = 12/32/52 ms

Anledningen till att vi tappar paket är bara för att jag varit lite lat. R4 har två default-routes som pekar mot R2 & R3, så vartannat paket skickas tillbaka till R2 och timar ut.. 😉

När vi återigen aktiverar interfacet på R2 skickas ett HSRP “Coup”-paket innehållande R2’s priority. R3 ser detta och ändrar sin state från Active -> Speak -> Standby, samtidigt som R2 går tillbaka till Active.

ipv6-hsrp-coup
*Mar 1 02:56:18.195: %HSRP-5-STATECHANGE: FastEthernet0/0 Grp 1 state Active -> Speak
*Mar 1 02:56:28.195: %HSRP-5-STATECHANGE: FastEthernet0/0 Grp 1 state Speak -> Standby

Om vi vill ge vår primära router lite tid att få “stabilisera” sig innan vi skickar över stafettpinnen igen kan vi konfigurera en delay-timer via kommandot:

R2(config-if)#standby 1 preempt delay minimum ?
 <0-3600> Number of seconds for minimum delay

Ytterligare en intressant sak är att efter vi aktiverat HSRP på ett interface så slutar routern annonsera sina övriga link-local prefix (FF80::2 / FF80::3) via Router Advertisement.

ipv6-hsrp-linklocal

Men konfigurerar vi istället ytterligare en global adress annonseras det:

R2(config-if)#ipv6 add 2001:db8:cc1e:999::1/64

ipv6-hsrp-globalRA

Det var allt jag hade om HSRP i IPv6, borde väl ta och sätta ihop en post som tar upp lite mer avancerade exempel för IPv4 men det får nog bli lite längre fram i tiden när vi är klara med IPv6.

IPv6 – Link-local Multicast

Då broadcast inte längre används i IPv6 som vi nämnt i tidigare inlägg kan det väl vara lämpligt med en introduktion till multicast.

Rekommenderar ovanstående video till att börja med, förklarar konceptet väldigt bra.

Jag har använt mig av samma topologi för denna labb.

ipv6-simple-topology

Multicast ger oss möjligheten att skicka ett och samma paket till flera mottagare, men tas endast emot av enheter som är intresserade av paketet (genom att de gått med i vår multicast-grupp). Betydligt mer effektivt än broadcast där alla enheter måste processa paketet oavsett om de är intresserade av informationen eller ej.

Multicast adresser börjar som bekant alltid med FF00::/8, men det finns flera olika typer av multicast-trafik/grupper. För Multicast-adresser som börjar med FF02 som vi ska kolla på idag betyder att de är Link-local, dvs de forwardas EJ utanför vårt L2-segment.

  • FF02::1 – All-nodes address, används för att nå alla enheter på L2-segmentet
  • FF02::2 – All-routers address, används för att nå alla routrar på L2-segmentet
  • FF02::5 – All-OSPF routers, används för att nå alla OSPF-routrar L2-segmentet (samma funktion som IPv4s 224.0.0.5)
  • FF02::6 – All-OSPF DR/BDR routers, används för att nå alla OSFP DR/BDR-routrar på L2-segmentet (samma funktion som IPv4s 224.0.0.6)
  • FF02::9 – All-RIPng routers, används för att nå alla RIP-routrar på L2-segmentet
  • FF02::A – All-EIGRP routers, används för att nå alla EIGRP-routrar på L2-segmentet
  • FF02::1::FFxx:xxxx – Solicited-node address, resolvar en Link-local IPv6-adress till Link-Layer address (IPv6s version av ARP!)

Det sistnämnda kräver väl lite mer förklaring.. En IPv6 Unicast-adress är antingen:

  • Global (2000::/3 – 3ffff::/3)
  • Link-Local  (FE80::/8)

För varje IPv6 Unicast-adress vi har konfigurerad så måste enhet även gå med i den associerade Solicited-node multicast-gruppen för den specifika adressen. Multicast-gruppen Solicited Node börjar alltid med adressen FF02::1:FFxx:xxxx, där vi för de sista 24 bitarna använder motsvarande sista 24-bitar från vår Global eller Link-Local adress.

Detta ger oss möjlighet att kommunicera med enheter trots att vi inte ännu kan deras mac-adress, det är med andra ord IPv6 variant av ARP-lookup (broadcast) som vi använder i IPv4. Funktionen kallas NDP (Neighbor Discovery Protocol) och gör en hel del annat skoj förutom IPv6 -> Mac-adress resolving, men det får bli en egen post vid ett senare tillfälle.

Om vi tar följande exempel från en Global adress:

2001:db8:6783:1111::1/64

För att göra det enklare skriver vi ut alla  “leading 0’s” vi använt.

2001:0db8:6783:1111:0000:0000:0000:0001/64, och så tar vi de sista 24-bitarna:

2001:0db8:6783:1111:0000:0000:0000:0001/64

00:0001

Solicited Node multicast-adressen blir då:

FF02::1:FF00:0001

Vi tar och testar detta i R1;

conf t
interface fa0/0
no ipv6 add
ipv6 enable
R1#show ipv6 int fa0/0
FastEthernet0/0 is up, line protocol is up
 IPv6 is enabled, link-local address is FE80::C000:22FF:FE40:0 
 No Virtual link-local address(es):
 No global unicast address is configured
 Joined group address(es):
 FF02::1
 FF02::2
 FF02::1:FF40:0

Vi kan se att routern automatiskt gått med i tre multicast-grupper.

  • FF02::1 – All-nodes address
  • FF02::1:FF40:0 – Solicited-node address

Om vi även aktiverar IPv6-routing genom kommandot ipv6 unicast-routing kan vi se att routern går med i ytterligare en grupp:

Joined group address(es):
 FF02::1
 FF02::2
 FF02::1:FF40:0
  • FF02::2 – All-routers address

Routern vet nu att den är en router(:D), och måste således gå med i All-routers multicast-gruppen. Låt oss aktivera EIGRP, OSPF & RIP på routern och se vad som händer.

conf t
 int fa0/0
 ipv6 rip RIP-LAB enable
 ipv6 ospf 1 area 0
 ipv6 eigrp 10
 ipv6 router ospf 1
 router-id 1.1.1.1
 ipv6 router eigrp
 router-id 1.1.1.1

Detta ger oss följande resultat (vi behöver lägga till router-id för EIGRP & OSPF då vi inte har någon IPv6-adress konfigurerad på routern):

R1#sh ipv6 int fa0/0
FastEthernet0/0 is up, line protocol is up
 IPv6 is enabled, link-local address is FE80::C000:22FF:FE40:0 
 No Virtual link-local address(es):
 No global unicast address is configured
 Joined group address(es):
 FF02::1 <- All-nodes
 FF02::2 <- All-routers
 FF02::5 <- All OSPF-routers
 FF02::6 <- All OSPF BD/BDR-routers
 FF02::9 <- All RIPng-routers
 FF02::A <- All EIGRP-router s
 FF02::1:FF40:0 <- Solicited node-address

Snyggt!

Hur går det då till lite mer specifikt när en host först bootar upp och endast känner till sin default-gateways L3 IPv6-adress (R1), exempelvis 2001:db8:6783:1::1?

Hosten kommer skicka en “ICMPv6 Neighbor-Solicitation” förfrågan till Solicited-Node Multicast-adressen på L2-segmentet för just 2001:db8:6783:1::1/64, vilket blir?

FF02::1:FF00:1

R1 som är den enda som lyssnar till denna multicast-grupp kommer svara Host med ett ICMPv6 Neighbor-Advertisement innehållandes dess MAC-adress.

Om du kommer ihåg posten från tidigare idag så såg vi följande wireshark-dump på just ett “Neighbor Solicitation”-paket:

IPv6-neighborsolicitation

Paketet är adresserat till multicast-gruppen FF02::1:FFCD:1111 för att kontrollera om det finns någon enhet med adressen “FE80::200:ABFF:FECD:1111)”.

Varje L3 multicast-adress har förövrigt en motsvarande L2-adress. L2-adressen börjar alltid med 3333 (16bitar), och tar sedan de sista 32 bitarna från vår multicast-grupp.

Multicast-gruppen FF02::1 blir då:

3333:0000:0001 -> 33:33:00:00:00:01.

FF02::5 blir:

3333:0000:0005 -> 33:33:00:00:00:05

Vi kan verifiera detta genom att kolla hur ett OSPF-hello paket ser ut:

ipv6-ospfhello

Destinationsadresserna är:

  • L2 – 33:33:00:00:00:05
  • L3 – FF02::5

Det blir lite krångligare när vi ska konvertera Solicited-node adressen till L2 då vi endast använt 24-bitar till att skapa vår L3-adress, men vi behöver som bekant 32-bitar. Vi löser det på ungefär samma sätt som EUI-64 adresser skapas, genom att lägga till FF efter de första 16 bitarna.

L2-adressen för FF02::1:FF00:0001 blir då:

3333:FF00:0001 -> 33:33:FF:00:01