Урок 27. Настройка статической маршрутизации. Что такое статический маршрут на роутере


А вы хорошо знаете статическую маршрутизацию? / Хабрахабр

Статический маршрут — первое, с чем сталкивается любой человек при изучении понятия маршрутизации IP пакетов. Считается, что это — наиболее простая тема из всех, в ней всё просто и очевидно. Я же постараюсь показать, что даже настолько примитивная технология может содержать в себе множество нюансов.Оговорка. При написании топика я исхожу из того, что читатель знаком с концепцией маршрутизации, умеет делать статические маршруты и не считает слово «ARP» ругательным. Впрочем, даже бывалые связисты наверняка найдут тут что-то новое. Все примеры были проверены на IOS линейки 15.2M. Поведение других ОС может различаться. И никакого динамического роутинга тут не будет.

Мы работаем со следующей топологией:

Как появляется статический маршрут?

Для начала, выполним команду, которую знает каждый, и посмотрим дебагами, что произойдет:R00(config)#ip route 3.1.1.0 255.255.255.0 10.0.0.3IP-ST(default): updating same distance on 3.1.1.0/24 IP-ST(default): 3.1.1.0/24 [1], 10.0.0.3 Path = 8, no change, not active state IP-ST(default): 3.1.1.0/24 [1], 10.0.0.3 Path = 2 3 7 RT: updating static 3.1.1.0/24 (0x0): via 10.0.0.3 RT: add 3.1.1.0/24 via 10.0.0.3, static metric [1/0], add succeed, active state IP ARP: creating incomplete entry for IP address: 10.0.0.3 interface GigabitEthernet0/1 IP ARP: sent req src 10.0.0.1 30e4.db16.7791, dst 10.0.0.3 0000.0000.0000 GigabitEthernet0/1 IP ARP: rcvd rep src 10.0.0.3 0019.aad6.ae10, dst 10.0.0.1 GigabitEthernet0/1 IOS создал маршрут, и сразу послал arp запрос в поисках next hop, который у нас – 10.0.0.3. И сразу вопрос: откуда роутер узнал, что запрос надо слать в интерфейс Gi0/1? Наверняка кто-то скажет «из списка локальных интерфейсов», и жестоко ошибется. Маршрутизация так не работает. На самом деле, IOS сделал рекурсивный запрос к таблице маршрутизации, чтобы узнать, как добраться до next hop:R00#show ip route 10.0.0.3 Routing entry for 10.0.0.0/24 Known via "connected", distance 0, metric 0 (connected, via interface) Routing Descriptor Blocks: * directly connected, via GigabitEthernet0/1 Route metric is 0, traffic share count is 1 И вот он, наш Gi0/1. IOS узнает, что с рекурсивными запросами к RIB надо заканчивать, как только находит маршрут с флагом «directly connected». Но что если ему в ответ на изначальный запрос к 10.0.0.3 вернется вовсе не connected маршрут, а промежуточный, ссылающийся на другой next hop? Вернемся к этому чуть позже, а пока вспомним, что такое CEF.

Примерно во всей документации, ориентированной на начинающих, говорится, что каждый пакет перемещается в соответствии с таблицей маршрутизации. На самом деле на всех более-менее современных платформах это уже не так, ведь таблица маршрутизации (далее – RIB) вовсе не оптимизирована для быстрой передачи данных. Оценить масштаб бедствия позволяет эта таблица (хотя у process switching’а множество недостатков помимо неоптимальных запросов – например, постоянное переключение шедулера CPU между контекстами, что весьма затратно). CEF является серьезной оптимизацией. В современной реализации он строит две таблицы – FIB (Forwarding Information Base, таблица передачи пакетов, в основе нее – связный граф со страшным названием 256-way mtrie) и adjacency table (таблица соседств). Первая из них строится на основе таблицы маршрутизации и за один проход позволяет получить всю нужную информацию. Строится она заранее, еще до того, как появится первый соответствующий ей пакет.

Вернемся к нашему статическому маршруту. Вот запись в таблице маршрутизации:

R00#show ip route 3.1.1.0 Routing entry for 3.1.1.0/24 Known via "static", distance 1, metric 0 Routing Descriptor Blocks: * 10.0.0.3 Route metric is 0, traffic share count is 1 Куда слать пакет? Где искать 10.0.0.3? Непонятно. Надо еще раз запросить таблицу маршрутизации, на этот раз по поводу 10.0.0.3, и, если надо, выполнить еще несколько итераций, пока не выясним connected интерфейс. И вот примерно таким образом мы фактически в несколько раз снижаем производительность маршрутизатора.

А вот что говорит CEF:

R00#show ip cef 3.1.1.0 detail 3.1.1.0/24, epoch 0 recursive via 10.0.0.3 attached to GigabitEthernet0/1 Просто и лаконично. Есть интерфейс, есть next hop, к которому надо слать пакет. Что там говорилось про adjacency table?R00#show adjacency 10.0.0.3 detail Protocol Interface Address IP GigabitEthernet0/1 10.0.0.3(10) 0 packets, 0 bytes epoch 0 sourced in sev-epoch 2 Encap length 14 0019AAD6AE1030E4DB1677910800 ARP Обратим внимание на какую-то длинную последовательность в предпоследней строке. Что-то это напоминает… Смотрим mac 10.0.0.3:R00#show arp | in 10.0.0.3 Internet 10.0.0.3 1 0019.aad6.ae10 ARPA GigabitEthernet0/1 Смотрим свой mac адрес на gi0/1:R00#show int gi0/1 GigabitEthernet0/1 is up, line protocol is up Hardware is CN Gigabit Ethernet, address is 30e4.db16.7791 (bia 30e4.db16.7791) Ага. Та страшная строка – всего лишь два мака, которые надо подставить в заголовок Ethernet на этапе инкапсуляции, и ethertype 0x0800, т.е. банальный IPv4. И в двух таблицах CEF есть абсолютно вся информация, какая нужна для успешной отправки пакета дальше по цепочке.

Если у кого-то возникнет вопрос, зачем железке держать сразу две таблицы вместо одной, то дам очевидный ответ: обычно у маршрутизатора мало интерфейсов (а заодно и соседей) и много маршрутов. Какой смысл тысячи раз дублировать одни и те же маки в FIB? Памяти много не бывает, особенно на аппаратных платформах, будь то новомодные ASR’ы или даже L3 свитчи линейки Catalyst. Все они задействуют CEF при передаче пакетов.

И кстати, вернемся на минутку к изначальному дебагу. Отключим CEF командой no ip cef (никогда так не делайте) и сравним результат:

IP-ST(default): updating same distance on 3.1.1.0/24 IP-ST(default): 3.1.1.0/24 [1], 10.0.0.100 Path = 8, no change, not active state IP-ST(default): 3.1.1.0/24 [1], 10.0.0.100 Path = 2 3 7 RT: updating static 3.1.1.0/24 (0x0): via 10.0.0.100 RT: add 3.1.1.0/24 via 10.0.0.100, static metric [1/0], add succeed, active state Маршрут добавлен. Arp запроса не было. И правильно – зачем RIB сдался mac адрес? Если пустить пинг до, к примеру, 3.1.1.1, то скорее всего будет так:R00#ping 3.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 3.1.1.1, timeout is 2 seconds: .!!!! Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/4 ms Первый пакет отбрасывается, и роутер посылает arp запрос с целью узнать mac адрес 10.0.0.3, если он ранее не был известен. CEF же всегда заранее узнает mac адрес next hop'а.

С этим разобрались. Теперь вернемся к вопросу, что будет, если next hop статического маршрута вовсе не на directly connected интерфейсе. Поступим просто:

R00(config)#ip route 10.0.0.3 255.255.255.255 100.100.100.101 , где Gi0/2 имеет адрес 100.100.100.100/24.R00#show ip cef 3.1.1.0 detail 3.1.1.0/24, epoch 0 recursive via 10.0.0.3 recursive via 100.100.100.101 recursive via 100.100.100.0/24 attached to GigabitEthernet0/2 Как все плохо-то… А что если у нас есть маршрут на целую суперсеть?R00(config)#no ip route 10.0.0.3 255.255.255.255 100.100.100.101 R00(config)#ip route 10.0.0.0 255.0.0.0 100.100.100.101 R00#show ip cef 3.1.1.0 detail 3.1.1.0/24, epoch 0 recursive via 10.0.0.3 attached to GigabitEthernet0/1 Сейчас наша таблица маршрутизации выглядит так:R00#show ip route 10.0.0.0/8 is variably subnetted, 2 subnets, 3 masks S 10.0.0.0/8 [1/0] via 100.100.100.101 C 10.0.0.0/24 is directly connected, GigabitEthernet0/1 L 10.0.0.1/32 is directly connected, GigabitEthernet0/1 100.0.0.0/8 is variably subnetted, 2 subnets, 2 masks C 100.100.100.0/24 is directly connected, GigabitEthernet0/2 L 100.100.100.100/32 is directly connected, GigabitEthernet0/2 Вроде хорошо. Новый маршрут на 100.100.100.101 не применяется для 10.0.0.3, так как его маска /8 намного короче, чем /24 у connected интерфейса. Но вдруг Gi0/1, содержавший next hop для 3.1.1.0/24, по какой-то непонятной причине ушел в down, и его connected маршрут пропал из RIB. %LINK-5-CHANGED: Interface GigabitEthernet0/1, changed state to administratively down %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/1, changed state to down RT: interface GigabitEthernet0/1 removed from routing table RT: del 10.0.0.0 via 0.0.0.0, connected metric [0/0] RT: delete subnet route to 10.0.0.0/24 RT: del 10.0.0.1 via 0.0.0.0, connected metric [0/0] RT: delete subnet route to 10.0.0.1/32 IP-ST(default): updating GigabitEthernet0/1 Вот что стало:R00#show ip cef 3.1.1.0 detail 3.1.1.0/24, epoch 0 recursive via 10.0.0.3 recursive via 10.0.0.0/8 recursive via 100.100.100.101 recursive via 100.100.100.0/24 attached to GigabitEthernet0/2 Ой. Теперь пакеты на сеть 3.1.1.0/24 идут куда-то не туда. Я не могу представить себе сценарий, когда ожидаемое поведение статического маршрута – переключение на другой интерфейс. Если за тем интерфейсом находится резервный путь, то все-таки надо создавать еще один статический маршрут…

Что делать? Указывать сразу в маршруте интерфейс. Пересоздадим маршрут:

R00(config)#no ip route 3.1.1.0 255.255.255.0 10.0.0.3 R00(config)#ip route 3.1.1.0 255.255.255.0 Gi0/1 10.0.0.3 Поднимаем Gi0/1. Смотрим, куда теперь ведет маршрут на 3.1.1.0/24:R00#show ip route 3.1.1.0 Routing entry for 3.1.1.0/24 Known via "static", distance 1, metric 0 Routing Descriptor Blocks: * 10.0.0.3, via GigabitEthernet0/1 Route metric is 0, traffic share count is 1 Тут уже указан интерфейс. Поэтому не будет рекурсивных запросов к таблице маршрутизации. Проверяем FIB:R00#show ip cef 3.1.1.0 3.1.1.0/24 nexthop 10.0.0.3 GigabitEthernet0/1 Да, никакого «recursive». А если снова погасить gi0/1? Маршрут исчез.R00#show ip route 3.1.1.0 % Network not in table R00#show ip cef 3.1.1.0 0.0.0.0/0 no route И это притом, что маршрут до 10.0.0.3 все еще был:R00#show ip cef 10.0.0.3 10.0.0.0/8 nexthop 100.100.100.101 GigabitEthernet0/2 А что будет, если путь к next hop даст маршрут по умолчанию, а маршрут на 3.1.1.0/24 не ссылается на интерфейс?R00(config)#no ip route 10.0.0.0 255.0.0.0 100.100.100.101 R00(config)#ip route 0.0.0.0 0.0.0.0 100.100.100.101 R00(config)#no ip route 3.1.1.0 255.255.255.0 Gi0/1 10.0.0.3 R00(config)#ip route 3.1.1.0 255.255.255.0 10.0.0.3 R00#show ip route 3.1.1.0 % Network not in table R00#show ip cef 3.1.1.0 detail 0.0.0.0/0, epoch 0, flags default route recursive via 100.100.100.101 recursive via 100.100.100.0/24 attached to GigabitEthernet0/2 Обратите внимание, что первой строкой после «show ip cef» идет «0.0.0.0/0», а не «3.1.1.0/24». Несмотря на то, что next hop формально есть, по факту все итерации опроса таблицы маршрутизации (кроме первой) игнорируют маршрут по умолчанию, что логично, иначе любой запрос к таблице маршрутизации почти всегда бы резолвился (под «резолвиться» понимается нахождение интерфейса, в который нужно отправить пакет). Поэтому наш статический маршрут отсутствует, но пакеты все равно улетают к Gi0/2. Вроде бы все то же самое, что и без явного указания интерфейса? Не совсем. Допустим, протоколу маршрутизации сказали «redistribute static». Если статический маршрут пропал, то анонс тоже отзывается. А если нет, то маршрутизатор продолжит говорить всем «туда идти через меня», и это почти наверняка обернется L3 кольцом для префикса 3.1.1.0/24, который мог бы быть доступен откуда-нибудь еще. Но стоп, мы договаривались не трогать динамический роутинг…

