Route exam Lab study

johnwest43

I was wondering if anyone studying for Route would want to setup a lab study group.

What i was thinking was each person puts together a lab, gets it working then sends the config files to someone else in the group to "break" them and send them back to owner to load into the routers in their lab and try to find and fix the problem (kind of like the original CCIE exam). Or maybe even some of the more expierenced Cisco guys could lend a hand in the "breaking process".

Does this interest anyone? if so maybe we can do the same for Switch and T-Shoot.

Thanks

DPG

I might post some GNS3 labs if there is any interest.

JaCkNiFe

johnwest43 wrote: »

I was wondering if anyone studying for Route would want to setup a lab study group.

What i was thinking was each person puts together a lab, gets it working then sends the config files to someone else in the group to "break" them and send them back to owner to load into the routers in their lab and try to find and fix the problem (kind of like the original CCIE exam). Or maybe even some of the more experienced Cisco guys could lend a hand in the "breaking process".

Does this interest anyone? if so maybe we can do the same for Switch and T-Shoot.

Thanks

I would definitely be interested in helping, time permitting of course. I am beginning a study regiment for the CCIE written and I think this would be great practice for anyone (myself included) studying for any exam to get dirty in the CLI and learn the technologies well enough to design a functional, educational lab.

A limiting factor I see for some members would be access to Cisco's IOS. I think taking a headcount of who wants to participate and finding a common IOS(s) (within reason) may help with supported features, etc.

cheers!

johnwest43

JaCkNiFe wrote: »

A limiting factor I see for some members would be access to Cisco's IOS. I think taking a headcount of who wants to participate and finding a common IOS(s) (within reason) may help with supported features, etc.

I figure as long as everyone is using 12.4 we should be ok. For the part where someone "breaks" the config I figured we could just shoot txt files back and forth and copy and paste them into the router.

wrwarwick

Sounds interesting. Count me in.

Now to figure out how to organize this...

martell1000

i was thinking about that right the other week.

i am planing to take the route exam soon - so i would be onboard.

vinbuck

Just an FYI that I discovered in GNS3 for IPv6 while studying for ROUTE. 3600 series router IOS images only Support OSPF and RIPng for IPv6. If I recall correctly, 3700 series and 7200 series were the only routers in GNS3 that supported EIGRP for IPv6.

gbadman

I'm in.

DPG

I am going to use a 3640 IOS (you are on your own in finding one).

Here are three quick labs all with the same scenario. These should be good for ROUTE and TSHOOT study.

R1 isn't able to ping Loopback0 on R3.


Here are the GNS3 files:
dpg1.zip
dpg2.zip
dpg3.zip

pham0329

I'm too lazy to build a lab, but would love to troubleshoot one!

Edit: OK, how do you import someone else's lab into GNS3? I tried DPG's lab and got a bunch of error, even after editing the topology.net file.

Anyhow

• Lab 1 - no default metric were specified when redistributing into EIGRP, thus the routes are marked as unreachable.
• Lab 2 - R3 is not running OSPF on the loopback
• Lab 3 - network command on R3 is incorrect.

johnwest43

wrwarwick wrote: »

Sounds interesting. Count me in.

Now to figure out how to organize this...

I think all we need to do is start creating labs on our own using gns3 or real hardware, it doesnt matter. Then we need to just post the configs of each router in a seperate text file to the forum or PM to someone and who ever wants to edit the text files (break) can do so and then repost them for the originator to load into their routers and troubleshoot away.

cisco_trooper

Make sure you aren't simply finding the changes made to the configurations. That is easy. What you need to focus on in all of this is WHY the change in configuration broke the network. Don't sell yourselves short.

gbadman

Nice one DPG

pham0329 wrote: »

• Lab 1 - no default metric were specified when redistributing into EIGRP, thus the routes are marked as unreachable.

I think there's a little bit more wrong with lab 1 than the lack of a seed metric. R2 isn't redistributing the 192.168 network into ospf, since it's a connected route rather than learned via eigrp. Redistributing connected routes would fix that problem.

pham0329

gbadman wrote: »

Nice one DPG



I think there's a little bit more wrong with lab 1 than the lack of a seed metric. R2 isn't redistributing the 192.168 network into ospf, since it's a connected route rather than learned via eigrp. Redistributing connected routes would fix that problem.

