[Cisco] Bri interface blijkt up en down gaan

[Verwijderd]

Ik heb enige tijd een vaag probleem op mijn netwerk.

Situatie ik heb een cisco 2930 router waaraan 2 ISDN lijnen hangen. Bri 1/0 en 1/1. Bri0 is voor het inbellen op ander locaties, bri 1 is voor het internet gedeelte op mijn kantoor.
We hebben sinsds enige tijd ADSL omdat de internet kosten steeds maar toenamen en hadden dus verwacht dat de kosten van het internet zouden afnemen.

Helaas niet waar, ik zoeken en zoeken en er waren nog wel een paar dingen de gebruik maakten van de ISDN verbinding naar het internet. Die uitgeschakeld; en nog steeds waren de internet kosten via ISDN redelijk hoog.

Ga ik in mijn router kijken wat daar allemaal gebeurd krijg ik de volgende meldingen

code:

4d04h: %LINK-3-UPDOWN: Interface BRI1/1:1, changed state to up
4d04h: %DIALER-6-BIND: Interface BRI1/1:1 bound to profile Dialer1
4d04h: %ISDN-6-CONNECT: Interface BRI1/1:2 is now connected to 80793611011 80793
611011
4d04h: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI1/1:1, changed state t
o up
4d04h: %ISDN-6-CONNECT: Interface BRI1/1:1 is now connected to 80793611011
4d04h: %DIALER-6-UNBIND: Interface BRI1/1:1 unbound from profile Dialer1
4d04h: %ISDN-6-DISCONNECT: Interface BRI1/1:1  disconnected from 80793611011 , c
all lasted 181 seconds
4d04h: %LINK-3-UPDOWN: Interface BRI1/1:1, changed state to down
4d04h: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI1/1:1, changed state t
o down
4d04h: %LINK-3-UPDOWN: Interface BRI1/1:1, changed state to up
4d04h: %DIALER-6-BIND: Interface BRI1/1:1 bound to profile Dialer1
4d04h: %ISDN-6-CONNECT: Interface BRI1/1:1 is now connected to 80793611011
4d04h: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI1/1:1, changed state t
o up
4d04h: %ISDN-6-CONNECT: Interface BRI1/1:1 is now connected to 80793611011

wat houdt dit precies in en hoe kom ik eraf.
Kan ik bijvoorbeeld op een bepaalde manier debuggen om er achter te komen waar dit vandaan komt?

Wat dit betreft is mijn kennis behoorlijk basic en ben ik erg blij met cisco configmaker.

[ Voor 6% gewijzigd door Verwijderd op 21-11-2003 13:37 ]

[DJ]

Wat je hierboven ziet is dat de router toch nog aan het bellen is naar die ISP. Blijkbaar is er op die router nog ergens iets ingesteld dat hij daar naar toe moet bellen (DNS Server instellingen? Route statements?).

Post je configuratie hier eens (zonder passwords uiteraard). Dan kunnen we gaan kijken wat er nog verkeerd staat.

[Verwijderd]

Verwijderd schreef op 21 november 2003 @ 13:23:
Ik heb enige tijd een vaag probleem op mijn netwerk.

Situatie ik heb een cisco 2930 router waaraan 2 ISDN lijnen hangen. Bri 1/0 en 1/1. Bri0 is voor het inbellen op ander locaties, bri 1 is voor het internet gedeelte op mijn kantoor.
We hebben sinsds enige tijd ADSL omdat de internet kosten steeds maar toenamen en hadden dus verwacht dat de kosten van het internet zouden afnemen.

Helaas niet waar, ik zoeken en zoeken en er waren nog wel een paar dingen de gebruik maakten van de ISDN verbinding naar het internet. Die uitgeschakeld; en nog steeds waren de internet kosten via ISDN redelijk hoog.

Ga ik in mijn router kijken wat daar allemaal gebeurd krijg ik de volgende meldingen

code:

4d04h: %LINK-3-UPDOWN: Interface BRI1/1:1, changed state to up
4d04h: %DIALER-6-BIND: Interface BRI1/1:1 bound to profile Dialer1
4d04h: %ISDN-6-CONNECT: Interface BRI1/1:2 is now connected to 80793611011 80793
611011
4d04h: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI1/1:1, changed state t
o up
4d04h: %ISDN-6-CONNECT: Interface BRI1/1:1 is now connected to 80793611011
4d04h: %DIALER-6-UNBIND: Interface BRI1/1:1 unbound from profile Dialer1
4d04h: %ISDN-6-DISCONNECT: Interface BRI1/1:1  disconnected from 80793611011 , c
all lasted 181 seconds
4d04h: %LINK-3-UPDOWN: Interface BRI1/1:1, changed state to down
4d04h: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI1/1:1, changed state t
o down
4d04h: %LINK-3-UPDOWN: Interface BRI1/1:1, changed state to up
4d04h: %DIALER-6-BIND: Interface BRI1/1:1 bound to profile Dialer1
4d04h: %ISDN-6-CONNECT: Interface BRI1/1:1 is now connected to 80793611011
4d04h: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI1/1:1, changed state t
o up
4d04h: %ISDN-6-CONNECT: Interface BRI1/1:1 is now connected to 80793611011

