LINUX.ORG.RU
решено Форум — Admin  

Quagga OSPF не передает «соседям» нужный мне маршрут

 ,


0

1

Привет!

Небольшой провайдер. Имею на обслуживании несколько серверов, которые обмениваются маршрутами (клиентами) по OSPF.

Поставили новый сервер. особенность — подключение клиентов через SuperVLAN (если я не ошибаюсь).

Вот данные сервера:

ОС: FreeBSD 10.0-RELEASE. Quagga (version 0.99.21). название сервера «Iota».

Интерфейс в сторону OSPF-соседей:

root@iota:/e/quagga # ifconfig taurus0
taurus0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	options=209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC>
	ether 00:15:17:28:b1:31
	inet 195.55.85.24 netmask 0xfffffff0 broadcast 195.55.85.31 
	media: Ethernet autoselect (1000baseT <full-duplex>)
	status: active

Интерфейсы которые смотрят в сторону клиентов:

em0.253: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	options=103<RXCSUM,TXCSUM,TSO4>
	ether 00:15:17:28:b1:33
	inet 10.10.0.1 netmask 0xffffffff broadcast 10.10.0.1 
	media: Ethernet autoselect (1000baseT <full-duplex>)
	status: active
	vlan: 253 parent interface: em0

em0.254: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	options=103<RXCSUM,TXCSUM,TSO4>
	ether 00:15:17:28:b1:33
	inet 10.10.0.1 netmask 0xffffffff broadcast 10.10.0.1 
	media: Ethernet autoselect (1000baseT <full-duplex>)
	status: active
	vlan: 254 parent interface: em0

em0.255: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	options=103<RXCSUM,TXCSUM,TSO4>
	ether 00:15:17:28:b1:33
	inet 10.10.0.1 netmask 0xffffffff broadcast 10.10.0.1 
	media: Ethernet autoselect (1000baseT <full-duplex>)
	status: active
	vlan: 255 parent interface: em0

em0.1121: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	options=103<RXCSUM,TXCSUM,TSO4>
	ether 00:15:17:28:b1:33
	inet 195.55.85.121 netmask 0xffffffff broadcast 193.53.83.121 
	media: Ethernet autoselect (1000baseT <full-duplex>)
	status: active
	vlan: 1121 parent interface: em0

Каждому клиенту свой VLAN. Клиент по DHCP получает или серую IP (с последующим NAT) з пула 10.10.0.0/16 или белую с пула 195.55.85.120/29.

Задача: по OSPF сообщить OSPF-соседям что 195.55.85.120/29 у меня на сервере «Iota».

Уже упростил конфиг Quagga до минимума , но сеть 195.55.85.120/29 или клиент 195.55.85.122 не анонсируются:

! Конфиг для теста
router ospf
! Мой ID и мой IP
 ospf router-id 195.55.85.24

 passive-interface em0
 passive-interface libra0
 passive-interface lo0

! Моя сетевуха в сторону OSPF-соседей
 network 195.55.85.16/28 area 0.0.0.0
 neighbor 195.55.85.17 priority 200

 area 0.0.0.0 authentication message-digest
 area 0.0.0.0 range 195.55.85.120/29

 redistribute kernel
 redistribute connected
 redistribute static

Хотя клиент есть:

root@iota:/e/quagga # ping 195.55.85.122
PING 195.55.85.122 (195.55.85.122): 56 data bytes
64 bytes from 195.55.85.122: icmp_seq=0 ttl=128 time=5.795 ms

В системе маршрут на него есть:

root@iota:/e/quagga # netstat -rnW | grep 85.122
195.55.85.122/32   00:15:17:28:b1:33  US          0     56773   1500 em0.1121

Но в OSPF маршрута на 195.55.85.122 нету. Ни на сервере не вижу в OSPF ни на соседях.

На сервере: 

iota_ospfd# show ip ospf database 

       OSPF Router with ID (195.55.85.24)

                Router Link States (Area 0.0.0.0)

Link ID         ADV Router      Age  Seq#       CkSum  Link count
195.55.85.17    195.55.85.17     671 0x80000a37 0x4e51 1
195.55.85.18    195.55.85.18     462 0x8000092c 0x0e8f 1
195.55.85.19    195.55.85.19    1373 0x80000931 0x0293 1
195.55.85.20    195.55.85.20     404 0x8000092b 0x0c8c 1
195.55.85.21    195.55.85.21     466 0x80000935 0xf595 1
195.55.85.22    195.55.85.22     463 0x80000929 0x0c88 1
195.55.85.23    195.55.85.23     675 0x80000a36 0x444a 1
195.55.85.24    195.55.85.24     599 0x80000004 0x6d4f 1
195.55.85.25    195.55.85.25    1264 0x8000092d 0xfd89 1

                Net Link States (Area 0.0.0.0)