А что если в статическом маршруте указать интерфейс, но не указывать IP адрес следующего хопа? Ответ: в случае Ethernet, если на next hop не отключен proxy arp, связность не нарушится, но роутеру может ОЧЕНЬ поплохеть. Подробнее. Если сказать «ip route 3.1.1.0 255.255.255.0 gi0/1», то ничего особо страшного не случится, даже пару сотен записей в arp таблице любой роутер переварит (и существуют сценарии-workaround’ы, в которых оптимальным решением является именно такой костыль), но вот «ip route 0.0.0.0 0.0.0.0 gi0/1» на пограничном маршрутизаторе наверняка убьет его. Потому запомните общее правило: если создается статический маршрут с next hop’ом на Ethernet интерфейсе, то его IP адрес должен указываться всегда. Исключения – только когда вы очень хорошо представляете себе, что делаете, зачем делаете и почему нельзя сделать иначе.

И напоследок, сделаем одну очень нехорошую штуку.

R00(config)# ip route 3.1.1.0 255.255.255.0 10.0.0.3 R00(config)#ip route 10.0.0.3 255.255.255.255 3.1.1.1 Первый маршрут в порядке, сто раз протестирован. А вот второй странный – он ведет через первый. А первый теперь ссылается на второй, и у нас бесконечная рекурсия. Вот что произошло:IP-ST(default): updating same distance on 3.1.1.0/24 IP-ST(default): 3.1.1.0/24 [1], 10.0.0.3 Path = 8, no change, not active state IP-ST(default): 3.1.1.0/24 [1], 10.0.0.3 Path = 2 3 7 RT: updating static 3.1.1.0/24 (0x0): via 10.0.0.3 RT: add 3.1.1.0/24 via 10.0.0.3, static metric [1/0], add succeed, active state IP-ST(default): updating same distance on 10.0.0.3/32 IP-ST(default): 10.0.0.3/32 [1], 3.1.1.1 Path = 8, no change, not active state IP-ST(default): 10.0.0.3/32 [1], 3.1.1.1 Path = 2 3 7 RT: updating static 10.0.0.3/32 (0x0): via 3.1.1.1 RT: add 10.0.0.3/32 via 3.1.1.1, static metric [1/0], add succeed, active state Добавилось успешно. Но затем в дебагах высветилось:RT: recursion error routing 3.1.1.1 - probable routing loop RT: recursion error routing 10.0.0.3 - probable routing loop И появилась запись в лог с severity 3:%IPRT-3-RIB_LOOP: Resolution loop formed by routes in RIBR00#show ip cef 10.0.0.3 detail 10.0.0.3/32, epoch 0 Adj source: IP adj out of GigabitEthernet0/1, addr 10.0.0.3 359503C0 Dependent covered prefix type adjfib cover 10.0.0.0/24 1 RR source [no flags] recursive via 3.1.1.1, unresolved recursive-looped R00#show ip cef 3.1.1.0 detail 3.1.1.0/24, epoch 0, flags cover dependents Covered dependent prefixes: 1 notify cover updated: 1 recursive via 10.0.0.3, unresolved recursive-looped Однако, RIB никакого криминала не видит:Routing entry for 3.1.1.0/24 Known via "static", distance 1, metric 0 Routing Descriptor Blocks: * 10.0.0.3 Route metric is 0, traffic share count is 1 R00#show ip route 10.0.0.3 Routing entry for 10.0.0.3/32 Known via "static", distance 1, metric 0 Routing Descriptor Blocks: * 3.1.1.1 Route metric is 0, traffic share count is 1 Вывод – никогда так не делайте.

Почему статический маршрут может не попасть в таблицу маршрутизации?

Любой сетевик должен сходу дать одно из объяснений, касающееся любого источника маршрутов в IOS: существует другой маршрут на тот же самый префикс, но с меньшим AD (все помнят Administrative Distance?). Маршрут, источник которого – “connected”, всегда имеет AD=0, и ни один другой источник маршрутов не может привнести ничего ниже, чем «1», даже статический маршрут с явным указанием интерфейса. Пример connected:R00# show ip route C 10.0.0.0/24 is directly connected, GigabitEthernet0/1 Т.е. пока интерфейс Gi0/1 находится в состоянии up и имеет адрес из подсети 10.0.0.0/24, ни один статический маршрут на этот префикс в таблице маршрутизации не появится.

Еще есть вариант «разные источники маршрутов добавляют маршруты на один и тот же префикс с одинаковым AD». Поведение IOS в данном случае не документировано, общая рекомендация – «никогда так делайте».

Но посмотрим другие, менее очевидные примеры. Например, статические маршруты можно создать со словом «permanent», которое переводится как «постоянный», и тогда они будут всегда висеть в таблице маршрутизации. Правильно? Нет.

Добавляем его и смотрим:

R00(config)#ip route 3.1.1.0 255.255.255.0 10.0.0.3 permanent R00#show ip cef 3.1.1.0 3.1.1.0/24 nexthop 10.0.0.3 GigabitEthernet0/1 Кладем Gi0/1, и видим:R00#show ip cef 3.1.1.0 3.1.1.0/24 unresolved via 10.0.0.3 В RIB он есть, и другие протоколы маршрутизации могут его использовать:R00#show ip route 3.1.1.0 Routing entry for 3.1.1.0/24 Known via "static", distance 1, metric 0 Routing Descriptor Blocks: * 10.0.0.3, permanent Route metric is 0, traffic share count is 1 А теперь, не поднимая Gi0/1:R00(config)#no ip route 3.1.1.0 255.255.255.0 10.0.0.3 permanent R00(config)#ip route 3.1.1.0 255.255.255.0 10.0.0.3 permanent Просто пересоздали его, ничего не меняя. И вот что произошло:IP-ST(default): updating same distance on 3.1.1.0/24 IP-ST(default): 3.1.1.0/24 [1], 10.0.0.3 Path = 8, no change, not active state IP-ST(default): cannot delete, PERMANENT R00#show ip route 3.1.1.0 % Network not in table R00#show ip cef 3.1.1.0 0.0.0.0/0 no route Постоянный, говорите? Нет. Есть один маленький нюанс: чтобы перманентный маршрут навеки вписался в таблицу маршрутизации, нужно, чтобы он хотя бы на долю секунды резолвился. Хотя какое еще «навеки»? Когда он остался висеть в воздухе без резолвящегося интерфейса, достаточно сказать «clear ip route *» или тем более «reload», чтобы он исчез из RIB.

