LAB 4 ticket 6

hello ... according to the lab instructions those are our limitations:

 

Lab Do’s and Don’ts:

  • Do not change or add any IP addresses from the initial configuration unless otherwise specified or required for troubleshooting.
  • If additional IP addresses are needed but not specifically permitted by the task, use IP unnumbered.
  • Do not change any interface encapsulations unless otherwise specified.
  • Do not change the console, AUX, and VTY passwords or access methods unless otherwise specified.
  • Do not use any static routes, default routes, default networks, or policy routing unless otherwise specified.
  • Save your configurations often.

now, ticket 6 sas the following:


Ticket 6

  • Ensure that R6 may ping BB1 across the directly connected link.
  • Use the username/password pair cisco/cisco to access R6.

2 Points

 

i "solved" this ticket, using a similar approach to the one used on "lab 2 ticket 1" , after i noticed a failing ppp authentication i went on the virtual-template1 and i removed the authentication:

int virtual-template 1
 no ppp auth

 

according to the solution given, INE instead, fixed a AAA miss-config.

my question now is ... would my solution be consider valid? i don't see any limitation regarding removing ppp authentication.

 

ideas? if my solution would not be consider valid, can someone explain why?

Comments

  • It is my understanding that we want to enable:

    aaa new-model

    Then shut it off on the VTY lines like this:

    aaa authentication login default line

    This way the VTY will still accept the password on set on the vty lines as it did before aaa new-model was enabled.  

    You can then enable aaa authentication for PP:

    aaa authentication ppp default local

     

     

  • I used a similar approach to solve this ticket but with a less dramatic change.

    I applied: "no aaa authentication ppp default group radius" so the authentication kept at the interface level only, without aaa. I have the same doubt, if my solution would be considered valid. 

    Anyway, I have doubts about removing completely the PPP authentication... since both sides are supposed to be configured for it and we can not touch the BB routers. Did your solution actually worked, anubisg1?

    I guess maybe Cisco won't consider valid the easiest solutions like removing features instead of fixing them. Any comments from CCIE or more experienced partners?

  • Hi All,

    I would check whether a radius server group is in config.  If so, then that's probably something you want left in AAA part.

    Also, I'm seeing a lot of labs altering ACL entries; but first I would check config to see whether something else is using ACL.  An acl can be wrong on one interface or route map or class map, but entirely appropriate for another.  For example, you need to adujst ACL 100.  Before doing so, make a quick check "show run | in _100_" to see whether it is being used in unexpected places.

  • I'm currently in the CCIE R&S Bootcamp and one of the first things that Cristian told us was you are supposed to fix what's broke, not remove something as a solution. If there is a way to modify (change acl from deny to permit) allow login by using 'AAA authentication login default local' then that is what you should do.

Sign In or Register to comment.