RIPv2 Conditional default-routes

A few examples of advertising a default-route within RIPv2 using different techniques, some was a bit tricky to figure out. The requirements were as follows (three separate labs):

  1. From R6 – Advertise a default-route via RIP only outbound on Vl146, you are not allowed to use any access/prefix-lists
  2. From R4 – Advertise a default-route via RIP as long as R4 has a route to R9s loopback
  3. From R1 – Advertise a default-route via RIP as long as R1 has reachability to R7s LAN-interface 155.1.7.7, otherwise withdraw route

First lab – Advertise by outbound interface

Advertising a default-route on a specific interface without filtering by accesss/prefix-list we could instead use a route-map.

! R6

route-map FILTER permit 10
 set interface Gi1.146

router rip
 default-information originate route-map FILTER

Big difference from ex. OSPF is that RIP doesn’t require the route to be in it’s actual routing-table to advertise it, which in turn leads to a routing loop in our topology. R6 advertise the route to R1 & R4, R1 will in turn advertise it to R7 who will forward it to R6. R6 will accept the route as it dosen’t have a default-route in it’s table and advertise that.

R6#sh ip rip database 0.0.0.0 0.0.0.0
0.0.0.0/0
 [4] via 155.1.67.7, 00:00:07, GigabitEthernet1.67

R6#sh ip rip database 0.0.0.0 0.0.0.0
0.0.0.0/0
 [8] via 155.1.67.7, 00:00:00, GigabitEthernet1.67

R1#sh ip route | beg Gate
Gateway of last resort is 155.1.146.6 to network 0.0.0.0

R* 0.0.0.0/0 [120/13] via 155.1.146.6, 00:00:02, GigabitEthernet1.146

This can be solved in many ways, I chose to insert a dummy default-route to null0, but you could also use filtering etc.

! R6

ip route 0.0.0.0 0.0.0.0 null0

R6 will now ignore the default-route advertisement from R7 and not propagate it any further.

R6#sh ip rip database 0.0.0.0 0.0.0.0
0.0.0.0/0 redistributed
 [1] via 0.0.0.0,

R8#sh ip rip database 
0.0.0.0/0 auto-summary
0.0.0.0/0
 [3] via 155.1.58.5, 00:00:09, GigabitEthernet1.58

Second lab – Conditional default-route

This lab requires us to originate a default-route from R4 as long as it has a route to R9s loopback0, the final solution looked like this for me:

! R4

ip prefix-list R9 permit 150.1.9.9/32

route-map R9_TRACKING permit 10
 match ip address prefix-list R9

ip route 0.0.0.0 0.0.0.0 null0

router rip
 default-information originate route-map R9_TRACKING

The logic is that as long as our route-map matches the prefix-list of R9s loopback it will advertise the default-route, and we add a static route to avoid routing loops via the DMVPN-hub R5 (no split-horizon). Let’s verify to be sure.

R5#sh ip route | inc 0.0.0.0
Gateway of last resort is 155.1.45.4 to network 0.0.0.0
R* 0.0.0.0/0 [120/1] via 155.1.45.4, 00:00:05, GigabitEthernet1.45

If we shut R9s loopback the default-route should time out eventually.

! R9

int Lo0
 shut

R4#sh ip route 150.1.9.9
% Subnet not in table

R5#sh ip route 0.0.0.0 
% Network not in table

Third lab – IP SLA & default-route

This lab requires us to advertise a default-route as long as R1 has reachability to R7s LAN-interface 155.1.7.7, otherwise withdraw route. So obviously we’re looking at setting up IP SLA to start with.

! R1

ip sla 1
 icmp-echo 155.1.7.7
 frequency 5

ip sla schedule 1 start-time now life forever
track 1 ip sla 1

R1#sh track 1
Track 1
 IP SLA 1 state
 State is Up

I couldn’t figure out how to use our tracker in RIP however, eventually I found a pretty neat solution that might not be the prettiest, but it does the trick. First we create a “dummy-route” together with our tracker.

! R1
ip route 169.254.254.1 255.255.255.255 null0 track 1

Next step we borrow from our second lab, we create a prefix-list matching our dummy-route together with a route-map that we then use as a condition for our default-route advertising.

! R1

ip prefix-list DUMMY_FILTER permit 169.254.254.1/32
route-map DUMMY permit 10
 match ip address prefix-list DUMMY_FILTER

router rip
 default-information originate route-map DUMMY

The logic is, when our tracker (testing icmp-reachability to 155.1.7.7) goes down, our dummy static route will be removed from the routing table. This will in turn make rip stop advertising (or rather poison-reverse) the default as our route-map no longer has any match. Let’s try it!

! R7

interface Gi1.7
 shut

! R1

R1#debug ip rip
RIP protocol debugging is on
R1#
%TRACK-6-STATE: 1 ip sla 1 state Up -> Down
R1#
RIP: sending v2 flash update to 224.0.0.9 via Loopback0 (150.1.1.1)
RIP: build flash update entries
 0.0.0.0/0 via 0.0.0.0, metric 16, tag 0
 155.1.7.0/24 via 0.0.0.0, metric 16, tag 0

As our tracker goes down, R1 poisons the default-route and it will eventually timeout in our other routers.

R2#sh ip route 0.0.0.0 
% Network not in table

Fun stuff, even RIP can be pretty tricky even though it’s such a basic protocol compared to the rest. 🙂

RIPv2 Filtering with Prefix-lists

A small lab on RIPv2 and the use of prefix-lists which had a pretty neat solution with filtering by advertising router that I hadn’t seen before.

Requirements:

  • Stop R5 from advertising the Loopback-prefixes of R6 & R7 to R8 with a prefix-list, everything else should be forwarded
  • In R5, filter out any RIP updates received from R4 over the DMVPN-cloud, other routes should be accepted over DMPVN

We enable RIPv2 on all routers with the very basic commands:

router rip
 version 2
 network 150.1.0.0
 network 155.1.0.0
 no auto-summary

Step1 should be fairly straightforward, we create a prefix-list denying the loopbacks of R6 & R7 and filter updates going out on Gi1.58 on R5.

ip prefix-list LO_FILTER deny 150.1.6.6/32
ip prefix-list LO_FILTER deny 150.1.7.7/32
ip prefix-list LO_FILTER permit 0.0.0.0/0 le 32

The “permit 0.0.0.0/0 le 32” works just like a “permit any any” in an access-list. Final step is to set which interface (Gi1.58) and in what direction it should be filtered (outgoing).

router rip
 distribute-list prefix LO_FILTER out GigabitEthernet1.58

After the invalid timer has expired the routes for R6 & R7s loopbacks should drop from R8s routing table while still getting the rest of the networks.

R8# sh ip route | beg Gate
Gateway of last resort is not set

150.1.0.0/32 is subnetted, 8 subnets
R 150.1.1.1 [120/2] via 155.1.58.5, 00:00:28, GigabitEthernet1.58
R 150.1.2.2 [120/2] via 155.1.58.5, 00:00:28, GigabitEthernet1.58
R 150.1.3.3 [120/2] via 155.1.58.5, 00:00:28, GigabitEthernet1.58
R 150.1.4.4 [120/2] via 155.1.58.5, 00:00:28, GigabitEthernet1.58
R 150.1.5.5 [120/1] via 155.1.58.5, 00:00:28, GigabitEthernet1.58
C 150.1.8.8 is directly connected, Loopback0
R 150.1.9.9 [120/4] via 155.1.58.5, 00:00:28, GigabitEthernet1.58
R 150.1.10.10 [120/1] via 155.1.108.10, 00:00:05, GigabitEthernet1.108

The next requirement is the tricky bit, here I was stuck for quite a while and I still haven’t actually managed to find any current official documentation regarding it except for this deprecated IOS 12.2 docs. First step first, as we need to filter out routes from R4 over the DMVPN and accept the rest, let’s create two (a bit strange I know but you’ll soon see why) prefix-lists:

ip prefix-list ACCEPT_ALL permit 0.0.0.0/0 le 32

ip prefix-list BLOCK_R4 deny 155.1.0.4/32
ip prefix-list BLOCK_R4 permit 0.0.0.0/0 le 32

We then use an extension within the distribute-list command in RIP thats called “gateway”, to first specify which networks we will accept (ACCEPT_ALL) filtered by gateway (BLOCK_R4). The actual command looks like this:

router rip
 distribute-list prefix ACCEPT_ALL gateway BLOCK_R4 in

We should now see every network except the ones advertised from R4 over the DMVPN-cloud (150.1.0.4):

R5#sh ip route | beg Gate
Gateway of last resort is not set