Но продолжим. Сделаем вот так:

R00(config)#ip route 3.1.1.0 255.255.255.0 Gi0/1 10.0.0.3 R00(config)#ip route 3.1.1.10 255.255.255.255 3.1.1.1 Вроде нормальные маршруты. Что произойдет? Со вторым – ровным счетом ничего.IP-ST(default): 3.1.1.10/32 [1], 3.1.1.1 Path = 8, no change, not active state IP-ST(default): 3.1.1.10/32 [1], 3.1.1.1 Path = 2 3 6 8, no change, not active state Суть вот в чем. Допустим, есть маршрут на X.X.X.X через Y.Y.Y.Y. Мы добавляем маршрут на X1.X1.X1.X1 (этот префикс полностью покрывается X.X.X.X) через X2.X2.X2.X2 (а он тоже покрывается X.X.X.X). IOS делает закономерный вывод: второй маршрут не несет в себе никакой новой информации и совершенно бесполезен, поэтому его можно не устанавливать в RIB.

А теперь финт ушами.

R00(config)#no ip route 3.1.1.10 255.255.255.255 3.1.1.1 R00(config)#ip route 3.1.1.10 255.255.255.255 Gi0/1 3.1.1.1 IP-ST(default): updating same distance on 3.1.1.10/32 IP-ST(default): 3.1.1.10/32 [1], GigabitEthernet0/1 Path = 1 RT: updating static 3.1.1.10/32 (0x0): via 3.1.1.1 Gi0/1 RT: network 3.0.0.0 is now variably masked RT: add 3.1.1.10/32 via 3.1.1.1, static metric [1/0], add succeed, active state IP ARP: creating incomplete entry for IP address: 3.1.1.1 interface GigabitEthernet0/1 IP ARP: sent req src 10.0.0.1 30e4.db16.7791, dst 3.1.1.1 0000.0000.0000 GigabitEthernet0/1 R00#show ip cef 3.1.1.10 3.1.1.10/32 nexthop 3.1.1.1 GigabitEthernet0/1 И вот это подводит нас к еще одному важному моменту. Указание интерфейса в статическом маршруте позволяет обойти многие проверки, так как статическому маршруту больше не требуется выполнять рекурсивные запросы к RIB в поисках пути до next hop, и при своем добавлении он не заденет триггеры на других маршрутах. Но это не отменяет главного требования: next hop обязан резолвиться в конкретный интерфейс, а тот интерфейс обязан быть в up. Тот факт, что рекурсивных запросов к RIB больше не будет, означает, что указанный IP адрес next hop’а находится прямо за интерфейсом, и наверняка отзовется на arp запрос (с точки зрения роутера). Если у соседнего по Gi0/1 роутера включен proxy arp, то он в ответ на arp запрос наверняка вернет свой mac адрес, и всё будет хорошо. Разве что лишняя запись в arp таблице…

Но все равно так делать не стоит.

Необходимо упомянуть и о еще одном важном моменте. Статический маршрут должен по идее исчезнуть из таблицы маршрутизации, как только он перестанет резолвиться. Но на практике есть множество ситуаций, когда next hop пропадает, но при этом статический маршрут на какое-то время остается. К примеру, когда next hop резолвится через маршрут, полученный от протокола динамической маршрутизации. Все дело в том, что процесс, отслеживающий наличие next hop в RIB, не всегда может получить уведомление об исчезновении маршрута, и он вынужден периодически (раз в 60 секунд по умолчанию) перепроверять, все ли хорошо. Это вызовет заметную задержку сходимости сети.

Поменять интервал проверки, к примеру, на 10 секунд можно с помощью команды:

ip route static adjust-time 10

habrahabr.ru

Азы статической маршрутизации ~ Сетевые заморочки

В прошлой статье мы с вами обсудили процесс маршрутизации между сетями, подключенными к интерфейсами одного единственного маршрутизатора (рекомендую ознакомиться с ней), сегодня же мы разберем, как осуществляется маршрутизация между сетями, подключенными к разным маршрутизаторам, связанным между собой. Пока что мы не будим лезть в дебри протоколов динамической маршрутизации, а разберемся, как пользоваться статической маршрутизацией. В качестве примеров, для демонстрации настройки будим использовать маршрутизаторы фирмы Cisco,  доступные в Packet Tracer.Как мы уже выяснили, если у нас всего один маршрутизатор, то нам достаточно всего лишь сконфигурировать его интерфейсы, и он сразу же будет выполнять маршрутизацию между сетями, подключенными к нему. Немного по иному обстоят дела, если в нашей сети есть несколько маршрутизаторов. Допустим, наша интерсеть сеть будет иметь следующий вид:
Объединение сетей с помощью маршрутизаторов

Как мы и обсуждали ранее сети, подключенные к интерфейсам одного маршрутизатора, будут видеть друг друга. Так сети «левого » маршрутизатора 192.168.1.0/24, 172.20.0.0/16 и 192.168.100.0/30 будут видеть друг друга. Аналогично обстоят дела с «правым» маршрутизатором. Но вот как будут обстоять дела с взаимодействием сетей данных маршрутизаторов между собой? Например, компьютеры сети 10.0.0.0/8 не будут доступны из сети 192.168.1.0/24.  Данный принцип, для всех сетей, проиллюстрирован на «жестком» рисунке ниже:

Карта доступности сетей

Почему же некоторые сети не видят друг друга. Все очень просто, соседние маршрутизаторы не содержат записей о сетях подключенных, только к другому маршрутизатору. Например, маршрутизатор «левый» не знает о существование сети 10.0.0.0/8, подключенной к «правому» маршрутизатору.

