Як я можу краще ознайомитись з обладнанням (маршрутизаторами), керованим провайдером?


15

У мене є ряд клієнтів, які мають мережеве обладнання, яким керує їх провайдер. Зазвичай це у вигляді комутатора або маршрутизатора, що надається провайдером, розміщених у місці розташування клієнта.

Для сайтів, які мають MPLS або підключення до кількох локацій, було б надзвичайно зручно пов'язати це обладнання з існуючою інфраструктурою моніторингу ( OpenNMS , Observium тощо), тим більше, що всі інші аспекти середовища регулярно перевіряються.

На жаль, більшість постачальників обмежують доступ до обладнання та змушують вас пройти їх для зміни конфігурації. Це зрозуміло, але як я можу отримати більш точну інформацію? В основному у мене спостерігається велика чорна діра.

Недавній приклад - клієнт, у якого виникли проблеми з VoIP (відмови від викликів та проблеми якості) через MPLS-зв'язок між двома установами. У мене немає деталей щодо рівня QoS, реалізованого ( тому що ми не можемо бачити всередині роутера ). Провайдер не має яких - небудь інших , ніж для збільшення пропускної здатності від 4Mbps до 7Mbps пропозицій ( клієнтам додаткових послуг - $$$). Вони сказали: "Ви налагоджуєте зв'язок на віддаленому місці" . Так що, звичайно, клієнт погодився на це без будь-яких інженерних обґрунтувань.

Найкраще, що я міг зробити, - це контролювати порти комутаторів, що ведуть до маршрутизаторів Інтернет-провайдера на обох сайтах, і я не бачив жодної ознаки насичення пропускної здатності ... лише великі стрибки затримки (вимірюється перемикання на комутатор).

Основний сайт: введіть тут опис зображення

Віддалений сайт: введіть тут опис зображення


  • Отже, це щось, про що можна домовитись з провайдером?
  • Ви коли-небудь переконували постачальника надати більш поглиблені дані моніторингу або дозволити SNMP-моніторинг їх обладнання?
  • Який ви звертаєтесь, якщо підозрюєте, що проблема пов’язана з провайдером?

1
Я здивований, що вони принаймні не запропонували б SNMP-можливості лише для читання; у більшості Інтернет-провайдерів, з якими я мав справу, не було проблем із наданням такого роду доступу.
NickW

видалено коментарі, щоб сформувати відповідь за запитом.
Денніс Нолте

Ви стежите за пакетами або лише пропускною здатністю в біт / с?
Денніс Нолте

3
Вітаю на 100 К!
squillman

А як щодо моніторингу входу та виходу до маршрутизатора (з обох сторін)? Ви також можете просто використовувати основні traceroute, pathping, hpingі iperfвизначити , якщо вони посилають пакети , міжсайтовий послідовно по доріжках шорт.
mbrownnyc

Відповіді:


11

Зазвичай для великого контракту ви повинні мати змогу домовитись принаймні лише для читання доступу до їх крайового маршрутизатора.

Однак навіть будуючи новий центр обробки даних біля одного з наших підключень до провайдера (~ 40м кабель) і досить великий контракт тоді я не зміг цього отримати. Часто траплялися якісь витоки даних, які ви могли отримати.

Однак, залежно від місцевих законів, це може бути вже якийсь несанкціонований доступ, і вам слід переконатися, що ви можете отримати дозвіл або ризикувати, що ніхто не помічає :)

Отримати якийсь регрес - це, як звичайно, домовляється , але, швидше за все, не варто.

Приклад невеликого контракту: ми отримуємо до 2 місяців того, що ми їм повертаємо, якщо вони справді зіпсуються і не надають послуги, які ми купуємо у них. Ми (тоді ще) втратили б набагато більше в гіршому випадку, тому це було досить марно з точки зору грошей.

Ми намагалися документувати все «зовнішнє». Що ви не можете змінити, запишіть / відслідковуйте, щоб ви відразу дізналися, чи змінилося.

У нас були документи про те, яку маршрутизацію отримують наші клієнти, скільки часу це зазвичай займає, наскільки велика пропускна здатність між посиланнями, кожна деталь, яку ми могли придумати. Це було зроблено за допомогою провайдера, тому це не зайняло так багато часу, я думаю, це був тиждень чи щось подібне.

Для фактичної фіксації та / або звинувачення :

Якщо ми знайшли конкретну проблему, ми повідомили їх із моніторинговими даними та частинами нашої документації. Стався інцидент, коли вони змінили маршрутизацію, і частина нашого замовника затримка на кілька мс більше, ніж раніше, що було вирішальним для нашої служби.

Однак вони весь час на це не реагували позитивно.

Ми отримали дозвіл "довести", що це їхня проблема, спамували посилання та могли відтворити додаткову затримку, коли буде досягнуто певного порогу. Незабаром після цього було виправлено навіть з різними маршрутами.

В основному є два варіанти:

Або у вас справді хороші зв’язки з відповідальними техніками (читайте CTO провайдера), і вони можуть дозволити вам доступ лише для читання, або вам доведеться спробувати помилку , відтворити проблему (як би важко це не було), а потім отримати хтось насправді це зрозуміє.

Навіть не намагайтесь із звичайною підтримкою клієнтів провайдерів, навіть їх "підтримка вищого рівня" більшість випадків не дозволяє визнати свої помилки.

Все це не працюватиме з достатньою кількістю грошей у контракті.


3

Деякі Інтернет-провайдери можуть надавати сервер із скла , який надає обмежену інформацію для доступу громадськості. Ці відомості, як правило, включають traceroute/ping від маршрутизатора провайдера до конкретного місця, а також базову інформацію BGP.

Можна перевірити такі сайти, як wiki lookinglass.org або bgp4.net, щоб побачити, чи є в мережі Інтернет провайдер. Однак зауважте, що ця інформація дуже обмежена і може не задовольнити оригінальне запитання.

Загалом, відповідь від @ dennis-nolte дійсна: все зводиться до грошей і початкового строку контракту. Досить просто попросити Інтернет-провайдера надати доступ лише для читання, коли ISP помічає великого клієнта під час обговорення первинного контракту, але вони неохоче роблять що-небудь як задум.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.