From: Edwards, Andrew M (andrew.m.edwards@boeing.com)
Date: Thu Sep 16 2004 - 21:06:21 GMT-3
Right it was lab2. My mistake.
But I understood a stub area, by default, injects a type 3 summary
address into the stub area from the ABR weather it has a default route
or not. The totall stubby area (no-summary option) just stops sending
in external 5 LSA.
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/
fiprrp_r/1rfospf.htm#wp1017652
"AREA STUB
//
There are two stub area router configuration commands: the stub and
default-cost options of the area router configuration command. In all
routers attached to the stub area, the area should be configured as a
stub area using the stub option of the area command. Use the
default-cost option only on an ABR attached to the stub area. The
default-cost option provides the metric for the summary default route
generated by the ABR into the stub area.
To further reduce the number of link-state advertisements (LSAs) sent
into a stub area, you can configure the no-summary keyword on the ABR to
prevent it from sending summary LSAs (LSA type 3) into the stub area."
And
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/
fipr_c/ipcprt2/1cfospf.htm#wp1001216
So, my question is why a STUB area wouldn't meet the requirements?
Further, regarding propagating routes. When you lab this up, the /32
virtual-template routes are NOT propagated. They are, however, in the
routing table. This is similar to having all FR point-to-multipoint
subinterfaces. The result is having /32 routes of the directly
connected networks, and the true connected network address and mask.
I would have understood a question that asked to not have /32 addresses
in my routing table to meet the requirement, but not necessarily the
propagated part.
Am I the only one confused by the authors wording of the requirements?
andy
-----Original Message-----
From: john matijevic [mailto:matijevi@bellsouth.net]
Sent: Thursday, September 16, 2004 9:30 AM
To: Edwards, Andrew M; ccielab@groupstudy.com
Subject: RE: lab 1 ccie routing and switching lab scenario book
questions
Hello Andrew,
First of all I don't think this is lab 1 because there is no ospf
configuration in Lab 1, I am pretty sure what you mean is LAB 2 please
correct me if I am wrong. Now as for the first task, the reason it is a
totally stubby area is because if you just use a stub area there will be
no default route (IA route), if you use a totally stubby area that will
make sure that the other side of the totally stubby area can reach
external networks, with a default route being advertised as a single
(IA) route. As far as the second task you mentioned. Ensure that no host
routes are propagated, the answer is using no peer neighbor route, and
ip ospf network point-to-point on the loopbacks. Please make sure you
lab this scenario out. The book is not nearly as valuable, unless you
actually implement these labs. If you need rack to practice, I am giving
free access to my rack.
Sincerely,
John Matijevic, CCIE #13254, MCSE, CNE, CCEA
CEO
IgorTek Inc.
151 Crandon Blvd. #402
Key Biscayne, FL 33149
Hablo Espanol
305-321-6232
http://home.bellsouth.net/p/PWP-CCIE
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Edwards, Andrew M
Sent: Thursday, September 16, 2004 11:39 AM
To: ccielab@groupstudy.com
Subject: RE: lab 1 ccie routing and switching lab scenario book
questions
All-
I have a few questions or clarifications I wanted to throw out to the
list from lab 1. I'm looking for feedback or comments.
section 2.2
Ensure only the types of LSA propagated within OSPF area 2 are type 1,
2, and 3.
The answer key indicates that area 2 should be totally stubby area (use
no-summary on ABR). Doesn't a stub area also meet the requirements?
-------------
section 2.2
Ensure that no host routes are propagated throughout the network at this
point of the lab.
The virtual-template and virtual-access interface /32 routes are not
propagated. They are just in the routing table as connected on R1, R4,
and R6. Without the 'no peer neighbor' statement, if you go to R6, it
sees 10.100.101.2/32 (attached) and 10.100.100.0 255.255.255.240 (via
R4). Doesn't this meet the "not propagating host routes" requirement?
Without using the 'no peer neighbor' statement, the lab already doesn't
propagate the 10.100.101.2/32 from R6 to anywhere just like it doesn't
propagate the /32 from R4 or R1 point to point interfaces.
I guess the question is, how are the /32 host routes considered
propagated propagated by any router when they are directly connected? I
could see if the requirement was to ensure that no host routes were in
the routing table.....? Did anyone else have this same
understanding/confusion as I did?
Andy
This archive was generated by hypermail 2.1.4 : Fri Oct 01 2004 - 15:00:45 GMT-3