Давайте сымитируем данную ситуацию в Cisco Packet Tracer, а заодно поищем пути ее решения. Для начала соберем в Packet Tracer следующую схему (как это сделать смотрите в предыдущей статье):
Начинаем собирать нашу сеть
На данной схеме компьютер PC0 имеет IP адрес – 192.168.1.100, PC1 – 172.20.20.100, PC2 – 192.168.2.100, PC3 – 10.10.10.100. Интерфейсы маршрутизатора, к которым подключены компьютеры, имеют такие же адреса, как и сами компьютеры, только в четвертом октете стоит 1. Например, для интерфейса к которому подключен ПК с адресом 192.168.1.100 зададим IP адрес 192.168.1.1. В качестве шлюза по умолчанию у каждого компьютера указан интерфейс маршрутизатора, к которому он подключен. После настройке интерфейсов маршрутизаторов, сохраните их конфигурации, выполнив wr mem. Далее соединим маршрутизаторы между собой. Чтобы это сделать, нам потребуется добавить к маршрутизатору интерфейсную плату. В данном случае добавим к маршрутизатору плату  NM-1FE-TX (NM – Network module, 1FE – содержит один порт FastEthernet, TX – поддерживает 10/100MBase-TX).Чтобы это сделать перейдите к окну конфигурации маршрутизатора, выключите его, щелкнув по кнопке питания изображенной на нем.
Кнопка выключения маршрутизатора в Packet Tracer

После этого перетяните необходимую интерфейсную плату в разъем маршрутизатора.

Вставляем интерфейсную плату в маршрутизатор

После того как карта добавлена, еще раз щелкните по тумблеру маршрутизатора, чтобы включить его. Посмотрите его интерфейсы, должен добавиться еще один – FastEthernet1/0. Повторите аналогичные действия со вторым маршрутизатором. Задайте интерфейсу FastEthernet1/0 «левого» маршрутизатора IP адрес 192.168.100.1 c с маской 255.255.255.252, а «правому маршрутизатору» 192.168.100.2 с аналогичной маской. После этого соедините интерфейсы FastEthernet1/0  этих маршрутизаторов между собой.

Маршрутизатору, соединенные между собой

Проверим доступность компьютеров одной сети из других. Если все сделано верно, то картина доступности должна соответствовать второму рисунку данной статьи. Если вы внимательно посмотрите на данный рисунок, то заметите что на данном рисунке не все стрелки двунаправленные. С двунаправленными стрелками все понятно, если вы будите пинговать в данном направлении, то компьютеры будут отвечать вам на ваши ICMP запросы (так как происходит маршрутизация в пределах одного маршрутизатора). Намного интереснее  обстоит дело с однонаправленными зелеными стрелками. Хотя пинги в данном направлении не проходят, на самом деле ICMP пакеты доходят до места назначения, но вот вернуться обратно уже не могут. Рассмотрим как это происходит на конкретном примере. Допустим, с компьютера с IP адресом 172.20.20.100 вы пытаетесь пропинговать интерфейс с IP адресом 192.168.100.2, «правого» маршрутизатора. Картина будет выглядеть следующим образом:

Интерфейс "правого" маршрутизатора не отвечает

Попробуем отследить путь ICMP пакетов. Для этого включим дебаги  (режим отладки определенных параметров) на маршрутизаторах, через которые предположительно должны пройти ICMP пакеты. Выполним команду debug ip packet, на обоих маршрутизаторах. После чего опять попытаемся пропинговать с адреса  172.20.20.100 адрес 192.168.100.2. Посмотрим, что появилось на «левом маршрутизаторе»:

IP: tableid=0, s=172.20.20.100 (FastEthernet0/1), d=192.168.100.2 (FastEthernet1/0), routed via RIB

IP: s=172.20.20.100 (FastEthernet0/1), d=192.168.100.2 (FastEthernet1/0), g=192.168.100.2, len 128, forward

Первая строка говорит о том, что на маршрутизатор прибыл пакет с адреса 172.20.20.100, направляемый на адрес 192.168.100.2. Во второй строчке говорится о том, что данный пакеты был передан дальше, ключевое слово здесь «forward».

Теперь посмотри, что творится в это же время на «правом» маршрутизаторе:

IP: tableid=0, s=172.20.20.100 (FastEthernet1/0), d=192.168.100.2 (FastEthernet1/0), routed via RIBIP: s=172.20.20.100 (FastEthernet1/0), d=192.168.100.2 (FastEthernet1/0), len 128, rcvd 3

IP: s=192.168.100.2 (local), d=172.20.20.100 len 128, unroutable

Как видно из первых двух строчек, наш ICMP пакет все таки дошел до «правого» маршрутизатора.  А что должен сделать интерфейс, на который направлялся ping? Правильно, ответить на него послав ICMP пакеты в обратном направлении  с адреса 192.168.100.2 на 172.20.20.100. Вот тут то и начинаются проблемы. «Правый» маршрутизатор не имеет в своей таблице маршрутизации информации о сети 172.20.20.0/16. Шлюз по умолчанию мы еще не прописывали, поэтому маршрутизатор просто не может отослать ответы, в результате чего появляется третья строка дебага, ключевое слово в которой «unroutable».

После того как мы разобрались с тем, как в нашей сети, в данный момент, ходят пакеты. Отключим дебаги (no debug ip packet – отключает включенный ранее дебаг, show debugging – позволяет посмотреть включенные дебаги), и перейдем к настройке маршрутизации.

В нашей маленькой сети, самым простым способом настроить маршрутизацию, является добавление маршрута по умолчанию. Для того чтобы это сделать выполните на «левом» маршрутизаторе в режиме конфигурирования следующую команду:

   ip route 0.0.0.0 0.0.0.0 192.168.100.2

На «правом» маршрутизаторе:

   ip route 0.0.0.0 0.0.0.0 192.168.100.1

В следующих командах первые 4 цифры обозначают IP адрес сети назначения, следующие  4 цифры обозначают её маску, а последние 4 цифры – это IP адрес интерфейса, на который необходимо передать пакеты, чтобы попасть в данную сеть. Если мы указываем в качестве адреса сети 0.0.0.0 с маской 0.0.0.0, то данный маршрут становится маршрутом по умолчанию, и все пакеты, адреса назначения которых, прямо не указаны в таблице маршрутизации будут отправлены на адрес, указанный в нем.

