Toon posts:

CCNP/CCIE - PBR Routing?

Pagina: 1
Acties:

Verwijderd

Topicstarter
Hallo,

Iemand hier die mij wellicht kan helpen met het volgende? Ik probeer PBRouting op te zetten, maar krijg niet de verwachte resultaat..

Het betreft hier een kleine netwerk; twee hosts, één PBR router en twee ISP`s. Alle HTTP verzoeken van "Host" moet via de ABRR (PBR router) doorverwezen worden naar ISP1 (groene cirkel). De rest van de verbindingen kunnen naar zowel ISP 1 en ISP 2.

Tekening van het netwerk.
Afbeeldingslocatie: http://i50.tinypic.com/216hvo.png

De volgende configuraties.

Host.
Current configuration : 843 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Host
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
memory-size iomem 5
ip cef
!
!
!
!
no ip domain lookup
!
!
interface FastEthernet0/0
no ip address
duplex auto
speed auto
!
interface Serial0/0
no ip address
clock rate 2000000
!
interface FastEthernet0/1
ip address 192.168.1.2 255.255.255.0
duplex auto
speed auto
!
router eigrp 1
network 192.168.1.1 0.0.0.0
no auto-summary
!
ip default-gateway 192.168.1.1
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 FastEthernet0/1
!
!
no ip http server
no ip http secure-server
!

!
control-plane
!
!
line con 0
exec-timeout 0 0
logging synchronous
line aux 0
line vty 0 4
!
!
end
ABRR (PBR)
Current configuration : 1075 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname ABRR
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
memory-size iomem 5
ip cef
!
!
!
!
no ip domain lookup
!
!
!
!
interface FastEthernet0/0
ip address 192.168.1.1 255.255.255.0
ip policy route-map t1
duplex auto
speed auto
!
interface Serial0/0
no ip address
clock rate 64000
!
interface FastEthernet0/1
no ip address
shutdown
duplex auto
speed auto
!
interface Serial0/1
ip address 10.1.101.2 255.255.255.0
clock rate 64000
!
interface Serial0/2
ip address 10.1.102.2 255.255.255.0
clock rate 64000
!
interface Serial0/3
no ip address
shutdown
clock rate 2000000
!
ip forward-protocol nd
!
!
no ip http server
no ip http secure-server
!
access-list 101 permit tcp any any eq www
!
route-map t1 permit 10
match ip address 101
set ip next-hop 10.1.101.1
!
!
!
!
control-plane
!
!
!
line con 0
exec-timeout 0 0
logging synchronous
line aux 0
line vty 0 4
!
!
end
De configuratie van ISP 1 en 2 is vrij simpel. Output van ISP 1 (twee is haast identiek).
interface Serial0/1
ip address 10.1.101.1 255.255.255.0
no ip route-cache
clock rate 2000000
!
ip default-gateway 10.1.101.2
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 Serial0/1
Nu, als ik het goed begrepen heb, dient al het HTTP verkeer van "HOST" zo doorverwezen te worden naar ISP1, correct? Nu werkt het pingen en telnet van "Host" naar ISP1 en ISP2 zonder problemen. Het telnet naar port 80 werkt ook! Maar dan alleen naar ISP1? Bij het telnet naar ISP2 port 80, mislukt de verbinding? Waarom??

Host#telnet 10.1.102.1 80
Trying 10.1.102.1, 80 ...
% Connection timed out; remote host not responding


ABRR (PBR) debug output.
**Mar 1 04:48:50.462: IP: s=192.168.1.2 (FastEthernet0/0), d=10.1.102.1, g=10.1.101.1, len 44, FIB policy routed


Wat begrijp ik nu niet of verkeerd? Want het zou eigenlijk zo moeten zijn; dat indien "Host" http verkeer opstuurt richting ABRR (PBR), dat deze (PBR) het verkeer dan zou moeten omzeilen richting ISP1, correct? Waarom laat ie het hier dan vallen? PBR dient het verkeer toch te "redirecten", en niet tegen te houden?

Iemand enige idee hoe dit zit?

  • Pauwl
  • Registratie: September 2001
  • Laatst online: 12:03
zoals je ziet probeert hij al het www verkeer te routeren naar 101.1, zoals je opgeeft in je pbr config.
Het doet dus feitelijk precies wat je geconfigureerd hebt.
Ik snap dan ook niet waarom je www verkeer naar 102.1 wilt sturen als je in je pbr opgeeft dat al het www verkeer gerouteerd moet worden naar 101.1? :?

Wat wil je nu precies bereiken?

Verwijderd

Topicstarter
Hoi Pauwl en dank voor je reactie.

Het ging mij er eigenlijk om dat de PBRouter zelf de nodige actie ondernam om de client request te "redirecten" naar de 101.1 ISP. Als ik al vanaf de "Host" zeg: telnet 10.1.101.1 80, ja dan komt ie vanzelfsprekend bij ISP 101.1. Ik test dit daarom door via de "Host" te zeggen: www request naar ISP2. Vervolgens zou de PBrouter zeggen: "Match! Redirect naar 101.1". De PBR doet dat inderdaad, maar waarom komt mijn client request niet door? Waarom dan de mislukte verbinding?

Ik las/hoorde trouwens dat je met policy based routing niet de destination van het packet kunt wijzigen, maar wel het pad? Is dit correct? Want ik probeer hier namelijk de destination van het pakketje te wijzigen, wellicht niet de bedoeling van Policy based routing?

Heb ik nu PBrouting verkeerd begrepen? Of is mijn config en mijn kennis van PBrouting correct, slechts de cliënt welk "raar" doet, door de verbinding niet tot stand te brengen?

Gr.

  • ik222
  • Registratie: Maart 2007
  • Niet online
Wat er gebeurt is logisch, PBR doet niets anders dan op eigenschappen van het verkeer (source adres, protocol etc.) het een bepaalde kant op sturen. Het veranderd dus niets aan de uiteindelijke bestemming van het verkeer. Wat er nu gebeurt wanneer jij verkeer naar ISP 2 (10.1.102.1) wilt sturen is het volgende.

- Het telnet verkeer over poort 80 van '" Host" komt aan op je router (ABBR)
- Die router ziet dat het je PBR config matcht (het is immers poort 80) en stuurt het dus netjes volgens je configuratie door naar 10.1.101.1.
- Het verkeer komt nu aan bij ISP 1 (10.1.101.1) maar die heeft geen route naar ISP 2 (10.1.102.1) en dus komt het verkeer nooit aan op zijn eindbestemming.

Als je die eindbestemming wel wilt veranderen moet je niet naar PBR maar naar NAT kijken :)

  • jvanhambelgium
  • Registratie: April 2007
  • Laatst online: 30-11 14:23
PBR is geen voodoo in de zin dat je geen "destination" van een packet an-sich kan veranderen ! (zoals vb source-nat dat wel kan) maar wel DE ROUTE ernaar toe.
Met PBR kan je "afwijken" van de standaard routing-regeltjes ( en dat is in de praktijk altijd destination based)

Betreffende je specifiek probleem ... is de WEG TERUG ook helemaal goed ?!
Stel ...

Vanaf HOST (=192.168.1.2) doe je een telnet op port 80 naar 10.1.102.1
De host (= router) forward naar de PBR via Fast0/0 en daar zit ook je route-map op.

Zoals je ziet op je debug-output is de "next hop" gezet op ISP1 ongeacht welke IP je nu wilde bereiken (want je deed een telnet naar een IP dat eigenlijk op ISP2 zit)

Laten we ervan uitgaan dat je packet effectief op de ISP1-router toekomt, maar die kan er niets mee. Die ISP1-router weet immers niet specifiek de weg naar "10.1.102.1" (want dat zit bij ISP2)
Bon, hij gaat z'n default-route aanspreken als laatste redmiddel...

Packet komt terug op de PBR-router over de Serial0/1...deze gaat "klassiek" routeren (gewone FIB zeg maar) en zou dit packet dus over Serial0/2 moeten sturen naar ISP2-router indien de FIB van PBR-router weet dat het subnet/netwerk 10.1.102.0/24 daar te vinden is.

Print eens een "sh ip route" vanop de PBR-router ? Kent hij effectief al hetgene hij moet weten?

Bijkomend vraagje ? Waarom de clockrate 64000 op de kant PBR-router op beide interfaces en clockrate 2000000 langs de andere kant ? Die link is toch degelijk "up" en bruikbaar hé?

Verwijderd

Topicstarter
Dank Pauwl, Ik222 en jvanhambelgium!

Begrijp het gebeuren, op een haartje na. Zoals Ik222 en jvanham zeggen: Het pakket komt inderdaad aan op ISP1, doch de destination adres verandert niet. Zodra ISP1 het ip: "10.1.102.1" ziet, weet ie er inderdaad niks mee te doen. In de config staat wel: 0.0.0.0/0 via s0/1. ISP1 zou deze daarom via z'n s0/1 terug moeten sturen naar PBR? Deze kijkt op zijn beurt weer naar de destination adres, en zou het pakket nu richting ISP2 moeten sturen? Laatst stukje klopt denk ik niet? Immers ik heb "debug ip packet" aanstaan op ISP1 en ISP2. ISP2 ontvangt geen ip packets van PBR.. waar ga ik de fout in?

Wat ook raar is: Gezien "debug ip packet" aanstaat op ISP1, zou deze de foute packets richting ISP2 moeten zien, correct? Ik zie ze echter niet opdagen. Ziet indien ik een telnet 80 doe richting ISP1:

Host
Host#telnet 10.1.101.1 80
Trying 10.1.101.1, 80 ... Open


ABRR (PBR)
*Mar 1 11:56:33.733: IP: s=192.168.1.2 (FastEthernet0/0), d=10.1.101.1, g=10.1.101.1, en 40, FIB policy routed

ISP1
*Mar 1 12:58:43.960: IP: s=10.1.101.1 (local), d=192.168.1.2 (Serial0/1), len0, sending

Dit gebeuren doet zich niet voor wanneer ik telnet 80 richting ISP2. Je zou denken, gezien PBR deze door verwijst naar ISP1, dat ISP1 op z`n minst pakketten moeten ontvangen correct? Dit gebeurt echter niet.

