From: Marc Russell (mrussell@xxxxxxxxxxxxxx)
Date: Thu Feb 07 2002 - 16:35:02 GMT-3
Yes, the SNMP problems were fixed in the new 1-day version that will be
available next week.
Marc Russell
www.ccbootcamp.com
-----Original Message-----
From: R. Benjamin Kessler [mailto:ben@kesslerconsulting.com]
Sent: Saturday, February 02, 2002 10:03 PM
To: CCIELab
Subject: Bootcamp Lab 8a - questions about the answer key for R1
OK, I've done the famous Lab 8a and have the following questions about the
supplied "answer" configs - specifically dealing with R1's config
It seems that SNMP is not configured per the lab requirements. In the lab I
have, it says that only host 137.20.40.17 should be able to connect to with
the RW community; this host should also be the target for trap messages. In
both instances the answer key references the host 137.20.64.7.
The lab indicates that the trap messages should be sourced from R1's E0
interface; I used the command 'snmp-server trap-source Ethernet0' but there
is no mention of this in the supplied config for R1.
RO access is to be restricted to "any devices on the subnet used on the
ethernet in area 0" - the supplied config shows that ACL 3 is configured to
permit 137.20.64.0/20 however ACL 2 is applied to the SNMP command
setting-up RO access.
I'm being a bit nit-picky about the SNMP stuff, I know - simple typos; but I
didn't see any references to this in the Groupstudy archives or on
ccbootcamp's web site and since Marc is re-doing all the labs he might want
to catch and fix this (if he hasn't already). Obviously, if this were the
real lab, Marc wouldn't have gotten the SNMP points :)
Another slightly nit-picky thing is about ACL 65 (used in the OSPF -> BGP
redist route-map); it references the /20 ISDN subnet between R5 and R6 but
has a reverse mask that would be used for a /24. It 'works' - but a host
entry in the ACL (i.e. no reverse mask) would work when simply matching
routes for redistribution. Would this be considered "wrong" in the lab? I'm
thinking yes, but wanted to poll the audience.
OK, something of more substance that I have a question about is the EBGP
peering between R1 and R7. We were forced into EBGP-multihop when the
instructions told us to source the advertisements from R1's loopback
interface. Pretty simple, I added the "ebgp-multihop 2" parameter to both
R1 and R7 for their neighbor statements to each other. Looking at the
answers though, R1 didn't have the command. I figured it must be a typo but
I tried removing the command from R1 and cleared the connection. I assumed
that the peer session wouldn't be established between the two routers but I
was wrong. What gives? I checked Halabi (2nd ed., pp 306-307) and Doyle
vol II (pg 184) and they put the multihop command on both routers but their
examples were also a bit different than this one. I need a bit of
clarification here. My working theory is that R7 obviously needs the
increased TTL to reach R1's loopback and that R1 doesn't decrement the TTL
as the bgp packets are 'routed' internally from the loopback interface to
the ethernet. Is like the situation where packets sourced from the router
ignore any ip access-group xxx out commands that may try to block them?
If anyone can point me to some docs discussing this type of config that
would be great. I'm guessing that my putting the multihop 2 command on both
routers would be wrong and cost me many BGP points....hmmm, 7 days until the
big dance and I'm less confident every day :(
Thanks for any thoughts, feedback, etc.
This archive was generated by hypermail 2.1.4 : Thu Jun 20 2002 - 13:46:15 GMT-3