Link ID         ADV Router      Age  Seq#       CkSum
195.55.85.23    195.55.85.23     675 0x800004a2 0xa2e7

                AS External Link States
195.55.85.121   195.55.85.24     599 0x80000003 0xade8 E2 195.55.85.121/32 [0x0]
Проверяю наличие маршрута на соседях через show ip ospf routes. IP сервера вижу:

alpha_ospfd> show ip ospf route 
============ OSPF network routing table ============
N    195.55.85.16/28       [10] area: 0.0.0.0
                           directly attached to taurus0

============ OSPF router routing table =============
R    195.55.85.18          [10] area: 0.0.0.0, ASBR
                           via 195.55.85.18, taurus0
R    195.55.85.20          [10] area: 0.0.0.0, ASBR
                           via 195.55.85.20, taurus0
R    195.55.85.21          [10] area: 0.0.0.0, ASBR
                           via 195.55.85.21, taurus0
R    195.55.85.22          [10] area: 0.0.0.0, ASBR
                           via 195.55.85.22, taurus0
R    195.55.85.24          [10] area: 0.0.0.0, ASBR
                           via 195.55.85.24, taurus0
R    195.55.85.25          [10] area: 0.0.0.0, ASBR
                           via 195.55.85.25, taurus0

============ OSPF external routing table ===========
...
N E2 195.55.85.121/32      [10/20] tag: 0
                           via 195.55.85.24, taurus0

IP клиента 195.55.85.122 не вижу нигде.

Почему не анонсируется подсеть? Может быть дело в «SuperVlan»?

Извините за много букв. Что еще нужно показать для прояснения ситуации?

Спасибо! Выручайте, (второй) третий день не ем, не сплю... ;)

С Quagga раньше не работал...



Последнее исправление: Lufa (всего исправлений: 1)
← Zabbix новая установка, какую версию выбрать?!
Правильная очистка storage Dovecot →
  1 2 →
Ответ на: комментарий от AS

Сделал на «законодателе мод» Cisco следующее: 

ip route 1.1.1.1 255.255.255.255 Gi0/0.12
debug arp
term mon
ping 1.1.1.1

Mar 19 14:03:15.432: IP ARP: sent req src 192.168.1.20 0011.2233.4455,
                 dst 1.1.1.1 0000.0000.0000 GigabitEthernet0/0.12.

Если снифером посмотреть то DST MAC будет ff...

The_Ketchup ★★
()
Ответ на: комментарий от The_Ketchup

Тут я выпал из темы.
Клиенту выдается сеть по DHCP при этом на шлюзовом интерфейсе
прописывается адрес из другой подсети и с маской /32

Да. Смотрите, вот например:

DHCPD: 

