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

Redistribution – Expert Lab

Tänkte ta mig an labben jag nämnde i föregående inlägg från Petr Lapukhov.

Topologin är följande:

expert redistribution

EIGRP AS 123 has been preconfigured on router BabyDoll,SweetPea and Rocket.

  • OSPF Area 0 (Process 234) has been preconfigured on router SweetPea, Rocket and Blondie.
  • EIGRP AS 356 has been preconfigured on router Rocket, BlueJones and Amber.
  • RIP Version 2 has been preconfigured on router Blondie, Amber and WiseMan.
  • Router BabyDoll’s loopback0 interface is advertised in EIGRP AS123.
  • Router SweetPea’s, Blondie’s and Rocket’s loopback0 interfaces are advertised in OSPF Area 0.
  • Router Amber’s and BlueJones’s loopback0 interfaces are advertised in EIGRP AS356.
  • Router WiseMan’s loopback0 interface is advertised in RIPV2.
  • Configure 2-way redistribution on router SweetPea and Rocket between EIGRP AS123 and OSPF.
  • Configure redistribution on router Rocket between EIGRP AS356 and OSPF.
  • Configure redistribution on router Blondie between RIPV2 and OSPF.
  • Ensure you have full connectivity at this moment, every network / loopback should be reachable from any device.

Själva konfigureringen gick smärtfritt och borde inte ställa till några problem vid det här laget.

Troubleshooting:

  1. Remove the “network 1.0.0.0” command on router BabDoll and replace it by redistributing the loopback0 interface into EIGRP AS123.
  2. Do a traceroute from router SweetPea and Rocket to 1.1.1.1, you notice packets are sent through the OSPF network. Ensure they take the most optimal route to the destination.
  3. Ensure all traffic will be sent using the FastEthernet links. The Frame-Relay links should only be used as a backup when the FastEthernet links are down.

Steg 1 & 2

Easy stuff, konfade följande:

BabyDoll(config-router)#no network 1.0.0.0
BabyDoll(config-router)#redistribute connected

En show ip route från SweetPea & Rocket visar dock följande:

SweetPea

Gateway of last resort is not set
C 192.168.123.0/24 is directly connected, FastEthernet0/0
 1.0.0.0/24 is subnetted, 1 subnets
D EX 1.1.1.0 [170/156160] via 192.168.123.1, 00:02:08, FastEthernet0/0
 2.0.0.0/24 is subnetted, 1 subnets
C 2.2.2.0 is directly connected, Loopback0
 3.0.0.0/24 is subnetted, 1 subnets
O 3.3.3.0 [110/65] via 192.168.234.3, 00:31:32, Serial1/0
O E2 192.168.45.0/24 [110/20] via 192.168.234.4, 00:31:32, Serial1/0
 4.0.0.0/24 is subnetted, 1 subnets
O 4.4.4.0 [110/65] via 192.168.234.4, 00:31:33, Serial1/0
 5.0.0.0/24 is subnetted, 1 subnets
O E2 5.5.5.0 [110/20] via 192.168.234.3, 00:31:33, Serial1/0
 6.0.0.0/24 is subnetted, 1 subnets
O E2 6.6.6.0 [110/20] via 192.168.234.3, 00:31:37, Serial1/0
 7.0.0.0/24 is subnetted, 1 subnets
O E2 7.7.7.0 [110/20] via 192.168.234.4, 00:31:38, Serial1/0
C 192.168.234.0/24 is directly connected, Serial1/0
O E2 192.168.35.0/24 [110/20] via 192.168.234.3, 00:31:38, Serial1/0

Rocket

Gateway of last resort is not set
C 192.168.123.0/24 is directly connected, FastEthernet0/0
 1.0.0.0/24 is subnetted, 1 subnets
O E2 1.1.1.0 [110/20] via 192.168.234.2, 00:14:50, Serial2/0
 2.0.0.0/24 is subnetted, 1 subnets
O 2.2.2.0 [110/65] via 192.168.234.2, 00:44:09, Serial2/0
 3.0.0.0/24 is subnetted, 1 subnets
C 3.3.3.0 is directly connected, Loopback0
O E2 192.168.45.0/24 [110/20] via 192.168.234.4, 00:44:09, Serial2/0
 4.0.0.0/24 is subnetted, 1 subnets
O 4.4.4.0 [110/65] via 192.168.234.4, 00:44:10, Serial2/0
 5.0.0.0/24 is subnetted, 1 subnets
D 5.5.5.0 [90/156160] via 192.168.35.5, 00:54:56, FastEthernet1/0
 6.0.0.0/24 is subnetted, 1 subnets
D 6.6.6.0 [90/156160] via 192.168.35.6, 00:54:57, FastEthernet1/0
 7.0.0.0/24 is subnetted, 1 subnets
O E2 7.7.7.0 [110/20] via 192.168.234.4, 00:44:11, Serial2/0
C 192.168.234.0/24 is directly connected, Serial2/0
C 192.168.35.0/24 is directly connected, FastEthernet1/0

Så Sweetpea tar för tillfället rätt väg direkt till R1, men Rocket går via OSPF/Frame-Relay switchen -> R2 -> R1 – suboptimal routing!

Varför det blir såhär har vi gått igenom många gånger tidigare, OSPF har lägre AD än vad EIGRP har, så Rocket ersätter sin egna route med den SweetPea annonserar.  Vi testar med en enkel lösning först och höjer AD för OSPFs externa routes.

router ospf 234
distance ospf external 180

Vi konfar detta på både SweetPea & Rocket, de använder nu routen som annonseras av EIGRP istället och går direkt till R1.

1.0.0.0/24 is subnetted, 1 subnets
D EX 1.1.1.0 [170/156160] via 192.168.123.1, 00:03:58, FastEthernet0/0

Detta leder dock till rätt konstiga problem för andra nät! Om vi kör en sh ip route på SweetPea visas följande:

Gateway of last resort is not set
C 192.168.123.0/24 is directly connected, FastEthernet0/0
 1.0.0.0/24 is subnetted, 1 subnets
D EX 1.1.1.0 [170/156160] via 192.168.123.1, 00:07:03, FastEthernet0/0
 2.0.0.0/24 is subnetted, 1 subnets
C 2.2.2.0 is directly connected, Loopback0
 3.0.0.0/24 is subnetted, 1 subnets
O 3.3.3.0 [110/65] via 192.168.234.3, 00:07:03, Serial1/0
D EX 192.168.45.0/24 
 [170/1709312] via 192.168.123.3, 00:07:01, FastEthernet0/0
 4.0.0.0/24 is subnetted, 1 subnets
O 4.4.4.0 [110/65] via 192.168.234.4, 00:07:04, Serial1/0
 5.0.0.0/24 is subnetted, 1 subnets
O E2 5.5.5.0 [180/20] via 192.168.234.3, 00:07:04, Serial1/0
 6.0.0.0/24 is subnetted, 1 subnets
O E2 6.6.6.0 [180/20] via 192.168.234.3, 00:07:05, Serial1/0
 7.0.0.0/24 is subnetted, 1 subnets
