Настройка роутера Cisco Packet Tracer
Возникла проблема при настройке роутера в Packet Tracer.
Сеть состоит из двух роутеров, коммутатора и двух компов.
Надо настроить маршрутизацию (статика), по заданым параметрам:
Не пинговался PC1 с PC2, понял, что R1 и R2 не в одной подсети. Поменял К1: f 0/1 — 192.168.1.2 на f 0/1 — 192.168.2.1. Проблема осталась.
Поскажите что делать?
Думаю, что для начала стоит правильно задать все подсети!
Если я правильно понял вы хотите реализовать след.схему: PC1 — L3(1) — L2 — L3(2) — PC2
(L3 — роутер;L2-коммутатор)
L3(1) имеет LAN 192.168.1.10/24 клиентская подсеть
L3(1) имеет WAN 192.168.1.2
L3(2) имеет LAN 192.168.3.1/24 клиентская подсеть
L3(2) имеет WAN 192.168.2.1
Итого, это как-то «не очень» развернутая подсеть 192.168.1.1/16 : в вашей маленькой сети 65534 рабочих хоста. Крутовато для реальных 4 машин)
Но даже если вы на широкую руку захотите реализовать сеть /16 , то лучше уж так: 192.168.1.1/30 (подсеть PC1-L3(1))
192.168.1.5/30 (L3(1)-L3(2))
192.168.1.9/30 (подсеть PC2-L3(2))
Дальше прописывайте, как вы и хотели на L3(1) маршрут к L3(2).
Router(config)#ip route 0.0.0.0 0.0.0.0 192.168.1.6 прописываете на 192.168.1.5.
И наоборот.
Пока писал, ради интереса проверил в CPT:
Всё ещё ищете ответ? Посмотрите другие вопросы с метками маршрутизация cisco-packet-tracer или задайте свой вопрос.
дизайн сайта / логотип © 2022 Stack Exchange Inc; материалы пользователей предоставляются на условиях лицензии cc by-sa. rev 2022.1.12.41149
Нажимая «Принять все файлы cookie» вы соглашаетесь, что Stack Exchange может хранить файлы cookie на вашем устройстве и раскрывать информацию в соответствии с нашей Политикой в отношении файлов cookie.
Как настроить маршрутизацию на роутере cisco packet
Всем привет сегодня мы с вами поговорим про такую вещь как статическая маршрутизация в оборудовании Cisco. Эта статья продолжение поста Как настроить маршрутизатор cisco / Организация сети для небольшого офиса. Там мы настроили локальную сеть в двух офисах компании, один маленький офис, второй чуть побольше. На роутере во втором офисе мы остановились на настройке статической маршрутизации, чем мы и займемся.
Таблица маршрутизации
Первое с чем нужно познакомиться, это с понятием таблицы маршрутизации. Если в двух словах это некая карта маршрутов, до сетей о которых знает ваш коммутатор 3 уровня или роутер. Для большей наглядности ее можно сравнить с картой дорог до городов России. И для того, чтобы например мне попасть из Москвы в Нижний Новгород, я должен выбрать определенную дорогу. Так и ваш роутер выбирает ее. Далее если мне нужно из Москвы попасть в Казань, и мне нужно ехать туда через Нижний Новгород, то В НН должен быть свой маршрут до Казани и так далее.
Статический маршрут — это постоянный неизменный маршрут, чаще всего прописанный в ручную.
Схема сети офисов
У нас есть филиал, в котором 3 компьютера коммутатор второго уровня Cisco 2960 и Роутер Cisco 1841, есть три vlan (2,3,4). Есть главный офис в котором есть 5 vlan (2,3,4,5), маршрутизацией локального трафика занимается ядро в виде коммутатора 3 уровня Cisco 3560, который VLAN 5 подключен к роутеру Cisco 2911, на котором настроен будет интернет и канал до филиала.
В предыдущем посте где мы создавали данную локальную сеть я не настроил vlan 5 на роутере и ядре, исправим это.
Настройка Cisco 2911 и Cisco 3560
Настройка Cisco 3560
Создаем Vlan 5
vlan 5
name VLAN5
exit
Настроим ip адрес VLAN5
int vlan 5
ip address 192.168.5.1 255.255.255.0
exit
Добавим порт gi1/1 в VLAN5
int gi0/1
выставляем режим доступа
switchport mode access
switchport access vlan 5
no shutdown
do wr mem
Настройка Cisco 2911
Так как у нас локальной маршрутизацией трафика занимается ядро то тут sub интерфейсов создавать не нужно. Настроим порт роутера gi0/0 на vlan5.
Добавление статических маршрутов на Cisco 2911
Так как наш роутер Cisco 2911 ничего не знает о сетях 192.168.1.0, 192.168.2.0, 192.168.3.0, то нужно задать ему статические маршруты до них, через ядро делается это следующим образом.
Удостоверимся что пинг не проходит до компьютера 192.168.1.1, вводим на роутере.
Видим ответов нет
Переходим в режим конфигурирования командой
и смотрим команду ip:
access-list Named access-list
cef Cisco Express Forwarding
default-gateway Specify default gateway (if not routing IP)
default-network Flags networks as candidates for default routes
dhcp Configure DHCP server and relay parameters
domain IP DNS Resolver
domain-lookup Enable IP Domain Name System hostname translation
domain-name Define the default domain name
flow-export Specify host/port to send flow statistics
forward-protocol Controls forwarding of physical and directed IP broadcasts
ftp FTP configuration commands
host Add an entry to the ip hostname table
local Specify local options
name-server Specify address of name server to use
nat NAT configuration commands
route Establish static routes
routing Enable IP routing
ssh Configure ssh options
tcp Global TCP parameters
Нам нужна команда ip route.
так как ip адрес на ядре сети (Cisco 3560) у VLAN 5 у нас 192.168.5.1 то он будет выступать для нас шлюзом. В итоге пишем.
и выполнив теперь команду Ping мы видим. что пакет дошел до 192.168.1.1
Планирование сети
Все бы хорошо, но мы не правильно спланировали сеть в удаленном офисе. Так как там как и в главном, тоже есть сеть 192.168.1.0, 192.168.2.0, 192.168.3.0, такого быть не должно иначе получается дубли. Как правильно планировать сеть я писал тут, вам нужно перенастроить, как ранее описано в предыдущей статье. В итоге в филиале я заменил сети на 11, 22, 33 третьи актеты ip адреса. Общая картина теперь выглядит так.
Соединение роутеров
Соединяем наши роутеры. Предположим, что между ними есть прямой линк, в жизни конечно это VPN канал. настроим в начале роутер Cisco 2911 в главном офисе.
маска тут 32 бита так как нам достаточно всего 2 ip адреса.
Теперь настроим роутер Cisco 1841 в филиале. У меня это интерфейс fa0/1
У нас загорелись порты обоих коммутаторов.
Проверяем пинги с роутеров друг до друга
Видим, что все успешно.
Настройка маршрутов между роутерами
Пробуем например с роутера в филиале пропинговать компьютер 192.168.1.1, и естественно пинг не пройдет так как нет маршрутов, чем мы и займемся. Так как у нас один шлюз соединения между офисами, то правильнее будет прописать один дефолтный путь, но можно и прописывать конкретный статический маршрут, например если основной шлюз интернет и весь трафик по умолчанию идет туда и вы хотите на конкретную сеть завернуть через другой шлюз.
но если бы нужно было прописать ручками каждый то вот так
ip route 192.168.1.0 255.255.255.0 192.168.100.1
ip route 192.168.2.0 255.255.255.0 192.168.100.1
ip route 192.168.3.0 255.255.255.0 192.168.100.1
do wr mem
Настроим теперь роутер у главного офиса, нам нужно добавить маршруты до сетей 192.168.11.0, 192.168.22.0, 192.168.33.0.
либо если нужно в ручную отдельным маршрутом.
Настройка маршрутов на ядре
Напомню, что локальный трафик маршрутизирует ядро сети коммутатор 3 уровня Cisco 3560, и на нем нужно тоже указать маршруты, до филиала. В качестве шлюза указывается, ip адрес vlan5 на роутере 2911 192.168.5.251
Вот финальный вид нашей филиальной сети.
Берем теперь компьютер из филиала с ip адресом 192.16811.1 и пробуем с него пропинговать 192.168.1.1 для примера. И видим, что все отлично пингуется, значит связь между офисами есть.
Посмотреть таблицу маршрутизации на Cisco можно командой
Где буква C означает что соединение установлено, буква S означает что маршрут статический.
Вот так вот просто объединить офисы в одну сеть, мы с вами разобрались со статической маршрутизацией, рассмотрели ее на примерах. В организации тестового стенда мне помог симулятор, Скачать Cisco packet tracer можно тут. На этом все.
Популярные Похожие записи:
10 Responses to Статическая маршрутизация Cisco
Спасибо за статью.
Помогите разобраться с маршрутизацией и настроить доступ к локальным сетям:
Есть три здания:
Здание1 IP-адрес внешний 10.135.13.129 Маска 255.255.255.128 IP-адрес внутренний 150.150.2.3 Маска 255.255.0.0
Здание 2 IP-адрес внешний 10.135.59.1 Маска 255.255.255.128 IP-адрес внутренний 192.168.30.1 Маска 255.255.255.0
Здание 3 IP-адрес внешний 10.135.67.1 Маска 255.255.255.128 IP-адрес внутренний 192.168.0.1 Маска 255.255.255.0
Ping между роутерами Cisco по внешним адресам есть
У меня вот такое предположение:
ip route 192.168.30.0 255.255.255.0 10.135.13.129
ip route 192.168.0.0 255.255.255.0 10.135.13.129
ip route 150.150.0.0 255.255.0.0 10.135.59.1
ip route 192.168.0.0 255.255.255.0 10.135.59.1
ip route 150.150.0.0 255.255.0.0 10.135.67.1
ip route 192.168.30.0 255.255.255.0 10.135.67.1
Ping к компьютерам из внутренних сетей не проходит.
а по трассировкам куда трафик идет?
Трассировка до яндекса
Трассировка маршрута к YA.ru [213.180.193.3]
с максимальным числом прыжков 30:
1 <1 мс <1 мс <1 мс 150.150.2.3
2 3 ms 3 ms 3 ms 10.135.13.129
3 13 ms 4 ms 5 ms 10.254.246.73
4 5 ms 6 ms 7 ms 10.2.1.146
5 5 ms 7 ms 7 ms 10.2.1.165
6 5 ms 6 ms 2 ms ss-cr04-be12.51.msk.stream-internet.net [212.188.1.5]
7 3 ms 3 ms 7 ms m9-cr04-be9.77.msk.stream-internet.net [195.34.59.249]
8 4 ms 3 ms 3 ms m9-cr03-ae13.77.msk.stream-internet.net [212.188.42.106]
9 4 ms 4 ms 6 ms yandex-m9.msk.stream-internet.net [195.34.36.30]
10 3 ms 5 ms 4 ms m9-p1-be1.yndx.net [87.250.239.22]
11 * * * Превышен интервал ожидания для запроса.
12 3 ms 4 ms 4 ms fol5-c2-ae7.yndx.net [87.250.239.84]
13 4 ms 4 ms 4 ms _ww.yandex.ru [213.180.193.3]
Трассировка до внутренней сети здания 2
Трассировка маршрута к 192.168.30.1 с максимальным числом прыжков 30
1 <1 мс <1 мс <1 мс 150.150.2.3
2 * * * Превышен интервал ожидания для запроса.
3 * * * Превышен интервал ожидания для запроса.
4 * * * Превышен интервал ожидания для запроса.
5 * * * Превышен интервал ожидания для запроса.
6 ^C
Трассировка между зданием 1 и 2
Трассировка маршрута к 10.135.59.1 с максимальным числом прыжков 30
1 <1 мс <1 мс <1 мс 150.150.2.3
2 4 ms 5 ms 1 ms 10.135.13.129
3 4 ms 6 ms 4 ms 10.135.59.1
Хотя по логике должно быть так:
Route -p add 192.168.30.0 mask 255.255.255.0 10.135.59.1
Route -p add 192.168.0.0 mask 255.255.255.0 10.135.67.1
Route -p add 150.150.0.0 mask 255.255.0.0 10.135.13.129
Route -p add 192.168.0.0 mask 255.255.255.0 10.135.67.1
Route -p add 150.150.0.0 mask 255.255.0.0 10.135.13.129
Route -p add 192.168.30.0 mask 255.255.255.0 10.135.59.1
Нашел ошибку(мешали остатки настроек от прошлого хозяина) теперь трессеровка вот так выглядит:
Трассировка маршрута к 192.168.30.1 с максимальным числом прыжков 30
1 <1 мс <1 мс <1 мс 150.150.2.3
2 4 ms 3 ms 3 ms 10.135.13.129
3 3 ms 3 ms 3 ms 10.128.4.102
4 10.128.4.101 сообщает: Заданная сеть недоступна.
Маршруты прописаны как в пред идущем посте.
Алексей извините, что не ответил, отсутствовал по уважительной причине, сын родился �� Рад, что вы нашли у себя причину проблемы.
Про маршрутизацию всё рассказали и показали, а вот доступ к Интернету, что-то упустили,хотелось бы по подробнее, или я что-то не увидел? =)
…маска тут 32 бита так как нам достаточно всего 2 ip адреса
ip address 192.168.100.1 255.255.255.252
имелось в виду маска 30 бит, а не 32?
Спасибо, за статью.
Однако, если прописывать в ручную
на Router0 (1841):
ip route 192.168.1.0 255.255.255.0 192.168.100.1
ip route 192.168.2.0 255.255.255.0 192.168.100.1
ip route 192.168.3.0 255.255.255.0 192.168.100.1
на Router1 (2911):
ip route 192.168.11.0 255.255.255.0 192.168.100.2
ip route 192.168.22.0 255.255.255.0 192.168.100.2
ip route 192.168.33.0 255.255.255.0 192.168.100.2
то пинги между сетями не проходят. Маршрутизатор 2911 не пропускает из сети 192.168.100.0 в 192.168.5.0 и наоборот.
А вот если прописать
на Router0 (1841):
ip route 0.0.0.0 0.0.0.0 192.168.100.1
на Router1 (2911):
ip route 0.0.0.0 0.0.0.0 192.168.100.2
то всё норм.
NexxDigital — компьютеры и операционные системы
Как настроить статическую маршрутизацию cisco packet tracer. Статическая маршрутизация Cisco
Протоколы маршрутизации — это правила, по которым осуществляется обмен информации о путях передачи пакетов между маршрутизаторами. Протоколы характеризуются временем сходимости, потерями и масштабируемостью. В настоящее время используется несколько протоколов маршрутизации.
Одна из главных задач маршрутизатора состоит в определении наилучшего пути к заданному адресату. Маршрутизатор определяет пути (маршруты) к адресатам или из статической конфигурации, введённой администратором, или динамически на основании маршрутной информации, полученной от других маршрутизаторов. Маршрутизаторы обмениваются маршрутной информацией с помощью протоколов маршрутизации.
Маршрутизатор хранит таблицы маршрутов в оперативной памяти. Таблица маршрутов это список наилучших известных доступных маршрутов. Маршрутизатор использует эту таблицу для принятия решения куда направлять пакет.
В случае статической маршрутизации администратор вручную определяет маршруты к сетям назначения.
В случае динамической маршрутизации – маршрутизаторы следуют правилам, определяемым протоколами маршрутизации для обмена информацией о маршрутах и выбора лучшего пути.
Статические маршруты не меняются самим маршрутизатором. Динамические маршруты изменяются самим маршрутизатором автоматически при получении информации о смене маршрутов от соседних маршрутизаторов. Статическая маршрутизация потребляет мало вычислительных ресурсов и полезна в сетях, которые не имеют нескольких путей к адресату назначения. Если от маршрутизатора к маршрутизатору есть только один путь, то часто используют статическую маршрутизацию.
Лабораторная работа №4. Настройка статической маршрутизации.
Проведем настройку статической маршрутизации с помощью графических мастеров интерфейса Cisco Packet Tracer.
Создайте схему сети, представленную на рис.6.1.
Рис.6.1. Схема сети.
На данной схеме представлена корпоративная сеть, состоящая из следующих компонентов:
Сеть 1 – на Switch1 замыкается сеть первой организации (таблица 6.1):
Таблица 6.1. Сеть первой организации.
В данной сети на Comp2 установлен DNS и Web сервер с сайтом организации.
На Comp3 установлен DHCP сервер. Компьютер Comp4 получает с DHCP сервера IP адрес, адрес DNS сервера провайдера (сервер Provider) и шлюз. Шлюз в сети – 192.168.1.1/24.
Сеть 2 – на Switch2 замыкается сеть второй организации (таблица 6.2):
Таблица 6.2. Сеть второй организации.
В данной сети на Comp5 установлен DNS и Web сервер с сайтом организации.
На Comp4 установлен DHCP сервер. Компьютер Comp7 получает с DHCP сервера IP адрес, адрес DNS сервера провайдера (сервер Provider) и шлюз. Шлюз в сети – 10.0.0.1/8.
Сеть 3 – на Hub1 замыкается городская сеть 200.200.200.0/24. В сети установлен DNS сервер провайдера (комьютер Provaider с IP адресом -200.200.200.10/24), содержащий данные по всем сайтам сети (Comp2, Comp5, Comp8).
Сеть 4 – маршрутизатор Router3 выводит городскую сеть в интернет через коммутатор Switch3 (сеть 210.210.210.0/24). На Comp8 (IP адрес 210.210.210.8/24, шлюз 210.210.210.3/24.) установлен DNS и Web сервер с сайтом.
Маршрутизаторы имеют по два интерфейса:
Router1 – 192.168.1.1/24 и 200.200.200.1/24.
Router2 – 10.0.0.1/8 и 200.200.200.2/24.
Router3 – 210.210.210.3/24 и 200.200.200.3/24.
1 – настроить сети организаций;
2 – настроить DNS сервер провайдера;
3 – настроить статические таблицы маршрутизации на роутерах;
4 – проверить работу сети – на каждом из компьютеров — Comp4, Comp7 и Comp8. С каждого из них должны открываться все три сайта корпоративной сети.
В предыдущих лабораторных работах рассматривалась настройка сетевых служб и DNS сервера. Приступим к настройке статической маршрутизации на роутерах. Поскольку на представленной схеме четыре сети, то таблицы маршрутизации как минимум должны содержать записи к каждой из этих сетей – т.е. четыре записи. На роутерах Cisco в таблицах маршрутизации как правило не прописываются пути к сетям, к которым подсоединены интерфейсы роутера. Поэтому на каждом роутере необходимо внести по две записи.
Настройте первый роутер.
Для этого войдите в конфигурацию маршрутизатора и в интерфейсах установите IP адрес и маску подсети. Затем в разделе МАРШРУТИЗАЦИЯ откройте вкладку СТАТИЧЕСКАЯ, внесите данные (рис.6.2) и нажмите кнопку ДОБАВИТЬ:
Рис.6.2. Данные для сети 10.0.0.0/8.
В результате у вас должны появиться две записи в таблице маршрутизации (рис.6.3):
Рис.6.3. Формирование статической таблицы маршрутизации.
Чтобы посмотреть полную настройку таблицы маршрутизации, выберите в боковом графическом меню инструмент ПРОВЕРКА (пиктограмма лупы), щелкните в схеме на роутере и выберите в раскрывающемся меню пункт ТАБЛИЦА МАРШРУТИЗАЦИИ.
После настройки всех роутеров в вашей сети станут доступны IP адреса любого компьютера и вы сможете открыть любой сайт с компьютеров Comp4, Comp7 и Comp8.
Лабораторная работа №5. Построение таблиц маршрутизации.
Выполните самостоятельно следующую работу, схема сети для которой представлена на рис.6.4.
Рис.6.4. Схема сети.
Пять концентраторов представляют следующие пять сетей:
Hub11 – сеть 11.0.0.0
Hub12 – сеть 12.0.0.0
Hub13 – сеть 13.0.0.0
Hub14 – сеть 14.0.0.0
Hub15 – сеть 15.0.0.0
Router 1 имеет дополнительный сетевой интерфейс, который добавляется из модуля WIC-1ENET при выключенном роутере.
В сети три Web узла на Server1, Server2 и Server3.
Сервера и компьютер имеют произвольные IP адреса со шлюзами своих роутеров.
Интерфейсы роутеров определяются сетью на концентраторе и номером роутера.
Например для Router3: 15.0.0.3 и 14.0.0.3
компьютер Comp1 должен открыть все три сайта на серверах корпоративной сети. В настройках Comp1 в качестве DNS сервера указан DNS сервер провайдера на Server_Provider.
Статическая маршрутизация в вопросах и ответах
Этот краткий FAQ я составил, руководствуясь идеей необходимости вычленить из огромной области знаний, называемой “статическая IP-маршрутизация”, только те вопросы, которые действительно необходимо знать читателю рубрики, в которой помещена эта статья, то бишь, системному администратору.
В повседневной работе рядовой администратор систем, завязанных на LAN, сталкивается с вопросами маршрутизации лишь эпизодически. И, естественно, не имея достаточного времени, чтобы ясно увидеть задачу, он не может эффективно ее решить. Но маршрутизация – это инструмент чрезвычайно гибкий, и достаточно иметь десяток приемов, чтобы вчерашние проблемы превратить в приятную работу. Именно с такими приемами читатель сможет познакомиться, дочитав статью до конца.
Что касается динамической маршрутизации, могу лишь сказать, что это несколько другая тема, которая здесь не рассматривается, но которую невозможно понять, не зная основ в статике.
Ниже рассматриваются примеры, реализованные на ОС Linux. Если вы работаете на другой ОС, то необходимо лишь уточнить синтаксис команд и незначительные детали. Также для понимания поднимаемых вопросов необходимо хорошее понимание IP-адресации и начальные навыки в конфигурировании сетевых устройств.
вопрос 1
Почему хосты, интерфейсы которых имеют IP-адреса, принадлежащие разным логическим сетям, в некоторых случаях могут нормально взаимодействовать без дополнительной маршрутизации? Вот примеры подобных пар IP-адресов: 10.10.1.1/8 – 10.10.2.2/16, 192.168.5.1/16 – 192.168.5.2/24. Ведь в первом случае адреса сетей будут 10.0.0.0 и 10.10.0.0, во втором 192.168.0.0 и 192.168.5.0.
Посмотрим, когда такое “взаимодействие” (назовем так обмен пакетами между интерфейсами хостов) может не получиться. Если на хосте образуется пакет с IP-адресом назначения, не попадающим ни под один из маршрутов внутренней таблицы маршрутизации этого хоста, то он отправляется на маршрут по умолчанию (default gateway, см. также вопрос 6). И решение о том, куда направлять пакет, предоставляется следующему маршрутизатору, и так далее. Таким образом, если верный маршрут до получателя не существует ни на одном из маршрутизаторов по пути следования пакета, он может “потеряться” и не дойти до получателя.
В вопросе же указаны пары адресов, обмен пакетами между которыми вполне осуществим с помощью записей во внутренних таблицах маршрутизаций хостов, добавляемых операционной системой автоматически при активации сконфигурированных интерфейсов. Например, у хоста с активированным и настроенным на IP-адрес 10.10.1.1/8 интерфейсом, во внутренней таблице маршрутизации, помимо других, будет приблизительно такая запись:
Destination Gateway Genmask Flags Metric Ref Use Iface
10.0.0.0 * 255.0.0.0 U 0 0 0 eth0
Теперь посмотрим, подходит ли такая запись для пакета с адресом 10.10.2.2. Применим к этому адресу маску 255.0.0.0 из вышеприведенной записи. Получаем логическую сеть 10.0.0.0. Таким образом, пакет отправится на интерфейс eth0. А для получателя, IP-адрес отправителя пакета совершенно безразличен, и учитывается только при генерации ответа.
То же можно сказать и о хосте с интерфейсом, у которого IP-адрес 10.10.2.2/16. Применение маски 255.255.0.0 к IP адресу 10.10.1.1 даст логическую сеть 10.10.0.0. Маршрут на этом хосте для такой логической сети существует, и пакет с адресом назначения 10.10.1.1 будет отправлен именно по этому маршруту. Замечу, что это может быть ответ на пакет, пришедший с с хоста, рассмотренного первым. В результате получаем полноценный обмен пакетами.
Таким образом, если есть пара интерфейсов в пределах одного физического сегмента, то можно сформулировать следующее простое правило: если применение маски первого интерфейса к обоим IP-адресам дает равный результат, а также применение маски второго интерфейса к обоим IP адресам дает также равный результат, то хосты будут нормально обмениваться пакетами в обоих направлениях.
То, что мы обсудили, имеет название. Supernetting – высвобождение адресов хостов за счет уменьшения количества сетей — метод, обратный выделению подсетей за счет уменьшения количества хостов (subnetting).
вопрос 2
У меня в LAN появился хост с “неподходящей” подсетью в IP-адресе, например, другого класса. Изменять этот IP-адрес нельзя. Что делать? Не менять же адреса у всех хостов, которые с ним работают?
Есть несколько методов решения этой проблемы.
Метод 1. Самый простой инеэффективный – добавить дополнительный IP-адрес с подходящей подсетью хосту, который инициирует коннекты. Здесь есть варианты. Можно установить дополнительный интерфейс и сконфигурировать его соответствующим образом. Проще добавить к интерфейсу так называемый alias. Это дополнительный IP-адрес, привязанный к интерфейсу и действующий наравне с основным. Следующая команда присваивает интерфейсу eth0 дополнительный IP адрес 172.16.1.1.
#ifconfig eth0:1 inet 172.16.1.1 netmask 255.255.0.0 broadcast 172.16.255.255
где eth0:x – название виртуальных интерфейсов, которые обслуживаются той же сетевой картой, что и интерфейс eth0. Указание broadcast в данном случае не обязательно, но если вы практикуете использование нестандартных масок, рекомендую взять в привычку указание этого параметра, т.к. по умолчанию принимается значение, соответствующее классу IP-адреса и часто не соответствует указанной маске.
Замечу, что при добавлении интерфейса с IP-адресом либо IP alias, всегда автоматически добавляется соответствующий маршрут в таблицу маршрутизации. Именно это обстоятельство позволяет решить нашу проблему.
Недостаток данного метода в необходимости конфигурирования большого количества клиентов.
Метод 2. Можно добавить в хосты, инициирующие коннекты, соответствующий маршрут. Например. Клиентский хост имеет знакомый из предыдущего вопроса IP-адрес 10.10.2.2/16. Сервер имеет IP-адрес 172.16.1.200/16. Добавляем на клиентском хосте маршрут.
#route add –net 172.16.0.0 netmask 255.255.0.0 eth0
Тем самым мы указываем, что все пакеты, предназначенные для логической сети 172.16.0.0, нужно отправлять на интерфейс eth0. Этого достаточно, чтобы клиентский хост с IP-адресом 10.10.2.2/16 мог устанавливать сессии с сервером 172.16.1.200/16. Этот метод на самом деле мало отличается от первого:-)
/* Можно также использовать маршрут на отдельный хост (подробнее рассмотрен в вопросе 6). Если в приведенном выше примере не существенно, какую форму записи маршрута (на хост или на сеть) выбрать, есть ситуации, когда маршрут на хост является единственно возможным вариантом. Сразу пример: внутри нашей сети, использующей «нереальные» (fake) адреса, находится хост с реальным адресом, причем все остальные его собратья по IP-сети (подсети) находятся в другом месте (за шлюзом, например). В этом случае можно использовать только маршрут на хост. — прим. ред. */
Метод 3. Может оказаться очень эффективным метод указания маршрута на шлюзе (благо он есть практически в любой организации), если клиентские рабочие станции уже настроены на него. На Рис. 1 показана такая ситуация. Многочисленные клиентские хосты (Cx) настроены на шлюз по умолчанию 10.10.99.99/16. Тогда на G1 добавляем маршрут, как это сделано в предыдущем пункте.
G1#route add –net 172.16.0.0 netmask 255.255.0.0 eth0
Тогда все пакеты хостов Сx к адресу 172.16.1.200/16 будут вначале перенаправляться на G1, потому что на Cx маршрута на сеть 172.16.0.0 нет и, следовательно, применяется маршрут по умолчанию (default) на 10.10.99.99, а затем с G1 согласно указанного нами маршрута на интерфейс, подключенный к внутренней LAN. Это может быть интерфейс eth0. А может быть и дополнительный eth1. И, наконец, с этого интерфейса пакеты попадают на S1 .
/* Кстати, если уж вводить на G1 дополнительный интерфейс, можно изменить и схему подключения G1 и S1, а именно: S1 включить напрямую в eth1 на G1, оставив последнему только одну точку подключения к LAN. С точки зрения network design’a это несколько корректней, особенно применительно к некоммутируемому Ethernet, хотя в каждом конкретном случае могут быть свои нюансы. — прим. ред. */
Вот результат применения команды tracert на Windows-машине C1 в описанном случае.
Tracing route to 172.16.1.200 over a maximum of 30 hops
1 1 ms
На этот раз нет смысла заворачивать маршрут на G1, потому что есть возможность прописать маршрут сразу на S1, и только один раз.
вопрос 4
А если в обсуждаемой выше схеме хосту G1 присвоить дополнительный IP 172.16.x.x? Тогда нет необходимости прописывать маршрут?
Совершенно верно. Можно было на G1 не добавлять маршрут, а присвоить IP-адрес интерфейсу eth1, либо IP alias на eth0, как описано в методе 1 вопроса 2. Тогда остается добавить маршрут по умолчанию на наш законный шлюз (как это сделано на всех клиентах Cx) на сервере S1, чтобы он мог инициировать коннекты к Cx.
S1#route add default gw 10.10.99.99
Получаем еще одну полностью работающую схему. Думаю, здесь вопросов больше нет.
вопрос 5
Какие существуют способы диагностики, помогающие устранить ошибки в конфигурации маршрутов?
Выявление ошибок, на мой взгляд, удобно проводить, двигаясь от конечного интерфейса к начальному. Последовательный ping в таком направлении обычно сразу позволяет выявить этап, на котором застревают пакеты. Следует отметить опцию –R в команде ping. Она показывает маршрут движения пакета, подобно тому, как это делает команда traceroute. Для того, чтобы увидеть пришедший ICMP-пакет на интерфейс назначения может пригодится сетевой монитор, скажем, tcpdump. Например, команда
#tcpdump proto ICMP
показывает все пакеты, порожденные программой ping, и может быть полезна для диагностики ситуации, когда пакеты доходят до хоста назначения, но ответы на них не доходят до пингующего хоста.
Для проверки правильности прохождения пакетами маршрутов незаменимой остается traceroute. Напомню, что каждая строка (hop) означает изменение маршрута согласно таблиц маршрутизации. Первая строка обычно порождается таблицей маршрутизации хоста, с которого идет трассировка. Каждая последующая – прохождение маршрутизатора.
Очень важно, на мой взгляд, понимание следующего тезиса. IP-маршрутизация работает на сетевом (3-м) уровне модели OSI и опирается на канальный (2-й). В этом смысле маршрутизатор можно условно назвать коммутатором 3-го уровня. Для того чтобы отделить ошибки, не связанные с маршрутизацией, нужно провести диагностику на канальном уровне. Тогда, убедившись, что на этом уровне все хорошо, можно искать проблемы на сетевом уровне.
Отличной проверкой правильной работы канального уровня /* точнее, сопряжения канального уровня с сетевым — прим. ред. */ может служить наличие корректного MAC-адреса нужного интерфейса в ARP-кэше. Например.
source_host>ping –с 1
source_host>arp –a
Сверив полученный из кэша адрес с истинным адресом интерфейса (команда ifconfig),
target_host>ifconfig
можно сказать что, скорее всего, на канальном уровне все в порядке.
/* Когда ситуация в вашей сети еще не совсем «устаканилась», то бишь вы часто меняете адреса на некоторых хостах/интерфейсах, изучение ARP-кэша поможет вам отыскать самый что ни на есть классический глюк: если некий адрес только что принадлежал одному хосту и его переназначили другому, то MAC-адрес прежнего хозяина того IP-адреса, который вы столь усердно и безрезультатно пингуете, мог просто застрять в ARP-кэше. Пакеты уходят «вникуда», их там никто не ждет — старый владелец адреса может быть отключен или ему назначен другой адрес и он пытается смаршрутизировать пакеты. ерунда в общем полная:)
Очистить ARP-кэш (полностью или частично) можно с помощью команды arp –d. — прим. ред. */
В принципе, пяти команд – ifconfig, route, ping, arp, и traceroute хватает для решения любой задачи статической маршрутизации. Ну и сетевой анализатор, как было сказано выше, не помешает.
вопрос 6
Какие еще существуют записи для таблицы маршрутизации?
Пока мы применяли один тип маршрута – трафик логической подсети направлялся на интерфейс. Другой тип маршрута для выделения нужного трафика — это маршрут для указанного хоста. Т.е. есть возможность указать маршрут персонально для одного хоста (опция add -host), хотя применяется такая запись редко.
Это были виды маршрутов с точки зрения критериев принятия решения о выборе записи.
С точки зрения направления движения трафика помимо рассмотренного нами указания интерфейса есть возможность перенаправить пакеты на указанный IP-адрес шлюза (gateway). Тогда не учитывается конкретный IP-адрес, указанный в пакетах и, следовательно, принятие решения о цели пакетов откладывается до следующего маршрутизатора. Таких перенаправлений может быть сколь угодно много, и ограничено лишь значением TTL (Time To Live).
Частным случаем перенаправления на шлюз является запись default. Это запись для сети, имеющей значение 0.0.0.0, т.е. “вся сеть“. Правило для такого маршрута срабатывает, когда IP-адрес цели пакета не подходит ни под один из критериев, указанных в таблице маршрутизации. На практике маршрут по умолчанию следует настраивать на шлюз в Интернет. В этом есть практический смысл. Если хосты, которые запрашивает клиент, отсутствуют в LAN, то они могут быть в остальной сети, т.е. в Интернет.
В добавлении маршрута на конкретный IP-адрес есть одна особенность. Для IP-адреса шлюза уже должен существовать маршрут. Иначе неизвестно куда отправлять пакет. Поясню сказанное на примере. Сначала добавляем запись для сети 192.168.5.0, а затем уже запись для сети 172.16.0.0 на шлюз 192.168.5.1.
#route add –net 192.168.5.0 netmask 255.255.255.0 eth0
#route add –net 172.16.0.0 netmask 255.255.0.0 gw 192.168.5.1 eth0
вопрос 7
Моя LAN разделена на две большие части, которые соединены достаточно медленной (1Мбт/c) линией. Широковещательный трафик занимает значительную долю этой линии. Как мне разделить две эти сети на подсети, чтобы проходил трафик только с конкретными IP-адресами?
Собственно, это главная задача маршрутизации – уменьшать трафик за счет разделения сетей, либо другими словами, направлять трафик по назначению и никуда более.
Разберем пример, когда LAN состоит из двух частей, соединенных относительно низкоскоростным каналом (Рис. 2). Подключение к Интернет имеет только первая часть. Это приемлемо, когда канал в Интернет еще более узок, чем канал между частями LAN.
Рассмотрим конфигурацию приведенной схемы.
Верхняя часть.
R1#echo «1» > /proc/sys/net/ipv4/ip_forward
R1#route add default gw 10.10.99.99
R2#echo «1» > /proc/sys/net/ipv4/ip_forward
На хостах G1, R1, R2 должен быть включен форвард пакетов между сетевыми адаптерами. Вписываем “1” в файл /proc/sys/net/ipv4/ip_forward, если это не сделано.
Множество клиентов Cx имеют настройку на шлюз G1 для всех неизвестных сетей (по умолчанию). Любой обращение к сетям, отличным от 10.10.0.0, обрабатывает G1. В случае, если идет обращение к сети 10.20.0.0, шлюз G1 перенаправляет это обращение к маршрутизатору R1. А маршрутизатор R1 перенаправляет на маршрутизатор R2. В свою очередь R2 непосредственно находится в сети 10.20.0.0. и направляет обращение к нужному клиенту.
Обращаю внимание еще раз, что трафик в направлении сети 10.20.0.0 проходит через шлюз G1, и необходимо предусмотреть достаточную для этого полосу пропускания. В нашем примере предусмотрена дополнительная сетевая карта eth1, хотя можно обойтись и без нее. Я ее включил в конфигурацию только для наглядности.
Теперь посмотрим на движение ответа на рассмотренный запрос. Удаленные клиенты CRx имеют настройку по умолчанию на шлюз R2. IP-адрес хоста назначения будет относиться к сети 10.10.0.0 и, следовательно, ответ на запрос направится на R2. Здесь такой маршрут снова неизвестен, ответ перенаправлятся по маршруту по умолчанию, на R1, на котором есть интерфейс с подходящей сетью 10.10.0.0. Здесь ответ направляется сразу непосредственно на Cx, минуя шлюз G1, что нас вполне устраивает.
Рассмотрим движение запросов в Интернет всех клиентов Cx и CRx. Предполагаем, что запросы обрабатываются посредством Source network address translation (SNAT), и обеспечивается шлюзом G1. В верхней части клиенты Cx имеют простое подключение к Интернету посредством указания маршрута по умолчанию. Думаю, здесь все ясно. В нижней части клиенты имеют маршрут по умолчанию на шлюз R2. Попав на R2, запрос будет перенаправлен дальше опять по маршруту по умолчанию на R1. На R1 ситуация повторится, и запрос уйдет на шлюз в Интернет G1. Далее по назначению. Ответы на запрос пойдут по тому же маршруту в обратном направлении. Для этого на G1 и R1 уже предусмотрены маршруты для сети 10.20.0.0.
Если нужно в нижней части схемы добавить дополнительный шлюз G2 (10.20.99.99/16) с подключением клиентов CRx в Интернет, то просто зеркально отображаем конфигурацию из верхней части.
С1#route add default gw 10.10.99.99
G1#echo «1» > /proc/sys/net/ipv4/ip_forward
G1#route add –net 10.20.0.0 netmask 255.255.0.0 gw 10.10.99.98 eth1
R1#echo «1» > /proc/sys/net/ipv4/ip_forward
R1#route add –net 10.20.0.0 netmask 255.255.0.0 gw 172.17.1.2 eth1
R1#route add default gw 10.10.99.99
G2#echo «1» > /proc/sys/net/ipv4/ip_forward
G2#route add –net 10.10.0.0 netmask 255.255.0.0 gw 10.20.99.98 eth1
СR1#route add default gw 10.20.99.99
R2#echo «1» > /proc/sys/net/ipv4/ip_forward
R2#route add –net 10.10.0.0 netmask 255.255.0.0 gw 172.17.1.1 eth1
R2# route add default gw 10.20.99.99
То же можно сказать о необходимости убрать шлюзы в Интернет совсем. Тогда копируем конфигурацию с нижней части схемы в верхнюю. Конфигурация в этом случае упрощается до безобразия:-).
С1#route add default gw 10.10.99.98
R1#echo «1» > /proc/sys/net/ipv4/ip_forward
R1#route add default gw 172.17.1.2
СR1#route add default gw 10.20.99.98
R2#echo «1» > /proc/sys/net/ipv4/ip_forward
R2# route add default gw 172.17.1.1
вопрос 8
Как сделать так, чтобы конфигурация маршрутов сохранялась после перезагрузки компьютера?
Нужно внести соответствующие изменения в соответствующие файлы:-). Это проще сделать с помощью какой-нибудь комплексной утилиты. Например, с этим прекрасно справляется Linuxconf. Но я предпочитаю делать отдельный скрипт, который включает все настройки, и запускать его автоматически на третьем уровне исполнения. В этом есть значительные преимущества. В скрипте можно одним взглядом охватить всю конфигурацию. Это может оказаться полезным, если она достаточно сложна. Удобно, также, собирать однотипные скрипты со всех хостов для проведения переконфигурирования, либо резервирования конфигурации.
Настройка маршрутизации Cisco Packet Tracer
Cisco Packet Tracer — настройка маршрутизации
Помогите настроить маршрутизацию! Преподаватель дал схему и ip 192.168.32.0/26 Я считаю что через.
Настройка статической маршрутизации Cisco Packet Tracer
Доброго времени суток! Задали лабораторную работу и я столкнулся с непосильной задачей.
Подскажите по маршрутизации (в Cisco Packet Tracer)
Задача такая, сервер должен быть доступен с любого клиента. Все адреса прописал, маршрутизацию.
Таблицы маршрутизации (Cisco Packet Tracer)
Доброго времени суток, имеется сеть Прописал все ip/шлюзы по умолчанию/маски на компьютерах и.
Не выходит.. а к утру хотелось бы чтоб все работало. Попробовал NAT. Видимо что-то не так сделал. не работает. Еще толком не разобрался в проге.
Router#conf term
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#access-list 100 permit ip 192.168.1.64 0.0.0.31 any
Router(config)#ip nat pool NAME_POOL 100.10.10.1 100.10.10.10 netmask 255.255.0.0
Router(config)#interface se 0/0
Router(config-if)#ip nat inside
Router(config-if)#exit
Router(config)#interface se 0/1
Router(config-if)#ip nat outside
Router(config-if)#exit
Router(config)#ip nat inside source list 100 pool NAME_POOL
Сообщение от Jabbson
Сообщение от Jabbson
Я просил топологию, файл cisco packet tracer’a в формате *.pkt
PS>
ушел спать.
если завтра все еще актуально — жду топологию.
Так получается из-за того, что ISP роутер не знает о существовании каких либо сетей кроме 100.10.10.0 /16 и 192.168.0.0 /24 (directly connected) (на нём же не настроена никакая маршрутизация кроме непонятного статического дефолт-маршрута в сторону Ext. Web Server).
То есть, смотрите, пакет доходит от PC2 до ISP, тот в свою очередь и не против бы ответить. Смотрит кому отвечать надо и не находит к этому хосту маршрута в таблице маршрутизации. И соответственно делает что? Отправляет этот пакет по дефолт-маршруту к серверу, который в свою очередь смотрит на пакет, недоумевает на тему "зачем это сюда пришло" и убивает этот пакет. Вот такой детектив.
К вопросу о том, что делать.
Самым простым решением было бы заменить на ISP роутере
ip route 0.0.0.0 0.0.0.0 192.168.0.2
на
ip route 0.0.0.0 0.0.0.0 100.10.10.2
(как вариант — на ip route 0.0.0.0 0.0.0.0 Se0/0, что приведет абсолютно к тому же результату).