subnet 10.10.0.0 netmask 255.255.252.0 {
default-lease-time 60;
max-lease-time 3600;
option subnet-mask 255.255.252.0;
option routers 10.10.0.1;
option domain-name-servers 195.55.85.7, 8.8.8.8;
 class "vlan-41581" {match if option agent.circuit-id="em0.100";}
 pool {range 10.10.0.2; allow members of "vlan-41581";}
 class "vlan-41582" {match if option agent.circuit-id="em0.101";}
 pool {range 10.10.0.3; allow members of "vlan-41582";}
 class "vlan-41583" {match if option agent.circuit-id="em0.102";}
 pool {range 10.10.0.4; allow members of "vlan-41583";}
 class "vlan-41584" {match if option agent.circuit-id="em0.103";}
 pool {range 10.10.0.5; allow members of "vlan-41584";}
 class "vlan-41585" {match if option agent.circuit-id="em0.104";}
 pool {range 10.10.0.6; allow members of "vlan-41585";}
 class "vlan-41586" {match if option agent.circuit-id="em0.105";}
 pool {range 10.10.0.7; allow members of "vlan-41586";}

На сервере: 

/sbin/ifconfig em0.101 create inet 10.10.0.1/32 up
/sbin/ifconfig em0.102 create inet 10.10.0.1/32 up
/sbin/ifconfig em0.103 create inet 10.10.0.1/32 up
/sbin/ifconfig em0.104 create inet 10.10.0.1/32 up
/sbin/ifconfig em0.105 create inet 10.10.0.1/32 up
/sbin/ifconfig em0.106 create inet 10.10.0.1/32 up
/sbin/ifconfig em0.107 create inet 10.10.0.1/32 up
/sbin/ifconfig em0.108 create inet 10.10.0.1/32 up
/sbin/ifconfig em0.109 create inet 10.10.0.1/32 up
/sbin/ifconfig em0.110 create inet 10.10.0.1/32 up


/sbin/route add -net 10.10.0.2/32 -iface em0.100
/sbin/route add -net 10.10.0.3/32 -iface em0.101
/sbin/route add -net 10.10.0.4/32 -iface em0.102
/sbin/route add -net 10.10.0.5/32 -iface em0.103
/sbin/route add -net 10.10.0.6/32 -iface em0.104
/sbin/route add -net 10.10.0.7/32 -iface em0.105
/sbin/route add -net 10.10.0.8/32 -iface em0.106
/sbin/route add -net 10.10.0.9/32 -iface em0.107
/sbin/route add -net 10.10.0.10/32 -iface em0.108
/sbin/route add -net 10.10.0.11/32 -iface em0.109
/sbin/route add -net 10.10.0.12/32 -iface em0.110
Lufa
() автор топика
Ответ на: комментарий от Lufa

Пример с того же сервера, но другая сеть (серые IP).

Сама сеть /22, но со стороны сервера создается /32.

Lufa
() автор топика
Ответ на: комментарий от The_Ketchup

Клиенту выдается сеть по DHCP при этом на шлюзовом интерфейсе
прописывается адрес из другой подсети и с маской /32 ?

Lufa исправился и написал, что клиенту DHCP /29 выдает. Но, по началу, смотрелось именно так, что у клиента на ethernet - /32. А шлюз уж какой не прописывай, он в /32 не попадёт, так как это ну никак не сеть, а хост. Надо, хотябы, /31, и чтобы ОС клиента вышеназванный RFC поддерживала. То есть, я про сторону клиента.

AS ★★★★★
()
Последнее исправление: AS (всего исправлений: 1)
Ответ на: комментарий от Lufa

чего-то я не понял, а где тут выдача /29 внешних «белых» адресов ? Я правда DHCP очень очень давно не настрайвал тем более с правилами и классами :).

The_Ketchup ★★
()
Последнее исправление: The_Ketchup (всего исправлений: 1)
Ответ на: комментарий от AS

Я же писал как настрайвать клиента. Я в детстве в одном месте такое настрайвал и работало :) 

route add -host <GW IP> dev eth0
route add default gw <GW IP>

The_Ketchup ★★
()
Ответ на: комментарий от The_Ketchup

ip route 1.1.1.1 255.255.255.255 Gi0/0.12

С этим я уже согласился в
Quagga OSPF не передает «соседям» нужный мне маршрут (комментарий)

Если 1.1.1.1 есть там, куда смотрит Gi0/0.12, есть шанс, что всё сработает, как надо. :-)

AS ★★★★★
()
Ответ на: комментарий от AS

Извиняюсь, значит несколько не верно истолковал ваше сообщение.

Какая-то шизофреническая конфигурация если честно :).

ТС, как выдается /29 внешних адресов ?

The_Ketchup ★★
()
Ответ на: комментарий от The_Ketchup

route add -host <GW IP> dev eth0
route add default gw <GW IP>

Это ты, как раз, сымитировал вариант, который обсуждали для роутрера. Вопрос - везде ли у клиентов ОС, которая будет вести себя в соответствии с предложенной логикой. Ну и кто-то должен там делать «route add -host <GW IP> dev eth0».

AS ★★★★★
()
Ответ на: комментарий от The_Ketchup

Вот как белые выдаются.

Есть DHCP-сервер, который с биллинга получает конфиг.

Есть сервер FreeBSD к которому подключены клиенты. 1 клинтн — 1 VLAN. На сервере DHCP-релей.

DHCP: 

subnet 195.55.85.120 netmask 255.255.255.248 {
default-lease-time 60;
max-lease-time 3600;
option subnet-mask 255.255.255.248;
option routers 195.55.85.121;
option domain-name-servers 195.55.85.7, 8.8.8.8;
 class "vlan-1583274" {match if option agent.circuit-id="em0.1122";}
 pool {range 195.55.85.123; allow members of "vlan-1583274";}

}

На сервере: 

/sbin/ifconfig em0.1122 create inet 195.55.85.121/32 up
/sbin/route add -net 195.55.85.123/32 -iface em0.1122