O E2 7.7.7.0 [180/20] via 192.168.234.3, 00:06:44, Serial1/0
C 192.168.234.0/24 is directly connected, Serial1/0
O E2 192.168.35.0/24 [180/20] via 192.168.234.3, 00:07:05, Serial1/0

SweetPea tror nu att den ska gå via Rocket för att nå exempelvis 192.168.45.0.

En traceroute visar dock följande:

SweetPea#traceroute 7.7.7.7
Type escape sequence to abort.
Tracing the route to 7.7.7.7
1 192.168.234.3 24 msec 24 msec 20 msec
 2 * * * 
 3 192.168.234.3 60 msec 60 msec 36 msec
 4 * * * 
 5 192.168.234.3 88 msec 124 msec 52 msec
 6 * * * 
 7 192.168.234.3 112 msec 88 msec 116 msec
 8 * * *

Kollar vi Rocket så ser vi varför det loopas:

7.0.0.0/24 is subnetted, 1 subnets
D EX 7.7.7.0 [170/1709312] via 192.168.123.2, 00:05:42, FastEthernet0/0

expert redistribution 2

SweetPea skickar till Rocket som i sin tur skickar tillbaka till SweetPea. Här körde jag fast rätt rejält och tog istället och läste Petr Lapukhovs blogg om detta, se http://blog.ine.com/2008/02/09/understanding-redistribution-part-i/. Där anger han bl.a. två regler vi alltid ska utgå ifrån:

1 – Router should always prefer internal prefix information over any external information.

2 – Split-Horizon – Never redistribute a prefix injected from domain A into B back to domain A

Han menar också att vi ska tänka på att OSPF endast är en transit-area/core, och bör således ha bäst information generellt sätt. Vi bör därför se till att den föredrar OSPFs uppdateringar istället för EIGRPs som endast används “ute i kanterna”. OSPF’s AD för interna routes är 110 som standard, EIGRP har 90. Vi behöver således sänka AD’t till <90:

router ospf 234
distance ospf intra-area 80 
distance ospf inter-area 80 
distance ospf external 160

Vi behöver ju dock få R2 & R3 att hellre använda EIGRP för 1.1.1.0/24-nätet (R1’s loopback), detta kan vi lösa genom en access-lista istället:

access-list 1 permit 1.1.1.0
router ospf 234
distance 171 0.0.0.0 255.255.255.255 1

Detta ändrar distance för den specifika routern till 171, R2 & R3 kommer således föredra EIGRP External som har 170 per default.

Kollar vi återigen sh ip route så ser det nu mycket bättre ut:

SweetPea

Gateway of last resort is not set
C 192.168.123.0/24 is directly connected, FastEthernet0/0
 1.0.0.0/24 is subnetted, 1 subnets
D EX 1.1.1.0 [170/156160] via 192.168.123.1, 00:03:30, FastEthernet0/0
 2.0.0.0/24 is subnetted, 1 subnets
C 2.2.2.0 is directly connected, Loopback0
 3.0.0.0/24 is subnetted, 1 subnets
O 3.3.3.0 [80/65] via 192.168.234.3, 00:03:30, Serial1/0
O E2 192.168.45.0/24 [160/20] via 192.168.234.4, 00:03:30, Serial1/0
 4.0.0.0/24 is subnetted, 1 subnets
O 4.4.4.0 [80/65] via 192.168.234.4, 00:03:30, Serial1/0
 5.0.0.0/24 is subnetted, 1 subnets
O E2 5.5.5.0 [160/20] via 192.168.234.3, 00:03:30, Serial1/0
 6.0.0.0/24 is subnetted, 1 subnets
O E2 6.6.6.0 [160/20] via 192.168.234.3, 00:03:30, Serial1/0
 7.0.0.0/24 is subnetted, 1 subnets
O E2 7.7.7.0 [160/20] via 192.168.234.4, 00:03:30, Serial1/0
C 192.168.234.0/24 is directly connected, Serial1/0
O E2 192.168.35.0/24 [160/20] via 192.168.234.3, 00:03:30, Serial1/0

Rocket

Gateway of last resort is not set
C 192.168.123.0/24 is directly connected, FastEthernet0/0
 1.0.0.0/24 is subnetted, 1 subnets
D EX 1.1.1.0 [170/156160] via 192.168.123.1, 00:03:41, FastEthernet0/0
 2.0.0.0/24 is subnetted, 1 subnets
O 2.2.2.0 [80/65] via 192.168.234.2, 00:03:41, Serial2/0
 3.0.0.0/24 is subnetted, 1 subnets
C 3.3.3.0 is directly connected, Loopback0
O E2 192.168.45.0/24 [160/20] via 192.168.234.4, 00:03:41, Serial2/0
 4.0.0.0/24 is subnetted, 1 subnets
O 4.4.4.0 [80/65] via 192.168.234.4, 00:03:41, Serial2/0
 5.0.0.0/24 is subnetted, 1 subnets
D 5.5.5.0 [90/156160] via 192.168.35.5, 00:03:41, FastEthernet1/0
 6.0.0.0/24 is subnetted, 1 subnets
D 6.6.6.0 [90/156160] via 192.168.35.6, 00:03:41, FastEthernet1/0
 7.0.0.0/24 is subnetted, 1 subnets
O E2 7.7.7.0 [160/20] via 192.168.234.4, 00:03:41, Serial2/0
C 192.168.234.0/24 is directly connected, Serial2/0
C 192.168.35.0/24 is directly connected, FastEthernet1/0

Vi har inte längre några routing loopar eller suboptimal routing för 1.1.1.0/24-nätet.  En traceroute till 7.7.7.7 borde således fungera nu:

SweetPea#traceroute 7.7.7.7
Type escape sequence to abort.
Tracing the route to 7.7.7.7
1 192.168.234.4 48 msec 32 msec 20 msec
 2 192.168.45.7 64 msec * 24 msec
Rocket#traceroute 7.7.7.7
Type escape sequence to abort.
Tracing the route to 7.7.7.7
1 192.168.234.4 36 msec 24 msec 8 msec
 2 192.168.45.7 16 msec

Stabilt!

Vi ser rätt tydligt vad farligt det kan vara att gå in och ändra AD som gäller generellt för hela routern, utan detta bör göras specifikt för det önskade nätet endast för att undvika märkliga problem.

Steg 3

Ensure all traffic will be sent using the FastEthernet links. The Frame-Relay links should only be used as a backup when the FastEthernet links are down.

Som det är i nuläget använder vi alltid OSPF som transit-area för att ta mellan näten, med ett undantag – R6 <-> R1. En sh ip route på BlueJones(R6) visar följande:

Gateway of last resort is not set
2.0.0.0/24 is subnetted, 1 subnets
D EX 2.2.2.0 [170/1709312] via 192.168.35.3, 00:13:15, FastEthernet0/0
 3.0.0.0/24 is subnetted, 1 subnets
D EX 3.3.3.0 [170/1709312] via 192.168.35.3, 02:03:27, FastEthernet0/0
D EX 192.168.45.0/24 [170/1709312] via 192.168.35.3, 00:13:15, FastEthernet0/0
 4.0.0.0/24 is subnetted, 1 subnets
