Subnets.ru blog

Добро пожаловать в блог! Надеемся, что Вы еще вернетесь.

У Вас развелось много «железа» ?

Вы хотите, чтобы конфиги складывались на backup сервер автоматом ?

Это дело хорошее. Расскажу вам как это сделать один раз, в автоматическом режиме и забыть волнения по поводу «а если что упадет?».

Упадет — возьмете новую железку, зальете сохраненный конфиг и вперед !

Допустим что:

192.168.1.1 — IP-адрес cisco catalyst 2950 или cisco catalyst 2960
192.168.1.2 — IP-адрес cisco catalyst 3560G или любая другая циска 🙂
192.168.1.254 — IP-адрес backup сервера

Приступим:

Первый способ.

Для начала на наш FreeBSD backup сервер нужно установить порт:

cd /usr/ports/net-mgmt/p5-Telnet-Cisco
make install clean

После того как порт установился напишем небольшой perl скрипт:

#!/usr/bin/perl

use Net::Telnet::Cisco;

@c=("192.168.1.1","192.168.1.2");  #Массив с IP-адресами того что будем бекапить
@cn=("c2950.conf","c3560.conf");  #Как будет называться конфиг после бекапа
@login=("login","login");                 #Логин на оборудование
@pass=("c2950-passwd","c3560-passwd");       #Пароль
@passen=("en_passwd","en_passwd");             #Пароль на enable режим

$ftp="192.168.1.254";
$ftpuser="cisco-backup";      #Логин к FTP
$ftpass="ftpPasswd";           #Пароль к FTP

$maindir="/backup/cisco";     #Папка доступная по FTP

#Определяем папки в $maindir в формате ГОД/МЕСЯЦ/ДЕНЬ/ЧАС куда будет перемещен конфиг после закачки его на FTP
$dir="$maindir/inet";
$backup_dir=`date +"%Y/%m/%d/%H"`;
chomp($backup_dir);
$backup_dir="$dir/$backup_dir";

#Проверяем наличие директории куда будет складываться backup и
#Создаем директорию если её не существует
opendir(D,$backup_dir) or `/bin/mkdir -p $backup_dir`;
closedir D;

#Цикл по массиву с IP-адресами железок
for ($i=0;$i<=$#c;$i++){
        my $h=sprintf("%s",$c[$i]);
        my $conf=sprintf("%s",$cn[$i]);
        my $user=sprintf("%s",$login[$i]);
        my $pas=sprintf("%s",$pass[$i]);
        my $pasen=sprintf("%s",$passen[$i]);

        #Устанавливаем соединение с железкой
        my $session = Net::Telnet::Cisco->new(Host => $h);
        $session->login($user, $pas);
        # Enable mode
        if ($session->enable($pasen)) {
                #Если соединение установлено, то переходим в enable
                $session->errmode("return");
                my $bcmd=sprintf("copy startup-config ftp://%s:%s@%s",$ftpuser,$ftpass,$ftp);
                #Отправляем команды на backup
                my @output = $session->cmd('$bcmd');
                my @output1 = $session->cmd($ftp);
                my @output2 = $session->cmd("$conf");
        }else{
                warn "Can't enable: " . $session->errmsg;
        }
        $session->close;
        `/bin/sleep 3`;
        #Перемещаем закаченный на FTP конфиг в backup директорию
        #как итог она будет: /backup/cisco/inet/ГОД/МЕСЯЦ/ДЕНЬ/ЧАС
        system(sprintf("/bin/mv %s/%s %s",$maindir,$conf,$backup_dir));
}

Сохраняем наш скрипт, например как backup-cisco.pl

Делаем его запускаемым:

chmod a+x backup-cisco.pl

Вот и все. Осталось проверить его работу запустив руками, а затем, если все нормально, добавить его в crontab:

40 2 * * * root /backup/cisco/backup-cisco.pl

Что означает, что каждый день в 2:40 будет запускаться наш скрипт который сохранит конфиги цисок в директории /backup/cisco/inet/ГОД/МЕСЯЦ/ДЕНЬ/ЧАС

Второй способ.

Этот способ основан на кронтабе в самой циске.

Switch> enable
Switch# configure terminal
Switch# kron policy-list backup
Switch(config-kron-policy)# cli copy startup-config ftp://192.168.1.254
Switch(config-kron-policy)# exit
Switch(config)# ip ftp username cisco-backup
Switch(config)# ip ftp password ftpPasswd
Switch(config)# file prompt quiet
Switch(config)# kron occurrence backup at 2:40 recurring
Switch(config)# exit
Switch# wri

Посмотреть текущие kron задания можно командой:

show kron schedule

Удачного вам бекапа !

Ссылки:

• www.cisco.com
• Backup конфига Juniper на FTP

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

Авторы: Николаев Дмитрий (virus (at) subnets.ru) и Панфилов Алексей (lehis (at) subnets.ru)

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

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

Для примера будем добавлять маршрут в сеть 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)

Итак, вы в качестве пограничного маршрутизатора своей AS выбрали маршрутизатор Juniper.

Поздравляю вас ! Вы сделали отличный выбор ! 😉

В этой статье я постараюсь рассказать как настроить протокол BGP на оборудовании этого производителя.

Это не how-to на все случаи в жизни, а пример, с которого можно хоть как-то начать постигать замечательное железо от Juniper.

В качестве примера буду использовать:

Наша автономная система: AS100

Наш префикс: 1.1.0.0/20

Схема подключения:

Два апстрима: AS200 (2.2.2.1/30) и AS300 (3.3.3.1/30)

И один прямой пиринг с AS400 (4.4.4.1/30)

Будем подразумевать, что соответствующие IP интерфейсы на маршрутизаторе вы уже настроили. Пример настройки интерфейсов можно посмотреть в этой статье и сделать по аналогии.

Настройка протокола BGP начинается с секции protocols.

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

root@juniper> configure

перейдем в раздел protocols bgp

[edit]
root@juniper# edit protocols bgp

Начнем с того, что укажем номер своей автономной системы:

[edit protocols bgp]
root@juniper# set local-as 100

Зададим логирование изменений состояния «соседей» (peer):

[edit protocols bgp]
root@juniper# set log-updown

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

[edit protocols bgp]
root@juniper# set advertise-inactive

Зададим route flap damping (так называемые «хлопающие» маршруты):

Т.к. это пограничный маршрутизатор, а значит «серые» сети не должны выходить за его пределы, выполним следущее (discard):

[edit routing-options]
root@juniper# set route 10.0.0.0/8 discard

[edit routing-options]
root@juniper# set route 172.16.0.0/12 discard

[edit routing-options]
root@juniper# set route 192.168.0.0/16 discard

Не будем «насиловать» лишними маршрутами своих апстримов и будем им оглашать весь блок /20 целиком. Для этого сделаем агрегирование:

[edit routing-options]
root@juniper# set aggregate route 1.1.0.0/20 discard

Посмотрим что получилось в этой секции:

[edit routing-options]
root@juniper# show

Настало время создать маршрутные карты. Начнем с per-flow-load-balancing.

Перейдем в другую секцию:

[edit routing-options]
root@juniper# top

[edit]
root@juniper# edit policy-options

Создадим для per-flow-load-balancing:

[edit policy-options]
root@juniper# set policy-statement per-flow-load-balancing term balance then load-balance per-packet

Приступим к дефолтным маршрутным картам для соседей.

Для начала bogus-reject:

[edit policy-options]
root@juniper# set policy-statement bogus-reject from route-filter 127.0.0.0/8 orlonger

[edit policy-options]
root@juniper# set policy-statement bogus-reject from route-filter 10.0.0.0/8 orlonger

[edit policy-options]
root@juniper# set policy-statement bogus-reject from route-filter 172.16.0.0/12 orlonger

[edit policy-options]
root@juniper# set policy-statement bogus-reject from route-filter 192.168.0.0/16 orlonger

[edit policy-options]
root@juniper# set policy-statement bogus-reject from route-filter 169.254.0.0/16 orlonger