wat houdt dit precies in en hoe kom ik eraf.
Kan ik bijvoorbeeld op een bepaalde manier debuggen om er achter te komen waar dit vandaan komt?

Wat dit betreft is mijn kennis behoorlijk basic en ben ik erg blij met cisco configmaker.

Waarom gooi je de dialer er gewoon niet uit als je hem toch niet meer gebruikt ?

[Verwijderd]

de config van nu

code:

Current configuration:
!
version 12.0
service timestamps debug uptime
service timestamps log uptime
service password-encryption
!
hostname hothok
!
enable secret .
enable password .
!
username hot125 password 7 ..
username hot087 password 7 ..
username hot110 password 7 ..
username hot112 password 7 ..
username hot122 password 7 ..
!
ip subnet-zero
ip name-server 194.109.6.66
ip name-server 194.109.9.99
!
ip inspect name Ethernet tcp
ip inspect name Ethernet udp
ip inspect name Ethernet smtp
ip audit notify log
ip audit po max-events 100
isdn switch-type basic-net3
isdn voice-call-failure 0
isdn tei-negotiation first-call
!
interface Ethernet0/0
 ip address 94.0.1.1 255.255.255.0
 no ip directed-broadcast
 ip nat inside
!
interface BRI1/0
 ip address 95.0.238.1 255.0.0.0
 no ip directed-broadcast
 ip nat inside
 encapsulation ppp
 no ip mroute-cache
 dialer idle-timeout 14
 dialer map ip 95.0.125.1 name hot125 tel
 dialer map ip 95.0.87.1 name hot087 tel
 dialer map ip 95.0.110.1 name hot110 tel
 dialer map ip 95.0.112.1 name hot112 tel
 dialer map ip 95.0.122.1 name hot122 tel
dialer-group 1
 isdn switch-type basic-net3
 compress stac
 ppp authentication chap
!
interface BRI1/1
 no ip address
 no ip directed-broadcast
 ip nat outside
 encapsulation ppp
 dialer pool-member 1
 isdn switch-type basic-net3
 isdn tei-negotiation first-call
 ppp authentication chap pap
!
interface BRI1/2
 no ip address
 no ip directed-broadcast
 encapsulation ppp
 dialer idle-timeout 300
 dialer-group 1
 isdn switch-type basic-net3
 ppp authentication chap

 (BRI 2 t/m7 zijn hetzelfde en voor het overzicht maar weggelaten)
!
interface Dialer1
 description verbinding naar ISP XS4ALL
 ip address 194.109.61.52 255.255.255.0
 no ip directed-broadcast
 ip nat outside
 encapsulation ppp
 dialer remote-name ISP
 dialer pool 1
 dialer idle-timeout 180
 dialer string 80793611011
 dialer hold-queue 10
 dialer load-threshold 180 outbound
 dialer-group 1
 no cdp enable
 ppp quality 50
 ppp authentication pap chap callin
 ppp pap sent-username [e-mail] password 7 ..
!
ip nat inside source list 1 interface Dialer1 overload
ip nat inside source static tcp 94.0.1.3 25 194.109.61.52 25 extendable
ip classless
ip route 0.0.0.0 0.0.0.0 Dialer1
ip route 94.0.87.0 255.255.255.0 95.0.87.1
ip route 94.0.110.0 255.255.255.0 95.0.110.1
ip route 94.0.112.0 255.255.255.0 95.0.112.1
ip route 94.0.122.0 255.255.255.0 95.0.122.1
ip route 94.0.125.0 255.255.255.0 95.0.125.1
no ip http server
!
access-list 1 permit any
access-list 10 permit 94.0.1.0 0.0.0.255
dialer-list 1 protocol ip permit
snmp-server engineID local 00090200E01E5D9EE0
snmp-server community public RO
!
line con 0
 exec-timeout 0 0
 transport input none
line aux 0
line vty 0 4
 access-class 10 in
 password 7 ..
 login
!
end

De dialer wil ik niet weghalen om dat er nog wel gebruik van gemaakt moet kunnen worden als de ADSL een keertje niet beschikbaar is.

[DJ]

Op regel 20 en 21 staan nog twee verwijzingen naar DNS Serevrs van XS4ALL. Als de router dus een hostnaam moet resolven zal hij dat met die DNS Servers willen doen. Hiervoor zal hij gaan inbellen. Haal die eens weg, of vervang ze door internet DNS Servers (als je die hebt).