Lufa
() автор топика
Ответ на: комментарий от The_Ketchup

TС, напиши в процессе OSPF network 0.0.0.0 255.255.255.255 area 0.0.0.0 таким образом затянешь все сети которые есть на этом роутере,может поможет, хуже не сделает. К static маршрутам это не относится.

The_Ketchup ★★
()
Ответ на: комментарий от Lufa 
/sbin/ifconfig em0.1122 create inet 195.55.85.121/32 up
/sbin/route add -net 195.55.85.123/32 -iface em0.1122

потом будет:

/sbin/ifconfig em0.1123 create inet 195.55.85.122/32 up
/sbin/route add -net 195.55.85.123/32 -iface em0.1123

/sbin/ifconfig em0.1124 create inet 195.55.85.123/32 up
/sbin/route add -net 195.55.85.124/32 -iface em0.1124

и т.д. до 195.55.58.126.

Lufa
() автор топика
Ответ на: комментарий от The_Ketchup

понял. Если ты говорил что у тебя работает всё через via <IP> может проще переписать конфиг на сервере и указать вместо -iface via 195.55.85.121, если это делается скриптом то поправить в скрипте это просто.

Клиенту в этой конфигурации выдается всего один адрес а не /29.

The_Ketchup ★★
()
Ответ на: комментарий от The_Ketchup

ладно, до завтра. Если что - завтра продолжим. Пойду домой.

The_Ketchup ★★
()
Ответ на: комментарий от The_Ketchup

TС, напиши в процессе OSPF network 0.0.0.0 255.255.255.255 area 0.0.0.0

К сожалению не помогло. IP клиентов не видно.

sh ip route
C * 195.55.85.121/32 is directly connected, em0.1121
C>* 195.55.85.121/32 is directly connected, em0.1122
Lufa
() автор топика
Ответ на: комментарий от The_Ketchup

может проще переписать конфиг на сервере и указать вместо -iface via
195.55.85.121, если это делается скриптом то поправить в скрипте это просто.

Я думал. Но если указать IP 195.55.85.121 а не название vlan то в таблице маршрутизации прописывается неправильный интерфейс. Ведь 195.55.85.121 у меня может быть несколько:

em0.1122: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=103<RXCSUM,TXCSUM,TSO4>
    ether 00:15:17:28:b1:33
    inet 195.55.85.121 netmask 0xffffffff broadcast 195.55.85.121 
    media: Ethernet autoselect (1000baseT <full-duplex>)
    status: active
    vlan: 1122 parent interface: em0
em0.1121: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=103<RXCSUM,TXCSUM,TSO4>
    ether 00:15:17:28:b1:33
    inet 195.55.85.121 netmask 0xffffffff broadcast 195.55.85.121 
    media: Ethernet autoselect (1000baseT <full-duplex>)
    status: active
    vlan: 1121 parent interface: em0
Lufa
() автор топика
Ответ на: комментарий от Lufa

Чесно говоря сейчас я более озабочен вопросом архитектуры.

Имеет ли такая схема право на существование?

Клиенту выдаем /29 а на серверной стороне регистрируем интерфейс с /32 и IP одна и та же у нескольких интерфесов.

У кого серые IP, тому выдает /22, но на серверной стороне интерфейсы с /32.

Мне кажется такая схема называется Supervlan, или unnumbered в термиенологии Cisco.

Lufa
() автор топика
Ответ на: комментарий от Lufa

Нашел описание системы очень схожую с «моей»:

Схема работает по принципу VLAN на абонента + IP Unnumbered (SuperVLAN).
Абонент получает IP-адрес с помощью DHCP Option 82.
Идентификатором абонента является либо ID-свитча+VLAN ID, либо ID-свитча+VLAN ID+MAC.

Для обмена маршрутами между шлюзами и другими маршрутизаторами ядра используется пакет Quagga,
в котором мы используем zebra и bgpd/ospfd.
Нужно отметить, что для корректной работы конструкции Unnumbered IP (SuperVLAN) нужно в таблицу маршрутизации >прописывать руками маршруты вида:
Код:
route add -host cc.19.64.111 -iface em1.1234

где cc.19.64.111 ip абонента, а em1.1234 интерфейс (1234 - номер VLAN-а).
Т.к. у нас используется zebra, маршруты будем прописывать в ней, а zebra уже сама их внесет в системную таблицу >маршрутизации

http://forum.bitel.ru/viewtopic.php?f=1&t=5289

Т.е. надо не просить Quagga брать маршруты с системы, а создавать их прямо в Quagga (Zebra) и распостранять в локальную таблицу.