D EX 4.4.4.0 [170/1709312] via 192.168.35.3, 00:13:15, FastEthernet0/0
 5.0.0.0/24 is subnetted, 1 subnets
D 5.5.5.0 [90/156160] via 192.168.35.5, 02:12:26, FastEthernet0/0
 6.0.0.0/24 is subnetted, 1 subnets
C 6.6.6.0 is directly connected, Loopback0
 7.0.0.0/24 is subnetted, 1 subnets
D EX 7.7.7.0 [170/1709312] via 192.168.35.3, 00:13:16, FastEthernet0/0
D EX 192.168.234.0/24 
 [170/1709312] via 192.168.35.3, 02:03:29, FastEthernet0/0
C 192.168.35.0/24 is directly connected, FastEthernet0/0

Den ser helt enkelt inte 1.1.1.0/24-nätet. Alla andra routrar känner dock till nätet, R2 & R3 har lärt sig via EIGRP, R4  via OSPF från R1&R2, R5& R7 via RIP från R4,

Det bör ju således vara R3 eller R4’s jobb att informera R6, problemet är dock att vi endast redistributar mellan OSPF AS 234 & EIGRP 356 i Rocket. Vi löser detta genom att göra en two-way dist. mellan AS 123 & 356.

router eigrp 123
redistribute eigrp 356 metric 1500 1 255 1 1500
router eigrp 356
redistribute eigrp 123 metric 1500 1 255 1 1500
BlueJones#sh ip route 1.1.1.0
Routing entry for 1.1.1.0/24
 Known via "eigrp 356", distance 170, metric 1709312, type external
 Redistributing via eigrp 356
 Last update from 192.168.35.3 on FastEthernet0/0, 00:01:15 ago
 Routing Descriptor Blocks:
 * 192.168.35.3, from 192.168.35.3, 00:01:15 ago, via FastEthernet0/0
 Route metric is 1709312, traffic share count is 1
 Total delay is 110 microseconds, minimum bandwidth is 1500 Kbit
 Reliability 255/255, minimum MTU 1500 bytes
 Loading 1/255, Hops 1

Sweet!

Advanced

Vi har nu fullt flöde genom nätet, vi har dock fortfarande kvar uppgiften att flytta “transit-arean” från OSPF till EIGRP 356. och endast använda OSPF som backup. Det är nu vi kommer till CCIE-nivån av redistribution-tekniker  här kan jag ärligt säga att jag inte lyckades hitta någon lösning som fungerade. Petr har som tur var dock gjort en bloggpost om hur olika “redistribueringsproblem” kan lösas och finns att hitta här. Kommer använda hans post som guide för att ha en chans att slutföra detta, med förhoppning att kanske om ett år så fixar jag detta på egen hand! 🙂

Det vi vill göra är att ge route’s som kommer från EIGRP356 mer “önskvärda” än de vi lär oss från OSPF & RIP. Routrarna vi behöver modifiera är därmed “border routers” (R2,R3, R4 & R5).

The OSPF and EIGRP 356 domains are both transit. That means, when redistributing from the OSPF domain to EIGRP 356 we should accept the OSPF native prefixes (per the ACLs configured above) in addition to the transit RIP and EIGRP 123 prefixes. The latter prefixes could also be injected into EIGRP 356 natively, from the respective routing domains. Therefore, when accepting the transit routes from the OSPF domain, we should give them the metric value, which makes the prefixes less preferable. For out example, we will use EIGRP metric “1 100 1 1 1” for the “non-native” injected prefixes, which is less preferable than our default “1 1 1 1 1” due to the higher “delay” component value

Vi behöver först skapa access-listor som delar upp de olika näten efter vilken “domain” de kommer ifrån.

ip access-list standard RIP_PREFIXES
 permit 192.168.45.0
 permit 7.7.7.0
ip access-list standard OSPF_PREFIXES
 permit 192.168.234.0
 permit 2.2.2.0
 permit 3.3.3.0
 permit 4.4.4.0
ip access-list standard EIGRP_123_PREFIXES
 permit 192.168.123.0
 permit 1.1.1.0
ip access-list standard EIGRP_356_PREFIXES
 permit 192.168.35.0/24
 permit 6.6.6.0
 permit 5.5.5.0
 permit 3.3.3.0

R3

Vi tar sedan och skapar route-maps, vi börjar med R3:

För OSPF till EIGRP 356:

route-map OSPF_TO_EIGRP_356 permit 10
 match ip address OSPF_PREFIXES
 set metric 1 1 1 1 1
!
route-map OSPF_TO_EIGRP_356 permit 20
 match ip address EIGRP_123_PREFIXES
 set metric 1 100 1 1 1
!
route-map OSPF_TO_EIGRP_356 permit 30
 match ip address RIP_PREFIXES
 set metric 1 100 1 1 1

Vi ger med andra ord ett högre metric för RIP & OSPF-näten när de går via OSPF-domänen. genom att modifera K2-värdet till 100.

Vi måste ju dock även göra det åt andra hållet (EIGRP 356 -> OSPF):

route-map EIGRP_356_TO_OSPF permit 10
 match ip address EIGRP_356_PREFIXES
!
route-map EIGRP_356_TO_OSPF permit 20
 match ip address RIP_PREFIXES
 set metric 100

Vi behåller en låg metric för 356-näten men vi vill ju få RIP-näten mindre attraktiva. Vi behöver givetvis inte ha med EIGRP AS123 här då vi inte vill redistributa det från 356 -> OSPF.

Mellan EIGRP 356 <-> 123 modifierar vi inte metricen då de både redan använder sig av samma routing-protokoll, vi vill dock ge RIP-prefixen ett sämre metric:

route-map EIGRP_123_TO_EIGRP_356 permit 10
 match ip address EIGRP_123_PREFIXES
!
route-map EIGRP_356_TO_EIGRP_123 permit 10
match ip address EIGRP_356_PREFIXES
!
route-map EIGRP_356_TO_EIGRP_123 permit 20
match ip address RIP_PREFIXES
set metric 1 1 1 1 1

Tillsist har vi EIGRP 123 <- > OSPF kvar:

route-map OSPF_TO_EIGRP_123 permit 10
 match ip address OSPF_PREFIXES
 set metric 1 1 1 1 1
!
route-map OSPF_TO_EIGRP_123 permit 20
 match ip address RIP_PREFIXES
 set metric 1 100 1 1 1
!
route-map EIGRP_123_TO_OSPF permit 10
match ip address EIGRP_123_PREFIXES

Vi aktiverar sedan route-mapsen via:

router ospf 234
 redistribute eigrp 356 route-map EIGRP_356_TO_OSPF subnets
 redistribute eigrp 123 route-map EIGRP_123_TO_OSPF subnets
!
router eigrp 123
 redistribute ospf 234 route-map OSPF_TO_EIGRP_123
 redistribute eigrp 356 route-map EIGRP_356_TO_EIGRP_123
!
router eigrp 356
 redistribute eigrp 123 route-map EIGRP_123_TO_EIGRP_356
 redistribute ospf 234 route-map OSPF_TO_EIGRP_356

