Automatische toegewezen IP adressen vallen buiten de range

[Gait]

Sinds gisteren krijgen al mijn apparaten een IP adres toegewezen die niet in de goede range vallen.
Nu heb ik de meeste apparaten een statisch IP gegeven dus dat is niet echt een probleem, maar voor een aantal dingen wil/kan ik dit niet. (Namelijk m'n netbook en twee UPC settop boxen)

Hieronder zie je hoe mijn router is ingesteld:


Hieronder zie je hoe mijn PC zijn IP automatisch toegewezen krijgt en waarbij het netwerk niet gevonden wordt:


Hieronder zie je hoe het wel werkt met een statisch IP adres:


Wanneer een apparaat automatisch een IP adres krijgt toegewezen zou dit dus tussen 192.168.1.100/255 moeten zijn. Wat doe ik verkeerd? Zelf heb ik eigenlijk niks gewijzigd opeens werkte het niet meer.
Heb de router en de switch beiden al even zonder stroom laten staan, maar het mocht niet baten.

[ Voor 4% gewijzigd door Gait op 31-12-2010 14:05 . Reden: Verkeerde plaatje ]

[Onbekend]

Heb je je router en modem wel goed aangesloten?
Het ip-adres 192.168.100.1 lijkt wel van de (Ziggo) modem te komen.

[Nielson]

Je hebt ws nog een dhcp server in je netwerk. Probeer eens het adres http://192.168.100.1 te openen.

[Slurpgeit]

Het lijkt erop dat er een apparaat met IP 192.168.100.1 actief is in het netwerk die de adressen uitdeelt, ipv de router waar je nu in zit met 192.168.1.1.

[strandbal]

Het lijkt me sterk dat dit door je Linksys komt. Het lijkt er eerder op dat er ergens in je netwerk iets anders IP adressen uit zit te delen. Wat heb je allemaal aan je LAN hangen? NAS? Accesspoint?

[Gait]

Dat zal dan waarschijnlijk de 3COM switch zijn zou dit kunnen?

Mijn netwerk zit er als volgt uit:

Linksys WAG200G modem/router ------> 3COM switch

Aan de router zit enkel de switch en de Set top box van UPC die wel een een goed adres krijgt toegewezen.
Een laptop en netbook zitten hier draadloos op en deze vinden zelf ook geen netwerk.

En aan de switch zit het volgende:
PC, TV, UPC set top box, PS3, Xbox 360, TV, HTPC

En als ik met IPscan scan dan vind hij inderdaad wat op 192.168.100.1

Maar ik kan niet vinden hoe ik mijn switch kan benaderen.

[Petervanakelyen]

Gewoon surfen naar 192.168.100.1? Of gebruik nmap op te zien of er nog wat anders op die switch open staat (poort 443 - SSL, 22/23 - SSH/Telnet,...). Het hoeft overigens niet per se de switch te zijn. Een PC waar een DHCP-server op draait, je TV,... je zou er nog van kunnen verschieten hoeveel apparaten zo'n features zouden kunnen hebben.

[ Voor 39% gewijzigd door Petervanakelyen op 31-12-2010 14:41 ]

[Gait]

Ik heb nu alle netwerk kabels eruit zit met m'n netbook op draadloos internet en IP scan blijft die 192.168.100.100 zien.
Ik kan deze niet benaderen als ik erna surf.
Dus het moet iets met mijn router zijn toch?

[Dido]

Het zou natuurlijk zelf een AP van de buren kunnen zijn...
Er zit iets op 192.168.100.1 dat IP-adressen uitdeelt, en volgens je router is het niet je router, want die zit op 192.168.1.1

Waar komt 192.168.100.100 opeens vandaan trouwens?

[burne]

Gait schreef op vrijdag 31 december 2010 @ 15:05:
Ik heb nu alle netwerk kabels eruit zit met m'n netbook op draadloos internet en IP scan blijft die 192.168.100.100 zien.
Ik kan deze niet benaderen als ik erna surf.
Dus het moet iets met mijn router zijn toch?

Ping dat 192.168.100.1 ip eens, en kijk daarna in je arp-tabel.

code:

arp -a

Als je de eerste 6 letters/cijfers van dat mac-adres hier even roept kunnen we misschien zien van welke fabrikant het apparaat is.

[Petervanakelyen]

Neem anders je netbook en hang die even apart aan alle apparaten die je op je switch hangen (switch inclusief). Ook niet zo praktisch, maar een oplossing als je het niet via netwerktooltjes wilt gaan doen.

[kluyze]

Kan je in de apparaten die de verkeerde dhcp nemen niet gewoon zelf een dhcp-server opgeven of een standaard gateway specificeren?

[Petervanakelyen]

Dat is een workaround, maar zeker geen oplossing. Er zijn talloze situaties waarbij het niet handig is om nog extra instellingen te moeten specifieren in een DHCP-configuratie.

[kluyze]

Kan je even uittekenen hoe je netwerk er uit ziet?

Als het goed is dan zou je switch geen ip adres mogen hebben, tenzij het zo een apparaat is dat stiekem toch meer is dan alleen een switch. Om een switch te configureren is er normaal een extra poort (com/usb) voorzien waar je rechtstreeks een pc aan moet hangen, dat werkt meestal niet met een web interface.

[dt77h]

als je naar 192.168.100.1 gaat krijg je als het goed is de webinterface van de upc settopbox.

[DukeBox]

Ik wist niet dat er UPC set-up boxen waren die aan je lan moesten hangen ?

[Petervanakelyen]

dt77h schreef op vrijdag 31 december 2010 @ 16:06:
als je naar 192.168.100.1 gaat krijg je als het goed is de webinterface van de upc settopbox.

Maar dat ding hoort normaalgezien geen IP-adressen uit te delen, toch?

[ Voor 59% gewijzigd door Petervanakelyen op 31-12-2010 16:08 ]

[Rob]

Waarom hangen de UPC settopboxen in het netwerk?

[dt77h]

nee normaal gesproken niet maar haal ze is van je netwerk af zou ik zeggen.
en renew de dhcp

[dt77h]

Rob schreef op vrijdag 31 december 2010 @ 16:10:
Waarom hangen de UPC settopboxen in het netwerk?

vraag ik me ook af, je kan er tenslotte toch niks mee

[Gait]

Die UPC settopboxen die kunnen worden aangesloten met een UTP kabel voor updates geloof ik, maar deze moeten niet percé in het netwerk.

Op dit moment heb ik mijn netbook verbonden met de router/modem d.m.v. een utp kabel en staat het draadloos internet uit in de router. Het gaat trouwens om 192.168.100.100 deze gaat alleen weg wanneer ik de kabel van de telefoonlijn eruit haal ben ik nu net achter gekomen.

@burne


@kluyze
M'n netwerk uittekenen op een netbook lukt niet heel handig, maar het is heel simpel.
Normaal gaat er een kabel van de router/modem naar de switch en vandaaruit zijn alle apparaten aangesloten in een gigabit netwerk. Behalve 1 UPC settop box want die gaat ook via de router/modem.

[Sluuut]

Gait schreef op vrijdag 31 december 2010 @ 16:45:
Die UPC settopboxen die kunnen worden aangesloten met een UTP kabel voor updates geloof ik, maar deze moeten niet percé in het netwerk.

Op dit moment heb ik mijn netbook verbonden met de router/modem d.m.v. een utp kabel en staat het draadloos internet uit in de router. Het gaat trouwens om 192.168.100.100 deze gaat alleen weg wanneer ik de kabel van de telefoonlijn eruit haal ben ik nu net achter gekomen.

@burne
[afbeelding]

@kluyze
M'n netwerk uittekenen op een netbook lukt niet heel handig, maar het is heel simpel.
Normaal gaat er een kabel van de router/modem naar de switch en vandaaruit zijn alle apparaten aangesloten in een gigabit netwerk. Behalve 1 UPC settop box want die gaat ook via de router/modem.

Eindigd de screenshot ook echt daar, of staat er onder de screenshot nog een arp result van 192.168.100.1 ?

[Gait]

Hij eindigt daar.

[DukeBox]

trek eens dat upc ding eruit...

[Gait]

Alles is er uit zoals ik zei heb ik nu mn netbook met utp kabel verbonden aan de router/modem en verder helemaal niets.

[Petervanakelyen]

Heb je de laatste firmware op de WAG200G? Je kan het ding pingen, wat geven tooltjes zoals Nmap of Radmin's Advanced Port Scanner aan?

[Gait]

De router heeft alleen poort 80 open
Mijn netbook de poorten 135, 139 en 445.
En 192.168.100.100 geen één.

Dit heb ik zojuist met Radmin's Port Scanner gedaan

En ja, de laatste firmware is geïnstalleerd op de router.

[ Voor 16% gewijzigd door Gait op 31-12-2010 17:33 . Reden: Toevoeging firmware router, ip aangepast ]

[Petervanakelyen]

Wat gebeurd er als je een tracert doet naar 192.168.100.100?

[Gait]

[burne]

*ROFL*

Werkt Bevelander tegenwoordig bij Solcon?




TS: helaas. Dit ga jij niet zelf oplossen, vrees ik. Hier zal je ISP in moeten grijpen. Wijs ze op dit topic, config je PC even met een vast IP zodat je in ieder geval interwebs hebt, en ga lekker oud en nieuw vieren.

[Petervanakelyen]

Dit is interessant, tot nu toe nog niet veel meegemaakt

[ Voor 54% gewijzigd door Petervanakelyen op 31-12-2010 17:57 ]

[Gait]

Huh ik snap dit niet helemaal deze reacties? Maar ik moet dus maar een support-ticket starten bij Solcon?

Kunnen jullie toelichten wat er dan aan de hand is wat zo opmerkelijk is?

[ Voor 26% gewijzigd door Gait op 31-12-2010 18:00 ]

[Petervanakelyen]

De 192.168.x.x range is een IP-range die enkel voor adressen in een lokaal netwerk mag worden gebruikt. Je thuisnetwerk, bijvoorbeeld, dat gescheiden is van het publieke netwerk van je ISP door middel van NAT.

Aan de hand van de traceroute is echter duidelijk dat het IP-adres in kwestie helemaal niet binnen je lokaal netwerk zit, maar ergens naar een apparaat bij je ISP verwijst. Zeker als dat apparaat nog rustig voor DHCP-server speelt, is het tijd om je internetprovider eens een flinke schop te geven, want dan is er een behoorlijke configuratiefout gebeurd.

[ Voor 3% gewijzigd door Petervanakelyen op 31-12-2010 18:41 ]

[DJSmiley]

Als je router gewoon als router fungeert (en niet als bridge ingesteld staat) zul je echt niet ineens een ip vanaf je providerkant krijgen: DHCP requests blijven binnen je eigen netwerk.

Dat solcon toevallig misschien ook die range gebruikt voor interne routering is leuk, en in dit geval toevallig hetzelfde, maar heeft imho niets met dit probleem te maken. (Wij gebruiken zelf ook class b adressen om verkeer tussen cmtssen en core te routeren, upc doet hetzelfde)

Zoals al eerder gezegd: doe eens een arp vanaf een pc die het verkeerde netwerk toegewezen krijgt?

arp -a 192.168.100.1

Adhv het macadres wat je dan ziet kun je achterhalen wat voor merk het apparaat is, en misschien wat gerichter zoeken.

Je kan natuurlijk ook gewoon een ping openzetten naar 192.168.100.1 en net zo lang stekkers eruit/erin tot je de dader gevonden hebt.

Op je switch komen: dat lukt alleen als je een managed switch hebt. In dat geval zou je ook dhcp snooping kunnen configureren, dan heb je ook geen last meer van roque dhcp servers.. maar dat is natuurlijk niet de echte oplossing.

[ Voor 5% gewijzigd door DJSmiley op 31-12-2010 19:34 ]

[burne]

DJSmiley schreef op vrijdag 31 december 2010 @ 19:31:
Zoals al eerder gezegd: doe eens een arp vanaf een pc die het verkeerde netwerk toegewezen krijgt?

Maar z'n arp-tabel liet zien dat die niet in het lokale subnet zat. Hij heeft 192.168.1.1 als default gateway maar krijgt een arp-reply van buiten dat subnet wat 'm een 192.168.100.2-adres geeft. Ik kan me nauwelijks voorstellen waarom dat zo opgezet is, anders dan door een fout bij de ISP.

[maarud]

moet je niet 192.168.1.1 invullen bij DHCP-server (screenshot van je router)?

Dat is nu nog leeg namelijk

[Verwijderd]

maarud schreef op vrijdag 31 december 2010 @ 19:44:
moet je niet 192.168.1.1 invullen bij DHCP-server (screenshot van je router)?

Dat is nu nog leeg namelijk

Nee, dat adres vul je in als je naar een externe DHCP server wilt wijzen

[ik222]

Met DJSmiley, dat 192.168.100.100 een adres is buiten je eigen netwerk is op zich helemaal niet zo vreemd en heeft ook helemaal niets met het probleem te maken.

Feit is gewoon dat er ergens in jou netwerk een DHCP server actief is (192.168.100.1). Of als dat niet zo is dan is je modem / router totaal verkeerd ingesteld en doet die dus zijn werk niet.

burne schreef op vrijdag 31 december 2010 @ 19:41:
[...]

Maar z'n arp-tabel liet zien dat die niet in het lokale subnet zat. Hij heeft 192.168.1.1 als default gateway maar krijgt een arp-reply van buiten dat subnet wat 'm een 192.168.100.2-adres geeft. Ik kan me nauwelijks voorstellen waarom dat zo opgezet is, anders dan door een fout bij de ISP.

DHCP pakketten mogen nooit buiten het eigen netwerk komen, dus hoe dan ook zit die DHCP server in zijn eigen netwerk. Dat kan overigens eventueel wel komen doordat de modem/router verkeerd is ingesteld maar ook dan heb je wel een heel toevallige samenloop van omstandigheden...

[ Voor 52% gewijzigd door ik222 op 31-12-2010 19:52 ]

[DJSmiley]

burne schreef op vrijdag 31 december 2010 @ 19:41:
[...]

Maar z'n arp-tabel liet zien dat die niet in het lokale subnet zat. Hij heeft 192.168.1.1 als default gateway maar krijgt een arp-reply van buiten dat subnet wat 'm een 192.168.100.2-adres geeft. Ik kan me nauwelijks voorstellen waarom dat zo opgezet is, anders dan door een fout bij de ISP.

De enige screenshot die ik zie van een arp tabel is genomen vanaf een pc die WEL goed is, en dus in het juiste subnet zit. Dan is het idd logisch dat een ping naar 100.x zn wan over gerouteerd wordt.

Als ie ook niet in de arptabel voorkomt vanaf een probleempc dan wordt het een ander verhaal idd.

[Gait]

Dit krijg ik bij een PC die niet goed is:

[Jimster]

192.168.100.1 met MAC-adres 00-10-95-ff-ff-fe is een Thomson apparaat. Heb je iets van Thomson thuis?

[Poltergeist]

Jimster schreef op vrijdag 31 december 2010 @ 21:45:
192.168.100.1 met MAC-adres 00-10-95-ff-ff-fe is een Thomson apparaat. Heb je iets van Thomson thuis?

zo'n UPC box, wellicht?

[Gait]

Ja dat is de inmiddels weer opnieuw aangesloten settop box van UPC die direct is aangesloten op de router, maar wanneer ik deze eruit haal dan blijft 192.168.100.100 alsnog actief.

[Jimster]

Gait schreef op vrijdag 31 december 2010 @ 21:55:
Ja dat is de inmiddels weer opnieuw aangesloten settop box van UPC die direct is aangesloten op de router, maar wanneer ik deze eruit haal dan blijft 192.168.100.100 alsnog actief.

IP adres gereleased en gerenewed?

[basz]

Maar 192.168.100.1 blijft niet actief, toch? 192.168.100.100 zal een ander apparaat zijn wat ook een ip heeft gekregen van die upc-box. Lan uit je upc-box en al je apparatuur herstarten.

[Vorkie]

DJSmiley schreef op vrijdag 31 december 2010 @ 19:31:
.....

Dat solcon toevallig misschien ook die range gebruikt voor interne routering is leuk, en in dit geval toevallig hetzelfde, maar heeft imho niets met dit probleem te maken. (Wij gebruiken zelf ook class b adressen om verkeer tussen cmtssen en core te routeren, upc doet hetzelfde)
.....

wel knap dat de router dan het interne verkeer over de externe lijn vervoerd... Dit is bij design namelijk geblokkeerd in het modem / router en ook nog eens bereikbaar is vanuit een client van de klant.

Het is en blijft een foute routering, hoe je het ook brengt. De klant mag niet bij de INTERNE ip adressen komen van de EXTERNE cores in dit geval.

Het andere probleem is dat hij een IP krijgt uit 100.x reeks. Maar als hij op die PC een vast IP adres invoert in de 1.x reeks hij gewoon internet heeft.

Er gaat zeker iets fout met de routeringen, want met alles los krijgt hij nog steeds een 100.x adres...

Het enige wat ik mij dan kan bedenken is dat hij VMWARE oid heeft geinstalleerd en deze heeft gebridged op zijn notebook...

/edit
Ik gok Microsoft Virtual PC en Windows XP mode
(http://www.google.nl/#hl=...ell=1&fp=f48390e1ab4751d0)

[ Voor 7% gewijzigd door Vorkie op 31-12-2010 22:00 ]

[boers706]

Maar moet die setopbox van UPC via het netwerk aangesloten worden? Ikzelf heb zo'n apparaat van Ziggo en die zit gewoon via coax aangesloten. Er zitten wel twee netwerkaansluitingen op, maar die zijn voor toekomstig gebruik.

Het zou mij niets verbazen dat je helemaal geen netwerkstekker in die setopbox nodig bent, maar dat het apparaat wel ip-adressen uitdeelt.

Als je de netwerkstekker uit die setopbox haalt en alles reset, dus ook je linksys router, krijg je dan nog steeds ip-adressen in de 192.168.100.* reeks?

[AlterMann]

Gait schreef op vrijdag 31 december 2010 @ 21:55:
Ja dat is de inmiddels weer opnieuw aangesloten settop box van UPC die direct is aangesloten op de router, maar wanneer ik deze eruit haal dan blijft 192.168.100.100 alsnog actief.

192.168.100.100 is niet actief (doelhost niet bereikbaar).
Je moet 192.168.100.1 proberen te pingen, dat is je boosdoener

/Spuit 11

[Gait]

Ik heb nu de settop boxen er uit gehaald. Het IP adres wordt nu wel weer goed opgehaald. Waarom nu wel en vanmiddag niet begrijp ik niet, maar die 192.168.100.100 blijft nog steeds.

Alles werkt nu wel weer, ik begrijp er echt helemaal niks meer van, met alle apparaten losgekoppeld deed hij het niet en nu wel weer, behalve dat die 192.168.100.100 er nog steeds is terwijl mn enige thomson apparaat nu niet meer aangesloten is.

192.168.100.1 pingen geeft nu een time-out

En ik heb de stroom van mn router gehaald en mn pc opnieuw opgestart.

[ Voor 12% gewijzigd door Gait op 31-12-2010 22:26 ]

[Jimster]

Heb je het apparaat met .100.100 wel opnieuw opgestart of de lease vernieuwd?

Vanuit dos-prompt: ipconfig /release en daarna ipconfig /renew

Edit: Ik moet beter leren lezen..

[ Voor 47% gewijzigd door Jimster op 31-12-2010 22:42 ]

[Gait]

Ik weet niet welk apparaat dat is, ik moet dat denk ik maar bij Solcon neerleggen. Ik heb wederom alles losgekoppeld op m'n netbook na. En die 192.168.100.100 blift staan, maar nu krijgt m'n netbook wel automatisch het goede ip adres toegewezen.

Ja m'n router is gereset en ik het ipconfig/release en renew gedaan op m'n netbook.

[ik222]

Gait schreef op vrijdag 31 december 2010 @ 22:47:
Ik weet niet welk apparaat dat is, ik moet dat denk ik maar bij Solcon neerleggen. Ik heb wederom alles losgekoppeld op m'n netbook na. En die 192.168.100.100 blift staan, maar nu krijgt m'n netbook wel automatisch het goede ip adres toegewezen.

Ja m'n router is gereset en ik het ipconfig/release en renew gedaan op m'n netbook.

Zoals eerder al aangegeven, die 192.168.100.100 is helemaal geen probleem. Dat is namelijk gewoon een adres wat solcon gebruikt in hun routering. Dat heeft verder helemaal niets met jou probleem te maken.

Jou probleem was dus als ik het zo teruglees dat de UPC box voor DHCP server aan het spelen was. Deze moet je dus gewoon niet meer aansluiten. Die box is namelijk ook helemaal niet bedoeld om in je netwerk te hangen...

[DukeBox]

ik222 schreef op zaterdag 01 januari 2011 @ 01:05:
Jou probleem was dus als ik het zo teruglees dat de UPC box voor DHCP server aan het spelen was. Deze moet je dus gewoon niet meer aansluiten. Die box is namelijk ook helemaal niet bedoeld om in je netwerk te hangen...

Precies, zoals ik al 2 keer eerder aangaf. Sluit dat ding NIET aan, is nergens voor nodig en zoals je nu merkt, levert ie alleen maar problemen op doordat ie ook als DHCP server werkt.

Daarnaast, dat je in je huidige netwerk ook een ander 192.168.x.x adres kan pingen maakt niet uit. Dat je ISP dat intern gebruikt in de routering kan gewoon. Vaak zie je dat voor aanmeld/configuratie sites zodat je die kan benaderen zonder dat je zelf een publiek ip-adres hebt.

[dt77h]

De UPC mediabox fungeert gewoon als dhcp als je die in het netwerk hangt de mediabox is ook niet bedoeld om in je netwerk te hangen.
De netwerkaansluiting is enkel om het interne modem op frequentie te zetten. En om de signaalwaarden van het kabelmodem uit te lezen.

[Gait]

Oké bedankt voor de hulp, ik heb ze nu definitief uit het netwerk gehaald.

[burne]

ik222 schreef op zaterdag 01 januari 2011 @ 01:05:
Zoals eerder al aangegeven, die 192.168.100.100 is helemaal geen probleem. Dat is namelijk gewoon een adres wat solcon gebruikt in hun routering. Dat heeft verder helemaal niets met jou probleem te maken.

Het is wel een probleem. Mensen die intern 192.168.100/24 gebruiken (om welke reden dan ook) verwachten niet dat hun verkeer opeens op een machine in 'vlan501' van Solcon terecht komt.

Je routeert geen RFC 1918-adressen. NOOIT. Niet voor je klanten, niet voor de buitenwereld.

Het probleem is een beetje vergelijkbaar met de Bevelander-referentie. Martijn Bevelander had een huurlijn bij Colt (ja, zo dom is 'ie) en geen filtering op de routes die de bgp op de router accepteerde. Dat ging goed totdat een andere Colt-klant 192.168.0/24 ging adverteren. Al het interne netwerk-verkeer van Bevelander ging niet naar de juiste machines op kantoor maar naar een kantoor ergens in London. Dat was vlak na dat het joch in de Telegraaf gestaan had met een hetelucht-verhaal en z'n wanhopige reacties op het IRC-kanaal waar 'ie om hulp vroeg staan nog altijd op m'n netvlies gegrift.

[DukeBox]

burne schreef op zondag 02 januari 2011 @ 12:58:
Het is wel een probleem. Mensen die intern 192.168.100/24 gebruiken (om welke reden dan ook) verwachten niet dat hun verkeer opeens op een machine in 'vlan501' van Solcon terecht komt.

Dan is het nog steeds geen probleem. 1, die range wordt nooit buiten je LAN/WAN gerouteerd dus als dat wel gebeurd hoor je daar geen last van te hebben.
Daarnaast, als je die range zelf in gebruik hebt zorg je ook zelf voor je routering en niet je ISP.

Je routeert geen RFC 1918-adressen. NOOIT. Niet voor je klanten, niet voor de buitenwereld.

Toch is het dan appart dat veel MPLS providers (BT, KPN, ClaraNet..) die adressen gebruikt voor de routering.

[burne]

DukeBox schreef op zondag 02 januari 2011 @ 15:27:
die range wordt nooit buiten je LAN/WAN gerouteerd

Daarnaast, als je die range zelf in gebruik hebt zorg je ook zelf voor je routering en niet je ISP.

Zie Gait in "Automatische toegewezen IP adressen vall..."

Beide argumenten gaan niet altijd op, zoals ervaren door de TS.

Toch is het dan appart dat veel MPLS providers (BT, KPN, ClaraNet..) die adressen gebruikt voor de routering.

Je denkt dat het source-adres in een traceroute laat zien dat jij dat IP kunt bereiken? Probeer het maar eens.

[ik222]

burne schreef op zondag 02 januari 2011 @ 12:58:
[...]

Het is wel een probleem. Mensen die intern 192.168.100/24 gebruiken (om welke reden dan ook) verwachten niet dat hun verkeer opeens op een machine in 'vlan501' van Solcon terecht komt.

Je routeert geen RFC 1918-adressen. NOOIT. Niet voor je klanten, niet voor de buitenwereld.

Ik bedoelde meer dat dit niet direct iets was wat hiermee te maken heeft aangezien DHCP packets sowieso niet buiten het LAN komen. Het beginprobleem ging er namelijk over dat de TS op een bepaalde machine een ip uit een andere range kreeg. Maar uiteraard kun je indien je provider dit soort adressen gebruikt wel routeringsproblemen krijgen en daarom doe je dit inderdaad ook nooit als provider. Daar heb je dus 100% gelijk in.

Overigens verderop in netwerken gebruiken ISP's inderdaad vaak wel private ranges maar die adressen zijn dan ook niet direct bereikbaar voor de afnemer van de lijn en dan kan het wel gewoon.

Maar dat 192.168.100.100 adres was dus ook helemaal niet van Solcon, het was een adres wat bereikbaar was via die Mediaboxen. Heeft dus helemaal niets met Solcon te maken verder. Die mediaboxen moet je sowieso niet in het netwerk hangen omdat ze daar niet voor gemaakt zijn en als je dat doet krijg je inderdaad problemen zoals de TS in dit topic.

[ Voor 4% gewijzigd door ik222 op 02-01-2011 16:32 ]

[Glashelder]

burne schreef op zondag 02 januari 2011 @ 16:03:
[...]

[afbeelding]

KPN doet dit ook met Bitstream lijnen. Ik zie je punt ook niet helemaal; die router gooit pakketten met een destination in een andere range het internet op (in dit geval toevallig een private range). Big deal, dat doen zoveel routers, zelfs Cisco doet dat. Het punt is dat als je intern 192.168.100.x als range gebruikt, dat dat verkeer dan niet je eigen netwerk verlaat en daarom heb je er geen last van. Dat er na een aantal hops eenzelfde IP adres voorbij komt doet er niet toe (sowieso doet je router natuurlijk aan NAT).

Verder over die UPC box. Het ding bevat een kabelmodem om on-demand diensten aan te kunnen bieden. Vermoedelijk kan het ding de CMTS niet bereiken (heeft geen goede verbinding met het UPC netwerk dus). Kabelmodems (in ieder geval van UPC) gaan dan inderdaad 192.168.100.x adressen uitdelen. Fix dus je bekabeling (signaal is niet goed genoeg of je hebt er een niet retourgeschikte versterker of harddisk-recorder of wat dan ook tussenhangen) want waarschijnlijk werkt je on-demand niet, of laat die UPC doos uit het netwerk.

Ik weet niet meer wat voor IP range het was (ik meen 192.168.1.x), maar die kan (kon) je met een Bitstream lijn (in ieder geval bij Telfort) gewoon pingen Zit er inmiddels al een tijdje niet meer.

[ Voor 7% gewijzigd door Glashelder op 02-01-2011 16:36 ]

[ik222]

Glashelder schreef op zondag 02 januari 2011 @ 16:34:
[...]

KPN doet dit ook met Bitstream lijnen. Ik zie je punt ook niet helemaal; die router gooit pakketten met een destination in een andere range het internet op (in dit geval toevallig een private range). Big deal, dat doen zoveel routers, zelfs Cisco doet dat. Het punt is dat als je intern 192.168.100.x als range gebruikt, dat dat verkeer dan niet je eigen netwerk verlaat en daarom heb je er geen last van. Dat er na een aantal hops eenzelfde IP adres voorbij komt doet er niet toe (sowieso doet je router natuurlijk aan NAT).

Wat je zegt klopt opzich natuurlijk. Maar dat 192.168.100.x adres aan de WAN kant is wel onbereikbaar indien je in je LAN dezelfde range gebruikt natuurlijk. En als het adres bestaat dan zal het ook ergens voor nodig zijn, dan is het niet handig als het onbereikbaar wordt doordat iemand toevallig die 192.168.100.x range gebruikt in zijn interne netwerk. En dat is de reden waarom je dit als provider niet wilt.

[Vorkie]

burne schreef op zondag 02 januari 2011 @ 12:58:
[...]

Het is wel een probleem. Mensen die intern 192.168.100/24 gebruiken (om welke reden dan ook) verwachten niet dat hun verkeer opeens op een machine in 'vlan501' van Solcon terecht komt.

Je routeert geen RFC 1918-adressen. NOOIT. Niet voor je klanten, niet voor de buitenwereld.

Het probleem is een beetje vergelijkbaar met de Bevelander-referentie. Martijn Bevelander had een huurlijn bij Colt (ja, zo dom is 'ie) en geen filtering op de routes die de bgp op de router accepteerde. Dat ging goed totdat een andere Colt-klant 192.168.0/24 ging adverteren. Al het interne netwerk-verkeer van Bevelander ging niet naar de juiste machines op kantoor maar naar een kantoor ergens in London. Dat was vlak na dat het joch in de Telegraaf gestaan had met een hetelucht-verhaal en z'n wanhopige reacties op het IRC-kanaal waar 'ie om hulp vroeg staan nog altijd op m'n netvlies gegrift.

Precies wat ik mijn verhaal ook verwoord.

Wat er ook aangegeven wordt, via de RFC betreft internet routeringen mogen de private adressen helemaal niet buiten de LAN kant uitgaan.
In dit geval is dit wel gebeurt, losstaand van het feit dat hij de mediabox in het netwerk heeft hangen.

ik raad dan ook aan om te kijken of het probleem te reproduceren is en zo ja, de traceroute naar SOLCON mailen en aangeven dat je interne verkeer naar buiten wordt geleid.

[Glashelder]

ik222 schreef op zondag 02 januari 2011 @ 16:46:
[...]

Wat je zegt klopt opzich natuurlijk. Maar dat 192.168.100.x adres aan de WAN kant is wel onbereikbaar indien je in je LAN dezelfde range gebruikt natuurlijk. En als het adres bestaat dan zal het ook ergens voor nodig zijn, dan is het niet handig als het onbereikbaar wordt doordat iemand toevallig die 192.168.100.x range gebruikt in zijn interne netwerk. En dat is de reden waarom je dit als provider niet wilt.

De reden van die IP adressen is waarschijnlijk het linken van twee netwerksegmenten. In het geval van een Telfort lijn via Bitstream, het Bitstream netwerk met het Telfort netwerk. Als klant hoef je nooit die adressen (direct) te benaderen.

Maar goed ik snap je punt wel hoor, maar het heeft echt helemaal niks met dit probleem te maken

[ Voor 6% gewijzigd door Glashelder op 02-01-2011 17:35 ]

[DukeBox]

burne schreef op zondag 02 januari 2011 @ 16:03:
[afbeelding]

Ik weet niet wat je met deze trace wil aangeven, maar je range wordt nog steeds niet buiten je LAN/WAN gerouteerd. Dat de range buiten je LAN ook voorkomt kan een keuze zijn van de ISP maar dan nog steeds routeerd de range niet die jij voor je LAN gebruikt.

Zie Gait in "Automatische toegewezen IP adressen vall..."
Beide argumenten gaan niet altijd op, zoals ervaren door de TS.

Jawel, nogmaals:
Als je zelf de range gebruikt zal deze niet buiten je LAN/WAN routeren.
Het enige nadeel zou kunnen zijn dat je bepaalde service pagina's niet zou kunnen bereiken.

Je denkt dat het source-adres in een traceroute laat zien dat jij dat IP kunt bereiken? Probeer het maar eens.

Ik snap niet wat je bedoeld, graag een uitleg.
Wat ik bedoel is dat je vaak in een MPLS ziet dat bij een trace er onderweg ook met private ranges wordt gerouteerd tussen routers. In het UPC netwerk zie ik het ook wel eens terug komen wanneer dit via interoute naar een interconnect gaat van BT.

[burne]

DukeBox schreef op zondag 02 januari 2011 @ 19:53:
Ik weet niet wat je met deze trace wil aangeven, maar je range wordt nog steeds niet buiten je LAN/WAN gerouteerd. Dat de range buiten je LAN ook voorkomt kan een keuze zijn van de ISP maar dan nog steeds routeerd de range niet die jij voor je LAN gebruikt.

Ik begreep van TS dat dit een traceroute is van een computer met 192.168.100.2 naar 192.168.100.1, en dat dat .2-adres van een DHCP-server gekomen is.

MPLS [..] wordt gerouteerd tussen routers.

MultiProtocol Label Switching routeert niet. Het switcht, aan de hand van de labels die aan de encapsulated packets gegeven zijn. Je kunt aan de hand van de IP-adressing in een traceroute niet afleiden hoe het verkeer door het netwerk loopt. Het enige wat je ziet is het IP-adres van de LER's, niet de (RSVP- of LDP-) beslissingen die genomen worden.

[ik222]

burne schreef op zondag 02 januari 2011 @ 20:37:
[...]

Ik begreep van TS dat dit een traceroute is van een computer met 192.168.100.2 naar 192.168.100.1, en dat dat .2-adres van een DHCP-server gekomen is.

Ja maar die DHCP server was dus gewoon zijn Mediabox, en dat die dit soort dingen doet is nu precies de reden dat die niet in het netwerk hoort te hangen. Dat heeft verder ook helemaal geen functie.

[ Voor 4% gewijzigd door ik222 op 02-01-2011 20:52 ]

[DukeBox]

burne schreef op zondag 02 januari 2011 @ 20:37:
MultiProtocol Label Switching routeert niet. Het switcht, aan de hand van de labels die aan de encapsulated packets gegeven zijn.

Ah.. ok, tnx. Heb ik ook weer wat geleerd