@jvan. De routers werken correct. De clockrate (2000000) is default. Alle routers kunnen elkaar bereiken. De routers kennen namelijk een ip route 0.0.0.0/0 naar PBR. Deze handelt zelf verder de packets af.
Gateway of last resort is not set

10.0.0.0/24 is subnetted, 2 subnets
C 10.1.102.0 is directly connected, Serial0/2
C 10.1.101.0 is directly connected, Serial0/1
C 192.168.1.0/24 is directly connected, FastEthernet0/0

[ Voor 24% gewijzigd door Verwijderd op 04-11-2012 20:29 ]


  • jvanhambelgium
  • Registratie: April 2007
  • Laatst online: 30-11 14:23
Euh...

Ik kan niet uit je config afleiden of er op ISP2 "iets" draait waar je een HTTP connectie mee kan opzetten ? Ander is het uiteraard normaal dat ie zegt "remote host not responding" !
Heb je op ISP1 en ISP2 router de "ip http server" draaien ?? Of iets dat op port 80 zit ?

Indien dit het geval is moet je mischien maar een bruut aan de debug gaan.
Als je weinig tot geen traffiek doet moet je geen schrik hebben om de boel te laten crashen !
Soms kan er dan iets verschijnen wat nuttige info is ;-)


Genereer even geen traffiek ; doe vervolgens een "debug ip packet" op zowel PBR als ISP2 en probeer dan vanaf de HOST het testje met telnet op port 80 naar het IP van ISP2
Je kan ook "debug ip routing" mee opzetten.