One down.. Three to go! 🙂

R2

Här finns endast EIGRP 123 & OSPF 234 domänen. För att möjliggöra “backup”-routing via OSPF-domänen om länken till R3 går ner behöver vi även redistributa in EIGRP356 & RIP-routes till EIGRP 123. Värt att tillägga är dock att för RIP-näten så kommer de ju även senare annonseras via R4->R3 -> EIGRP AS123, vi behöver därför sätta ett “bättre” metric när de kommer från OSPF-domänen. För EIGRP123 -> OSPF behöver vi endast redist. de interna näten.

Vi återanvänder ACL’en från tidigare men route-mapsen blir enligt följande:

route-map OSPF_TO_EIGRP_123 permit 10
 match ip address OSPF_PREFIXES
 set metric 1 1 1 1 1
!
route-map OSPF_TO_EIGRP_123 permit 20
 match ip address RIP_PREFIXES
 set metric 1 100 1 1 1
!
route-map OSPF_TO_EIGRP_123 permit 30
 match ip address EIGRP_356_PREFIXES
 set metric 1 1 1 1 1
!
route-map EIGRP_123_TO_OSPF permit 10
match ip address EIGRP_123_PREFIXES
Inga konstigheter här, vi aktiverar redist. genom:
router eigrp 123
 redistribute ospf 234 route-map OSPF_TO_EIGRP_123
!
router ospf 234
 redistribute eigrp 123 route-map EIGRP_123_TO_OSPF subnets

R4

Här behöver vi endast hantera OSPF <-> RIP. Vi har redan konfigurerat så R3 annonserar RIP-näten till OSPF med en metric på 100, vi kan därför lämna den som default här. För OSPF in till RIP sätter vi en metric på 8  (hopcount), och för “transit-prefixen” EIGRP 123 & EIGRP 356 sätter vi ett högre värde. Vi kan då ge en bättre väg från R5 till dessa nät senare.

route-map RIP_TO_OSPF permit 10
 match ip address RIP_PREFIXES 
!
route-map OSPF_TO_RIP permit 10
 match ip address OSPF_PREFIXES
 set metric 8
!
route-map OSPF_TO_RIP permit 20
 match ip address EIGRP_123_PREFIXES
 set metric 12
!
route-map OSPF_TO_RIP permit 30
 match ip address EIGRP_356_PREFIXES
 set metric 12
Och vi aktiverar redist med:
router rip
 redistribute ospf 234 route-map OSPF_TO_RIP
!
router ospf 234
 redistribute rip route-map RIP_TO_OSPF subnets

R5

Last up! Här kommer vi redistributa mellan EIGRP 356 & RIP. Vi behåller vårat standard metric på 8 för de interna RIP-näten samt EIGRP-näten från AS123 & 356 för att göra denna väg mer attraktiv än att gå via OSPF, som vi sätter till 12.

route-map RIP_TO_EIGRP_356 permit 10
 match ip address RIP_PREFIXES
 set metric 1 1 1 1 1
!
route-map EIGRP_356_TO_RIP permit 10
 match ip address EIGRP_356_PREFIXES
 set metric 8
!
route-map EIGRP_356_TO_RIP permit 20
 match ip address OSPF_PREFIXES
 set metric 12
!
route-map EIGRP_356_TO_RIP permit 30
 match ip address EIGRP_123_PREFIXES
 set metric 8

Tro det eller ej men vi är tyvärr inte klara än! 😀 Vi går fortfarande över OSPF-domänen för vissa av näten.

Men genom att justera AD-värdena för respektive router ska vi nog kunna lösa detta nu! Den uppgiften vi hade från GNS3Vault skiljde sig från den lösningen Petr skrev om så här fanns det ingen hjälp att få, men detta var ju löjligt basic om vi jämför med allt vi gjort tidigare.

Konfigen blev följande:

R2
router ospf 234
distance ospf external 190
R3
router ospf 234
distance ospf external 190
R4
router ospf 234
distance ospf external 190

R5
router rip
distance 190

Jag fick även gå in och modifiera route-mapen på R2 då pga vi manuellt satt metrics så började R1/BabyDoll lastbalansera mellan R2&R3 för att nå EIGRP AS356- & RIP-domänerna.

route-map OSPF_TO_EIGRP_123 permit 10
 match ip address OSPF_PREFIXES
 set metric 1 100 1 1 1
!
route-map OSPF_TO_EIGRP_123 permit 20
 match ip address RIP_PREFIXES
 set metric 1 100 1 1 1
!
route-map OSPF_TO_EIGRP_123 permit 30
 match ip address EIGRP_356_PREFIXES
 set metric 1 100 1 1 1
!
route-map EIGRP_123_TO_OSPF permit 10
 match ip address EIGRP_123_PREFIXES

Verifiering

Från R1 – > R7:

BabyDoll#traceroute 7.7.7.7
Type escape sequence to abort.
Tracing the route to 7.7.7.7
1 192.168.123.3 52 msec 24 msec 64 msec
 2 192.168.35.5 44 msec 92 msec 20 msec
 3 192.168.45.7 84 msec * 72 msec

R2 -> R5:

SweetPea#traceroute 5.5.5.5
Type escape sequence to abort.
Tracing the route to 5.5.5.5
1 192.168.123.3 20 msec 56 msec 28 msec
 2 192.168.35.5 44 msec * 20 msec

R4 -> R2:

Blondie#traceroute 2.2.2.2
Type escape sequence to abort.
Tracing the route to 2.2.2.2
1 192.168.234.2 32 msec * 48 msec

*Kom ihåg att vi tillät att trafik med destination direkt till OSPF-domänen ej behövde cirkulera hela nätet.

R4 – > R1:

Blondie#traceroute 1.1.1.1
Type escape sequence to abort.
Tracing the route to 1.1.1.1
1 192.168.45.5 36 msec 24 msec 20 msec
 2 192.168.35.3 36 msec 20 msec 28 msec
 3 192.168.123.1 28 msec * 60 msec

Så vackert att man nästan blir tårögd! 😉

Detta avslutar det här inlägget och nu känns det allt som det får räcka med redistribution ett tag framöver, next up – BGP! 🙂

Vill du testa själv så har GNS3Vault en färdig grundtopologi att hämta här.

Redistribution – Labs

Har tillbringat eftermiddagen med att göra GNS3 Vaults Redistribute-labbar.

RIP to EIGRP redistribution

RIP to OSPF redistribution

Dessa två var väldigt enkla, inget speciellt att tänka på.. Men denna var rätt intressant:

One-Way Redistribution

Oneway

  • All IP addresses have been preconfigured for you.
  • Configure OSPF on router Ace and Aggie and only advertise network 192.168.12.0 /24.
  • Configure EIGRP AS 1 on router Ace, Aggie and Abu. Only advertise network 192.168.13.0 /24 and 192.168.23.0 /24.
  • Redistribute the loopback0 interface in EIGRP AS 1 on router Abu.
  • Redistribute EIGRP information into OSPF on router Ace.
  • Do a traceroute from router Aggi or Ace to network 3.3.3.0 /24. You notice that you are not using the most optimal path…fix this problem so router Aggie uses the most optimal path.

