Subnets.ru blog

Ответ на частые вопросы:

• Как добавить статический маршут ?
• Как посмотреть таблицу маршрутизации ?

Для примера будем добавлять маршрут в сеть 10.10.0.0/16 (маска 255.255.0.0) через gateway 10.10.1.1/24

Не забывайте, что маршрут добавится ТОЛЬКО если на вашем компьютере есть IP-адрес который входит в одну подсеть с gateway (в данном примере gateway 10.10.1.1, значит у вас должен быть настроен IP-адрес из сети 10.10.1.0/24 т.к IP-адрес gateway имеет маску /24 (255.255.255.0))

FreeBSD

Добавление:

route add 10.10.0.0/16 10.10.1.1

если после выполнения команды вам говорится, что команда не найдена, то используйте полный путь до команды route (и для других команд):

/sbin/route

так же если прочитать:

man route

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

/sbin/route add -net 10.10.0.0 -netmask 255.255.0.0 10.10.1.1

Просмотр таблицы маршрутизации выполняется командой:

netstat -rn

с полным путем:

/usr/bin/netstat -rn

Удаление:

/sbin/route delete 10.10.0.0/16

Linux

Добавление:

route add -net 10.10.0.0/16 gw 10.10.1.1

альтернатива:

ip route add 10.10.0.0/16 via 10.10.1.1

Просмотр таблицы:

route -n

или используйте:

ip route

Удаление:

route delete -net 10.10.0.0 netmask 255.255.0.0

Windows

Откройте командную строку (cmd).

Добавление:

route add 10.10.0.0 mask 255.255.0.0 10.10.1.1

Просмотр:

route print

Удаление:

route delete 10.10.0.0 mask 255.255.0.0 10.10.1.1

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА !

Автор: Николаев Дмитрий (virus (at) subnets.ru)

Policy-based routing — это более гибкий механизм маршрутизации пакетов, чем обычная адресная маршрутизация (destination routing).

Его главная особенность состоит в том, что перед маршрутизацией все пакеты проходят через
маршрутную карту (route-map), которая определяет, какие пакеты маршрутизировать и какой роутер будет следующим исходя из IP-адреса источника (source — source routing). Вы можете включить policy-based routing если хотите, чтобы некоторые пакеты были направлены по пути, отличному от очевидно самого короткого пути (the obvious shortest path), то есть пути взятого из таблицы маршрутизации.

Необходимость применения данного метода разнообразна, например когда необходимо маршрутизировать несколько подсетей в два и более канала от двух разных провайдеров т.к. каждый провайдер дал свою подсеть, а default gateway на cisco смотрит только на одного из провайдеров.

Допустим что:
У нас имеется cisco catalyst 3560G c IOS advanced ip services
интерфейс для стыка с провайдером «пров-1» vlan 10, IP-адресация 1.1.1.0/30
выделенная подсеть для раздачи под юзеров 192.168.241.0/26
IP-адрес 192.168.241.1 висит на vlan 20

интерфейс для стыка с провайдером «пров-2» vlan 11, IP-адресация 2.2.2.0/30
выделенная подсеть для раздачи под юзеров 10.0.18.0/26
IP-адрес 10.0.18.1 висит на vlan 21

при этом роутинг по умолчанию на cisco указан на «пров-1»

ip route 0.0.0.0 0.0.0.0 1.1.1.1

Соответственно получаем ситуацию когда подсеть выделенная от пров-2 будет улетать в канал от пров-1 и работать не будет. В этой ситуации нам и поможет policy-based routing

Как разрешить эту проблему используя policy-based routing:
Switch> enable
Switch# configure terminal
Switch(config)# ip routing
Switch(config)# sdm prefer routing
Switch(config)# exit
Switch# wri
Switch# reload

После того как cisco перезагрузится:

Создаем standart access-list (например номер 11) где описываем подсеть выделенную пров-2:
Switch> enable
Switch# configure terminal
Switch(config)# ip access-list standard 11
Switch(config-std-nacl)# permit 10.0.18.0 0.0.0.63
Switch(config-std-nacl)# exit

Далее создаем маршрутную карту указывая в ней созданный access-list как то что нужно матчить (match):

Switch(config)# route-map TEST permit 10
Switch(config-route-map)# matсh ip address 11
Switch(config-route-map)# set ip next-hop 2.2.2.1
Switch(config-route-map)# exit

Так мы создали маршрутную карту route-map с именем TEST, которая матчит IP-адреса из подсети пров-2 и выставляет как next-hop IP-адрес пров-2, теперь осталось её применить.

Заходим на интерфейс cisco на котором висит IP-адрес 10.0.18.1, который будет выступать в качестве default gateway для пользователей в этой подсети:

Switch(config)# int vlan 21
Switch(config-if)# ip policy route-map TEST
Switch(config-if)# exit
Switch(config-if)# exit
Switch# wri

Вот и все. Таким образом все пакеты приходящие от подсети 10.0.18.0/26 на интерфейс vlan 21 будут «улетать» в правильный канал, а именно канал от пров-2.

Командой Switch# debug ip policy вы можете включить режим, который поможет вам
определить, что делает policy-based routing — попадают ли пакеты под
соответствующие правила и информацию о маршрутизации пакета.

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА !

Автор: Николаев Дмитрий (virus (at) subnets.ru)

Многие новички в сетях и FreeBSD сталкиваются с вопросом:

«Как соединить две сети если сервер на FreeBSD имеет физическое подключение к обеим сетям ?»

Схема сети

Иными словами сервер FreeBSD должен выступать в роли router (маршрутизатор).

Итак, что мы имеем:

• Ethernet сеть
• Две подсети класса «С» (/24 — маска 255.255.255.0)
• Сервер FreeBSD с двумя сетевыми картами
• Клиенты в обеих подсетях

Наша задача, чтобы клиенты из подсети 192.168.1.0/24 могли обмениваться трафиком с клиентами из подсети 192.168.0.0/24.

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

За это отвечает параметр net.inet.ip.forwarding, посмотрим в какое значение он имеет:

[root@freebsd ~]# sysctl net.inet.ip.forwarding
net.inet.ip.forwarding: 0

На данный момент его значение «0», а это значит, что сервер FreeBSD не будет выполнять маршрутизации.

Включим эту функцию:

[root@freebsd ~]# sysctl net.inet.ip.forwarding=1
net.inet.ip.forwarding: 0 -> 1

Так мы изменили значение с «0» на «1». Теперь нужно сделать, так чтобы после ребута это значение всегда было 1-цой. Это можно сделать 2-мя способами:

1. в файл /etc/rc.conf добавить строчку: gateway_enable=»YES»
2. в файл /etc/sysctl.conf добавить строчку: net.inet.ip.forwarding=1

На сервере у нас есть две сетевые карты и соответственно два интерфейса: em0 и em1.

Пусть em0 «смотрит» в сеть слева, а em1 в сеть справа. Назначим IP-адреса для интерфейсов FreeBSD сервера:

[root@freebsd ~]# ifconfig em0 add 192.168.1.1/24
[root@freebsd ~]# ifconfig em1 add 192.168.0.1/24

Если на команду ifconfig вы получаете ответ:
command not found
воспользуйтесь командой
[root@virus ~]# whereis ifconfig
ifconfig: /sbin/ifconfig /usr/share/man/man8/ifconfig.8.gz /usr/src/sbin/ifconfig
которая укажет где именно располагается утилита ifconfig
как видно из результата выполнения команды whereis утилита ifconfig находится /sbin/ifconfig
вводите полный путь до утилиты ifconfig, тогда надпись command not found появляться не будет и команда будет выполняться

[root@freebsd ~]# ifconfig -a

em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
           ether 00:02:a5:4e:92:48
           inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
           media: Ethernet autoselect (100baseTX <full-duplex>)
           status: active
em1: flags=8802<UP,BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
           ether 00:02:a5:4e:92:49
           inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255
           media: Ethernet autoselect (100baseTX <full-duplex>)
           status: active

Рассмотрим что все это значит :

em0 и em1 — имена сетевых интерфейсов
флаг UP — означает что сетевая карта включена, если этого флага не будет, то пакеты не будут приниматься на этом интерфейсе (для включения воспользуйтесь командой: ifconfig ИМЯ_ИНТЕРФЕЙСА up)
ether — это mac-адрес этой сетевой карты
inet — назначенный IP-адрес для этого интерфейса и broadcast адрес для этой подсети
media — информация о скорости и дуплексе интерфейса
status — текущий статус интерфейса. Если status: no carrier, то это означает, что на сетевой карте нет линка.

Сохраним настройки, чтобы IP-адреса назначались интерфейсам после ребута сервера, для этого необходимо добавить в файл /etc/rc.conf следующие строчки:

ifconfig_em0=»inet 192.168.1.1 netmask 255.255.255.0″
ifconfig_em1=»inet 192.168.0.1 netmask 255.255.255.0″

Если на сервере вы используете firewall, например ipfw, то добавим правила разрешающие проход пакетов из одной сети в другую:

ipfw add 100 allow ip from 192.168.1.1/24 to 192.168.0.1/24
ipfw add 110 allow ip from 192.168.1.0/24 to 192.168.1.1/24

Теперь настройте клиентские компьютеры:

• Выставить IP-адрес из нужной подсети: 192.168.1.ХХХ или 192.168.0.ХХХ
• Выставить маску подсети 255.255.255.0
• Выставить шлюз по умолчанию: для подсети 192.168.1.ХХХ это 192.168.1.1, а для подсети 192.168.0.ХХХ это 192.168.0.1 (именно эти IP-адреса на интерфейсах нашего FreeBSD сервера)

Наступило время проверить есть ли связь сервера и клиентов. Для этого возьмем заведомо рабочий клиентский компьютер из 2-х сетей, например это будут компьютеры с IP-адресами:

• 192.168.1.11
• 192.168.0.15

Воспользуемся утилитой ping на сервере:

[root@freebsd ~]# ping 192.168.1.11

Если результат будет таким:

PING 192.168.1.11 (192.168.1.11): 56 data bytes
64 bytes from 192.168.1.11: icmp_seq=0 ttl=64 time=0.466 ms
64 bytes from 192.168.1.11: icmp_seq=1 ttl=64 time=0.238 ms
64 bytes from 192.168.1.11: icmp_seq=2 ttl=64 time=0.272 ms
^C
— 192.168.1.11 ping statistics —
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.238/0.325/0.466/0.100 ms

Значит все хорошо и связь между сервером и клиентом есть. Проделайте тоже самое с 192.168.0.15.

Если результат ping отрицательный, то убедитесь что на клиентском компьютере правильно выставлен IP-адрес и маска подсети, а так же наличие линка на сетевой карте.

Теперь можно попробовать проверить связь между клиентскими компьютерами из разных подсетей.

Так же воспользуемся утилитой ping, но уже на компьютере с IP-адресом 192.168.1.11:

ping 192.168.0.15

Если ответ есть, то и свзяь между компьютерами из разных подсетей есть.

Если ответа нет, то воспользуемся утилитой tracert (для Windows) или traceroute (для FreeBSD):

tracert 192.168.0.15

Если сразу «идут звездочки»:

1 * * *

То проверьте правильность выставление шлюза по умолчанию.

Если трасса выглядит так:

1 192.168.1.1 (192.168.1.1) 0.421 ms 0.447 ms 0.485 ms
2 * * *

То пакет доходит до сервера, убедитесь что firewall сервера не блокирует пакеты и что клиентский компьютер с IP-адресом 192.168.0.15 правильно настроен и «видит» сервер (проверьте IP-адрес, маску подсети, шлюз по умолчанию и наличие ping до сервера)

Вы все проверили, но по прежнему ничего не работает ? Воспользуемся утилитой tcpdump на сервере, которая покажет пакеты проходящие через интерфейсы сервера:

[root@freebsd ~]# tcpdump -ni em0
и
[root@freebsd ~]# tcpdump -ni em1

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

[root@freebsd ~]# tcpdump -ni em0

12:17:23.398376 IP 192.168.1.11 > 192.168.0.15: ICMP echo request, id 49222, seq 0, length 64
12:17:24.399906 IP 192.168.1.11 > 192.168.0.15: ICMP echo request, id 49222, seq 1, length 64

Т.е. компьютер 192.168.1.11 посылает пакет ICMP echo request до компьютера 192.168.0.15, но ответов мы не видим. Посмотри передает ли сервер эти пакеты на другую сетевую карту:

[root@freebsd ~]# tcpdump -ni em1

12:21:18.167017 IP 192.168.1.11 > 192.168.0.15: ICMP echo request, id 50246, seq 4, length 64
12:21:19.168022 IP 192.168.1.11 > 192.168.0.15: ICMP echo request, id 50246, seq 5, length 64

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

Когда все работает вывод будет таким:

12:21:17.165998 IP 192.168.1.11 > 192.168.0.15: ICMP echo request, id 50246, seq 3, length 64
12:21:17.171199 IP 192.168.0.15 > 192.168.1.11: ICMP echo reply, id 50246, seq 3, length 64
12:21:18.167017 IP 192.168.1.11 > 192.168.0.15: ICMP echo request, id 50246, seq 4, length 64
12:21:18.171353 IP 192.168.0.15 > 192.168.1.11: ICMP echo reply, id 50246, seq 4, length 64

Мы видим стандартый вывод «запрос-ответ», когда на пакет ICMP echo request приходит ответ в виде пакета ICMP echo reply

Ссылки:

• Настраиваем 802.1Q trunk между свичами Cisco Catalyst 3560G и сервером FreeBSD
• Настраиваем vlan на FreeBSD

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА !

Автор: Николаев Дмитрий (virus (at) subnets.ru)

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

Введние в статичскую маршрутизацию