Trouwens, die PBR-router ?? Welk devices is da ? Een Catalyst L3 switch ? Welk model + software versie ?


----------------------------------------
Het telnet naar port 80 werkt ook! Maar dan alleen naar ISP1? Bij het telnet naar ISP2 port 80, mislukt de verbinding? Waarom??

Host#telnet 10.1.102.1 80
Trying 10.1.102.1, 80 ...
% Connection timed out; remote host not responding

ABRR (PBR) debug output.
**Mar 1 04:48:50.462: IP: s=192.168.1.2 (FastEthernet0/0), d=10.1.102.1, g=10.1.101.1, len 44, FIB policy routed
----------------------------------------------

[ Voor 4% gewijzigd door jvanhambelgium op 04-11-2012 20:40 ]


Verwijderd

Topicstarter
Op ISP2 draait inderdaad "ip http server". PBRouter = ABRR#show version
Cisco IOS Software, 3700 Software (C3725-ADVIPSERVICESK9-M), Version 12.4(17), RELEASE SOFTWARE (fc1)

Zet debug ip packet aan op PBR, ISP1 en ISP2. Doe vervolgens eerst een ping richting ISP2.

Host

Host#ping 10.1.102.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.102.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/32/68 ms


PBR
*Mar 1 12:25:31.372: IP: s=192.168.1.2 (FastEthernet0/0), d=10.1.102.1, len 100, FIB policy rejected(no match) - normal forwarding
*Mar 1 12:25:31.400: IP: s=192.168.1.2 (FastEthernet0/0), d=10.1.102.1, len 100, FIB policy rejected(no match) - normal forwarding
*Mar 1 12:25:31.424: IP: s=192.168.1.2 (FastEthernet0/0), d=10.1.102.1, len 100, FIB policy rejected(no match) - normal forwarding
*Mar 1 12:25:31.456: IP: s=192.168.1.2 (FastEthernet0/0), d=10.1.102.1, len 100, FIB policy rejected(no match) - normal forwarding
*Mar 1 12:25:31.476: IP: s=192.168.1.2 (FastEthernet0/0), d=10.1.102.1, len 100, FIB policy rejected(no match) - normal forwarding