Det var den sista punkten som ställde till det. Kontrollerar vi routing table på Aggie kan vi se följande:

Gateway of last resort is not set
C 192.168.12.0/24 is directly connected, FastEthernet1/0
D 192.168.13.0/24 [90/30720] via 192.168.23.3, 00:03:09, FastEthernet0/0
 3.0.0.0/24 is subnetted, 1 subnets
O E2 3.3.3.0 [110/500] via 192.168.12.1, 00:00:08, FastEthernet1/0
C 192.168.23.0/24 is directly connected, FastEthernet0/0

Aggie väljer helt enkelt att gå via Ace för att komma till 3.3.3.3/24 istället för att gå direkt ner till Abu via fa0/0. En show topology table för EIGRP visar dock att vi ju faktiskt känner till “den bättre vägen” men trots detta väljer att gå via Ace.

Aggie#sh ip eigrp topology 
IP-EIGRP Topology Table for AS(1)/ID(192.168.23.2)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
 r - reply Status, s - sia Status
P 3.3.3.0/24, 0 successors, FD is Inaccessible
 via 192.168.23.3 (1709312/1706752), FastEthernet0/0
P 192.168.13.0/24, 1 successors, FD is 30720
 via 192.168.23.3 (30720/28160), FastEthernet0/0
P 192.168.23.0/24, 1 successors, FD is 28160
 via Connected, FastEthernet0/0

Varför? EIGRP External-routes har en AD av 170, OSPF’s E1/E2 har 110! Lösningen är helt enkelt att modifiera Aggie’s AD, exempelvis genom att höja OSPF’s external över 170.

router ospf 1
distance ospf external 200

Kollar vi återigen routing table kan vi nu se följande:

Gateway of last resort is not set
C 192.168.12.0/24 is directly connected, FastEthernet1/0
D 192.168.13.0/24 [90/30720] via 192.168.23.3, 00:10:07, FastEthernet0/0
 3.0.0.0/24 is subnetted, 1 subnets
D EX 3.3.3.0 [170/1709312] via 192.168.23.3, 00:00:01, FastEthernet0/0
C 192.168.23.0/24 is directly connected, FastEthernet0/0

Labben hittar du här.

Multipoint One-way Redistribution

Oneway

Uppgiften är egentligen densamma som vi hade tidigare, skillnaden är att vi nu ska redistributa EIGRP-informationen på både Ace & Aggie in till OSPF, tidigare gjorde vi detta endast på Ace. Vilka problem kan detta leda till?

Routing table för Ace ser bra ut:

Gateway of last resort is not set
C 192.168.12.0/24 is directly connected, FastEthernet1/0
C 192.168.13.0/24 is directly connected, FastEthernet0/0
 3.0.0.0/24 is subnetted, 1 subnets
D EX 3.3.3.0 [170/1709312] via 192.168.13.3, 00:32:00, FastEthernet0/0
D 192.168.23.0/24 [90/30720] via 192.168.13.3, 00:34:03, FastEthernet0/0

Men för Aggie är det samma problem som innan:

Gateway of last resort is not set
C 192.168.12.0/24 is directly connected, FastEthernet1/0
D 192.168.13.0/24 [90/30720] via 192.168.23.3, 00:33:31, FastEthernet0/0
 3.0.0.0/24 is subnetted, 1 subnets
O E2 3.3.3.0 [110/500] via 192.168.12.1, 00:00:01, FastEthernet1/0
C 192.168.23.0/24 is directly connected, FastEthernet0/0

Vi gör återigen samma lösning på Aggie;

router ospf 1
distance ospf external 200

Resultatet blir:

Gateway of last resort is not set
C 192.168.12.0/24 is directly connected, FastEthernet1/0
D 192.168.13.0/24 [90/30720] via 192.168.23.3, 00:38:07, FastEthernet0/0
 3.0.0.0/24 is subnetted, 1 subnets
D EX 3.3.3.0 [170/1709312] via 192.168.23.3, 00:00:02, FastEthernet0/0
C 192.168.23.0/24 is directly connected, FastEthernet0/0

Men om vi nu kontrollerar routing-tabel för Ace så har något hänt..

Gateway of last resort is not set
C 192.168.12.0/24 is directly connected, FastEthernet1/0
C 192.168.13.0/24 is directly connected, FastEthernet0/0
 3.0.0.0/24 is subnetted, 1 subnets
O E2 3.3.3.0 [110/500] via 192.168.12.2, 00:00:08, FastEthernet1/0
D 192.168.23.0/24 [90/30720] via 192.168.13.3, 00:38:14, FastEthernet0/0

Vafan! Kom ihåg att vi endast kan gäller lokalt för routern vi ändrar på, Ace anser därför nu att den har en bättre väg till 3.3.3.0/24-nätet via Aggie istället.

Vi är med andra ord tvungna att lägga in “distance ospf external 200” även på Ace. Efter detta är allt frid och fröjd igen.. 🙂 Även om det är väldigt enkelt just nu så är det ju bara att sätta sig in i vilka märkliga problem & routing-loopar detta kan leda till i större topologier.

Labben hittar du här.

RIP to EIGRP Two-Way Redistribution & Route Tagging

routetagg redist

  • All IP addresses have been preconfigured for you.
  • RIP and EIGRP have been preconfigred for you on the corresponding routers.
  • Enable two-way redistribution between RIP and EIGRP on router Lassie and Willy.
  • You notice that router Willy or Lassie are sending traffic to 4.4.4.4 towards router Flipper, make sure you get rid of this sub-optimal routing.
  • Use route tagging to accomplish this.

Precis som labben säger tror Willy att bästa vägen för att nå 4.4.4.4 är via Flipper(!) efter vi lagt in grundkonfig.

Gateway of last resort is not set
R 192.168.12.0/24 [120/1] via 192.168.13.1, 00:00:08, FastEthernet0/0
 1.0.0.0/24 is subnetted, 1 subnets
R 1.1.1.0 [120/1] via 192.168.13.1, 00:00:08, FastEthernet0/0
C 192.168.13.0/24 is directly connected, FastEthernet0/0
 4.0.0.0/24 is subnetted, 1 subnets
R 4.4.4.0 [120/6] via 192.168.13.1, 00:00:08, FastEthernet0/0
D 192.168.24.0/24 [90/30720] via 192.168.34.4, 00:03:40, FastEthernet1/0
C 192.168.34.0/24 is directly connected, FastEthernet1/0

Varför? Jo precis som tidigare, RIP har en AD på 120, EIGRP External har 170, Willy kommer med andra ord alltid föredra att gå via Flipper istället för direkt ner till Skippy. Inte helt optimalt direkt.. Den här gången fick vi dock inte modifiera AD-värdet utan ska istället använda oss av route tagging, nice!

Om vi börjar med RIP -> EIGRP, så behövs först en access-lista som definierar vilka routes vi vill tagga (RIP):

