Страница 1 из 2
iBGP проблема с коннектом
Добавлено: 20 сен 2017, 09:15
timonsterrr
Всех привествую. Решил настроить ibgp в сети. И столкнулся с пробелемой, что коннект не переходит в состояние estableshed
Дано:
R1 - это основной бордер. У него есть 2 сесии eBGP и я добавил на нем инстанс для ibg (AS 65530) IP в траснп сети: 10.120.254.1 looback 10.255.0.1
R2 - это ibg роутер. он должен установить сессию с R1 на нем дефолт инстанс с AS65530 IP в траснп сети 10.120.254.4 loopback 10.255.0.252
R3 - это ibg роутер. он должен установить сессию с R1 на нем дефолт инстанс с AS65530 IP в траснп сети 10.120.254.2 loopback 10.255.0.253
Между ними есть транспортная сеть (10.120.254.0/24 ) (Такая сеть была выбрана из-за проблемы с зеркалированием на сорм на аггрегирующем свитче)
сейчас пытаюсь установить сессию между R1 и R2 вот конфиги:
R2:
Код: Выделить всё
routing bgp instance print
Flags: * - default, X - disabled
0 * name="default" as=65530 router-id=10.255.0.252 redistribute-connected=no
redistribute-static=no redistribute-rip=no redistribute-ospf=no
redistribute-other-bgp=no out-filter="" client-to-client-reflection=yes
ignore-as-path-len=no routing-table=""
routing bgp peer print detail
Flags: X - disabled, E - established
0 name="BGP-R1" instance=default remote-address=10.120.254.1 remote-as=65530
tcp-md5-key="" nexthop-choice=default multihop=no route-reflect=no
hold-time=3m ttl=default in-filter=bgp-in-r1 out-filter=bgp-out-r1
address-families=ip update-source=loopback0 default-originate=never
remove-private-as=no as-override=no passive=no use-bfd=no
конфиг БГП R1:
Код: Выделить всё
routing bgp instance print
Flags: * - default, X - disabled
0 * name="default" as=65530 router-id=10.255.0.252 redistribute-connected=no
redistribute-static=no redistribute-rip=no redistribute-ospf=no
redistribute-other-bgp=no out-filter="" client-to-client-reflection=yes
ignore-as-path-len=no routing-table=""
routing bgp instance print
Flags: * - default, X - disabled
0 * name="default" as=65530 router-id=10.255.0.252 redistribute-connected=no
redistribute-static=no redistribute-rip=no redistribute-ospf=no
redistribute-other-bgp=no out-filter="" client-to-client-reflection=yes
ignore-as-path-len=no routing-table=""
peer:
name="Internal-peer-R2" instance=bgp-internal remote-address=10.120.254.4
remote-as=65530 tcp-md5-key="" nexthop-choice=default multihop=no
route-reflect=no hold-time=3m ttl=default in-filter=bgp-internal-in
out-filter=bgp-internal-out address-families=ip update-source=loopback0
default-originate=never remove-private-as=no as-override=no passive=no
use-bfd=no
Сессия не устанавливается. В логах с обеих сторон сообщения что connection terminated
Есть мысли что не так в моем конфиге?
Re: iBGP проблема с коннектом
Добавлено: 20 сен 2017, 10:02
Chupaka
Только connection termonated - и больше никаких сообщений?
Можно посмотреть с детальным логом:
/system logging add topics=bgp action=memory
Также проверить, что фильтр файрвола ничего не запрещает (bgp работает по протоколу tcp, порт 179)
UPD: так у вас у обоих роутеров одинаковый router-id - видимо, из-за этого и конфликт
Re: iBGP проблема с коннектом
Добавлено: 20 сен 2017, 10:51
timonsterrr
Решил вопрос отключением опции - update source на none
Но теперь другая беда с роутером. На нем в данный момент нет ни одного правила файрвол и он не отвечает на пинги и другие ип запросы (настраиваю его с ноля)
При том транспортный интерфейс подключенный к коммутатору тоже не пингуется (между коммутатором и роутером поднят оспф) с самого коммутатора роутер пигуется. А с компа подключенного к коммутатору - нет. Маршрут к лупбэк и транспортному адресу присутствует. (ccr1036 модель роутера)
Re: iBGP проблема с коннектом
Добавлено: 20 сен 2017, 11:37
timonsterrr
Все, разобрался....Что то я пока настраивал все...запарил с обратными маршрутами)
Re: iBGP проблема с коннектом
Добавлено: 20 сен 2017, 11:50
Chupaka
timonsterrr писал(а): ↑20 сен 2017, 10:51
Решил вопрос отключением опции - update source на none
Не высмотрел эту опцию %) /routing bgp export её бы лучше указал
Если update-source ставите в loopback, то и настраивать надо сессию между loopback-адресами, а не адресами транспортной сети
Re: iBGP проблема с коннектом
Добавлено: 20 сен 2017, 11:58
timonsterrr
Chupaka писал(а): ↑20 сен 2017, 11:50
timonsterrr писал(а): ↑20 сен 2017, 10:51
Решил вопрос отключением опции - update source на none
Не высмотрел эту опцию %) /routing bgp export её бы лучше указал
Если update-source ставите в loopback, то и настраивать надо сессию между loopback-адресами, а не адресами транспортной сети
Понял вас. Попробую так сделать. Спасибо
Re: iBGP проблема с коннектом
Добавлено: 21 сен 2017, 06:01
timonsterrr
Что то не могу я победить эту схему... В общем сессия установилась, все нормально. А вот инет как то странно работает. Пинги все есть, а сайты открываются через раз...либо открываются кусками, либо очень медленно либо вообще не открываются
Re: iBGP проблема с коннектом
Добавлено: 21 сен 2017, 06:07
timonsterrr
Пытаюсь сделать как описано здесь
https://mum.mikrotik.com//presentations/US13/kevin.pdf (но, это просто презентация и всего конфига там нет.)
Re: iBGP проблема с коннектом
Добавлено: 21 сен 2017, 08:49
Chupaka
Пинги большими пакетами (1500 байт?) нормально ходят? Вообще не открываются - с какой ошибкой?
Re: iBGP проблема с коннектом
Добавлено: 21 сен 2017, 10:57
timonsterrr
Chupaka писал(а): ↑21 сен 2017, 08:49
Пинги большими пакетами (1500 байт?) нормально ходят? Вообще не открываются - с какой ошибкой?
Сейчас пока что воспроизвести не могу, помню точного номера ошибки. Роутер пока отключил. Пинги с мту 1500 ходят нормально и до БГП хоста и ниже в трафик сети (с роутера R3)
Просто у меня схема сети в данный момент следующего вида:
(
https://cloud.mail.ru/public/4QD4/8kNrZ8jso)
не могу понять как избавиться от дефолт маршрута на свитче аггрегации к роутерам...ибо весь исходящий трафик идет через один роутер, а возвращается через другой
Хотя по сути, если мы между CE и PE поднимем BGP по лупбэк интерфесам то на CE дефолт маршрут можно указать на лупбэк роутера с кем бгп, а обратные маршруты PE получат по бгп. и не важен будет роут свитча
Re: iBGP проблема с коннектом
Добавлено: 21 сен 2017, 13:46
Chupaka
а у R2 и R3 (вы именно их называете CE?) какие задачи?
если свитч занимается маршрутизацией - то не всё ли ему равно, где там какие БГП в сторонке от него?
Пока что не очень понятно, чего надо добиться
Re: iBGP проблема с коннектом
Добавлено: 21 сен 2017, 14:15
timonsterrr
R2 и R3 - это PE
CE - это уровень дотсупа абонентов (роутер бижайший к ним)
Собственно еще раз попробовал переключиться на схему. И да, вы были правы - проблема с MTU
Почему то при переключении трафика в R3 максимальный MTU который проходит 1472 поэтому и такие проблемы со связь...другой вопрос....почему так резко падает мту...
Хотя стоп...1472 байта это и есть 150 мту....ничего не пойму в чем же засада
Re: iBGP проблема с коннектом
Добавлено: 21 сен 2017, 16:17
Chupaka
Так какие у них задачи? Зачем они двумя концами подключаются к одному и тому же оборудованию (R1 и L3-коммутатору)?
Re: iBGP проблема с коннектом
Добавлено: 21 сен 2017, 17:22
timonsterrr
r1 принимает линки провайдеров и поддерживает бгп сессии с провайдерскими хостами фул вью плюс на нем нат.
r2 осуществляет шейпинг торрентов и маршрутизацию ядра
r3 то же самое что р2 просто р2 близок к пределу производительности и было решено разделить нагрузку поставив параллельно р3 и перенаправить на него трафик от р1 путем ананса меньших префиксов адресов. в сторону р2 останутся укрупненние маршруты
свитч аггрегирует линки от узлов, поддерживает с ними оспф прцесс.
Re: iBGP проблема с коннектом
Добавлено: 21 сен 2017, 17:33
Chupaka
timonsterrr писал(а): ↑21 сен 2017, 17:22
путем ананса меньших префиксов адресов. в сторону р2 останутся укрупненние маршруты
о каких префиксах речь? локальных подсетей, анонсируемых в сторону r1? тогда балансироваться будет трафик из Интернета в сеть, исходящий будет идти через один роутер. если настроить на L3-коммутаторе ECMP на r2-r3 - он будет балансировать исходящий между ними (строго говоря, в примерно случайном порядке, более-менее равномерно) - подойдёт ли это для шейперов?
мы в своё время распределяли нагрузку на уровне узлов агрегации, они policy routing'ом балансировали абонентов на аналоги ваших r2 и r3, которые занимались шейпингом и натированием, а r1 работал уже чисто для ebgp
Re: iBGP проблема с коннектом
Добавлено: 21 сен 2017, 19:00
timonsterrr
речь о локальных префиксах. По сути сейчас все, что касается маршрутизации - работает, трафик балансируется как надо и тд. Беда только с проблемой что хттп трафик как то странно проходит через р3. похоже на то будто пакеты бьются. страницы могут открываться кусками и тд, если возвращаю трафик через р2 то все работает ок. Завтра буду снимать дампы, смотреть что происходит с пакетами при прохождении р3. Ибо мысли закончились уже.
В текущей схеме пока что да. исходящий весь идет через один роутер р2. мне важнее сбалансировать трафик, возвращающийся в сеть от р1. ну и попутно перестроить сеть полностью на динамические протоколы маршрутизации, привести в порядок ядро и агрегацию и заняться наконец файрволом и тд.
Re: iBGP проблема с коннектом
Добавлено: 25 сен 2017, 08:33
timonsterrr
Cнял дамп, при ситуации, когда трафик возвращается через R3 (хост к которому обращался 185.70.107.42)
Вижу, что в дампе что то идет не так...но моих познаний не хватает для определения причины. Если бы кто то мог подсказать мне бы это сильно помогло.
ссылка на дамп:
https://cloud.mail.ru/public/HwN6/ghtKDvkPh
Re: iBGP проблема с коннектом
Добавлено: 25 сен 2017, 08:59
Chupaka
Маршруты на R1 в сторону локальных подсетей нормальные? На R2 и R3 как файрвол настроен?
Re: iBGP проблема с коннектом
Добавлено: 25 сен 2017, 09:10
timonsterrr
Chupaka писал(а): ↑25 сен 2017, 08:59
Маршруты на R1 в сторону локальных подсетей нормальные? На R2 и R3 как файрвол настроен?
на R2 файрвол пока что не включен, а вот конфиг с R3:
Код: Выделить всё
ip firewall filter print
Flags: X - disabled, I - invalid, D - dynamic
0 X ;;; Add Syn Flood IP to the list
chain=input action=add-src-to-address-list tcp-flags=syn connection-limit=30,32 protocol=tcp address-list=Syn_Flooder address-list-timeout=30m
1 X ;;; Drop SYN Flood
chain=input action=drop src-address-list=Syn_Flooder
2 X chain=input action=add-src-to-address-list address-list=remider address-list-timeout=1d connection-mark=show-reminder log=no log-prefix=""
3 X chain=forward action=add-src-to-address-list dst-address-list=noris address-list=norisy address-list-timeout=1w log-prefix="norisy"
4 X ;;; Pornohub
chain=forward action=add-src-to-address-list dst-address-list=pornhub address-list=drochers address-list-timeout=5d log=no log-prefix=""
5 X chain=forward action=reject reject-with=icmp-network-unreachable dst-address-list=pornhub log=no log-prefix=""
6 X ;;; TrackersMark
chain=forward action=add-src-to-address-list dst-address-list=trackers address-list=kachki address-list-timeout=2d log=no log-prefix=""
7 X chain=input action=reject protocol=tcp in-interface=InternalLink dst-port=21
8 X chain=input action=drop protocol=tcp in-interface=InternalLink dst-port=22
9 X chain=input protocol=tcp src-address=10.125.125.0/24 dst-port=22
10 X chain=input action=accept dst-address=194.190.80.93 log=no log-prefix=""
11 X chain=input action=drop protocol=tcp src-port=16660 log=yes
12 chain=input action=drop connection-state=invalid
13 chain=forward action=drop connection-state=invalid
14 X ;;; drop DHCP not 92vlan
chain=forward action=drop protocol=udp in-interface=!bridge92 out-interface=!bridge92 dst-port=68 log=yes log-prefix=""
15 X ;;; drop DHCP not 92vlan
chain=forward action=drop protocol=udp in-interface=!bridge92 out-interface=!bridge92 dst-port=67 log=yes log-prefix=""
16 X chain=forward action=add-src-to-address-list src-address-list=!allowed address-list=not_found address-list-timeout=15m in-interface=!InternalLink out-interface=InternalLink
17 X chain=forward src-address=172.16.33.10 dst-address=80.89.138.3
18 X chain=input protocol=tcp src-address=194.190.81.235 dst-port=8291
19 ;;; ToServers
chain=forward dst-address-list=servers
20 chain=forward dst-address=10.125.125.0/24
21 X ;;; Billing
chain=input action=accept src-address=80.89.138.3 log=no log-prefix=""
22 X chain=input action=accept protocol=tcp src-address=172.16.0.0/16 dst-port=8080,8081,8082 log=no log-prefix=""
23 X chain=input action=accept protocol=tcp src-address=10.125.0.0/16 dst-port=8080,8081,8082 log=no log-prefix=""
24 X chain=input action=accept protocol=tcp src-address=194.190.80.0/22 dst-port=8081,8082 log=no log-prefix=""
25 X chain=input action=accept protocol=tcp src-address=80.89.138.0/24 dst-port=8081,8082 log=no log-prefix=""
26 X chain=input action=drop protocol=tcp dst-port=8080,8081,8082 log=no log-prefix=""
27 X chain=forward action=drop src-address=172.16.0.0/16 dst-address=10.125.125.0/24 dst-address-list=!servers log=yes log-prefix=""
28 X chain=forward action=reject src-address=172.16.33.10 dst-address-list=https_ban
29 X chain=forward action=accept src-address=10.125.125.0/24 log=no log-prefix=""
30 X ;;; TechDir
chain=forward src-address=194.190.80.94
31 X ;;; Save Billing
chain=forward action=drop dst-address=80.89.138.3
32 X chain=forward action=drop dst-address-list=mgmt in-interface=InternalLink log=no log-prefix=""
33 X ;;; 172.16.0.0/16
chain=forward action=add-src-to-address-list src-address=172.16.0.0/16 src-address-list=!clients address-list=suspected address-list-timeout=2d
34 X ;;; 194.190.80.0/22
chain=forward action=add-src-to-address-list src-address=194.190.80.0/22 src-address-list=!clients address-list=suspected address-list-timeout=2d
35 X ;;; 80.89.138.0/24
chain=forward action=add-src-to-address-list src-address=80.89.138.0/24 src-address-list=!clients address-list=suspected address-list-timeout=2d
36 X chain=forward action=passthrough src-address=10.125.125.162 log=no log-prefix=""
37 X ;;; Neoplata
chain=forward action=reject reject-with=icmp-network-unreachable src-address-list=banned log=no log-prefix=""
38 X chain=forward action=drop src-address=10.125.125.84 log=no log-prefix="
Большая часть правил выключена, за неактуальностью, есть только несколько самых базовых
Re: iBGP проблема с коннектом
Добавлено: 25 сен 2017, 09:13
timonsterrr
Отключил все правила файрвола на R2 (через него идет весь исходящий трафик) все заработало, спасибо за подсказку.
Re: iBGP проблема с коннектом
Добавлено: 25 сен 2017, 09:16
timonsterrr
В принципе все логично....в файрволе правило на форвардинг на дроп соединений с коннект сейтом инвалид. Маршрутизатор видит только исходящие пакеты а входящего трафика не видит, и информации о состоянии не имеет, что подпадает под правило дропа...и пакет дропается.
Настройка файрвола для меня следующий этап...пока что темный лес, знаю только базовые принципы. Буду разбираться...
Re: iBGP проблема с коннектом
Добавлено: 25 сен 2017, 10:42
Chupaka
Да, с несимметричной маршрутизацией надо продумывать правила фильтра, с соединениями работать толком не получится.
Re: iBGP проблема с коннектом
Добавлено: 27 сен 2017, 09:18
timonsterrr
Chupaka писал(а): ↑21 сен 2017, 17:33
timonsterrr писал(а): ↑21 сен 2017, 17:22
путем ананса меньших префиксов адресов. в сторону р2 останутся укрупненние маршруты
о каких префиксах речь? локальных подсетей, анонсируемых в сторону r1? тогда балансироваться будет трафик из Интернета в сеть, исходящий будет идти через один роутер. если настроить на L3-коммутаторе ECMP на r2-r3 - он будет балансировать исходящий между ними (строго говоря, в примерно случайном порядке, более-менее равномерно) - подойдёт ли это для шейперов?
мы в своё время распределяли нагрузку на уровне узлов агрегации, они policy routing'ом балансировали абонентов на аналоги ваших r2 и r3, которые занимались шейпингом и натированием, а r1 работал уже чисто для ebgp
Есть вопрос по ECMP
У меня L3 свитч это цискостайл железка. Команды 1в1.
на ней прописан дефолт роут 0.0.0.0 0.0.0.0 1.1.1.1
если я пропишу так:
ip route load-balance
ip route max-paths 8
ip route 0.0.0.0 0.0.0.0 1.1.1.1 (роут для исходящего на R2)
ip route 0.0.0.0 0.0.0.0 2.2.2.2 (роут для исходящего на R3)
будет ли при таком конфиге исходящий трафик балансироваться и при падении например 1.1.1.1 полностью переключаться в 2.2.2.2?
Re: iBGP проблема с коннектом
Добавлено: 27 сен 2017, 10:20
Chupaka
Как понимаю, на циске необходимо убедиться, что интерфейс, через который доступен адрес шлюза, будет падать при аварии. Т.е. там нет проверки доступности шлюза, и если роутер выключится, но интерфейс останется в состоянии UP, то коммутатор вполне может продолжить слать пакеты в порт, хотя их никто не принимает.
Я бы попробовал вместо статических маршрутов на роутерах настроить в OSPF default-originate (не забыть ip route load-balance) - коммутатор вполне должен сам подхватить ECMP-маршрут, и при пропадании роутера его некстхоп сам пропадёт из маршрутизации
Re: iBGP проблема с коннектом
Добавлено: 27 сен 2017, 10:22
timonsterrr
Chupaka писал(а): ↑27 сен 2017, 10:20
Как понимаю, на циске необходимо убедиться, что интерфейс, через который доступен адрес шлюза, будет падать при аварии. Т.е. там нет проверки доступности шлюза, и если роутер выключится, но интерфейс останется в состоянии UP, то коммутатор вполне может продолжить слать пакеты в порт, хотя их никто не принимает.
Я бы попробовал вместо статических маршрутов на роутерах настроить в OSPF default-originate (не забыть ip route load-balance) - коммутатор вполне должен сам подхватить ECMP-маршрут, и при пропадании роутера его некстхоп сам пропадёт из маршрутизации
Пожалуй так и сделаю. Тоже уже думал об этом. Спасибо
Я так понимаю за это на микротах отвечает distribute-default опция инстанса?