Go CCIE Go!! - A Cisco Certified Internetwork Expert

Thank you all.
Tony
—– Original Message —– From: “Godswill Oletu” To: “Zafar Khan” Cc: “Sean C” ; “Russell Kelly (rukelly)” ; Sent: Friday, September 01, 2006 1:27 AM Subject: Re: InternetworkExpert Ver3 Lab 13 Task 4.2 RIP
> Zafar, > > Now you have taken it way too far…. > > Why this? > > ! > router rip > ….. > distribute-list DENY_RIP in > ! > ip access-list standard DENY_RIP > deny any > ! > > Not only that, the proctor “will NEVER be able make your e0 receive or > send ANY rip traffic”, the proctor will discover that your router is an > isolated island in the entire RIP domain with no ability to accept RIP > updates from any RIP speaking device, including downstream routers? And > the proctor will have the last “grin”. > > Was that actually what was asked for? > > Any one of 1) Distribute-list w/passive interface, 2) ACL on E0 w/passive > interface, or 3)Redistribute connected should be enough. > > Take it easy. > > > Godswill Oletu > CCIE #16464(R&S). > >>>> > —– Original Message —– > From: “Zafar Khan” > To: “Godswill Oletu” > Cc: “Sean C” ; “Russell Kelly (rukelly)” > ; > Sent: Thursday, August 31, 2006 2:09 PM > Subject: Re: InternetworkExpert Ver3 Lab 13 Task 4.2 RIP > > >> What are your thoughts on this config >> >> interface Ethernet0 >> ip address 204.12.1.1 255.255.255.0 >> ip access-group TEST in >> >> router rip >> version 2 >> passive-interface Ethernet0 >> network 204.12.1.0 >> distribute-list DENY_RIP in >> no auto-summary >> >> ip access-list standard DENY_RIP >> deny any >> ! >> ip access-list extended TEST >> deny udp any any eq rip >> permit ip any any >> >> >> Unless the proctor write his own stack, I am quite positive he will >> NEVER be able to make my e0 recieve or send ANY rip traffic (grin) >> >> Regards >> Zafar >> >> >> On 8/31/06, Godswill Oletu wrote: >>> Sean, >>> >>> ! >>> router rip >>> redistribute connected >>> ! >>> >>> Should also be find, no need to use the route-map option. Moreso, it >>> appears >>> that all the other connected networks on R4 are being advertised into >>> RIP >>> via the ‘network’ statement and one will avoid the additional issues >>> that >>> might arise as a result of the restriction the ‘route-map’ will create. >>> >>> If you must use a route-map with ‘redistributed connected’ and IGP >>> redistribution is involved, watch out for the usual pitfalls that the >>> restriction on the route-map will introduction into your IGP domain and >>> resolve them. >>> >>> Thanks. >>> >>> Godswill Oletu >>> CCIE #16464(R&S) >>> >>> >>> >>> —– Original Message —– >>> From: “Sean C” >>> To: “Godswill Oletu” ; “Russell Kelly (rukelly)” >>> ; >>> Sent: Thursday, August 31, 2006 8:42 AM >>> Subject: Re: InternetworkExpert Ver3 Lab 13 Task 4.2 RIP >>> >>> >>> > Hi Godswill, >>> > >>> > What of Russell Kelly’s initial suggestion of redistributing connected >>> > with >>> > a corresponding route-map of only F0/0? >>> > >>> > Curious for your thoughts, >>> > Sean >>> > —– Original Message —– >>> > From: “Godswill Oletu” >>> > To: “Ivan” ; >>> > Cc: “tonynguyenchi” >>> > Sent: Thursday, August 31, 2006 8:03 AM >>> > Subject: Re: InternetworkExpert Ver3 Lab 13 Task 4.2 RIP >>> > >>> > >>> >> Ivan, >>> >> >>> >> From your response, we both have the same understanding, agreed >>> >> distribute-list will not stop the announcement of the route, but ACL >>> >> will >>> >> not also stop the announcement. The only thing that will stop the >>> >> announcement/advertisement is appyling a passive interface on the BB >>> > router >>> >> doing the annoucement/advertisement, but this is beyond our reach in >>> >> the >>> >> lab. So, all we can do is to stop the >>> >> announcement/advertisement/updates >>> >> from entering the FIB on R4. >>> >> >>> >> Having said that, your approach is, stop and search all traffics at >>> >> the >>> >> interface and if they are rip traffic (udp 520) drop them at the >>> > interface. >>> >> The original poster’s approach is, why disturb every traffic coming >>> >> into >>> > R4 >>> >> for a problem that can be resolved within the specific technology >>> >> (RIP), >>> >> apply a distribute-list and prevent RIP updates from that interface >>> >> from >>> >> getting into the FIB. >>> >> >>> >> Remember that, the problem here is RIP updates, first look for a RIP >>> >> solution and when that is not possible either due to restrictions in >>> >> place >>> >> or other prevailing circumstances, then other more broader approach >>> >> can >>> >> be >>> >> taken. >>> >> >>> >> If faced with a task like this either in the exam or in my production >>> >> network, ACL will be part of my arsenal, but it will not be my >>> >> ammunition >>> > of >>> >> choice to be used. Why use a Scud missile when an AK45 will take care >>> >> of >>> > the >>> >> problem? >>> >> >>> >> HTH >>> >> >>> >> Godswill Oletu >>> >> CCIE #16464 >>> >> >>> >> >>> >> —– Original Message —– >>> >> From: “Ivan” >>> >> To: ; “Godswill Oletu” >>> >> Cc: “tonynguyenchi” >>> >> Sent: Thursday, August 31, 2006 7:29 AM >>> >> Subject: Re: InternetworkExpert Ver3 Lab 13 Task 4.2 RIP >>> >> >>> >> >>> >> > Are u sure that distribute list _filter_ incoming announce? I think >>> >> > that >>> >> > “distribute-filter in” only control intalling this routes in FIB. >>> >> > >>> >> > > that should do it: >>> >> > > >>> >> > > passive interface will make sure you do not send and >>> >> > > distribute-list >>> >> will >>> >> > > take care of receiving… >>> >> > > >>> >> > > Godswill Oletu >>> >> > > CCIE #16464 >>> >> > > >>> >> > > >>> >> > > —– Original Message —– >>> >> > > From: “tonynguyenchi” >>> >> > > To: >>> >> > > Sent: Thursday, August 31, 2006 5:33 AM >>> >> > > Subject: InternetworkExpert Ver3 Lab 13 Task 4.2 RIP >>> >> > > >>> >> > > > Dear Group, >>> >> > > > >>> >> > > > The task requires: configure R4 to advertise the 204.12.1.0/24 >>> > (F0/0) >>> >> > > >>> >> > > subnet >>> >> > > >>> >> > > > via RIP, but do not send and receive RIP update on this >>> >> > > > interface. >>> >> > > > >>> >> > > > Can I do this as the following: >>> >> > > > >>> >> > > > router rip >>> >> > > > version 2 >>> >> > > > passive-interface FastEthernet0/0 >>> >> > > > network 139.1.0.0 >>> >> > > > network 150.1.0.0 >>> >> > > > network 204.12.1.0 >>> >> > > > distribute-list BLOCK_RIP in FastEthernet0/0 >>> >> > > > no auto-summary >>> >> > > > ! >>> >> > > > ip access-list standard BLOCK_RIP >>> >> > > > deny any >>> >> > > > >>> >> > > > Thanks and best regards, >>> >> > > > >>> >> > > > Tony >>> >> > > > >>> >> > > > >>> >> _______________________________________________________________________ >>> >> > > > 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 >>> >> > >>> >> > — >>> >> > Ivan >>> >> >>> >> _______________________________________________________________________ >>> >> 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 >>> >>> _______________________________________________________________________ >>> 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