ISP1
*Mar 1 00:41:28.735: IP: tableid=0, s=192.168.1.2 (Serial0/2), d=10.1.102.1 (Serial0/2), routed via RIB
*Mar 1 00:41:28.735: IP: s=192.168.1.2 (Serial0/2), d=10.1.102.1 (Serial0/2), len 100, rcvd 3
*Mar 1 00:41:28.739: IP: tableid=0, s=10.1.102.1 (local), d=192.168.1.2 (Serial0/2), routed via FIB
*Mar 1 00:41:28.739: IP: s=10.1.102.1 (local), d=192.168.1.2 (Serial0/2), len 100, sending


Alles werkt dus naar behoren. Nu telnet 10.1.102.1 80
Host
Host#telnet 10.1.102.1 80
Trying 10.1.102.1, 80 ...
% Connection timed out; remote host not responding


PBR
*Mar 1 12:27:51.572: IP: s=192.168.1.2 (FastEthernet0/0), d=10.1.102.1, g=10.1.101.1, len 44, FIB policy routed


En voor de rest niks op ISP1 of ISP2.. Het lijkt haast alsof PBRouter de verkeer gewoon dropt?

  • jvanhambelgium
  • Registratie: April 2007
  • Laatst online: 30-11 14:23
Hmm, da's behoorlijk weinig output eigenlijk op de PBR-router qua debug...
*wat* stond er eigenlijk van debugging op ?

Zet ne keer "debug all" aan op de PBR-router ? Er *moet* toch nog iets meer uitkomen niet ?

  • Pauwl
  • Registratie: September 2001
  • Laatst online: 12:03
De policy staat op de fastethernet van de pbr router.
Wat gebeurt er als je vanaf de pbr router zelf telnet naar poort 80 naar 102.1? Gaat dat wel goed?

Wat je ook nog kan proberen is ipv interfaces als next-hop te definieren gewoon het ipv4 adres. Misschien dat er wat fout gaat met een arp request oid. Kun je ook nog even debugging op aangooien.

[ Voor 39% gewijzigd door Pauwl op 04-11-2012 21:56 ]


  • jvanhambelgium
  • Registratie: April 2007
  • Laatst online: 30-11 14:23
Pauwl schreef op zondag 04 november 2012 @ 21:54:
De policy staat op de fastethernet van de pbr router.
Wat gebeurt er als je vanaf de pbr router zelf telnet naar poort 80 naar 102.1? Gaat dat wel goed?

Wat je ook nog kan proberen is ipv interfaces als next-hop te definieren gewoon het ipv4 adres. Misschien dat er wat fout gaat met een arp request oid. Kun je ook nog even debugging op aangooien.
Denk eraan dat "by default" gegenereerde packets op de PBR-router *NIET* door de PBR-policy gaan geprocessed worden.

Om dit toch te doen zou er ook op de PBR-router een lijntje in de config moeten bijkomen ;

ip local policy route-map 10

