підключення віддаленого сайту через волокно: 2 влани шару чи маршрут 3?

Вітаю всіх,

Ще в старі часи, коли у вас було два географічно розділені сайти, посилання були досить звуженими, тому ми поставили на них маршрутизатори і, ну, "маршрутизували" між ip-підмережами на сайт. То була найкраща практика на той час.

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

З огляду на це, чи все ще вважається «найкращою практикою» використовувати маршрутизацію та різні підмережі між віддаленими сайтами? Або ми можемо розширити нашу "локальну" (основну) мережу на віддалений сайт разом з основним сайтом vlans? Це все ще вважається неоптимальною чи навіть поганою практикою? Більш суттєво, чи є причина цього не робити? (Окрім того, я розумію проблему "екскаваторного переривання"; очікується, що окремі фізичні шляхи будуть вирішувати цю ситуацію).

Інші думки?

Дякую!

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

З огляду на це, чи все ще вважається «найкращою практикою» використовувати маршрутизацію та різні підмережі між віддаленими сайтами? Або ми можемо розширити нашу "локальну" (основну) мережу на віддалений сайт разом з основним сайтом vlans? Це все ще вважається неоптимальною чи навіть поганою практикою? Більш суттєво, чи є причина цього не робити? (Окрім того, я розумію проблему "екскаваторного переривання"; очікується, що окремі фізичні шляхи будуть вирішувати цю ситуацію).

По-перше, немає такої речі, як найкраща практика в цій ситуації. Деталі дизайну великих зображень, такі як взаємозв'язки веб-сайтів слой2 / шар3, визначаються потребами бізнесу, бюджетом, можливостями персоналу, вашими уподобаннями та набором функцій вашого постачальника.

Навіть з усією любов'ю до переміщення екземплярів VM між дата-центрами (що набагато простіше при взаємозв’язкух рівня L2 між центрами обробки даних), я особисто все ж намагаюся з'єднати будівлі на рівні 3, оскільки посилання layer3 зазвичай означають:

1. Опустіть opex і зменшіть час вирішення проблеми. Переважна більшість діагностики усунення несправностей у мережі базуються на послугах IP. Наприклад, mtr має видимість лише layer3. Таким чином, стрибки слою 3 набагато легше виправити, коли ви знайдете краплі пакетів, або через перевантаженість або помилки на посиланнях. Layer3 також простіше діагностувати, коли ви маєте справу з проблемами, пов'язаними з кількома шляхами (порівняно, наприклад, з багатошаровим шаром 3, таким як LACP). Нарешті, простіше знайти місце, де знаходиться сервер або ПК, коли ви можете простежити прямо до крайового перемикача.

2. Менші ефіри / заливання доменів. Якщо у вас невідповідні таймери ARP / CAM , ви вразливі до невідомого одноразового затоплення. Виправлення цього добре відоме, але більшість мереж, які я бачу, ніколи не турбуються про відповідність таймерів ARP та CAM правильно. Кінцевий результат? Більше трафіку трафіку та затоплення всередині домену layer2 ... і якщо ви заливаєтесь між своїми посиланнями між будівельними шарами2, ви затоплюєте природні точки перевантаженості мережі.

3. Простіше розгортати брандмауери / ACL / QoS ... всі ці речі можуть працювати на слой2, але вони, як правило, працюють краще на шарі 3 (адже органи постачальників / стандартів витратили щонайменше 15 з попередніх 20 років, будуючи набори функцій постачальників, віддаючи перевагу шар 3) .

4. Менш простягається дерево. MSTP / RSTP зробила spanning-дерево набагато більш терпимим, але всі аромати STP все ще зводяться до того неприємного протоколу, який любить заливати, передає неправильний напрямок, коли ви скидаєте BPDU на посилання, що блокує STP. Коли це могло статися? Сильний перевантаженість, лускаві приймачі, посилання, які йдуть односпрямованими (з будь-якої причини, включаючи людину), або посиланнями, які працюють з помилками.

