IEOC - INE's Online Community

after spending a coupling of hours trying this trick with access-list/policy-map/neighbor statments/ etc;... i finally went back to my 2nd idea to use the authentication on interface.

So after spending about two hours getting this figured out (yes, i would have bombed the lab at this point) i got everything working to my satisfaction and now look at the SG for there take on the answer.

I dont see the point in using authentication between R4 and R6 LAN segment because its not like another router is on this segment.

passive interfaces...they used alot of them.  i know its best practice but only used one passive interface and thats on the R6-to-BB1 serial 1/0...

also i didnt use a network statment "54.1.2.0" since there was no need for rip adjacency and i was just going to redistro connected for part of requirment (advertise frame-relay link between R6 and BB1) <--i hope my thoughts on this are right....

Also in the SG ...on R3 they have network statment for the 142.1.34.0 LAN segment.  it doesnt ask for this ...

RIP: ignored v2 packet from 204.12.1.254 (illegal version)
RIP: ignored v2 packet from 54.1.2.254 (illegal version)

0. distribute-list
1. distance
2. authentication
3. send/receive version
4. redistribute connected+neighbour stats for R6-R3 segment

Is there any reason we can't instead use the combination of "passive interface" and neighbor statements on R3/R6 to turn things into unicasted updates, rather than broadcast/multicast updates?

My configuration on R3:

Rack1R3#sh run | section router rip
router rip
 version 2
 passive-interface default
 network 204.12.1.0
 neighbor 204.12.1.6
 distance 255 204.12.1.254 0.0.0.0
 no auto-summary

and on R6:

Rack1R6#sh run | section router rip
router rip
 version 2
 passive-interface default
 no passive-interface Ethernet0/1
 network 54.0.0.0
 network 142.1.0.0
 network 204.12.1.0
 neighbor 204.12.1.3
 distance 255 204.12.1.254 0.0.0.0
 distance 255 54.1.2.254 0.0.0.0
 no auto-summary

I think this should prevent us from taking in or sending out routing information from the BB3 or BB1 routers, and should make full connectivity otherwise, assuming R4 speaks correctly to R6, which it will.

Rack1R4#sh run | section router rip
router rip
 version 2
 passive-interface default
 no passive-interface Ethernet0/0
 network 142.1.0.0
 no auto-summary

I don't think I violate any requirement here.  Thoughts?

Second question that I just hit in checking my full reachability.... The lab guide never indicates to put the loopback of R6 into RIP, I guess we're supposed to assume it since it's part of the RIP domain.  I guess this is why going back to verify is a MUST!

How about using the gateway command with an acl identifying the routers to accept routes from?  It's another alternative.

Very good aproach, i used ACL + offset-list to achieve the same result but consider the solution of the SG, 

using passive-interface prevents from sending updates to the backbone routers but that interfaces is advertised to the internal routers.

Using authentication with an arbitraty key/password between R3 and R6 prevents from learning routes from the backbone. 

This is very good way to solve the problem if in a task you are constrained from a certain type of solution, dont use this or dont use that.

HTH

Santiago E

taburley:

 

How about using the gateway command with an acl identifying the routers to accept routes from?  It's another alternative.

Well I used the passive interface and used the neighbor command and offseting the routes to and from the backbones.. Under RIP R6 would  R3 on G0/1. Then offset the routes to and from the backbones. Here are my configs: