Cisco 2800 2 subnets routeren

[Biebel]

Hallo,
Ik heb al gezocht in de archives, maar kan niet zo goed vinden wat ik zoek, dus bij deze mijn vraag:

Ik wil graag 2 subnets koppelen via een Cisco 2800 Router.

Subnet a = 172.28.4.0
Subnet b = 172.28.66.0

de 2 Ethernet poorten op de 2800 hebben als adressen:
A) 172.28.4.41
B ) 172.28.66.1
ik heb IP ROUTING aangezet, en volgens alle topic op het www moet het nu werken.
maar dat doet het niet.

Ik heb ook al geprobeerd de poorten in 1 Bridging group te zetten.

ik heb de laatste versies van IOS en SDM erop staan.

Ik sla vast iets over, maar wat?
Hiervoor heb ik alleen geroute op een PIX 501 en PIX515, en natuurlijk op een Windows PC.
en dat werkte gewoon meteen.

[Vicarious]

Hebben ze de goede subnet masks? Hoe heb je geverifieerd dat het niet werkt? Heb je per ongeluk NAT aangezet op een van de interfaces? Doe je volledige config eens?

[Verwijderd]

Maar heb je in de nadat je "conf t" hebt ingevoerd ook "router rip" en hierna de twee netwerken toegevoegd ? Misschien makkelijker ? gooi je config eens in een code tabel hier, dan kunnen wij even kijken of het wel goed staat in je config.

nog even samengevat:

code:

(in de config}
router rip -> enter
172.28.4.0 255.255.255.0 -> enter
172.28.66.0 255.255.255.0 -> enter

probeer te pingen van subnet naar subnet, ^{ik ga er in het voorbeeld even vanuit dat je niets van VLSM oid hebt gebruikt btw !}

[ Voor 37% gewijzigd door Verwijderd op 08-08-2008 12:11 ]

[Biebel]

Code is:

code:

Using 766 out of 196600 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Router
!
boot-start-marker
boot-end-marker
!
enable secret 5 *
enable password *
!
no aaa new-model
ip cef
!
!
interface FastEthernet0/0
 ip address 172.28.4.41 255.255.254.0
 speed auto
 full-duplex
 no mop enabled
!
interface FastEthernet0/1
 ip address 172.28.66.1 255.255.254.0
 speed auto
 full-duplex
 no mop enabled
!
router rip
 redistribute connected
 network 172.28.0.0
!
!
ip http server
!
dialer-list 1 protocol ip permit
snmp-server community public RO
!
control-plane
!
!
line con 0
line aux 0
line vty 0 4
 password *
 login
!
scheduler allocate 20000 1000
end

[Biebel]

nog even samengevat:

code:

(in de config}
router rip -> enter
172.28.4.0 255.255.255.0 -> enter
172.28.66.0 255.255.255.0 -> enter

Helaas werkt dit niet, wel met het commando NETWORK ervoor, maar dan komt ie in de config zoals hij nu is.

probeer te pingen van subnet naar subnet.

resultaat is destination host unreachable, vanaf een pc aan beide kanten.

om een en ander nog iets duidelijker te maken:

172.28.4.0 subnet ------------|Router|-------------172.28.66.0 subnet
en het doel is om het verkeer zonder beperking beide kanten op te sturen.

[ Voor 19% gewijzigd door Biebel op 08-08-2008 12:40 ]

[paella]

ging RIP er niet van uit dat (in dit geval) het klasse B subnet gebruikt wordt? Dus dat ie niet meer kan weten waar 172.28.4.0 en 172.28.66.0 terecht moeten komen? Kortom, zo zal het dan niet werken met RIP. Ga naar bv. OSPF of nummer om.

[Vicarious]

Wat paella zegt. Je kan ook RIPv2 gebruiken:

code:

router rip
version 2

RIPv2 ondersteunt ook VLSM.

Je hebt kans dat je ook nog (afhankelijk van het routing protocol) auto-summary uit moet zetten.

[TrailBlazer]

Waarom rip configureren. Ik zie nergens dat de TS nog een device heeft wat rip praat.
Staan de default gateways van de clients wel goed.
Kan de client wel de beide interfaces van de cisco pingen.

Overigens RIP v1 kan prima gebruik worden ook met andere maskers dan de standaard maskers alleen dan moet je in je netwerk heel consequent hetzelfde masker gebruiken.

[Biebel]

De gateway op de clients staat goed.

Een client in het 66.0 segment kan beide interfaces pingen.
Een client in het 4.0 segment kan alleen de 4.41 pingen

Ik heb ook OSPF geprobeerd, zelfde probleem.

