ISP`s IT Аутсорсинг
Быстрый переход: Главная блога Главная сайта Форум
Если Вы чего то недопоняли или не нашли - задайте
вопрос на нашем форуме и мы попробуем Вам помочь.
Subnets.ru Регистрация IP и Автономных систем mega-net.ru

Архив за Ноябрь, 2010

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

Задача

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

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

Имеем

  • Juniper M10i
  • JUNOS 10.1R1.8

Решение

Решить эту задачу нам поможет  routing-instances.

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

Читаем доку: Configuring Routing Instances

Первый возникающий вопрос это какого типа routing-instances нам нужен ? Смотрим описание:

  • forwarding—Provide support for filter-based forwarding, where interfaces are not associated with instances. All interfaces belong to the default instance. Other instances are used for populating RPD learned routes. See Configuring Filter-Based Forwarding.
  • l2vpn—Provide support for Layer 2 VPNs. For more detailed information about configuring VPNs, see the JUNOS VPNs Configuration Guide.
  • layer2-control—(MX Series routers only) Provide support for RSTP or MSTP in customer edge interfaces of a VPLS routing instance. For more detailed information about configuring RSTP and MSTP, see the JUNOS MX Series Ethernet Services Routers Layer 2 Configuration Guide
  • no-forwarding—This is the default routing instance. Do not create a corresponding forwarding instance.
  • virtual-router—Similar to a VPN routing and forwarding instance type, but used for non-VPN-related applications. There are no VRF import, VRF export, VRF target, or route distinguisher requirements for this instance type.
  • virtual-switch—(MX Series routers only) Provide support for Layer 2 bridging. Use this routing instances type to isolate a LAN segment with its Spanning Tree Protocol (STP) instance and separates its VLAN identifier space. For more detailed information about configuring a virtual switch, see the JUNOS MX Series Ethernet Services Routers Layer 2 Configuration Guide and the JUNOS MX Series Ethernet Services Routers Solutions Guide.
  • vpls—Virtual private local-area network (LAN) service. Use this routing instance type for point-to-multipoint LAN implementations between a set of sites in a VPN. For more information about configuring VPLS, see the JUNOS VPNs Configuration Guide.
  • vrf—VPN routing and forwarding instance. Provides support for Layer 3 VPNs, where interface routes for each instance go into the corresponding forwarding table only. For more information about configuring VPNs, see the JUNOS VPNs Configuration Guide.

To configure a routing instance type, include the instance-type statement:

routing-instances {
     routing-instance-name {
           interface interface-name;
           instance-type (forwarding | l2vpn | layer2-control | no-forwarding | virtual-router | virtual-switch | vpls | vrf);
     }
}

Если вы общались с железом от Cisco, то первое что вам бросится в глаза, так это знакомое слово VRF (либо вы уже слышали/настраивали VRF-lite).

В моем случае мне походит тип virtual-router, т.к. VPN`а у меня нет, а все что мне нужно это создать вторую, отдельную от основной, таблицу маршрутизации, которая будет действовать только в пределах данного роутера.

Приступим

Исходные данные для нашего VRF:
VRF апстрим #1:

  • подключен к физическому интерфейсу: ge-0/0/1.0
  • ASN: 100
  • IP-адрес: 1.1.1.1/30

VRF апстрим #2:

  • подключен к физическому интерфейсу: ge-0/0/2.0
  • ASN: 200
  • IP-адрес: 2.2.2.1/30

VRF клиент #1:

  • подключен к физическому интерфейсу: ge-0/1/0.0
  • ASN: 300
  • IP-адрес: 3.3.3.2/30

Назовем наш VRF именем test, а наш номер AS будет 400.

Обращаю ваше внимание так это на то, что конфигурацию протокола BGP у основного роутера мы не трогаем, т.е. никаких изменений туда вносить не надо.
Подмечу, что конфигурацию самих физических интерфейсов и policy-statement (роут мапов) для пиров в нашем VRF нужно производить в режиме конфигурирования основного роутера, а не в routing-instances test.

Заходим в режим конфигурирования:

root@juniper> configure

Затем перейдем в уровень routing-instances:

root@juniper# edit routing-instances

После чего нам нужно задать имя нашего routing-instance (допустим test) и задать в нем остальные настройки, в том числе настройки протокола BGP.

[edit routing-instances]
root@juniper#
set test description «test routing table»

Зададим тип  routing-instance:

[edit routing-instances]
root@juniper#
set test instance-type virtual-router

Затем укажем какие интерфейсы роутера помещать в данный instance (в моем случае это будет три интерфейса, т.к. три пира и каждый в своем интерфейсе, это могут быть как целиком физические интерфейсы, так и вланы):

[edit routing-instances]
root@juniper#
set test  interface ge-0/0/1.0
root@juniper# set test  interface ge-0/0/2.0
root@juniper# set test  interface ge-0/1/0.0

Дальнейшая настройка routing-instance ничем не отличается от настройки основного роутера. Те же секции, те же команды. Не буду далее описывать каждую команду и покажу что мы должны получить на выходе по нашему routing-instance test:
[edit]
root@juniper#
show routing-instances test

test {
    description "test routing table";
    instance-type virtual-router;
    interface ge-0/0/1.0;
    interface ge-0/0/2.0;
    interface ge-0/1/0.0;
    routing-options {
        router-id 1.1.1.2;
        autonomous-system 400;
    }

    protocols {
        bgp {
            path-selection always-compare-med;
            traceoptions {
                file bgp_vrf.log size 1m files 10;
            }
            log-updown;
            remove-private;
            local-as 400;
            group upstreams {
                type external;
                no-advertise-peer-as;
                neighbor 1.1.1.1 {
                    description VRF_Upstream_1;
                    import vrf-upstream-1-in;
                    export vrf-customer;
                    remove-private;
                    peer-as 100;
                }
                neighbor 2.2.2.1 {
                    description VRF_Upstream_2;
                    import vrf-upstream-2-in;
                    export vrf-customer;
                    peer-as 200;
                }
            }
            group customers {
                neighbor 3.3.3.2 {
                    description VRF_client_1;
                    import vrf-client-in;
                    export vrf-client-out;
                    peer-as 300;
                }
            }
        }
    }
}

Собственно на этом конфигурация VRF и закончена. Как видно из конфига мы настроили BGP протокол внутри VRF`а где апстримов поместили в группу upstreams, а нашего клиента в группу customers.

Теперь остается настроить сами физические интерфейсы и создать полиси-мапы (vrf-upstream-1-in, vrf-customer, vrf-upstream-2-in, vrf-customer, vrf-client-in, vrf-client-out).

Напоминаю, что это делается в режиме «глобального» конфигурирования роутера, а не в routing-instance test.

Что мы должны увидеть после коммита данного конфига ?

По команде:

[edit]
root@juniper#
run show bgp summary

мы увидим что появилась ещё одна роутинг таблица, в которой перечислены наши VRF пиры.

Так же можно посмотреть что там с маршрутами в нашей routing-instance test:

[edit]
root@juniper#
run show route table test.inet.0

Несколько заметок, например запустив пинг до нашего VRF клиента командой:

[edit]
root@juniper#
run ping 3.3.3.2

не удивляйтесь что пинга нет, даже при наличии линка на физическом интерфейсе и не торопитесь с выводами, что физика не работает или с той стороны не настроен IP-адрес, просто вы забыли о том, что вы выполняете эту команду из основного роутера, а ведь физический интерфейс в сторону VRF-клиента принадлежит routing-instance test и основной роутер действительно не знает маршрут в эту подсеть.

Меняем команду на:

[edit]
root@juniper#
run ping 3.3.3.2 routing-instance test
и вот он наш пинг:

PING 3.3.3.2 (3.3.3.2): 56 data bytes
64 bytes from 3.3.3.2: icmp_seq=0 ttl=255 time=0.660 ms
64 bytes from 3.3.3.2: icmp_seq=1 ttl=255 time=0.647 ms
^C
--- 3.3.3.2 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.647/0.653/0.660/0.007 ms

т.е. мы явно сказали роутеру какой instance использовать для отправки пакетов до хоста 3.3.3.2.

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

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

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 3, среднее: 5,00 из 5)
Загрузка...
Отправить на почту Отправить на почту

Возникла задача удаленного реинсталла сервера c установленной FreeBSD, осложнявшаяся отсутствием KVM как класса и сложностью доступа к серверу.
Погуглив, было найдено это описание. То, что и было нужно. Нам понадобятся две вещи:

  1. ISO-образ будущей устанавливаемой системы
  2. Пакет утилит mfsBSD

Приступим к созданию загрузочного имиджа.

Создадим рабочую директорию:
# mkdir /usr/zzz
# cd /usr/zzz

Выкачиваем ISO:
# fetch ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/ISO-IMAGES/8.1/FreeBSD-8.1-RELEASE-amd64-disc1.iso
Выкачиваем mfsBSD:
#fetch http://people.freebsd.org/~mm/mfsbsd/mfsbsd-latest.tar.gz
распаковываем и переходим в получившующся диру:
# tar xvzf mfsbsd-1.0-beta1.tar.gz
# cd mfsbsd-1.0-beta1/conf/

Тюним конфиги под свои реалии:
# cp loader.conf.sample loader.conf

geom_uzip_load="YES"
mfs_load="YES"
mfs_type="mfs_root"
mfs_name="/mfsroot"
tmpfs_load="YES"
vfs.root.mountfrom="ufs:/dev/md0"
mfsbsd.rootpw="123456"

# cp rc.conf.sample rc.conf

hostname="mfsbsd"
defaultrouter="192.168.109.14"
ifconfig_em0="inet 192.168.109.35 netmask 255.255.255.0" #т.к. сетевая карта известна, то можно ее явно указать

varmfs="YES"
varsize="64m"

sshd_enable="YES"
sendmail_enable="NONE"
cron_enable="NO"

# echo «nameserver 8.8.8.8» >resolv.conf
Монтируем ISO-шник в диру /cdrom
# mdconfig -a -t vnode -f ../../FreeBSD-8.1-RELEASE-amd64-disc1.iso md0
# mount_cd9660 /dev/md0 /cdrom/
# make BASE=/cdrom/8.1-RELEASE/

Extracting base and kernel ... done
Removing unnecessary files from distribution ... done
Installing configuration scripts and files ... done
Generating SSH host keys ... done
Configuring boot environment ... done
Creating usr.uzip ... done
Copying user packages ... done
Creating and compressing mfsroot ... done

Вот и готова наша палочка-выручалочка:
# ls -la *.img

-rw-r--r--  1 root  493  45088768 Nov 11 19:30 mfsboot.img

заливаем ее на удаленную машинку:
# scp mfsboot.img user@remotehost:~/

Далее, заходим на наш удаленный тазик.

Т.к. конфигурацию партиций менять не планировалось, то получаем информацию о текущих партициях:
# bsdlabel /dev/ad0s1 > ~/label.txt

которую нужно где-то сохранить
# scp ~/label.txt user@remotehost:~/

туда же отправляем /etc/fstab
# scp /etc/fstab user@remotehost:~/

Едем дальше:

Осталось записать наш имидж в начало диска:
# dd if=mfsboot.img of=/dev/ad0 bs=1m

dd: /dev/ad0: Operation not permitted

Вот нас и посетила розовая птица обломинго… Но не все так безнадежно — нам поможет в решении этой засады:

# sysctl kern.geom.debugflags=16

kern.geom.debugflags: 0 -> 16

# dd if=mfsboot.img of=/dev/ad0 bs=1m

43+0 records in
43+0 records out
45088768 bytes transferred in 2.797733 secs (16116181 bytes/sec)

Все, мы «закатали» наш временный загрузочный образ и можем ребутаться:
# shutdown -r now

после ребута заходим на наш тазик по ssh сразу под рутом и продолжаем:
Т.к. у sysinstall есть проблемы с созданием устройств в devfs, то сделаем это за него.

В начале пометим системный диск как пустой:
mfsbsd# dd if=/dev/zero of=/dev/ad0 count=2

2+0 records in
2+0 records out
1024 bytes transferred in 0.001632 secs (627369 bytes/sec)

Создадим слайс, размером во весь диск с записью загрузочного кода в сектор 0:
mfsbsd# fdisk -BI /dev/ad0

******* Working on device /dev/ad0 *******
fdisk: invalid fdisk partition table found
fdisk: Class not found

Создаем стандартную метку для диска (включая загрузочный код):
mfsbsd# bsdlabel -wB /dev/ad0s1

Возвращаем обратно инфу о партициях:
scp user@remotehost:/home/user/label.txt .

и реанимируем их:
mfsbsd# bsdlabel -R /dev/ad0s1 label.txt

Форматируем наши партиции:
mfsbsd# newfs /dev/ad0s1a

/dev/ad0s1a: 512.0MB (1048576 sectors) block size 16384, fragment size 2048
using 4 cylinder groups of 128.02MB, 8193 blks, 16448 inodes.
super-block backups (for fsck -b #) at:
160, 262336, 524512, 786688

mfsbsd# newfs /dev/ad0s1e

/dev/ad0s1e: 512.0MB (1048576 sectors) block size 16384, fragment size 2048
using 4 cylinder groups of 128.02MB, 8193 blks, 16448 inodes.
super-block backups (for fsck -b #) at:
160, 262336, 524512, 786688

mfsbsd# newfs /dev/ad0s1d

/dev/ad0s1d: 512.0MB (1048576 sectors) block size 16384, fragment size 2048
using 4 cylinder groups of 128.02MB, 8193 blks, 16448 inodes.
super-block backups (for fsck -b #) at:
160, 262336, 524512, 786688

mfsbsd#  newfs /dev/ad0s1f

/dev/ad0s1f: 5631.0MB (11532192 sectors) block size 16384, fragment size 2048
using 31 cylinder groups of 183.77MB, 11761 blks, 23552 inodes.
super-block backups (for fsck -b #) at:
160, 376512, 752864, 1129216, 1505568, 1881920, 2258272, 2634624, 3010976, 3387328, 3763680, 4140032, 4516384, 4892736, 5269088, 5645440, 6021792, 6398144,
6774496, 7150848, 7527200, 7903552, 8279904, 8656256, 9032608, 9408960, 9785312, 10161664, 10538016, 10914368, 11290720

Подготавливаем плацдарм для будущей ОС:
mfsbsd# mount /dev/ad0s1a /mnt/
mfsbsd# mkdir /mnt/var
mfsbsd# mkdir /mnt/usr
mfsbsd# mkdir /mnt/tmp
mfsbsd# mount /dev/ad0s1d /mnt/var/
mfsbsd# mount /dev/ad0s1e /mnt/tmp/
mfsbsd# mount /dev/ad0s1f /mnt/usr/

Все, работу по подготовке к инсталляции FreeBSD через сеть мы закончили.
Настало время sysinstall — запускаем его и выбираем пункт меню Custom. В пункте Options ОБЯЗАТЕЛЬНО меняем значение Install Root на /mnt .
Далее посещаем Distributions с выбором там опции Minimal. В Media выбираем ближайший к нам ftp. Финализируем Commit’ом.

Если все хорошо, то появится заветный вопрос «Visit the general configuration menu for a chance to set any last options?», ответ на который зависит от вас.
Мы же продолжаем дальше:

mfsbsd# cp /etc/resolv.conf /mnt/etc/
mfsbsd# cp /etc/rc.conf /mnt/etc/

после чего удалите из него все лишнее.
Опционально:
mfsbsd# cp /etc/ssh/sshd_config /mnt/etc/ssh/

Возвращаем назад fstab:
# scp user@remotehost:/home/user/fstab /mnt/etc

Чрутимся в /mnt:
mfsbsd# chroot /mnt
копируем на место ядро и его модули:

mfsbsd# cp -Rp /boot/GENERIC/* /boot/kernel
Меняем пасс на рута:
mfsbsd# passwd root

Changing local password for root
New Password:
Retype New Password:

Финальный ребут:
# shutdown -r now

Скрестив пальцы, молимся великому пингу и ожидаем поднятия сервера с новой осью 🙂

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

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

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 4, среднее: 5,00 из 5)
Загрузка...
Отправить на почту Отправить на почту