В нашей организации стоит головной тунельный сервер(IPSec (1)). Удалённые подразделения через WAN (ADSL) ходят к нам. Весь трафик шифруется. В одном подразделении для увеличения пропускной способности поставили 2-а DSL модема. Это подразделение очень критично к перебоям в связи!!! Задачи:
1.) Cделать так, чтобы при падении одного канала весь трафик заруливался на работающий канал.
2.) Сбалансировать нагрузку на данные 2-а канала. Чтобы трафик шёл паралельно по двум каналам.
Что было сделано:
В удалённом подразделении установил 2-а шлюза FreeBSD 4.10+IPSec+PPPoE и на одном из них установил Quagga(Сервер 2.1). Выход в локальную сеть подразделения (172.20.29.0/24) осуществляется через 2.1 (из него идёт патчкорт на хаб). Сервер 2.2 соединён с 2.1 через кросс-кабель.
Проблемы
1.) При падении одного канала Quagga НЕ изменяет шлюз по умолчанию для удалённой сети. Т.Е. СВЯЗЬ полностью РВЁТСЯ!!!
2.) Балансировка не осуществляется! Хотя просмотром tcpdamp’ом вроде трафик идёт на обоих маршрутизаторах! НО MRTG рисует загрузку только на одном канале!!!
3.) Необходимо чтобы серверы маршрутизации увидели друг друга. Но они не видят!!! Удалённый сервер не берёт маршруты с головного сервера, где все они статически прописаны. Приходится и на нём статику прописывать. В результате вообще теряется смысл динамики!!!!
Как решить данные проблемы?
Конфигурация:Головной Удалённое подразделение
| PSec(1)|_______________________| 2.2 |
| сервер, | | 172.20.26.1 |
| Quagga | |
192.168.8.13____________________| 2.1 |
| 172.20.26.2 |
| 172.20.29.1 |_____| HUB (172.20.29.0/24)|
| Quagga |
Головной сервер (1)
zebra.confhostname Router
password zebra
enable password xxx
interface lo
!
interface xl1
interface xl2
interface xl0
interface tun0
interface rl0
interface gif0
interface gif1
interface gif2
interface gif3
interface gif4
interface gif5
interface gif6
interface gif7
interface gif8
interface gif9
multicast
line vty
!
! Static default route sample.
!
! Балансировка !
ip route 172.20.29.0/24 172.20.29.1
ip route 172.20.29.0/24 172.20.26.1
!
ip route 172.20.31.0/24 172.20.31.1
ip route 172.20.32.0/24 172.20.32.1
!
log file /var/log/zebra/zebra.logospfd.conf
hostname Router_ospf
password ospfd
enable password xxx
!
!
interface gif4
ip ospf cost 20
interface gif7
ip ospf cost 20
!
router ospf
redistribute connected
redistribute static
redistribute kernel
!
neighbor 172.20.29.1
network 0.0.0.0/0 area 0
!
ospf router-id 192.168.8.13
access-list access permit 127.0.0.1/32
access-list access deny any
!
log file /var/log/zebra/osfd.logУдалённый сервер (2.1)
zebra.conf
hostname Router
password zebra
enable password xxx
!
!
interface gif0
interface lo0
interface rl0
interface rl1
multicast
interface tun0
interface vr0
!
ip route 10.0.0.0/8 192.168.8.13
! Балансировка !
ip route 192.168.8.0/24 192.168.8.13
ip route 192.168.8.0/24 172.20.26.1
!line vty
!ospfd.conf
hostname ospfd
password zebra
enable password xxx
!
router ospf
redistribute connected
redistribute static
redistribute kernel
!
neighbor 192.168.8.13
!
network 0.0.0.0/0 area 0
ospf router-id 172.20.29.1
log file /var/log/ospfd.log
! end –fileКак побороть вышеперечисленные проблемы?
Так в чём проблемы? Почему не передаются таблицы маршрутизации?
Мужики! Помогите пожалуйста разобратся с Quagga(zebra)!!!!
Вообщем я совсем отчаился запустить OSPF на gif интрефейсах. Кто НИБУДЬ !!! Помогите!!! У кого нибудь это получалось?
>3.) Необходимо чтобы серверы маршрутизации увидели друг друга. Но они не видят!!!
>Удалённый сервер не берёт маршруты с головного сервера, где все они
>статически прописаны. Приходится и на нём статику прописывать. В результате вообще
>теряется смысл динамики!!!! Как решить данные проблемы?
Если не ошибаюсь, у меня получилось решить похожую проблему. Правда, мне требуется большего. Что использовано: Linux, IPSec (openswan/freeswan) + GRE (iproute2) + OSPF(quagga-0.98.5). Думаю, что OS и реализация IPSec не принципиальны.Как реализовано:
Каждый из офисов (центральный и удаленные) подключены к 2 провайдерам. От каждого удаленного офиса идет пара VPN-ов (через разных провайдеров) на центральный офис, но не между собой. Поверх каждого VPN брошен GRE туннел. OSPF поднят с обоих сторон (в центральном и удаленном офисе). Это конфиг (может не совсем полный, но должен быть рабочий) для центрального офиса...
По поводу GRE туннелей
[sergeil@homedesk ~]$ ip tunnel show
gre0: gre/ip remote any local any ttl inherit nopmtudisc
gre101000: gre/ip remote 172.31.101.1 local 172.31.101.5 ttl 100
gre101008: gre/ip remote 172.31.101.9 local 172.31.101.13 ttl 100
gre101016: gre/ip remote 172.31.101.17 local 172.31.101.5 ttl 100
gre101024: gre/ip remote 172.31.101.25 local 172.31.101.13 ttl 100[root@homedesk quagga]# cat zebra.conf
hostname homedesk-zebra
!
password zebra
enable password xxxxxxxx
!
debug zebra events
debug zebra kernel
!
interface lo
!
interface eth0
description lan interface 192.168.100.100/24
interface eth1
interface eth2interface ipsec0
description primary ipsec channel by eth2
interface ipsec1
description secondary ipsec channel by eth1
!
interface ipsec2
shutdown
interface ipsec3
shutdown
!
interface gre0
description default gre device
shutdown
!
interface gre101000
description multi-VPN, siteID=101, Addr=172.16.101.2/30
interface gre101008
description multi-VPN, siteID=101, Addr=172.16.101.10/30
!
interface gre101016
description multi-VPN, siteID=101, Addr=172.16.101.18/30
interface gre101024
description multi-VPN, siteID=101, Addr=172.16.101.26/30
!
!
log file /var/log/quagga/zebra.log
line vty
! -*- ospf -*-
! -------------------------------------------
! OSPFd configuration file
!--------------------------------------------
hostname homedesk-ospf
!
password xxx
enable password xxxxxxxx
!
interface lo
!
interface ipsec0
!
interface eth0
interface eth1
interface eth2
!
! Пара туннелей для первого удаленного офиса.
interface gre101000
ip ospf network point-to-multipoint
ip ospf cost 50
ip ospf authentication-key xxxxxxxxx
interface gre101008
ip ospf network point-to-multipoint
ip ospf cost 50
ip ospf authentication-key xxxxxxxxx
!
! Слудующая пара тунелей для второго удаленного офиса.
interface gre101016
ip ospf network point-to-multipoint
ip ospf cost 50
ip ospf authentication-key xxxxxxxx
interface gre101024
ip ospf network point-to-multipoint
ip ospf cost 50
ip ospf authentication-key xxxxxxxxxrouter ospf
ospf router-id 192.168.100.0
!
! Не следует посылать на эти интерфейсы broadcast, multicast
passive-interface eth0
passive-interface eth1
passive-interface eth2
passive-interface ipsec0
passive-interface ipsec1
!
! если характер сети pointopoint, neighbor можно не указывать
!
neighbor 172.16.101.1
neighbor 172.16.101.9
neighbor 172.16.101.17
neighbor 172.16.101.25
!
! Это наша точка соприкосновения с магистралью.
!
network 172.16.101.0/29 area 0
network 172.16.101.8/29 area 0
network 172.16.101.16/29 area 0
network 172.16.101.24/29 area 0! Это наша сеть, подключенная к сетевому интерфейсу eth0.
! Она полностью находится в зоне 192.168.100.0
network 192.168.100.0/24 area 192.168.100.0
! ----------------------------------------------------
! Area area is stub
!-----------------------------------------------------
area 192.168.100.0 stub!-----------------------------------------------------------------
! Logging and debug setting area
! ---------------------------------------------------------
log file /var/log/quagga/zebra-ospf.log
!
! Режим расширенного протоколирования
! используем пока не отладит все.
!debug ospf ism
!debug ospf nsm
!debug ospf lsa
!debug ospf zebra
!debug ospf event
!debug ospf packet all detail
В общем, когда подключен один удаленный офис - все ОК. Конечно, балансировка посессийная и не очень хорошая (требуется патчь ядра), но отказоустойчивость весьма недурственная...Проблема: Если подключается второй удаленный офис, то удаленные офисы начинают видеть друг друга. Это не совсем то, что мне нужно. Пытаюсь настроить фильтрацию маршрутов, но пока получается плохо...
Вот, что получается с маршрутизацией (удаленная сеть 10.101.0.0/16)
homedesk-zebra> show ip route ospf
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
I - ISIS, B - BGP, > - selected route, * - FIB routeO>* 10.101.0.0/16 [110/60] via 172.16.101.17, gre101016, 01:12:43
* via 172.16.101.25, gre101024, 01:12:43
...
O 192.168.100.0/24 [110/10] is directly connected, eth0, 01:12:59
interface gre101000
description multi-VPN, siteID=101, Addr=172.16.101.2/29
interface gre101008
description multi-VPN, siteID=101, Addr=172.16.101.10/29
!
interface gre101016
description multi-VPN, siteID=101, Addr=172.16.101.18/29
interface gre101024
description multi-VPN, siteID=101, Addr=172.16.101.26/29Извините, опечатался с маской подсети...
[sergeil@homedesk ~]$ ifconfig gre101000
gre101000 Link encap:UNSPEC HWaddr AC-1F-65-05-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:172.16.101.2 P-t-P:172.16.101.2 Mask:255.255.255.248
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1392 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:559 errors:2 dropped:0 overruns:0 carrier:2
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:49192 (48.0 KiB)[sergeil@homedesk ~]$ ifconfig gre101008
gre101008 Link encap:UNSPEC HWaddr AC-1F-65-0D-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:172.16.101.10 P-t-P:172.16.101.10 Mask:255.255.255.248
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1392 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:570 errors:2 dropped:0 overruns:0 carrier:2
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:50160 (48.9 KiB)[sergeil@homedesk ~]$ ifconfig gre101016
gre101016 Link encap:UNSPEC HWaddr AC-1F-65-05-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:172.16.101.18 P-t-P:172.16.101.18 Mask:255.255.255.248
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1392 Metric:1
RX packets:594 errors:0 dropped:0 overruns:0 frame:0
TX packets:592 errors:2 dropped:0 overruns:0 carrier:2
collisions:0 txqueuelen:0
RX bytes:40688 (39.7 KiB) TX bytes:54844 (53.5 KiB)[sergeil@homedesk ~]$ ifconfig gre101024
gre101024 Link encap:UNSPEC HWaddr AC-1F-65-0D-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:172.16.101.26 P-t-P:172.16.101.26 Mask:255.255.255.248
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1392 Metric:1
RX packets:4336 errors:0 dropped:0 overruns:0 frame:0
TX packets:4108 errors:2 dropped:0 overruns:0 carrier:2
collisions:0 txqueuelen:0
RX bytes:2633314 (2.5 MiB) TX bytes:611312 (596.9 KiB)
>! ----------------------------------------------------
>! Area area is stub
>!-----------------------------------------------------
> area 192.168.100.0 stub
>
Что значит данное выражение? Какого его действие?Кстати убрал статику - всё работает!
>>! ----------------------------------------------------
>>! Area area is stub
>>!-----------------------------------------------------
>> area 192.168.100.0 stub
>>
>Что значит данное выражение? Какого его действие?
Извините, но вынужден порекомендовать Вам почитать, например, CCNP.
Раз Вы задали такой вопрос, то для практического использования OSPF
имеющихся у Вас сведений, мягко говоря, недостаточно.
>!
>! Static default route sample.
>!
>! Балансировка !>ip route 172.20.29.0/24 172.20.29.1
>ip route 172.20.29.0/24 172.20.26.1>ip route 172.20.31.0/24 172.20.31.1
>ip route 172.20.32.0/24 172.20.32.1Я не понимаю зачем Вы делаете статическую маршрутизацию? Вес статически сконфигурированного маршрута = 1. То есть, ospfd, как я понимаю, просто не работает... OSPF должен сам найти ваши подсети...
>>!
>>! Static default route sample.
>>!
>>! Балансировка !
>
>>ip route 172.20.29.0/24 172.20.29.1
>>ip route 172.20.29.0/24 172.20.26.1
>
>>ip route 172.20.31.0/24 172.20.31.1
>>ip route 172.20.32.0/24 172.20.32.1
>
>Я не понимаю зачем Вы делаете статическую маршрутизацию? Вес статически сконфигурированного маршрута
>= 1. То есть, ospfd, как я понимаю, просто не работает...
>OSPF должен сам найти ваши подсети...
Именно - OSPF не работает, но если не указывать в статике - то вообще пакеты не ходят!
Пока не поднял BGP, OSPF соседи не видели друг друга, теперь видят. Счас статику уберу, может увидят. А как же они определят эти два разных паралельных пути? Объявлением сети или сами?Вообще FreeBSD может ли в принципе балансировку делать. Видел на этом портале где то что нет! Так ли это?
Вообщем получается следующая картина:C>* 172.20.27.1/32 is directly connected, gif5
S>* 172.20.28.0/24 [1/0] via 172.20.28.1, gif6
O 172.20.28.1/32 [110/10] is directly connected, gif6, 01:22:27
C>* 172.20.28.1/32 is directly connected, gif6
B>* 172.20.29.0/24 [20/0] via 172.20.29.1, gif7, 01:21:49
O 172.20.29.1/32 [110/50] is directly connected, gif7, 01:22:27
C>* 172.20.29.1/32 is directly connected, gif7
C>* 172.20.30.0/24 is directly connected, xl2
S>* 172.20.31.0/24 [1/0] via 172.20.31.1, gif8
O 172.20.31.1/32 [110/10] is directly connected, gif8, 01:22:27Выходит OSPF не работает, работает BGP. НО нет другого шлюза на сеть 172,20,29,0/24 только один!!!
B>* 172.20.29.0/24 [20/0] via 172.20.29.1, gif7, 01:21:49
Получается нет балансировки нагрузки!!! Только отказоустойчивость? (ещё правда не проверял)
OSPF работал (находил соседа)только в следующей конфигурации:
gif9: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1460
tunnel inet 192.168.180.1 --> 192.168.180.11
inet 192.168.8.0 --> 172.20.32.0 netmask 0xffffff00В такой
Вообщем получается следующая картина:C>* 172.20.27.1/32 is directly connected, gif5
S>* 172.20.28.0/24 [1/0] via 172.20.28.1, gif6
O 172.20.28.1/32 [110/10] is directly connected, gif6, 01:22:27
C>* 172.20.28.1/32 is directly connected, gif6
B>* 172.20.29.0/24 [20/0] via 172.20.29.1, gif7, 01:21:49
O 172.20.29.1/32 [110/50] is directly connected, gif7, 01:22:27
C>* 172.20.29.1/32 is directly connected, gif7
C>* 172.20.30.0/24 is directly connected, xl2
S>* 172.20.31.0/24 [1/0] via 172.20.31.1, gif8
O 172.20.31.1/32 [110/10] is directly connected, gif8, 01:22:27Выходит OSPF не работает, работает BGP. НО нет другого шлюза на сеть 172,20,29,0/24 только один!!!
B>* 172.20.29.0/24 [20/0] via 172.20.29.1, gif7, 01:21:49
Получается нет балансировки нагрузки!!! Только отказоустойчивость? (ещё правда не проверял)
OSPF работал (находил соседа)только в следующей конфигурации:
gif7: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1460
tunnel inet 192.168.180.1 --> 192.168.180.11
inet 192.168.8.0 --> 172.20.29.0 netmask 0xffffff00В такой не работает
gif7: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1460
tunnel inet 192.168.180.1 --> 192.168.180.9
inet 192.168.8.13 --> 172.20.29.1 netmask 0xffffffffВообщем бох с ним с OSPF, пусть хоть через BGP работает, НО 2-го маршрута то нет!!!! Или так и должно быть? Покажите пожалуйста свой вывод донной инфы на работающем маршрутизаторе с балансировкой каналов.
>Вообщем бох с ним с OSPF, пусть хоть через BGP работает, НО
>2-го маршрута то нет!!!! Или так и должно быть?Не уверен... Насколько я знаю, BGP ищет лучший путь, а не все доступные.
По этой причине я использую OSPF, а не BGP...> Покажите пожалуйста свой вывод донной инфы на работающем маршрутизаторе
> с балансировкой каналов.Я не использую BGP. Внешние маршруты сконфигурированы статически.
Из листинга выкушены сведения о внешних интерфейсах из соображений
безопасности и как не влиляющие на конечный результат...
Сейчас активен только один сдвоенный VPN.
Удаленная сеть 10.101.0.0/16, локальная 192.168.100.0/24homedesk-zebra> show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
I - ISIS, B - BGP, > - selected route, * - FIB routeO>* 10.101.0.0/16 [110/60] via 172.16.101.17, gre101016, 00:55:38
* via 172.16.101.25, gre101024, 00:55:38
C>* 127.0.0.0/8 is directly connected, lo
C>* 172.16.101.0/29 is directly connected, gre101000
C>* 172.16.101.8/29 is directly connected, gre101008
C>* 172.16.101.16/29 is directly connected, gre101016
O> 172.16.101.17/32 [110/50] via 172.16.101.17 inactive, 00:55:38
* via 172.16.101.25, gre101024, 00:55:38
C>* 172.16.101.24/29 is directly connected, gre101024
O 172.16.101.25/32 [110/50] via 172.16.101.17 inactive, 00:55:38
via 172.16.101.25 inactive, 00:55:38
O> 172.16.101.250/32 [110/50] via 172.16.101.17 inactive, 00:55:38
* via 172.16.101.25, gre101024, 00:55:38
C>* 172.31.101.4/30 is directly connected, lo
C>* 172.31.101.12/30 is directly connected, lo
O 192.168.100.0/24 [110/10] is directly connected, eth0, 00:56:03
C>* 192.168.100.0/24 is directly connected, eth0
Я так понимаю, что данная строчка и есть балансировка?O>* 10.101.0.0/16 [110/60] via 172.16.101.17, gre101016, 00:55:38
* via 172.16.101.25, gre101024, 00:55:38C OSPF у меня вряд ли получится не идёт броадкаст в IPSec тунель!!! Можно как нибудь ему явно задать соседа(кроме neighbor ххх.ххх.ххх.ххх)
>Я так понимаю, что данная строчка и есть балансировка?
>
>O>* 10.101.0.0/16 [110/60] via 172.16.101.17, gre101016, 00:55:38
> * via 172.16.101.25, gre101024, 00:55:38
>Да, это оно и есть. OSPF нашел и настроил в ядре два равноценных маршрута. В зависимости от свойств ядра будет использовать один (первый) или оба маршрута. Как только один из каналов "просядет", OSPF выбросит его из таблицы маршрутизации и оставит только доступный. Кстати, линков может быть больше, чем два. Правда, не знаю сколько именно...
>
>C OSPF у меня вряд ли получится не идёт броадкаст в PSec тунель!!!
>
IPSec не пропустит OSPF. Вам нужен туннель. Скорее всего, PPPoE подойдет для этих целей. Я использую GRE... Кстати, при конфигурации point-to-point или point-to-multipoint выбор назначенного ABR не осуществляется и broadcast использоваться не должен.>
> Можно как нибудь ему явно задать соседа(кроме neighbor ххх.ххх.ххх.ххх)
>Нет. А зачем?
>Да, это оно и есть. OSPF нашел и настроил в ядре два
>равноценных маршрута. В зависимости от свойств ядра будет использовать один (первый)
>или оба маршрута. Как только один из каналов "просядет", OSPF выбросит
>его из таблицы маршрутизации и оставит только доступный. Кстати, линков может
>быть больше, чем два. Правда, не знаю сколько именно...А можно подробнее. Какие опции в ядре должны быть включены?
>IPSec не пропустит OSPF. Вам нужен туннель. Скорее всего, PPPoE подойдет для
>этих целей. Я использую GRE... Кстати, при конфигурации point-to-point или рoint-to-multipointGRE - это наверное в Linux? У меня сделано это на фре. Для неё тоже наверное есть подобный тунель?
Уже нашёл что есть и для FREEBSD GRE тунель. Можно ли его пустить поверх (или внутри) gif тунеля?
>Уже нашёл что есть и для FREEBSD GRE тунель.
Я был-бы очень удивлен, если-бы его там не было...
:-)> Можно ли его пустить поверх (или внутри) gif тунеля?
GRE - это IP протокол и он должен проходить везде, где может пройди пакет IP
Единственное... обратите внимание на MTU интерфейса...Кстати, для информации...
http://www.cisco.com/en/US/tech/tk583/tk372/technologies_con...
>Я не использую BGP. Внешние маршруты сконфигурированы статически.
>Из листинга выкушены сведения о внешних интерфейсах из соображений
>безопасности и как не влиляющие на конечный результат...
>Сейчас активен только один сдвоенный VPN.
>Удаленная сеть 10.101.0.0/16, локальная 192.168.100.0/24Если маршруты сконфигурированы статически, то префикс будет не O, а S!То есть выгледело бы следующим образом
S>* 10.101.0.0/16 [110/60] via 172.16.101.17, gre101016, 00:55:38
S * via 172.16.101.25, gre101024, 00:55:38
У меня так выглядело до этого!!! Где у вас статика прописана (в каком файле и на каком шлюзе?)
>
>Если маршруты сконфигурированы статически, то префикс будет не O, а S!То есть
>выгледело бы следующим образом
>
>S>* 10.101.0.0/16 [110/60] via 172.16.101.17, gre101016, 00:55:38
>S * via 172.16.101.25, gre101024, 00:55:38
>У меня так выглядело до этого!!! Где у вас статика прописана (в
>каком файле и на каком шлюзе?)Статика прописана только на публичных интерфейсах eth1,eth2, через которые идет подключения к разным провайдерам и через которые строятся IPSec туннели. Хотя это, наверное, и статикой назвать сложно... Маршрутизация настроена через таблицы маршрутизации средствами iproute2. Смотри multi-home под Linux. Более никаких статических или псевдо-статических маршрутов не используется.
Те маршруты, которые Вас заинтересовали, настроены исключительно ospfd. Кстати, если Вы внимательно посмотрите файл конфигурации ospfd, то заметите, что для ospfd разрешены только туннели GRE. Все остальные интерфейсы запрещены.
homedesk-zebra> show ip route ospf
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
I - ISIS, B - BGP, > - selected route, * - FIB routeO>* 10.101.0.0/16 [110/60] via 172.16.101.17, gre101016, 00:10:12
* via 172.16.101.25, gre101024, 00:10:12
O> 172.16.101.17/32 [110/50] via 172.16.101.17 inactive, 00:10:12
* via 172.16.101.25, gre101024, 00:10:12
O 172.16.101.25/32 [110/50] via 172.16.101.17 inactive, 00:10:12
via 172.16.101.25 inactive, 00:10:12
O> 172.16.101.250/32 [110/50] via 172.16.101.17 inactive, 00:10:12
* via 172.16.101.25, gre101024, 00:10:12
O 192.168.100.0/24 [110/10] is directly connected, eth0, 00:10:17
Как строится тунель GRE на FreeBSD? Я делаю следующим образом#!/bin/sh
ifconfig gre10 destroy
ifconfig gre10 create
ifconfig gre10 tunnel 192.168.180.6 192.168.180.1
ifconfig gre10 inet 172.20.26.1 192.168.8.13 netmask 255.255.255.0Получается:
gre10: flags=9051<UP,POINTOPOINT,RUNNING,LINK0,MULTICAST> mtu 1476
inet 172.20.26.1 --> 192.168.8.13 netmask 0xffffff00
inet6 fe80::2c0:26ff:fea8:7ace%gre10 prefixlen 64 scopeid 0x9Почему то нет tunnel inet .... (как для gif)! Для GRE это нормально? Правильно я конфигурирую?
>IPSec не пропустит OSPF. Вам нужен туннель. Скорее всего, PPPoE подойдет для этих целей. Я использую GRE...
А gif пропустит? Если убрать IPSec шифрование?
>>IPSec не пропустит OSPF. Вам нужен туннель. Скорее всего, PPPoE подойдет для этих целей. Я использую GRE...
>А gif пропустит? Если убрать IPSec шифрование?Я не знаю что такое gif
>>IPSec не пропустит OSPF. Вам нужен туннель. Скорее всего, PPPoE подойдет для этих целей. Я использую GRE...
>А gif пропустит? Если убрать IPSec шифрование?Кстати, кое-что по поводу OSPF, BSD
http://pilot.org.ua/zebra/ospf.html
>>IPSec не пропустит OSPF. Вам нужен туннель. Скорее всего, PPPoE подойдет для этих целей. Я использую GRE...
>А gif пропустит? Если убрать IPSec шифрование?Кстати, нашел очень недурственный FAQ. Аж самому понравился... Единственно, что плохо, так это то, что в нем четко говорится, что я не могу фильтровать входящие аннонсы OSPF. То есть, моя задача не решается...
>Как строится тунель GRE на FreeBSD? Я делаю следующим образом
>
>Почему то нет tunnel inet .... (как для gif)! Для GRE это
>нормально? Правильно я конфигурирую?Я не знаю BSD и его возможностей.
Я строю туннели через iproute2. Поддержка в ядре через модуль ip_gre
>Как строится тунель GRE на FreeBSD? Я делаю следующим образом
>Кажется, здесь есть создание тунеля в FreeBSD и есть еще кое-что для нашего случая...
http://dragon.maxgigapop.net/twiki/pub/DRAGON/VLSR/dragon_vl...
>разным провайдерам и через которые строятся IPSec туннели. Хотя это, наверное,
>и статикой назвать сложно... Маршрутизация настроена через таблицы маршрутизации средствами iproute2.
То есть маршрутизация настроена через статику в Линуксе!? А почему не прописана через zebra.conf?
>
>>разным провайдерам и через которые строятся IPSec туннели. Хотя это, наверное,
>>и статикой назвать сложно... Маршрутизация настроена через таблицы маршрутизации средствами iproute2.
>То есть маршрутизация настроена через статику в Линуксе!? А почему не прописана
>через zebra.conf?Потому, что я скриптом тестирую оба канала (через ping) и меняю default route в зависимости от доступности (первый, второй, оба)... Не одним VPN-ом занимается рутер... Установленные соединения в публичный интернет, конечно, обламываются по тайм-ауту, но новые устанавливаются на доступный канал...
>Потому, что я скриптом тестирую оба канала (через ping) и меняю default
>route в зависимости от доступности (первый, второй, оба)... Не одним VPN-ом
>занимается рутер... Установленные соединения в публичный интернет, конечно, обламываются по тайм-ауту,
>но новые устанавливаются на доступный канал...
Что-то я не понял??? зачем тогда OSPF? Если у вас всё скриптом делается???!!! Или это только для интернет? Для VPN - OSPF?
Вообщем ЗАРАБОТАЛО!!!! Но НЕустойчиво!!! Маршруты то появляются то пропадают!!!
ВНИМАНИЕ!!! Дело было в следующем:
Всё идёт и через обычный gif интерфейс, НО его необходимо строить следующим образом:ifconfig gif7 destroy
ifconfig gif7 create
gifconfig gif7 192.168.180.1 192.168.180.9
ifconfig gif7 inet 192.168.8.13 netmask 255.255.255.0 172.20.29.1 netmask 255.255.255.255 mtu 1460Именно так и не как по другому. Дело было первой маске подсети, она должна быть именно /24
Ни в одном HOWTO(IPSec,Gif) этого не описано!!!Осталось решить 2-е проблемы:
1.) Что необходимо сделать чтобы маршруты периодически не пропадали(1 раз в 5 сек.)?
2.) Почему не видят маршрутизаторы друг друга, кот. соеденена через витую пару?
(я в удалённом подразделении, куда идут 2-а конца установил на каждом по Zebre. Они соеденены крос-кабелем и почему то не видят друг друга!!! у одного адрес 172.20.26.1, у др. 172.20.26.2)
И почему то на маршрутизаторах, кот. соеденены крос-кабелем, интерфесы не активные в OSPF? Странно, почему?
Что за ерунда!!! Маршруты то появляются то пропадают. Естественно и канал проваливается!!!
В логи идёт следующее:2006/03/27 17:34:06 OSPF: Route[External]: AS-external-LSA is self originated
2006/03/27 17:34:06 OSPF: Route[External]: Calculate AS-external-LSA to 172.20.29.0/24
2006/03/27 17:34:06 OSPF: Route[External]: Can't find originating ASBR route
2006/03/27 17:34:06 OSPF: Route[External]: Calculate AS-external-LSA to 172.20.31.0/24
2006/03/27 17:34:06 OSPF: Route[External]: AS-external-LSA is self originated
2006/03/27 17:34:06 OSPF: Route[External]: Calculate AS-external-LSA to 192.168.3.0/24
2006/03/27 17:34:06 OSPF: Route[External]: AS-external-LSA is self originated
2006/03/27 17:34:06 OSPF: Route[External]: Calculate AS-external-LSA to 192.168.18.0/24
2006/03/27 17:34:06 OSPF: Route[External]: AS-external-LSA is self originated
2006/03/27 17:34:06 OSPF: Route[External]: Calculate AS-external-LSA to 192.168.20.0/24Чувствую решение уже где то рядом...
В чём может быть дело?
Незнаю, может поможет...
у меня оспф неборы через гре не вязались пока я не сделал ttl 128 (число от фонаря, но больше 1 %) ) суть в том что оспф мультикаст пакеты имеют ттл 1 и проходя через гре тунель (2 ифейса) отшибаются с ттл ексид.
>Незнаю, может поможет...
>у меня оспф неборы через гре не вязались пока я не сделал
>ttl 128 (число от фонаря, но больше 1 %) ) суть
>в том что оспф мультикаст пакеты имеют ттл 1 и проходя
>через гре тунель (2 ифейса) отшибаются с ттл ексид.
Как можно изменить ttl в FreeBSD? Что то я такого не нашёл. Только mtu! Для gif интерфейса?
>Как можно изменить ttl в FreeBSD? Что то я такого не нашёл.
>Только mtu! Для gif интерфейса?хз, я с фрякой мало общался, полистай маны, мож шо будет.
O>* 172.20.29.0/24 [110/100] via 172.20.26.1, gif4, 00:00:00
* via 172.30.1.1, gif7, 00:00:00Теперь всё работает!!! И балансировка (судя по графикам MRTG) и отказоустойчивость!!! Готов написать статью. Чтоб другие не вставали на те же грабли (кот. было очень много!!!) при настройке конфигурации на FreeBSD. Как её можно здесь выложить?
>O>* 172.20.29.0/24 [110/100] via 172.20.26.1, gif4, 00:00:00
> *
>
> via 172.30.1.1, gif7, 00:00:00
>
>Теперь всё работает!!! И балансировка (судя по графикам MRTG) и отказоустойчивость!!! Готов
>написать статью. Чтоб другие не вставали на те же грабли (кот.
>было очень много!!!) при настройке конфигурации на FreeBSD. Как её можно
>здесь выложить?Вы, главное, напишите, а где опубликовать - это уже вопрос второй.
:-D
Осталось только одно. Выяснить на каком порту работает OSPF? Вроде открыл всё для 224.0.0.0/8 на маршрутизаторе (уже другом) Не работает OSPF. Октрыавю полностью файрволл - работает!!! Что ещё необходимо открыть?
>Осталось только одно. Выяснить на каком порту работает OSPF? Вроде открыл всё
>для 224.0.0.0/8 на маршрутизаторе (уже другом) Не работает OSPF. Октрыавю полностью
>файрволл - работает!!! Что ещё необходимо открыть?Порт можно использовать приминительно к tcp или udp. OSPF это отдельный протокол.
>Осталось только одно. Выяснить на каком порту работает OSPF? Вроде открыл всё
>для 224.0.0.0/8 на маршрутизаторе (уже другом) Не работает OSPF. Октрыавю полностью
>файрволл - работает!!! Что ещё необходимо открыть?
ipfw add 700 allow ospf from 192.168.100.2 to any
ipfw add 700 allow ospf from any to 192.168.100.2
>O>* 172.20.29.0/24 [110/100] via 172.20.26.1, gif4, 00:00:00
> *
>
> via 172.30.1.1, gif7, 00:00:00
>
>Теперь всё работает!!! И балансировка (судя по графикам MRTG) и отказоустойчивость!!! Готов
>написать статью. Чтоб другие не вставали на те же грабли (кот.
>было очень много!!!) при настройке конфигурации на FreeBSD. Как её можно
>здесь выложить?
Оооочень бы мне сейчас пригодилась эта статья... может есть какие наработки?
RomaRick, как же тебя найти :) решаю аналогичную задачу пока практически безрезультатно :(