Статический маршруты используются по ряду причин и чаще всего, когда не существует динамического маршрута к определенному месту назначения или когда включение динамического протокола маршрутизации не выполнимо. По умолчанию статические маршруты имеют административную дистанцию равную 1, что дает им преимущество над маршрутами изученными из динамических протоколов маршрутизации. Что такое административная дистанция и как она влияет на выбор маршрута, читайте в статье “Административная Дистанция”, опубликованной ранее на CicsoLab.RU.

Когда вы увеличиваете административную дистанцию в значение большем чем значение динамического протокола маршрутизации, статический маршрут будет работать только в случае, когда пропадет динамическая маршрутизация. Например, маршруты изученные из динамического протокола IGRP имеют административную дистанцию по умолчанию 100. Для того, чтобы конфигурировать статический маршрут, который будет перекрыт IGRP маршрутом, укажите административную дистанцию больше 100. Такой вид статической маршрутизации называется “плавающей”. Такой маршрут инсталлируется в таблицу маршрутизации только, когда более предпочтительный маршрут исчезнет оттуда. Например,

ip route 172.31.10.0 255.255.255.0 10.10.10.2 101

Обратите внимание, что административная дистанция 255, рассматривается как недостижимая и статический маршрут с административной дистанцией 255 никогда не будет введен в таблицу маршрутизации.

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

ip route 0.0.0.0 0.0.0.0 Ethernet0

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

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

Указание числового следующего хопа (next hop) для маршрута, предотвратит выполнение ARP запросов на каждый адрес. Однако, если интерфейс за которым лежит next hop упадет, а числовое значение следующего хопа достижимо через рекурсивный маршрут, вы должный указать и IP адрес следующего хопа и интерфейс через который данный next hop может быть найден. Например,

ip route 0.0.0.0 0.0.0.0 Serial 3/3 192.168.20.1

Проблема

Теперь рассмотрим небольшой проблемный сценарий. В данной сетевой диаграмме, существует два статических маршрута к одному и тому же месту назначения (172.31.10.0/24). Один маршрут является “плавающим” маршрутом. Это резервный путь к целевой сети. Проблема в данном сценарии в том, что плавающий маршрут никогда не инсталлируется не таблицу маршрутизации, когда основной канал падает.

Рис.1

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

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

Выбираем наилучший путь

Административная дистанция это первый критерий который использует маршрутизатор, чтобы определить какой протокол маршрутизации использовать если два протокола предоставляют маршрутную информацию к одному и тому же месту назначения. Административная дистанция это мера доверия или надежности к источнику маршрутной информации. Административная дистанция имеет только местное значение и не вещается в маршрутных обновлениях (routing updates).

Чем меньше численное значение административной дистанции, тем более надежен протокол. Например, если роутер принимает маршрут к определенной сети и через OSPF и через IGRP, маршрутизатор выберет протокол IGRP, поскольку IGRP более надежен. Это значит, что маршрутизатор добавит в свою роутинговую таблицу маршрут от протокола IGRP.

Если вдруг, вы потеряли источник IGRP информации (например, выключили питание на нем), роутер будет использовать информацию поставляемую протоколом OSPF, до тех пор пока источник IGRP маршрутов не возобновит свою работу.

Таблица значений административной дистанции

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

Если административная дистанция равна 255, роутер не доверяет источнику маршрута и никогда не инсталлирует такой маршрут в таблицу маршрутизации.

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

ip route 10.0.0.0 255.0.0.0 Dialer 1 250

Здесь административная дистанция для маршурута 10.0.0.0/8 установлена в значение 250.

Таблица маршрутизации может выглядеть следующий образом

R1#show ip route

Gateway of last resort is not set

172.16.0.0/24 is subnetted, 1 subnets
C 172.16.1.0 is directly connected, Ethernet0
R 10.0.0.0/8 [120/1] via 172.16.1.200, 00:00:16, Ethernet0
C 192.168.1.0/24 is directly connected, Loopback0

Если интерфейс Ethernet0 упадет, то в таблицу маршрутизации инсталлируется плавающий статический маршрут и весь трафик предназначенный для сети 10.0.0.0/8 будет маршрутизироваться через интерфейс Dialer 1 и по резервному каналу.

R1#show ip route
Gateway of last resort is not set
172.16.0.0/24 is subnetted, 1 subnets
C 172.16.1.0 is directly connected, Ethernet0
S 10.0.0.0/8 is directly connected, Dialer1
C 192.168.1.0/24 is directly connected, Loopback0

Как только Ethernet интерфейс подниматься обратно, то в таблицу сразу же инсталлируется маршрут от динамического протокола RIP и трафик снова пойдет через Ethernet 0.

По материалам: cisco.com

Оригинал статьи тут