alibek Опубликовано 2 марта, 2019 · Жалоба Уже несколько месяцев я время от времени наблюдаю странный случай, который не могу понять или объяснить. Есть абонент (я), подключаюсь в интернет используя 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. Вообщем ничего криминального тут нет, но понять этого я тоже не могу. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Chrst Опубликовано 2 марта, 2019 · Жалоба Одна из версий. Практика большинства не больших операторов наращивать "свою" емкость установкой дополнительных BRAS. Как правило такая схема работает в режиме балансировки нагрузки и подключаясь в одно время можно быть затерминированных на одном брас, в другое время совершенно на другом. Конфигурации брасов как правило идентичны, за малыми отличиями. Возможен вариант, что на одном из брасов промахнулись с конфигурацией и или разрешили доступ на локальные IP, либо наоборот не запретили как на остальных. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 2 марта, 2019 · Жалоба Нет, настройки я проверял именно на том BRAS на котором терминирован. Сейчас как раз такой момент, когда у меня есть связь с 10.1.128.13, так что сейчас я могу проверить все подозрительные места. На моем BRAS в теории доступа к приватной серверной подсети быть не должно, он в абонентском контексте вообще не знает такого маршрута. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vurd Опубликовано 2 марта, 2019 · Жалоба Нужна прямая и обратная трассировки. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
myst Опубликовано 2 марта, 2019 · Жалоба Ассиметричный роутинг? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 2 марта, 2019 · Жалоба 20 минут назад, myst сказал: Ассиметричный роутинг? Ну или так, или магия. Наверняка что-то с маршрутами. Но пока не могу представить, где именно. 2 часа назад, vurd сказал: Нужна прямая и обратная трассировки. На прямой третий хоп не опознается. А на обратной трасса не проходит. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
myst Опубликовано 2 марта, 2019 · Жалоба А ещё бывает traffic engineering очень кривой, тут уже только лично смотря на конфигурацию л3 устройств. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pppoetest Опубликовано 2 марта, 2019 · Жалоба 7 часов назад, alibek сказал: На прямой третий хоп не опознается. В порядке бреда, там случайно никто ттл не правил, чтобы скрыть лишние хопы. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 2 марта, 2019 · Жалоба Нет, TTL там не менялся, скорее всего где-то зацикливание маршрута. На обратной трассе первые два хопа это шлюз сегмента и служебное ядро (с кучей транспортных сегментов /30), а далее хопы не отвечают. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bike Опубликовано 2 марта, 2019 · Жалоба 7 часов назад, alibek сказал: Нет, настройки я проверял именно на том BRAS на котором терминирован. Сейчас как раз такой момент, когда у меня есть связь с 10.1.128.13, так что сейчас я могу проверить все подозрительные места. На моем BRAS в теории доступа к приватной серверной подсети быть не должно, он в абонентском контексте вообще не знает такого маршрута. Как мне кажется, в Вашем случае поиск проблемы на стороне BRAS - не правильное направление, т.к. у Вас дефолт в контексте маршрутизатора и он посылает весь трафик на бордер. У нас подобная схема где NAT GRE проводим на софт роутере, а не на CG-NAT Ericsson SE100. Ищите откуда появляется или есть обратный маршрут серой сети от бордера на BRAS. П.С. Для теста - смените дефолт на BRASe на нужные маршруты сетей до бордера. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 2 марта, 2019 · Жалоба Блин, вот же я маху дал. На 10.1.128.13 есть CoA-сервер, управляющий некоторыми параметрами услуг. И чтобы CoA работал, он должен быть доступен в абонентском контексте, поэтому на BRAS имеется маршрут на этот хост (с маской /32) через core-контекст и межконтекстный роутинг. Специально ведь делал, а на такой побочный эффект не рассчитывал. И ведь смотрел конфигурацию, и маршруты видел, но мозг автоматически помечал эти строки "служебное" и упускал из вида. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Chrst Опубликовано 2 марта, 2019 · Жалоба 25 минут назад, alibek сказал: Блин, вот же я маху дал. На 10.1.128.13 есть CoA-сервер, управляющий некоторыми параметрами услуг. И чтобы CoA работал, он должен быть доступен в абонентском контексте, поэтому на BRAS имеется маршрут на этот хост (с маской /32) через core-контекст и межконтекстный роутинг. Специально ведь делал, а на такой побочный эффект не рассчитывал. И ведь смотрел конфигурацию, и маршруты видел, но мозг автоматически помечал эти строки "служебное" и упускал из вида. 8 часов назад, Chrst сказал: Возможен вариант, что на одном из брасов промахнулись с конфигурацией и или разрешили доступ на локальные IP, либо наоборот не запретили как на остальных. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bike Опубликовано 2 марта, 2019 · Жалоба Это называется - "глаз замылился". Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vurd Опубликовано 3 марта, 2019 · Жалоба 14 часов назад, alibek сказал: На прямой третий хоп не опознается. А на обратной трасса не проходит. Ну тогда берите магический шар и вперёд. Я вам говорю, нужны обе трассы. Что значит "не проходит", пинг же есть между хостами. 1. Встаем снифером и смотрим, что хосты действительно не ложные, т.е. вы должны увидеть обмен. 2. Делаем трассы, как угодно. Что там за хосты, везде линукс? Если есть винда и есть се100 с лагами, то нужно суметь исполнить udp trace. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
