Task 2.1 & Task 3.8 & Task 3.9

For Task 2.1 & Task 3.8 I didn't get the points for those saying you cannot track VC status in multipoint interfaces.

My answer to that is "WHAT IN THE WORLD ARE YOU TALKING ABOUT?" :) I am able to track VC status with end to end keepalives no matter if the interfaces is point to point or multipoint. What should've been said is I cannot track line protocol status. How does that coincide with Task2.1 ? How did I not satisfy the requirements of that task?

 

Task 3.9 I have the exact same command as in the study guide, but the proctor said it doesn't work because of the error in Task 3.8. Now, how are those tasks connected?

 

Now this makes me thinking, obviously the proctor, with lack of better words, took a dump on grading this Mock Lab. I have done 2 and 3 and didn't had these problems. So whoever graded this lab did it in a matter to throw me off instead of keeping or getting me on track. I hope I won't find this ignorance on my real attempt.

Comments

  • <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">





    I'm assuming we're talking about relation to the backup-interface
    command?  Sure, you can track the status with E2E, but the problem is
    that even if the pvc goes down, the main interface/multipoint interface
    does not!  A long as LMI is functional, your physical frame link will
    indeed stay up therefore NOT triggering the backup interface.



    HTH,






     



    Scott Morris, CCIEx4
    (R&S/ISP-Dial/Security/Service Provider) #4713,

    JNCIE-M #153, JNCIS-ER, CISSP, et al.

    JNCI-M, JNCI-ER

    [email protected]



    Internetwork Expert, Inc.

    http://www.InternetworkExpert.com

    Toll Free: 877-224-8987

    Outside US: 775-826-4344



    Knowledge is power.

    Power corrupts.

    Study hard and be Eeeeviiiil......






    andreiarnautu wrote:

    For Task 2.1 & Task 3.8 I didn't get the points for those
    saying you cannot track VC status in multipoint interfaces.

    My answer to that is "WHAT IN THE WORLD ARE YOU TALKING ABOUT?" :)
    I am able to track VC status with end to end keepalives no matter if
    the interfaces is point to point or multipoint

     

    Task 3.9 I have the exact same command as in the study guide, but
    the proctor said it doesn't work because of the error in Task 3.8. Now,
    how are those tasks connected?







    Internetwork Expert - The Industry Leader in CCIE Preparation

    http://www.internetworkexpert.com



    Subscription information may be found at:

    http://www.ieoc.com/forums/ForumSubscriptions.aspx

  • Hi Scott, thank you for the quick response!!!! I was actually editing my reply to make it more accurate. Sorry, somebody got on my dark side :)

  • <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">





    As long as it wasn't me.  :)   I usually like to know ahead of time (in
    other words make it intentional!) that I'm on someone's dark side. 
    heheehhe.






     



    Scott Morris, CCIEx4
    (R&S/ISP-Dial/Security/Service Provider) #4713,

    JNCIE-M #153, JNCIS-ER, CISSP, et al.

    JNCI-M, JNCI-ER

    [email protected]



    Internetwork Expert, Inc.

    http://www.InternetworkExpert.com

    Toll Free: 877-224-8987

    Outside US: 775-826-4344



    Knowledge is power.

    Power corrupts.

    Study hard and be Eeeeviiiil......






    andreiarnautu wrote:

    Hi Scott, thank you for the quick response!!!! I was actually
    editing my reply to make it more accurate. Sorry, somebody got on my
    dark side :)







    Internetwork Expert - The Industry Leader in CCIE Preparation

    http://www.internetworkexpert.com



    Subscription information may be found at:

    http://www.ieoc.com/forums/ForumSubscriptions.aspx

  • haha, I would've known you were messing with me:) A message for the proctor who graded my lab, "You have been targeted for termination" - T1000 [:)]

    On Thu, Jul 16, 2009 at 2:30 PM, Scott Morris <[email protected]> wrote:
    As long as it wasn't me.  :)   I usually like to know ahead of time (in
    other words make it intentional!) that I'm on someone's dark side. 
    heheehhe.







     



    Scott Morris, CCIEx4
    (R&S/ISP-Dial/Security/Service Provider) #4713,

    JNCIE-M #153, JNCIS-ER, CISSP, et al.

    JNCI-M, JNCI-ER

    [email protected]



    Internetwork Expert, Inc.

    http://www.InternetworkExpert.com

    Toll Free: 877-224-8987

    Outside US: 775-826-4344



    Knowledge is power.

    Power corrupts.

    Study hard and be Eeeeviiiil......






    andreiarnautu wrote:

    Hi Scott, thank you for the quick response!!!! I was actually
    editing my reply to make it more accurate. Sorry, somebody got on my
    dark side :)








    Internetwork Expert - The Industry Leader in CCIE Preparation

    http://www.internetworkexpert.com



    Subscription information may be found at:

    http://www.ieoc.com/forums/ForumSubscriptions.aspx





    Internetwork Expert - The Industry Leader in CCIE Preparation

    http://www.internetworkexpert.com



    Subscription information may be found at:

    http://www.ieoc.com/forums/ForumSubscriptions.aspx

  • Hi Andrei,

    Task 2.1: Whenever you configure the backup interface command you need to ask yourself what will cause the line protocol of the interface to go down.  For Frame Relay the line protocol of the main interface is based on receiving LMI keepalive from the Frame Relay cloud.  For Frame Relay subinterfaces it is based on the circuit status.

    You enabled FR EEKs only on R5's DLCI503:

    Rack19R5#show run int s0/0
    interface Serial0/0
     no ip address
     encapsulation frame-relay
     no fair-queue
     frame-relay traffic-shaping
     frame-relay interface-dlci 503 ppp Virtual-Template1
      class DLC503

    However, it's not the only DLCI assigned to R5's S0/0 interface by the FR switch via LMI. The following DLCIs are also assigned to R5's S0/0 interface - 501, 502, 504 and 513. You can use the show frame-relay pvc | include DLCI command to find out all DLCIs assigned to the interface.

    R5's FR link will not go down until all these PVCs are in the INACTIVE, DELETED or EEK DOWN state.
    If the Frame Relay circuit between R3 and R5 goes down, the other 4 DLCIs will still be in the ACTIVE state. Thus, the FR link will be up and R5's S0/1 interface will remain in the STANDBY state.

    Task 3.8: Furthermore, you applied the backup interface command to R5's Virtual-Template1 interface.
     
    Rack19R5#show run int Virtual-Template1
    interface Virtual-Template1
     backup interface Serial0/1
     ip address 158.19.0.5 255.255.255.0
     ppp chap hostname Rack19R5
     ppp chap password 0 CISCO

    For PPPoFR you need to put the command on the Serial interface not the virtual-template. The reason why is that the virtual-template's line protocol is always down, as the virtual-access is the logical instance that is used from the template.  However you can't access the virtual-access interface directly to configure it so you can't put the backup interface command on it.

    Rack19R5#show ip interface brief | i Serial0/1|Virtual-Template1
    Serial0/1                  158.19.45.5     YES NVRAM  up                    up     
    Virtual-Template1          158.19.0.5      YES NVRAM  down                  down   

    Does it make sense?

    Task 3.9 says "R4 should send a route to R5 when the HDLC link IS UP that would allow R5 to have full reachability THROUGH R4". According to Task 3.8 R5's HDLC link should be up ONLY when FR connection goes down. So, when R5's FR link is up it shouldn't receive the default route from R4. In your case, R5's S0/0 is up, but it still receives the default route from R4.

  • To be more clear, because your 3.8 is broken (your backup interface will never come up), then 3.9 clearly isn't going to work either.

Sign In or Register to comment.