Посмотрим как это выглядит на конкретном примере. Допустим, мы хотим пропинговать с компьютера с адресом 192.168.1.100 компьютер с IP адресом 10.10.10.100.  В качестве шлюза по умолчанию на компьютере с адресом 192.168.1.100 установлен адрес интерфейса маршрутизатора 192.168.1.1. Сначала компьютер будет искать в свой таблице маршрутизации (да у обычного компьютера она тоже есть) непосредственно адрес 10.10.10.100, после того как он его не найдет, он начнет искать в таблице маршрутизации маршрут к сети 10.0.0.0/8. После того, как данный маршрут так же не будет обнаружен. ICMP пакеты будут отправлены на адрес по умолчанию, то есть на интерфейс маршрутизатора с адресом 192.168.1.1. Получив пакет, маршрутизатор просмотрит адрес его назначения – 10.10.10.100 и также попытается обнаружить его в свой таблице маршрутизации. Когда это не увенчается успехом, маршрутизатор попробует найти в свой таблице маршрутизации маршрут к сети 10.0.0.0/8. Когда он не обнаружит и его, пакет будет отправлен используя, только что заданный нами, маршрут по умолчанию. И ICMP пакет будет передан на интерфейс, с адресом 192.168.100.2, «правого» маршрутизатора. Правый маршрутизатор попробует обнаружить в свой таблице маршрутизации маршрут к адресу 10.10.10.100. Когда это не увенчается успехом, «правый» маршрутизатор будет искать маршрут к сети 10.0.0.0/8. Информация о данной сети содержится в таблице маршрутизации, и маршрутизатор знает, что для того чтобы попасть в данную сеть необходимо отправить пакеты на интерфейс FastEthernet0/1, непосредственно к которому подключена данная сеть. Так как в нашем примере вся сеть 10.0.0.0/8, представляет из себя всего 1 компьютер, то пакеты сразу же попадают в место назначения, компьютер с IP адресом 10.10.10.100. При отсылке ответных ICMP пакетов, все происходит аналогичным образом, только адресом назначения уже будет являться 192.168.1.100/24.

К сожалению далеко не всегда можно обойтись указанием только маршрутов по умолчанию. В более сложных сетевых конфигурациях может потребоваться прописывать маршрут для каждой из сетей в отдельности. Давайте сразу рассмотрим как же это делается.  Для этого, сначала удалим из таблицы маршрутизации все статически добавленные маршруты, используя команду no ip route xxxx(адрес сети) yyyy(маска) zzzz(адрес интерфейса). В конечном итоге таблицы маршрутизации должны содержать только информацию о непосредственно подключенных  к ним сетях. Для «левого» маршрутизатора таблица будет примерно такой:

Содержимое таблицы маршрутизации

Теперь нам необходимо добавить к каждому из маршрутизаторов маршруты к двум сетям, которые ему неизвестны (к сетям, подключенным к соседнему маршрутизатору). На «левом» маршрутизаторе выполним:

   ip route 192.168.2.0 255.255.255.0 192.168.100.2

   ip route 10.0.0.0 255.0.0.0 192.168.100.2

На правом маршрутизаторе выполним:

   ip route 192.168.1.0 255.255.255.0 192.168.100.1

   ip route 172.20.0.0 255.255.0.0 192.168.100.1

Если все сделано верно, то ваши сети должны будут взаимодействовать согласно рисунку:

Карта сети

Как вы видите нам пришлось добавить довольно много маршрутной информации, даже  в такой простой сетевой конфигурации. А представьте сколько их придется прописывать, если у вас сеть имеющая десятки маршрутизаторов… Это будет адский труд. Поэтому в больших сетях обычно используют динамическую маршрутизацию, которая кроме облегчения составления таблиц маршрутизации имеет и другие плюсы. О динамической маршрутизации, мы поговорим с вами в следующих статьях.

www.netza.ru

Урок 27. Настройка статической маршрутизации

 

Чтобы лучше понять принцип маршрутизации настроим статическую маршрутизацию на основе нескольких примеров. Для настройки подключимся к консоли маршрутизатора посредством консольного (rollover) кабеля, а после установки IP адреса можно подключаться через Telnet/SSH.

 

После включения питания оборудование проходит диагностику, называемую POST (Power On Self Testing). Если оборудование и система в порядке, то загружается операционная система IOS (Internetwork Operating System).

Если система не содержит конфигурацию, то система запустит мастера первоначальной настройки, с помощью которого можно настроить порты, пароль к системе и т.д.:

Рекомендую пропустить данный этап и настроить необходимые параметры самостоятельно.

Но прежде повторим какие режимы доступны для настройки:

Теперь настроим сеть, указанную на рисунке:

 

Необходимо настроить маршрутизацию так, чтобы все компьютеры были друг другу доступны.

 

Приступим. 

Приведем настройки для маршрутизатора A_Router. Настройки для маршрутизатора B_Router аналогичны за исключением IP адресов.

 

Ввод в режим глобальной конфигурации:

Router> enable

Router# confgiure terminal

 

 Меняем имя маршрутизатора:

Router(config)# hostname A_Router

A_Router(config)#  - имя поменялось с Router на A_Router

 

Назначаем IP адрес и маску для интерфейса FastEthernet 0/0, подключенного к локальной сети: 

A_Router(config)# interface fastethernet0/0

A_Router(config-if)# ip address 172.16.0.1 255.255.0.0

 

Затем включаем интерфейс:

A_Router(config-if)# no shutdown

 

 Для информативности можно добавить комментарий к каждому интерфейсу:

A_Router(config-if)# description Connected to LAN as default gateway

 

То же самое проделаем и с другим интерфейсом, подключенному к маршрутизатору В. Настрой там сеть 10.1.1.0/30.  Подобные интерфейсы еще называют WAN (Wide Area Network) интерфейсами.

 

Теперь настроим статическую маршрутизацию к сети 192.168.1.0/24:

A_Router(config)# ip route 192.168.1.0 255.255.255.0 fastethernet0/1 - через

 этот интерфейс доступна сеть 192.168.1.0/24

 

либо можно ввести IP адрес интерфейса вместо его названия:

A_Router(config)# ip route 192.168.1.0 255.255.255.0 10.0.0.1

 

Подобные настройки с учетом IP адресов необходимо выполнить и на другом маршрутизаторе.

 

Вот как выглядит конфигурация на обоих маршрутизаторах:

 

Теперь выполни команду ping 192.168.1.100 с любого компьютера маршрутизатора A_Router. Если результат выглядит примерно так

то, все настроено правильно.

 