150.1.0.0/32 is subnetted, 10 subnets
R 150.1.1.1 [120/1] via 155.1.0.1, 00:00:07, Tunnel0
R 150.1.2.2 [120/1] via 155.1.0.2, 00:00:12, Tunnel0
R 150.1.3.3 [120/1] via 155.1.0.3, 00:00:06, Tunnel0
R 150.1.4.4 [120/1] via 155.1.45.4, 00:00:09, GigabitEthernet1.45
C 150.1.5.5 is directly connected, Loopback0
R 150.1.6.6 [120/2] via 155.1.0.1, 00:00:07, Tunnel0
R 150.1.7.7 [120/2] via 155.1.0.3, 00:00:06, Tunnel0
R 150.1.8.8 [120/1] via 155.1.58.8, 00:00:19, GigabitEthernet1.58
R 150.1.9.9 [120/3] via 155.1.0.3, 00:00:06, Tunnel0
R 150.1.10.10 [120/2] via 155.1.58.8, 00:00:19, GigabitEthernet1.58

R5#sh ip rip database 150.1.4.4 255.255.255.255
150.1.4.4/32
 [1] via 155.1.45.4, 00:00:20, GigabitEthernet1.45

Sweet! We’re still receiving R4’s loopback but over the physical link instead of the DMVPN.

TSHOOT – Part III, Dist-layer

tshoot-distlayer

Tar och bygger vidare på vårat tshoot-nät med Distribution-layer den här gången. Vi behöver bl.a. konfa upp EIGRP<->OSPF & RIP_NG <->OSPFv3 redistrubution.

Men först måste vi givetvis fixa L2/L3-konfig.. Tyvärr är just switch-funktionen i GNS3 väldigt begränsad (använder endast NM-16ESW-kort i 3640s), så våra port-channel nummer kommer inte stämma överens. Det finns inte heller möjlighet att skapa en L3-channel mellan DSW1 & DSW2 så här blir det endast en port som kommer användas.

Basic L3

R4

R4(config)#inte fa0/0
R4(config-if)#ip add 10.1.4.5 255.255.255.252
R4(config-if)#descrip to DSW1
R4(config-if)#no shut
R4(config-if)#ipv6 add 2026::2:1/122
R4(config-if)#inte fa0/1
R4(config-if)#ip add 10.1.4.9 255.255.255.252
R4(config-if)#desc to DSW2
R4(config-if)#no shut

DSW1

DSW1(config)#ip routing
DSW1(config)#ipv6 unicast-routing
DSW1(config)#int fa0/0
DSW1(config-if)#ip add 10.1.4.6 255.255.255.252
DSW1(config-if)#descrip to R4
DSW1(config-if)#no shut
DSW1(config-if)#ipv6 add 2026::2:2/122
DSW1(config)#int range fa1/13 - 14
DSW1(config-if-range)#descrip L3 Etherchannel to DSW2
DSW1(config-if-range)#no switchport
DSW1(config-if-range)#shut
DSW1(config-if-range)#
DSW1(config-if-range)#inte fa1/13
DSW1(config-if)#ip add 10.2.4.13 255.255.255.252
DSW1(config-if)#ipv6 add 2026::3:1/122
DSW1(config-if)#no shut

DSW2

DSW2(config)#ip routing
DSW2(config)#ipv6 uni
DSW2(config)#ipv6 unicast-routing
DSW2(config)#inte fa0/0
DSW2(config-if)#ip add 10.1.4.10 255.255.255.252
DSW2(config-if)#descrip to R4
DSW2(config-if)#no shut
DSW2(config-if)#int range fa1/13 - 14
DSW2(config-if-range)#descrip L3 Etherchannel to DSW1
DSW2(config-if-range)#no switchport
DSW2(config-if-range)#shut
DSW2(config-if-range)#inte fa1/13
DSW2(config-if)#ip add 10.2.4.14 255.255.255.252
DSW2(config-if)#no shut
DSW2(config-if)#ipv6 add 2026::3:2/122
DSW2(config-if)#exit

EIGRP

R4

R4(config)#router eigrp 10
R4(config-router)#no auto
R4(config-router)#no auto-summary
R4(config-router)#passive-
R4(config-router)#passive-interface default
R4(config-router)#no passive
R4(config-router)#no passive-interface fa0/0
R4(config-router)#no passive-interface fa0/1
R4(config-router)#network 10.1.4.4 0.0.0.3
R4(config-router)#network 10.1.4.8 0.0.0.3

DSW1

DSW1(config)#router eigrp 10
DSW1(config-router)#no auto-summary
DSW1(config-router)#passive-interface default
DSW1(config-router)#no passive-interface fa0/0
DSW1(config-router)#no passive-interface fa1/13
DSW1(config-router)#network 10.1.4.4 0.0.0.3
DSW1(config-router)#network 10.2.4.12 0.0.0.3

DSW2

DSW2(config)#router eigrp 10
DSW2(config-router)#no auto-summary
DSW2(config-router)#passive-interface default
DSW2(config-router)#no passive-interface fa0/0
DSW2(config-router)#no passive-interface fa1/13
DSW2(config-router)#network 10.1.4.8 0.0.0.3
DSW2(config-router)#network 10.2.4.12 0.0.0.3

RIPng

R4

R4(config-router)#inte fa0/0
R4(config-if)#ipv6 rip RIP_ZONE enable
R4(config-if)#int fa0/1
R4(config-if)#ipv6 rip RIP_ZONE enable

DSW1

DSW1(config)#inte fa0/0
DSW1(config-if)#ipv6 rip RIP_ZONE enable
DSW1(config)#int fa1/13
DSW1(config-if)#ipv6 rip RIP_ZONE enable

DSW2

DSW2(config)#inte fa0/0
DSW2(config-if)#ipv6 rip RIP_ZONE enable
DSW2(config)#int fa1/13
DSW2(config-if)#ipv6 rip RIP_ZONE enable

Redistribution

Då vi inte har multipoint-redistribution behöver vi inte använda oss av route-maps/tags i det här fallet.

R4(config)#router eigrp 10
R4(config-router)#redistribute ospf 1 metric 1500 1 255 1 1500
R4(config-router)#router ospf 1
R4(config-router)#redistribute eigrp 10 subnets
R4(config)#ipv6 router ospf 6
R4(config-rtr)#redistribute rip RIP_ZONE include-connected metric 20
R4(config)#ipv6 router rip RIP_ZONE
R4(config-rtr)#redistribute ospf 6 metric 5 include-connected

Verifiering

DSW2#sh ipv6 rip database
RIP process "RIP_ZONE", local RIB
 2026::2:0/122, metric 2, installed
 FastEthernet1/13/FE80::CE03:13FF:FE54:F10D, expires in 165 secs
 2026::3:0/122, metric 2
 FastEthernet1/13/FE80::CE03:13FF:FE54:F10D, expires in 165 secs
 2026::34:0/122, metric 7, installed
 FastEthernet1/13/FE80::CE03:13FF:FE54:F10D, expires in 165 secs
 ::/0, metric 7, installed
 FastEthernet1/13/FE80::CE03:13FF:FE54:F10D, expires in 165 secs

Ping till R1 från DSW2

DSW2#ping ipv6 2026::12:1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2026::12:1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 136/160/200 ms
DSW2#ping 10.1.1.1
Translating "10.1.1.1"
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 52/111/192 ms

Vackert!

En trace till webservern fungerar dock ej:

DSW2#traceroute 209.65.200.241 Translating "209.65.200.241"
Type escape sequence to abort.
 Tracing the route to 209.65.200.241
1 10.1.4.9 16 msec 48 msec 48 msec
 2 10.1.1.9 108 msec 48 msec 44 msec
 3 10.1.1.5 40 msec 80 msec 84 msec
 4 10.1.1.1 140 msec 108 msec 156 msec
 5 * * *

Detta beror helt enkelt på att vi inte konfigurerat upp någon NAT ännu i R1 så trafiken hittar inte tillbaka. Det fixar vi imorgon tillsammans med DHCP-tjänsten & access-layer. 🙂

IPv6 – RIPng

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

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

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

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

ipv6-simple-topology

R1 / R2 / R3:

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

Show ipv6 rip visar följande:

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

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

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

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

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

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

Från R2:

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

R3:

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

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

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

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

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

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

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

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

ipv6-ripng

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

IPv6 – 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

IPv6 – Simple Topology & RIPng

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

ipv6-simple-topology

Låt oss börja med R1:

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

ipv6 unicast-routing

Interface-konfigen blir sedan:

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

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

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

Detta ger följande output:

ipv6-biref

R2:

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

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

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

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

R3

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

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

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

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

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

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

ipv6-route

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

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

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 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. 😀