Вот только надо скрипты запилить для создание/удаления маршрутов по мере подключения/отключения клиентов.

Lufa
() автор топика
Ответ на: комментарий от Lufa

http://forum.bitel.ru/viewtopic.php?f=1&t=5289

В этой схеме я не понял, что, всё же, получает клиент в плане маски. Если /32, то кто ему прописывает маршрут для шлюза, упомянутый в Quagga OSPF не передает «соседям» нужный мне маршрут (комментарий)

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

Т.е. надо не просить Quagga брать маршруты с системы, а создавать их прямо в Quagga (Zebra)

А ссылку на патч 494 видел там же ?

Правда, в конце написано: 0.99.21 seems to be working out of the box without patch.

AS ★★★★★
()
Последнее исправление: AS (всего исправлений: 1)
Ответ на: комментарий от AS

Если /32, то кто ему прописывает маршрут для шлюза, упомянутый в Quagga OSPF не передает «соседям» нужный мне маршрут (комментарий)

DHCP option 121 с Router=0.0.0.0 позволяет такое делать. Там правда по RFC клиент должен игнорировать DHCP option 3 (Router), если получает 3 и 121 вместе, но на это забивают клиенты. Оффтопик сроду забивал, Mikrotik тоже забил в конце-концов, other linux - не знаю.

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

Proxy ARP на шлюзе настроить

rubic ★
()
Ответ на: комментарий от rubic

Proxy ARP на шлюзе настроить

Это всё как-то костыльно. Хочется иметь как можно меньше штук, которые могут начать работать непонятно при больших объёмах, как трафика, так и интерфейсов.

AS ★★★★★
()
Ответ на: комментарий от AS

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

Только что добавил 2-х клиентов (тестовый сервер).

Клиент 1 получает: 195.55.85.122/29 . Клиент 2 получает: 195.55.85.123/29 .

На сервере создаются VLAN: 

em0.1122: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=103<RXCSUM,TXCSUM,TSO4>
    ether 00:15:17:28:b1:33
    inet 195.55.85.121 netmask 0xffffffff broadcast 195.55.85.121 
    media: Ethernet autoselect (1000baseT <full-duplex>)
    status: active
    vlan: 1123 parent interface: em0

em0.1123: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=103<RXCSUM,TXCSUM,TSO4>
    ether 00:15:17:28:b1:33
    inet 195.55.85.121 netmask 0xffffffff broadcast 195.55.85.121 
    media: Ethernet autoselect (1000baseT <full-duplex>)
    status: active
    vlan: 1124 parent interface: em0

И маршруты: 

root@iota:/e/quagga # netstat -rnW | grep 85.122

195.55.85.122/32   00:15:17:28:b1:33  US          0     56773   1500 em0.1122

195.55.85.123/32   00:15:17:28:b1:33  US          0     56773   1500 em0.1123

На шлюзе (бордере) пока прописал статический маршрут для сети 120/29 на сервер с клиентами.

Клиенты ходят в интернет. Клиенты пингуют друг друга.

Lufa
() автор топика
Ответ на: комментарий от Lufa

Клиенты ходят в интернет

Это понятно, почему. Тут обсудили уже.

Клиенты пингуют друг друга.

А вот это - не очень. VLAN-ы ни через какой бридж не связаны ? Они точно VLAN-ы ? Proxy ARP тут уже упомянули, его нет, или есть ?

AS ★★★★★
()
Последнее исправление: AS (всего исправлений: 1)
Ответ на: комментарий от AS

VLAN-ы ни через какой бридж не связаны ?
Они точно VLAN-ы ?

Создаются вот так: 

/sbin/ifconfig em0.1122 create inet 193.53.83.122/32 up

Proxy ARP тут уже упомянули, его нет, или есть ?

Как проверить? 

root@iota:/etc # sysctl net.link.ether.inet.proxyall
net.link.ether.inet.proxyall: 1

Lufa
() автор топика
Ответ на: комментарий от Lufa

Создаются вот так:

Тут, всё же, linux.org, а не bsd. Про теорию IP и OSPF - это я могу, а вот про BSD-шную конкретику - нет.

tcpdump-ом, что ли, посмотри, как трафик между клиентами бегает. Можно на коммутаторе порт отзеркалировать, и там посмотреть, если на сервере с bsd не весь трафик будет видно.

AS ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
  1 2 →
← Zabbix новая установка, какую версию выбрать?!
Admin
Правильная очистка storage Dovecot →