[Rtificial]

Ik heb in het verleden dergelijke dingen nog wel eens kunnen oplossen door de threshold te verhogen, zodat ie minder snel gaat bellen...

[Verwijderd]

Ik ben wat vergeten er bij te zeggen. Iets wat niet geheel onbelangrijk is.......

Dit gebeurt 24/7 ongeveer om de 5 min.

Het is dus iets wat periodiek gebeurt ook als er geen users aanwezig zijn.

Ik wil dus eigenlijk ook weten of dit ergens anders dan van de router vandaan komt.

Ik kan namelijk niks meer verzinnen in mijn netwerk wat dit verkeer klan genereren!

[ Voor 32% gewijzigd door Verwijderd op 21-11-2003 17:03 . Reden: xtra uitleg ]

[Verwijderd]

Verwijderd schreef op 21 november 2003 @ 17:00:

Ik wil dus eigenlijk ook weten of dit ergens anders dan van de router vandaan komt.

Ik kan namelijk niks meer verzinnen in mijn netwerk wat dit verkeer klan genereren!

Wellicht je mail server?

'k zou iig beginnen de default route naar dialer1 er uit te halen en dan wat verder zoeken op cisco's website. Scheelt wat in de kosten.

Bestaat een 2930 router trouwens wel? Kan zo snel vrij weinig vinden.. oud model?

Mocht je adsl over isdn hebben dan is een 836 wellicht wel iets voor je, komt adsl direct op binnen en kun je eenvoudig failover configureren met de bri poort.

[Equator]

Je kan de default route natuurlijk ook via het IP adres van je ADSL router (indien aanwezig) laten lopen.
no ip route 0.0.0.0 0.0.0.0 dialer1
ip route 0.0.0.0 0.0.0.0 <ipadres adsl router>

Dan zal de router alle verbindingen waar hij voor naar internet wil gaan over de adsl lijn gooien.
Heb je geen adsl router, gooi dan gewoon de dns servers eruit, en verwijder de default route.

[Verwijderd]

Ik weet niet waar ik zat met me hoofd maar het is idd geen 2930 maar een 3600 serie router. X-cuses voor het eventuele ongemak.

Ik heb het volgende uitgevonden.

De mailserver had als backup de ISDN verbinding met het internet de route die daar instond had dezelfde metric als de ADSL verbinding. Aangepast en zo te zien gebeurt er niks meer.

Bedankt in iig voor de input.

Ik zou alleen nog wel willen weten of mogelijk was om te kijken waar de eventuele opdracht vandaan kwam.

Ik weet dat het de mailserver was maar ik zou toch wel willen weten hoe ik dit had kunnen debuggen

[teigetjuh]

Je kan een debug op je router aanzetten, maar als ik het zo lees lijkt het op je DNS, die die continu resolved. Je kan een dialer/Bri ook in shutdown zetten dan gaat ie niet meer bellen. Je hebt um dan eventueel weer heel snel werkend door een no shut.

[Mark]

Verwijderd schreef op 24 november 2003 @ 11:23:
Ik weet dat het de mailserver was maar ik zou toch wel willen weten hoe ik dit had kunnen debuggen

Dit had je kunnen debuggen met: debug dialer events & debug dialer traffic

[snakeye]

Je dailer word gewoon getrigged omdat er verkeer op je router binnenkomt en aangezien je 0.0.0.0 route naar je dialer (dus internet) wijst zal ie bij elke ip packetje waarvan de route niet bekend is gaan uitbellen. een simpele ping etc.. je moet dus ook zien uit te vissen welke verkeer je isdn triggerd.

Dit kan je bijvoorbeeld doen door ip accounting output packets aan te zetten op je Bri interface dan kan je in elk geval zien waar het vandaan komt.

(uitlezen met sh ip acco )

Tergelijkerrijd is het ook slim om bijvoorbeeld je dailer-list aan te passen zodat ie alleen gaat bellen als jij dat echt wil. Bijvoorbeeld:


dialer-list 1 ip permit list 100

access-list 100 permit tcp any any (triggered alleen bij een tcp sessie )

Dit kan je nog verfijnen voor verkeer vanaf een bepaalde host

access-list 100 permit tcp host xxx.xxx.xxx.xxx any

(gaat alleen uitbellen bij tcp verkeer vanaf een bepaalde host..

etc...

[Verwijderd]

super gaan we meteen doen!!!

[proza]

En al gevonden wie de "boosdoener" was Ben benieuwd naar je verhaal. Debug dialer event moet een oplossing hebben kunnen geven welk source IP adres de initiator is geweest van de ISDN call setup