...dan pas zou je vanop de PBR-router zelf soortgelijke test mogen doen...
Is wel valid voor IOS 12.2 , dus ik weet niet of die in latere IOS'ses anders is aangepakt.

  • ik222
  • Registratie: Maart 2007
  • Niet online
Doet het device 'ISP 2' uberhaupt aan routing? En hoe zit de route tabel er daar exact uit? Gezien het feit dat de ABRR router ander verkeer gewoon meldt lijkt het mij bijna dat het verkeer nooit terug komt op de ABRR router.

Overigens los van dit alles bouw je wel een vrij vreemde situatie als je 'ISP 's' hebt met een default route terug naar de klant :P

Verwijderd

Topicstarter
Mensen dank, waardeer jullie hulp en reacties.

Ik heb even het netwerk enigszins aangepast. EIGRP draait nu op alle routers (behalve host 0.0.0.0/0 richting PBR). Een kleine output.

PBR.
10.0.0.0/24 is subnetted, 2 subnets
C 10.1.102.0 is directly connected, Serial0/1
C 10.1.101.0 is directly connected, Serial0/0
C 192.168.1.0/24 is directly connected, FastEthernet0/0

router eigrp 1
network 10.1.101.2 0.0.0.0
network 10.1.102.2 0.0.0.0
network 192.168.1.1 0.0.0.0
no auto-summary

PBR#show run | sec access-list
access-list 101 permit tcp any any eq www

PBR#sh run | sec route-map
ip policy route-map wwwISP1
route-map wwwISP1 permit 10
match ip address 101
set ip next-hop 10.1.101.1

ISP1.
ISP1#show run | sec eigrp
router eigrp 1
network 10.1.101.1 0.0.0.0
no auto-summary

Gateway of last resort is not set

10.0.0.0/24 is subnetted, 2 subnets
D 10.1.102.0 [90/2681856] via 10.1.101.2, 00:19:10, Serial0/0
C 10.1.101.0 is directly connected, Serial0/0
D 192.168.1.0/24 [90/2195456] via 10.1.101.2, 00:19:10, Serial0/0

ISP2.
ISP2#sh run | sec eigrp
router eigrp 1
network 10.1.102.1 0.0.0.0
no auto-summary

10.0.0.0/24 is subnetted, 2 subnets
C 10.1.102.0 is directly connected, Serial0/0
D 10.1.101.0 [90/2681856] via 10.1.102.2, 00:19:57, Serial0/0
D 192.168.1.0/24 [90/2195456] via 10.1.102.2, 00:20:03, Serial0/0


Iedereen en alles kan elkaar nu bereiken. We proberen dan nogmaals.

Host#telnet 10.1.101.1 80
Trying 10.1.101.1, 80 ... Open

PBR#*Mar 1 00:26:21.015: IP: s=192.168.1.2 (FastEthernet0/0), d=10.1.101.1, len 44, FIB policy match
*Mar 1 00:26:21.015: IP: s=192.168.1.2 (FastEthernet0/0), d=10.1.101.1, g=10.1.101.1, len 44, FIB policy routed

ISP1 #*Mar 1 00:26:21.671: IP: tableid=0, s=192.168.1.2 (Serial0/0), d=10.1.101.1 (Serial0/0), routed via RIB *Mar 1 00:26:21.675: IP: s=192.168.1.2 (Serial0/0), d=10.1.101.1 (Serial0/0), len 40, rcvd 3

Dit werkt nogmaals. Nu de telnet naar ISP2...

Host#telnet 10.1.102.1 80
Trying 10.1.102.1, 80 ... Open

PBR# *Mar 1 00:29:29.047: IP: s=192.168.1.2 (FastEthernet0/0), d=10.1.102.1, len 40, FIB policy match *Mar 1 00:29:29.047: IP: s=192.168.1.2 (FastEthernet0/0), d=10.1.102.1, g=10.1.101.1, len 40, FIB policy routed

ISP2
*Mar 1 00:29:29.355: IP: tableid=0, s=192.168.1.2 (Serial0/0), d=10.1.102.1 (Serial0/0), routed via RIB
*Mar 1 00:29:29.355: IP: s=192.168.1.2 (Serial0/0), d=10.1.102.1 (Serial0/0), len 40, rcvd 3