voorbeeld:
Client 172.28.66.5 pingt:
ping to 172.28.4.41 = reply
ping to 172.28.66.1 = reply
ping to 172.28.4.1 = timed out (dus geen unreachable)

Andere kant op:
Client 172.28.4.189 pingt:
ping to 172.28.4.41 = reply
ping to 172.28.66.1 = reply
ping to 172.28.66.5 = timed out (dus geen unreachable)

[ Voor 22% gewijzigd door Biebel op 08-08-2008 14:06 ]

[Verwijderd]

Waarom wil je een routing protocol als RIP of OSPF gebruiken? Als je twee interfaces in je 2800 router hebt, deze heb je allebei een IP adres gegeven en routing (conf t, ip routing) staat aan dan zou je door middel van een show ip route kunnen zien dat de twee subnets als C aangegeven zijn (connected) en dan zou routering zonder problemen moeten werken.

Kun je de output van sh ip route posten?

[Biebel]

Verwijderd schreef op vrijdag 08 augustus 2008 @ 14:06:
Waarom wil je een routing protocol als RIP of OSPF gebruiken? Als je twee interfaces in je 2800 router hebt, deze heb je allebei een IP adres gegeven en routing (conf t, ip routing) staat aan dan zou je door middel van een show ip route kunnen zien dat de twee subnets als C aangegeven zijn (connected) en dan zou routering zonder problemen moeten werken.

Kun je de output van sh ip route posten?

Ja, dat dacht ik dus ook, dus vandaar dat ik het idee heb dat ik iets mis, want ik kan, zoals je in de vorige post kunt zien, wel pingen naar beide interfaces. hij komt alleen niet bij een host op het andere netwerk.

Router#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

172.28.0.0/16 is variably subnetted, 3 subnets, 2 masks
S 172.28.0.0/16 [1/0] via 172.28.66.0
[1/0] via 172.28.4.0
C 172.28.4.0/23 is directly connected, FastEthernet0/0
C 172.28.66.0/23 is directly connected, FastEthernet0/1

[Verwijderd]

Ok, dat klopt wel wat je daar ziet. ip routing staat aan? Ik bouw het hier even na met een oude 2600...

[TrailBlazer]

Biebel schreef op vrijdag 08 augustus 2008 @ 14:01:
De gateway op de clients staat goed.

Een client in het 66.0 segment kan beide interfaces pingen.
Een client in het 4.0 segment kan alleen de 4.41 pingen

Ik heb ook OSPF geprobeerd, zelfde probleem.

voorbeeld:
Client 172.28.66.5 pingt:
ping to 172.28.4.41 = reply
ping to 172.28.66.1 = reply
ping to 172.28.4.1 = timed out (dus geen unreachable)

Andere kant op:
Client 172.28.4.189 pingt:
ping to 172.28.4.41 = reply
ping to 172.28.66.1 = reply

net zeg je nog dat een client in 4.0/23 enkel de 4.41 kan pingen. Hier zeg je opeens wat anders.

ping to 172.28.66.5 = timed out (dus geen unreachable)

Doe eens route print op beide clients.

[Verwijderd]

Als je vanaf beide clients het ip adres van de interface van de router in het andere subnet kunt pingen doet je router het goed. Als je dan de client niet kunt pingen in het andere subnet staat de default route of default gateway wss niet goed.

[TrailBlazer]

als je vanaf je client beide interfaces kan pingen dan zou de default gateway in orde moeten zijn. Je kan nog iets hebben met proxy arp maar het lijkt allemaal wel goed zo.

[Verwijderd]

Je zou wireshark aan kunnen zetten op een client die niet te pingen is om te kijken of er uberhaupt pakketjes/frames vanaf het andere subnet binnenkomen...

[Biebel]

TrailBlazer schreef op vrijdag 08 augustus 2008 @ 14:23:
[...]

net zeg je nog dat een client in 4.0/23 enkel de 4.41 kan pingen. Hier zeg je opeens wat anders.

[...]

Doe eens route print op beide clients.

Klopt, maar na het uitzetten van RIP, en het gewoon aanmaken van ip routes

code:

 ip route 172.28.0.0 255.255.0.0 172.28.4.0
ip route 172.28.0.0 255.255.0.0 172.28.66.0
ip route 172.28.4.0 255.255.254.0 172.28.4.1 permanent
ip route 172.28.66.0 255.255.254.0 172.28.66.0 permanent

werkt dat in elk geval wel. excuus voor de onvolledige info.
een route print:
(ff in code)

code:

client 4.198
U:\>route print
===========================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0x2 ...00 18 71 7b e7 c1 ...... Broadcom NetXtreme Gigabit Ethernet - Packet Sch
eduler Miniport
===========================================================================
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      172.28.4.41    172.28.4.198       20
        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1
       172.28.4.0    255.255.254.0     172.28.4.198    172.28.4.198       20
     172.28.4.198  255.255.255.255        127.0.0.1       127.0.0.1       20
   172.28.255.255  255.255.255.255     172.28.4.198    172.28.4.198       20
        224.0.0.0        240.0.0.0     172.28.4.198    172.28.4.198       20
  255.255.255.255  255.255.255.255     172.28.4.198    172.28.4.198       1
Default Gateway:       172.28.4.41
===========================================================================
Persistent Routes:
  None

Client 66.5
U:\>route print
===========================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0x2 ...00 18 71 7b e7 c1 ...... Broadcom NetXtreme Gigabit Ethernet - Packet Sch
eduler Miniport
===========================================================================
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      172.28.66.1    172.28.66.5       20
        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1
       172.28.66.0    255.255.254.0     172.28.66.5     172.28.66.5       20
     172.28.66.5   255.255.255.255        127.0.0.1       127.0.0.1       20
   172.28.255.255  255.255.255.255      172.28.66.5     172.28.66.5       20
        224.0.0.0        240.0.0.0      172.28.66.5     172.28.66.5       20
  255.255.255.255  255.255.255.255      172.28.66.5     172.28.66.5       1
Default Gateway:       172.28.66.1
===========================================================================
Persistent Routes:
  None

[Biebel]

Verwijderd schreef op vrijdag 08 augustus 2008 @ 14:40:
Je zou wireshark aan kunnen zetten op een client die niet te pingen is om te kijken of er uberhaupt pakketjes/frames vanaf het andere subnet binnenkomen...

ff gekeken, maar helaas, komt niets binnen.

Als ik een Tracert doe: (66.0 subnet naar 4.0 subnet)
Tracert 172.28.4.1
tracing route to 172.28.4.1 over a maximum of 30 hops
1 <1ms <1ms <1ms 172.28.66.1
2 * * * Request timed out
3 * * * Request timed out
etc.

Vanaf de andere kant (4.0 naar 66.0 subnet) sneuvelen de pakketten bij de 4.41..

[ Voor 34% gewijzigd door Biebel op 08-08-2008 14:52 ]

[Verwijderd]

eerste twee ip route entries kloppen niet volgens mij? je hoeft geen statics aan te maken, connected gaat voor static...

en

Biebel schreef op vrijdag 08 augustus 2008 @ 14:48:
[...]

ff gekeken, maar helaas, de pakketten sneuvelen bij de 4.41
(gezien na een tracert)

dat weet je niet, ze kunnen ook op de terugweg sneuvelen.

[ Voor 90% gewijzigd door Verwijderd op 08-08-2008 14:49 ]

[Biebel]

Verwijderd schreef op vrijdag 08 augustus 2008 @ 14:48:
eerste twee ip route entries kloppen niet volgens mij? je hoeft geen statics aan te maken, connected gaat voor static...

en


[...]

Die eerste 2 kan ik niet verwijderen. die maakt hij zelf aan om de een of andere reden..

dat weet je niet, ze kunnen ook op de terugweg sneuvelen.

Klopt, zie de aanvulling op mijn vorige post.

[jvanhambelgium]

- kuis alle RIP / static-route rommel op! Er moet niks op die Cisco staan van routes of routing-protocols (directly connected networks weet je wel...)
- als je zowel links als recht op de clients hun respectievelijke gateways EN de Cisco interface op het naburig subnet kan pingen zit je goed ...

Als er dan nog problems zijn is het een probleem van de clients (verkeerd subnetmask,firewall)
Kan haast niet anders...

[Biebel]

jvanhambelgium schreef op vrijdag 08 augustus 2008 @ 14:59:
- kuis alle RIP / static-route rommel op! Er moet niks op die Cisco staan van routes of routing-protocols (directly connected networks weet je wel...)
- als je zowel links als recht op de clients hun respectievelijke gateways EN de Cisco interface op het naburig subnet kan pingen zit je goed ...

Als er dan nog problems zijn is het een probleem van de clients (verkeerd subnetmask,firewall)
Kan haast niet anders...

Ben weer even bezig de router factory default te maken, dan begin ik even overnieuw.
zodat alle RIP zooi weg is.

Klein dingetje nog, op een interface kan ik geen default gateway zetten he?
als ik namelijk van het 66.0 segment kom, wil ik dat de router het request doorgeeft aan de 4.1
maar als ik van het 4.0 segment aankom wil ik dat het request gebroadcast word.
iemand enig idee?
Ik kan wel een next hop aanmaken voor de 4.41. maar voor de andere kant?

