forum.lissyara.su

Добавлено: **2012-07-23 18:27:21**

День добрый!

Столкнулся со следующей проблемой, уже пару дней не могу победить.

Итак, что у нас есть:

Два подключения по PPPoE:

Код: Выделить всё

ng0: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> mtu 1460
        inet 85.159.0.X --> 188.0.95.255 netmask 0xffffffff
ng1: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> mtu 1460
        inet 79.143.32.X --> 81.30.160.2 netmask 0xffffffff

Одна честная оптика без PPPoE:

Код: Выделить всё

vlan9: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet 46.164.148.X netmask 0xfffffff8 broadcast 46.164.148.X
        ether 00:0e:2e:95:d0:5e
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
        vlan: 9 parent interface: rl0

Маршрут по умолчанию - одно из PPPoE подключений:

Код: Выделить всё

default            81.30.160.2        UGS      6182   993560    ng1

Необходимо построить gre-тунель между удаленным офисом и этим по новому оптическому каналу.

Создаем gre в текущем офисе:

Код: Выделить всё

gre1: flags=9051<UP,POINTOPOINT,RUNNING,LINK0,MULTICAST> mtu 1400
        tunnel inet 46.164.148.X --> 24.173.208.X
        inet 10.255.255.100 --> 10.255.255.99 netmask 0xffffff00

Создаем gre в удаленном офисе:

Код: Выделить всё

gre0: flags=9051<UP,POINTOPOINT,RUNNING,LINK0,MULTICAST> mtu 1400
        tunnel inet 24.173.208.X --> 46.164.148.X
        inet 10.255.255.99 --> 10.255.255.100 netmask 0xffffff00

И пускаем пинги. Теперь картина на tcpdump'е:

Удаленный офис:

Код: Выделить всё

[~]:tcpdump -npli gre0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on gre0, link-type NULL (BSD loopback), capture size 96 bytes
04:46:51.911323 IP 10.255.255.99 > 10.255.255.100: ICMP echo request, id 647, seq 1405, length 64
04:46:52.912318 IP 10.255.255.99 > 10.255.255.100: ICMP echo request, id 647, seq 1406, length 64
04:46:53.913329 IP 10.255.255.99 > 10.255.255.100: ICMP echo request, id 647, seq 1407, length 64

Код: Выделить всё

[~]:tcpdump -npli fxp1 proto gre
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on fxp1, link-type EN10MB (Ethernet), capture size 96 bytes
04:47:23.117482 IP 79.143.32.X > 24.173.208.X: GREv0, length 88: IP 10.255.255.100 > 10.255.255.99: ICMP echo reply, id 647, seq 1436, length 64
04:47:23.943578 IP 24.173.208.X > 46.164.148.X: GREv0, length 88: IP 10.255.255.99 > 10.255.255.100: ICMP echo request, id 647, seq 1437, length 64
04:47:24.122490 IP 79.143.32.X > 24.173.208.X: GREv0, length 88: IP 10.255.255.100 > 10.255.255.99: ICMP echo reply, id 647, seq 1437, length 64
04:47:24.944596 IP 24.173.208.X > 46.164.148.X: GREv0, length 88: IP 10.255.255.99 > 10.255.255.100: ICMP echo request, id 647, seq 1438, length 64

Как видим, наш роутер отправляет gre пакеты со своего дефолта, а не с того интерфейса, на который они пришли.

Это же подтверждается tcpdump'ом в локальном офисе:

Код: Выделить всё

[~]:tcpdump -npli ng1 proto gre
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ng1, link-type NULL (BSD loopback), capture size 96 bytes
12:49:13.131120 IP 46.164.148.X > 24.173.208.X: GREv0, length 88: IP 10.255.255.100 > 10.255.255.99: ICMP echo reply, id 647, seq 1546, length 64
12:49:14.133034 IP 46.164.148.X > 24.173.208.X: GREv0, length 88: IP 10.255.255.100 > 10.255.255.99: ICMP echo reply, id 647, seq 1547, length 64
12:49:15.132920 IP 46.164.148.X > 24.173.208.X: GREv0, length 88: IP 10.255.255.100 > 10.255.255.99: ICMP echo reply, id 647, seq 1548, length 64

не смотря на то, что source-address от vlan9, траффик уходит все равно с ng1.

Со входящим трафиком все нормально:

Код: Выделить всё