[edit policy-options]
root@juniper# set policy-statement bogus-reject from route-filter 224.0.0.0/4 orlonger

[edit policy-options]
root@juniper# set policy-statement bogus-reject from route-filter 240.0.0.0/4 orlonger

Так мы задали список маршрутов, теперь укажем что мы с ними хотим сделать, в т.ч., и не принимать такие маршруты:

[edit policy-options]
root@juniper# set policy-statement bogus-reject then reject

Создадим default-route-reject для запрета приема default gateway по протоколу BGP:

[edit policy-options]
root@juniper# set policy-statement default-route-reject from route-filter 0.0.0.0/0 exact

[edit policy-options]
root@juniper# set policy-statement default-route-reject then reject

Создадим bogus-ases для запрета приема «серых» (private) номеров AS:

[edit policy-options]
root@juniper# set policy-statement bogus-ases from as-path grey-as

[edit policy-options]
root@juniper# set policy-statement bogus-ases then reject

[edit policy-options]
root@juniper# set policy-statement as-path grey-as 64512-65535

Пришло время для карт для соседей. В маршрутных картах на in (input) вы можете «играться» с теми или иными маршрутами приходящими от соседей. Фильтровать что-то, поднимать local-prefence и т.п. Для примера покажу как поднять local-prefence на маршрутах, для которых ваш апстрим является origin (т.е. те маршруты, которые принадлежат его AS).

Итак Prov-1-in:

[edit policy-options]
root@juniper# set policy-statement Prov-1-in term own-as from as-path prov-1-as

[edit policy-options]
root@juniper# set policy-statement Prov-1-in term own-as then local-preference 200

[edit policy-options]
root@juniper# set policy-statement Prov-1-in term own-as then accept

Теперь создадим as-path:

[edit policy-options]
root@juniper# set as-path prov-1-as «.*200»

Т.к. orign AS для маршрута всегда находится в конце as-path, то я и задал регулярное выражение которое ищет AS200 в конце as-path. Подробнее о регулярных выражениях читайте в технической документации по вашей версии JUNOS. Вы можете использовать не только as-path, но и префиксы которые принадлежат данному апстриму. Это на ваш выбор. Я выбрал as-path потому, что бы каждый раз не лазать и не изменять конфиг когда у этого апстрима появится новый блок IP-адресов.

Теперь зададим последний этап обработки приходящих от этого апстрима маршутов и действий с ними. Т.к. у нас full-view, то логично, что мы разрешим все остальное:

[edit policy-options]
root@juniper# set policy-statement Prov-1-in term final-accept then accept

Тут же вы можете выставить default local-preference для этого апстрима:

[edit policy-options]
root@juniper# set policy-statement Prov-1-in term final-accept then local-preference 100

Проделайте тоже самое и для Prov-2-in подставив туда его значения создав policy-statement Prov-2-in и as-path с AS300.

Для примера для нашего прямого пира AS400 мы создадим маршрутку с его префиксами, а не с as-path:

[edit policy-options]
root@juniper# set policy-statement Peer-1-in term own-prefix from prefix-list-filter peer-1-prefix exact

[edit policy-options]
root@juniper# set policy-statement Peer-1-in term own-prefix then accept

Поднимем local-preference для этих маршрутов выше, чем все остальное:

[edit policy-options]
root@juniper# set policy-statement Peer-1-in term own-prefix then local-preference 210

Теперь запретим все остальное (т.к. как я уже говорил это прямой пир, а не апстрим, а раз так то принимаем только те префиксы, которые ему принадлежат):

[edit policy-options]
root@juniper# set policy-statement Peer-1-in term final-reject then reject

Ну и осталось создать peer-1-prefix который мы прописали выше и указать в нем префиксы, которые принадлежат AS400, допустим это будут префиксы:

• 195.128.0.0/16
• 77.87.224.0/21

[edit policy-options]
root@juniper# set prefix-list peer-1-prefix 195.128.0.0/16

[edit policy-options]
root@juniper# set prefix-list peer-1-prefix 77.87.224.0/21