[Verwijderd]

Waarschijnlijk heb je het al geprobeert, maar de clients zijn wel vanuit de router te pingen? (geen fw die de ping op de client blokkeert) Ook met als source de interface in het andere subnet?

[paella]

Een request gebroadcast???

[TrailBlazer]

Dat kan best hoor maar niet heel erg makkelijk. Je kan een ip helper configuren met als bestemming een broadcast segment. Je kan nog exotischer dingen doen met een multicast helper map maar dat wil je echt niet.

[Biebel]

Verwijderd schreef op vrijdag 08 augustus 2008 @ 15:22:
Waarschijnlijk heb je het al geprobeert, maar de clients zijn wel vanuit de router te pingen? (geen fw die de ping op de client blokkeert) Ook met als source de interface in het andere subnet?

Ik kan vanaf de router de clients pingen ja.
maar vanaf een client in het ene segment naar een client in het 2e segment gaat dus niet.

[jvanhambelgium]

Biebel schreef op vrijdag 08 augustus 2008 @ 15:04:
[...]

Ben weer even bezig de router factory default te maken, dan begin ik even overnieuw.
zodat alle RIP zooi weg is.

Klein dingetje nog, op een interface kan ik geen default gateway zetten he?
als ik namelijk van het 66.0 segment kom, wil ik dat de router het request doorgeeft aan de 4.1
maar als ik van het 4.0 segment aankom wil ik dat het request gebroadcast word.
iemand enig idee?
Ik kan wel een next hop aanmaken voor de 4.41. maar voor de andere kant?

Begin nou niet te rennen voor je kan lopen ! Begin met de basics en dan zien we wel.
Wat jij denkelijk zoekt noemt een in Cisco vocabulaire "ip helper" en die komt goed van pas in Windos networking omgeving waar vb op het ene segment een client staat die moet gaan inloggen op een domein waar de server op het andere segment iets mee heeft.
Hij gaat de broadcast van die client die wil inloggen omzetten en forward naar een specifiek IP (de helper dus) als unicast! (niet als broadcast in dit geval , het is dus niet gewoon een "bridge" ofzo)
Je kan ook die broadcast van de client omzetten naar een directed-broadcast naar een groep van machines aan de andere kant.

Deze functie werk voor protocols als tftp,bootp client,bootp server,time, tacacs,netbios,netbios-datagram,dns


maar laat ons beginnen met de basics...

[Biebel]

jvanhambelgium schreef op vrijdag 08 augustus 2008 @ 15:41:
[...]


Begin nou niet te rennen voor je kan lopen ! Begin met de basics en dan zien we wel.
Wat jij denkelijk zoekt noemt een in Cisco vocabulaire "ip helper" en die komt goed van pas in Windos networking omgeving waar vb op het ene segment een client staat die moet gaan inloggen op een domein waar de server op het andere segment iets mee heeft.
Hij gaat de broadcast van die client die wil inloggen omzetten en forward naar een specifiek IP (de helper dus) als unicast! (niet als broadcast in dit geval , het is dus niet gewoon een "bridge" ofzo)
Je kan ook die broadcast van de client omzetten naar een directed-broadcast naar een groep van machines aan de andere kant.

Deze functie werk voor protocols als tftp,bootp client,bootp server,time, tacacs,netbios,netbios-datagram,dns


maar laat ons beginnen met de basics...

Klopt, ik gebruik voor onze andere netwerksegmenten wel een IP helper voor DHCP inderdaad.

Met een compleet lege (lees: standaard) config, zonder static routing whatsoever, kan ik nu vanaf een pc in het 4.0 segment, alles pingen in het 66.0 segment.
echter, de andere kant op niet.
beide interfaces van de router staan exact gelijk.

[TrailBlazer]

Firewall op de PC is de echt de enige mogelijke oorzaak.

[Biebel]

Die stond aan op 1 van de pc's. dat is nu opgelost.

Als ik nu vanaf een PC op het 4.0 segment naar een pc op het 66.0 segment ping werkt het, pas als ik die kant op heb gepingt kan ik ook terug. (net of de router eerst moet weten waar het vandaan komt..)
Nou ja, in elk geval kan ik routeren, dat werkt, nu nog uitvinden waarom ik eerst naar het 66.0 segment moet pingen om de andere kant op te kunnen pingen..

allen bedankt voor de nuttige hulp, ik ben een stuk verder gekomen!

[Verwijderd]

Heb je geen VPN client geinstalleerd staan? Checkpoint bijv wil wel eens behoorlijk wat vreemd gedrag veroorzaken...