From: Brian Dennis (bdennis@internetworkexpert.com)
Date: Tue Feb 27 2007 - 20:54:14 ART
This is actually a big problem that people run into. You never want to get
into a "comfort zone" where you don't read over the instructions or just
assume something is supposed to be done a certain way. In IEWB-RS version 4
we scramble things up so that you can never really get into a "comfort zone"
;-)
--Brian Dennis, CCIE4 #2210 (R&S/ISP-Dial/Security/SP) bdennis@internetworkexpert.com Internetwork Expert, Inc. http://www.InternetworkExpert.com Toll Free: 877-224-8987 Direct: 775-745-6404 (Outside the US and Canada)
On 2/27/07 2:01 PM, "Andre Serrao" <andreserrao@gmail.com> wrote:
> Thanks for your feedback, Marvin. I didn't read the instructions carefully, > so I just assumed we couldn't add addresses, based on comments on classes I > took in the past. I will certainly read them next time. > > My multicast question uses a specific scenario, but I was hoping even people > who doesn't have the IEWB material would be able to answer, since it's about > multicast verification. I understand that sometimes the problem may be IGP > related. Hopefully, this is not the case here. Anyway, my question is about > verification of multicast. Is there a rule to determine which source > interface is taken when using the command "ping 224.6.6.6" ? Is it > conclusive enough if I can ping with no extended commands? > > I tried to enable pim dense-mode in all interfaces, just in case it's taking > an interface that is not multicast enable. Again, I still think the proper > test specifies the source interface as the one where the server is supposed > to be, right? > > Thanks, > Andre > > > On 2/27/07, Marvin Greenlee <marvin@ipexpert.com> wrote: >> >> Nowhere is it stated that the real lab restricts you from adding new >> addresses. Read the first pages of the actual lab carefully, as they give >> you the initial guidelines for configuration. They could very well say >> something like "if you add addresses, use the same major network as your >> topology", "do not add static routes unless explicitly permitted in a >> section", "routes to null0 dynamically generated by a routing protocol are >> acceptable", etc. >> >> As far as help with the section, not everyone on this list will have that >> workbook. You may want to post some reference to what the section is >> asking >> for, or a basic explanation of the logical topology. >> >> Marvin Greenlee, CCIE #12237 (R&S, SP, Sec) >> Senior Technical Instructor - IPexpert, Inc. >> "When Will You Be an IP Expert?" >> marvin@ipexpert.com >> http://www.IPexpert.com >> >> >> >> -----Original Message----- >> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of >> Andre Serrao >> Sent: Tuesday, February 27, 2007 3:28 AM >> To: Cisco certification >> Subject: IEWB v3.0 Full Lab 9 q6.2 >> >> First Question: >> Solutions guide shows new addresses added to tunnel interfaces (e.g. >> 148.1.13.1). That should NOT be correct, right? You have to use ip >> unnumbered serial 0/0, in my opinion, since the real lab restricts us from >> adding new addresses. >> >> Rack1R1# >> interface Tunnel0 >> ip unnumbered Serial0/0 >> ip pim dense-mode >> tunnel source Loopback0 >> tunnel destination 150.1.3.3 >> >> >> Rack1R3# >> interface Tunnel0 >> ip unnumbered Serial0/0.302 >> ip pim dense-mode >> tunnel source Loopback0 >> tunnel destination 150.1.1.1 >> >> Second Question: >> I am trying to verify if my answer is correct. My config is very similar >> to >> the config in the solutions guide, except for the addressing of the >> tunnel. >> >> Using the solutions guide method of verification, I get nothing. >> Rack1R3#ping 224.6.6.6 repeat 5 >> >> Type escape sequence to abort. >> Sending 5, 100-byte ICMP Echos to 224.6.6.6, timeout is 2 seconds: >> ..... >> >> However, if I ping sourcing from my fa0/0 (where my server is supposed to >> be), it does work (look output). So, what is the best method to verify >> this? >> Which one proves that the config is right? >> >> >> Rack1R3(config)#do ping >> Protocol [ip]: >> Target IP address: 224.6.6.6 >> Repeat count [1]: >> Datagram size [100]: >> Timeout in seconds [2]: >> Extended commands [n]: y >> Interface [All]: tunnel0 >> Time to live [255]: >> Source address: 148.1.3.3 >> Type of service [0]: >> Set DF bit in IP header? [no]: >> Validate reply data? [no]: >> Data pattern [0xABCD]: >> Loose, Strict, Record, Timestamp, Verbose[none]: >> Sweep range of sizes [n]: >> Type escape sequence to abort. >> Sending 1, 100-byte ICMP Echos to 224.6.6.6, timeout is 2 seconds: >> Packet sent with a source address of 148.1.3.3 >> >> Reply to request 0 from 148.1.68.6, 96 ms >> <<<<<------------------------------------------------------| >> >> >> >> >> --------------------------------- >> >> _______________________________________________________________________ >> Subscription information may be found at: >> http://www.groupstudy.com/list/CCIELab.html > > _______________________________________________________________________ > Subscription information may be found at: > http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Thu Mar 01 2007 - 07:38:48 ART