Чи означає це, що погано розгортати слой2 між будівлями? Зовсім не ... це дійсно залежить від вашої ситуації / бюджету / уподобань персоналу. Однак я б перейшов із посиланнями layer3, якщо інша причина не є іншою. ¹ Ці причини можуть включати релігійні уподобання у вашому персоналі / mgmt, нижча ознайомленість із налаштуваннями шару3 та ін.

Це нелегко, оскільки в обох підходів є переваги та недоліки. У моєму попередньому житті, коли мої службові обов'язки включали набагато більше мережеве адміністрування, а не системне адміністрування, у нас було, можливо, два десятки сайтів в межах 12 миль широкого географічного району. Близько половини цих сайтів, де налаштовано як окремі сайти 3 рівня, які були перенаправлені до головного офісу, а інша половина була налаштована як сайти "Layer-2" (тобто ми просто розширили VLAN на цей сайт).

Перевагами сайтів "Шар-2" були те, що вони були набагато простішими в налаштуванні та обслуговуванні; не потрібні маршрутизатори, не оновлюються наші статичні маршрути, немає реле DHCP, немає окремої конфігурації VLAN тощо. Основними недоліками, які я зазнав, були нетехнічні, такі речі, як набагато важче знайти негідний DHCP-сервер, коли ваш домен широкомовного зв'язку знаходиться у 12 різних будівлях, кожен за кілька миль один від одного. Багато адміністративних завдань стає складнішим, коли вам не вистачає мережевої поділки різних сайтів, такі речі, як різні правила брандмауера для Office A і Office B, але не для Office C, є складними, коли всі вони мають однакову VLAN / підмережу. Я припускаю, що ви також можете вирішити проблему з трансляціями залежно від того, скільки пристроїв у вас є, але за допомогою технології комутації сьогодні, якою вона є,

Переваги сайтів "Шар-3" в значній мірі зворотні для сайтів "Шар-2". Ви отримуєте компартменталізацію, можете писати правила брандмауера для кожного сайту, і ви знаєте, в якій саме будівлі знаходиться проклятий маршрутизатор Linksys. Недоліками, очевидно, є обладнання, необхідне для маршрутизації та необхідна конфігурація та обслуговування. Протоколи динамічної маршрутизації та такі речі, як VTP (якщо ви наважуєтесь їх використовувати!), Можуть полегшити навантаження на конфігурацію, якщо ваша мережа є достатньо складною.

Моя відповідь без відповіді: Не розбивайтесь без зайвих зусиль (тобто не протистояти спокусі бути надмірно розумними), але не дозволяйте короткотерміновому простому вирішенню виграти, де має сенс мати окремі VLAN / підмережі. Як хтось, хто переслідував мою частку серверів Linksys Rogue DHCP ... е "Маршрутизатори" ... Я думаю, що є вагомий випадок для однієї VLAN / підмережі на кожну конструкцію будівельної мережі, щоб просто обмежити шкоду, яку можуть нанести ці неправильні конфігурації . З іншого боку, якщо у вас є лише два сайти, і вони знаходяться прямо поруч, можливо, їм є сенс ділитися тим же VLAN / підмережею.

Як багато хто сказав, є як хороші, так і менш хороші сторони як для L2, так і для L3-рішення. Я працював у телефонній компанії раніше, і я також допомагав меншим мережам розпочати роботу.

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

На мій досвід, рішення L3 було важче зрозуміти сторонам, яким я допомагав. Вартість також може стати проблемою, якщо обладнання та програмне забезпечення повинно підтримуватися виробником. Linux на x86-машині - це дуже економічно вигідний і функціонально заповнений маршрутизатор.

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

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

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

Я думаю, маршрутизація - найкращий вибір. Вся ваша мережа вийде з ладу, якщо волокно розірветься. А маршрутизація з перемикачами шару 3 (перемикання шару 3) швидка як перемикання рівня 2, якщо ви використовуєте CEF або щось подібне.