Job Search, Job Listing, Opportunity
Work at home job, job vacancy
find a job, vacancy list, cari lowongan
Butuh, Segera, secretary, director

InternetworkExpert Ver3 Lab 13 Task 4.2 RIP


My personal preference is to always use a route-map when redistributing routes from one IGP to another (or from connected into an IGP)
I’m not sure I understand your comments about restrictions when using a route-map. Using a route-map provides a lot more flexibility and control.
Perhaps I am wrong here, but I don’t see how using a route-map is a negative when going from connected –> rip.
Regards,
Alex
—–Original Message—– From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Godswill Oletu Sent: Friday, 1 September 2006 3:51 AM To: Sean C; Russell Kelly (rukelly); ccielab@groupstudy.com Subject: Re: InternetworkExpert Ver3 Lab 13 Task 4.2 RIP
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 >> > > > >> > > > >>

Bookmark this post:These icons link to social bookmarking sites where readers can share and discover new web pages.
  • blinkbits
  • BlinkList
  • blogmarks
  • co.mments
  • connotea
  • del.icio.us
  • De.lirio.us
  • digg
  • Fark
  • feedmelinks
  • Furl
  • LinkaGoGo
  • Ma.gnolia
  • NewsVine
  • Netvouz
  • RawSugar
  • Reddit
  • scuttle
  • Shadows
  • Simpy
  • Smarking
  • Spurl
  • TailRank
  • Wists
  • YahooMyWeb
keywords found: using ammunition version broader production corresponding appyling 

Leave a Comment

Related Post