Lasse Jarlskov skrev:
> Jeg ved ikke hvilket udstyr CPH-metronet bruger, men jeg har for
> nyligt (i denne måned) oplevet et meget lignende problem.
>
> Problemet lignede meget det du beskriver; efter 30 minutters
> inaktivitet, var der ingen forbindelse. Efter 3½ time uden
> forbindelse, var der pludselig forbindelse i en halv time igen.
>
> Forbindelsen kunne også genetableres af os ved at cleare arp-tabellen
> på den router, der terminerer ethernet-grænsesnittet ud mod
> ADSL-kunderne.
Lyder som samme problem jeg havde med en Cisco677, reboot var det
eneste, der hjalp.
> Problemet er opstået med kunder på Ericssons EDA-DSLAMer. Disse
> DSLAMer omskriver ethernet-MAC-adressen på alle pakker og har derfor
> en binding mellem den rigtige klients MAC-adresse og deres egen
> omskrevne. Denne binding varer åbenbart som default 30 minutter.
> Hvis denne binding ikke er i brug i 30 minutter, så timer den ud. Den
> kan genetableres indefra, men ikke udefra - meget som man kender det
> fra en dynamisk nat-entry.
> Den kan kun genetableres ved at en maskine hos kunden generer noget
> trafik.
>
> Broadcast-trafik på ethernet-niveau er dog ikke afhængig af denne
> binding og derfor kan man stadig sende broadcast-trafik til kundens
> maskiner. Det eneste trafik der på denne type forbindelse er gyldig
> broadcast-trafik på ethernet-niveau er arp-forespørgsler.
> I vores setup er den maskine der terminerer ethernet-grænsesnittet en
> cisco-router - her er arp-timeout som default 4 timer. Derfor begyndte
> det at virke af sig selv efter totalt 4 timers inaktivitet.
>
> Løsningen var ganske simpelt at sætte arp-timeout ned til en halv time
> på de interfaces der terminerer ADSL-kunder.
>
>
>
> Jeg ved ikke om du kan bruge denne historie til noget, eller om nogle
> teknikere hos CPH-metronet kan.
Jeg vil prøve at smide din posting til dem, så må vi se om det
hjælper noget.
> Hvis du stadig er interesseret, kan du evt. undersøge om nogle af
> disse tidsangivelser passer - får du evt. forbindelsen tilbage i ca.
> 30 minutters tid efter totalt 4 timers afbrydelse? Prøv evt. med andre
> værdier her.
jeg har sat et script op, der kører i samme interval som den time man
er i, dvs.
kl. 01 med 1 minuts interval
k. 02 med 2 minutters interval
osv
kl. 00.10 svares der ikke længere på ping, kl. 01 kører det som
smurt frem til kl. 06.30, hvor der igen ikke svares på ping en enkelt
gang. dvs. at det lugter af et 5 minutters timeout
Her er et udtræk af loggen:
Fri Jul 14 06:00:01 CEST 2006
Fri Jul 14 06:05:00 CEST 2006
Fri Jul 14 06:10:00 CEST 2006
Fri Jul 14 06:15:00 CEST 2006
Fri Jul 14 06:20:00 CEST 2006
Fri Jul 14 06:25:00 CEST 2006
Fri Jul 14 06:30:12 CEST 2006
1 81.7.149.193 0.343 ms
2 81.7.154.1 0.157 ms
3 192.38.7.75 0.590 ms
4 213.185.31.98 0.950 ms
5 213.185.31.101 0.989 ms
6 *
7 *
8 *
9 *
10 *
11 *
12 *
13 *
14 *
15 *
==========================================================
Fri Jul 14 06:35:00 CEST 2006
Fri Jul 14 06:40:01 CEST 2006
Fri Jul 14 06:45:00 CEST 2006
Fri Jul 14 06:50:01 CEST 2006
Fri Jul 14 06:55:00 CEST 2006
Fri Jul 14 07:00:10 CEST 2006
1 81.7.149.193 0.344 ms
2 81.7.154.1 0.155 ms
3 192.38.7.75 0.581 ms
4 213.185.31.98 0.952 ms
5 213.185.31.101 1.019 ms
6 *
7 *
8 *
9 *
10 *
11 *
12 *
13 *
14 *
15 *
==========================================================
Fri Jul 14 07:05:00 CEST 2006
Fri Jul 14 07:10:00 CEST 2006
Fri Jul 14 07:15:00 CEST 2006
Fri Jul 14 07:20:08 CEST 2006
1 81.7.149.193 0.350 ms
2 81.7.154.1 0.170 ms
3 192.38.7.75 0.554 ms
4 213.185.31.98 0.859 ms
5 213.185.31.101 0.952 ms
6 *
7 *
8 *
9 *
10 *
11 *
12 *
13 *
14 *
15 *
==========================================================
Fri Jul 14 07:25:01 CEST 2006
Når datoen står alene, så er det fordi ping har fået svar, ===
afslutter en trace til 213.185.8.12
Der er mere loginfo her, hvis det har din interesse:
http://emax.dk/~emax/ping.log
> Kan du evt. få opsnuset hvilken type DSLAM CPH-metronet benytter?
Jeg kan jo spørge
--
Take Care
Kim Emax