[ROUTER] Vreemd probleem....

[seq_uence]

[SPECS]
2 locaties met een 2 Mb huurlijn, aan beide zijden een Cisco 26** router.
Netwerk bestaat uit 2 VLAN's, 1 voor telefonie en 1 voor data.

Lokatie 1: router 10.254.18.227 PBX: 172.16.1.2
Lokatie 2: router 192.168.0.253 PBX: 172.16.2.2

Deze config heeft altijd gewerkt.

[PROBLEEM]

Donderdag tegen de middag ligt de verbinding tussen lokatie 1 en 2 plat, na wat speurwerk door de leverancier (zelf was ik op vakantie) was het oordeel dat de interfacekaart van de router op lokatie 2 stuk was.

Kaartje vervangen maar geen verbinding, uiteindelijk is de verbinding weer tot stand gebracht door 2 extra routes in de router op te nemen voor data en telefonie, nl. deze:

router lokatie 1:

192.168.0.253 225.255.255.0 172.16.10.20 (= interface huurlijn lokatie 2)
172.16.2.0 255.255.255.0 172.16.10.20

router lokatie 2:

10.254.18.227 255.255.255.0 172.16.10.10 (= interface huurlijn lokatie1)
172.16.1.0 255.255.255.0 172.16.10.10


Na invoeren van deze routes is de data en telefonieverbinding weer in de lucht, alleen is het mij een raadsel waarom het voorheen niet meer werkte, er is nl. voor dat het probleem ontstond niets veranderd aan de config van de routers.

Ik hoop dat iemand een suggestie heeft, het probleem is nu wel opgelost maar ik weet nog steeds de oorzaak niet.

[Verwijderd]

iets met de ARP tables misschien?

[CmdrKeen]

Ik heb onlangs ook een *heel* vreemd WAN-probleem gehad. Zelfde opstelling, alleen DSL i.p.v. huurlijnen. Eén van de netwerken zat in de 192.168.*.*-reeks en een ander netwerk in de 10.*.*.*-reeks, beide een 255.255.255.0-netmask.

Het probleem was opgelost toen de 10.*.*.*-reeks omgenummerd werd naar 192.168.*.* (wel ander subnet dan andere vestiging).

Ik weet niet of het een praktische tip is (waarschijnlijk istie zelfs niet praktisch uitvoerbaar omdat je je de downtime niet kan permitteren), maar hier is het: zet al je netwerken in 192.168.*.* en al je routers in 10.*.*.*. Verwijder dan de "nieuwe" routes die eerst niet nodig waren en kijk wat er blijft werken.

[seq_uence]

Omnummeren is geen optie, en het werkt nu ook allemaal weer. Maar wat ik niet snap is het feit dat een goed werkende config ineens niet meer werkt zonder dat er iets veranderd is en zonder dat er hardware stuk is.
Dus ook zonder de extra routes zou het moeten werken, maar dat is nu dus niet meer het geval.

Wel zit in de router op lokatie 2 nog het nieuwe interfacekaartje, maar dat had geen effect dus die gaan we dinsdag weer vervangen. Of zou dat er toch nog iets mee te maken hebben ?

Want hoe weet een router dan de weg zonder de ingegeven routes die we nu hebben toegevoegd ?

[Verwijderd]

Zoals hezik zei is het hoogstwaarschijnlijk de arp cache.

[seq_uence]

Verwijderd schreef op 02 november 2002 @ 16:28:
Zoals hezik zei is het hoogstwaarschijnlijk de arp cache.

Weet ik dus niet zoveel van, maar wat ik wel weet is dat die routers wel eens eerder down zijn geweest zonder problemen.

Hoe kan die ARP cache dan verdwijnen uit de router ?

[Verwijderd]

Is met een bepaald interval te configureren, meestal iets van 4 uur. Nu kan je hem ook handmatig flushen......als je al niet weet hoe je de ARP CACHE moet flushen weet je blijkbaar ook niet zo veel van routers.

[Verwijderd]

Het zou me niets verbazen dat als je die routes nu weghaalt dat dan het zaakje nog steeds werkt..

Waar het om gaat is dat je een andere interface (=ander MAC adres) geplaatst is..

(er is dus wel iets veranderd)

[seq_uence]

Verwijderd schreef op 02 november 2002 @ 16:39:
Het zou me niets verbazen dat als je die routes nu weghaalt dat dan het zaakje nog steeds werkt..

Waar het om gaat is dat je een andere interface (=ander MAC adres) geplaatst is..

(er is dus wel iets veranderd)

Dat gaan we dinsdagavond nog eens proberen.
Het MAC adres zal inderdaad veranderd zijn, maar dat kaartje is vervangen omdat men dacht dat ie stuk was.

Stel dat het oude kaartje er weer in zit, ik haal de routes weg en reload de routers en alles werkt. Wat heeft dan het probleem veroorzaakt ?

[seq_uence]

Verwijderd schreef op 02 november 2002 @ 16:37:
Is met een bepaald interval te configureren, meestal iets van 4 uur. Nu kan je hem ook handmatig flushen......als je al niet weet hoe je de ARP CACHE moet flushen weet je blijkbaar ook niet zo veel van routers.

Weet ik inderdaad niet zoveel van, heb ik ook niet genoeg tijd voor. Maar gelukkig weet ik van een heleboel andere zaken wel genoeg.

Of weet jij wel alles ?

[Verwijderd]

Eh, je begrijpt het niet helemaal..

Als je nu die routes weghaalt zal het hoogstwaarschijnlijk gewoon werken.

Hoe het (ongeveer) zit:

Die router onthoudt dat bij een bep. adres een MAC adres hoort. Jij haalt het oude kaartje er uit en stopt er een nieuwe met een ander MAC in. Dan is die router (dus) in de war. Waarsch. heeft het toevoegen van die route als effect gehad dat hij z'n arp-cache leegde, en dus was je probleem opgelost. Als je nu het oude kaartje terugplaatst zal het (dus) weer niet werken, vanwege dezelfde reden. Zet je het oude kaartje terug en haal je de routes weg en het werkt, zegt nog niets. Omdat het weghalen van die routes best een trigger kan zijn om je ARP cache te legen.

De clou is dat er wel degelijk iets veranderd is: er zit een ander kaartje in, waardoor het MAC gewijzigd is. Dat is gelijk de enige wijziging (althans, als je verhaal volledig is). De fout kan dus alleen daar zitten. Zit de fout ergens anders dan is er toch iets anders ook gewijzigd.

[seq_uence]

Ja ok hezik, dat is gewijzigd. Maar als je mijn verhaal leest zijn de problemen al begonnen voordat het kaartje is vervangen, het kaartje is toen vervangen omdat men dacht dat die stuk was en dat daardoor de verbinding down was.
Maar dat bleek niet het geval, dus wat kan er dan oorspronkelijk mis zijn gegaan waardoor de verbinding down was.......

En hoe weet die router dan z'n 'gateway' als je geen static routes hebt ingevoerd ?

[Verwijderd]

a) misschien was het kaartje wel echt kapot?

b) er zijn diverse mogelijkheden waarop een router er achter kan komen wat de route moet zijn. Over routerprotocollen kun je boeken vol schrijven, sterker nog, dat is al gebeurd

//edit

Maar dat bleek niet het geval,

deze conclusie is niet terecht. Gebaseerd op je verhaal valt niet te zeggen of dat kaartje echt kapot was of niet. Probeer even te doorgronden wat ik je vertel, je zult dan zien dat het goed mogelijk is dat het kaartje echt kapot is, vervangen wordt door een wel werkende en dat het dan nog steeds niet werkt.

[seq_uence]

Ok hezik, ik zie nu wat je bedoeld. Het kaartje zou stuk kunnen zijn, maar door het vervangen is de chache geflushed en weet de router de weg niet meer. De static routes die toegevoegd zijn lossen dat op, als ik deze weghaal staan ze nog in de cache en dus blijft het gewoon werken. (tenminste dat zou goed mogelijk zijn)

Zie ik het zo goed ?


Nog een vraag, met welk commando kun je op de router de cache opvragen, of is dat niet mogelijk ? En kun je dan ongestraft de arp-cache flushen ?

[Verwijderd]

Ok hezik, ik zie nu wat je bedoeld. Het kaartje zou stuk kunnen zijn, maar door het vervangen is de chache geflushed en weet de router de weg niet meer. De static routes die toegevoegd zijn lossen dat op, als ik deze weghaal staan ze nog in de cache en dus blijft het gewoon werken. (tenminste dat zou goed mogelijk zijn)

Zie ik het zo goed ?

ehh.. nee

Je kaartje is kapot en vervangen maar in de ARP cache van de andere router staat aan het IP van deze router nog het MAC adres van het oude kaartje gebonden. Door het toevoegen van de routes (dit is hypothetisch overigens, dit stuk weet ik niet zeker) is de ARP cache geflushed en je probleem opgelost. De static routes zelf voegen waarsch. niets toe.

Nog een vraag, met welk commando kun je op de router de cache opvragen, of is dat niet mogelijk ? En kun je dan ongestraft de arp-cache flushen ?

[/quote]

Voor het commando moet je even in de manual kijken (ken niet de IOS commandoset uit m'n hoofd). Je kunt 'm idd ongestraft flushen.

[seq_uence]

Ok mensen, bedankt voor de reakties, meer info is natuurlijk altijd welkom !

[Verwijderd]

Even voor alle duidelijkheid: ik zeg niet dat dit perse het probleem moet zijn. Dit is echter wel het eerste waar ik naar zou kijken..

[seq_uence]

Verwijderd schreef op 02 november 2002 @ 23:21:
Even voor alle duidelijkheid: ik zeg niet dat dit perse het probleem moet zijn. Dit is echter wel het eerste waar ik naar zou kijken..

Snap ik hezik, wat ik niet snap is dat de leverancier hier met geen woord over heeft gerept. Ga ik nog eens naar vragen.

[seq_uence]

Nog een aanvulling, in 1e instantie is alleen voor de data een static route toegevoegd. Daarna werkte de telefonie nog steeds niet, die ging weer werken nadat ook daar een static route voor was toegevoegd.

De stelling dat de ARPcache geflushed wordt door toevoegen van een static route lijkt me dus niet juist.......

[seq_uence]

Nou gisteren de oude interface kaart weer teruggezet, mankeert niets aan. Het vreemde is dat de verbinding alleen werkt met de toegevoegde routes terwijl deze er voorheen niet in stonden.

Ik vermoed dat de storing in 1e instantie door de huurlijn van KPN veroorzaakt is, in de router kon je nl. zien dat ie 'line down' aangaf. KPN zegt zelf dat er niets aan de hand is en was met die lijn....

Maar waarom werkt het dan nu niet zonder de routes, via EIGRP zouden de routers elkaar moeten vinden maar ook daar zie je bij Neigbors geen entry's staan die 'de andere kant' kenbaar maken.

Wie o wie heeft nog een suggestie ?

[Verwijderd]

Is KPN gaan filteren?