[~]:tcpdump -npli vlan9 proto gre
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vlan9, link-type EN10MB (Ethernet), capture size 96 bytes
12:50:48.229123 IP 24.173.208.X > 46.164.148.X: GREv0, length 88: IP 10.255.255.99 > 10.255.255.100: ICMP echo request, id 647, seq 1641, length 64
12:50:49.229072 IP 24.173.208.X > 46.164.148.X: GREv0, length 88: IP 10.255.255.99 > 10.255.255.100: ICMP echo request, id 647, seq 1642, length 64
12:50:50.229140 IP 24.173.208.X > 46.164.148.X: GREv0, length 88: IP 10.255.255.99 > 10.255.255.100: ICMP echo request, id 647, seq 1643, length 64
12:50:51.233972 IP 24.173.208.X > 46.164.148.X: GREv0, length 88: IP 10.255.255.99 > 10.255.255.100: ICMP echo request, id 647, seq 1644, length 64

Естественно прописан маршрут на удаленный офис:

Код: Выделить всё

[~]:netstat -rn | grep 24.173
24.173.208.X/32   46.164.148.Y     UGS         0        0  vlan9

46.164.148.Y - шлюз.

Если пустить ping, traceroute или mtr - пакеты уходят с vlan9, а вот gre уходит с ng1 вместо vlan9.

Помогите, пожалуйста, в какую сторону хоть смотреть и как изменить это поведение.

P.S. Также тему создал на BSDPortal'е.

Добавлено: **2012-07-24 9:59:33**

учите основы сетей
где в роутах прописана сеть 10. которую вы в гре запихали?

Добавлено: **2012-07-25 12:15:42**

Для if_gif есть LINK0 - "прилипание маршрута", когда маршрут до dst рассчитывается и запоминается (больше в табл. маршрутизации не заглядывает). В gre - нет такого (LINK0 в if_gre - это признак 47 протокол, т.е. gre), но м.б. оно и по-умолчанию так (?).
up/down gre интерфейса надо бы попробовать

Добавлено: **2012-07-25 14:50:02**

а причем тут какие то прилипания?
если таблица маршрутизации не знает какие пакеты в тунель отправлять, то оно и работать не будет

Добавлено: **2012-07-25 15:46:28**

дык он пингает концы тунелей, т.е. directly connected.

При этом пинг ходит, и внутри(!) туннеля. Вопрос в том, что туннель строится не через тот канал.

Добавлено: **2012-07-25 15:48:58**

ну и что что пингает? тунель для пинга построен или для того что бы в него какую то сеть завернули?
man ping
man netstat

Добавлено: **2012-07-25 15:51:12**

Если пустить ping, traceroute или mtr - пакеты уходят с vlan9, а вот gre уходит с ng1 вместо vlan9.

gre уходит по дефолтовому машруту, как ему и предписано
учтите вообщем man и сети

Добавлено: **2012-07-25 15:58:29**

Повнимательнее посмотрите сообщ. ТС на вывод tcpdump. И вообще, посмотрите суть вопроса.

Добавлено: **2012-07-25 16:00:04**

что мне нужно увидеть в ваших tcpdump?

Добавлено: **2012-07-25 16:09:50**

ок, понял
uname -a

Добавлено: **2012-07-25 16:16:34**

показывайте таблицу маршрутизации и для 10 сети

Добавлено: **2012-07-26 23:20:48**

не знаю в чем была проблема, однако поборол следующим образом:
- перебиваем дефолт на 46.164.148.Y
- создаем тунель
- пингаем другой конец
- возвращаем дефолт на место (81.30.160.2)

Тунель остается жить.

Если кто знает как изменить такое поведение - прошу помощи.

P.S. По поводу маршрутизации 10 сетки - с какой, б...ь, радости директли коннектед сетям нужна еще дополнительная маршрутизация?? Пакеты в тунель отправляются, вот то что тунель неправильно строится - так тут уже в другом проблема.

Добавлено: **2012-07-27 0:06:29**

uname -a сначала обновите, а не сидите на древнем Г мамонта,
9.0 уже давно в релизе,
вы еще выставте проблемы почему бы это у вас на 3.3 версии бсд не работает, капец люди офигели

Добавлено: **2018-03-30 15:33:26**

наткнулся на такое же поведение в 9.3-STABLE

Добавлено: **2018-03-30 19:50:54**

угу. тока год-то не 2012 уже, а 2018

обновляйтесь...

Добавлено: **2018-03-31 13:14:46**

не всегда нужно торопиться..
иногда бывают причины не спешить

forum.lissyara.su

Gre и правильный интерфейс

Gre и правильный интерфейс

Re: Gre и правильный интерфейс

Re: Gre и правильный интерфейс

Re: Gre и правильный интерфейс

Re: Gre и правильный интерфейс

Re: Gre и правильный интерфейс

Re: Gre и правильный интерфейс

Re: Gre и правильный интерфейс

Re: Gre и правильный интерфейс

Re: Gre и правильный интерфейс

Re: Gre и правильный интерфейс

Re: Gre и правильный интерфейс

Re: Gre и правильный интерфейс

Gre и правильный интерфейс

Gre и правильный интерфейс

Gre и правильный интерфейс