Trouble Ticket 5 Frame Relay/ISDN Backup Lab

On the WAN you are interfacing with service providers no matter what service you use. When it is critical that remote offices communicate with headquarters or each other, normally some type of automatic failover is in place until the network recovers. Redundancy is one thing; problem diagnosis is another.

Suppose you get a call from a user indicating that “things are slow.” Slow compared to what? Is the underlying cause a throughput issue or that of response time. A large file transfer will be limited by bandwidth, for example, whereas a transaction processing system will be limited by latency (lots of end-to-end trips). Ultimately, you must characterize whether you are dealing with a user complaint or an application requirement. To do that, it is important to understand the behavior of the application and the protocol stack from end to end.

This is not intended to be a design book, but internetworks clearly operate more efficiently if they are designed well. My point is that your issues on the WAN may not just be configuration-oriented. Finding faults and understanding why they occurred may mean you have performance issues that traffic sharing and quality of service (QoS) can assist with or you may in fact need more bandwidth. Many times we think bandwidth solves all, when in fact it doesn't shrink geography. These issues are beyond the scope of the book but are becoming more and more important in everyday network support. Ensure you properly design your networks to begin with and that you are prepared to support them with the right tools in your tool bag.

In this Trouble Ticket, you must play the role of the end user and the service provider and take care of all issues. Verify that Frame Relay is working and using the ISDN link for a backup. Start your testing with hosta and work your way around to hostb to spot the issues to draw you closer to the real problem areas.

The physical devices and wires have not changed, but the logical topology has been adjusted somewhat. Update your drawing as per Figure 10-8 after you discover the new changes.

Figure 10-8. Trouble Ticket 5 Frame Relay/ISDN Backup


The swan keeps passing packets to the duck router to get to kentnarrows. I want you to assume the T1 between swan and duck is quite saturated, however. Send all packets from swan to kentnarrows and its hosts by way of the goose router. Likewise, packets coming from hosta and hostb should not go through the chesapeakebay switch to get to the swan router. In addition, chesapeakebay should take the shortest route to the hosts.

Congratulate yourself when you can successfully console and telnet to kentnarrows, chesapeakebay, and knappsnarrows from hosta. A current syslog capture display is in Example 10-23 if it can be of any help.

Example 10-23. Trouble Ticket 5 Syslog Capture
Aug 01 13:37:41 local Listening for Syslog messages on IP address:
    172.16.1.42
Aug 01 13:38:45 172.16.2.9 58: Aug  1 01:39:09.524: %SYS-5-CONFIG_I:
    Configured from console by console
Aug 01 13:40:34 172.16.1.41 82: Aug  1 01:40:59.069: %SYS-5-CONFIG_I:
    Configured from console by console
Aug 01 13:41:53 172.16.1.18 136: Aug  1 01:42:17.984: %SYS-5-CONFIG_I:
    Configured from console by console
Aug 01 13:42:25 172.16.1.18 137: Aug  1 01:42:46.992: %SYS-5-CONFIG_I:
    Configured from console by console
Aug 01 13:44:59 172.16.3.10 68: Aug  1 01:45:24.693: %LINK-3-UPDOWN:
    Interface BRI0:1, changed state to down
Aug 01 13:44:59 172.16.3.10 69: Aug  1 01:45:24.725: %LINK-3-UPDOWN:
    Interface BRI0:2, changed state to down
Aug 01 13:44:59 172.16.3.10 70: Aug  1 01:45:24.817: %LINK-3-UPDOWN:
    Interface BRI0, changed state to up
Aug 01 13:45:00 172.16.3.10 71: Aug  1 01:45:25.029: %ISDN-6-LAYER2UP:
    Layer 2 for Interface BR0, TEI 102 changed to up
Aug 01 13:45:00 172.16.3.10 72: Aug  1 01:45:25.201: %ISDN-6-LAYER2UP:
    Layer 2 for Interface BR0, TEI 103 changed to up
Aug 01 13:45:23 172.16.3.10 73: Aug  1 01:45:48.729: %ISDN-6-LAYER2DOWN:
    Layer 2 for Interface BRI0, TEI 102 changed to down
Aug 01 13:45:23 172.16.3.10 74: Aug  1 01:45:48.733: %ISDN-6-LAYER2DOWN:
    Layer 2 for Interface BRI0, TEI 103 changed to down
Aug 01 13:45:23 172.16.3.10 75: Aug  1 01:45:48.773: %LINK-5-CHANGED:
    Interface BRI0, changed state to standby mode
Aug 01 13:45:23 172.16.3.10 76: Aug  1 01:45:48.805: %LINK-3-UPDOWN:
    Interface BRI0:1, changed state to down
Aug 01 13:45:24 172.16.3.10 77: Aug  1 01:45:48.837: %LINK-3-UPDOWN:
    Interface BRI0:2, changed state to down
