Two labs connected together, then connected to internet gateway ip.

JeanM

I must be missing something simple here, but can't figure this out and it's bugging me.

So I have "Lab1" that contains R1 and R2, connected to each other using serial interface. R2 is then connected to "Lab2 via ethernet.
R1 S0 = 192.168.3.1
R2 S0 = 192.168.3.2
R2 E0 = 10.10.10.1 - connected to a switch port on Switch1.

"Lab2" contains R3 and R4. R3 is connected to R4 usiang Serial interface, and to the Switch1 using E0.
R3 E0 = 10.10.10.2 - connected to a switch1 port
R3 S0 = 192.168.6.1
R4 S0 = 192.168.6.2

R4 ethernet port E0 192.168.1.20 is finally connected to another switch2 (vlan ip interface 192.168.1.66), and it's uplink is connected to my home internet router (192.168.1.1).

I have connectivity between R1 and R4 interfaces, I have ip route 0.0.0.0 0.0.0.0 on R4 set to E0 which is connected to the switch, and then connected to the home internet router (gateway ip is 192.168.1.1)

Rip v2 is used on the routers. i've also tried eigrp on r4. rip routes are working between the two labs.


I must be missing something on the R4 router as I can ping from this router 192.168.1.1 and internet, can also ping all my lab routers as well. All the lab routers can ping the R4, but can't ping 192.168.1.1?

The switch2 with up link , with the 192.168.1.66, has internet connectivity as well as my pc is connected to the internet via it, using static ip.

I am just missing something on R4, lets call it the "edge" router as it can ping both "LABS" and the 192.168.1.1 BUT, the labs can't go beyond the edge router?

Hope this makes sense.

Any suggestions?

from the R4

Gateway of last resort is 0.0.0.0 to network 0.0.0.0
R 10.0.0.0/8 [120/1] via 192.168.6.1, 00:00:16, Serial0/0
C 192.168.6.0/24 is directly connected, Serial0/0
C 192.168.1.0/24 is directly connected, FastEthernet0/0
R 192.168.3.0/24 [120/2] via 192.168.6.1, 00:00:16, Serial0/0
S* 0.0.0.0/0 is directly connected, FastEthernet0/0
Edge#



Edge#
Edge#ping 192.168.3.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.3.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 64/68/84 ms
Edge#
Edge#
Edge#
Edge#ping 10.10.10.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/40/56 ms
Edge#
Edge#
Edge#ping 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/18/24 ms
Edge#
Edge#


from a lab1 router
Gateway of last resort is 192.168.3.2 to network 0.0.0.0
C 192.168.3.0/24 is directly connected, Serial0/0
S* 0.0.0.0/0 [1/0] via 192.168.3.2
jupiter#



pinging the edge router ok

jupiter#
jupiter#ping 192.168.1.20
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.20, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 60/69/96 ms

pinging past the edge router fails

jupiter#ping 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
jupiter#

Forsaken_GA

does 192.168.1.1 have a route back to the subnets you're trying to ping from? ie, are you running RIP with your internet router as well, or alternatively, have you setup static routes for your lab subnets on it?

If not, then how is it supposed to know how to reply? It's default route is going to point toward your ISP, so that's not going to work. If 192.168.1.1 receives a ping packet from 192.168.3.1, how does it know how to forward response packets to that address?

This is something that new folks tend to forget and get hung up on. Routing is bidirectional. Having a route to the destination is not enough, you need to have a route back to the source, unless your traffic is purely unidirectional

networker050184

Forsaken_GA wrote: »

This is something that new folks tend to forget and get hung up on. Routing is bidirectional. Having a route to the destination is not enough, you need to have a route back to the source, unless your traffic is purely unidirectional

Yep, usually this same mistake every time this problem comes up. Remember to walk the route out both ways.

JeanM

Forsaken_GA wrote: »

does 192.168.1.1 have a route back to the subnets you're trying to ping from? ie, are you running RIP with your internet router as well, or alternatively, have you setup static routes for your lab subnets on it?

If not, then how is it supposed to know how to reply? It's default route is going to point toward your ISP, so that's not going to work. If 192.168.1.1 receives a ping packet from 192.168.3.1, how does it know how to forward response packets to that address?

This is something that new folks tend to forget and get hung up on. Routing is bidirectional. Having a route to the destination is not enough, you need to have a route back to the source, unless your traffic is purely unidirectional

Good point! No, not running rip on internet router.

I'll try static routes for back route? or another routing protocol?

Actually, what if you "can't touch" the 192.168.1.1 ? Would you then instead setup NAT/PAT on the edge router instead?

For example, the link going from the 192.168.1.1 to the "uplink" switch is live and so are the ports on this first switch. The dhcp pool is set from for 192.168.1.1xx and I also use static ip's below the 192.168.1.1xx for the lab components.

Thanks!

JeanM

Uploaded a visual representation.

kurosaki00

do the switch connected to the cloud have frame relay or something?
192.168.1.1 has any way to communicate back to 192.168.6.2 ?

why not post the running config?

JeanM

No, that's what I'll work on later tonight to get the 192.168.1.x and 192.168.6.x working.

Just getting some ideas

MrBrian