You're right. This is what happens when you assume there's only one problem with the lab , and only have notepad to view the config with

DPG

gbadman wrote: »

Nice one DPG



I think there's a little bit more wrong with lab 1 than the lack of a seed metric. R2 isn't redistributing the 192.168 network into ospf, since it's a connected route rather than learned via eigrp. Redistributing connected routes would fix that problem.

Pham had it right.


R3#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.16.0.0/30 is subnetted, 1 subnets
C 172.16.0.0 is directly connected, FastEthernet0/0
10.0.0.0/24 is subnetted, 1 subnets
C 10.0.0.0 is directly connected, Loopback0
192.168.0.0/30 is subnetted, 1 subnets
O E2 192.168.0.0 [110/20] via 172.16.0.2, 00:00:55, FastEthernet0/0

DPG

pham0329 wrote: »

You're right. This is what happens when you assume there's only one problem with the lab , and only have notepad to view the config with

This should be the only part you would need to change:

[127.0.0.1:7200]

It might need to be [localhost:7200] depending on your config.

DPG

I'll post some more labs when I get a chance. I will focus more on design and implementation rather than just troubleshooting.

MrBrian

gbadman wrote: »

I think there's a little bit more wrong with lab 1 than the lack of a seed metric. R2 isn't redistributing the 192.168 network into ospf, since it's a connected route rather than learned via eigrp. Redistributing connected routes would fix that problem.

You don't really need to redistribute connected for R3 to receive the 192.168.0.0/30 network from R2. This topic threw me off for awhile! In this case we'll look at redistributing EIGRP into OSPF. Most everywhere you read about redistribution, it says that the router will look in its routing table for EIGRP routes, and then put those in the OSPF database so it can advertise them out. True.. But there's also something else...

In this example, R2 doesn't have the routes in its routing table because they're connected. However, since EIGRP is running for that interface (because of the network command applied to it) it will advertise the route. Also, this is why we see the connected route between R2 and R3, over on R1 in the EIGRP domain (even though it's not in R2's routing table as an OSPF route)... So we don't need to do a redistribute connected. You can do a "sho ip ospf int brief" you'll see the int's that OSPF is running on.. this definitely threw me off for a while. Especially since the books I was reading didn't really mention it.

Here's an example from Cisco that is pretty much identical to this case.. In the contents at the top, click 'Connected Routes' and take a look at that section. At the very end of the section it talks about this process. Hth

Redistributing Routing Protocols - Cisco Systems

MrBrian

I'm on board for any lab and/or config exchanges. Sounds like fun. I always like when people post topologies and ask for certain requirements to get us thinking how we could solve it. It's like a brain teaser game, but it can help you with your career at the same time lol.. so game on!

If we want to create our own labs and then post our configs for people to break, I'd think we should also post the topology for our configs as well. And maybe explain our goals for the topology. That way anyone that wants to break the configs for us will know good things to mess up for that topology situation. It would be tough to piece it all together if we just had running configs for like, 5 routers or something. Just a thought..

gbadman

MrBrian wrote: »

You don't really need to redistribute connected for R3 to receive the 192.168.0.0/30 network from R2. This topic threw me off for awhile! In this case we'll look at redistributing EIGRP into OSPF. Most everywhere you read about redistribution, it says that the router will look in its routing table for EIGRP routes, and then put those in the OSPF database so it can advertise them out. True.. But there's also something else...

In this example, R2 doesn't have the routes in its routing table because they're connected. However, since EIGRP is running for that interface (because of the network command applied to it) it will advertise the route. Also, this is why we see the connected route between R2 and R3, over on R1 in the EIGRP domain (even though it's not in R2's routing table as an OSPF route)... So we don't need to do a redistribute connected. You can do a "sho ip ospf int brief" you'll see the int's that OSPF is running on.. this definitely threw me off for a while. Especially since the books I was reading didn't really mention it.

Here's an example from Cisco that is pretty much identical to this case.. In the contents at the top, click 'Connected Routes' and take a look at that section. At the very end of the section it talks about this process. Hth

Redistributing Routing Protocols - Cisco Systems

Very true. I suppose I was working out a theory around what I was seeing rather than consulting the source:).

Perhaps another way to understand the exchange of those connected routes is that both ospf and eigrp advertise their topology tables (partial in the case of eigrp) rather than their eigrp/ospf routing tables. So the routes in question do not have to be present in the routing table. Even though both protocols are processing their respective connected routes, the routers have chosen the directly connected versions rather than the protocol versions to put into their routing tables, due to admin distance. This doesn't stop them from redistributing those routes between the two protocols (without the need to redistribute the directly connected versions of those routes).

There's a second point that's still causing me a bit of grief though. It had been my understanding that the network statement under the routing process only caused networks to be advertised for those interfaces with subnets within the defined network. That Cisco doc seems to suggest that too. However it would appear from lab 1 that the subnet of an interface doesn't have to be within the defined mask. It can be greater than the mask. So for instance in the lab, the /30 networks are advertised even though /32 masks have been defined under the routing processes.

This leads me on to the problem I had that led me down the dubious redistribute connected alley. The lab only works for me when I change the mask of the 192.168 network to /30 under the routing process.

Any illumination would be most welcome.

gbadman

MrBrian wrote: »

If we want to create our own labs and then post our configs for people to break, I'd think we should also post the topology for our configs as well. And maybe explain our goals for the topology. That way anyone that wants to break the configs for us will know good things to mess up for that topology situation. It would be tough to piece it all together if we just had running configs for like, 5 routers or something. Just a thought..

Spot on. This open-ended format is ok for a simple 3-router topology like this. It becomes more important to focus on a specific topic or set of objectives for larger topologies.

MrBrian

gbadman wrote: »

There's a second point that's still causing me a bit of grief though. It had been my understanding that the network statement under the routing process only caused networks to be advertised for those interfaces with subnets within the defined network. That Cisco doc seems to suggest that too. However it would appear from lab 1 that the subnet of an interface doesn't have to be within the defined mask. It can be greater than the mask. So for instance in the lab, the /30 networks are advertised even though /32 masks have been defined under the routing processes.

This leads me on to the problem I had that led me down the dubious redistribute connected alley. The lab only works for me when I change the mask of the 192.168 network to /30 under the routing process.

Any illumination would be most welcome.

Sorry I just looked at the topology and was speaking generally, as if everything was configured correctly. I didn't look at the zip files of the configs. You're right though, the network statements under the routing protocol will tell the protocol on which interfaces to run the routing process.. It doesn't actually tell eigrp or ospf to advertise the specific network you point to with the network command. If you configure a network command for an IP with a 0.0.0.0 wildcard then only the interface with that IP will advertise hello's and be put into the topology table/database. The 0's in the wildcard say that "this whole octet must match" as compared to the IP.

Say you configure "network 192.168.0.32 0.0.0.15... then only interfaces with those 14 IP's (.33-.46) will run the routing protocol. With the wildcard you can limit the routing protocol to IP's within a certain block, or just advertise the interface using 0.0.0.0. saying all bits must match. So if in a network statement, you directly point to an IP using a wildcard 0.0.0.0, it doesn't matter what mask the interface is using.. it could be 10.0.0.50/8, but if you say "network 10.0.0.50 0.0.0.0" then the routing protocol matches it.

johnwest43

MrBrian wrote: »

If we want to create our own labs and then post our configs for people to break, I'd think we should also post the topology for our configs as well. And maybe explain our goals for the topology. That way anyone that wants to break the configs for us will know good things to mess up for that topology situation. It would be tough to piece it all together if we just had running configs for like, 5 routers or something. Just a thought..

Nailed it MrBrian! Thats perfect!

I am going to try to post 1 today as a test run. The only thing i will say is that i dont think that we should post the answers directly to the forum. We should PM them to the person who did the breaking so if others want to try to fix it the answers wont be in the open.

DPG

Here is a basic EIGRP lab.

Configure all connected interfaces to participate in EIGRP AS 10. Advertise R1's and R3's Loopback0 interfaces into EIGRP.
When complete you should be able to ping between the loopback interfaces.



GNS3 files: eigrp1.zip

DPG

Let's try not to post answers right away so others will have the chance to solve them. Feel free to PM me to verify the correct configs.

Advanced OSPF Lab

Finish the config so that R1 is able to ping R4's loopback interface.


GNS3 Files: ospf1.zip