Отстраняване на проблеми за маршрутизация с използване на пинг и отстраняване на грешки мрежи Cisco
Системният администратор е много често се сблъскват с маршрутните проблеми. Съвсем наскоро трябваше да се, така, че старата памет реших да напиша една статия за това малко.
Прекарването на Cisco мрежи не трябва да предизвиква трудности, а ако все пак нещо не работи така, както искате - ние ще се притекат на помощ на доброто старо време-и пинг.
За тези, които не са в този въпрос, помощната програма PING съществува във всички популярни системи, като се започне от Windows, завършваща с IOS на Cisco. С него формира ICMP пакет, съдържащ заявка за ехо. Ако след изтичането на определен период от време дистанционното устройството да бъде в състояние да се получи, обработва и изпраща отговор - като се смята, че една стабилна канал за комуникация и домакини работят правилно.
Например имам един прост начин да се диагностицира изведнъж липсва "Интернет:
- пинг 192.168.1.100 - има ли връзка с портал;
- пинг 8.8.8.8 - има ли връзка с vneshke;
- пинг ya.ru - има ли връзка с DNS-сървър;
Така че, нека да видим как можете да използвате пинг за диагностициране на проблеми с мрежата.
I пое прост топология в GNS3, тук имаме 4 рутер, R1-R4, съответно. Три / 24-ти подмрежа. Площта между рутера 1 и 2 - подмрежа 12.0.0.0/24, между 2 и 3 - 23.0.0.0/24, между 3 и 4 - 34.0.0.0/24 съответно. Това е първия октет показва, между които мрежовите рутери. Само миналата октет показва директно рутера.
Така да се каже, че, например, IP 23.0.0.3 съхраняват от R2 и R3 и R3 интерфейс принадлежи.
Топологията на мрежата ни
Маршрути в района, аз специално не назначават такива.
Преди всичко нека да се справят с основните функции на диагностичен план на Cisco.
Ще изпратим пинг до 12.0.0.1 до 12.0.0.2. Тези два интерфейса са пряко свързани, така че виждам нещо като това:
Средна пасаж пинг
Каква информация виждаме тук:
Всеки герой е "!" Е успешното приключване на пакета.
Сега малко разширяване на продукцията.
# Debug IP подробно пакет
И изпрати пинг многократно:
Подробна изход на пинг
Както можете да видите, информацията се издава на конзолата много повече. Тук имаме временна маркировка, протокол (IP), S = (източник - източник), г = (дестинация - дестинацията), името на порта (FastEthernet0 / 1), типа на ICMP (8 - искане ехо, 0 - отговор) и така нататък. г.
Защо тази информация може да бъде полезна за нас? Следните ситуации. Ние изпращане на пинг до R4 с R1. Аз не мисля, че пакетите достигат, защото рутера не знае къде да изпрати пакети към мрежата 34.0.0.0/24.
Заявката не бе успешна
Иди виж причината: unroutable (без маршрут до дестинацията). Ако ние не уточни за отстраняване на грешки, вие ще видите нещо друго. Забрани за отстраняване на грешки и да видим:
# Undebug всички
# Ping 34.0.0.4
Само "... ..", където всяка точка е неуспешно предаване пинг. Не води.
Сега нека направим малко по-различно. Предписват по подразбиране път към следващия рутера (R2), защото ние (R1) все още няма къде да изпраща пакети с изключение на него:
# Conf т
# Ip маршрут 0.0.0.0 0.0.0.0 12.0.0.2
Тук вече виждам 5 символа "U", което означава, Unroutable. Не е ясно къде е проблемът, ако ние не знаем подробностите за маршрута между маршрутизатори. На добър необходимо сега да гледам всичките четири довереник и за таблиците на кореспонденция изглежда.
Ние включват отстраняване на грешки R2 и повторете Ping:
Въпреки факта, че R2 ние просто не се прави нищо (просто включва отстраняването на грешки), в докладите си за конзолата лети всички преминаващи пакети.
Внимание! отстраняване на грешки команди могат да бъдат много интензивно процесора работа на рутера, така че трябва да ги използват с повишено внимание. По-долу ще обсъдим как можете да работите малко по-комфортно с отстраняване на грешки.
Така че, това, което виждаме в отстраняване на грешки R2 (когато пинг R1 R4):
Трансфер ICMP ехо с 12.0.0.1 до 34.0.0.4 върна резултат unroutable, тъй като рутера 2 не знае къде да изпрати пакета с. Мрежа 34.0.0.0/24 той не е бил запознат с (от ляво го 12.0.0.1, нали 23.0.0.3). Да му дадем малко намек. За активиране на тази динамична протокол за маршрутизация RIP рутери R2 и R3:
R2 # конф т
R2 (конфигурационния) # рутер RIP
R2 (конфигурационния-рутер) # мрежа 12.0.0.0
R2 (конфигурационния-рутер) # мрежа 23.0.0.0
R2 (конфигурационния-рутер) # изход
R3 # конф т
R3 (конфигурационния) # рутер RIP
R3 (конфигурационния-рутер) # мрежа 23.0.0.0
R3 (конфигурационния-рутер) # мрежа 34.0.0.0
R3 (конфигурационния-рутер) # изход
Това означава, че рутера уточнява мрежата известно за тях. В рутер 2 мрежа 12 * и 23 *, и в 3-23 * и 34 *, съответно. За RIP, ще говорим по-късно. Така че, ние сме съобщи нашата мрежа. Повторете с пинг-заявка R1 до R4. На R1 все още е тъп. Но включването на отстраняване на грешки пакети за R4 показва различна картина:
Пакети пристигат, но не изчезват
S = 12.0.0.1, г = 34.0.0.4 - достига, т.е. заявка за ехо дойде при нас. Но обратното:
S = 34.0.0.4, г = 12.0.0.1 - unroutable, недостижима. По дяволите. Просто не знам къде да се изпрати на следващия. Е, има най-малко половината път направи!
Сега ние просто ще остави че R4 изпрати всичките (обикновено всички!) Пакети за R3 (защото той няма къде да се изпрати), самият R3 разбирам, той RIP активирана.
Сега всичко е в ред!
След прибавяне на статичен маршрут до R4:
R4 (конфигурационния) # IP маршрут 0.0.0.0 0.0.0.0 34.0.0.3
Той е работил! С R1 R4 е налично!
Изключете отстраняване на грешки на всички рутери, които не са CPU интензивно и не изпълват конзолни трупи:
R2 # .... R3 # .... R4 # ... едно и също нещо.
Сега, надявам се, е по-лесно да се диагностицира маршрутизация неизправност, когато не е ясно, която идва да се опаковат и къде да - все още.
Сега, както е обещано, а малко се говори за fichah. Ние често виждаме пинг команда в бягство последователност надпис Type да се откажем (натиснете последователността бягство да се откажем), стандарта Linux Ctrl + C не работи тук. Какво да се прави? За тази последователност е Cisco Ctrl + 6. Това тук е не-очевидни комбинация.
Освен това, за отстраняване на грешки. Вижте това, което трасира в секунда е възможно да пишете
Друг начин да се намали натоварването на конзолата - формиране на изходното буфер и последващото му оттеглянето:
R4 (конфигурационния) # не сеч конзола
R4 (конфигурационния) # сеч буфериран 5000
R4 (довереник) # направя отстраняване на грешки IP пакети
R4 (конфигурационния) # направи пинг 12.0.0.1
.
R4 (конфигурационния) # направи undebug всички
R4 (довереник) # показват дневник
Това е последната команда ще ни покаже регистър, който се съхранява в размер на буфера от 5000 байта:
Грешки в буфер
Това е в общи линии всичко, което исках да кажа все още. Повече подробности от работата разказват Traceroute.
Вие също така ще се насладите на:
