Jump to content
Калькуляторы

Роутинговая загадка

Уже несколько месяцев я время от времени наблюдаю странный случай, который не могу понять или объяснить.

 

Есть абонент (я), подключаюсь в интернет используя PPPoE, получаю публичный IP, например AA.AA.AA.95.

Терминируюсь на BRAS (Ericsson SE100), у BRAS есть аплинк (бордер), транспорт наружу тоже через публичные IP.

На бордере BGP с аплинками, естественно на публичных IP, ну и далее интернет.

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

В публичными IP вроде бы все.

 

Еще в сети есть приватные адреса, для управления, внутренних нужд и т.д.

У серверов также есть приватные IP, в подсети 10.1.128.0/24. Например есть сервера 10.1.128.11, 10.1.128.12, 10.1.128.13.

Загадка в том, что иногда у меня есть прямая связь с 10.1.128.13, то есть он пингуется напрямую.

Трассировка при этом выглядит так: мой домашний роутер - BRAS - неизвестный узел - 10.1.128.13.

Этот сервер пингуется с любого домашнего устройства (за домашним роутером).

 

Прямая связи между AA.AA.AA.95 и 10.1.128.13 есть не всегда; по умолчанию связи нет, но иногда что-то происходит и такая связь появляется. Что именно — мне неизвестно, никак не могу вычислить причину. Иногда происходит что-то еще и такая связь пропадает, но и этой причины я пока не знаю; это точно не перезагрузка домашнего роутера (она не мешает), но возможно перезагрузка сервера (но перегружать сервер ради проверки я точно не буду).

Я делал VPN-подключение в офисную сеть, из которой есть доступ в 10.1.128.0/24 — оно не причем; то есть я подключаю VPN, эта серверная подсеть пингуется, отключаю VPN, 10.1.128.13 в прежнем состоянии (то есть если он пинговался до VPN, то пингуется и после разъединения VPN, то есть дело не в том, что где-то маршрут «залип»).

С другими устройствами в 10.1.128.0/24 при этом связи по прежнему нет.

 

У BRAS есть приватный адрес и маршрут на 10.1.128.0/24, но он в отдельном контексте (контекст на SE100 можно понимать как расширенный VRF), в абонентском контексте этого маршрута нет, там только дефолтный шлюз на бордер.

У бордера тоже есть приватный адрес и маршрут на 10.1.128.0/24, но тогда бы я в трассировке увидел на один хоп больше. Да и не работал бы такой маршрут — next-hop для этой подсети является шлюз 10.1.128.250, а он не знает маршрутов в мир, в том числе на AA.AA.AA.95.

Дело также не в «залипших» ARP-записях на моем ПК — во-первых у меня ничего постороннего в ARP нет, во-вторых 10.1.128.13 пингуется с любого устройства в домашней сети.

Возможно дело в самом сервере — у него помимо приватного 10.1.128.13 есть публичный AA.AA.XX.100. Но на сервере маршрутизация выключена, в iptables на внешних интерфейсах дропаются богоны, а на приватных интерфейсах прописаны ACL.

 

Вообщем ничего криминального тут нет, но понять этого я тоже не могу.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Нет, настройки я проверял именно на том BRAS на котором терминирован.

 

Сейчас как раз такой момент, когда у меня есть связь с 10.1.128.13, так что сейчас я могу проверить все подозрительные места.

На моем BRAS в теории доступа к приватной серверной подсети быть не должно, он в абонентском контексте вообще не знает такого маршрута.

Share this post


Link to post
Share on other sites

20 минут назад, myst сказал:

Ассиметричный роутинг?

Ну или так, или магия.

Наверняка что-то с маршрутами.

Но пока не могу представить, где именно.

 

2 часа назад, vurd сказал:

Нужна прямая и обратная трассировки.

На прямой третий хоп не опознается.

А на обратной трасса не проходит.

Share this post


Link to post
Share on other sites

7 часов назад, alibek сказал:

На прямой третий хоп не опознается.

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

Share this post


Link to post
Share on other sites

Нет, TTL там не менялся, скорее всего где-то зацикливание маршрута.

На обратной трассе первые два хопа это шлюз сегмента и служебное ядро (с кучей транспортных сегментов /30), а далее хопы не отвечают.

Share this post


Link to post
Share on other sites

7 часов назад, alibek сказал:

Нет, настройки я проверял именно на том BRAS на котором терминирован.

 

Сейчас как раз такой момент, когда у меня есть связь с 10.1.128.13, так что сейчас я могу проверить все подозрительные места.

На моем BRAS в теории доступа к приватной серверной подсети быть не должно, он в абонентском контексте вообще не знает такого маршрута. 

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

У нас подобная схема где NAT GRE проводим на софт роутере, а не на CG-NAT Ericsson SE100.

Ищите откуда появляется или есть обратный маршрут серой сети от бордера на BRAS.

П.С. Для теста - смените дефолт на BRASe на нужные маршруты сетей до бордера.

Share this post


Link to post
Share on other sites

Блин, вот же я маху дал.

На 10.1.128.13 есть CoA-сервер, управляющий некоторыми параметрами услуг. И чтобы CoA работал, он должен быть доступен в абонентском контексте, поэтому на BRAS имеется маршрут на этот хост (с маской /32) через core-контекст и межконтекстный роутинг.

Специально ведь делал, а на такой побочный эффект не рассчитывал.

И ведь смотрел конфигурацию, и маршруты видел, но мозг автоматически помечал эти строки "служебное" и упускал из вида.

Share this post


Link to post
Share on other sites

25 минут назад, alibek сказал:

Блин, вот же я маху дал.

На 10.1.128.13 есть CoA-сервер, управляющий некоторыми параметрами услуг. И чтобы CoA работал, он должен быть доступен в абонентском контексте, поэтому на BRAS имеется маршрут на этот хост (с маской /32) через core-контекст и межконтекстный роутинг.

Специально ведь делал, а на такой побочный эффект не рассчитывал.

И ведь смотрел конфигурацию, и маршруты видел, но мозг автоматически помечал эти строки "служебное" и упускал из вида.

8 часов назад, Chrst сказал:

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

 

Share this post


Link to post
Share on other sites

14 часов назад, alibek сказал:

 

На прямой третий хоп не опознается.

А на обратной трасса не проходит.

Ну тогда берите магический шар и вперёд. Я вам говорю, нужны обе трассы. Что значит "не проходит", пинг же есть между хостами.

1. Встаем снифером и смотрим, что хосты действительно не ложные, т.е. вы должны увидеть обмен.

2. Делаем трассы, как угодно. Что там за хосты, везде линукс? Если есть винда и есть се100 с лагами, то нужно суметь исполнить udp trace.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.