Поздравляю, статическая маршрутизация выполнена. Теперь каждый маршрутизатор будет доступен с любого компьютера.

 

Напомню, что данная конфигурация хранится в оперативной памяти, поэтому сохраним ее в энергонезависимой памяти для последующего использования:

A_Router# copy running-config startup-config

Destination filename [startup-config]?

 

Нажми Enter и конфигурация из оперативной памяти будет скопирована в энергонезависимую.

 

Running-config - текущая конфигурация в оперативной памяти

Startup-config - сохраненная конфигурация в энергонезависимой памяти NVRAM. Именно этот файл будет загружен в оперативную память маршрутизатора при включении питания.

 

Чтобы просмотреть текущую конфигурацию введи:

A_Router# show running-config

 

Чтобы увидеть таблицу маршрутизации введи:

 

Ты увидишь новый маршрут обозначенный буквой S, то есть статический (static):

Чтобы увидеть список всех интерфейсов введи:

A_Router# show ip interface brief

 

 

Теперь немного усложним задачу. Между маршрутизаторами поставим третий маршрутизатор:

 

Конфигурация маршрутизатора A_Router не изменилась, а в B_Router необходимо изменить адрес WAN интерфейса.

Вот как будет выглядеть конфигурация C_Router:

 

Таблицы маршрутизации A_Router и B_Router также не изменились. А в C_Router выглядит так:

А теперь еще больше усложним сеть, добавив четвертый маршрутизатор:

Теперь у нас имеется альтернативный маршрут через маршрутизатор D, который подключен к сети посредством серийных интерфейсов со скоростью передачи в 56 Кбит/с (настройку и принцип работы серийных интерфейсов мы рассмотрим в одном из последующих уроков).

Добавим новый маршрут в A_Router и B_Router. Настроем D_Router аналогично C_Router с учетом адресации.

 

Теперь таблицы маршрутизации будут выглядеть так:

Запустим утилиту Ping на одном из хостов, чтобы убедиться, что маршрутизация работает правильно.

 

По какому же маршруту передаются пакеты? 

Пакеты передаются одновременно по двум маршрутам, так как по умолчанию на маршрутизаторах Cisco включена балансировка нагрузки. 

С одной стороны все выглядит хорошо. Имеется запасной маршрут, повышающий надежность связи. Однако в этом кроется и потенциальная опасность.

В данном примере один маршрут является более медленным по сравнению с другим маршрутом, что может привести к значительным задержкам при передаче пакетов. Это крайне нежелательно при передаче медиатрафика (видео, голос). Для такого типа трафика необходим постоянный маршрут с минимальными задержками, то есть оптимальным решением является использовать быстрый маршрут для всего трафика, а второй - в качестве резервного на случай отказа первого.

 

Рассмотрим другую ситуацию. Подключим к сети коммутатор:

 

Конфигурация прежняя. Таблицы маршрутизации на A_Router и B_Router тоже не изменились. Пакеты свободно проходят по двум маршрутам.

 

Теперь отключим C_Router и проверим как будет работать связь:

В чем же дело? Ведь у нас же есть работающий маршрут. 

Взглянем на таблицу маршрутизации A_Router:

Ничего не изменилось. Маршрутизатор считает, что C_Router все еще работает и продолжают передавать через него часть пакетов. Поэтому почти половина пакетов потеряна.

 

Если мы отключим интерфейс Fast Ethernet 1/0 на A_Router, то запись о маршруте исчезнет из таблицы маршрутизации и все пакеты будут приняты:

Здесь оптимальным решением было бы использовать более медленный маршрут в качестве основного либо изменить топологию сети (данный пример лишь показательный).

Это лишь частные случаи, которые необходимо учитывать в каждой сети.

 

Какое же решение существует в данных примерах? 

Решение простое: в таблицу маршрутизации поместить один (основной) маршрут, который удаляется из таблицы в случае потери связи на канальном уровне. Альтернативный маршрут добавляется в таблицу сразу после удаления основного из таблицы.

 

Достигается это с помощью установки определенных приоритетов, которые называются административное расстояние (administrative distance). 

Административное расстояние показывает насколько надежным является маршрут по сравнению с другими маршрутами и принимает значения от 1 до 255. Чем ниже значение, тем более надежен маршрут. Статические маршруты по умолчанию всегда имеют административное расстояние равным 1. При наличии двух и более маршрутов до одной и той же сети в таблицу маршрутизации помещается маршрут с наименьшим административным расстоянием. То же самое касается и маршрутов, вычисленных динамическими протоколами маршрутизации RIP, OSPF, EIGRP. Каждый из них имеет определенное значение административного расстояния:

  • RIP - 120
  • OSPF - 110
  • EIGRP - 90

 

Из этого следует, что если в маршрутизаторе работают одновременно 2 и более протоколов маршрутизации, то в таблицу маршрутизации попадут маршруты протокола с более низким административном расстоянием (EIGRP) при условии, что эти протоколы вычислили маршруты до одной и той же сети назначения.

 

Вот как настраивается административное расстояние для статических маршрутов:

Router(config)# ip route сеть маска исходящий_интерфейс (адрес следующего хопа) административное_расстояние

 

Следует быть внимательным и аккуратным при использовании статической маршрутизации.

 

Где используется статическая маршрутизация? 

Чаще всего на маршрутизаторах клиентов, подключенных к провайдерам. В большинстве случаев такие маршрутизаторы имеют 2 интерфейса, поэтому достаточно пересылать пакеты до любых сетей через WAN интерфейс.

 

Неужели в этом случае для каждой сети нужно настраивать отдельный маршрут? 

Нет, достаточно ввести такую команду:

Router(config)# ip route 0.0.0.0 0.0.0.0 интерфейс (адрес следующего хопа)

 

Данная запись означает все сети, то есть образуют единый маршрут для всех сетей. Поэтому нет необходимости настраивать маршруты для каждой отдельной сети.

 

Однако запись

Router(config)# ip route 82.23.56.1 255.255.255.255 fastethernet1/0

 

означает маршрут до конкретного хоста, а не сети. С помощью маски и технологии VLSM можно объединять несколько маршрутов в один общий, если они проходят через один и тот же интерфейс или маршрутизатор.

 

easy-network.ru

Как прописать статический маршрут? И зачем он нужен? « Blog of Khlebalin Dmitriy

Как прописать статический маршрут? И зачем он нужен?

На прошлой неделе, пришлось вспомнить о статической маршрутизации в Windows…

