Ключевые слова:ospf, route, gre, tunnel, zebra, (найти похожие документы)
From: ZIO
Date: Mon, 23 Oct 2010 17:02:14 +0000 (UTC)
Subject: OSPF поверх GRE туннелей в linux
Оригинал: http://my.opera.com/Zl0/blog/2010/05/06/ospf-gre-linux
Развивая тему GRE туннелей, очень часто используя несколько провайдеров
мы можем получить параллельные туннели, т.е два разнесенных сервера
устанавливают туннели через разных ISP, в таком случае, если оба
туннеля работают и активны мы можем получить петли в маршрутизации, да
и вообще как в linux отследить состояние каждого туннеля? Для этого я
решил использовать динамическую маршрутизацию ospf из пакета quagga.
Общая картина такая: два GW (Debian Lenny 5.0.4), за каждым из них
подсети, которые должны быть связаны и иметь роутинг друг до друга. У
каждого GW по два ISP, между GW настроен ipsec в режиме transport между
адресами 1.1.1.1 и 3.3.3.3, и 2.2.2.2 и 4.4.4.4.Поверх этого проложены
два GRE туннеля, так же между соответствующими парами адресов наших GW.
Листинг интерфейсов:
GW1
136: tunnel0@eth1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1476
qdisc noqueue state UNKNOWN link/gre 1.1.1.1 peer 3.3.3.3
inet 172.250.1.2 peer 172.250.1.1/24 scope global tunnel0
137: tunnel1@eth2: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1376
qdisc noqueue state UNKNOWN link/gre 2.2.2.2 peer 4.4.4.4
inet 172.250.2.2 peer 172.250.2.1/24 scope global tunnel1
GW2
41: tunnel0@eth1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1476
qdisc noqueue state UNKNOWN link/gre 3.3.3.3 peer 1.1.1.1.
inet 172.250.1.1 peer 172.250.1.2/24 scope global tunnel0
42: tunnel1@eth2: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1476
qdisc noqueue state UNKNOWN link/gre 4.4.4.4 peer 2.2.2.2
inet 172.250.2.1 peer 172.250.2.2/24 scope global tunnel1
tunnel0 на концах имеет адрес 172.250.1.1 и 172.250.1.2
tunnel1 на концах имеет адрес 172.250.2.1 и 172.250.2.2
Наличие флага MULTICAST на линках важное условие.
Если все верно, ipsec установлен и туннели подняты, то с адреса
172.250.1.1 мы видим 172.250.1.2, а с адреса 172.250.2.1 видим
172.250.2.2 и наоборот естественно.
# ping 172.250.1.1
PING 172.250.1.1 (172.250.1.1) 56(84) bytes of data.
64 bytes from 172.250.1.1: icmp_seq=1 ttl=64 time=23.4 ms
64 bytes from 172.250.1.1: icmp_seq=2 ttl=64 time=23.8 ms
# ping 172.250.2.1
PING 172.250.2.1 (172.250.2.1) 56(84) bytes of data.
64 bytes from 172.250.2.1: icmp_seq=1 ttl=64 time=43.0 ms
64 bytes from 172.250.2.1: icmp_seq=2 ttl=64 time=44.1 ms
После этого можно настраивать маршрутизацию между сетями.
Устанавливаем quagga и нужно поправить три файла.
1. Тут без комментариев.
/etc/quagga/daemons
zebra=yes
bgpd=no
ospfd=yes
ospf6d=no
ripd=no
ripngd=no
isisd=no
2. Тут описываем интерфейсы которые будет слушать демон
/etc/quagga/zebra.conf
! На GW2 меняем hostname
hostname gw1
password zebra
enable password zebra
!
! Interface's description.
!
interface lo
description loop
interface tunnel0
description ISP1
interface tunnel1
description ISP2
!
log file /var/log/quagga/zebra.log
3. Также на GW2, меняем hostname, router-id, и сети которые будут
участвовать в маршрутизации.
/etc/quagga/ospfd.conf
!
hostname gw1
password zebra
enable password superzebra
log file /var/log/quagga/ospfd.log
!
!
!
!
interface lo
!
interface tunnel0
ip ospf network point-to-point
ip ospf cost 20
ip ospf mtu-ignore
!
interface tunnel1
ip ospf network point-to-point
ip ospf cost 10
ip ospf mtu-ignore
!
router ospf
ospf router-id 10.1.20.1
network 172.250.1.0/24 area 0.0.0.0
network 172.250.2.0/24 area 0.0.0.0
network 10.1.20.0/24 area 0.0.0.0
area 0.0.0.0 range 10.1.20.0/24 cost 10
!
line vty
!
Здесь комментарии по некоторым параметрам:
ip ospf network point-to-point - определяет к какому типу сети
подключен интерфейс, а так же что наш сосед это точно другой конец
туннеля.
ip ospf cost- для каждого интерфейса вычисляется стоимость, для
согласования стоимости мы можем присвоить свою цену, чем ниже цена, тем
больше шансов, что через этот интерфейс пройдет маршрут при схождении.
ip ospf mtu-ignore - на линках tunnel1 c разных концов у нас разное
mtu, потому что ISP2 у нас dsl, если не игнорировать mtu в таком случае
соседи не установят отношений.
ospf router-id - идентификатор роутера, должен быть уникальным, для
большей наглядности можно использовать основной ip адрес роутера.
network 10.1.20.0/24 area 0.0.0.0 - определяем какие сети участвуют в
маршрутизации
Играя с параметром ip ospf cost мы можем добиться следующего: если цена
интерфейсов будет ровна и оба канала работают и активны, то ospf будет
пытаться балансировать нагрузку между интерфейсами, с помощью ip route
и nexthop, конечно не точно 50/50, а как закешируется маршрут, но будет
пытаться так или иначе.
10.1.20.0/24 proto zebra metric 20
nexthop via 172.250.1.1 dev tunnel0 weight 1
nexthop via 172.250.2.1 dev tunnel1 weight 1
Если цену интерфейсов сделать разной, то в штатном режиме, маршрут
будет лежать через интерфейс с большей ценой, если он ломается, и связи
до соседа по нему нет, то маршрут поднимается через более "дешевый"
интерфейс, как только связь восстанавливается, все возвращается на
место.
После запуска quagga лучше проверить состояние работы из консоли самого
демона.
#telnet localhost 2604
Hello, this is Quagga (version 0.99.10).
Copyright 1996-2005 Kunihiro Ishiguro, et al.
User Access Verification
Password: zebra
gw1> sh ip ospf interface
tunnel0 is up
ifindex 136, MTU 1476 bytes, BW 0 Kbit
<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>
Internet Address 172.250.1.2/24, Peer 172.250.1.1, Area 0.0.0.0
MTU mismatch detection:disabled
Router ID 10.1.20.1, Network Type POINTOPOINT, Cost: 20
Transmit Delay is 1 sec, State Point-To-Point, Priority 1
No designated router on this network
No backup designated router on this network
Multicast group memberships: OSPFAllRouters
Timer intervals configured, Hello 10s, Dead 40s, Wait 40s, Retransmit 5
Hello due in 9.958s
Neighbor Count is 1, Adjacent neighbor count is 1
tunnel1 is up
ifindex 137, MTU 1376 bytes, BW 0 Kbit
<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>
Internet Address 172.250.2.2/24, Peer 172.250.2.1, Area 0.0.0.0
MTU mismatch detection:disabled
Router ID 10.1.20.1, Network Type POINTOPOINT, Cost: 10
Transmit Delay is 1 sec, State Point-To-Point, Priority 1
No designated router on this network
No backup designated router on this network
Multicast group memberships: OSPFAllRouters
Timer intervals configured, Hello 10s, Dead 40s, Wait 40s, Retransmit 5
Hello due in 1.101s
Neighbor Count is 1, Adjacent neighbor count is 1
Если все завелось правильно, то мы должно увидеть наших соседей на
другом конце туннеля,10.1.30.1 это router-id нашего соседа.
gw1> sh ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface RXmtL RqstL DBsmL
10.1.30.1 1 Full/DROther 36.870s 172.250.1.1 tunnel0:172.250.1.2 0 0 0
10.1.30.1 1 Full/DROther 31.157s 172.250.2.1 tunnel1:172.250.2.2 0 0 0
А так же маршруты от соседа
gw1> sh ip ospf route
============ OSPF network routing table ============
N 172.250.1.0/24 [20] area: 0.0.0.0
directly attached to tunnel0
N 172.250.2.0/24 [10] area: 0.0.0.0
directly attached to tunnel1
N 10.1.30.0/24 [20] area: 0.0.0.0
via 172.250.2.1, tunnel1
via 172.250.1.1, tunnel0
N 10.1.20.0/24 [10] area: 0.0.0.0
directly attached to eth0
В итоге после обмена маршрутами мы будем иметь в зависимости от
настроек ospf либо load balancing, либо failover. Так как протокол OSPF
сам отслеживает состояние каналов, остается лишь настроить мониторинг
чтобы знать, какой канал или каналы активны и работают.
