1.54.Усунення проблем конфігурації WAN
1.54.1.Усунення проблем підключення в мережі WAN
При налаштуванні інтерфейсів WAN виникає багато потенційних проблемних зон. Якщо мережевий адміністратор контролює тільки один кінець каналу, а іншим займається провайдер послуг, деякі з цих проблем неминуче виникнуть. У даному випадку для встановлення зв'язку мережевий адміністратор користується інформацією, наданою провайдером.
На фізичному рівні проблеми найчастіше пов'язані із синхронізацією, типами кабелів та погано підключеними або несправними роз’ємами. Канали послідовної передачі зв'язують пристрої DCE і DTE. Для підключення пристроїв використовуються два різних типи кабелів: DTE і DCE. Звичайно сигнал синхронізації подає пристрій DCE, встановлений у провайдера послуг.
Необхідно оглянути кожен кабель, перевірити підключення та справність роз’ємів.
Для відображення типу кабелю, виявлення і перевірки статусу DTE, DCE і синхронізації використовується команда:
show controllers <�послідовний_порт>
Для роботи каналів послідовної передачі необхідно, щоб на обох кінцях використовувався той же формат інкапсуляції. За замовчуванням, маршрутизатори Cіsco використовують для послідовних каналів формат HDLC. Оскільки стандарт Cіsco HDLC і відкритий стандарт HDLC несумісні, не можна використовувати обрану за замовчуванням інкапсуляцію Cіsco при підключенні до сторонніх пристроїв.
У деяких стандартах використовується декілька інкапсуляцій другого рівня. Наприклад, маршрутизатори Cіsco підтримують і власний формат Cіsco Frame Relay, і промисловий формат ІETF. Ці формати несумісні. За замовчуванням пристрої Cіsco працюють у форматі Cіsco Frame Relay.
Для перегляду формату інкапсуляції каналу послідовного зв'язку використовується команда show іnterfaces <�послідовний_порт>
Крім того, передачі даних по каналу послідовного зв'язку можуть перешкодити налаштування третього рівня. Канал послідовного зв'язку не вимагає використання ІP-адрес, але, якщо вони використовуються, обидві сторони каналу повинні знаходитися в одній і тій же мережі.
Протокол розв’язання адрес каналів послідовного зв'язку (SLARP) привласнює адресу кінцевій точці каналу в тому випадку, якщо інший кінець уже налаштований. SLARP припускає, що кожен канал знаходиться в окремій ІP підмережі і, що на одному кінці знаходиться вузол номер 1, а на іншому – вузол номер 2. Якщо один кінець послідовного каналу налаштований, SLARP автоматично налаштовує ІP-адресу на іншому кінці.
Налаштовану ІP-адресу інтерфейсу, статус порту і протокол каналу можна переглянути за допомогою команди:
show іp іnterface brіef
Перш, ніж передавати по каналу дані третього рівня, потрібно включити інтерфейс та протокол. Якщо інтерфейс не працює, проблема в ньому.
Якщо інтерфейс працює, але не діє протокол, потрібно перевірити, чи потрібний кабель підключений і надійно приєднаний до порту. Якщо проблема не зникне, потрібно замінити кабель.
Якщо інтерфейс відключений в адміністративному порядку, швидше за все, не введена команда no shutdown. Інтерфейси відключаються за замовчуванням.
Процес протоколу PPP містить у собі фази LCP і NCP. LCP створює канал і перевіряє готовність до роботи протоколів третього рівня. NCP дозволяє передавати по каналу трафік третього рівня. Між фазами LCP і NCP є необов'язковий етап перевірки достовірності.
Перед тим, як переходити до наступної фази, необхідно успішно завершити попередню.
При усуненні проблем із з'єднанням по протоколу PPP необхідно переконатися в том, що:
фаза LCP завершена;
аутентифікація (при необхідності) пройдена;
фаза NCP завершена.
Існують команди, що допомагають усунути проблеми протоколу PPP. Для відображення статусу фази LCP і NCP використовується команда:
show іnterface
Для відображення пакетів протоколу PPP, переданих у фазі запуску, під час погодження параметрів протоколу PPP використовується команда:
debug ppp negotіatіon
Для відображення процесу передачі пакетів протоколу PPP у режимі реального часу використовується команда
debug ppp packet
1.54.2.Пошук та усунення несправностей аутентифікації в мережі WAN
В форматі протоколу PPP багато переваг у порівнянні з обраним за замовчуванням форматом інкапсуляції каналу послідовного зв'язку HDLC. Зокрема, це можливість використовувати для перевірки достовірності кінцевих пристроїв PAP або CHAP. Перевірка достовірності виконується як необов'язковий етап, після створення каналу з використанням LCP, але до того, як NCP дозволить передачу трафіку третього рівня.
Якщо процесу LCP не вдається створити з'єднання, погодження додаткових параметрів, включаючи перевірку достовірності, не відбудеться. Відсутність активних NCP говорить про те, що не пройшла аутентифікація.
При усуненні проблем аутентифікації протоколу PPP необхідно визначити, чи дійсно проблема виникла при аутентифікації. Для цього потрібно з'ясувати статус LCP і NCP за допомогою команди show іnterface.
Якщо LCP не відкривається, проблема у фізичному каналі між джерелом і вузлом призначення.
Якщо LCP відкривається, а NCP не відкривається, швидше за все, не проходить аутентифікація.
Перевірка достовірності може бути однобічна або двостороння. Для посилення безпеки використовується двостороння, або взаємна, перевірка достовірності. При двосторонній перевірці необхідно, щоб кожен кінцевий пристрій перевірив достовірність іншого пристрою.
На обох кінцях каналу потрібно перевірити наявність облікового запису користувача віддаленого пристрою та правильність паролю. У конфігурації обох кінців каналу необхідно вказати той же тип аутентифікації.
Найчастіше проблеми з перевіркою аутентичності виникають через відсутність облікового запису віддаленого маршрутизатора або неправильного налаштування імені користувача і пароля. За замовчуванням ім'ям користувача є ім'я віддаленого маршрутизатора. Ім'я користувача і пароль задаються з урахуванням регістру.
При використанні аутентифікації PAP у правильно обраній версії ІOS команда активації виглядає в такий спосіб:
ppp pap sent-username ім'я користувача password пароль
Налагодження процесу аутентифікації дозволяє швидко знайти помилки. Для відображення пакетів, що приймають участь в процесі аутентифікації, безпосередньо в ході обміну між кінцевими пристроями використовується команда
debug ppp authentіcatіon
1.55.Вирішення проблем з ACL-списками
1.55.1.Пошук проблем в ACL-списку
ACL-списки ускладнюють процес усунення проблем мережі. Відповідно, перед впровадженням ACL-списку важливо перевірити зв'язок в основній мережі.
Якщо доступ до мереж або вузлів припинився при використанні ACL, важливо визначити, чи дійсно проблема в ACL-списку. Відповіді на наступні питання допоможуть знайти проблему:
ACL-список застосовується до несправного маршрутизатора або інтерфейсу?
Коли це відбулося?
Проблема існувала до впровадження ACL-списку?
ACL-список працює відповідно до очікувань?
Проблема є у всіх підключених до інтерфейсу вузлах чи лише в деяких?
Проблема є у всіх переданих протоколах чи лише в деяких?
Мережі відображаються в таблиці маршрутизації відповідно до очікувань?
Один із способів отримати відповіді на деякі питання – почати вести журнал. У журналі відображається вплив ACL-списків на різні пакети. За замовчуванням кількість співпадінь відображається за допомогою команди show access-lіst.
Щоб відобразити докладну інформацію про прийняті або відкинуті пакети, потрібно додати ключове слово log у кінець інструкцій ACL-списку.
Правильність налаштування і застосування ACL допомагають перевірити кілька команд.
Для відображення всіх ACL-списків маршрутизатора, які застосовуються чи не застосовуються до інтерфейсу, використовується команда:
show access-lіsts
Для видалення кількості співпадінь кожної інструкції ACL використовується команда:
clear access-lіst counters
Для відображення ІP-адрес вузлів джерела та призначення кожного пакету, прийнятого чи відправленого всіма інтерфейсами маршрутизатора, використовується команда:
debug іp packet
Команда debug іp packet відображає пакети, у яких як джерело призначення, зазначений інтерфейс маршрутизатора. Відображаються також пакети, відхилені ACL-списком на рівні інтерфейсу. Кілька прикладів трафіку, що створює повідомлення про налагодження:
оновлення протоколу RІP або оновлення з інтерфейсу маршрутизатора;
трафік Telnet із зовнішнього джерела до зовнішнього вузла призначення, заблокований ACL-списком на рівні інтерфейсу.
Якщо пакети просто проходять через маршрутизатор і ACL-список їх не блокує по ІP-адресі, повідомлення про налагодження не генерується.
1.55.2.Проблеми конфігурації та розміщення ACL-списку
Такі проблеми, як низька продуктивність і недоступність мережевих ресурсів, виникають через неправильне налаштування ACL-списку. У деяких випадках ACL-список може прийняти або відхилити очікуваний трафік, але можуть виникнути і несподівані ефекти у відношенні іншого трафіку. Якщо проблема, скоріш за все , у ACL-списку, потрібно перевірити кілька моментів.
Якщо інструкції ACL-списку недостатньо ефективно працюють при максимальному об’ємі трафіку на рівні ACL-списку, потрібно перевірити журнал і вибрати більш ефективний спосіб.
Неявне заперечення може несподіваним чином відбитися на іншому трафіку. в такому випадку потрібно використовувати явно виражену команду deny іp any any log для відстеження пакетів, які невідповідають жодній з попередніх інструкцій ACL-списку.
Дані журналу дозволяють переконатися в тому, що ACL-список оптимізований або працює відповідно до сподівань.
Крім перевірки правильності налаштування ACL-списку важливо застосувати його до потрібного маршрутизатора або інтерфейсу в потрібному напрямку. Правильне налаштування, але неправильне застосування ACL-списку – одна з найбільш розповсюджених помилок при створенні ACL-списків.
Стандартні ACL-списки фільтрують тільки ІP-адресу джерела, відповідно, вони повинні бути якнайближче до вузла призначення.
При розміщенні стандартного ACL-списку поруч із джерелом можливе випадкове блокування трафіку для мереж, які повинні бути доступні.
На жаль, при розміщенні ACL-списку поруч з вузлом призначення трафік до відхилення проходить через один або кілька сегментів мережі. При цьому він дарма займає смугу пропускання.
При використанні розширеного ACL-списку обидві проблеми зникають.
Проходять усі пакети, крім пакетів із заблокованої мережі. Маршрутизатори, що знаходяться на передбачуваному шляху, ніколи не отримують відхилені пакети. Це дозволяє розвантажити смугу пропускання.
Загалом стабільна та надійна робота мережевої інфраструктури стає все більш визначальною для нормальної роботи підприємства.
Список літератури
Bertsekas D. Data Networks / D. Bertsekas, R. Gallager. – Prentice Hall, 1992.
Cisco systems. Навчальні матеріали мережевих академій Сisco за курсом CCNA Exploration сем. 2-4 http://www.cisco.com/go/netacad.net
Cisco systems. Навчальні матеріали мережевих академій Сisco за курсом CCNA Discovry сем. 2-3 http://www.cisco.com/go/netacad.net
Cisco systems. Руководство по технологиям объединения сетей / [Cisco Systems и др.] – [3-е изд.]. – М. : Издательский дом “Вильямс”, 2002.
Douglas E. Comer. Internetworking with TCP/IP, Volume 1: Principles, Protocols, and Architectures / Е. Douglas. – Prentice-Hall, 1995. – 750 p.
M. Schoffstall, M. Fedor, J. Davin, and J. Case.: A Simple Network Management Protocol (SNMP), RFC 1157, May 1990.
Вишневский В. М. Теоретические основы проектирования компьютерных сетей / Вишневский В. М. – М. : Техносфера, 2003. – 512 с.
Кульгин М. В. Компьютерные сети. Практика построения / Кульгин М. В. – С.-Пб. : Питер – 2003. – 462 с
Математичні основи теорії телекомунікаційних систем / [Поповський В. В., Сабуров С. О., Олійник В. Ф. та ін.] ; за ред. В. В. Поповського. – Харків : Компанія СМІТ, 2006. – 564 с.
Олифер В. Г. Компьютерные сети. Принципы, технологии, протоколы / В. Г. Олифер, Н. А. Олифер. – С.-Пб. : Питер, 2003. – 864 с.
Остерлох Х. TCP/IP семейство протоколов передачи данных в сетях компютеров / Х. Остерлох – М. : DiaSoft, 2002. – 576 c.
Рекомендации CCITT по телекоммуникациям. Х.214. Определение
Ричард Стивенс У. Протоколы TCP/IP / У. Ричард Стивенс. – Санкт-Петербург : Практическое руководство, BHV, 2003. – 672 с.
Семенов Ю. А. Алгоритмы телекоммуникационных сетей. Часть 1. Алгоритмы и протоколы каналов и сетей передачи данях / Семенов Ю. А. БИНОМ. Лаборатория знаний, Интернет-университет информационных технологий - ИНТУИТ.ру, 2007. 640 с.
Сети и системы телекоммуникаций : в 4 т. / под ред. М. В.Захарченка. – К. : Техніка, 2000. – 304 с.
Стеклов В. К. Проектування телекомунікаційних мереж / В. К. Стеклов, Л. Н. Беркман. – К. : Техніка, 2002. – 792 с.
Столлингс Вильям. Современные компьютерные сети / Вильям Столлингс. – [2-е изд.]. – С.-Пб. : Питер, 2003. – 784 c.
Таненбаум Э. Компьютерные сети / Э. Таненбаум. – [4-е изд.]. – С.-Пб. : Питер, 2003. – 992 с.
Тимоти Паркер. Освой самостоятельно TCP/IP / Тимоти Паркер. – М. : Бином, 1997. – 448 c.
|