From: Godswill Oletu (oletu@inbox.lv)
Date: Thu Aug 31 2006 - 15:27:39 ART
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" <mahaguru@gmail.com>
To: "Godswill Oletu" <oletu@inbox.lv>
Cc: "Sean C" <Upp_and_Upp@hotmail.com>; "Russell Kelly (rukelly)"
<rukelly@cisco.com>; <ccielab@groupstudy.com>
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 <oletu@inbox.lv> 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" <Upp_and_Upp@hotmail.com>
>> To: "Godswill Oletu" <oletu@inbox.lv>; "Russell Kelly (rukelly)"
>> <rukelly@cisco.com>; <ccielab@groupstudy.com>
>> 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" <oletu@inbox.lv>
>> > To: "Ivan" <ivan@iip.net>; <ccielab@groupstudy.com>
>> > Cc: "tonynguyenchi" <tonynguyenchi.ccie@gmail.com>
>> > 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" <ivan@iip.net>
>> >> To: <ccielab@groupstudy.com>; "Godswill Oletu" <oletu@inbox.lv>
>> >> Cc: "tonynguyenchi" <tonynguyenchi.ccie@gmail.com>
>> >> 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" <tonynguyenchi.ccie@gmail.com>
>> >> > > To: <ccielab@groupstudy.com>
>> >> > > 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
This archive was generated by hypermail 2.1.4 : Fri Sep 01 2006 - 15:41:59 ART