ip access-list standard RIP
 permit 1.1.1.1
 permit 192.168.12.0 0.0.0.255
 permit 192.168.13.0 0.0.0.255

Vi bygger sedan en route-map som märker dessa med tag 10, och blockerar routes märkte med tag 5 (fixar vi senare):

route-map RIP-INTO-EIGRP deny 5
 match tag 5

route-map RIP-INTO-EIGRP permit 10
 match ip address RIP
 set tag 10

Och samma sak för EIGRP -> RIP:

ip access-list standard EIGRP
 permit 4.4.4.4
 permit 192.168.24.0 0.0.0.255
 permit 192.168.34.0 0.0.0.255
route-map EIGRP-INTO-RIP deny 5
 match tag 10

route-map EIGRP-INTO-RIP permit 10
 match ip address EIGRP
 set tag 5

En show ip route för Lassie & Willie ser nu ut enligt följande:

Willy

Gateway of last resort is not set
R 192.168.12.0/24 [120/1] via 192.168.13.1, 00:00:20, FastEthernet0/0
 1.0.0.0/24 is subnetted, 1 subnets
R 1.1.1.0 [120/1] via 192.168.13.1, 00:00:20, FastEthernet0/0
C 192.168.13.0/24 is directly connected, FastEthernet0/0
 4.0.0.0/24 is subnetted, 1 subnets
D EX 4.4.4.0 [170/156160] via 192.168.34.4, 00:09:53, FastEthernet1/0
D 192.168.24.0/24 [90/30720] via 192.168.34.4, 00:09:53, FastEthernet1/0
C 192.168.34.0/24 is directly connected, FastEthernet1/0
Lassie
Gateway of last resort is not set
C 192.168.12.0/24 is directly connected, FastEthernet0/0
 1.0.0.0/24 is subnetted, 1 subnets
R 1.1.1.0 [120/1] via 192.168.12.1, 00:00:06, FastEthernet0/0
R 192.168.13.0/24 [120/1] via 192.168.12.1, 00:00:06, FastEthernet0/0
 4.0.0.0/24 is subnetted, 1 subnets
D EX 4.4.4.0 [170/156160] via 192.168.24.4, 00:04:00, FastEthernet1/0
C 192.168.24.0/24 is directly connected, FastEthernet1/0
D 192.168.34.0/24 [90/30720] via 192.168.24.4, 00:04:00, FastEthernet1/0

Sådär ja! Vill du också göra denna labb så finns den här.

Ska brygga mig en stor kanna kaffe och sätta mig med advanced distribution-labben gjord av Petr Lapukhov (CCIEx4 :D). Den är dock främst riktad mot de som studerar inför CCIE-Lab men rekommenderades även för de som verkligen ville gå in på djupet under sina ccnp-studier, och det vill vi ju givetvis! Det får dock bli en egen post om jag nu lyckas. 😉

Policy-based Routing – The Basics

Detta blir ett kort inlägg om policy-based routing där vi återigen använder oss av route maps för att modifiera routingen.

Satte upp följande topologi med OSPF som routing-protokoll:

Policy-based routing

Låt oss säga att vi nu vill göra en form av lastbalansering och skicka trafik som ska till 10.1.1.0/24 & 10.1.2.0/24 via R3, och trafik till 10.1.3.0/24 & 10.1.4.0/24 via R4. Möjligtvis hade vi kunnat åstadkomma detta genom att justera metrics i en evighet men det går att lösa betydligt enklare med hjälp av “Policy-based routing”.

Vi skapar först två access-listor:

access-list 100 permit ip any 10.1.1.0 0.0.0.255
access-list 100 permit ip any 10.1.2.0 0.0.0.255
access-list 110 permit ip any 10.1.3.0 0.0.0.255
access-list 110 permit ip any 10.1.4.0 0.0.0.255

Och sedan tillhörande route-map:

route-map PBR permit 10
 match ip address 100
 set ip next-hop 10.23.0.3

route-map PBR permit 20
 match ip address 110
 set ip next-hop 10.24.0.4

Till skillnad från gårdagens distribution-lab så aktiverar vi policy-routing på önskat interface, i detta fall R2’s fa1/0 mot R1:

interface FastEthernet1/0
 no switchport
 ip address 10.12.0.2 255.255.255.0
 ip policy route-map PBR

Detta gäller dock endast trafik som flödar GENOM routern, om vi även vill applicera en policy på trafik som genereras från den egna router används kommandot: ip local policy route-map PBR.

Gör vi nu en traceroute från R1 kan vi se effekten detta har:

Tracing the route to 10.1.1.1
1 10.12.0.2 40 msec 40 msec 32 msec
 2 10.23.0.3 56 msec 52 msec 40 msec
 3 10.35.0.5 84 msec * 56 msec
Tracing the route to 10.1.2.1
1 10.12.0.2 60 msec 40 msec 24 msec
 2 10.23.0.3 60 msec 44 msec 24 msec
 3 10.35.0.5 68 msec * 68 msec
Tracing the route to 10.1.3.1
1 10.12.0.2 32 msec 64 msec 28 msec
 2 10.24.0.4 60 msec 44 msec 44 msec
 3 10.45.0.5 44 msec * 64 msec
Tracing the route to 10.1.4.1
1 10.12.0.2 44 msec 56 msec 20 msec
 2 10.24.0.4 60 msec 24 msec 52 msec
 3 10.45.0.5 52 msec * 44 msec

Genom debug-kommandot “debug ip policy” kan vi se vad som sker när vi pingar från R1 (10.12.0.1) till R5’s 10.1.3.1 in action:

*Mar 1 00:33:04.367: IP: s=10.12.0.1 (FastEthernet1/0), d=10.1.3.1, len 28, FIB policy match
*Mar 1 00:33:04.367: IP: s=10.12.0.1 (FastEthernet1/0), d=10.1.3.1, g=10.24.0.4, len 28, FIB policy routed
*Mar 1 00:33:04.411: IP: s=10.12.0.1 (FastEthernet1/0), d=10.1.3.1, len 28, FIB policy match
*Mar 1 00:33:04.411: IP: s=10.12.0.1 (FastEthernet1/0), d=10.1.3.1, g=10.24.0.4, len 28, FIB policy routed

Easy! 🙂

Route Redistribution – Lab

Gjorde en av Jeremys “Advanced route redistribution” från hans CCNP-nuggets serie idag. Haft rätt fullt upp förra veckan så har inte blivit så mycket pluggande, får försöka öka tempot igen nu. 🙂

Labben var riktigt givande, satt fast rätt länge på vissa delar, framförallt det sista steget, där var jag tvungen att tjuvkika hur Jeremy löste det hela.. 😛

Topologin såg ut såhär:

redist lab

Och uppgiften var följande:

redist lab 2

 

Min slutkonfig för R2 & R3 blev i slutändan föjande:

access-list 1 permit 10.4.0.0 0.0.0.255
access-list 1 permit 10.4.1.0 0.0.0.255
access-list 2 permit 10.4.2.0 0.0.0.255
access-list 2 permit 10.4.3.0 0.0.0.255
access-list 3 permit 10.4.4.0 0.0.0.255

