1. Welkom op het onafhankelijke Ziggo Gebruikersforum. Een forum voor en door gebruikers van Ziggo.
    Registreer je gratis om direct zelf berichten te plaatsen en gebruik te maken van extra functies!
    Verberg deze melding

Cisco 1841 router + Ziggo Internet (voorheen @Home Tilburg)

Discussie in 'Internet - Eigen netwerk' gestart door groenleer, 7 jul 2009.

Niet open voor verdere reacties.
  1. Allen,

    Ik zit met een probleem op een Cisco 1841 router.

    De router beschikt over 2 FastEthernet interfaces. FastEthernet 0/0 is gekoppeld aan het modem van Ziggo.
    FastEthernet 0/1 is opgesplits in vlans en gekoppeld aan een Cisco switch.

    Het hele vlan gebeuren werkt perfect.
    Echter de wan interface (FastEthernet 0/0) kan geen ip adres verkrijgen vanuit Ziggo.

    Ik heb al verschillende zaken geprobeerd maar vind steeds geen oplossing.

    Hoe ziet de config er uit?
    interface fastEthernet 0/0
    stukjes uit de config:
    Code:
    interface FastEthernet0/0
     description Interface to the World Wide Web (Internet) Aquirer IP thru DHCP!$FW_OUTSIDE$
     ip dhcp client hostname {hostname_here}
     ip dhcp client client-id hex 01000AE44E6DF2
     ip address dhcp
     ip access-group 103 in
     no ip redirects
     no ip proxy-arp
     ip nat outside
     ip inspect SDM_LOW out
     ip virtual-reassembly
     speed auto
     full-duplex
     ipv6 nd suppress-ra
     no ipv6 mld router
     no ipv6 pim
     no keepalive
     no cdp enable
     no mop enabled
    
    Ik heb de hostname ingesteld op de hostname zoals verkregen vanuit Ziggo & @Home.
    Het client id is het MAC-adres van de oude breedbandrouter, met 01 er voor.
    01 dient er voor om aan te geven dat het om een Hardware Ethernet interface gaat.
    Een DHCP request vanuit Windows XP plaats ook 01 voor het mac adres in de aanvraag!

    Om twijfel te voorkomen over de filtering regels die actief zijn, hierbij access-list 103:

    Code:
    access-list 103 permit tcp any any eq ftp-data
    access-list 103 permit tcp any any eq ftp
    access-list 103 permit udp host yyy.yyy.yyy.yyy eq domain any
    access-list 103 permit udp host zzz.zzz.zzz.zzz eq domain any
    access-list 103 permit udp host www.www.www.www eq domain any
    access-list 103 remark Auto generated by SDM for NTP (123) xxx.xxx.xxx.xxx
    access-list 103 permit udp host xxx.xxx.xxx.xxx eq ntp any eq ntp
    access-list 103 deny   ip 172.16.6.0 0.0.0.255 any
    access-list 103 deny   ip 172.16.5.0 0.0.0.255 any
    access-list 103 deny   ip 172.16.4.0 0.0.0.255 any
    access-list 103 permit udp any eq bootps any eq bootpc
    access-list 103 permit udp any eq bootpc any eq bootpc
    access-list 103 permit udp any eq bootps any eq bootps
    access-list 103 permit udp any eq bootpc any eq bootps
    access-list 103 permit icmp any any echo-reply
    access-list 103 permit icmp any any time-exceeded
    access-list 103 permit icmp any any unreachable
    access-list 103 deny   ip 10.0.0.0 0.255.255.255 any
    access-list 103 deny   ip 172.16.0.0 0.15.255.255 any
    access-list 103 deny   ip 192.168.0.0 0.0.255.255 any
    access-list 103 deny   ip 127.0.0.0 0.255.255.255 any
    access-list 103 deny   ip host 255.255.255.255 any
    access-list 103 deny   ip any any log
    
    de ip adressen www.www.www.www, yyy.yyy.yyy.yyy en zzz.zzz.zzz.zzz zijn 3 ipadressen van DNS servers.
    xxx.xxx.xxx.xxx is het ipadres van de XS4all ntp server.


    Wanneer ik de router met deze configuratie aansluit op een testnetwerk met een DHCP server krijg ik netjes een ip adres.
    Ongeacht of ik een reservation heb geplaatst op hostname, macadres of in zijn geheel niet.

    Wanneer ik de router koppel aan het modem dan verstuurt de router wel verschillende DHCP discover berichten, maar er komen geen offers terug vanuit Ziggo.
    Omdat ik het idee heb dat de dhcp aanvragen correct zijn heb ik het idee dat Ziggo op een bepaalde waarde filtert waardoor mijn requests niet bij de dhcp server terecht komen.

    Wanneer ik debug aan zet verschijnt het volgende:
    Code:
    *Jul  7 18:57:40.663: DHCP: QScan: Purging entry
    *Jul  7 18:57:40.663: DHCP: deleting entry 6451E5DC 0.0.0.0 from list
    *Jul  7 18:57:40.663: Temp IP addr: 0.0.0.0  for peer on Interface: FastEthernet0/0
    *Jul  7 18:57:40.663: Temp  sub net mask: 0.0.0.0
    *Jul  7 18:57:40.663:    DHCP Lease server: 0.0.0.0, state: 9 Purging
    *Jul  7 18:57:40.663:    DHCP transaction id: B97
    *Jul  7 18:57:40.663:    Lease: 0 secs,  Renewal: 0 secs,  Rebind: 0 secs
    *Jul  7 18:57:40.663:    No timer running
    *Jul  7 18:57:40.663:    Retry count: 0   Client-ID: 000a.e44e.6df2
    *Jul  7 18:57:40.663:    Client-ID hex dump: 000AE44E6DF2
    *Jul  7 18:57:40.663:    Hostname: cp********-a
    *Jul  7 18:58:09.985: DHCP: Try 25 to acquire address for FastEthernet0/0
    *Jul  7 18:58:09.997: DHCP: allocate request
    *Jul  7 18:58:09.997: DHCP: new entry. add to queue, interface FastEthernet0/0
    *Jul  7 18:58:09.997: DHCP: SDiscover attempt # 1 for entry:
    *Jul  7 18:58:09.997: Temp IP addr: 0.0.0.0  for peer on Interface: FastEthernet0/0
    *Jul  7 18:58:09.997: Temp  sub net mask: 0.0.0.0
    *Jul  7 18:58:09.997:    DHCP Lease server: 0.0.0.0, state: 1 Selecting
    *Jul  7 18:58:09.997:    DHCP transaction id: B98
    *Jul  7 18:58:09.997:    Lease: 0 secs,  Renewal: 0 secs,  Rebind: 0 secs
    *Jul  7 18:58:09.997:    Next timer fires after: 00:00:04
    *Jul  7 18:58:09.997:    Retry count: 1   Client-ID: 000a.e44e.6df2
    *Jul  7 18:58:09.997:    Client-ID hex dump: 000AE44E6DF2
    *Jul  7 18:58:09.997:    Hostname: cp********-a
    *Jul  7 18:58:09.997: DHCP: SDiscover placed class-id option: 4D53465420352E30
    *Jul  7 18:58:09.997: DHCP: SDiscover: sending 289 byte length DHCP packet
    *Jul  7 18:58:09.997: DHCP: SDiscover 289 bytes 
    *Jul  7 18:58:09.997:             B'cast on FastEthernet0/0 interface from 0.0.0.0
    *Jul  7 18:58:13.661: DHCP: SDiscover attempt # 2 for entry:
    *Jul  7 18:58:13.661: Temp IP addr: 0.0.0.0  for peer on Interface: FastEthernet0/0
    *Jul  7 18:58:13.661: Temp  sub net mask: 0.0.0.0
    *Jul  7 18:58:13.661:    DHCP Lease server: 0.0.0.0, state: 1 Selecting
    *Jul  7 18:58:13.661:    DHCP transaction id: B98
    *Jul  7 18:58:13.661:    Lease: 0 secs,  Renewal: 0 secs,  Rebind: 0 secs
    *Jul  7 18:58:13.661:    Next timer fires after: 00:00:04
    *Jul  7 18:58:13.661:    Retry count: 2   Client-ID: 000a.e44e.6df2
    *Jul  7 18:58:13.661:    Client-ID hex dump: 000AE44E6DF2
    *Jul  7 18:58:13.661:    Hostname: cp********-a
    *Jul  7 18:58:13.661: DHCP: SDiscover placed class-id option: 4D53465420352E30
    *Jul  7 18:58:13.661: DHCP: SDiscover: sending 289 byte length DHCP packet
    *Jul  7 18:58:13.661: DHCP: SDiscover 289 bytes 
    *Jul  7 18:58:13.661:             B'cast on FastEthernet0/0 interface from 0.0.0.0
    *Jul  7 18:58:17.661: DHCP: SDiscover attempt # 3 for entry:
    *Jul  7 18:58:17.661: Temp IP addr: 0.0.0.0  for peer on Interface: FastEthernet0/0
    *Jul  7 18:58:17.661: Temp  sub net mask: 0.0.0.0
    *Jul  7 18:58:17.661:    DHCP Lease server: 0.0.0.0, state: 1 Selecting
    *Jul  7 18:58:17.661:    DHCP transaction id: B98
    *Jul  7 18:58:17.661:    Lease: 0 secs,  Renewal: 0 secs,  Rebind: 0 secs
    *Jul  7 18:58:17.661:    Next timer fires after: 00:00:04
    *Jul  7 18:58:17.661:    Retry count: 3   Client-ID: 000a.e44e.6df2
    *Jul  7 18:58:17.661:    Client-ID hex dump: 000AE44E6DF2
    *Jul  7 18:58:17.661:    Hostname: cp********-a
    *Jul  7 18:58:17.661: DHCP: SDiscover placed class-id option: 4D53465420352E30
    *Jul  7 18:58:17.661: DHCP: SDiscover: sending 289 byte length DHCP packet
    *Jul  7 18:58:17.661: DHCP: SDiscover 289 bytes 
    *Jul  7 18:58:17.661:             B'cast on FastEthernet0/0 interface from 0.0.0.0
    *Jul  7 18:58:21.660: DHCP: QScan: Timed out Selecting state%Unknown DHCP problem.. No allocation possible
    *Jul  7 18:58:30.476: DHCP: Waiting for 60 seconds on interface FastEthernet0/0
    
    Iemand die een idee heeft waar dit probleem hem in zou kunnen zitten?
     
  2. Prob is misschien dat Ziggo niet meer met een hostname werkt misschien, ik had jaren dezelfde, maar sinds een maand of 4 niet meer.
    Mocht ik ernaast zitten excuses, daar de rest algebra is voor mij :wink:

    edit: op http://watismijnip.nl/ kan je checken of je h-name hetzefde is gebleven.
     
  3. Ik denk, maar dat weet ik natuurlijk niet zeker, dat je je vergist.

    Mijn hostnaam, dat is de cp**** of cc**** code die je moet opgeven als computernaam, is wel degelijk van belang. De helpdesk wil nog wel eens adviseren om die van -a naar -b of zelfs -c over te zetten.
    Daarna wordt je een ander ip-adres toegewezen.

    Het ip-adres is het dynamische deel in dit verhaal en kan van dag tot dag verschillen. Hoewel het maar sporadisch voorkomt dat Ziggo deze wijzigt.

    Het vreemde in dit geheel is dat er wel een DHCP discover verstuurd wordt maar er nooit een offer terug komt.

    Als ik de zelfde opstelling neem, maar inplaats van de router een willekeurige pc (linux, windows) aansluit met de correcte hostnaam, werkt het wel.
    Ik kan ook gewoon 5 keer van apparaat wisselen, het is dus niet zo dat het modem filtert op mac-adressen in mijn ogen.
     
  4. Toch wordt de hostnaam niet meer gebruikt bij Ziggo. Het ip-adres wat je krijgt is afhankelijk van het MAC adres van de pc of router die je aansluit. De DHCP server koppelt dat aan je ip-adres. Wijzig je het mac-adres door een andere pc aan te sluiten, moet je eerst het modem resetten en daarna zal de pc of router een ander ip-adres krijgen dan wat je daarvoor had.
     
  5. Dan blijft het vreemd dat ik nog steeds een andere pc rechtstreeks achter het modem kan hangen zonder het modem te resetten. Deze pc's hebben geen gekloond mac adres maar maken gebruik van een cphostnaam. Zonder de cphostnaam krijg ik namelijk geen ip adres.

    Weten jullie zeker dat deze nieuwe methode overal in nederland werkt? Ik heb namelijk nog een vrij 'oud' kabelmodem. Circa 4 jaar.
     
  6. Ik heb voorlopig een vraag en een opmerking.
    Opmerking: Voor je nameservers permit je alleen udp. Nameservers gebruiken daarvoor vaak ook tcp.
    Vraag: Je denied expliciet de volgende blokken:
    access-list 103 deny ip 172.16.6.0 0.0.0.255 any
    access-list 103 deny ip 172.16.5.0 0.0.0.255 any
    access-list 103 deny ip 172.16.4.0 0.0.0.255 any
    Dit is een dubbeling van:
    access-list 103 deny ip 172.16.0.0 0.15.255.255 any
    Wat is daarmee je bedoeling?

    Mees de Roo
     
  7. Scherp gezien.

    172.16.4.0 172.16.5.0 en 172.16.6.0 zijn een aantal reeksen die ik hier gebruik. Test netwerkjes etc. Die heb ik expliciet er in gezet. de 172.16.0.0 komt via SDM van Cisco er in.

    TCP wordt als fallback pas gebruikt als UDP niet (meer) werkt voor DNS. Ik zou inderdaad TCP poort 53 ook open kunnen zetten.
     
  8. Maak ook even een (tijdelijke) extra entry:
    access-list 103 permit ip 192.168.100.0 255.255.255.0 any
    Het modem is zelf:
    http://192.168.100.1/
    en deelt onder bepaalde omstandigheden ip's uit het blok:
    192.168.100.0/24
    uit.
    Mogelijk hapert er onderweg iets; kijk daarvoor ook in het modem.
    Dat hostname statement kan hooguit problemen veroorzaken; Ziggo doet er in ieder geval niets mee.
    Die modem powerdown/up cyclus heeft overigens al veel mensen geholpen bij dit soort wisselingen van devices.
    Is die oude breedband-router trouwens niet meer beschikbaar voor vergelijkings-doeleinden, of had die een ingebouwd modem oid?

    Mees de Roo
     
Niet open voor verdere reacties.

Deel Deze Pagina