Hier dus wel gelukt! Begrijp ik het goed, dat de telnet sessie eerst door PBR wordt doorverwezen naar ISP1, die het vervolgens doorzet naar ISP2? Want als ik dit doe:
Host#traceroute 10.1.102.1 port 80

Type escape sequence to abort.
Tracing the route to 10.1.102.1

1 192.168.1.1 28 msec 28 msec 16 msec
2 10.1.102.1 20 msec * 52 msec

Dan geeft ie dat niet weer. Het springt van 1.1 (fa0/0 van PBR) door naar 102.1 (ISP2). Denk dus dat de PBR niet eens het packet omzet naar 101.1? Weet iemand trouwens wat de g betekent in policy debug?
Mar 1 00:29:29.047: IP: s=192.168.1.2 (FastEthernet0/0), d=10.1.102.1, g=10.1.101.1, len 40.
Heb dat net even terug gelezen: "g= IP gateway address of the packet being routed." ?. Dus dit zegt niet per definitie dat het pakket die kant op gestuurd, slechts dat de 101.1 de "gateway" is?

@ik222. Hehe, ja opzet is erg vaag. Ik heb net ook even de 902 lab erbij gepakt, de path cantrol sim gedaan en gelijk alles werkend. Ik kan er alleen niet tegen als iets vast blijft zitten in mn hoofd. Het feit dat de destination pakket niet wijzigd, was iets wat ik inderdaad over het hoofd zag. Doch, ik vraag me af wat PBR nu doet met het pakket destined voor 102.1.. hij lijkt het gewoon te routen naar 102.1. Dus in feiten negeert hij de PB routing.. maar zelf beweert ie iets anders (output debug).

  • Freeaqingme
  • Registratie: April 2006
  • Laatst online: 11:47
Weet iemand trouwens wat de g betekent in policy debug?
Mar 1 00:29:29.047: IP: s=192.168.1.2 (FastEthernet0/0), d=10.1.102.1, g=10.1.101.1, len 40.
Wilde gok:
s = source
d = destination
g = gateway?

No trees were harmed in creating this message. However, a large number of electrons were terribly inconvenienced.


  • Equator
  • Registratie: April 2001
  • Laatst online: 28-11 20:09

Equator

Crew Council

#whisky #barista

Move naar Netwerken

Verwijderd

Topicstarter
Solved!

Heb maar even een andere test omgeving opgezet. Scenario: Er is via EGIRP complete verbinding tussen alle netwerk apparaten. Netwerk opzet is zoals hierboven (tekening).

Nu: Client 1 > mag alleen naar ISP2.

PBR#show ip access-list
Extended IP access list client1
10 permit ip host 192.168.1.2 any (18 matches)

PBR#show route-map
route-map policy, permit, sequence 10
Match clauses:
ip address (access-lists): client1
Set clauses:
ip next-hop 10.1.102.1
Policy routing matches: 12 packets, 720 bytes

Vanaf Host (192.168.1.2) naar ISP1.
Tracing the route to 10.1.101.1

1 192.168.1.1 60 msec 32 msec 20 msec
2 10.1.102.1 24 msec 20 msec 16 msec
3 10.1.102.2 24 msec 20 msec 16 msec
4 10.1.101.1 20 msec * 20 msec

Hiermee is het verhaal bevestigd! Host stuurt een ping richting ISP1. PBrouter kent echter de config om alle requests van Host door te sturen naar ISP2. Dat doet ie dan ook! Het pakket komt aan bij ISP2, deze kijkt in de header en ziet d=101.1. Het pakket wordt teruggestuurd naar PBR serial interface (102.2), en deze route het nu (gezien daar (op de serial) geen policy is aangebracht) het pakket door naar 101.1 (ISP1).

Nog altijd raar waarom de telnet 80 requests van de eerder ondernomen pogingen niet doorkwamen.. maar begrijp het eindelijk! Na 10 uur lang zoeken en met dank aan de reacties hier zijn we eruit! Mijn dank mensen! Jullie reacties/hulp zeer op prijs gesteld d:)b

Gr, Kek.

  • ik222
  • Registratie: Maart 2007
  • Niet online
Goed dat je zelf het antwoord op je laatste vraag al gevonden hebt :)
Pagina: 1