route-map EIGRP-INTO-OSPF deny 5
match tag 40
route-map EIGRP-INTO-OSPF permit 10
match ip address 1
set metric 100
set tag 10
route-map EIGRP-INTO-OSPF permit 20
match ip address 2
set metric 200
set tag 20
route-map EIGRP-INTO-OSPF deny 30
match ip address 3
route-map EIGRP-INTO-OSPF permit 40
set metric 300
set tag 30
router ospf 1
redistribute eigrp 100 subnets route-map EIGRP-INTO-OSPF
route-map OSPF-INTO-EIGRP deny 5
match tag 10 20 30
route-map OSPF-INTO-EIGRP permit 10
set tag 40
set metric 1500 1 255 1 1500
router eigrp 100
redistribute ospf 1 route-map OSPF-INTO-EIGRP

Och för R2 löste vi sista punkten med:
router eigrp 100
distance eigrp 90 105

 

Route Filtering – The Basics

Genom att använda oss av Route Filtering har vi möjlighet att själva bestämma vilka route’s vi vill tillåta i vårat routing table från de olika routing-protokollen, och även vad vi annonserar ut till övriga routrar.

När vi applicerar ett filter på inkommande trafik använder routern följande flödesschema:

routefilter

Som synes agerar route filtret precis som en access-lista med en explicit deny any.

Låt oss använda följande topologi för att testa oss fram:

routefilter ospf

En sh ip route på R5 ger just nu följande:

20.0.0.0/24 is subnetted, 4 subnets
 O E2 20.0.0.0 [110/20] via 192.168.0.1, 00:00:01, FastEthernet0/1
 O E2 20.0.1.0 [110/20] via 192.168.0.1, 00:00:01, FastEthernet0/1
 O E2 20.0.2.0 [110/20] via 192.168.0.1, 00:00:01, FastEthernet0/1
 O E2 20.0.3.0 [110/20] via 192.168.0.1, 00:00:01, FastEthernet0/1
 O IA 172.16.0.0/16 [110/40] via 192.168.0.1, 00:00:01, FastEthernet0/1
 10.0.0.0/25 is subnetted, 2 subnets
 O IA 10.0.0.0 [110/30] via 192.168.0.1, 00:00:01, FastEthernet0/1
 O IA 10.0.0.128 [110/20] via 192.168.0.1, 00:00:02, FastEthernet0/1
 C 192.168.0.0/24 is directly connected, FastEthernet0/1
 30.0.0.0/24 is subnetted, 2 subnets
 S 30.0.0.0 is directly connected, Null0
 S 30.0.1.0 is directly connected, Null0

För att aktivera filtrering använder vi oss av något som kallas “distribute-list” under routing-processen,

R5(config)#router ospf 1
R5(config-router)#distribute-list ?
 <1-199> IP access list number
 <1300-2699> IP expanded access list number
 WORD Access-list name
 gateway Filtering incoming updates based on gateway
 prefix Filter prefixes in routing updates
 route-map Filter prefixes based on the route-map

Som synes har vi här flera olika möjligheter, vi börja med den enklaste!

Filtrering via Access-list

Låt oss testa filtrera bort 20.0.1.0/24 & 20.0.3.0/24 på R5. Vi skapar först en vanlig access-lista:

access-list 1 deny 20.0.1.0 0.0.0.255
access-list 1 deny 20.0.3.0 0.0.0.255

Vi använder oss sedan av “distribute-list” för att aktivera filtreringen:

router ospf 1
distribute-list 1 in

Om vi endast skriver ovanstående så gäller filtret på alla inkommande interface där vi aktiverat OSPF, men vi kan även skriva ett specifikt interface.

En sh ip route borde ju nu visa alla route’s utom 20.0.1.0 & 20.0.3.0:

Gateway of last resort is not set
C 192.168.0.0/24 is directly connected, FastEthernet0/1
 30.0.0.0/24 is subnetted, 2 subnets
S 30.0.0.0 is directly connected, Null0
S 30.0.1.0 is directly connected, Null0

Hum…?
Förhoppningsvis kanske du redan förstått varför det inte fungerar, kom ihåg den explicita deny any som finns för access-listor! Vi justerar access-listan till följande istället:

access-list 1 deny 20.0.1.0 0.0.0.255
access-list 1 deny 20.0.3.0 0.0.0.255
access-list 1 permit any

En sh ip route visar nu:

Gateway of last resort is not set
20.0.0.0/24 is subnetted, 2 subnets
O E2 20.0.0.0 [110/20] via 192.168.0.1, 00:00:02, FastEthernet0/1
O E2 20.0.2.0 [110/20] via 192.168.0.1, 00:00:02, FastEthernet0/1
O IA 172.16.0.0/16 [110/40] via 192.168.0.1, 00:00:02, FastEthernet0/1
 10.0.0.0/25 is subnetted, 2 subnets
O IA 10.0.0.0 [110/30] via 192.168.0.1, 00:00:02, FastEthernet0/1
O IA 10.0.0.128 [110/20] via 192.168.0.1, 00:00:02, FastEthernet0/1
C 192.168.0.0/24 is directly connecte
*Mar 1 00:42:22.831: %SYS-5-CONFIG_I: Configured from console by consoled, FastEthernet0/1
 30.0.0.0/24 is subnetted, 2 subnets
S 30.0.0.0 is directly connected, Null0
S 30.0.1.0 is directly connected, Null0

2easy! 🙂

Filtrering via Prefix-List

Prefx-list liknar access-listor då vi även här använder oss av permit/deny men är en betydligt mer “kraftfull” variant. Om vi exempelvis vill filtrera bort 20.0.1.0/24 igen så hade vi med en access-lista skrivit:

access-list 1 deny 20.0.1.0 0.0.0.255
access-list 1 permit any

Om vi vill göra samma sak med en prefix-list så skriver vi istället följande:

ip prefix-list OSPF-FILTER deny 20.0.1.0/24

Härligt nog slipper vi skriva wildcardmask den här gången. 🙂 Det som gör prefix-list det lilla extra är den inbyggda funktionen ge (greater than or equal to) & le (less than or equal to). Se följande exempel:

ip prefix-list OSPF-FILTER deny 20.0.0.0/24 le 25

Detta innebär att alla route’s som faller inom spannet 20.0.0.0/24 och har “Less than or Equal to” en /25-mask filtreras bort. Vi kommer med andra ord tillåta /26-32-nät inom samma spann! Förstå vad omständigt det skulle vara att göra samma sak med en vanlig access-lista..  Ytterligare ett exempel:

ip prefix-list OSPF-FILTER permit 10.0.0.0/8 ge 16 le 24

Detta tillåter route’s som faller inom 10.0.0.0/8-spannet och har en subnät-mask som är “Greater than or Equal to” /16 men måste samtidigt vara “Less than or Equal to” /24. Detta innebär att exempelvis 10.0.24.0/24 kommer tillåtas, men 10.10.0.4/30 kommer blockeras då nätet är för litet.  Vad händer med ett nät som inte ens passar in på spannet, ex, 192.168.0.0/24? Det blockeras..