Just like the others have said, it sounds like your ping packets from your internal lab routers are getting to the Internet router (192.168.1.1), but not getting back. This is because your Internet router may not have a route back! Every router has a simple routing table telling it what networks it can reach. So if your Internet router is receiving the pings, it will look at the source IP from the packet.. and say it's from 192.168.3.1.. then it will look at its routing table to see if it has a route to that network. If not, then it's a no go. Try doing a traceroute to 192.168.1.1 from R1, R2, or R3, and see where the successful traffic stops. The reason R4 and your Internet router can communicate within the 192.168.1.x address space is because they're directly connected to it, so that network is automatically added to their tables.

What do routers R1, R2, and R3 have in their routing tables for the 192.168.1.0 network? Do you have default routes on those pointing to R4? If you're at one of those routers and try to generate a ping packet to 192.168.1.1 then they'll need either a default route pointing to R4, a static entry, or a dynamic entry, which tells them how to get to that network. That will be to ensure that the traffic is getting to the Internet router. That's the first step.. next you'd need to ensure your Internet router has a route back to each of those subnets.

Not sure what kind of Internet router you have, but if it's a soho router, you can enter it's web gui and there should be a place to add static routes. Just add your networks like 192.168.3.0, 192.168.4.0, 10.10.10.0, etc(with the appropriate masks).. and point them out the proper interface, or at the next hop IP, which would be R4's 192.168.1.20. Or you could try running RIP if it supports it, I know most do. Good luck

JeanM

Thanks, that makes sense about the internet router not knowing what to do with the non 192.168.1. networks!

For the lab router directly connected to the edge router I've set a gateway of last resort that points to the edge router. The edge router has a default route pointing to the next hop out of 192.168.1.20 which is 192.168.1.1

Example from lab router
Gateway of last resort is 192.168.6.2 to network 0.0.0.0
C 192.168.5.0/24 is directly connected, Serial1/0
10.0.0.0/30 is subnetted, 1 subnets
C 10.10.10.0 is directly connected, Ethernet0/0
C 192.168.6.0/24 is directly connected, Serial1/1
C 192.168.7.0/24 is directly connected, Serial1/2
R 192.168.1.0/24 [120/1] via 192.168.6.2, 00:00:11, Serial1/1
S* 0.0.0.0/0 [1/0] via 192.168.6.2
Sun#


From edge-

Gateway of last resort is 0.0.0.0 to network 0.0.0.0
R 192.168.5.0/24 [120/1] via 192.168.6.1, 00:00:18, Serial0/0
R 10.0.0.0/8 [120/1] via 192.168.6.1, 00:00:18, Serial0/0
C 192.168.6.0/24 is directly connected, Serial0/0
R 192.168.7.0/24 [120/1] via 192.168.6.1, 00:00:18, Serial0/0
C 192.168.1.0/24 is directly connected, FastEthernet0/0
S* 0.0.0.0/0 is directly connected, FastEthernet0/0

I'll check the soho (netgear) and add the routes or rip there as suggested and see what happens.

JeanM

Added static routes in the netgear (I put dd-wrt on it) and now I can ping in/out


Sun#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 192.168.6.2 to network 0.0.0.0
C 192.168.5.0/24 is directly connected, Serial1/0
10.0.0.0/30 is subnetted, 1 subnets
C 10.10.10.0 is directly connected, Ethernet0/0
C 192.168.6.0/24 is directly connected, Serial1/1
C 192.168.7.0/24 is directly connected, Serial1/2
R 192.168.1.0/24 [120/1] via 192.168.6.2, 00:00:20, Serial1/1
S* 0.0.0.0/0 [1/0] via 192.168.6.2
Sun#
Sun#
Sun#ping 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 48/52/72 ms
Sun#
Sun#
Sun#sh ip int br
Sun#sh ip int brief
Interface IP-Address OK? Method Status Protocol
Ethernet0/0 10.10.10.2 YES manual up up
Serial1/0 192.168.5.1 YES manual up up
Serial1/1 192.168.6.1 YES manual up up
Serial1/2 192.168.7.1 YES manual up up
Serial1/3 unassigned YES NVRAM down down


Just need to fix name resolution behind edge router and then I'll be happy.

I still want to try this also with nat/pat next to pretend that you "can't touch the 192.168.1.1 router" if that makes sense.

MrBrian

Nice. Yea I dd-wrt is really cool, I've got it on my soho router as well

Yea you can try doing nat/pat on R4.. translating the inner IP's to use 192.168.1.20 as well.. and the Internet router is attached to that net, so it will know how to send things back.. Mix it up! Although a funny spot for it, it should I work. Doing things like this is good for practice

JeanM

MrBrian wrote: »

Nice. Yea I dd-wrt is really cool, I've got it on my soho router as well

Yea you can try doing nat/pat on R4.. translating the inner IP's to use 192.168.1.20 as well.. and the Internet router is attached to that net, so it will know how to send things back.. Mix it up! Although a funny spot for it, it should I work. Doing things like this is good for practice

Totally, this way it sinks in! Once I get more comfortable I'll add my PIX firewall in the mix

Forsaken_GA

JeanM wrote: »

Actually, what if you "can't touch" the 192.168.1.1 ? Would you then instead setup NAT/PAT on the edge router instead?

Yup, any time you can't influence the routing to an upstream router, and you have downstream hosts that need to communicate that way, you NAT the traffic.

JeanM

Forsaken_GA wrote: »

Yup, any time you can't influence the routing to an upstream router, and you have downstream hosts that need to communicate that way, you NAT the traffic.

Thanks for confirming! Love this forum.