Aug 01 13:46:00 172.16.3.10 78: Aug  1 01:46:24.885: %SYS-5-CONFIG_I:
    Configured from console by console
Aug 01 13:47:27 172.16.3.10 80: Aug  1 01:47:51.733: %FR-5-DLCICHANGE:
    Interface Serial1 - DLCI 600 state changed to ACTIVE
Aug 01 13:47:27 172.16.3.10 81: Aug  1 01:47:51.733: %LINEPROTO-5-UPDOWN:
    Line protocol on Interface Serial1.500, changed state to up
Aug 01 13:47:48 172.16.3.10 87: Aug  1 01:48:13.345: %SYS-5-CONFIG_I:
    Configured from console by console
Aug 01 13:50:16 172.16.3.10 88: Aug  1 01:50:38.612: %SYS-5-CONFIG_I:
    Configured from console by console
Aug 01 13:58:38 172.16.1.18 138: Aug  1 01:59:00.391: %SYS-5-CONFIG_I:
    Configured from console by console
Aug 01 14:00:25 172.16.3.10 89: Aug  1 02:00:49.985: %FR-5-DLCICHANGE:
    Interface Serial1 - DLCI 500 state changed to DELETED
Aug 01 14:00:36 172.16.1.18 139: Aug  1 02:01:00.914: %FR-5-DLCICHANGE:
    Interface Serial0 - DLCI 600 state changed to INACTIVE
Aug 01 14:00:36 172.16.1.18 140: Aug  1 02:01:00.914: %LINEPROTO-5-UPDOWN:
    Line protocol on Interface Serial0.600, changed state to down
Aug 01 14:00:45 172.16.1.18 141: Aug  1 02:01:11.014: %LINK-3-UPDOWN:
    Interface BRI0:1, changed state to down
Aug 01 14:00:45 172.16.1.18 142: Aug  1 02:01:11.046: %LINK-3-UPDOWN:
    Interface BRI0:2, changed state to down
Aug 01 14:00:45 172.16.1.18 143: Aug  1 02:01:11.134: %LINK-3-UPDOWN:
    Interface BRI0, changed state to up
Aug 01 14:00:46 172.16.1.18 144: Aug  1 02:01:11.358: %ISDN-6-LAYER2UP:
    Layer 2 for Interface BR0, TEI 104 changed to up
Aug 01 14:00:46 172.16.1.18 145: Aug  1 02:01:11.522: %ISDN-6-LAYER2UP:
    Layer 2 for Interface BR0, TEI 105 changed to up
Aug 01 14:01:36 172.16.1.18 146: Aug  1 02:02:00.903: %FR-5-DLCICHANGE:
    Interface Serial0 - DLCI 600 state changed to DELETED
Aug 01 14:01:36 172.16.1.18 147: Aug  1 02:02:01.899: %LINEPROTO-5-UPDOWN:
    Line protocol on Interface Serial0, changed state to down

NOTE

At this point, you should be putting to practice many of the CatOS/IOS commands you have worked with throughout the book. Once again, your solution should not just be to compare running configurations, but rather use a methodical plan. Use the divide-and-conquer layered approach and practice commands such as ping, trace, show, clear, and debug.


Trouble Ticket 5 Frame Relay/ISDN Backup Lab Solution

Use the following list to make sure you found and fixed all the issues I planned. There may be others, too.

heron (r2) issues:

  • The no ip split-horizon statement on s1.

goose (r3) issues:

  • You need to add an ip ospf cost statement to interface s0/2.

  • The access list is preventing hosta from telnetting to knappsnarrows.

crab (r5) issues:

  • The backup interface command was on the main s1 interface rather than the subinterface.

  • ISDN switch type on interface.

  • Data-link connection identifiers (DLCIs).

  • Missing service profile identifier (SPID).

swan (r6) issues:

  • Username statement.

  • Authentication was Password Authentication Protocol (PAP) rather than Challenge Handshake Authentication Protocol (CHAP).

  • Frame Relay compression.

  • DLCIs.

  • Missing dialer-group statement, so no interesting traffic was defined.

  • ip ospf cost statement is too high of a cost.

ferry (r7) frame switch issues:

  • Incorrect frame DCE statement on s0.

  • Route statements.

chesapeakebay (s1) issues:

  • Password recovery.

kentnarrows (s2) issues:

  • Password recovery for secret and telnet passwords.

When you can successfully console to all devices and telnet to kentnarrows, chesapeakebay, and knappsnarrows from hosta, congratulations are in order. Remember to make sure the other initial requirements are operational, too.

NOTE

I realize that you are used to telnetting from one device to another, but part of the requirement for the remaining Trouble Tickets is for you to console directly to devices as well. Please do that to make sure you find all the issues I intended.


Compare your final saved fixed configurations to the tt5 fixed configs file. Add any additional notes to your drawing and tables.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.145.17.46