Om vi vill tillåta alla nät då?

ip prefix-list ALL permit 0.0.0.0/0 le 32

Utan “le 32” kommer endast 0.0.0.0 0.0.0.0.0-routen matchas, dvs endast default-route tillåts.

Ett sista exempel, lås oss säga att vi endast vill tillåta Class A-adresser med en /24 mask:

ip prefix-list CLASSA permit 0.0.0.0/1

Låt oss testa detta med vår befintliga topologi, säg att vi vill filtrera bort alla external routes som R2 skickar till R5:

ip prefix-list EXTERNAL seq 10 deny 20.0.0.0/22 ge 24
ip prefix-list EXTERNAL seq 20 permit 0.0.0.0/0 le 32
router ospf 1
distribute-list prefix EXTERNAL in

Observera att vi inte behöver använda oss av sequence-nummer, routern kommer själv lägga in detta (åtminstone i den 3750 jag labbar i).

En sh ip route i R5 ger oss följande:

O IA 172.16.0.0/16 [110/40] via 192.168.0.1, 00:00:03, FastEthernet0/1
 10.0.0.0/25 is subnetted, 2 subnets
O IA 10.0.0.0 [110/30] via 192.168.0.1, 00:00:03, FastEthernet0/1
O IA 10.0.0.128 [110/20] via 192.168.0.1, 00:00:03, FastEthernet0/1
C 192.168.0.0/24 is directly connected, FastEthernet0/1
 30.0.0.0/24 is subnetted, 2 subnets
S 30.0.0.0 is directly connected, Null0
S 30.0.1.0 is directly connected, Null0

Stabilt! Vi kan precis som för access-listor kontrollera om vi fått några matches mot våra statements med följande kommando:

R5#sh ip prefix-list detail 
Prefix-list with the last deletion/insertion: hej
ip prefix-list EXTERNAL:
 count: 2, range entries: 2, sequences: 10 - 20, refcount: 2
 seq 10 deny 20.0.0.0/22 ge 24 (hit count: 8, refcount: 1)
 seq 20 permit 0.0.0.0/0 le 32 (hit count: 3, refcount: 1)

Filtrering via Route-map

Route-maps kan liknas lite som ett scripting-språk då det använder sig av något som kan liknas vid IF- & Do-statements, cisco har dock valt att kalla det match och set. Låt oss testa göra samma sak som vi gjort tidigare, filterera bort de externa route’sen från R2 i R5.

Route-maps använder sig dock av access-listor alternativt  prefix-list för att matcha ip-adresser/nät:

R5(config-route-map)#match ip address ?
 <1-199> IP access-list number
 <1300-2699> IP access-list number (expanded range)
 WORD IP access-list name
 prefix-list Match entries of prefix-lists

Vi har ju dock kvar prefix-listen från föregående exempel så låt oss använda den även här:

route-map RM-EXTERNAL deny 10
match ip address prefix-lists EXTERNAL
router ospf 1
distribute-list route-map RM-EXTERNAL in

En sh ip route på R5 visar följande:

Gateway of last resort is not set
C 192.168.0.0/24 is directly connected, FastEthernet0/1
 30.0.0.0/24 is subnetted, 2 subnets
S 30.0.0.0 is directly connected, Null0
S 30.0.1.0 is directly connected, Null0

Wtf? Lås oss gå tillbaka och se hur vår prefix-lista var uppbyggd!

R5#sh ip prefix-list 
ip prefix-list EXTERNAL: 2 entries
 seq 10 deny 20.0.0.0/22 ge 24
 seq 20 permit 0.0.0.0/0 le 32

Problemet är att vi nu tillåter alla route’s i ACL:en (förutom de externa näten), men pga vårat deny-statement i route-mapen så nekas ju dessa istället. Låt oss ändra route-mapen till ett permit istället.

route-map RM-EXTERNAL permit 10
match ip address prefix-lists EXTERNAL

Kollar återigen på R5:

O IA 172.16.0.0/16 [110/40] via 192.168.0.1, 00:00:03, FastEthernet0/1
 10.0.0.0/25 is subnetted, 2 subnets
O IA 10.0.0.0 [110/30] via 192.168.0.1, 00:00:03, FastEthernet0/1
O IA 10.0.0.128 [110/20] via 192.168.0.1, 00:00:03, FastEthernet0/1
C 192.168.0.0/24 is directly connected, FastEthernet0/1
 30.0.0.0/24 is subnetted, 2 subnets
S 30.0.0.0 is directly connected, Null0
S 30.0.1.0 is directly connected, Null0

Sweet! Det gäller med andra ord att hålla ordning på begreppen när vi bygger lite mer avancerade ACL’s senare. Den rekommendationen jag läst är att man bör alltid hålla sig till permit-statements i route-maps, och sen sköter man själva “deniandet” i prefix- & accesslistorna.

Detta är bara en liten introduktion till de olika varianterna men inlägget börjar kännas lite väl långt så tar och avslutar här, för tro mig, det blir betydligt mer avancerat senare. 😀

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 – Stubzone fortsättning

Fortsättning på föregående inlägg då jag inte riktigt lyckades greppa användandet av stubzones för att minska Query-overflow.

Denna länk förklarade det väldigt bra med tydligt exempel på vad som kan gå snett om vi ej använder oss av stubzones, framförallt när det finns redundanta vägar.

http://routemyworld.com/2008/07/23/bsci-eigrp-queries-stuck-in-active-route-summarization-and-stub-routers/

TL:DR-versionen är att det inte direkt är till för att minska antal Query-paket som skickas totalt, utan mer det antal R1 (från vår gamla topologi) med efterföljande neighbors behöver skicka innan den får ett Reply-paket tillbaka, vilket i sin tur minskar risken för “Stuck in Active”.

Beteendet där R7 skickar en Query till R3 efter att den precis mottagit en Update förklarades klockrent här:

Regarding R5’s behavior in step 5… As R5 is a stub router, the R3 did not send it a Query in step 2. That means that in step 4 R5 still believes that it can get to 0.0.0.0/0 via R3 – USING THE OLD METRIC. More specifically, R5 has its feasible distance and R3’s distance to 0.0.0.0/0 based on static route from R1.

When R3 sends the Update with new metric to 0.0.0.0/0 in step 4, the R5 recalculates the new distance from R3 to the 0.0.0.0/0 and concludes that the R3 does not satisfy the feasibility condition anymore, as R3’s new distance to 0.0.0.0/0 is higher than R5’s current feasibility distance (never mind that FD is based on an old report from R3!).

So R5 removes R3 from the list of feasible successors for 0.0.0.0/0 and checks if there is another one. Nope, R3 was the only one. So the R5 goes active on this particular route, puts FD to infinity, and sends Query to all the neighbors (all = just R3).

The R3 sends a Reply (with the same metric as in the Update it sent a moment ago), but now the metric that R3 provides is better than the current one (infinity), so R5 accepts R3 as the successor.

http://packetlife.net/blog/2010/mar/22/understanding-eigrp-queries/

Detta var troligtvis sista posten relaterat till EIGRP, next up – OSPF.

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!