Статическая маршрутизация — вид маршрутизации, при котором маршруты указываются в явном виде при конфигурации маршрутизатора. Вся маршрутизация при этом происходит без участия каких-либо протоколов маршрутизации.Статический маршрут —  представляет собой заданный администратором маршрут, который заставляет пакеты, перемещающиеся между источником и адресатом, отправляться по указанному пути. Другими словами это явно указанный путь по которому должен пройти пакет из пункта А в пункт Б.В этой статье мы с вами говорим, о статическом маршруте на обыкновенном компьютере с операционной системой Windows. Для чего же нам нужно уметь прописывать статические маршруты? Спросите вы, сейчас попробую объяснить, где это знание вам может пригодиться.Сейчас очень распространено для безопасности использовать  «Виртуальные частные сети» (VPN).  VPN используют как в организациях, для организации своей защищенной сети, так и провайдеры, для предоставления доступа, к глобальной сети Интернет, простым пользователям.  Но, так или иначе, это иногда вызывает небольшие неудобства, как в организациях, так и у обычных пользователей.  Например, у вас дома два компьютера один из которых имеет доступ в Интернет по средствам VPN,  также он соединен со вторым компьютером локальной сетью, и каждый раз, когда он подключается к Интернету, то связь между двумя компьютерами теряется, так как первый компьютер (который подключился к VPN) уже находиться в другой сети и поэтому недоступен со второго компа. Это можно исправить как раз с помощью статического маршрута. Или другой случай, пригодиться сисадминам, (пример из жизни) есть организация, у которой имеются небольшие удаленные офисы, связь с которыми идет по средствам OpenVPN и был случай, когда мне пришлось узнать внешние ip адреса у этих удаленных офисов, я подключался к компьютеру по VPN сети и соответственно не мог узнать внешний ip, так как он мне бы показал внешний ip нашего VPN соединения, но что же делать, я просто на всего прописал один статический маршрут на удаленном компьютере, с помощью которого я попал на нужный мне сайт (который показывал внешний ip) и все. Есть, конечно, и другой вариант, съездить туда и узнать ip без подключения к VPN сети, но вы сами понимаете, что на это нет времени и попросту неохота.  Теперь вы немного представляете, где и для чего вам может пригодиться знание того, как прописываются статические маршруты.Хватит теории, переходим к практике. Сейчас мы с вами пропишем маршрут, который разрешит нам получить доступ к локальной сети при включенном VPN соединении, пригодиться обычным пользователям, у которых дома более одного компьютера, а в Интернет выходят по средствам VPN.

Имеем локальную сеть: 192.168.1.0/24Локальный IP первого компьютера (пусть он будет компьютер — A) – 192.168.1.2 (на котором присутствует VPN соединения)Локальный IP второго компьютера (а этот компьютер — B) – 192.168.1.3IP адрес шлюза т.е. модема – 192.168.1.1Нам нужно прописать маршрут на компьютере A чтобы он смог видеть компьютер B при включенном VPN  соединении. Делается это следующем образом: запускаем командную строку Пуск->выполнить->cmd и набираем следующую команду:

route –p add 192.168.1.0 mask 255.255.255.0 192.168.1.1

 

где:route – сама программа которая работает с таблицей маршрутизации;-p – ключ, который говорит, что маршрут будет постоянный, так как (Важное замечание!) без этого ключа все маршруты, которые вы добавите удаляться после перезагрузке, поэтому если вы хотите использовать маршрут всегда, то пропишите этот ключ, если только один раз, то его можно не писать;add – сама команда добавляющая запись в таблицу маршрутизации;192.168.1.0 – сеть, с которой вы хотите иметь связь;mask 255.255.255.0 – маска подсети;192.168.1.1 – адрес шлюза, обычно это адрес модема.

Добавив всего один маршрут вы получаете доступ к своей сети при подключенном Интернете т.е. VPN соединении.

Вот еще один небольшой пример, у вас дома подключение к интернету через модем ADSL и вам иногда (ну или постоянно) требуется подключение к VPN сети и соответственно вы уже выхода в интернет через свой канал не будите иметь, но с помощью статического маршрута вы можете получить доступ к определенным сайтам (узнав предварительно их ip адреса, с помощью команды ping в командной строке, например ping yandex.ru) к которым вам бы хотелось иметь постоянный доступ (и при подключенном vpn соединение и не подключенном). Например, сайт имеет ip адрес 172.18.24.13 а шлюз (маршрутизатор, модем) имеет IP адрес 192.168.0.1 вам необходимо прописать следующие:

route –p add 172.18.24.13 mask 255.255.255.255 192.168.0.1

Теперь поговорим поподробней о команде route. Общий синтаксис:

route [-f] [-p] [destination] [mask ] [gateway] [metric ] [if ]

Рассмотрим команды и ключи этой программы:-f — удаляет из таблицы маршрутизации все маршруты-p – сохраняет маршрут на постоянную основуadd – добавляет новый маршрутchange — меняет текущий маршрут в таблице маршрутизацииdelete — удаляет маршрут из таблицы маршрутизацииprint —  отображает содержимое таблицы маршрутизацииdestination — при добавлении или изменении маршрута этот параметр используется для указания идентификатора сети назначенияmask — при добавлении или изменении маршрута этот параметр используется для указания маски подсети для сети назначенияgateway — при добавлении или изменении нового маршрута этот параметр используется для указания шлюза (маршрутизатора или модема)metric — используется для указания целого числа в диапазоне от 1 до 9999, являющегося метрикой стоимости для маршрута. Если для определенной сети назначения существует несколько возможных маршрутов, будет использован маршрут с наименьшим значением метрикиif — используется для указания номера индекса интерфейса, который подключен к сети назначения.

Для того чтобы просто посмотреть таблицу маршрутизации у себя на компьютере введите в командную строку следующие:

route print

Вот в принципе и все что я хотел вам рассказать, но следует помнить что, проводя все выше указанные манипуляции нужно быть внимательным, так как ошибка всего в одной цифре приведет к нежелательным результатам, не критичным, но нежелательным. В особенности это относиться к корпоративным сетям, где маршрутизация уже настроена, и вы можете легко изменить, удалить нужные маршруты.

Всем хорошей работы !!!

Понравилось это:

Нравится Загрузка...

Похожее

29.08.2012 - Posted by khlebalin | ms windows 2003

Sorry, the comment form is closed at this time.

khlebalin.wordpress.com


Смотрите также