From: Emmanuel Oppong (e-oppong@xxxxxxxxx)
Date: Wed Feb 20 2002 - 03:57:05 GMT-3
You may try emailing Sole...I think he will reply
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
Andy Pilcher
Sent: Tuesday, February 19, 2002 7:58 PM
To: ccielab@groupstudy.com
Subject: Solie: Darth Reid solution errors?
Ok, gang. I know there have been some issues with the Solie solutions
(and yes, I have the latest solutions, downloaded today). But I have a
list of things I disagree with (so far) with the Darth Reid lab. Then
again, maybe it's my lack of skill and I'm just missing some things.
Help me out, folks...
Section III: OSPF and Frame Relay
* I'll spare everyone the discussion about the OSPF process on R2--
there's been a thread.
* #4 says to configure FRTS on the PVC between R1 and R2. I see the map
classes defined, but I do not see "frame-relay traffic-shaping" on the
(sub)interfaces. Shouldn't that be there? Also, per Solie's own text
(p. 364) the CIR should be the physical port speed, and the MinCIR
should be the provider's CIR. The R1 solution's map class has the
following:
frame-relay cir 32000
frame-relay bc 155400
frame-relay be 0
frame-relay adaptive-shaping becn
I buy the last two lines, but it seems like the first two lines should
be mincir and cir, respectively. Then bc (per text on page 364) should
be 1/8 of CIR, or 4000. Similar issues on R2.
Section VI: BGP
* #1 says to "... Configure two EBGP peers to 160.100.1.254 and
160.100.2.254 in AS 2001, yielding two exit points to your AS." The
solution indicates that both R2 and R3 have two peers to AS 2010-- is
that necessary? I mean, you want redundancy in your network, but it's
the same router (R6)! The redundancy doesn't buy you anything. Prior
to viewing the solution, I had thought that meant one peer on R2, the
other on R3.
Section VII: Miscellaneous Cisco IOS Software Configuration
* #1 says to deny the following on R1's E0 in as few lines as possible:
FTP, HTTP from 131.24.194.x
FTP, HTTP from 131.25.194.x
FTP, HTTP from 135.152.1.1
FTP, HTTP from 131.24.195.x
FTP, HTTP from 131.24.193.x
(the solutions document has some modifications to the original text to
take it to the above list)
The documented solution:
access-list 102 deny tcp 129.24.192.0 102.129.7.1 eq ftp any
access-list 102 deny tcp 129.24.192.0 102.129.7.1 eq www any
Okay, let's assume that it's okay to summarize the above prefixes into a
single aggregate with the appropriate mask: 129.24.192.0 102.129.7.1.
The first octet has to summarize the following binaries:
10000011 (131)
10000111 (135)
mask: 00000100 (4) (so it's address 131, mask 4)
So where does Solie get 129 (10000001) and 102 (01100110)?
The logic holds for the second octet: summarizing 24, 25, and 152 you
get 24 for the address and 129 for the mask. But the third octet falls
apart again:
11000010 (194)
00000001 (1)
11000011 (195)
11000001 (193)
mask: 11000011
which is address 0, mask 195. Again, where does Solie get address 192
(11000000), mask 7 (00000111)? And finally, the fourth octet is
represented by "x" in the question, so it pretty much has to be address
0, mask 255.
Now, back to my original assumption: that you can summarize all the
prefixes into one. Bad assumption, I believe. If you do that with the
address and mask in the solution, you could potentially permit someone
from the 131.152.195.0 subnet, which is not even on the original list of
requirements! Seems like this is a case of over-simplification. When
you're doing route summarizations, that's one thing to not accurately
represent the original prefixes with a larger aggregate. But we're
talking about an ACCESS list here-- it's all about security. Needs to
be a little more accurate, don't you think?
Section VIII: IPX Configuration
* #1 says to configure IPX RIP on LAN interfaces and IPX EIGRP on the
Frame cloud. R1's solution has IPX RIP turned off only for network 12
(multipoint interface to R3/R4). What about the R1/R2 link? Shouldn't
it also disable RIP for network 11?
* #2 says to create a static SAP on R5. The SAP has the service on
socket 0x4, which is not one I'm familliar with. I've always created
static SAPs on socket 0x452 (the socket for SAPs). What gives?
* #3 says to filter the static SAP configured in step #2. Question:
would you need to put a filter on both the interface and the routing
process? The solution has an input-sap-filter on the serial interface
as well as a distribute-sap-list in on the EIGRP process. Perhaps I'm
showing my IPX ignorance, but wouldn't the interface filter be adequate?
Everything else I felt was either open to interpretation or reasonably
accurate. But these things are bugging me a little. And I still have
to study the dial solution a little more to make sure I understand it.
But I'd appreciate any help you guys can give in figuring out these
little points of mine. Thanx.
Andy
This archive was generated by hypermail 2.1.4 : Thu Jun 20 2002 - 13:46:28 GMT-3