Итак с приемом маршрутов разобрались, приступим к оглашению наших. Эта задача состоит из двух частей:

• оглашение агрегированного маршрута для апстримов
• оглашение разделенного блока /20 для прямого пира

При прописывании всех наших соседей мы использовали разные маршрутные карты для того, что бы у нас была возможность управлять анонсами для каждого соседа по разному. Это вам пригодится для управления входящим в вашу AS трафиком, например prepend`ом.

Начнем с AS200 (первый апстрим) и как мы условились апстримам мы оглашаем агрегированный маршрут:

[edit policy-options]
root@juniper# set policy-statement Prov-1-out term my-prefix from protocol aggregate

[edit policy-options]
root@juniper# set policy-statement Prov-1-out term my-prefix from policy our-CIDR-blocks-aggregated

[edit policy-options]
root@juniper# set policy-statement Prov-1-out term my-prefix then accept

Создадим сам фильтр policy our-CIDR-blocks-aggregated:

[edit policy-options]
root@juniper# set policy-statement our-CIDR-blocks-aggregated term AS100-prefix from route-filter 1.1.0.0/20 exact

[edit policy-options]
root@juniper# set policy-statement our-CIDR-blocks-aggregated term AS100-prefix then accept

Т.к. на данном этапе мы всем апстримам оглашаем одно и тоже, то создайте Prov-2-out сами.

Теперь нужно сделать out для нашего прямого пира и оглашать мы ему будем две сети /21:

[edit policy-options]
root@juniper# set policy-statement Peer-1-out term AS100-prefix from protocol static

[edit policy-options]
root@juniper# set policy-statement Peer-1-out term AS100-prefix from policy our-CIDR-blocks

[edit policy-options]
root@juniper# set policy-statement Peer-1-out term AS100-prefix then accept

[edit policy-options]
root@juniper# set policy-statement Peer-1-out term final-reject then reject

[edit policy-options]
root@juniper# set policy-statement our-CIDR-blocks term AS100-prefixes from route-filter 1.1.0.0/21 exact

[edit policy-options]
root@juniper# set policy-statement our-CIDR-blocks term AS100-prefixes from route-filter 1.1.8.0/21 exact

[edit policy-options]
root@juniper# set policy-statement our-CIDR-blocks term AS100-prefixes then accept

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

[edit policy-options]
root@juniper# commit check

Если в ответ вы получили сообщение:

configuration check succeeds

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

[edit policy-options]
root@juniper# commit comment «My first configuration»

Juniper может хранить до 50-ти «закомиченных» конфигураций и вы всегда можете откатываться к любой их них, поэтому я рекомендую всегда добавлять комментарий к конфигу, чтобы потом различать их 🙂

Посмотреть состояние всех соседей можно командой:

[edit policy-options]
root@juniper# run show bgp summary

Т.к. мы все ещё находимся в режиме конфигурирования нам приходится добавлять ключевое слово run чтобы команда show отработала не на конфигурации.

Если мы выйдем из режима конфигурирования:

[edit policy-options]
root@juniper# exit

то тут слово run добавлять уже не нужно:

root@juniper> show bgp summary

Другие команды для просмотра состояний соседей, пришедших/отправленных им маршрутах и т.п. я рассмотрю в другой статье.

Мануал, по всем командам, вы можете прочитать в технической документации по вашей версии Junos на сайте производителя: www.juniper.net

Рекомендую полистать книгу:

JUNOS Cookbook

By Aviva Garrett

………………………………………..

Publisher: O’Reilly

Pub Date: April 2006

Print ISBN-10: 0-596-10014-0

Print ISBN-13: 978-0-59-610014-8

Pages: 682

Заранее прошу прощения за оЧепЯтки и неточности. По мере нахождения багов и замечаний статья будет изменяться.

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

Автор: Николаев Дмитрий (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 — попадают ли пакеты под
соответствующие правила и информацию о маршрутизации пакета.

---

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

---

Посмотреть содержание маршрутной карты можно командой:
Switch# show route-map TEST

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

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