MikroTik.by

а у R2 и R3 (вы именно их называете CE?) какие задачи?

если свитч занимается маршрутизацией - то не всё ли ему равно, где там какие БГП в сторонке от него?

Пока что не очень понятно, чего надо добиться

R2 и R3 - это PE

CE - это уровень дотсупа абонентов (роутер бижайший к ним)

Собственно еще раз попробовал переключиться на схему. И да, вы были правы - проблема с MTU
Почему то при переключении трафика в R3 максимальный MTU который проходит 1472 поэтому и такие проблемы со связь...другой вопрос....почему так резко падает мту...

Хотя стоп...1472 байта это и есть 150 мту....ничего не пойму в чем же засада

Так какие у них задачи? Зачем они двумя концами подключаются к одному и тому же оборудованию (R1 и L3-коммутатору)?

r1 принимает линки провайдеров и поддерживает бгп сессии с провайдерскими хостами фул вью плюс на нем нат.
r2 осуществляет шейпинг торрентов и маршрутизацию ядра
r3 то же самое что р2 просто р2 близок к пределу производительности и было решено разделить нагрузку поставив параллельно р3 и перенаправить на него трафик от р1 путем ананса меньших префиксов адресов. в сторону р2 останутся укрупненние маршруты

свитч аггрегирует линки от узлов, поддерживает с ними оспф прцесс.

timonsterrr писал(а): ↑21 сен 2017, 17:22 путем ананса меньших префиксов адресов. в сторону р2 останутся укрупненние маршруты

о каких префиксах речь? локальных подсетей, анонсируемых в сторону r1? тогда балансироваться будет трафик из Интернета в сеть, исходящий будет идти через один роутер. если настроить на L3-коммутаторе ECMP на r2-r3 - он будет балансировать исходящий между ними (строго говоря, в примерно случайном порядке, более-менее равномерно) - подойдёт ли это для шейперов?

мы в своё время распределяли нагрузку на уровне узлов агрегации, они policy routing'ом балансировали абонентов на аналоги ваших r2 и r3, которые занимались шейпингом и натированием, а r1 работал уже чисто для ebgp

речь о локальных префиксах. По сути сейчас все, что касается маршрутизации - работает, трафик балансируется как надо и тд. Беда только с проблемой что хттп трафик как то странно проходит через р3. похоже на то будто пакеты бьются. страницы могут открываться кусками и тд, если возвращаю трафик через р2 то все работает ок. Завтра буду снимать дампы, смотреть что происходит с пакетами при прохождении р3. Ибо мысли закончились уже.

В текущей схеме пока что да. исходящий весь идет через один роутер р2. мне важнее сбалансировать трафик, возвращающийся в сеть от р1. ну и попутно перестроить сеть полностью на динамические протоколы маршрутизации, привести в порядок ядро и агрегацию и заняться наконец файрволом и тд.

Cнял дамп, при ситуации, когда трафик возвращается через R3 (хост к которому обращался 185.70.107.42)

Вижу, что в дампе что то идет не так...но моих познаний не хватает для определения причины. Если бы кто то мог подсказать мне бы это сильно помогло.
ссылка на дамп: https://cloud.mail.ru/public/HwN6/ghtKDvkPh

Маршруты на R1 в сторону локальных подсетей нормальные? На R2 и R3 как файрвол настроен?

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="

Большая часть правил выключена, за неактуальностью, есть только несколько самых базовых

Отключил все правила файрвола на R2 (через него идет весь исходящий трафик) все заработало, спасибо за подсказку.

В принципе все логично....в файрволе правило на форвардинг на дроп соединений с коннект сейтом инвалид. Маршрутизатор видит только исходящие пакеты а входящего трафика не видит, и информации о состоянии не имеет, что подпадает под правило дропа...и пакет дропается.

Настройка файрвола для меня следующий этап...пока что темный лес, знаю только базовые принципы. Буду разбираться...

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

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?

Как понимаю, на циске необходимо убедиться, что интерфейс, через который доступен адрес шлюза, будет падать при аварии. Т.е. там нет проверки доступности шлюза, и если роутер выключится, но интерфейс останется в состоянии UP, то коммутатор вполне может продолжить слать пакеты в порт, хотя их никто не принимает.

Я бы попробовал вместо статических маршрутов на роутерах настроить в OSPF default-originate (не забыть ip route load-balance) - коммутатор вполне должен сам подхватить ECMP-маршрут, и при пропадании роутера его некстхоп сам пропадёт из маршрутизации

