Vraag over Default route (cisco)

[Verwijderd]

Hoi ik heb een vraag

al het verkeer dat op de hoofdrouter DREUTEN01 in dreuten binnenkomt en niet afgeleverd moet worden naar de routers in het dreuten-netwerk, moet aangeboden worden aan de hoofdrouter in Juinen (JUINEN01).
Het IP-adres van de seriele interface op DREUTEN01 is 10.1.2.1. De seriele interface op de JUINEN01 is 10.1.3.1.
Welk commando zorgt ervoor dat al het netwerkverkeer vanuit Dreuten (dus ook verkeer naar internet) via de JUINEN01 wordt afgeleverd in Juinen?

ik kom hier niet uit ze zeggen dat het met default toute te maken heeft kan iemand me helpen

[vincedd]

verwijderd

[ Voor 87% gewijzigd door vincedd op 13-05-2009 18:20 ]

[jvanhambelgium]

ip route 0.0.0.0 0.0.0.0 serialX/Y 10.1.3.1

dat zou het moeten doen...

in te kloppen op de router DREUNTEN01

[ Voor 21% gewijzigd door jvanhambelgium op 13-05-2009 18:32 ]

[mbaltus]

Is het niet ofwel via interface ofwel via next hop

ip route 0.0.0.0 0.0.0.0 serialX/Y
óf
ip route 0.0.0.0 0.0.0.0 10.1.3.1

[jvanhambelgium]

mbaltus schreef op donderdag 14 mei 2009 @ 10:44:
Is het niet ofwel via interface ofwel via next hop

ip route 0.0.0.0 0.0.0.0 serialX/Y
óf
ip route 0.0.0.0 0.0.0.0 10.1.3.1

Mag allebei, is geen probleem indien de interface point-to-point is.
Je kan (zeker in recente IOS'sen) ook de interface meegeven en daarachter nog eens de next hop.

Er zijn verschillende oplossing mogelijk

Jouw 1e voorbeeld zal enkel werken op een point-to-point type interface, doe dit op een broadcast-type interface (vb ethernet) en het gaat fout.

Het 2e voorbeeld zal ook werken aangezien de Cisco weet dat het 10.1.3.1 "stubje" deel uitmaakt van het directly-connected netwerkje dat aan de serialX/Y hangt. Packetje raakt wel buiten.

[Verwijderd]

Het 2e voorbeeld zal ook werken aangezien de Cisco weet dat het 10.1.3.1 "stubje" deel uitmaakt van het directly-connected netwerkje dat aan de serialX/Y hangt. Packetje raakt wel buiten.

Behalve dat de IP adressen die de ts geeft (10.1.3.1 / 10.1.2.1) waarschijnlijk niet in hetzelfde subnet zitten, aannemende dat het subnetmask /24 of kleiner (kleiner, als in kleiner subnet, dus groter getal --> /25 is kleiner dan /24) is. Meestal zal er voor zo'n verbinding een /30 gebruikt worden, waarbij dus 10.1.3.1 en 10.1.2.1 niet in hetzelfde subnet vallen.

[jvanhambelgium]

Verwijderd schreef op donderdag 14 mei 2009 @ 12:59:
[...]

Behalve dat de IP adressen die de ts geeft (10.1.3.1 / 10.1.2.1) waarschijnlijk niet in hetzelfde subnet zitten, aannemende dat het subnetmask /24 of kleiner (kleiner, als in kleiner subnet, dus groter getal --> /25 is kleiner dan /24) is. Meestal zal er voor zo'n verbinding een /30 gebruikt worden, waarbij dus 10.1.3.1 en 10.1.2.1 niet in hetzelfde subnet vallen.

Uiteraard is een /30 meestal een mooie oplossing, maar het is een actief productienetwerk, dus ik denk dat het zaakje wel correct werkt...

Als je aan 1 kant 10.1.3.1 ingeeft en aan de andere kan 10.1.2.1 met een mask 255.255.0.0 gaat het bijvoorbeeld wel werken, wel wat gekke adressing maar komt. Je zou evengoed "unnumbered" kunnen werken natuurlijk...
Mischien draait de TS werk ergens al een routing-protocol ??


Laat met het dus anders stellen ;-) Het subnetje tussen de serial PtP moet werken ;-)
Vanaf een host in DREUTEN zou je toch een host in JUINEN moeten kunnen pingen bijvoorbeeld

[Verwijderd]

jvanhambelgium schreef op donderdag 14 mei 2009 @ 14:26:
Uiteraard is een /30 meestal een mooie oplossing, maar het is een actief productienetwerk, dus ik denk dat het zaakje wel correct werkt...

Als je aan 1 kant 10.1.3.1 ingeeft en aan de andere kan 10.1.2.1 met een mask 255.255.0.0 gaat het bijvoorbeeld wel werken, wel wat gekke adressing maar komt. Je zou evengoed "unnumbered" kunnen werken natuurlijk...
Mischien draait de TS werk ergens al een routing-protocol ??

Het grappige is, dat 2 verschillende ip-subnets op een seriele lijn gewoon werkt... (daarom werkt ip unnumbered ook), maar het kan, als er een keer iets fout gaat in het netwerk een verschrikkelijke koppijn-situatie opleveren, omdat een aantal dingen niet werken zoals je zou verwachten...

Laat met het dus anders stellen ;-) Het subnetje tussen de serial PtP moet werken ;-)
Vanaf een host in DREUTEN zou je toch een host in JUINEN moeten kunnen pingen bijvoorbeeld

Ik heb het idee dat hij dat juist voor elkaar probeert te krijgen.