im in a CCNA class right now, and im having some troubles with my lab network ive created, i have 4 router/switch combos interconnected by smart serial and running RIPv2, but ive connected the first router to the school's network via Ethernet, and for some reason the other routers can ping to the ethernet interface on router one but not through it, and router 1 can ping out to the internet.
any ideas? i can upload the config files if needed
Do you have a diagram? Is the "internet" a real ISP? If you can ping to the ISP through RouterA and the routers behind RouterA can ping RouterA's LAN interface, but they can't ping to the internet, it sounds like a natting issue.
anyways, what i meant by "route info lost in translation" is that the school's ethernet network that im plugging into is 192.168.3.0 /25, and on router one it shows up as such, but it propagates to the other routers as 192.168.3.0 /24 for some reason. i cant help but think that this is related to if not a cause of the issue.
By default, RIPv2 summarizes routes to classful boundaries when crossing networks. Do you have "no auto-summary" configured in your "router rip" process?
so router 4 can ping to 192.168.3.115 but not beyond, however router one can ping all the way out to google.com
What network(s) are on the serial links between R1-R2, R2-R3, R3-R4? Does your school network have a route to those devices via 192.168.3.115?
they are each a private 172.16.0.0 /30 network
r4 s0/0 is 172.16.0.1
r3 s0/1 is 172.16.0.2
r3 s0/0 is 172.16.0.5
r2 s0/1 is 172.16.0.6
r2 s0/0 is 172.16.0.9
r1 s0/1 is 172.16.0.10
and no, the router on the other end of the 192.168.3.0 ethernet network cannot see routers 2 through 4, however it does have router 1 as a CDP neighbor and all the PCs on that network can reach router 1 just not any farther
So it seems that the school's network/hosts do not have a route to your private space. I'm not sure what your ultimate goal and constraints are, but you have several options at your disposal that may or may not be feasible:
-Advertise your private nets via RIP
-Include a static route in the school's network to your private nets
-Have R1 perform NAT overload (PAT) for your internal address space
Which route (no pun intended) you choose depends on your constraints and can be left as a supplement to your current CCNA coursework.
i would rather not use RIP because then our ISP would suddenly have 5 more entries in their routing table and probably be asking us whats going on.
so, the static route would be my best option, but how would that solve the problem?
R1 is having IP address which is from your School's network. And NAT configured in your school must be allowing the traffic sourced only from that network i.e 192.168.3.0 /25 to be NATed.
So when you source anything from 172.16.0.0 range it doesnt get NATed.
I will suggest to try NAT on R1 such that traffic from Inside network i.e 172.16.0.0 is overloaded on outside interface i.e 192.168.3.115
Test this and let us know. Thanks.
The ISP won't see any additional routes/networks. Your school is likely using a default route out to the ISP. If by chance the school is advertising routes to the ISP, they won't be advertising any RFC 1918 address space.
Is this a direct part of your coursework, or are you experimenting on your own? My direct question is, is the school network supposed to be able to reach your test network, or is this something that you've simply plugged in for experimentation? If the latter, you're likely not going to be successful in getting the admin to add a static route for your test set-up.
In that case, probably the easiest way to go would be to have your R1 perform NAT for your test network. Configure R1 to translate the test network (172.16.0.0) to the address it has received on its Ethernet interface (192.168.3.115).
It is a bit of a kludge, as the traffic from R2, R3, and R4 will be dual-NATted when accessing the internet (once from R1 to the 192.168.3.0 network, then at your school's edge router to (one of) the school's public IP addresses). NAT affects functionality of some services and protocols, but you should not have any problems testing basic connectivity.