Проблема исходящего трафика
Добрый день уважемый ЛОР, Со вчерашнего вечера появилась проблема. Сеть в доме простенькая, все через роутер Netgear JWNR2000V2. Заключается в том, что при проверки скорости через speedtest/загрузки файлов на обменник, скорость исходящая равна 0мб, а спидтест дак подавно не грузится после проверки входящей скорости. Роутер уже хардресетал, ПО на нем обновлял, проверял с планшета на андроиде, симптомы те же. К провайдеру обращался — он мне начал рассказывать про вирусы, файрволлы и тд. Ничем не помог тащемта. Решил обратиться с просьбой о помощи к Вам, уважаемый ЛОР. Ваши мысли, предложения, решения данной проблемы?
Проверьте как работает без роутера, т.е. подключие кабель к ПК няпрямую, если нужно поменяйте мак адрес.
Возможность только попозже появится. Роутер в коридоре, ноутбука нету. Завтра съезжу и возьму. А насчет мак адреса это у роутера? В чем смысл смены подскажите, если не трудно.
Роутер в коридоре, ноутбука нету. Завтра съезжу и возьму.
Можете временно перенести ПК к роутеру.
А насчет мак адреса это у роутера? В чем смысл смены подскажите, если не трудно.
В зависимости от способа настройки подключения ваш провайде как минимум на основе MAC адреса выдаёт параметры сети, IP адрес, шлюз, DNS сервер, так же, скорее всего, на шлюзе у него прописаны правила фильтрации MAC адресов интерфейсов, которым разрешён доступ к Internet, а которым — нет. Если при настройке подключения к провайдеру, подписании договора, уже был или был установлен монтажниками, то возможны две ситуации:
— на внешнем интерфейса роутера стоит копия мак адреса интерфейса вашего ПК и он зафиксирован у провайдера;
— на внешнем интерфейса роутера стоит какой-то другой мак адрес и он зафиксирован у провайдера.
В первом случае вы сможете подключить WAN провод роутера в ваш ПК, ваш ПК получит те же параметры сети и так как у него такой же MAC адрес ему будет разрешён доступ в Internet.
Во-втором случае из-за того, что у него MAC адрес отличается от MAC адреса внешнего интерфейса роутера либо вообще не получит параметры сети, либо получит, но доступ к Internet, скорее всего, всё равно будет не возможен, ввиду фильтрации MAC адресов на шлюзе провайдера.
Во втором случае вам придётся средствами операционной системы сменить MAC адрес интерфейса вашего ПК, что бы со стороны провайдера всё выглядело как и в случае с роутером.
Источник
BGP: некоторые особенности поведения трафика
В этой небольшой заметки хочу коснуться некоторых интересных моментов и особенностей управления трафиком (или попыток управления трафиком) в случае использования протокола BGP. Статья не даст ответ на вопрос о том, как сделать счастье в сети!
Изложенная информация носит познавательный характер и будет похожа на легкое чтиво для специалистов в области телекоммуникаций. Сведения будут изложены в достаточно свободной форме, без излишнего насыщения спецификой. Попробуем ответить на вопрос: «почему трафика нет там, где он должен быть, и есть там, где быть его не должно».
Мы не будем рассматривать назначение протокола BGP со всеми вытекающими последствиями, а сразу возьмем быка за рога.
Исходные данные
Начнем с того, что мы имеем собственную автономную систему, делегированный блок(-и) адресов и одного провайдера. В данном случае связь нашей AS с сетью Интернет осуществляется используя один единственный канал с провайдером. Трафик в нашу сеть (к нашим префиксам) пройдет через этот логический канал, второго мнения тут быть не может. Аналогично с входящим трафиком, весь исходящий трафик пойдет через единственный существующий канал.
Все работает хорошо, но рано или поздно приходит момент, когда возникает необходимость подключения к дополнительному провайдеру. Причин этому множество, но хотел бы немного остановиться на этом моменте. Подключая второго (третьего . ) провайдера клиент пытается обеспечить резервирование каналов, повысить связность, оптимизировать затраты на Интернет (у провайдера А дешевый «мировой» канал, провайдер В может обеспечить скоростное и дешевое включение в локальные точки обмена трафиком) и .
Ситуация с резервированием канала может иметь два основным сценария:
1) имеется основной канал емкостью 1Гбит. Резервный (только на случай резерва) покупается значительно меньшей пропускной способность — например, 100 Мбит. В этом случае стоит осознавать последствия выхода из строя основного канал — конца света не наступит, но клиенты ощутят перемены;
2) резервный канал покупается аналогичной (или близкой к тому) пропускной способность. Такой канал получается не совсем дешевый и очень не хочется что бы он простаивал. Тут администратор начинает шаманить с разными балансировками.
Природно, что сетевой администратор хочет абсолютно точно понимать как трафик входит/выходит/проходит через его сеть. А бы даже сказал — его автономную систему. Так вот, в этом можно на 100% быть уверенным только в том случае, если используется один провайдер. Если провайдеров несколько, то понимание о трафике в сети перерастает в предположения о трафике в сети. И вот почему.
В рукаве администратора несколько механизмом влияния на информационные потоки (local preference, weight, med, as-path, etc.), но на сколько они эффективны? Скажу, что они достаточно эффективны (кто-бы сомневался), но не до конца. Ниже приведу парочку интересных примеров.
1. Исходящий трафик
Предположим что от двух провайдеров мы получаем Full View. Первый провайдер у нас будет основной, второй — резервный. Определяем политику обработки анонсов от провайдера: устанавливаем на префиксы, полученные от первого провайдера, больший local preference (как вариант) чем на префиксы, полученный от второго провайдера.
Рис. 1
В итоге весь исходящий трафик должен пойти по основному каналу. Визуализируем логические каналы (например с помощью Cacti Weathermap) и наблюдаем странную картину: трафик уходит не только через основной канал, но и через резервный. Как же так?
Все дело в том, что один Full View другому — рознь. Посмотрим на то, что мы получаем от провайдеров, в частности, на количество получаемых префиксов PfxRcd (пример взят с реального маршрутизатора):
#sh ip bgp summary
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
X.X.X.X 4 AAAAA 3582179 106997 96854566 0 0 4w6d 392986
Y.Y.Y.Y 4 BBBBB 772880 508161 96854556 0 0 6d02h 400394
Сессия с оборудованием X.X.X.X (AS-AAAAA) — основная.
Видим разницу в количестве в 8000 префиксов. Это означает, что если мы будет запрашивать ресурсы, находящиеся в этих 8000 сетях, то будет использоваться резервный канал. Почему так получается? Обратив внимание на эти префиксы (дельту) я заметил, что и от основного провайдера я их получаю, но в агрегированном виде. Имеется ввиду, что вместо 4*/24 мы получаем 1*/22. Кто делает эту сумаризацию? Тяжело сказать, наверное, кто-то из upstream’ов.
Небольшой подитог: даже исходящий трафик способен вытекать тудой, кудой мы не ожидаем.
2. Входящий трафик
В этом случае все с одной стороны проще, с другой сложнее.
Каким образом мы можем влиять на поведение входящего трафика? Классика — искуственно удлинять AS-PATH (prepend), отправлять анонсы провайдеру с некоторыми communities для занижения провайдерского local preference (сражу скажу, что такую возможность предоставляют не все провайдеры, а у некоторых, достаточно не маленьких, даже нет looking-glass. В таком случае коллеги звонят провайдеру и дежурный администратор в телефонном режиме рассказывает какие префиксы он «видит» и с какими атрибутами) и другие значительно менее эффективные методы.
Но как бы мы не старались, в большей мере все зависит от политик провайдера. И если с балансировкой/нагрузкой исходящего трафика все более менее хорошо, то входящий трафик мы будем получать в оба канал, причем в достаточно непредсказуемом соотношении.
Например. Наша AS-A имеет связи с двумя провайдерами: AS-B (основной) и AS-C (резервный). Свои сети мы анонсируем обоим провайдерам, но в сторону резервного мы специально удлиняем AS-PATH (хотим получить трафик в этот канал только при неисправностях с основным).
Рис. 2
Резервный провайдер получает анонсы о наших сетях из двух источников: непосредственно от клиента (от нас) и от своих пиринговых партнеров (пунктирная линия). Во многих случаях приходится сталкиваться с тем, что провайдер считает более приоритетным путем в клиентскую сеть тот путь, который непосредственно соединяет его с клиентом. Для этого он (резервный провайдер) увеличивает значения local preference на анонсы, полученные непосредственно от клиента (в данном случае 200), а не от пира (в данном случае 100). Всем своим соседям он расскажет именно об удлиненном пути (анонсах полученных от клиента), так как BGP маршрутизатор анонсирует дальше только лучший маршрут.
Значит, если трафик будет проходить через автономную сеть провайдера AS-B, то получать мы его будем в основной канал, если через сеть провайдера AS-C — в резервный. В итоге, хотим мы того или нет, но входящий трафик к нам будет «заходить» с обоих каналов. В добавок мы получаем ассиметрию: всячески пытаемся отправить трафик в основной канал, а получаем его и с основного, и с резервного.
Небольшой подитог: при двух и более провайдерах, трафик будет «литься» со всех сторон.
3. Иногда, даже порядок установки сессий играет роль
1. Рассмотрим пример.
Рис. 3
Наша сеть (AS-A) связана с провайдером (AS-B). AS-C, AS-D — другие провайдеры, AS-E — такой-же клиент как и мы. Зеленой стрелкой показано распостранение маршрутной информации, синей — входящий трафик.
2. И тут мы решаем установить связь с AS-E (это наш партнер, не провайдер). Суть связи не в организации дополнительного канала, а в обеспечении резервирования — страховки друг друга. По умолчанию, линк должен быть не нагружен. При возникновении аварий, одна AS подстраховывает другую.
Для этого мы устанавливаем политику на исходящие анонсы в сторону партнера, а именно удлиняем AS-PATH. Для партнерской сети этот анонс не является лучшим, поэтому дальше AS-E его не распространяется.
Рис. 4
3. Но так случилось, что наша сессия с основным провайдером порвалась (или это мы тестировали). В таком случае происходит: красные стрелки — распостранение удлиненного маршрута, синие стрелки — путь трафика в сеть.
Рис. 5
И тоже все в порядке.
Сессия с основным провайдером поднимается. Следует отметить, что провайдер AS-D — это тот случай о котором мы говорили ранее (для клиентов устанавливают повышенный local preference), остальные провайдеры такого не делают, то есть выбор пути основывается на AS-PATH.
4. AS-B принимает анонс от AS-A. Анонс без prepend, стало быть этот путь теперь лучший, и именно он анонсируется далее.
Рис. 6
Видим как далее распостраняется анонс и меняются источники трафика:
Рис. 7
5. В конце концов информация о доступности собственных префиксов AS-A доходит до AS-D. Для этой автономной системы такой путь считается менее приемлемым, так как ранее на обновления от клиента (от AS-E) были установлены более высокие local preference. Итогом этих процессов является такое установившееся состояние:
Рис. 8
Прошу обратить внимание на рис. 4 и рис. 8. Как видно, характер входящего трафика существенно меняется. В этом случае наш резервный канал стал если не основным, то далеко не резервным. Как исправить ситуацию? Для возвращения на круги своя можно положить/поднять сессию с партнером (AS-E), но метод далеко не научный.
Небольшой подитог: я хотел продемонстрировать, что иногда даже порядок установки сессий играет роль и влияет на характер трафика. Можно сказать, что случай слегка надуманный, но взят он из реальной жизни и имеет место быть.
Управления трафиком используя протокол BGP и маршрутизация между автономными системами — комплексный и интересный процесс. Количество факторов, влияющих на информационные потоки, даже больше, чем нам может показаться.
Источник
Провайдер заблокировал исходящий трафик, как бороться?
Здравствуйте, суть вопроса следующая.
Провайдер практически полностью блокирует исходящий трафик, от чего интернетом пользоваться практически невозможно, большинство сайтов недоступны, корректно работают только популярные сервисы типа vk, youtube, почта mail ( другие сайты mail.ru не работают ), поисковик google и т.д.
Проблема началась около 10 дней назад, через несколько дней решил позвонить в тех. поддержку провайдера и узнать в чем проблема, ответить мне внятно не смогли, сказали что всё работает нормально и корректно, мол проблема с моей стороны и ни чем помочь не могут. В основном пользуюсь интернетом через wi-fi, думал возможно проблема в нем или роутере, подключался напрямую без роутера и с нескольких ПК с разными ОС — проблема оставалась. Различные сайты теста скорости интернета показывают, что нет исходящего трафика.
Конечно, единственным верным решением было бы бежать от такого провайдера, но в месте где на данный момент проживаю просто нет альтернативы, от чего приходится пользоваться тем, что есть.
Так же пробовал подключатся через различные VPN’ы, но они попросту не коннектились.
Возможно кто сталкивался с подобным, как можно решить «мирно» данный вопрос со своим провайдером и корректно ( что самое главное ) сформулировать ему вопрос?
Помощь в написании контрольных, курсовых и дипломных работ здесь.
Как перенаправит исходящий локальный трафик в сеть, с домена на другой ip в локальной сети?
Подскажите пожалуйста, как можно настроить переадресацию исходящего трафика из локальной сети, к.
Провайдер заблокировал возможность раздавать инет через Wi-Fi
Здравствуйте, есть проблема. Наш провайдер инета является монополистом в доме, с ценами вдвое выше.
роутер глушит исходящий трафик
Добрый день, прошу помощи гуру, так как поиск и мои мозги помочь не могут 🙂 Дано: подключение к.
как зайти на планшет в однокласники если заблокировал провайдер доступ
как зайти на планшет в однокласники если заблокировал провайдер доступ через опера мини видео не.
Источник