Chupaka писал(а): ↑27 сен 2017, 10:20 Как понимаю, на циске необходимо убедиться, что интерфейс, через который доступен адрес шлюза, будет падать при аварии. Т.е. там нет проверки доступности шлюза, и если роутер выключится, но интерфейс останется в состоянии UP, то коммутатор вполне может продолжить слать пакеты в порт, хотя их никто не принимает.

Я бы попробовал вместо статических маршрутов на роутерах настроить в OSPF default-originate (не забыть ip route load-balance) - коммутатор вполне должен сам подхватить ECMP-маршрут, и при пропадании роутера его некстхоп сам пропадёт из маршрутизации

Пожалуй так и сделаю. Тоже уже думал об этом. Спасибо
Я так понимаю за это на микротах отвечает distribute-default опция инстанса?

Настроил на микротах default distribute, свитч получил маршрут 0.0.0.0 но в одном экземпляре. Если на одном из микротов отключить дистрибуцию дефолт роута то он получает от другого. Тобишь резервирование работает, а вот балансировка нет т.к. маршрут не вида
0.0.0.0/0 1.1.1.1
2.2.2.2
а обычный либо на R2 либо на R3
и отличается метрика полученных маршрутов от R2 [150,6] от R3 [150,2] Поэтому и не работает балансировка т.к. маршруты не равновесны...надо понять теперь почему метрика отличается

оба подключены к свитчу напрямую...10gb линками. Отличаются только маски транспортных сетей для R3 на /30 для R2 на /29

Вроде понял почему так....для R3 network type - point-topoint, а для R2 - broadcast

Для того, чтобы понять, почему метрики разные, неплохо бы конфигурацию увидеть

/route ospf instance print для начала

Chupaka писал(а): ↑27 сен 2017, 11:43 Для того, чтобы понять, почему метрики разные, неплохо бы конфигурацию увидеть

/route ospf instance print для начала

Вроде понял почему так....для R3 network type - point-topoint, а для R2 - broadcast Это оказывает влияние?

А если default сделать с типом 2? Ну и мы всё же до сих пор не увидели Default Route Metric

Chupaka писал(а): ↑27 сен 2017, 11:50 А если default сделать с типом 2? Ну и мы всё же до сих пор не увидели Default Route Metric

R2

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

routing ospf instance print 
Flags: X - disabled, * - default 
 0  * name="default" router-id=10.255.0.254 distribute-default=always-as-type-1 
      redistribute-connected=as-type-1 redistribute-static=no 
      redistribute-rip=no redistribute-bgp=no redistribute-other-ospf=no 
      metric-default=5 metric-connected=20 metric-static=20 metric-rip=20 
      metric-bgp=auto metric-other-ospf=auto in-filter=ospf-in 
      out-filter=ospf-out

R3

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

routing ospf instance print 
Flags: X - disabled, * - default 
 0  * name="default" router-id=10.255.0.252 distribute-default=never 
      redistribute-connected=as-type-1 redistribute-static=no 
      redistribute-rip=no redistribute-bgp=no redistribute-other-ospf=no 
      metric-default=1 metric-connected=20 metric-static=20 metric-rip=20 
      metric-bgp=auto metric-other-ospf=auto in-filter=ospf-in 
      out-filter=ospf-out

Пока что отключил на R3 дистрибуцию дефолтового роута (есть еще необходимость перенастроить мангл на нем)

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

timonsterrr писал(а): ↑27 сен 2017, 12:07 все получилось.

ура =)

MikroTik.by

iBGP проблема с коннектом

Re: iBGP проблема с коннектом

Re: iBGP проблема с коннектом

Re: iBGP проблема с коннектом

Re: iBGP проблема с коннектом

Re: iBGP проблема с коннектом

Re: iBGP проблема с коннектом

Re: iBGP проблема с коннектом

Re: iBGP проблема с коннектом

Re: iBGP проблема с коннектом

Re: iBGP проблема с коннектом

Re: iBGP проблема с коннектом

Re: iBGP проблема с коннектом

Re: iBGP проблема с коннектом

Re: iBGP проблема с коннектом

Re: iBGP проблема с коннектом

Re: iBGP проблема с коннектом

Re: iBGP проблема с коннектом

Re: iBGP проблема с коннектом

Re: iBGP проблема с коннектом

Re: iBGP проблема с коннектом

Re: iBGP проблема с коннектом

Re: iBGP проблема с коннектом