"when the link is down..."

I've run across lots of scenarios while studying which contain statements such as "ensure full connectivity is maintained in the event the link between SW1 and R6 is down."

 

Sometimes it's easy to see the reason full connectivity would be maintained, and other times I feel like it's not so easy and I spend a lot of time trying to see the fault.

 

Does anyone have any methods or perspectives they can share on how they mentally approach such situations?

 

I'd be very interested to see how other people look at it.

 

thanks in advance for any comments.

Comments

  • JoeMJoeM ✭✭✭

    The example you are giving is standard for the need of a backup/alternative route -- redundancy.  

    It is not necessary to know a reason for the failure. For verification purposes, shut down an interface (or change a frame map).  Be creative for verification purposes only -- and then put it back the way it was.  ;-)


    "ensure full connectivity is maintained in the event the link between SW1 and R6 is down."

    A couple of basic reasons for this statement:

              routing protocol scenarios  (many)

              backup interface x/x  (command)

  • You just need to get used to it. Some cases are more obvious than others - eg if OSPF is involved the first thing to look at is if virtual links are needed.

    My method when I totally don't have any idea is to go back to my tcl script. This requires you to get full connectivity before you can start looking at the link down case. Then you just take the link down, run the script again and see what has changed. Sometimes you will see that whole areas of the network have lost connection, other times it will be more subtle. Once you know which devices have lost access to what you might have a good idea, eg if all EIGRP devices can no longer contact OSPF it is probably redistribution. If you still can't narrow it down, start running tracert to find out on which specific device the connectivity has been lost.

    One key point to remember is that the issue can be in either direction - there are plenty of scenarios where you will tracert and find the device where it is failing, but that device doesn't have connectivity issues. Quite often this is down to the reverse route back from the destination being broken.

  • Hi JoeM and A-G,

     

    Thanks for your replies.

     

    I think most of the straighforward solutions such as needing a backup link or a backup protocol are pretty easy for me to spot.

     

    What I feel like I waste too much time on are all of the ones where there's a hidden reachability problem that't not obvious.

     

    Ones that come to mind are:

     

    routing loops, virtual links (protocol partitioning), split horizon issues, summarization, BGP path selection

     

    The TCL script idea is a good one.  And looking in more directions than the first too.

     

    Something else I was kind of looking at goes along with your suggestion about OSPF and Virtual Links.

     

    I'm trying to start asking myself "What type of fault issues are inherent with this design and or protocol?"

     

    Sort of taking a proactive approach to find the faults before they exist.

     

    For example, in a hub and spoke, split horizon could get you. etc.

     

  • JoeMJoeM ✭✭✭

    Hi SPnetwork,


    This comes with practice and expertise on each given protocol and scenario.   Practice Practice Practice  each protocol.

    I think most of the straighforward solutions such as needing a backup link or a backup protocol are pretty easy for me to spot.

    What I feel like I waste too much time on are all of the ones where there's a hidden reachability problem that't not obvious.

    The less we understand a protocol, the more hidden the problem will be.

    routing loops

    First things first.  

    1. Draw Redistribution Map (outlined in a PETR blog here someplace).
    2. Understand the Administrative Distances (internal/external) for all IGP protocols.
    3. Implement a strategy that will resolve any issues.

    NOTE:  Workbook-2  has a lot of scenarios and solutions.

    Understand why we would have virtual-links.  Also think ahead to link failures.  Will Areas stay connected?

    Understand the reason for split-horizon.  Purpose?   How does it work on hub-and-spokes?  Which protocols?

    summarization effects length of a route.  It can be used as part of a strategy for backup or selecting an exit

    Learn the BGP attributes. This is a must. The workbook scenarios will help you with remembering/learning how to match a solution with the goal.

    practice practice practice     FUN after learning it.  ;-)

     

    The TCL script idea is a good one.  And looking in more directions than the first too.

    This is verfication.  I think if we just do it at the start, we might be all over the place, when a later task might fix it.  Time Conservation.  So, although this is a great verification tool to use, it comes AFTER you have applied the solutions. 


    Finally, do not worry too much about knowing everything.  Stay on the lesson (task) and try to learn what is being taught.  This is what the workbooks are for, to teach and remind us of many scenarios.  Things will become clearer with practice. 

    My 2cents after finishing WB-1 and 2  more than once.  The fog is clearing.  ;-)



     

     

  • JoeM,

     

    I meant to write thanks for your notes.  They are all very good!

     

    I can see what you mean, the confusion might be from not knowing it quite well enough.  I've been working through a lot more full scale labs in the past week or so and I can see the more I run across these scenarios, the subtle word differences look less and less subtle.

     

    Thanks!

  • JoeMJoeM ✭✭✭

    Glad it helped.  

    I agree with you about the subtle wording differences.   It is very gratifying to read a task, and understand exactly what is being asked.   I remember alumni saying it will be clear once we understand the given technology.    It is true.

Sign In or Register to comment.